RAG가 답을 못 찾는 이유: 문서·검색·생성을 나눠 진단하기

RAG가 틀린 답을 내놓으면 원본 문서부터 최종 답변까지 같은 질문의 근거를 따라갑니다. 원본에 답이 없거나, 검색에서 빠지거나, 모델 입력을 만들면서 잘리거나, 전달된 조건을 생성 과정에서 놓쳤을 수 있습니다. RAGAs 원 논문도 검색 문맥의 관련성, 근거를 충실히 쓰는 능력, 생성 품질을 서로 다른 평가 대상으로 다룹니다.

“문서를 연결했으니 검색은 됐을 것”이라는 추정으로 시작하면 문제 위치를 잘못 짚습니다. 검색 서버가 돌려준 결과와 모델이 실제 받은 입력을 각각 보존해야, 검색 설정을 바꿀지 답변 구성을 고칠지 판단할 수 있습니다.

정답 문장과 적용 조건부터 고정하기

진단용 질문에는 기대 답변의 문장보다 근거 위치를 먼저 붙입니다. 문서 ID, 버전, 절이나 페이지와 함께 정답을 뒷받침하는 문장을 표시합니다. 답이 여러 문서에 걸쳐 있으면 필요한 근거 묶음을 적습니다. 정답 하나를 자유롭게 쓴 뒤 그 문구와 비슷한 출력만 찾는 방식은 같은 뜻의 올바른 답을 놓칠 수 있습니다.

가상 사내 규정은 “개인 결제한 교육비는 사전 승인 후 신청일로부터 30일 이내에 청구합니다. 외부 자격시험 응시료는 별도 규정을 따릅니다”라고 정합니다. “교육비 청구 기한”의 근거에는 30일이라는 숫자, 신청일이라는 시작점, 사전 승인 조건이 함께 들어갑니다. “시험 응시료도 30일 안에 청구하는가”에는 별도 규정까지 읽어야 답할 수 있습니다.

원본에서 그 문장을 찾지 못하면 먼저 자료의 존재와 수집 범위를 나눕니다. 담당 부서에도 없는 규정인지, 원본 저장소에는 있지만 수집 대상 폴더 밖인지, PDF 표가 텍스트 추출에서 빠졌는지를 확인합니다. 원본에는 있고 색인용 텍스트에는 없으면 수집·추출 문제입니다. 색인용 텍스트까지 있는데 검색되지 않으면 그다음 단계를 조사합니다.

권한도 같은 기준에 포함합니다. 질문자가 열람할 수 없는 문서에만 답이 있다면, 그 문서를 못 가져온 것을 검색 실패로 세지 않습니다. 평가자는 문서를 볼 수 있지만 실제 질문자는 볼 수 없는 상태를 구분해야 검색 회수율과 접근 통제 평가가 섞이지 않습니다.

검색 결과와 실제 모델 입력의 차이 찾기

검색 로그에는 순위와 점수만 남기지 않고 청크 ID와 반환된 본문도 남깁니다. 같은 ID의 내용이 나중에 바뀔 수 있으므로 원본 버전과 검색 시각도 연결합니다. 질문을 다시 표현한 검색어, 적용한 부서·날짜·권한 필터, 처음 가져온 후보와 재정렬 후 후보를 구별해 보존하면 근거가 빠진 단계를 찾기 쉽습니다.

초기 후보에 정답 근거가 없으면 검색어 해석, 청크 분할, 필터, 색인 상태를 살핍니다. 초기 후보에는 있는데 재정렬 후에 빠졌다면 재정렬과 후보 수를 조사합니다. 모델에 보낸 입력에는 필요한 문장이 없는데 생성 모델부터 교체하면 이 차이를 측정하지 못합니다.

검색 이후에도 입력 한도에 맞추는 과정에서 내용이 줄어들 수 있습니다. Azure AI Search의 semantic ranker 설명은 먼저 검색된 결과를 재정렬하며, 입력을 요약하는 과정에서 길이 한도를 넘는 부분을 자른다고 명시합니다. 서비스마다 방식은 다르므로 진단에서는 검색 응답, 재정렬 결과, 최종 모델 입력을 각각 대조합니다.

최종 입력을 볼 때는 근거 문장만 검색하지 않고 그 앞뒤 조건을 읽습니다. 교육비 기한이 남아 있어도 예외인 시험 응시료 문장이 잘렸다면 답에 필요한 문맥은 불완전합니다. 본문이 들어갔는지와 답할 만큼 들어갔는지는 다른 판정입니다.

근거를 직접 주는 대조 시험의 해석

검색을 거치지 않고 사람이 확인한 근거와 원래 질문을 모델에 직접 넣어 봅니다. 모델, 답변 지시, 출력 한도는 유지하고 근거만 교체합니다. 이때 정답이 나오면 실제 입력까지 근거를 전달하는 경로에 우선 조사할 후보가 생깁니다. 이 시험은 검색기를 건너뛰므로 검색 품질이 개선됐다는 결론은 낼 수 없습니다.