RAG 평가, 정답률만 보면 망한다
"우리 RAG 시스템, 정확도 87%입니다. 잘 되고 있어요."
그 말을 믿었다가, 감사에서 출처 불명 답변이 줄줄이 걸렸다.
먼저, 익숙한 장면 하나
법무팀에서 AI 도입을 검토 중입니다. 사내 규정집, 계약서 템플릿, 판례 요약본을 전부 벡터 DB에 넣고 RAG 시스템을 구축했어요. 몇 주간 테스트를 돌렸고, 정답률(Answer Correctness)이 87%가 나왔습니다. "오케이, 충분하다"는 결론을 내리고 내부 서비스를 오픈했습니다.
그런데 실제로 써보니 이상한 일이 생깁니다.
직원이 "육아휴직 급여 신청 절차가 어떻게 되나요?"라고 물었더니, 시스템이 그럴싸한 답변을 내놨어요. 내용 자체는 틀리지 않았습니다. 그런데 인용된 문서가... 3년 전에 폐기된 구버전 규정이었습니다. 정답률 평가에서는 "맞다"고 나왔지만, 실제로는 직원에게 잘못된 정보를 줄 수 있는 상황이었던 거죠.
이게 단순한 버그가 아닙니다. RAG 평가 방식 자체의 구조적 한계입니다.
"정답률 87%"의 함정
RAG(검색 증강 생성, Retrieval-Augmented Generation)를 도입한 기업들이 가장 먼저 보는 지표는 대부분 비슷합니다. Answer Correctness, 즉 "시스템이 낸 답이 정답과 얼마나 같은가"죠.
이 지표, 왜 문제가 될까요?
전통적인 QA 평가가 RAG에 안 맞는 이유
기존 QA(질의응답) 시스템 평가는 단순했습니다. 질문이 있고, 정해진 정답이 있고, 시스템 출력이 그 정답과 얼마나 일치하는지를 보면 됐어요. 퀴즈 채점이랑 똑같은 구조였죠.
전통적 QA 평가 구조:
질문(Q) → 시스템 답변(A) → 정답(Gold A)과 비교 → 맞으면 1점, 틀리면 0점이 방식은 사실 확인형 질문("서울의 인구는 몇 명인가?")에는 잘 맞습니다. 정답이 명확하고, 답이 맞으면 다른 건 크게 중요하지 않으니까요.
그런데 RAG는 다릅니다. RAG는 단순히 "정답을 찾는 시스템"이 아니에요. "신뢰할 수 있는 근거에 기반해서 복잡한 질문에 답하는 시스템" 입니다. 이 둘은 생각보다 훨씬 다릅니다.
실제로 TREC 2025 RAG Track 논문은 이 문제를 정면으로 지적합니다:
"Participants are challenged to design pipelines that not only combine retrieval and generation but also maintain transparency and factual grounding in their outputs."
— TREC 2025 RAG Track Overview
"투명성(transparency)"과 "사실적 근거(factual grounding)"를 동시에 요구하고 있어요. 정답률 하나로는 이 두 가지를 전혀 측정할 수 없습니다.
정답률이 높아도 신뢰 못 하는 세 가지 상황
실제 현장에서 자주 만나는 시나리오를 좀 더 구체적으로 풀어볼게요.
상황 1: 맞는 말, 근거 없음
시스템이 "이 약품의 부작용으로 두통과 메스꺼움이 보고된 바 있습니다"라고 답했습니다. 정답과 일치합니다. 그런데 막상 인용한 문서를 열어보면, 그 문서 어디에도 해당 약품 이름이 없어요. 모델이 사전 학습 지식으로 답을 만들고, 관련 있어 보이는 문서를 끌어다 붙인 겁니다. 맞긴 한데, RAG로서의 역할을 전혀 안 한 거예요.
상황 2: 맞는 말, 낡은 근거
법령, 규정, 제도처럼 자주 바뀌는 정보를 다루는 시스템에서 자주 발생합니다. 답변 자체는 과거 기준으로는 맞지만, 현재 시점에서는 틀린 정보가 됩니다. 정답률 평가가 과거 기준 데이터셋으로 만들어졌다면 이 오류를 잡아낼 수 없어요.
상황 3: 부분적으로 맞지만, 중요한 부분이 빠짐
"우리 회사 육아휴직 정책 알려줘"라는 질문에, 시스템이 급여 지급 기준은 정확히 답했지만 신청 기한이나 복직 절차는 아예 언급하지 않았습니다. 정답과의 일치율 계산에서는 부분 점수를 받겠지만, 사용자 입장에서는 반쪽짜리 정보를 받은 거예요.
이 세 가지 상황은 단 하나의 공통점을 가집니다: 정답률로는 잡히지 않는다는 것.
TREC 2025가 제안하는 4차원 평가 프레임워크
TREC(Text REtrieval Conference)은 1992년부터 정보검색 분야의 국제 평가 대회를 운영해온 기관입니다. 올해로 34회째를 맞은 이 대회의 2025 RAG 트랙은, 기존의 정답률 중심 평가를 완전히 뒤집는 새로운 프레임워크를 제안합니다.
150개가 넘는 제출 시스템을 평가하면서 도출한 이 프레임워크는 네 개의 축으로 구성됩니다.
1️⃣ Support (근거 지지): "이 답변을 실제로 뒷받침하는 문서가 있는가?"
가장 기본적이지만 가장 많이 놓치는 질문입니다. 시스템이 인용한 문서가 실제로 그 답변을 지지(support) 하는지를 검증하는 겁니다.
- 명시적 지지(Explicit Support): 문서에 답변 내용이 직접 서술되어 있음
- 암묵적 지지(Implicit Support): 문서의 내용을 추론하면 답변이 도출됨
- 비지지(Non-support): 문서가 답변과 관련이 없거나 모순됨
여기서 중요한 건 "암묵적 지지"입니다. Faithful RAG 논문은 이를 더 세밀하게 다루는데, 단순히 키워드 매칭이 되는지가 아니라 추론적 연결고리(reasoning chain) 가 있는지를 봐야 한다고 강조합니다.
2️⃣ Citation (출처 인용): "어떤 문서에서 가져왔는지 밝히고 있는가?"
답변이 어느 문서의 몇 번째 단락에서 나온 건지 추적할 수 있어야 합니다. 이건 단순한 형식 요건이 아니에요. 사용자가 직접 원문을 확인할 수 있어야 RAG 시스템이 진짜 가치를 갖기 때문입니다.
기업·공공기관 맥락에서 Citation이 특히 중요한 이유:
- 감사 대응: "이 답변의 근거가 뭔가요?"라는 질문에 즉각 답할 수 있어야 함
- 책임 소재 명확화: 오류 발생 시 어느 단계에서 잘못됐는지 추적 가능
- 사용자 신뢰: "AI가 그렇게 말했어요"가 아니라 "이 문서 3페이지에 나와 있어요"
3️⃣ Attribution (응답-문서 귀속): "답변의 각 부분이 어떤 문서에서 왔는지 연결할 수 있는가?"
Citation이 "어느 문서를 인용했다"는 선언이라면, Attribution은 좀 더 세밀합니다. 답변의 어느 부분이 어느 문서의 어느 부분에서 왔는지를 추적하는 거예요.
예를 들어, 답변이 세 문장으로 구성된다면:
- 1번 문장 → 문서 A의 2번째 단락
- 2번 문장 → 문서 B의 요약 섹션
- 3번 문장 → 모델 자체 생성 (문서 근거 없음 ⚠️)
이런 식의 세분화된 귀속 관계를 확인할 수 있어야, 어디서 할루시네이션이 발생했는지 정확히 진단할 수 있습니다.
TREC 2025는 MS MARCO V2.1 코퍼스를 사용하면서 문서를 세밀하게 분절(segmentation)한 이유도 바로 이 Attribution 평가를 정밀하게 하기 위해서입니다.
4️⃣ Completeness (완전성): "질문의 모든 측면에 답했는가?"
이게 가장 소홀히 다뤄지는 평가 기준입니다. 답한 내용이 맞는지만 보고, 답하지 않은 내용이 있는지는 잘 안 봐요.
TREC 2025는 단순한 키워드 질문 대신 멀티센텐스 내러티브 쿼리(multi-sentence narrative queries) 를 도입했습니다. 즉, 현실에서 사람들이 실제로 묻는 방식처럼 복잡하고 여러 층위를 가진 질문으로 평가하는 거예요.
예시:
단순 쿼리 (2024): "육아휴직 기간?"
내러티브 쿼리 (2025): "저는 중소기업에 다니는 3년차 직원인데,
내년 초에 둘째 출산을 앞두고 있습니다.
육아휴직을 신청하려면 어떤 조건이 필요하고,
급여는 어떻게 지급되며, 복직 후 불이익을 방지하기 위해
어떤 절차를 밟아야 하나요?"두 번째 질문에 제대로 답하려면, 신청 조건 + 급여 지급 방식 + 복직 절차를 모두 다뤄야 합니다. 어느 하나라도 빠지면 Completeness가 낮은 응답입니다. 정답률은 60%일 수 있어도, 현장에서 사용자는 "쓸모없다"고 느끼겠죠.
Faithful RAG가 더하는 관점: "추론 과정을 드러내라"
TREC 2025가 평가 기준을 다층화했다면, Faithful RAG 논문(arXiv:2603.10143)은 한 발 더 나아가 시스템 설계 자체를 바꿔야 한다고 말합니다.
문제의 핵심: 중간 추론을 검증하지 않는다
일반적인 RAG 파이프라인을 생각해보세요:
질문 → 벡터 검색 → 문서 k개 반환 → LLM에 프롬프트로 전달 → 답변 생성이 파이프라인에는 치명적인 블랙박스 구간이 있습니다. LLM이 k개의 문서를 받아서 답변을 만드는 과정이죠. 이 안에서 무슨 일이 벌어지는지 아무도 모릅니다. 관련 문서 내용을 충실히 반영했을 수도 있고, 문서 내용을 무시하고 사전 학습 지식으로 답을 만들었을 수도 있어요.
Faithful RAG는 이 블랙박스를 열기 위해 명시적 근거 생성(Rationale Generation) 모듈을 도입합니다.
8가지 검증 분류 체계
논문이 제안하는 핵심 아이디어 중 하나는 8가지 카테고리의 검증 분류체계(8-category verification taxonomy) 입니다. 답변의 각 하위 주장(sub-claim)이 어떤 방식으로 문서에 의해 지지되는지를 분류하는 거예요.
간단히 요약하면 크게 두 축으로 나뉩니다:
| 지지 유형 | 설명 | 예시 |
|---|---|---|
| 명시적 지지 | 문서에 직접 서술된 내용 | "약품 A의 부작용은 두통이다"라고 문서에 쓰여 있음 |
| 암묵적 지지 | 문서 내용에서 논리적으로 도출 가능한 내용 | 문서에 "두통을 유발하는 성분 X가 포함됨"이라고 있어 추론 가능 |
| 비지지 | 문서 어디에도 근거 없음 | 모델 자체 지식에서 생성 (할루시네이션 위험) |
이 분류를 각 답변의 하위 주장마다 적용하면, 어느 부분이 신뢰할 수 있고 어느 부분이 위험한지를 수술적으로 진단할 수 있습니다.
쿼리 재작성 + 재순위화: 검색 품질도 함께
Faithful RAG는 생성 단계만 개선하는 게 아닙니다. 검색 단계도 손봅니다.
- 신경망 쿼리 재작성(Neural Query Rewriting): 사용자의 질문을 검색에 최적화된 형태로 변환. "우리 회사 육아휴직 급여 어떻게 돼?"를 "중소기업 육아휴직 급여 지급 기준 및 상한액"으로 재작성하는 식이에요.
- BGE 기반 크로스인코더 재순위화(Cross-encoder Reranking): 처음 검색된 문서들 중에서 실제로 답변에 기여할 문서를 다시 한번 정밀하게 선별합니다.
이 두 가지가 합쳐지면 "잘못된 문서를 가져와서 할루시네이션 발생" 이라는 고전적인 RAG 실패 패턴을 줄일 수 있어요.
실제로 BioASQ와 PubMedQA 벤치마크에서, 이 접근법은 훨씬 큰 모델과 경쟁하면서도 BioASQ-Y/N에서 89.1%, PubMedQA에서 73.0%를 달성했습니다. 의료처럼 정확도가 생명과 직결되는 고위험 도메인에서의 결과라는 점에서 의미가 큽니다.
두 논문이 함께 말하는 것
TREC 2025와 Faithful RAG, 이 두 논문은 서로 다른 각도에서 같은 문제를 조명합니다.
| 구분 | TREC 2025 RAG Track | Faithful RAG |
|---|---|---|
| 초점 | 평가 방법론 | 시스템 설계 + 검증 방법론 |
| 핵심 기여 | 다차원 평가 프레임워크 정립 | 명시적 추론 + 8분류 검증 체계 |
| 적용 대상 | 평가자, 제품 담당자 | ML 엔지니어, 연구자 |
| 핵심 주장 | "정답률 하나론 부족하다" | "추론 과정을 드러내야 신뢰할 수 있다" |
| 공통 결론 | RAG는 근거 기반 시스템이어야 한다 | ← 동일 |
두 논문을 연결하면 이런 그림이 나옵니다:
[TREC 2025의 시각]
평가를 바꿔야 한다 → Support / Citation / Attribution / Completeness
[Faithful RAG의 시각]
시스템을 바꿔야 한다 → 쿼리 재작성 → 정밀 검색 → 추론 생성 → 검증
[두 논문의 교차점]
"RAG의 신뢰성은 최종 답변이 아니라,
근거와 답변 사이의 연결고리에서 만들어진다"다시 말해, 좋은 RAG 시스템은 평가 기준이 엄격해야 개선 방향이 보이고, 시스템이 잘 설계되어야 그 엄격한 평가를 통과할 수 있습니다. 두 논문은 동전의 양면인 셈이에요.
실제 현장에서는 어떻게 다를까?
이론은 이론이고, 현장에서 체감하려면 구체적인 비교가 필요합니다. 같은 질문을 두 가지 평가 기준으로 다뤘을 때 어떻게 달라지는지 봐볼게요.
시나리오: 공공기관 복지 안내 챗봇
질문: "장애인 활동 지원 서비스를 신청하고 싶습니다. 대상자 기준과 신청 방법, 그리고 지원 시간은 어떻게 결정되나요?"
❌ 정답률만 보는 평가 방식
시스템 답변:
"장애인 활동 지원 서비스는 만 6세 이상 65세 미만의 등록 장애인이 신청할 수 있으며, 읍면동 주민센터에서 신청하실 수 있습니다. 지원 시간은 장애 정도에 따라 결정됩니다."
평가 결과: Answer Correctness 82% ✅ (대상자 기준, 신청 방법 언급)
그런데 실제로는:
- 어느 법령/고시에서 이 내용이 나왔는지 불명확
- "지원 시간은 장애 정도에 따라 결정"이라는 표현이 너무 포괄적 (실제로는 종합조사 점수에 따른 등급별 기준시간 + 가산시간 구조)
- 인용 문서를 확인해보니 2021년 기준 (현행 기준과 다름)
이 답변을 받은 민원인은 주민센터에 갔다가 "종합조사를 먼저 받으셔야 해요"라는 말을 듣고 허탕을 칩니다.
✅ 4차원 평가 기준을 적용한 경우
평가 결과:
| 평가 기준 | 점수 | 이유 |
|---|---|---|
| Answer Correctness | 82% | 기본 내용은 맞음 |
| Support | ⚠️ 낮음 | "지원 시간은 장애 정도에 따라" → 인용 문서에 이 표현 없음 |
| Citation | ❌ 불량 | 인용 문서가 폐기된 구버전 고시 |
| Attribution | ⚠️ 부분적 | 대상자 기준 ← 정확한 문서 / 지원시간 ← 귀속 불명 |
| Completeness | ⚠️ 낮음 | 종합조사 절차, 등급별 기준시간 누락 |
종합 판정: 정답률은 높지만 신뢰 불가. 실서비스 사용 부적합.
이 결과를 받은 팀은 즉각 조치를 취할 수 있습니다. 어느 문서 인덱스를 업데이트해야 하는지, 어느 답변 구간에서 모델이 문서를 이탈하는지 정확히 알 수 있으니까요.
지금 당장 적용할 수 있는 평가 체크리스트
이론을 알았으니, 실무에 바로 쓸 수 있는 형태로 정리해드릴게요.
📋 RAG 시스템 평가 체크리스트 v1.0
[A] 답변 품질 (Answer Quality)
- 답변이 질문의 모든 하위 요소를 다루고 있는가? (Completeness)
- 답변의 각 주장이 명확하게 하위 클레임(sub-claim) 으로 분리 가능한가?
- 사실적으로 오류가 있는 내용은 없는가?
[B] 근거 추적 (Grounding)
- 답변의 각 핵심 주장에 인용 문서 번호/ID가 명시되어 있는가? (Citation)
- 인용된 문서를 실제로 열었을 때, 답변 내용이 그 문서에 존재하는가? (Support)
- 문서에 명시적으로 없지만 추론된 내용이 있다면, 그 추론 경로가 타당한가?
[C] 귀속 검증 (Attribution)
- 답변의 각 부분이 어느 문서의 어느 구간에서 왔는지 역추적 가능한가?
- 문서 근거 없이 모델이 자체 생성한(할루시네이션 의심) 구간이 존재하는가?
- 같은 질문을 여러 번 돌렸을 때 인용 문서가 일관성 있게 유지되는가?
[D] 문서 상태 검증 (Document Health)
- 인용된 문서의 최신 버전 여부를 확인하고 있는가?
- 폐기되거나 개정된 정책/법령 문서가 인덱스에 남아있지 않은가?
- 검색된 문서가 질문의 도메인 범위에 적합한가?
[E] 시스템 수준 모니터링
- Attribution 실패율을 주기적으로 추적하고 있는가?
- 정답률과 Completeness 점수 간의 갭을 모니터링하고 있는가?
- 고위험 답변(법령, 의료, 금융 등)에 대해 별도의 엄격한 기준을 적용하는가?
💡 실무 팁: 전체 쿼리를 다 평가하기 어렵다면, 고위험 카테고리(법령 해석, 금액 관련, 절차 안내)를 먼저 샘플링해서 4차원 평가를 적용해보세요. 작은 샘플에서도 금방 패턴이 보입니다.
한계와 현실적 과제
솔직하게 말씀드릴게요. 이 4차원 평가 방식이 완벽한 해답은 아닙니다.
비용과 속도 문제
Answer Correctness 하나만 측정할 때보다, Support + Citation + Attribution + Completeness를 모두 측정하면 평가 비용이 훨씬 올라갑니다. 특히 Attribution 검증은 사람이 직접 하거나, 정밀한 LLM 기반 검증 모델을 별도로 돌려야 해요. 대규모 시스템에서는 부담이 될 수 있습니다.
자동화의 한계
Faithful RAG 논문도 언급하듯이, 명시적 지지와 암묵적 지지를 자동으로 구분하는 건 여전히 어렵습니다. 특히 전문 도메인(법률, 의료, 금융)에서는 "이 추론이 타당한가"를 판단하는 데 도메인 전문가의 눈이 필요해요. 완전 자동화는 아직 갈 길이 멉니다.
내러티브 쿼리 평가의 복잡성
TREC 2025가 도입한 멀티센텐스 내러티브 쿼리는 현실을 더 잘 반영하지만, 평가 자체도 복잡해집니다. "완전히 답했는가"의 기준이 사람마다 다를 수 있고, TREC도 이를 위해 별도의 Relevance Judgment(RJ) 태스크를별도로 운영할 만큼 쉽지 않은 문제입니다.
그럼에도 불구하고
이 한계들이 "그냥 정답률만 보자"는 결론으로 이어져서는 안 됩니다. 오히려 현실적인 접근은 이렇습니다:
- 전수 평가 대신 샘플링: 전체 쿼리의 5~10%만 4차원 평가를 적용해도 시스템의 취약점 패턴을 충분히 파악할 수 있습니다.
- 도메인 위험도에 따른 차등 적용: 모든 답변에 같은 기준을 적용하기 어렵다면, 법령·규정·금액처럼 오류가 치명적인 카테고리에만 엄격한 기준을 우선 적용하세요.
- 자동화 + 인간 검토 병행: LLM 기반 자동 Attribution 검사로 1차 필터링을 하고, 의심 케이스만 사람이 검토하는 하이브리드 방식이 현실적입니다.
- 점진적 도입: 오늘부터 Completeness 하나만 추가해도 내일의 시스템은 달라집니다. 완벽한 체계를 한 번에 갖추려 하지 말고, 하나씩 쌓아가세요.
평가 방식을 고도화하는 것 자체가 시스템 개선의 나침반이 됩니다. 측정하지 않으면 개선할 수 없고, 잘못된 것을 측정하면 엉뚱한 방향으로 개선하게 되니까요.
산업별로 이게 왜 특히 중요한가
잠깐 각 산업 현장의 맥락에서 이 이야기를 다시 해볼게요. 동일한 평가 부재가 업종마다 얼마나 다른 방식으로 문제를 일으키는지 보면, 왜 지금 당장 평가 방식을 손봐야 하는지가 더 선명해집니다.
🏥 의료·헬스케어
환자나 의료진이 RAG 시스템에 약물 상호작용이나 진료 가이드라인을 물어보는 상황을 생각해보세요. 답변이 "대체로 맞는" 수준이어도, Attribution이 잘못되면 최신 가이드라인이 아닌 구버전 기준으로 답한 것일 수 있습니다. Faithful RAG가 BioASQ, PubMedQA 같은 의료 벤치마크에서 검증한 것도 바로 이 맥락입니다.
의료 도메인에서 "대체로 맞는" 답변은 충분하지 않습니다. "왜 그렇게 말하는지 추적 가능한" 답변이어야 합니다.
⚖️ 법률·공공행정
법령은 수시로 개정됩니다. 시행령이 바뀌고, 고시가 업데이트되고, 판례가 새로 쌓입니다. Citation 검증 없이 운영되는 법률 RAG 시스템은 언제든 폐기된 법령을 근거로 답변을 생성할 수 있어요. 이건 단순한 오류가 아니라 행정적 책임 문제로 이어질 수 있습니다.
공공기관 AI 담당자라면 이 질문을 반드시 해보셔야 합니다: "우리 시스템이 인용하는 문서 목록을 감사관에게 보여줄 수 있는가?"
💰 금융·보험
금융 상품 안내, 약관 해석, 세법 적용 등에서 Completeness가 낮은 답변은 심각한 민원으로 이어집니다. "이 상품에 중도 해지 수수료가 있나요?"라는 질문에 수수료 존재 여부만 답하고 구간별 차등 적용 조건을 빠뜨렸다면, 고객은 잘못된 기대를 갖고 계약하게 됩니다.
금융 RAG에서 Completeness는 단순한 품질 지표가 아니라 소비자 보호 문제입니다.
🎓 교육·R&D
연구자가 논문 검색 RAG를 쓰는 경우, Support 검증이 특히 중요합니다. 인용된 논문이 실제로 그 주장을 뒷받침하는지, 아니면 관련 분야 논문이긴 한데 그 클레임은 없는 건지를 구분하지 못하면 잘못된 문헌 인용이 발생합니다. 학술 신뢰성에 직결되는 문제죠.
평가 도구 현황: 지금 쓸 수 있는 것들
"그러면 실제로 이걸 어떻게 측정하나요?"라는 질문이 당연히 나올 것 같아서, 현재 활용 가능한 도구들을 간략히 소개합니다.
RAGAS (RAG Assessment)
현재 가장 널리 쓰이는 RAG 전용 평가 프레임워크입니다. Faithfulness, Answer Relevancy, Context Precision, Context Recall 등의 지표를 자동으로 계산해줍니다.
from ragas import evaluate
from ragas.metrics import (
faithfulness, # Support에 대응
answer_relevancy, # Completeness 일부 반영
context_precision, # Citation 품질 간접 측정
context_recall # 관련 문서 누락 여부
)
result = evaluate(
dataset=your_dataset,
metrics=[
faithfulness,
answer_relevancy,
context_precision,
context_recall
]
)다만, RAGAS도 완벽하지는 않습니다. Attribution의 세밀한 구간별 귀속 추적이나 Completeness의 정교한 측정은 아직 한계가 있어요. TREC 2025가 제안하는 4차원 프레임워크를 완전히 커버하진 않지만, 출발점으로는 충분합니다.
TruLens
LLM 애플리케이션 평가에 특화된 도구로, RAG 트라이어드(Context Relevance + Groundedness + Answer Relevance)를 측정합니다. Groundedness가 Attribution과 가장 가까운 개념입니다.
자체 LLM-as-Judge 구성
예산과 도메인 특수성 때문에 외부 도구가 맞지 않는다면, GPT-4o나 Claude 같은 강력한 LLM을 판정자로 활용하는 방식도 있습니다. 예를 들어:
[Attribution 검증 프롬프트 예시]
다음 답변의 각 문장이 제시된 문서에 의해 지지되는지 판단하세요.
답변: {answer}
인용 문서: {retrieved_docs}
각 문장에 대해 다음 중 하나로 분류하세요:
- EXPLICIT: 문서에 직접 서술됨
- IMPLICIT: 문서 내용에서 논리적으로 도출 가능
- UNSUPPORTED: 문서에 근거 없음 (할루시네이션 의심)
분류 결과와 판단 근거를 함께 제시하세요.이 방식은 도메인 맞춤 기준을 직접 설정할 수 있다는 장점이 있지만, LLM 판정 자체의 일관성을 주기적으로 검증해야 하는 부담이 있습니다.
정리: RAG 평가, 무엇을 봐야 하는가
긴 이야기를 했는데, 핵심만 다시 한번 정리해볼게요.
RAG는 QA가 아니다
RAG 시스템은 "퀴즈 정답을 맞히는 기계"가 아닙니다. 신뢰할 수 있는 근거에 기반해 복잡한 질문에 완전하게 답하는 시스템이에요. 이 차이를 인식하는 순간, 평가 방식도 달라져야 한다는 게 자명해집니다.
TREC 2025가 150개 이상의 시스템을 평가하면서 도달한 결론, Faithful RAG가 의료 도메인의 고위험 환경에서 검증한 원칙, 모두 같은 곳을 가리킵니다:
"답이 맞는지"보다 "그 답이 어디서 왔는지"가 더 중요한 시대가 되었다.
네 가지 축을 기억하세요
| 평가 기준 | 핵심 질문 | 왜 중요한가 |
|---|---|---|
| Support | 인용 문서가 실제로 답변을 뒷받침하는가? | 할루시네이션 탐지 |
| Citation | 출처가 명확히 표시되어 있는가? | 감사 대응, 사용자 신뢰 |
| Attribution | 답변의 각 부분이 어느 문서에서 왔는지 추적 가능한가? | 오류 진단, 책임 소재 |
| Completeness | 질문의 모든 측면에 답했는가? | 실제 사용자 만족도 |
오늘부터 할 수 있는 것
거창한 평가 인프라를 한 번에 구축하지 않아도 됩니다. 다음 세 가지만 이번 주 안에 해보세요:
-
Citation 감사 10건: 시스템이 인용한 문서 10개를 직접 열어서, 답변 내용이 그 문서에 실제로 있는지 확인해보세요. 결과가 놀라울 겁니다.
-
Completeness 갭 찾기: 실제 사용자가 가장 많이 물어본 복합 질문 5개를 골라, 답변이 질문의 모든 하위 요소를 다루고 있는지 체크리스트로 확인해보세요.
-
문서 인덱스 날짜 점검: 현재 벡터 DB에 들어있는 문서들의 최종 수정일을 확인하세요. 1년 이상 지난 정책·법령 문서가 있다면 즉시 업데이트 대상입니다.
마무리: 신뢰는 정확도가 아니라 추적 가능성에서 온다
RAG 시스템을 도입할 때 가장 많이 받는 질문 중 하나가 "정확도가 몇 퍼센트냐"입니다. 경영진도, 고객도, 감사관도 그 숫자 하나를 원하죠. 이해합니다. 단순하고 명확하니까요.
그런데 생각해보면, 우리가 사람에게 일을 맡길 때도 같은 기준을 쓰지는 않습니다. 직원이 "제가 이 보고서 87% 맞게 썼습니다"라고 하면 어떻게 반응하실 건가요? 우리는 자연스럽게 이렇게 묻게 됩니다: "그 근거는요? 어디서 확인한 거예요? 빠진 내용은 없나요?"
RAG 시스템에도 똑같은 질문을 해야 합니다. 그게 바로 Support, Citation, Attribution, Completeness가 하는 역할입니다.
정답률 87%짜리 시스템보다, 정답률 80%여도 모든 답변의 근거를 투명하게 추적할 수 있는 시스템이 기업과 공공기관이 실제로 신뢰하고 운영할 수 있는 시스템입니다.
신뢰는 정확도 숫자에서 오지 않습니다. 추적 가능성(traceability)에서 옵니다.
RAG 시스템을 운영 중이신 분들께 남기고 싶은 질문 하나:
지금 여러분의 시스템이 생성한 답변 중 하나를 골라서, 그 답변의 모든 주장이 어느 문서 어느 단락에서 왔는지 5분 안에 추적할 수 있으신가요?
그 질문에 "예"라고 답할 수 있을 때, 비로소 신뢰할 수 있는 RAG 시스템이라고 말할 수 있습니다.
이 글은 TREC 2025 RAG Track Overview (arXiv:2603.09891)와 Reason and Verify: A Framework for Faithful Retrieval-Augmented Generation (arXiv:2603.10143)을 바탕으로 작성되었습니다.
태그: #RAG #LLM #AI평가 #Hallucination #엔터프라이즈AI #공공AI #TREC2025 #FaithfulRAG #MLOps
