RAG 종류 총정리 ⑨ — 평가: 무엇을 어떻게 재야 개선이 증명되나

여덟 편 동안 변형을 늘어놨지만, 어느 것을 쓸지 정하는 건 결국 측정이다. 그리고 측정 자체에 비용과 함정이 있다. 이 글은 무엇을 재야 개선이 증명되는지, 그리고 왜 대부분의 팀이 잘못된 지표를 비싸게 재고 있는지를 다룬다.

가장 싸고 가장 정확한 평가는 "검색만 따로 재기"

recall@k, nDCG@10, MRR은 정답 문서 ID만 있으면 LLM 호출 0회, 비용 0원, 결정론적으로 계산된다. 반면 RAGAS의 Context Precision은 검색된 청크마다 judge를 호출한다 — top-k 20에 골든셋 300문항이면 지표 하나에 6,000회다. 같은 지표를 ID 기반 모드로 돌리면 0원이 된다.

DeepEval과 promptfoo 모두 공식 문서에서 retriever 지표와 generator 지표를 분리하라고 권한다. 이유는 비용만이 아니다. 검색 실패인지 생성 실패인지 먼저 갈라야 ⑤편의 처방(순위 실패면 리랭커, 근거 실패면 grounding 게이트)이 적용된다. Amazon의 RAGChecker도 답변을 claim 단위로 쪼개 retriever/generator 진단을 분리 제공하는 방향이다.

LLM judge를 믿기 전에 judge를 먼저 평가하라

• 흔들린다. judge 13종 × 피평가 9종을 교차 검증한 Judging the Judges에서 가장 크고 좋은 모델만 사람과 그럭저럭 정렬됐고, 그조차 사람 점수와 최대 5점 차이였다. 관대 편향과 프롬프트 길이 민감성도 확인됐다.
• 작은 판별 모델이 더 낫다. 10만 건 규모의 RAGBench의 결론은 "LLM 기반 RAG 평가법이 파인튜닝된 RoBERTa 하나를 못 이긴다"였다. ARES도 경량 judge 파인튜닝 + 수백 개 사람 라벨(통계 보정)로 충분함을 보였다.
• 1~5점 척도를 버려라. 실무 컨설턴트 Hamel Husain의 조언이 직설적이다 — "1~5점 척도 메트릭을 잔뜩 쓰고 있다면 잘못하고 있는 것". 3점과 4점의 차이를 아무도 정의하지 못하고 전문가 판단과 상관도 거의 없다. 대안은 binary pass/fail + 상세 critique(critique은 few-shot에 그대로 쓸 수 있을 만큼 구체적으로), 그리고 클래스 불균형 때문에 raw agreement 대신 precision/recall 분리.

골든셋은 30개로 시작해 수백 개로 끝난다

"수천 문항을 만들어야 시작할 수 있다"는 생각이 도입을 막는다. 실제 권고는 반대다 — 약 30개부터 시작해 새로운 실패 유형이 더 안 나올 때까지 늘린다. Honeycomb 사례에서는 3회 반복 만에 judge와 전문가 일치율 90%를 넘겼다. ARES는 "수백 개"면 충분하다고 본다.

한국어의 현실적 기준선은 Allganize의 공개 데이터셋이 보여 준다 — 300문항, 5개 도메인(금융·공공·의료·법률·커머스), 문서 63개 약 1,337페이지. 여기서 한국 기업 문서의 특성이 드러난다: 정답 근거가 문단 50~75%, 표 8~25%, 이미지 8~33%다. 근거의 3분의 1이 이미지일 수 있다는 건 파서 품질이 검색기 품질만큼 중요하다는 뜻이고(③·⑧편), 리더보드 상위 점수가 0.847(254/300)이라는 것도 기대치 설정에 도움이 된다.

무료로 쓸 수 있는 한국어 자원도 있다. Ko-StrategyQA로 멀티홉을, KorQuAD 2.0(위키 47,957문서 위 102,960 QA, 표·HTML 포함)으로 구조화 문서를 점검할 수 있다. 다만 KorQuAD 2.0의 사람 성능이 EM 68.82 / F1 83.86이라는 점은 기억해야 한다.

변형을 가르는 벤치마크, 그리고 천장

벤치마크	무엇을 가르나 / 대표 수치
CRAG (Meta KDD Cup)	RAG 도입 효과의 현실. LLM 단독 ≤34% → 단순 RAG 44% → 최고 솔루션 63%
FRAMES	단발 vs 멀티스텝. 검색 없이 0.40 → 멀티스텝 0.66
RGB	노이즈 견딤·근거 없을 때 거절·정보 통합·허위정보 걸러내기를 분리 측정
MultiHop-RAG	멀티홉에서 그래프·에이전틱이 값을 하는지
FinanceBench / LegalBench-RAG	도메인 특화의 냉혹함. 검색 붙인 GPT-4-Turbo가 81% 실패
LongBench v2	롱컨텍스트의 천장. 사람 전문가 53.7% vs 최고 모델 50.1%

RGB의 결과가 특히 실무적이다 — LLM들은 노이즈에는 그럭저럭 견디지만 "근거 없을 때 거절하기", "여러 근거 통합하기", "허위정보 걸러내기"에서 심각하게 실패한다. 사내 RAG 사고의 대부분이 이 세 가지에서 나온다. ⑤편의 기권 경로를 별도 지표로 재야 하는 이유다.

그리고 천장을 인정해야 한다. KorQuAD 2.0 사람 F1 83.86, LongBench v2 사람 전문가 53.7%, BIRD 인간 92.96%. 목표를 "정확도 95%"로 잡는 순간 그 프로젝트는 실패로 끝난다.

오프라인으로는 안 끝난다

RAG 실패 7가지 지점 논문의 결론 두 문장을 다시 인용한다 — "RAG 시스템의 검증은 운영 중에만 실질적으로 가능하고, 견고함은 설계되는 것이 아니라 진화한다." LangSmith의 안내도 같은 구조다: 프로덕션 trace를 데이터셋으로 승격시키고, 온라인 평가는 정답이 없으니 reference-free judge를 쓰되 필터 + 샘플링 비율로 비용을 통제한다.

온라인 지표는 단순한 것이 낫다 — 👍/👎, 에스컬레이션율, 인용 클릭률, 재질문율. 그리고 시맨틱 캐시를 붙였다면(캐싱 시리즈 ⑥편) 이 지표들이 A/B 게이트가 된다. 마지막으로 도구 하나를 덧붙이면, 국내 팀이 만든 AutoRAG가 청킹·리트리버·리랭커 조합을 자동 탐색해 준다. 흥미로운 신호는 이 프로젝트의 무게중심이 2026년에 파이프라인 AutoML에서 에이전트로 옮겨갔다는 것 — RAG 지형 변화가 도구에도 그대로 나타난다. 다음 글은 대부분의 실서비스가 실제로는 챗봇이라는 사실에서 출발한다.

— RAG 종류 총정리 시리즈 ⑨ / 다음 글: 멀티턴 대화형 RAG — 두 번째 질문에서 무너지는 이유