내 RAG의 Faithfulness는 0.67였다. 3개 중 1개의 답변은 여전히 틀렸다.

description: "온프레미스 (On-prem) JQaRA 평가. Reranking (재순위화)이 P@1을 약간 높였으나 시스템은 여전히 3분의 1의 확률로 틀렸다. 왜 Faithfulness (충실도) 하나만 보는 것이 함정인지, 그리고 대신 무엇을 게이트(gate)로 삼아야 하는지에 대하여."

나는 작은 일본어 RAG (Retrieval-Augmented Generation) 시스템을 구축했고, 이를 전적으로 내 개인 하드웨어 (RTX 5090, Ollama)에서 실행했으며, 생성 모델이 스스로의 숙제를 채점하게 하는 대신 **독립적인 판사 모델 (independent judge model)**을 사용하여 평가했다.

두 가지 사실이 나를 놀라게 했으며, 이 둘은 서로 연결되어 있다:

모두가 가장 먼저 시도하는 방법인 Reranker (재순위화 모델)를 추가했지만, 결과는 거의 변하지 않았다.
나의 Faithfulness (충실도) 점수는 수용 가능한 수준(0.67)으로 보였으나, 100개의 답변 중 33개는 검색된 컨텍스트 (retrieved context)에 근거했음에도 불구하고 사실 관계가 틀렸다.

이 포스트는 왜 이 두 사실이 같은 이야기인지, 그리고 왜 Faithfulness 게이트 하나만으로는 시스템의 오류를 전혀 감지하지 못한 채 3분의 1의 확률로 틀리는 시스템을 출시하게 될 것인지에 대해 다룬다.

요약 (TL;DR)

Reranking (재순위화)은 P@1을 1.3포인트 향상시켰으나, Recall@10 (재현율)은 낮췄다. 이는 검색(retrieval)이 이미 찾아낸 것들의 순서를 바꾸는 것이지, 검색이 놓친 것을 찾아낼 수는 없기 때문이다.
진정한 병목 현상은 Recall (재현율)이었다 (context_recall = 0.41): 답변에 필요한 증거가 아예 검색되지 않는 경우가 많았다.
faithfulness = 0.67은 함정이다. Faithfulness는 답변이 검색된 컨텍스트와 일치하는지를 측정하는 것이지, 답변이 _정확한지_를 측정하는 것이 아니다. 잘못되었지만 검색된 컨텍스트에 근거한 답변은 Faithfulness 점수가 높게 나온다.
독립적인 정답성 판사 (independent correctness judge)는 100개 중 33개의 "근거는 있으나 틀린" 답변을 찾아냈다 — 확신에 차서 틀렸고, 완전히 근거를 갖추었으며, Faithfulness로는 보이지 않는 답변들이다.
교훈: Faithfulness는 필요조건일 뿐 충분조건이 아니다. 답변의 정답성 (answer-correctness) + context_recall을 기준으로 게이트를 설정하라. 그리고 Recall (재현율)이 문제일 때는 Reranker에 매달리는 것을 멈춰라.

설정 (수치를 신뢰할 수 있도록)

구성 요소 (Component)	선택 (Choice)
벤치마크 (Benchmark)	JQaRA (じゃくら) — JAQKET 퀴즈 세트를 기반으로 구축된 일본어 QA-for-retrieval
...

판단자 (Judge)가 다른 모델이라는 점은 중요하며, 그 이유는 나중에 다시 다루겠습니다.

제1막: 당연해 보이는 선택 — 리랭커 (Reranker) 추가

표준적인 RAG 업그레이드 경로는 다음과 같습니다: 첫 번째 단계는 밀집 검색 (Dense Retrieval)이고, 두 번째 단계는 교차 인코더 (Cross-encoder) 리랭커를 사용하는 것입니다. 그래서 저는 리랭커를 추가하고 검색을 다시 실행했습니다.

지표 (Metric)	밀집 검색 (Dense)	밀집 검색 + 리랭크 (Dense + rerank)	Δ
P@1	0.8308	0.8440	+0.0132
Recall@10	0.5738	0.5634	−0.0104

이 수치를 주의 깊게 읽어보십시오. 리랭커는 리랭커가 하는 일을 정확히 수행했습니다. 즉, 리스트의 상단을 날카롭게 다듬었지만 (P@1 상승 — 단일 최적 문서가 1위에 도달하는 빈도가 높아짐), 동시에 일부 관련 문서를 상위 10위 밖으로 약간 밀어냈습니다 (Recall@10 하락). 이것은 정밀도(Precision)를 위해 재현율(Recall)을 희생한 것이지, 공짜로 얻은 승리가 아닙니다.

그리고 여기서 여러분이 멈춰서 생각해야 할 점이 있습니다. 만약 여러분의 생성기 (Generator)가 최상위 결과 하나가 아니라 상위 5개 또는 상위 10개 이상의 결과를 읽는다면, P@1이 개선되더라도 이러한 재현율 하락은 다운스트림 (Downstream) 답변에 해를 끼칠 수 있습니다. 여러분이 축하하고 있는 지표는 생성기에 입력되는 지표가 아닙니다.

더 깊은 문제는 이것입니다: 리랭커는 후보 세트의 순서를 재정렬할 뿐입니다. 밀집 검색 (Dense Retrieval)이 전혀 찾아내지 못한 문서를 마법처럼 불러올 수는 없습니다. 이는 우리가 실제로 중요하게 여겨야 할 숫자로 우리를 인도합니다.

제2막: 내가 너무 과신했던 지표

저는 충실도 (Faithfulness)가 핵심 결과로 나올 것이라 기대하며 생성 평가 (Generation Eval)로 넘어갔습니다. 결과는 0.6662였습니다. 평범한 수준이었지만, 눈을 가늘게 뜨고 보며 "음, 괜찮네. 다음 버전을 출시하자"라고 생각하게 만드는 그런 종류의 숫자였습니다.

그 직관이 바로 함정입니다.

지표 (Metric)	값 (Value)	실제 의미
faithfulness (충실도)	0.6662	"괜찮아 보이네" — 하지만 위험할 정도로 불완전함
...

Faithfulness (충실도)는 정답(ground truth) 대비 정확성을 측정하는 것이 아니라, 검색된 컨텍스트 (retrieved context)와의 일관성을 측정합니다. 잘못되었지만 검색된 구절을 충실하게 보고하는 답변은 정의상 faithful (충실) 합니다. 따라서 근거는 있지만 틀린 (grounded-but-wrong) 답변은 충실도 점수를 낮추지 않으며, 오히려 충실도의 "좋은" 부분에 속하게 됩니다. 충실도를 위해 최적화한다면, 여러분은 부분적으로 '자신감 있고 근거가 확실하지만 틀린 답변'을 향해 최적화하고 있는 셈입니다.

이를 잡아내기 위해서는 별도의 질문이 필요합니다: 답변이 실제로 정확한가? 저는 JQaRA의 골드 답변 (gold answers)을 대상으로 독립적인 정확성 (correctness) 체크를 실행했습니다. 핵심은 다음과 같습니다:

# "답변이 컨텍스트에 의해 뒷받침되는가?"가 아니라 (faithfulness)
# "답변이 골드 답변과 비교했을 때 정확한가?" 입니다 (correctness)

...

결과: 100개의 답변 중 33개가 충실하면서 동시에 틀렸습니다. 충실도 게이트 (faithfulness gate)를 사용했다면 이 답변들 모두를 통과시켰을 것입니다.

이런 일이 발생한 이유: 누출된 원인은 recall (재현율)이었습니다

세 가지 숫자는 하나의 인과 관계로 연결됩니다:

context_recall (컨텍스트 재현율) = 0.41 → 대부분의 질의에 대해, 실제로 질문에 답할 수 있는 구절이 검색된 컨텍스트에 포함되지 않았습니다.
생성기 (generator)는 어쨌든 답변을 내놓으며, 검색된 것이 무엇이든 그것에 근거하여 자신감 있고 유창하게 답변합니다.
그 답변은 충실하며 (검색된 텍스트에 근거함) 동시에 틀립니다 (검색된 텍스트에 정답이 포함되지 않음). → grounded-but-wrong (근거는 있지만 틀린 답변).

따라서 context_recall은 선행 지표이고, grounded-but-wrong은 후행 확인 지표이며, faithfulness는 이 두 가지 문제를 모두 덮어버리는 중간의 오해를 불러일으키는 숫자입니다.

이제 제1막과 제2막은 동일한 루프로 귀결됩니다: 리랭커 (reranker)를 찾아 나섰지만, 리콜 (recall)이 병목 현상일 때 리랭킹 (reranking)은 잘못된 단계를 최적화하는 것입니다. 검색되지 않은 문서는 아무리 순서를 재조정해도 해결되지 않습니다. 올바른 레버는 상류 (upstream) 단계 — 청킹 (chunking), 임베딩 모델 (embedding model), 하이브리드 (hybrid, 어휘적(lexical) + 밀집(dense)) 검색, 쿼리 확장 (query expansion) — 에 있었지, 정답이 빠져 있는 목록을 다듬는 크로스 인코더 (cross-encoder)가 아니었습니다.

판사 독립성에 관한 노트 (편차가 중요한 이유)

모델이 자신의 출력물을 직접 채점하게 하면, 모델은 자신의 결과물을 선호하는 경향이 있습니다. LLM-as-judge (판사로서의 LLM)는 잘 알려진 자기 선호 편향 (self-preference bias)을 가지고 있으며, 자기 채점 설정은 분산 (variance)이 거의 없는 1.0에 가까운 점수를 생성하는 경우가 많습니다. 그 거의 제로에 가까운 편차가 바로 문제의 신호입니다.

제 판사 모델 (gemma4:31b)은 생성 모델 (qwen3:32b)과 다른 모델이며, 충실도 (faithfulness)의 편차는 0.05 — 즉, 0이 아닌 값으로 나타났습니다. 작은 수치이지만, 이는 판사가 단순히 승인 도장만 찍는 것이 아니라 좋은 답변과 나쁜 답변을 실제로 구별하고 있다는 증거입니다. 이 글에서 단 하나의 프로세스 습관만 가져간다면, 바로 이것을 가져가십시오: 답변을 작성한 모델이 그 답변을 채점하는 모델이 되게 하지 마십시오.

내가 실제로 프로덕션 RAG의 배포를 결정할 기준

대부분의 "RAG 평가"는 계산하기 가장 쉽다는 이유로 충실도 (faithfulness) 단계에서 멈춥니다. 바로 그 점 때문에 그곳에서 멈추는 것은 잘못된 선택입니다. 제가 실제 배포를 위해 통과시켜야 할 관문은 다음과 같습니다:

정답과의 답변 정확도 (Answer-correctness vs ground truth) — 근거는 있지만 틀린 답변을 실제로 잡아내는 지표입니다. 타협 불가능한 요소입니다.
문맥 재현율 (context_recall) — 선행 지표입니다. 이 수치가 낮다면, 생성 모델을 건드리거나 리랭커를 찾기 전에 검색 (retrieval) 단계를 먼저 수정하십시오.
충실도 (faithfulness) — 유지하되, 정확도 (correctness)의 대용품이 아닌, 정확도 위에 얹는 환각 (hallucination) 방지책으로만 사용하십시오.
독립적인 판사 (An independent judge) — 다른 모델을 사용하고, 점수 분산 (score variance)을 관찰하여 판사가 단순히 승인 도장만 찍고 있는 것이 아닌지 확인하십시오.

데모는 해피 패스 (happy path)가 작동함을 증명합니다. 하지만 비즈니스 현장에 투입할 시스템은 자신이 얼마나 자주 확신을 가지고 틀리는지를 — 그리고 이를 숫자로 증명 해야 합니다. 그 두 지점 사이의 간극이 바로 이러한 평가 규율 (eval discipline)입니다.

다음 단계

코드, 평가 하네스 (eval harness), 그리고 원본 실행 결과는 여기에 있습니다: github.com/elvisyao007/eval-driven-llm. 다음으로 저는 context_recall = 0.41 수치를 공략할 예정입니다. 동일한 방식으로 측정된 하이브리드 검색 (hybrid retrieval) 및 청킹 (chunking) 실험을 진행할 것입니다. 공개적으로 빌드하는 과정 (build in public)을 계속 지켜봐 주세요.

만약 RAG 평가를 수행하면서 오직 충실도 (faithfulness)만 확인한다면, 근거는 있지만 틀린 비율 (grounded-but-wrong rate)을 확인해 보십시오. 그 수치가 0이 아닐 것이라고 확신합니다.