RAG 답변 품질 평가 가이드: 검색 재현율부터 인용 검증까지
RAG 답변이 틀렸을 때 검색기와 생성기 중 어디서 문제가 생겼는지 근거성, 검색 재현율, 인용 검증, 실패 샘플로 분리해 진단하는 실무 평가 방법을 설명합니다.
핵심 요약
- 검색 재현율, 답변 근거성, 인용 품질을 분리해 실패 지점을 찾는 평가 구조
- 정상·근거 없음·다중 문서·방해 문서 질문을 포함한 재현 가능한 JSONL 예시
- 자동 평가기 검증과 사람 표본 검토를 포함한 배포 전 체크리스트
사내 규정을 묻자 챗봇이 자연스러운 답과 문서 링크 세 개를 내놓았습니다. 문장은 매끄럽고 링크도 열립니다. 그런데 첫 번째 문서에는 해당 규정이 없고, 두 번째는 폐기된 버전이며, 실제 근거가 있는 세 번째 문서는 답변과 다른 조건을 말합니다.
이 상황을 정답/오답 하나로 기록하면 고칠 곳을 찾기 어렵습니다. 검색기가 최신 문서를 놓쳤는지, 생성기가 검색된 문서를 무시했는지, 답변을 만든 뒤 그럴듯한 링크를 붙였는지 구분되지 않기 때문입니다. RAGAS와 ARES도 RAG 평가를 검색 문맥의 관련성, 답변의 근거성, 답변 관련성처럼 여러 구성요소로 나눕니다. RAGAS 원 논문, ARES 원 논문
1. 최종 답변보다 실패 위치를 먼저 기록한다
RAG 파이프라인은 최소 네 단계로 쪼갤 수 있습니다.
질문
-> 검색 후보 생성
-> 재정렬과 문맥 선택
-> 답변 생성
-> 주장별 인용 연결
| 평가 층 | 확인할 질문 | 필요한 기록 | 대표 실패 |
|---|---|---|---|
| 검색 | 필요한 근거를 찾았는가 | 문서 ID, 순위, 검색 점수 | 정답 문서 누락 |
| 문맥 구성 | 필요한 부분을 모델에 전달했는가 | 청크 ID, 원문, 순서 | 관련 청크 잘림 |
| 생성 | 답변 주장이 문맥에서 나오는가 | 최종 답변, 주장 목록 | 문맥 밖 주장 추가 |
| 인용 | 인용이 바로 앞 주장을 지지하는가 | 주장-문서 연결 | 무관한 링크 첨부 |
최종 답변만 보관하면 검색 결과가 바뀌었는지, 같은 근거를 보고 생성 결과만 달라졌는지 알 수 없습니다. KILT도 최종 과제 성능과 근거 문서의 출처를 함께 평가합니다. KILT 원 논문
2. 평가셋에는 정답과 근거를 함께 넣는다
짧은 질의응답 목록만으로는 검색 재현율을 계산할 수 없습니다. 질문마다 허용되는 답, 필요한 근거 문서, 근거가 없는 경우의 기대 행동을 함께 정의해야 합니다.
다음 JSONL은 가장 작은 형태의 평가셋입니다.
{"id":"leave-001","question":"경조사 휴가 신청 기한은?","expected_facts":["행사일 이전 신청"],"gold_evidence_sets":[["hr-policy-2026#4.2"]],"expected_behavior":"answer","category":"single-hop"}
{"id":"expense-004","question":"해외 출장 숙박비 상한과 예외 승인자는?","expected_facts":["지역별 상한 적용","본부장 예외 승인"],"gold_evidence_sets":[["travel-policy-2026#3.1","approval-policy-2026#2.4"]],"expected_behavior":"answer","category":"multi-hop"}
{"id":"bonus-009","question":"내년 성과급 지급률은?","expected_facts":[],"gold_evidence_sets":[],"expected_behavior":"abstain","category":"unanswerable"}
{"id":"security-012","question":"퇴사자 계정 삭제 기한은?","expected_facts":["퇴사일 당일 비활성화"],"gold_evidence_sets":[["access-policy-2026#7"]],"distractors":["access-policy-2024#7"],"expected_behavior":"answer","category":"stale-conflict"}
gold_evidence_sets는 유효한 근거 조합이 여러 개일 수 있어서 배열의 배열로 둡니다. KILT의 Recall@k도 상위 k개 결과 안에 완전한 근거 집합이 들어왔는지 평가합니다. 여러 문서가 필요한 과제라면 집합 전체가 검색돼야 합니다. KILT 평가 정의
3. 검색 재현율은 정답 문서가 보였는가를 측정한다
검색 재현율은 생성 모델을 호출하기 전에 계산할 수 있습니다. 질문의 허용 근거 집합 중 하나가 상위 k개 결과에 모두 포함됐는지 확인합니다.
def complete_evidence_recall(retrieved_ids, gold_sets, k=5):
top_k = set(retrieved_ids[:k])
if not gold_sets:
return None
return int(any(set(evidence) <= top_k for evidence in gold_sets))
이 값이 0이면 생성 모델을 교체하기 전에 검색 쪽을 봐야 합니다. 임베딩 모델, 키워드 검색, 메타데이터 필터, 청크 크기, 재정렬 방식 중 하나가 필요한 문서를 밀어냈을 가능성이 큽니다.
Recall@k 하나도 충분하지는 않습니다. 상위 결과가 모두 불필요한 문서인데 정답 문서 하나만 끝에 걸린 경우, 모델이 긴 문맥에서 근거를 제대로 사용하지 못할 수 있습니다. RAGAS는 문맥 관련성을 “질문에 필요한 정보에 얼마나 집중돼 있는가”로 따로 평가합니다. RAGAS 원 논문 PDF
평가표에는 완전 근거 집합의 Recall@k, 첫 유효 근거의 순위, 관련 청크 비율, 폐기·권한 밖 문서 노출 여부를 함께 둡니다. 평균과 함께 multi-hop, stale-conflict, unanswerable 범주별 결과를 봐야 특정 유형의 회귀를 찾을 수 있습니다.
4. 근거성은 답변을 주장 단위로 쪼개서 본다
근거성은 답변이 일반적으로 사실인지 묻는 지표가 아닙니다. 제공된 문맥만으로 그 주장을 추론할 수 있는가를 묻습니다. RAGAS는 답변을 짧은 주장으로 분해한 뒤 각 주장이 문맥에서 지지되는지 판정하고, 지원되는 주장 비율로 faithfulness를 계산합니다. RAGAS의 faithfulness 정의
예를 들어 다음 답변을 세 주장으로 나눕니다.
해외 출장 숙박비는 지역별 상한이 적용되며, 초과 시 본부장 승인이 필요합니다. 영수증은 귀국 후 14일 안에 제출해야 합니다.
검색 문맥이 첫 두 주장만 지원한다면 답변 전체를 맞았다고 처리하면 안 됩니다. 세 번째 문장이 그럴듯해도 현재 문맥 밖에서 추가된 주장입니다.
답변 관련성도 근거성과 섞지 않습니다. 질문에 직접 답하지만 근거가 없을 수 있고, 반대로 근거는 맞지만 불필요한 설명이 길어 질문을 제대로 해결하지 못할 수도 있습니다. RAGAS는 답변 관련성을 사실성 평가와 분리해 정의합니다. RAGAS 원 논문
5. 인용은 개수보다 주장과의 연결을 검사한다
링크 세 개가 붙어 있다고 인용 품질이 높은 것은 아닙니다. ALCE는 인용 품질을 두 방향으로 나눕니다. 인용 재현율은 답변의 각 주요 주장이 인용된 문서로 지원되는지 보고, 인용 정밀도는 붙어 있는 각 인용이 실제로 해당 주장을 지지하는지 확인합니다. ALCE 원 논문
평가 데이터에는 다음처럼 주장과 인용의 대응을 남길 수 있습니다.
| 주장 | 인용 | 문서가 주장을 지원 | 판정 |
|---|---|---|---|
| 지역별 숙박비 상한이 있다 | travel-policy-2026#3.1 | 예 | 통과 |
| 예외 승인자는 본부장이다 | approval-policy-2026#2.4 | 예 | 통과 |
| 영수증 제출 기한은 14일이다 | travel-policy-2026#3.1 | 아니요 | 실패 |
답변 생성 후 검색된 문서 중 비슷한 문서를 골라 붙이는 사후 인용은 특히 조심해야 합니다. ALCE의 실험은 닫힌 책 방식으로 답을 만든 뒤 인용을 붙이는 접근이 답변 정확성과 별개로 인용 품질에서 문제가 될 수 있음을 보여줍니다. ALCE 분석
6. 정상 질문보다 실패 샘플이 더 많은 것을 알려준다
평가셋을 자주 묻는 질문만으로 채우면 데모는 좋아 보입니다. 운영 중 곤란한 질문은 대개 경계에서 나옵니다.
| 실패 샘플 | 기대 행동 | 잡아내는 문제 |
|---|---|---|
| 근거가 전혀 없는 미래 정책 질문 | 답변 보류 | 모델의 임의 추정 |
| 두 문서를 모두 읽어야 하는 질문 | 근거 두 개 인용 | 부분 검색 성공 |
| 최신·폐기 문서가 충돌하는 질문 | 최신 문서만 사용 | 버전 필터 오류 |
| 질문과 비슷하지만 답이 다른 방해 문서 | 방해 문서 무시 | 표면 유사도 의존 |
| 권한 없는 문서가 검색되는 질문 | 문서 미노출 | 접근 제어 누락 |
| 여러 조건을 한 문장에 묻는 질문 | 조건별 답변과 인용 | 일부 주장 누락 |
| 오탈자·약어가 포함된 질문 | 같은 근거 검색 | 질의 변형 취약성 |
실패 항목은 수정 후 삭제하지 말고 regression 범주로 옮겨 계속 실행합니다.
7. 자동 평가기는 사람 판정을 기준으로 점검한다
모든 답변을 사람이 읽기는 어렵습니다. 자동 평가기는 반복 실행과 후보 비교에 적합하지만, 평가 모델의 판단을 정답처럼 취급해서도 안 됩니다.
ARES는 문맥 관련성, 답변 근거성, 답변 관련성을 판정하는 모델을 사용하면서 작은 사람 주석 집합으로 예측 오차를 보정합니다. 완전 자동화를 선언하기보다 자동 판정과 사람 표본을 연결한 설계입니다. ARES 원 논문
RAGAS 논문도 평가 결과가 사용하는 LLM의 성능에 크게 의존한다는 한계를 밝힙니다. 같은 설정의 반복 실행에서도 결과가 달라질 수 있으므로 평가 모델, 프롬프트, 출력 스키마와 실행 시각을 기록해야 합니다. RAGAS 한계와 재현성 논의
사람이 판정한 소규모 기준 집합을 고정하고 자동 평가기와의 일치도를 확인하세요. 불일치가 많은 범주와 고위험 질문은 자동 통과시키지 않습니다. 평가 모델이나 프롬프트가 바뀌면 기준 집합부터 다시 실행합니다.
NIST 생성형 AI 프로필은 모델 능력 주장을 경험적으로 검증된 방법으로 평가하고, 출력의 출처와 인용을 배포 전과 운영 중에 검토하도록 권고합니다. RAG 데이터의 출처와 근거성도 검증 대상에 포함합니다. NIST AI 600-1
8. 배포 전 체크리스트
- 질문별 근거 문서와 문서 버전을 기록했다.
- 다중 문서, 근거 없음, 충돌 문서 샘플이 있다.
- 검색 결과와 실제 전달 청크를 함께 저장한다.
- 검색 재현율과 답변 근거성을 분리한다.
- 인용 재현율과 인용 정밀도를 별도로 계산한다.
- 자동 평가기와 사람 판정의 불일치를 확인한다.
- 운영 실패를 회귀 평가셋에 추가한다.
9. 이 평가가 보장하지 못하는 것
첫째, 골드 근거는 완전하지 않을 수 있습니다. 현실의 문서 저장소에는 같은 정책을 설명하는 여러 문서가 있고, 어느 범위까지 정답 근거로 인정할지 사람끼리도 다를 수 있습니다.
둘째, 자동 근거성 판정은 세계 지식의 참·거짓을 보장하지 않습니다. 문맥이 틀렸다면 답변이 문맥에 충실해도 잘못된 답이 됩니다. 문서 자체의 정확성, 최신성, 권한 검토가 먼저 필요하죠.
셋째, 오프라인 평가셋은 운영 환경을 전부 재현하지 못합니다. 색인 갱신 지연, 문서 접근 권한, 외부 저장소 장애, 실제 사용자의 모호한 질문은 배포 후 모니터링에서 다시 확인해야 합니다. NIST도 통제된 시험에서 드러나지 않는 문제를 찾기 위해 실제 사용 환경의 평가를 권고합니다. NIST AI 600-1
고칠 곳이 보이는 점수만 남긴다
한 번의 종합 점수로 RAG를 승인하면 점수가 떨어졌을 때 다시 추측해야 합니다. 검색 재현율이 낮으면 검색 설정을, 근거성이 낮으면 생성 지침과 문맥 구성을, 인용 정밀도가 낮으면 주장-출처 연결을 고칠 수 있어야 합니다.
첫 평가셋은 작아도 됩니다. 실제 업무 질문 열 개를 고르고, 그중 세 개는 근거 없음·다중 문서·폐기 문서 충돌로 바꿔 보세요. 실패가 시작된 단계를 설명할 수 없다면 아직 배포 점수가 아니라 데모 점수에 가깝습니다.