문서 QA용 RAG, 평가는 뭘 먼저 봐야 하나?
결론부터 쓰면, 벡터화 방식보다 먼저 볼 것은 "검색 단계에서 정답 근거가 top-k 안에 들어오는가"이고 그다음이 "생성이 그 근거를 실제로 썼는가"다. 이 둘을 하나의 정답률 점수로 뭉쳐 보면 검색 실패와 생성 실패를 구분하지 못해 원인 진단이 항상 늦다. 2025~2026 문서 QA 벤치마크들은 이미 이 두 단계를 쪼개서 보는 쪽으로 옮겨갔다.
- 정답률 하나로 판단하면 검색 실패와 생성 실패를 구분 못 한다
- 표·숫자 문서는 dense 단독보다 hybrid BM25가 나은 사례가 있다[T²-RAGBench]
- 근거가 맞아도 생성이 그 근거를 실제로 인용했는지는 별도 지표다[GaRAGe]
- PDF에 이미지·표가 많으면 text-only 벡터화만으로는 부족한 경우가 많다[UniDoc-Bench]
- 사내 문서는 공개 벤치마크 점수가 실사용 성능을 대변하지 못할 수 있다
실험실에서 자주 빠지는 함정은 이렇다. 새 임베딩 모델이나 검색기를 붙이고 "정답 맞았나?"만 확인한 뒤 배포로 넘긴다. 이 방식은 답이 맞아도 왜 맞았는지, 근거가 진짜였는지 확인하지 않는다. GaRAGe 실험에서는 여러 SOTA LLM이 relevance-aware factuality score 최대 60%, no-grounding 상황에서의 deflection true positive rate 최대 31%에 그쳤다는 결과가 나왔다. 답이 그럴듯해도 근거 선택이 실패하는 비율이 낮지 않다는 뜻이다.
회수 평가만 보면 왜 함정에 빠지나?
회수(retrieval) 지표만 보고 "검색이 잘 됐다"고 판단하면, 생성 단계에서 근거를 잘못 쓰는 문제를 놓친다. Recall@k, Precision@k, MRR, nDCG@k는 "정답 조각이 검색됐는가"를 보는 지표이지 "생성이 그 조각을 실제로 썼는가"는 별도다. TREC 2025 RAG 트랙은 이 간극을 인정하고 relevance assessment, response completeness, attribution verification, agreement analysis를 함께 쓰는 다층 평가를 제시했다. TREC 2025 RAG Track 공식 페이지
실무에서는 회수율이 90% 이상 나와도 최종 답변의 근거 인용이 틀리는 경우를 여러 번 봤다. 검색기가 top-5에 정답 조각을 넣었어도, 생성 모델이 다른 조각을 섞어 요약하면서 근거를 흐리는 식이다. 이런 실패는 회수 지표에는 안 잡히고 attribution verification 단계에서야 드러난다. GaRAGe는 2366개 질문과 35K+ 주석 passage로 "답이 맞는가"와 "정확히 어떤 근거를 썼는가"를 분리해 측정했는데, 이 분리가 없으면 검색기 교체 실험에서 성능이 좋아졌다고 착각하기 쉽다.
표·숫자 문서는 왜 벡터 검색만으로 부족한가?
일반 텍스트 QA에서 잘 작동하던 dense 검색이 표·숫자가 섞인 문서에서는 성능이 떨어지는 경우가 실측으로 확인됐다. T²-RAGBench는 32,908개의 question-context-answer triple로 금융 텍스트+테이블 RAG를 평가했고, Hybrid BM25(희소+밀집 결합)가 텍스트-테이블 데이터에서 가장 효과적이었다고 보고했다. 숫자 계산이나 표 해석이 들어가는 문서형 QA라면 BM25 단독이나 dense 단독보다 하이브리드 검색을 우선 검토할 근거가 여기서 나온다.
실무 적용 시 주의할 점은, 이 결과가 "금융 텍스트+테이블"이라는 특정 문서군 실험이라는 사실이다. 일반 사내 매뉴얼이나 위키형 문서에서는 같은 우위가 재현되지 않을 수 있다. 표가 거의 없는 문서군에 하이브리드 검색을 붙이면 인덱싱 비용과 지연시간만 늘어나는 경우도 있었다. 문서군 특성을 먼저 확인하고 검색 방식을 정하는 순서가 안전하다.
PDF에 이미지·표가 많으면 뭐가 달라지나?
멀티모달 문서에서는 text-only 벡터화만으로는 성능이 일관되게 낮게 나온다는 결과가 있다. UniDoc-Bench는 70k개의 실제 PDF 페이지와 8개 도메인, 1,600개 멀티모달 QA로 구성됐고 이 중 20%는 다중 주석자와 전문가 판정으로 검증했다. 실험 결과 multimodal text-image fusion RAG가 unimodal 검색이나 joint multimodal embedding retrieval보다 일관되게 우수했다.
이 결과를 사내 문서 QA에 적용할 때는 "이미지·표 비중"을 먼저 재는 게 순서다. 계약서나 사내 규정처럼 텍스트 위주 문서라면 text-image fusion을 도입할 이유가 약하고, 오히려 구현 복잡도와 이미지 처리 비용만 늘어난다. 반면 재무 보고서, 제품 스펙 문서처럼 차트·표가 핵심 정보를 담는 경우라면 fusion 방식을 먼저 검토할 근거가 있다.
정답률 하나로 RAG 성능을 다 말할 수 있나?
말할 수 없다. 이게 이 글에서 바로잡고 싶은 가장 흔한 오해다. Microsoft의 BenchmarkQED는 comprehensiveness, diversity, empowerment, relevance를 개별 품질축으로 두고 LLM-as-a-Judge로 대규모 평가를 자동화했는데, 이런 항목별 점수화가 단일 정답률보다 실제 사용자 만족과 더 가깝다고 정리됐다. Microsoft BenchmarkQED 프로젝트
또 하나 흔한 오해는 "RAG가 항상 long-context LLM보다 낫다"거나 그 반대라는 단정이다. LaRA는 2326개 test case, 4개 QA task, 3개 long-context 유형으로 RAG와 long-context LLM을 비교했는데, 우열이 모델 능력, 컨텍스트 길이, 태스크, 검색 특성의 상호작용에 따라 달라진다고 정리했다. 즉 "이 방식이 항상 낫다"는 문장 자체가 이 분야에서는 성립하기 어렵다. 문서군이 길고 산재해 있을수록 벡터화·검색 설정이 성능을 좌우한다는 점이 우열보다 더 실무적인 결론이다.
자체 평가 세트를 만들면 비용은 얼마나 드나?
공개 벤치마크만으로 사내 문서 QA를 판단하기는 어렵다는 흐름이 강해지고 있다. 2025년 ACL 산업 논문은 enterprise RAG 평가용 QA 벤치를 생성하는 DataMorgana를 소개했고, SIGIR 2025 LiveRAG Challenge에는 약 150명의 연구자가 참여한 맥락에서 공개 데이터의 한계가 드러났다. 사내 문서는 도메인 용어, 표 형식, 문서 구조가 공개 벤치마크와 다르기 때문에 그 격차가 실제 성능 오판으로 이어진다.
비용 측면에서 보면 자체 QA 세트 구축은 초기에 시간이 든다. 질문-답변-근거 조각을 사람이 검증하는 단계가 필요하고, UniDoc-Bench 사례처럼 일부만 다중 주석으로 검증하는 방식도 있다. 여기에 더해 노이즈나 counterfactual content, negative rejection이 섞인 컨텍스트로 강건성을 점검하는 절차까지 넣으면 초기 평가 비용이 배포 전 검증 단계에서 눈에 띄게 늘어난다. 다만 이 비용을 생략하면 배포 후 근거 오류를 사용자가 먼저 발견하는 위험을 감당해야 하므로, 어느 시점에 이 비용을 지불할지 선택하는 문제로 봐야 한다.
핵심 정리
- 문서 QA 평가는 "검색이 정답 근거를 찾았는가"와 "생성이 그 근거를 썼는가"를 분리해서 봐야 한다
- 표·숫자가 섞인 문서는 Hybrid BM25 검토, 이미지·표 비중이 큰 PDF는 text-image fusion 검토가 실측 근거로 뒷받침된다
- 단일 정답률 점수는 근거 선택 실패를 가리므로 항목별 점수화(회수·근거성·완결성)가 안전하다
- RAG와 long-context LLM의 우열은 모델·컨텍스트 길이·태스크에 따라 달라지므로 일반화된 우열 단정은 위험하다
- 사내 문서 QA는 공개 벤치마크만으로 부족하며, 자체 QA 세트 구축 비용을 배포 전 검증 항목으로 미리 계산해야 한다