RAG 평가셋 만드는 법: 검색 증강 생성의 환각을 줄이는 테스트 기준

요약: RAG 시스템은 벡터 DB를 붙였다고 안정해지지 않는다. 검색이 틀리면 답변도 틀리고, 검색은 맞았는데 모델이 다른 말을 섞을 수도 있다. 운영 환경에서 RAG 품질을 보려면 질문 몇 개를 사람이 찍어보는 방식이 아니라, 평가셋과 재현 가능한 테스트 기준이 필요하다.

RAG 실패는 두 단계에서 생긴다

RAG는 크게 검색과 생성으로 나뉜다. 사용자의 질문을 받아 관련 문서를 찾고, 그 문서를 근거로 답변을 만든다. 실패도 두 단계로 나눠 봐야 한다. 첫 번째는 검색 실패다. 필요한 문서가 후보에 들어오지 않거나, 너무 낮은 순위로 밀려 모델 입력에 포함되지 않는 경우다. 두 번째는 생성 실패다. 문서는 들어왔지만 모델이 근거를 잘못 읽거나, 문서에 없는 내용을 그럴듯하게 덧붙이는 경우다.

이 둘을 구분하지 않으면 개선 방향을 잘못 잡는다. 검색 실패인데 프롬프트만 고치면 효과가 작다. 생성 실패인데 임베딩 모델만 바꾸면 비용만 늘어난다. 그래서 RAG 평가셋은 질문과 정답만 있으면 부족하다. 어떤 문서가 근거여야 하는지, 답변에 반드시 포함될 사실은 무엇인지, 포함되면 안 되는 내용은 무엇인지까지 같이 적어야 한다.

골든셋은 실제 질문에서 시작한다

평가셋을 만들 때 처음부터 1,000개를 만들 필요는 없다. 운영 초기에는 50개면 충분하다. 중요한 것은 실제 사용자가 묻는 질문에서 시작하는 것이다. 고객 문의, 사내 검색 로그, 영업팀 질문, 개발자 온보딩 질문, 문서 검색어를 모아 중복을 제거한다. 그다음 제품·정책·기술·장애 대응처럼 유형을 나눈다.

좋은 골든셋 항목은 네 가지를 가진다. 질문, 기대 답변, 근거 문서 ID, 판정 기준이다. 예를 들어 “무료 플랜에서 API 호출 제한은 얼마인가?”라는 질문이 있다면 기대 답변에는 숫자와 조건이 들어가야 한다. 근거 문서 ID는 가격 정책 문서의 특정 섹션이어야 한다. 판정 기준에는 “월간 제한과 초과 시 동작을 모두 언급해야 통과”처럼 적는다.

애매한 질문도 일부러 포함해야 한다. “이거 환불돼요?”처럼 맥락이 부족한 질문은 모델이 단정하지 않고 추가 정보를 물어야 한다. RAG 시스템의 품질은 답을 잘하는 것뿐 아니라 모를 때 멈추는 능력에서도 나온다.

검색 평가: recall@k부터 본다

검색 단계의 첫 지표는 recall@k다. 정답 근거 문서가 상위 k개 안에 들어왔는지 보는 지표다. 예를 들어 k=5로 놓고 50개 질문 중 42개에서 정답 문서가 상위 5개 안에 들어왔다면 recall@5는 84%다. 운영용 RAG라면 먼저 이 숫자를 올리는 데 집중해야 한다.

여기서 주의할 점은 문서 chunk 단위다. 근거 문서 전체가 검색되었다고 해서 충분하지 않다. 실제로 모델 입력에 들어가는 것은 chunk다. 정답 문장이 포함된 chunk가 들어왔는지 봐야 한다. 가격 정책 문서가 검색됐지만 제한 숫자가 있는 섹션이 빠졌다면 검색 성공으로 치면 안 된다.

검색 실패를 보면 개선 방향이 보인다. 용어가 달라서 못 찾는다면 동의어 사전이나 하이브리드 검색이 필요하다. 문서가 너무 길게 잘려 중요한 문장이 빠진다면 chunk 전략을 바꿔야 한다. 최신 문서가 검색되지 않는다면 인덱싱 파이프라인 문제다. 모든 문제를 임베딩 모델 교체로 해결하려고 하면 비용 대비 효과가 낮다.

생성 평가: 근거 일치와 금지 표현을 본다

생성 단계에서는 답변이 근거와 일치하는지 봐야 한다. 자동 평가는 세 가지로 시작할 수 있다. 필수 사실 포함 여부, 근거 없는 주장 여부, 금지 표현 여부다. 필수 사실은 숫자, 날짜, 조건, 예외 조항처럼 명확한 항목이다. 근거 없는 주장은 문서에 없는 기능, 가격, 정책을 말하는 것이다. 금지 표현은 법적 단정, 보안 보장, 의료·투자 조언처럼 서비스 성격에 따라 위험한 문장이다.

LLM을 평가자로 쓰는 방법도 가능하지만, 처음에는 규칙 기반 체크와 사람 샘플링을 섞는 편이 안전하다. 예를 들어 가격 제한 숫자는 문자열 또는 정규식으로 확인한다. 정책 설명의 자연스러움은 사람이 본다. 모든 것을 LLM 평가자에게 맡기면 평가자 모델의 환각까지 관리해야 한다.

답변에는 인용도 필요하다. 사용자가 반드시 링크를 눌러야 하는 것은 아니지만, 시스템 내부 평가에서는 답변 문장과 근거 chunk를 연결해야 한다. 어떤 문장이 어떤 근거에서 나왔는지 추적할 수 있어야 문제가 생겼을 때 수정할 수 있다.

회귀 테스트로 만들어야 한다

RAG 평가는 한 번 돌리는 리포트가 아니라 회귀 테스트가 되어야 한다. 문서를 추가하거나 chunk 크기를 바꾸거나 임베딩 모델을 교체하거나 프롬프트를 수정할 때마다 같은 골든셋을 다시 돌린다. 그래야 개선이 실제 개선인지, 특정 질문만 좋아지고 다른 질문은 망가졌는지 알 수 있다.

테스트 결과는 버전과 함께 저장한다. 인덱스 버전, 문서 스냅샷, 임베딩 모델, 검색 파라미터, 생성 모델, 프롬프트 버전, 실행 시각을 남긴다. RAG는 구성 요소가 많아 “어제는 됐는데 오늘은 안 된다”가 자주 생긴다. 버전 로그가 없으면 원인을 찾기 어렵다.

작은 팀은 스프레드시트로 시작해도 된다. 질문 50개, 기대 답변, 근거 문서, 최근 결과, 실패 유형만 관리해도 충분하다. 이후 자동화가 필요해지면 JSONL로 옮기고 CI에서 일부만 돌리면 된다.

실패 유형을 분류해야 개선된다

테스트가 실패했을 때 단순히 fail로 표시하면 다음 액션이 없다. 실패 유형을 나눠야 한다. 추천 분류는 retrieval-miss, wrong-chunk, stale-doc, prompt-overreach, citation-mismatch, refusal-needed, formatting-error다. retrieval-miss는 정답 문서가 검색되지 않은 것, wrong-chunk는 문서는 맞지만 섹션이 틀린 것, stale-doc은 낡은 문서가 최신 문서를 이긴 것이다.

prompt-overreach는 문서에 없는 내용을 모델이 덧붙인 경우다. citation-mismatch는 답은 맞아 보이지만 인용 근거가 다른 경우다. refusal-needed는 답하면 안 되는 질문에 답한 경우다. formatting-error는 내용은 맞지만 형식 요구를 어긴 경우다. 이렇게 나누면 담당자가 명확해진다. 검색 엔지니어가 볼 문제인지, 문서 담당자가 고칠 문제인지, 프롬프트를 고칠 문제인지 알 수 있다.

운영 기준은 제품 위험에 맞춰 정한다

모든 RAG가 같은 기준을 가질 필요는 없다. 사내 개발 문서 검색은 약간의 누락을 사람이 보완할 수 있다. 반면 가격, 법무, 보안, 의료, 금융 영역은 오답 비용이 크다. 위험한 영역일수록 답변보다 거절과 근거 제시가 중요하다.

기준 예시는 이렇다. 일반 문서 검색은 recall@5 85% 이상, 필수 사실 정확도 90% 이상으로 시작할 수 있다. 고객 정책 답변은 recall@5 95% 이상, 근거 없는 주장 0건을 목표로 잡는다. 수치 자체보다 중요한 것은 팀이 어떤 위험을 감수할지 명시하는 것이다.

실행 체크리스트

• 실제 사용자 질문에서 50개 골든셋을 만든다.
• 각 항목에 질문, 기대 답변, 근거 chunk, 판정 기준을 넣는다.
• 검색 평가는 recall@k와 정답 chunk 포함 여부를 본다.
• 생성 평가는 필수 사실, 근거 없는 주장, 금지 표현을 확인한다.
• 인덱스 버전, 문서 스냅샷, 모델, 프롬프트 버전을 결과와 함께 저장한다.
• 실패 유형을 retrieval-miss, wrong-chunk, stale-doc, prompt-overreach 등으로 나눈다.
• 문서나 프롬프트를 바꿀 때 같은 골든셋으로 회귀 테스트를 돌린다.
• 위험도가 높은 주제는 정확한 답변보다 안전한 거절과 근거 제시를 우선한다.