RAG 검색 품질은 평가 세트부터 고쳐야 한다

RAG 답변이 어색할 때 팀은 모델을 바꾸거나 청크 크기부터 만지기 쉽습니다. 그런데 그 전에 확인할 것이 있습니다. 지금의 검색이 무엇을 놓치고 있는지, 좋아졌다고 말할 기준이 무엇인지입니다. 이 기준 없이 하이브리드 검색과 리랭킹을 더하면 비용과 복잡도만 늘고, 같은 실패가 더 그럴듯한 문장으로 돌아올 수 있습니다.

RAG는 모델이 답변을 만들기 전에 관련 문서를 찾아 근거로 쓰는 방식입니다. OpenAI의 Retrieval 가이드는 벡터 저장소를 데이터의 의미 기반 검색 인덱스로 설명합니다. 하지만 의미가 비슷하다는 것과 업무 질문에 필요한 문서를 정확히 찾는 것은 같은 일이 아닙니다. 제품 코드, 정책 번호, 사람 이름처럼 정확한 단어가 중요한 질문도 있기 때문입니다.

먼저 실제 질문으로 작은 평가 세트를 만든다

평가 세트는 거창한 벤치마크가 아닙니다. 고객 문의, 사내 검색어, 운영자가 자주 받는 질문 중에서 민감한 정보는 제거하고 20~30개를 골라 시작하면 됩니다. 각 질문에 정답 문서를 한두 개 지정하고, 왜 그 문서가 필요한지 한 문장으로 적습니다. 답변 문장만 맞는지 보지 말고 검색 결과에 그 근거가 들어왔는지를 따로 봐야 합니다.

질문은 한 종류로 몰아넣지 않는 편이 좋습니다. 다음처럼 실패하기 쉬운 모양을 섞어야 개선의 방향이 보입니다.

• 정확한 용어·상품 코드·날짜를 포함한 질문
• 같은 뜻을 다른 말로 물어보는 질문
• 여러 문서를 함께 확인해야 하는 질문
• 문서에 답이 없어서 모른다고 답해야 하는 질문
• 오래된 문서가 최신 문서와 충돌할 수 있는 질문

정답 문서는 제목만 기록하지 말고 문서 ID, 버전 또는 수정일, 사용자가 볼 수 있는 근거 문장 위치까지 남깁니다. 그래야 나중에 문서가 바뀌었을 때 평가가 조용히 무너지는 일을 줄일 수 있습니다.

하이브리드 검색은 두 결과를 그냥 더하는 기능이 아니다

Microsoft의 하이브리드 검색 문서는 전문 검색과 벡터 검색을 병렬로 실행하고, 서로 다른 순위 결과를 RRF로 합치는 구조를 설명합니다. 벡터 검색은 표현이 달라도 의미가 가까운 내용을 찾는 데 도움이 되고, 전문 검색은 코드나 고유 명사처럼 정확한 일치가 필요한 경우에 강점이 있습니다. 그래서 “벡터 검색보다 항상 좋다”가 아니라, 어떤 질문군에 둘을 함께 써야 하는지를 평가 세트로 확인하는 것이 순서입니다.

구현을 시작할 때는 검색 결과의 상위 문서와 점수, 적용한 필터를 로그로 남깁니다. 정렬을 임의로 덮어쓰면 관련도 순위가 사라질 수 있으므로, 업무상 필수 정렬과 검색 관련도 정렬을 구분해야 합니다. 권한·제품 상태·작성일 같은 필터도 중요하지만, 필터 때문에 정답 문서가 빠지는 사례가 없는지 평가 질문으로 검증합니다.

리랭킹은 후보 문서를 다시 비교하는 단계다

리랭킹은 첫 검색에서 얻은 후보들을 질문과 함께 다시 비교해 순서를 바꾸는 단계입니다. Cohere의 Rerank 문서는 질문과 문서 목록을 받아 의미 관련도 순으로 재정렬한다고 설명합니다. 따라서 리랭커는 빈 검색 결과를 구해 주는 장치가 아닙니다. 1차 후보에 정답 문서가 하나도 없다면, 먼저 청크·인덱싱·검색어·필터를 고쳐야 합니다.

처음부터 너무 많은 후보를 리랭킹하지 말고, 현재 상위 결과에 정답이 포함되는 비율을 본 뒤 작은 범위부터 비교합니다. 리랭킹 뒤에는 ‘정답 문서가 상위 N개 안에 있는가’와 ‘답변이 그 문서를 실제로 인용했는가’를 분리해 기록합니다. 모델과 언어에 따라 지원 범위와 비용이 다르므로, 공급자의 현재 문서와 요금도 도입 시점에 다시 확인해야 합니다.

답변은 근거를 보이고, 근거가 없으면 멈춘다

검색 결과가 좋아도 모델이 찾지 못한 내용을 채워 넣으면 RAG의 장점이 사라집니다. 답변에는 사용자가 열어 볼 수 있는 문서 제목이나 링크를 붙이고, 여러 근거가 필요하면 각 주장에 대응하는 문서를 가깝게 표시합니다. 검색한 문서가 질문을 뒷받침하지 못하면 자신 있게 답하지 말고, 범위를 좁힐 추가 질문이나 담당자 연결을 제안하는 편이 안전합니다.

특히 정책, 가격, 인사 규정처럼 시점에 따라 달라지는 문서는 문서의 수정일과 적용 범위를 같이 보여야 합니다. 근거 문서가 삭제되었거나 접근 권한이 바뀐 경우에도 답변을 중단하거나 제한된 답변으로 바꾸는 규칙을 둡니다. 인용은 장식이 아니라 사용자가 확인하고 정정할 수 있는 경로입니다.

개선 전후를 같은 질문으로 비교하는 운영 순서

평가 세트가 생기면 변경 하나씩만 비교할 수 있습니다. 청크 크기, 검색 방식, 후보 수, 리랭킹, 프롬프트를 한꺼번에 바꾸면 무엇이 영향을 줬는지 알 수 없습니다. 다음 순서로 진행하면 실패를 되돌리기도 쉽습니다.

1. 현재 설정으로 모든 평가 질문의 상위 문서와 답변 근거를 저장합니다.
2. 질문별로 정답 문서가 상위 N개에 들어왔는지, 근거 없는 답이 있었는지 표시합니다.
3. 하이브리드 검색이나 필터 변경을 한 가지 적용하고 같은 세트를 다시 실행합니다.
4. 정답 문서의 노출, 잘못된 문서의 상승, 응답 시간과 비용을 함께 비교합니다.
5. 1차 후보에 정답이 자주 없을 때만 청크·인덱스·검색어 확장으로 돌아갑니다.
6. 후보에는 있지만 답변이 틀릴 때만 리랭킹 또는 답변 근거 규칙을 조정합니다.

이 기록은 나중에 모델이나 문서가 바뀌었을 때 회귀를 찾는 기준이 됩니다. 새 문서를 추가하거나 권한 체계를 고칠 때도 같은 세트를 다시 돌려야 합니다. 잘되는 질문 몇 개를 골라 확인하는 방식은 실패를 숨기기 쉽습니다.

도입 전에 확인할 최소 체크리스트

• 실제 사용자 질문과 정답 근거가 연결된 평가 세트가 있는가
• 정답 문서가 1차 검색 후보에 들어오는지 먼저 측정했는가
• 고유 명사·코드 질문에서 전문 검색과 벡터 검색을 비교했는가
• 리랭킹 전후의 순위와 비용, 응답 시간을 같은 조건에서 비교했는가
• 답변마다 사용자가 열 수 있는 근거를 표시하는가
• 근거가 없거나 권한이 없는 문서일 때 답변을 멈추는가

RAG 품질은 특정 모델 하나가 보장하지 않습니다. 검색 단계에서 정답 문서를 데려오고, 다시 정렬할 이유가 있는지 확인하고, 답변이 그 문서 밖으로 나가지 않게 하는 운영이 함께 있어야 합니다. 다음 개선은 “무엇을 붙일까”보다 “어떤 질문의 어떤 실패를 고칠까”에서 시작하는 편이 오래 갑니다.