RAG 평가 체크리스트: 검색 품질을 답변 품질과 분리해서 보는 방법

RAG 시스템이 기대만큼 답하지 못할 때 많은 팀이 모델을 바꾸거나 프롬프트를 고칩니다. 그런데 실제 원인은 검색 단계에 있는 경우가 많습니다. 검색된 문서가 틀렸는데 모델이 좋은 답을 만들 수는 없습니다. 반대로 검색은 맞았는데 답변 프롬프트가 근거를 제대로 쓰지 못하는 경우도 있습니다. 그래서 RAG 평가는 검색 품질과 답변 품질을 분리해서 봐야 합니다.

RAG 평가의 목표는 “좋은 답이 나왔나” 하나가 아닙니다. 어떤 문서를 찾았는지, 그 문서가 질문을 답하기에 충분했는지, 모델이 근거를 왜곡하지 않았는지, 모르면 모른다고 했는지를 나눠 봐야 합니다. 그래야 어디를 고쳐야 할지 보입니다.

RAG 실패는 보통 네 단계 중 하나에서 생긴다

RAG 파이프라인은 대략 네 단계입니다.

1. 문서를 잘게 나누고 저장한다.
2. 질문을 검색 쿼리로 바꾼다.
3. 관련 chunk를 가져온다.
4. 모델이 chunk를 근거로 답한다.

실패도 이 네 단계에서 나옵니다. chunk가 너무 작으면 맥락이 끊깁니다. chunk가 너무 크면 검색 점수는 맞아도 답변에 필요한 문장이 묻힙니다. 쿼리 변환이 나쁘면 검색이 엉뚱한 방향으로 갑니다. top-k가 낮으면 필요한 문서를 못 가져오고, top-k가 높으면 잡음이 늘어납니다. 마지막으로 모델이 근거에 없는 내용을 보태면 hallucination이 됩니다.

따라서 “답변이 별로다”라고 뭉뚱그리면 안 됩니다. 검색이 문제인지, 생성이 문제인지, 데이터가 문제인지 먼저 분리해야 합니다.

검색 평가는 정답 문서 기준으로 본다

검색 품질을 보려면 질문별로 “정답 문서” 또는 “정답 chunk”를 지정한 테스트셋이 필요합니다. 처음부터 1,000개가 필요하지 않습니다. 실제 고객 질문 50개만 골라도 충분한 신호가 나옵니다.

각 질문에 대해 다음을 기록합니다.

• 질문 원문
• 기대 답변 요약
• 반드시 포함되어야 하는 근거 문서 ID
• 허용 가능한 대체 문서 ID
• 검색되면 안 되는 오래된 문서 ID
• 난이도: 쉬움, 보통, 어려움
• 질문 유형: 사실 조회, 절차, 비교, 트러블슈팅

이 테스트셋으로 recall@k를 봅니다. 예를 들어 recall@5는 상위 5개 검색 결과 안에 정답 chunk가 들어왔는지 보는 지표입니다. RAG에서 답변 품질이 낮다면 먼저 recall@5를 확인해야 합니다. 정답 근거가 top 5에 없으면 생성 프롬프트를 아무리 고쳐도 한계가 있습니다.

답변 평가는 근거 사용 여부를 본다

검색된 문서가 맞아도 답변이 틀릴 수 있습니다. 이때는 답변 평가 기준이 필요합니다. 단순히 “좋다/나쁘다”가 아니라 항목을 나눕니다.

특히 근거 충실도가 중요합니다. RAG의 장점은 외부 지식을 붙이는 것이지만, 모델이 근거를 무시하고 일반 지식으로 답하면 RAG를 붙인 의미가 줄어듭니다. 답변에는 가능하면 문서 제목, 섹션명, 날짜 같은 trace가 남아야 합니다.

chunk 전략은 숫자로 튜닝해야 한다

RAG 튜닝에서 가장 많이 하는 실수는 chunk size를 감으로 정하는 것입니다. 500자, 1,000자, 2,000자 중 무엇이 좋은지는 문서 종류에 따라 다릅니다. API 문서, 정책 문서, 블로그, FAQ는 적정 크기가 다릅니다.

추천 실험은 간단합니다.

1. 같은 문서셋으로 chunk size 3개를 만든다.
2. overlap 2개를 조합한다.
3. 같은 50개 질문으로 recall@5를 측정한다.
4. 검색 결과의 중복률과 잡음률을 같이 본다.
5. 답변 평가까지 연결해 최종 조합을 고른다.

예를 들어 정책 문서는 조항 단위로 자르는 것이 좋을 수 있고, 튜토리얼 문서는 단계 묶음 단위가 좋을 수 있습니다. 코드 문서는 함수·클래스·파일 경계를 유지하는 편이 유리합니다. 텍스트 길이만 기준으로 자르면 의미 단위가 깨집니다.

재랭킹과 필터는 만능이 아니다

검색 품질이 낮으면 reranker를 붙이고 싶어집니다. reranker는 유용하지만 만능은 아닙니다. 후보군에 정답 문서가 없으면 재랭킹도 구할 수 없습니다. 먼저 recall을 확보하고, 그다음 precision을 높이는 순서가 맞습니다.

필터도 조심해야 합니다. 날짜, 제품 버전, 권한, 언어 필터는 정확도를 높이지만 정답 문서를 배제할 수도 있습니다. 예를 들어 사용자가 “구버전 SDK에서 에러가 난다”고 물었는데 최신 문서만 필터링하면 답을 못 찾습니다. 필터는 질문 의도에 따라 동적으로 적용해야 합니다.

운영에서는 다음 규칙이 실용적입니다.

• 제품 버전이 질문에 있으면 해당 버전을 우선한다.
• 버전이 없으면 최신 문서를 우선하되 오래된 문서도 후보에 남긴다.
• 권한이 필요한 문서는 사용자 권한 확인 후 검색한다.
• 언어 필터는 강제하지 말고 fallback을 둔다.
• 검색 결과가 낮은 점수뿐이면 답변보다 추가 질문을 유도한다.

운영 모니터링은 실패 샘플을 모으는 일이다

RAG는 한 번 튜닝하고 끝나는 시스템이 아닙니다. 문서는 계속 바뀌고 사용자 질문도 바뀝니다. 그래서 운영 모니터링은 평균 점수보다 실패 샘플 수집이 중요합니다.

저장해야 할 로그는 다음입니다.

• 사용자 질문
• 검색 쿼리 또는 embedding 입력
• top-k 문서 ID와 점수
• 최종 답변
• 사용자가 클릭한 근거 문서
• thumbs up/down 또는 재질문 여부
• fallback 발생 여부
• 답변 생성 모델과 프롬프트 버전

이 로그가 있어야 “이번 주에 가격 정책 질문이 왜 자꾸 틀리지?”를 추적할 수 있습니다. 문서가 누락됐는지, chunk가 깨졌는지, 검색 필터가 잘못됐는지, 모델이 근거를 무시했는지 분리할 수 있습니다.

바로 적용할 체크리스트

• 실제 사용자 질문 50개로 작은 평가셋을 만든다.
• 질문별 정답 문서와 허용 가능한 대체 문서를 지정한다.
• recall@5, recall@10을 먼저 측정한다.
• 검색 품질과 답변 품질을 별도 점수로 기록한다.
• chunk size와 overlap은 최소 3개 조합으로 실험한다.
• reranker는 recall 확보 후 precision 개선용으로 붙인다.
• 버전·권한·언어 필터에는 fallback을 둔다.
• 운영 로그에 top-k 문서 ID와 프롬프트 버전을 저장한다.
• 실패 샘플을 매주 10개씩 리뷰한다.

RAG 품질 개선의 출발점은 모델 교체가 아닙니다. 검색이 맞았는지, 답변이 근거를 썼는지, 문서가 최신인지 분리해서 보는 것입니다. 이 분리가 되면 다음 액션이 선명해집니다. 검색이 문제면 인덱싱을 고치고, 답변이 문제면 프롬프트를 고치고, 데이터가 문제면 문서를 고치면 됩니다.