베트남의 한 은행 내부 AI 어시스턴트가 어떤 문서에도 존재하지 않는 컴플라이언스(Compliance) 규칙을 자신 있게 인용하기 시작했을 때, 팀은 자신들이 완전히 잘못된 것을 테스트하고 있었다는 사실을 발견했습니다. 이 포스트에서는 해당 프로젝트에서 RAGAs 평가를 어떻게 설정했는지, Faithfulness(충실도), Context Recall(문맥 재현율), 그리고 Answer Relevance(답변 관련성)가 각각 실제로 무엇을 측정하는지, 그리고 이 세 가지 지표가 어떻게 "데모에서는 좋아 보이는" 방식으로는 결코 얻을 수 없었던 진단 결과를 제공했는지 살펴봅니다.

핵심 요약 (Key takeaways)

• Faithfulness(충실도)는 생성 계층(generation layer)이 검색된 문맥(retrieved context)과 모순되는 사실을 환각(hallucination)하는 것을 포착합니다. 운영 환경에서 이 점수가 0.85 미만이라는 것은 확신에 찬 오답이 사용자에게 전달되고 있음을 의미합니다.
• Context Recall(문맥 재현율)은 검색 계층(retrieval-layer) 지표입니다. Faithfulness 점수가 1.0이면서 Context Recall이 낮다면, 시스템이 불완전한 정보를 정확하게 요약하고 있다는 뜻이며, 이는 똑같이 위험합니다.
• Answer Relevance(답변 관련성)는 기술적으로는 질문에 답하고 있지만 유용한 콘텐츠를 묻어버리는, 지나치게 방어적이거나 군더더기가 많은 응답에 대해 페널티를 부여합니다. 높은 Faithfulness와 Recall이 낮은 Relevance와 여전히 공존할 수 있습니다.
• LLM-as-judge 패턴을 사용하면 대규모의 인간 라벨링 데이터셋 없이도 RAGAs를 실용적으로 사용할 수 있습니다. 평가자로 gpt-4o-mini와 같은 작은 모델을 사용하면 주당 100개 질문 평가 실행 시 비용이 5달러 미만으로 발생합니다.
• 출시 전 응답 경로에 실시간 Faithfulness 게이트를 연결하십시오. 임계값 미만의 답변을 차단하고 '확신할 수 있는 답변을 찾을 수 없습니다'라는 폴백(fallback)을 반환하면 사용자 보고 오답률을 크게 줄일 수 있습니다.

베트남 은행을 위해 구축한 컴플라이언스 어시스턴트가 운영에 들어간 지 6개월 만에 특정하고 경고할 만한 방식으로 실패하기 시작했습니다. 검색 로그(retrieval logs)를 보면 시스템이 올바른 규제 문서를 찾고 있었습니다. 생성 로그(generation logs)를 보면 일관성 있고 잘 구조화된 답변을 보여주었습니다. 하지만 답변에는 검색된 청크(chunk) 어디에도 나타나지 않는 처벌 임계값과 승인 조건이 포함되어 있었으며, 어떤 경우에는 소스 텍스트와 정면으로 모순되기도 했습니다.

팀은 평가 프로세스로 초록 이모지 / 빨간 이모지를 사용하는 Notion 시트를 운영해 왔습니다. 2주마다 수동으로 샘플 점검(spot-checks)을 수행했습니다. 이 실패 모드(failure mode)는 누군가 발견하기 전까지 아마 한 달 동안 존재했을 것이며, 엔지니어링 팀이 아닌 고객 측의 도메인 전문가가 문제를 제기하고 나서야 비로소 알려졌습니다.

이것이 바로 프로덕션 RAG에서 "잘못된 것을 테스트하는 것"이 어떤 모습인지 보여주는 사례입니다. 검색(retrieval)이 제대로 작동하고 있었기 때문에 시스템은 정상적으로 작동하는 것처럼 보였습니다. 생성(generation) 단계에서는 확신에 찬 환각(hallucination)을 일으키고 있었지만, 우리의 모니터링 시스템 중 그 무엇도 이를 잡아내지 못했습니다.

RAGAs를 제대로 설정하는 것이 우리가 첫 주부터 출시했어야 하는 작업이었습니다.

RAGAs란 실제로 무엇인가

RAGAs (Retrieval Augmented Generation Assessment)는 RAG의 품질을 별도로 측정 가능한 독립적인 지표들로 분해하는 평가 프레임워크입니다. 구조적으로 서로 다른 실패 모드들을 하나의 숫자로 뭉뚱그려 버리는 단일 "정확도(accuracy)" 점수 대신, RAGAs는 파이프라인의 각 레이어(layer)별 점수를 제공합니다.

우리의 프로덕션 작업에서 가장 진단적 가치가 높은 세 가지 지표는 Faithfulness(충실도), Context Recall(문맥 재현율), 그리고 Answer Relevance(답변 관련성)입니다. 문제가 발생했을 때, 각 지표는 스택(stack)의 서로 다른 지점을 가리킵니다.

Faithfulness: 답변이 검색된 문맥에 근거하고 있는가?

Faithfulness는 다음과 같은 질문에 답합니다: 시스템이 응답에서 주장한 모든 내용 중, 실제로 검색된 청크(chunks)에 의해 뒷받침되는 내용은 얼마나 되는가?

계산 방식은 다음과 같습니다. LLM-as-judge(판사로서의 LLM)가 생성된 답변을 원자적 주장(atomic claims) — 즉, 개별적인 사실 진술 — 으로 분해한 다음, 각 주장을 검색된 문맥과 대조하여 확인합니다. 점수는 근거가 확인된 주장들의 비율입니다.

from ragas import evaluate
from ragas.metrics import faithfulness
from datasets import Dataset
...

은행 프로젝트에서 120개 질문의 평가 세트에 대한 Faithfulness는 0.71로 나타났습니다. 이는 시스템이 내놓은 주장 10개 중 약 3개가 어떤 검색된 문서에서도 추적할 수 없음을 의미했습니다. 컴플라이언스(compliance) 어시스턴트에게 이 수치는 재앙적인 수준입니다.

우리가 기준으로 삼는 실질적인 임계값(threshold)은 다음과 같습니다: 범용 어시스턴트의 경우 0.90 이상, 컴플라이언스(compliance)에 민감한 모든 서비스의 경우 0.95 이상입니다. 운영 환경(production)에서 이 수치가 0.85 미만이라면, 시스템은 사용자가 감지할 수 없는 속도로 사실을 조작(manufacturing facts)하고 있는 것입니다.

지표를 가장 빠르게 개선하는 해결책은 응답 경로(response path)에 실시간 충실도 게이트(faithfulness gate)를 도입하는 것입니다. 답변을 생성한 후, 가벼운 판사 모델(judge model)로 점수를 매깁니다. 만약 점수가 임계값 아래로 떨어지면, 환각(hallucination)을 그대로 내보내는 대신 "지식 베이스(knowledge base)에서 이에 대한 확신 있는 답변을 찾을 수 없습니다"와 같은 폴백(fallback) 응답을 반환합니다. 은행 프로젝트의 경우, 근본적인 청킹(chunking)이나 검색(retrieval) 문제를 수정하기 전임에도 불구하고 이 게이트를 추가함으로써 사용자 보고 오답률을 약 55% 줄일 수 있었습니다.

컨텍스트 재현율 (Context recall): 검색이 필요한 정보를 찾아냈는가?

컨텍스트 재현율(Context recall)은 검색 계층(retrieval layer)이 질문에 올바르게 답변하는 데 필요한 정보를 실제로 가져왔는지 측정합니다.

계산을 위해서는 정답(ground-truth answer)이 필요합니다. 판사 모델(judge model)은 정답에 포함된 원자적 사실(atomic facts)들을 식별하고, 그 사실들 중 몇 개가 검색된 청크(retrieved chunks)에 존재하는지 확인합니다. 0.6이라는 점수는 올바른 답변을 위해 필요한 사실의 40%가 전혀 검색되지 않았음을 의미하며, 이 경우 생성(generation) 단계에서 아무리 프롬프트 엔지니어링(prompt engineering)을 시도해도 이를 복구할 수 없습니다.

from ragas.metrics import context_recall

result = evaluate(dataset, metrics=[context_recall])
...

이 지표는 검색(retrieval)이 실제 병목 구간(bottleneck)임을 드러내 주는데, 팀들은 이를 생성(generation) 문제로 오인하는 경우가 빈번합니다. 저희는 어시스턴트가 불완전한 답변을 내놓는다는 이유로 팀이 3주 동안 시스템 프롬프트(system prompts)를 다시 쓰는 프로젝트를 본 적이 있습니다. 하지만 실제로는 컨텍스트 재현율(context recall)이 0.55에 머물러 있었고, 정보가 단순히 프롬프트로 전달되지 않고 있었을 뿐이었습니다.

우리가 목표로 하는 하한선은 0.80입니다. 0.70 미만이라면 프롬프트 작업을 멈추고 검색(retrieval)을 먼저 수정해야 한다는 강력한 신호입니다. 실질적인 조절 수단으로는 다음과 같은 것들이 있습니다: 검색되는 top-k 청크(chunks) 수 증가, 하이브리드 검색(hybrid search, BM25와 밀집 벡터(dense vector)의 결합)으로 전환, 쿼리 확장(query expansion) 또는 HyDE 추가, 혹은 청크 크기(chunk size)와 오버랩(overlap) 재검토 등이 있습니다. 컨텍스트 재현율(context recall)은 어느 방향으로 개선을 시도해야 할지 알려줍니다.

은행 프로젝트의 경우, 초기 평가에서 컨텍스트 재현율은 0.68이었습니다. 주요 문제는 규제 문서들이 512토큰(token)의 고정된 경계로 청킹(chunked)되어 있어, 많은 규칙 정의들이 두 개의 청크로 나뉘어 있었다는 점입니다. 검색 시스템이 하나의 청크는 찾아내지만, 인접한 다른 청크는 찾아내지 못했던 것입니다. 문장 윈도우 검색(sentence-window retrieval, 개별 문장을 인덱싱하되 검색된 컨텍스트를 주변 문장까지 포함하도록 확장하는 방식)으로 전환한 결과, 단 한 번의 반복(iteration)만으로 컨텍스트 재현율을 0.68에서 0.84로 끌어올릴 수 있었습니다.

답변 관련성(Answer relevance): 답변이 실제로 질문에 답하고 있는가?

답변 관련성(Answer relevance)은 앞선 두 지표와는 다른 측면을 포착합니다. 답변이 컨텍스트에 완전히 충실(faithful)하고 필요한 모든 정보를 성공적으로 재현(recall)하더라도, 답변이 불필요하게 길거나(padded), 회피적(evasive)이거나, 혹은 질문과는 약간 다른 질문에 답하고 있다면 관련성 점수는 낮게 나올 수 있습니다.

계산 방식은 역생성(reverse-generation) 접근법을 사용합니다. 판사 모델(judge model)이 주어진 답변이 답변할 법한 몇 가지 가상의 질문들을 생성한 다음, 그 가상의 질문들과 실제 사용자 질문 사이의 평균 코사인 유사도(cosine similarity)를 측정합니다. 만약 생성된 답변이 정말로 주제에 부합한다면, 가상의 질문들은 원래의 질문 주변으로 밀집하게 됩니다.

from ragas.metrics import answer_relevancy

result = evaluate(dataset, metrics=[answer_relevancy])
...

우리는 이 지표가 주로 두 가지 상황에서 하락하는 것을 목격합니다. 첫째, 시스템 프롬프트(system prompt)가 모델에게 "포괄적으로 작성하고 관련 문맥을 포함하라"고 지시할 때입니다. 이 경우 모델은 사용자가 요청하지 않은 배경 정보를 추가하게 되며, 답변이 질문에서 벗어나게 됩니다. 둘째, 검색된 문맥(retrieved context)에 부분적으로만 관련 있는 청크(chunks)가 포함되어 있고, 모델이 질문의 여러 가지 가능한 해석을 다루며 확답을 피하려(hedge) 할 때입니다.

우리가 목표로 하는 하한선은 0.80입니다. 해결책은 대개 프롬프트 수술(prompt surgery)입니다. 포괄적인 범위를 제공하기보다는 질문된 특정 질문에 답변하도록 지침을 강화하고, 시스템이 지속적으로 주제에서 벗어난 자료를 가져온다면 검색된 청크의 수를 줄여야 합니다.

세 가지 지표를 함께 실행하기

실제로는 모든 평가 반복(eval iteration) 시 세 가지 지표를 함께 실행합니다. 이 조합을 통해 어떤 레이어를 먼저 수정해야 하는지 알 수 있습니다.

from ragas.metrics import faithfulness, context_recall, answer_relevancy

result = evaluate(
...

LLM-as-judge(판사로서의 LLM) 접근 방식은 시작 단계에서 방대한 양의 사람이 라벨링한 데이터셋이 필요하지 않음을 의미합니다. 우리는 일반적으로 비용 문제로 인해 gpt-4o-mini를 판사 모델(judge model)로 사용합니다. 100개의 질문으로 구성된 평가 세트는 평가 1회 통과 시 5달러 미만으로 실행됩니다. 우리는 이를 프로덕션 파이프라인에 대해 매주 GitHub Actions cron으로 예약하며, 지표가 전주 대비 5%포인트 이상 하락할 경우 알림을 받도록 설정합니다.

모든 프로젝트에서 우리가 접근하는 방식

RAG 시스템이 프로덕션에 배포되기 전, 우리가 배포하는 최소 실행 가능 평가(minimum viable evaluation) 설정은 다음과 같습니다:

출시 전. 최소 80개 이상의 질문으로 구성된 정답(ground-truth) 평가 세트를 구축합니다. 알파 테스트에서의 롱테일 쿼리(long-tail queries), 도메인 전문가가 지적한 엣지 케이스(edge cases), 그리고 답변이 빈번하게 바뀌는 모든 질문 유형(규정, 가격, 정책 등)을 포함합니다. 각 질문에 대해 정답(ground-truth) 답변을 작성합니다. 완벽할 필요는 없습니다. 절대적인 점수보다는 추세(trends)가 더 중요합니다.

출시 시점. 실시간 충실도 게이트 (faithfulness gate)를 연결하세요. 이것은 응답 경로에서 가장 영향력이 큰 단일 추가 사항입니다. 답변을 생성하고, 점수를 매긴 뒤, 임계값(threshold) 미만일 경우 폴백(fallback)을 반환합니다. 모든 프로젝트는 첫 사용자가 사용하기 전에 이 단계를 거쳐야 합니다.

출시 이후. 세 가지 지표 전체에 대한 평가를 매주 실행하세요. 현재의 스냅샷(snapshot)뿐만 아니라 추세선(trend lines)을 추적해야 합니다. 문맥 재현율 (context recall)이 2주 연속 하락 추세를 보인다면, 이는 코퍼스 (corpus)에 추가된 새로운 문서가 청킹 (chunking) 가정을 깨뜨렸거나, 쿼리 (query) 분포가 변화했음을 의미하는 경우가 많습니다.

은행 프로젝트의 경우, 평가 설정에 3일이 소요되었습니다. 충실도 게이트를 구축하는 데는 오후 한나절이 걸렸습니다. 문맥 재현율 수정 (문장 창 검색 (sentence-window retrieval))에는 한 스프린트 (sprint)가 소요되었습니다. 3개월 시점에 충실도는 0.93, 문맥 재현율은 0.87, 답변 관련성 (answer relevance)은 0.84를 기록했습니다. 처음에 경고를 제기했던 컴플라이언스 (compliance) 전문가는 시스템의 가장 강력한 내부 지지자가 되었습니다.

데모를 출시하는 것과 방어 가능한 시스템을 출시하는 것의 차이는 바로 이 세 가지 숫자입니다. 첫 번째 실제 사용자가 알기 전에 이 숫자들을 먼저 확보하세요.

원문 게시처: sapotacorp.vn/blog. SapotaCorp는 Salesforce, Power Platform, Dynamics 365, Shopify, 그리고 AI/RAG 시스템 분야에서 고객 팀에 배치되는 숙련된 베트남 엔지니어를 공급합니다.