보기 좋게 답변하는 RAG가 정작 중요한 부분, 즉 증거 검색, 올바른 컨텍스트 인용, 그리고 환각(Hallucination) 방지에서 실패하고 있을 수 있습니다. 이 가이드는 RAG 평가를 실행 가능한 엔지니어링 단계로 끌어내립니다.

프로덕션 환경에서의 RAG 평가란 검색(Retrieval), 생성(Generation), 근거성(Groundedness), 완전성(Completeness), 비용(Cost) 및 회귀(Regressions)를 각각 별도로 측정하는 것을 의미합니다. 답변이 그럴듯하게 들리는지만 확인한다면, 당신은 시스템이 아니라 데모를 평가하고 있는 것입니다.

TL;DR

핵심 키워드는 프로덕션 RAG 평가입니다. 스페인어 검색 의도는 실용적입니다: 임베딩(Embeddings), 청킹(Chunking), 리랭킹(Reranking), 프롬프트(Prompts) 또는 모델을 변경하기 전에 테스트 세트를 구축하고, 지표를 선택하며, 게이트(Gates)를 설정하는 것입니다.

저의 견해는 이렇습니다: RAG의 첫 번째 대시보드는 예쁠 필요가 없습니다. 대신 어떤 질문이 실패했는지, 어떤 문서를 검색했는지, 어떤 증거가 누락되었는지, 모델이 어느 부분을 지어냈는지, 그리고 파이프라인의 어떤 변경이 그 문제를 일으켰는지를 알려주어야 합니다.

RAG 평가가 해결하는 문제

RAG는 출처가 포함된 답변을 약속하지만, 그 약속은 여러 계층에서 깨질 수 있습니다. 청킹(Chunking), 임베딩(Embedding), 권한 필터링, 리랭커(Reranker), 프롬프트(Prompt), 모델 또는 인용 형식에서 실패할 수 있습니다. 검색된 증거가 빈약하더라도 최종 답변은 합리적으로 들릴 수 있습니다.

그렇기 때문에 RAG를 하나의 블랙박스(Black box)로 평가하는 것은 편리하지만 위험합니다. 최소한 두 가지 질문을 분리해야 합니다: 올바른 컨텍스트를 검색했는가? 그리고 모델이 환각 없이 그 컨텍스트를 사용했는가?. 이 두 가지를 섞어버리면, 문제는 검색(Retrieval)에 있는데 프롬프트를 수정하거나, 모델이 좋은 출처를 무시하고 있는데 임베딩을 건드리는 상황이 발생합니다.

진지한 평가는 RAG가 작동한다는 것을 증명하려는 것이 아닙니다. 사용자가 발견하기 전에 어디서 작동을 멈추는지 찾아내려는 것입니다.

건강한 파이프라인은 단순히 답변만이 아니라 구성 요소, 즉 데이터셋 (dataset), 검색 (retrieval), 생성 (generation), 평가자 (judges), 임계값 (thresholds), 트레이스 (traces) 및 실패에 대한 인간의 검토를 측정합니다.

사고의 아키텍처: 데이터셋, 파이프라인, 평가자 및 게이트 (Gates)

RAG 평가 시스템은 네 가지 요소로 구성됩니다. 첫째, 실제 질문, 기대 답변, 그리고 가능한 경우 관련 문서가 포함된 데이터셋 (dataset)입니다. 둘째, 해당 질문들에 대해 파이프라인 (pipeline)을 실행하는 재현 가능한 방식입니다. 셋째, 검색 (retrieval)과 답변을 측정하는 평가자 (evaluators)입니다. 넷째, 성능 퇴보 (regression)가 발생했을 때 변경 사항을 차단하는 게이트 (gates)입니다.

데이터셋은 처음부터 거대할 필요가 없습니다. 저는 아무도 검토하지 않은 1,000개의 합성 질문 (synthetic questions)보다 잘 선별된 40개의 질문을 선호합니다. 데이터셋에는 빈번한 사례, 모호한 질문, 권한이 필요한 쿼리, 답변이 없는 질문, 최근의 변경 사항, 그리고 프로덕션 환경에서 RAG가 실패했던 사례들이 섞여 있어야 합니다.

게이트 (gates)가 완벽함을 요구해서는 안 됩니다. 대신 이미 잘 작동하던 것을 악화시키지 않아야 하며, 중요한 실패가 가시화되도록 요구해야 합니다. 검토 가능한 트레이스 (traces)를 동반한 불완전한 임계값 (threshold)이, 누군가 가끔 답변을 검토하겠다는 수동적인 약속보다 훨씬 낫습니다.

from datasets import Dataset
from ragas import evaluate
from ragas.metrics import Faithfulness, AnswerRelevancy, ContextPrecision, ContextRecall
...

MIN_SCORES = {
    "faithfulness": 0.85,
    "answer_relevancy": 0.80,
...

문제를 명확히 구분해주는 지표들

문맥 정밀도 (Context precision)는 검색된 청크 (chunks)가 답변에 유용했는지를 묻습니다. 이는 프롬프트 (prompt)에 쓰레기 데이터를 넣는 행위를 처벌하는 지표입니다. 막연하게 유사한 문서들로 채워진 top-k는 관대해 보일 수 있지만, 정밀도를 낮추고 각 답변의 비용을 높입니다.

확인해야 할 사항

문맥 재현율 (Context recall)은 필요한 증거를 검색했는지를 묻습니다. 이는 반대의 실패를 감지하는 지표입니다. 즉, 모델이 잘못된 답변을 하는 이유가 올바른 데이터가 컨텍스트 (context)에 전혀 전달되지 않았기 때문인 경우를 찾아냅니다. 재현율 (recall)이 떨어진다면, 프롬프트를 수정하는 것만으로는 근본적인 문제를 해결하기 어렵습니다.

충실도 (Faithfulness) 또는 근거성 (groundedness)은 답변이 문맥 (context)에 의해 뒷받침되는지를 측정합니다. 이는 장식적인 출처를 동반한 환각 (hallucination)에 대한 해독제입니다. 답변 관련성 (Answer relevancy)은 답변이 질문에 답하는지를 측정합니다. 사실적 정확성 (Factual correctness) 또는 답변 완전성 (response completeness)은 정답 (ground truth)이 존재할 때 참조값과 비교합니다.

데이터셋 (Dataset): 작게 시작하되, 날카롭게 구성하라

RAG를 위한 유용한 데이터셋은 query, expected_answer, expected_sources 또는 qrels, 권한이 있는 경우 사용자/테넌트 (user/tenant), 질문 카테고리, 난이도 및 실패 노트를 포함해야 합니다. 질문과 답변만 저장한다면, 검색 (retrieval)이 실패한 것인지 생성 (generation)이 실패한 것인지 알 수 없습니다.

부정 질문 (negative questions)을 포함하세요: 모름, 존재하지 않는 문서, 유사한 용어, 교차 권한 (cross-permissions) 및 오래된 데이터 등입니다. 항상 답변하는 RAG는 거절할 줄 아는 RAG보다 더 위험합니다.

실제 발생한 모든 장애는 최소 하나 이상의 평가 케이스를 생성해야 합니다. 고객 지원 팀이 잘못된 답변을 보고했다면, 단순히 프롬프트를 수정하는 것만으로 문제를 종결하지 마세요. 수정 전에는 실패하고 수정 후에는 통과하는 테스트 케이스를 추가하세요. 이러한 습관은 프로덕션 환경을 실수를 반복하는 곳이 아닌, 평가 (evals)의 원천으로 탈바꿈시킵니다.

검색 (Retrieval): 유사도뿐만 아니라 랭킹을 측정하라

검색은 임베딩 (embeddings)에서 끝나지 않습니다. 필터, 권한, 하이브리드 검색 (hybrid search), 재순위화 (reranking), 중복 제거 (deduplication), 문맥 창 (context windows) 및 최종 순서도 중요합니다. top_k=5에서 top_k=12로 변경하면 재현율 (recall)은 향상될 수 있지만, 모델이 무시할 수 없는 노이즈가 유입되어 충실도 (faithfulness)는 악화될 수 있습니다.

라벨링된 관련 문서가 있는 경우에는 recall@k, MRR 또는 NDCG와 같은 랭킹 지표를 사용하세요. 라벨링된 문서가 없는 경우에는 LLM 판사 (LLM judges)를 사용하여 문맥의 관련성을 추정하되, 검토 가능한 예시를 보존해야 합니다. 감사가 없는 판사는 체계적인 오류를 숨길 수 있습니다.

저의 실무 원칙은 다음과 같습니다: 임베딩이나 재순위화 모델 (reranker)을 변경하기 전에 30개의 쿼리를 고정하고, 프롬프트에 정확히 어떤 문서들이 들어가는지 비교하십시오. 만약 검색 결과의 차이를 설명할 수 없다면, 당신은 아직 최적화 (optimization)를 하고 있는 것이 아니라 단순히 노브 (knobs)를 만지고 있는 것뿐입니다.

생성 (Generation): 근거성 (groundedness)은 유용성 (utility)과 같지 않습니다

어떤 답변은 근거가 확실하지만(grounded) 나쁠 수 있습니다. 즉, 올바른 컨텍스트 (context)를 인용하지만 사용자에게 도움이 되지 않는 경우입니다. 반대로 어떤 답변은 유용하지만 위험할 수 있습니다. 완벽하게 대답하지만 출처에 없는 주장을 추가하는 경우입니다. 그렇기 때문에 단 하나의 최종 점수가 아니라 여러 가지 지표 (metrics)가 필요합니다.

근거성 (Groundedness)은 컨텍스트에 대한 정확도 (precision)를 살핍니다. 즉, 증거 범위를 벗어나서 지어내지 않는지를 확인합니다. 완전성 (Completeness)은 기대되는 답변에 대한 재현율 (recall)을 살핍니다. 즉, 중요한 부분을 누락하지 않았는지 확인합니다. 관련성 (Relevance)은 질문에 제대로 답하고 있는지를 살핍니다. 정확성 (Correctness)은 콘텐츠가 정답 (ground truth)과 일치하는지를 살핍니다.

제품 의사결정을 위해서는 트레이스 (traces)와 함께 실패 사례를 보여주어야 합니다: 질문, 청크 (chunks), 답변, 점수 (score), 판정관 (judge)의 이유, 그리고 이전 버전과의 차이점 (diff)을 포함해야 합니다. 합산된 숫자는 추세를 보는 데 유용하며, 구체적인 사례는 문제를 수정하는 데 유용합니다.

LLM 판정관 (LLM Judges): 유용하지만, 신탁 (oracles)은 아닙니다

LLM 기반 평가기는 많은 답변이 단 하나의 정확한 문자열을 갖지 않기 때문에 실용적입니다. OpenAI Evals, LangSmith, Ragas, LlamaIndex, Microsoft Foundry, DeepEval은 모두 동일한 아이디어로 수렴합니다: 기준을 정의하고, 예시를 전달하며, 판정관을 사용하여 구체적인 차원 (dimensions)에 점수를 매기는 것입니다.

하지만 LLM 판정관 또한 하나의 모델입니다. 모델, 온도 (temperature), 판정관 프롬프트 (prompt), 데이터셋 버전, 그리고 임계값 (thresholds)을 고정해야 합니다. RAG를 변경하는 동시에 판정관도 변경한다면, 시스템이 개선된 것인지 아니면 측정 규칙이 바뀐 것인지 알 수 없게 됩니다.

영향력이 큰 샘플에 대해서는 인간의 검토 (human review)를 남겨두어야 합니다: 신뢰도가 낮은 답변, 판정관 간의 불일치, 랭킹의 큰 변화, 그리고 보안, 개인정보 보호 또는 규정 준수 관련 질문들이 이에 해당합니다. 자동화는 양을 줄여주지만, 책임을 없애주지는 않습니다.

팀 전체를 막지 않으면서 게이트 (gates)를 설정하는 방법

게이트를 세 가지 수준으로 나눕니다. PR (Pull Request) 단계에서는 스모크 테스트 (smoke tests), 핵심 질문, 최근 회귀 테스트 (regressions)와 같은 작고 저렴한 하위 집합 (subset)을 실행합니다. Nightly 단계에서는 전체 데이터셋을 실행하여 지표를 측정하고 베이스라인 (baseline)과 비교합니다. 프로덕션 (production) 단계에서는 샘플, 사용자 피드백, 비용, 그리고 검색 드리프트 (retrieval drift)를 모니터링합니다.

단일한 글로벌 임계값 (global threshold)을 사용하지 마세요. 법률, 금융 또는 내부 지원용 RAG는 매우 높은 근거성 (groundedness)을 요구할 수 있습니다. 반면, 탐색적 검색기 (exploratory search engine)는 출처를 인용하고 신뢰 수준을 명확히 밝힌다면 더 많은 노이즈를 허용할 수 있습니다.

게이트 (gates)는 실행 가능한 정보 (actionable information)와 함께 실패해야 합니다. 단순히 faithfulness 낮음이라고만 하는 것은 충분하지 않습니다. 보고서에는 어떤 질문, 어떤 답변, 어떤 청크 (chunks), 그리고 어떤 변경 사항이 회귀 (regression)를 유발했는지 명시되어야 합니다.

비용, 지연 시간 및 지속적 평가

평가에도 비용이 듭니다. 변경 사항이 발생할 때마다 비용이 많이 드는 판사 (judge) 모델을 백 번씩 호출한다면, 팀은 결국 평가 (evals)를 건너뛰게 될 것입니다. 계층 구조를 사용하세요. 정답 세트 (qrels)가 있는 경우 검색 (retrieval)을 위한 결정론적 지표 (deterministic metrics)를 사용하고, 스모크 테스트 (smoke tests)를 위한 저렴한 판사, 그리고 중요한 릴리스 (releases)를 위한 더 강력한 판사를 사용하십시오.

점검해야 할 사항

차원별로 비용을 측정하세요. 검색 (retrieval)은 품질이 저하되기 전에 지연 시간 (latency) 때문에 성능이 저하될 수 있습니다. 리랭커 (reranker)는 관련성 (relevance)을 높일 수 있지만 비용을 두 배로 늘릴 수 있습니다. 더 나은 생성 모델 (generator model)은 한동안 형편없는 검색 (retrieval) 성능을 숨길 수 있습니다. 단계별 비용을 파악하지 못하면 최적화는 불완전하게 남습니다.

프로덕션 환경에서는 충분한 트레이스 (traces)를 저장하세요: 정규화된 쿼리 (query), 적용된 필터, 후보 문서, 최종 문서, 프롬프트 (prompt), 모델, 답변, 점수 (scores) 및 피드백 (feedback). 트레이스가 없다면 모든 RAG 버그는 주관적인 논쟁으로 변질됩니다.

팀에서 흔히 보이는 실수들

• 데모에서 잘 나오는 질문들 위주로, 단 10개의 '행복한 질문' (happy questions)만 평가함.
• 동일한 PR에서 청킹 (chunking), 임베딩 (embedding), 리랭커 (reranker), 프롬프트 (prompt)를 한꺼번에 변경함.
• 검색된 문서들을 저장하지 않고 최종 답변만 측정함.
• LLM 판사 (LLM judge)를 사용하면서 그 프롬프트의 버전을 관리하지 않거나 실패 사례를 검토하지 않음.
• 컨텍스트 재현율 (context recall)이 깨져 있는 상태에서 답변 관련성 (answer relevancy)을 최적화함.
• 답변이 없는 질문, 권한 문제, 만료된 데이터 및 악의적인 사례 (hostile cases)를 포함하지 않음.
• 인용 (citations)을 검증 가능한 증거가 아닌 예쁜 HTML처럼 취급함.

5일간의 도입 계획

• 1일 차: 실제 질문 40개를 추출하고 유형, 위험도, 빈도별로 분류합니다.
• 2일 차: 정답(ground truth)이 있는 사례에 대해 예상 답변(expected answer)과 예상 출처(expected sources)를 추가합니다.
• 3일 차: 현재 파이프라인을 실행하고 답변, 청크(chunks), 모델, 비용 및 지연 시간(latency)을 저장합니다.
• 4일 차: 문맥 정밀도(context precision), 문맥 재현율(context recall), 충실도(faithfulness), 답변 관련성(answer relevancy)을 계산하고, 가장 좋지 않은 10개 사례를 수동으로 검토합니다.
• 5일 차: 핵심 서브셋(subset)을 활용한 CI 게이트(gate)를 생성하고, 전체 데이터셋을 활용한 야간 보고서(nightly report)를 만듭니다.

결론

RAG 평가는 완벽한 지표를 찾는 과정이 아닙니다. 기술적 학습 기계를 만드는 과정입니다. 모든 실패는 하나의 사례를 만들어내고, 모든 변경 사항은 베이스라인(baseline)과 비교되며, 모든 릴리스(release)는 무엇을 얻고 무엇을 잃었는지 알게 됩니다.

저의 권장 사항은 덜 야심 차게, 하지만 더 규율 있게 시작하는 것입니다. 작은 데이터셋, 완전한 추적(traces), 분리된 지표, 겸손한 게이트(gates), 그리고 실패에 대한 인간의 검토를 갖추십시오. 이것이 작동할 때 코퍼스(corpus), 판사(judges), 모니터링을 확장하십시오. 그 반대의 순서는 보기 좋은 대시보드와 취약한 RAG를 만들 뿐입니다.

자주 묻는 질문 (FAQ)

RAG 평가란 무엇인가요?

RAG 평가는 검색 증강 생성 (Retrieval-Augmented Generation) 시스템이 관련 증거를 검색하고, 문맥에 충실하며 정확하고 완전한 답변을 생성하는지 측정하는 과정입니다.

프로덕션 환경의 RAG에는 어떤 지표를 사용해야 하나요?

문맥 정밀도(context precision), 문맥 재현율(context recall), 충실도(faithfulness) 또는 근거성(groundedness), 답변 관련성(answer relevancy), 참조 데이터가 있을 때의 정확도(correctness), 그리고 단계별 비용과 지연 시간(latency)부터 시작하십시오.

RAG를 평가하기 위해 정답(ground truth)이 필요한가요?

항상 필요한 것은 아닙니다. 쿼리(query), 문맥(context), 답변을 통해 관련성과 근거성(groundedness)을 평가할 수 있지만, 정답(ground truth)이 있는 사례를 사용하면 재현율(recall), 완전성 및 회귀(regressions)를 더 정밀하게 측정할 수 있습니다.

Ragas, LangSmith, LlamaIndex 또는 DeepEval 중 무엇을 써야 하나요?

사용 중인 스택에 따라 선택하십시오. 중요한 것은 데이터셋, 기준, 판사(judge) 및 베이스라인(baseline)을 버전 관리하는 것입니다. 구체적인 도구 자체보다는 평가의 규율이 더 중요합니다.

시작하려면 질문이 몇 개나 필요한가요?

잘 태그된 30~50개의 실제 질문만 있어도 중요한 결함을 찾아낼 수 있습니다. 그 이후에는 실제 발생한 인시던트(incident), 검색 로그(search logs), 그리고 검토된 합성 데이터(synthetic cases)를 통해 범위를 확장하십시오.

자동 평가가 인간의 검토를 대체할 수 있나요?

아니요. 자동 평가는 작업량을 줄여주고 회귀(regression)를 감지할 수 있지만, 영향력이 큰 결함은 여전히 인간의 검토와 감사 가능한 추적(auditable traces)이 필요합니다.

프로덕션 환경에서 최소한의 RAG 평가를 구축하는 방법