사내 문서 검색 AI가 자주 틀릴 때 어디부터 점검합니까?

검색과 생성을 떼어 봅니다

사내 문서 검색 AI(RAG)는 여러 단계를 거쳐 답을 만듭니다. 최종 답만 보면 어느 단계에서 틀렸는지 알 수 없으므로, 점검은 검색 결과만 따로 꺼내 보는 것에서 시작합니다.

1. 문서 수집
2. 텍스트 추출
3. 분할
4. 색인
5. 검색과 필터
6. 답변 생성

틀린 답이 나온 질문으로 검색 단계만 실행해, 정답 근거가 들어 있는 문서 조각이 결과에 포함되는지 봅니다. Amazon Bedrock Knowledge Bases라면 검색만 하는 Retrieve와 검색 후 답을 만드는 RetrieveAndGenerate가 따로 있어 이 분리가 쉽고, RAG 평가 기능도 검색만 평가하는 방식과 검색·생성을 함께 평가하는 방식으로 나뉩니다.

점검용 질문은 실제 불만이 들어온 질문에서 고르고, 질문마다 정답 근거가 어느 문서의 어느 부분인지 미리 적어 둡니다. 그래야 검색 결과를 보고 맞았는지 바로 판정할 수 있습니다. 결과는 둘 중 하나로 갈립니다.

• 정답 조각이 없다 → 문서 상태, 분할, 검색 방식, 필터를 봅니다.
• 정답 조각이 있는데 답이 틀렸다 → 답변 생성 지시와 근거 사용 방식을 봅니다.

정답 조각을 못 찾을 때

검색 결과에 정답 근거가 없을 때 가장 먼저 볼 곳은 의외로 문서 자체입니다. 스캔한 PDF는 사람 눈에는 글자로 보여도 추출하면 텍스트가 비어 있을 수 있고, 표는 분할 과정에서 행과 열의 관계가 깨지기 쉽습니다. 같은 규정의 구판과 신판이 함께 색인되어 있으면 검색은 둘 다 찾아오고, 모델은 어느 쪽을 근거로 쓸지 알 수 없습니다. 색인에 실제로 들어간 텍스트를 몇 건 직접 열어 보는 것이 가장 빠른 확인 방법입니다.

분할 크기에는 정답이 없습니다. 조각이 너무 작으면 조항 번호와 본문이 떨어져 문맥을 잃고, 너무 크면 한 조각에 여러 주제가 섞여 검색이 흐려집니다. 규정집처럼 조·항 구조가 뚜렷한 문서는 그 구조를 경계로 나누는 편이 대체로 유리합니다. 분할 방식을 바꾸면 색인을 다시 만들어야 하므로, 바꾸기 전에 평가 세트의 검색 성적을 기록해 두고 바꾼 뒤 같은 질문으로 비교합니다.

Bedrock Knowledge Bases 기준으로는 문장 경계를 지키며 일정 크기로 나누는 기본 분할, 고정 크기 분할, 작은 조각으로 찾고 큰 조각으로 넘기는 계층형 분할, 의미 단위로 나누는 의미 기반 분할을 고를 수 있습니다. 검색 방식은 의미 검색과 하이브리드 검색 중에서 고를 수 있는데, 하이브리드 검색은 지원하는 벡터 저장소에서만 쓸 수 있습니다. 재순위 모델과 복잡한 질문을 작은 질문으로 나누는 질문 분해 기능도 있습니다. 어떤 조합이 맞는지는 문서마다 다르므로 평가 세트로 전후를 비교해 고릅니다.

질문과 문서의 말이 다를 때

사용자는 「연차」라고 묻는데 규정에는 「연차유급휴가」만 있거나, 사내 약어로 묻는데 문서에는 정식 명칭만 있으면 검색이 빗나갑니다. 의미 검색이 어느 정도 흡수하지만 사내 약어나 제품 코드처럼 일반 언어에 없는 말은 놓치기 쉽습니다. 사내 용어집으로 질문을 넓히거나 문서에 별칭을 메타데이터로 붙이는 방법이 있고, 키워드 검색을 섞는 하이브리드 검색도 도움이 될 수 있습니다.

반대로 질문의 답이 문서에 실제로 없는 경우도 적지 않습니다. 이때 고칠 곳은 검색이 아니라 문서이며, AI가 「문서에서 확인되지 않는다」고 답하는 것이 정상 동작입니다. 이런 질문이 반복되면 문서를 보강할 목록으로 모읍니다.

권한과 최신성은 필터로 겁니다

「인사팀 문서는 인사팀만」, 「현행 규정만」 같은 조건을 프롬프트로 지시하면 모델이 지키지 않을 수 있고, 지키더라도 권한 밖 내용은 이미 검색 결과에 들어와 있습니다. 이런 조건은 검색 단계의 메타데이터 필터로 걸어야 합니다. 문서마다 부서·보안 등급·개정일 같은 속성을 붙여 두면 검색 결과 자체에서 걸러낼 수 있습니다. 최신본만 남기는 필터 하나가 구판 인용 오답을 통째로 없애는 경우도 많습니다. 다만 필터에 쓰는 속성은 문서를 올릴 때 함께 붙이는 절차로 만들어 두지 않으면 곧 빠지기 시작합니다. 개정일이 없는 문서가 섞이면 최신본 필터가 그 문서를 놓치거나 잘못 남길 수 있습니다.

정답 조각이 있는데 틀릴 때

검색 결과에 정답 근거가 들어 있는데도 답이 틀렸다면 문제는 생성 단계에 있습니다. 이때 확인할 것은 세 가지입니다.

• 근거만으로 답하라는 지시와 근거가 없으면 모른다고 답하라는 지시가 생성 프롬프트에 있는지 확인합니다. 모델이 근거 대신 일반 지식으로 답하는 경향이 보이면, 제공한 문서 밖의 지식을 쓰지 말라는 지시를 명시합니다.
• 인용 표시가 살아 있는지 확인합니다. Bedrock Knowledge Bases의 프롬프트 템플릿을 직접 고칠 때 $output_format_instructions$ 자리 표시자를 지우면 답에 인용이 붙지 않습니다. 인용이 없으면 사용자가 근거를 확인할 수 없고 오답을 발견하기도 어려워집니다.
• 가져온 조각이 지나치게 많아 서로 다른 내용이 섞이지 않았는지 봅니다. 조각 수를 늘리는 것이 항상 정확도를 높이지는 않습니다.

• 자주 묻는 질문과 정답 근거 문서를 짝지은 평가 세트가 있다
• 답하면 안 되는 질문이 평가 세트에 들어 있다
• 검색 결과만 따로 확인하는 방법이 있다
• 문서 추가·개정 때 구판이 색인에서 빠진다
• 분할·검색 설정을 바꿀 때 평가 세트로 전후를 비교한다
• 사용자가 오답을 신고할 수 있고 그 사례가 평가 세트로 들어간다

참고 자료

• AWS — Bedrock Knowledge Bases 콘텐츠 분할 방식
• AWS — Bedrock Knowledge Bases 검색·응답 생성 설정
• AWS — Amazon Bedrock RAG 평가