RAG 검색은 완벽한데 답변이 틀렸다 — 환각률 측정으로 본 생성 단계 함정

내부 문서 검색 시스템을 RAG로 전환한 뒤, 사용자가 "이거 완전히 반대 의미잖아요"라며 들고 온 답변을 보고 얼어붙었습니다. 검색된 문서엔 정확한 내용이 있었는데, LLM이 생성 단계에서 정반대로 요약했더군요. 검색 품질이 높아도 답변은 틀릴 수 있다는 걸 그때 처음 체감했어요. 제 경험상, 문서 검색 목적이면 제가 정한 운영 기준은 faithfulness 0.85 이상 유지이고, 고위험 도메인이면 생성 단계 모니터링이 더 중요합니다.

RAG 환각은 어떻게 측정할 수 있나요?

제가 6주간 프로덕션 RAG 시스템을 추적하며 쓴 지표는 세 가지였어요. RAGAS 프레임워크의 faithfulness(검색된 문서 대비 답변의 사실 충실도), answerrelevancy(질문 대비 답변 관련성), 그리고 자체 제작한 contradictionrate(문서와 모순되는 문장 비율)입니다. RAGAS 공식 문서 기준으로, faithfulness는 0~1 범위로 1에 가까울수록 LLM이 문서를 그대로 반영했다는 뜻이에요.

제 시스템에서 6주간 무작위 샘플 약 850건을 측정한 결과, 검색 recall이 95%를 넘어도 faithfulness가 0.7 아래로 떨어지는 케이스가 전체의 18%나 됐습니다. 검색은 정확한데 생성이 망가진 거죠. 사용자가 실제로 불만을 제기한 답변 10건 중 7건이 faithfulness 0.65 이하였어요. 이 지표가 낮으면 검색된 문서를 LLM이 제멋대로 해석하거나, 아예 무시하고 사전학습 지식으로 답한 겁니다.

RAGAS 라이브러리로 답변·질문·검색 문서를 입력하면 faithfulness 점수가 나옵니다. 문제는 점수만으론 "왜 틀렸는지"를 모른다는 거였죠. 그래서 contradictionrate를 추가했어요. 답변 문장을 문서와 대조해 모순되는 문장 비율을 세는 방식입니다. 제 측정 기준으로 faithfulness 0.6대 답변들은 contradictionrate가 30%를 넘었고, 사용자 불만도 여기 집중됐습니다.

검색 품질이 높아도 생성 단계에서 환각이 나는 이유는?

제가 6주간 추적하며 발견한 함정은 세 가지였어요. 첫째, 문서 청크 경계입니다. RAG는 긴 문서를 쪼개서 검색하는데, 핵심 문맥이 두 청크에 걸쳐 있으면 LLM이 앞뒤를 잘못 연결해요. 제가 확인한 케이스 중 하나는 "A 기능은 베타입니다"가 첫 청크 끝에, "정식 출시 예정"이 다음 청크 시작에 있었는데, LLM이 "A 기능은 정식 출시되었습니다"라고 생성했습니다. 제 실험에서 청크 크기를 512토큰에서 768토큰으로 늘렸더니 이런 케이스가 40% 줄었어요.

둘째, 검색 순위와 LLM 신뢰도 불일치. 검색 엔진이 상위 3개 문서를 반환하면, LLM은 첫 번째 문서를 가장 신뢰할 거라 기대하잖아요. 그런데 실제론 LLM이 세 번째 문서의 표현을 더 "그럴듯"하다고 판단해서 우선 채택하는 경우가 있었습니다. 특히 첫 번째 문서가 기술 용어로 빽빽하면, 쉬운 말로 쓴 세 번째 문서를 LLM이 선호하더라고요. 제 환경에서 이 패턴이 전체 환각 케이스의 25%를 차지했어요.

셋째, 프롬프트 지시와 사전학습 지식의 충돌. "검색된 문서만 사용하라"고 명시해도, LLM의 사전학습 지식이 문서 내용과 다르면 사전학습 쪽으로 기울 때가 있습니다. 제가 겪은 최악의 케이스는 내부 API 문서에 "deprecated"라고 명시된 엔드포인트를, LLM이 "이 엔드포인트는 여전히 사용 가능합니다"라고 답한 겁니다. 사전학습 시점에 그 API가 활성 상태였기 때문이죠. 제 측정으로 faithfulness 0.5대 답변 중 절반이 이 패턴이었어요.

이 세 함정은 검색 정확도와 무관합니다. 검색이 완벽해도 생성 단계에서 LLM이 독자적으로 판단하면서 환각이 생기는 거죠.

어떤 상황에서 RAG를 신뢰할 수 있을까요?

제가 6주 모니터링 끝에 내린 운영 기준은 간단합니다. 제 시스템에선 faithfulness 0.85 이상을 7일 연속 유지하고, 주간 랜덤 샘플 100건 중 contradiction_rate 10% 이하면 신뢰 가능하다고 판단했어요. 이 조건을 만족한 건 전체 기간 중 3주뿐이었습니다.

신뢰할 수 있는 상황은 세 가지로 좁혀졌어요. 첫째, 문서 형식이 일정하고 청크 경계가 자연스러울 때. 제 환경에서 기술 문서나 FAQ는 faithfulness가 평균 0.88을 유지했고, 이메일 스레드나 회의록은 0.72까지 떨어졌습니다. 둘째, 검색 문서 수를 3개 이하로 제한했을 때. 5개 이상 반환하면 LLM이 문서 간 모순을 스스로 조정하려다 환각을 낳더라고요. 셋째, 프롬프트에 "문서에 없으면 '모르겠습니다'라고 답하라"를 명시하고, 이 지시를 어긴 답변을 자동 필터링했을 때였습니다.

반대로 신뢰할 수 없는 상황도 명확했어요. 문서가 서로 모순되거나, 질문이 모호해서 LLM이 추론을 더할 여지가 클 때, 그리고 검색 문서가 질문과 약하게 관련돼서 사전학습 지식으로 빈칸을 메울 때였습니다. 제 관찰로는 이런 케이스에서 faithfulness가 0.6 아래로 떨어졌고, contradiction_rate는 35%를 넘었어요.

저는 두 가지 안전장치를 추가했어요. 첫째, faithfulness 실시간 체크. 답변 생성 직후 RAGAS 점수를 계산해서, 0.8 미만이면 "이 답변은 확신도가 낮습니다"라고 경고하는 거죠. 둘째, 주간 샘플링 검증. 매주 무작위로 100건을 뽑아서 사람이 직접 문서와 답변을 대조합니다. 이 과정에서 RAGAS가 놓친 미묘한 왜곡을 잡아냈어요. 제 시스템에서 이 두 장치를 도입한 뒤로 사용자 불만이 60% 줄었습니다.

자주 묻는 질문

Q. RAGAS faithfulness 점수가 높으면 환각이 없다고 봐도 되나요? A. 아니요. faithfulness 0.9대여도 문서 여러 개를 섞어 답할 때 미묘한 모순이 생길 수 있어요. 제 경험상 0.85 이상이면 대부분 안전하지만, 고위험 도메인(의료·법률)에선 사람 검증을 병행해야 합니다.

Q. 검색 recall과 faithfulness 중 어느 쪽이 더 중요한가요? A. 목적에 따라 다릅니다. 탐색적 질문(예: "이 주제 관련 자료 찾아줘")이면 recall이 중요하고, 사실 확인(예: "이 API deprecated됐어?")이면 faithfulness가 중요해요. 제가 운영한 시스템은 후자라 faithfulness를 우선했습니다.

Q. 환각률을 낮추는 가장 효과적인 방법은? A. 제 경험상 청크 크기 조정(512→768토큰)과 검색 문서 수 제한(3개 이하)이 가장 효과적이었어요. 프롬프트 튜닝도 중요하지만, 구조적 개선이 먼저입니다.

마무리

RAG는 검색과 생성 두 단계로 나뉘는데, 검색이 완벽해도 생성에서 무너지는 걸 6주간 직접 보며 배웠습니다. 제가 정한 운영 기준인 faithfulness 0.85 이상을 유지하려면 청크 경계 조정, 검색 문서 수 제한, 실시간 점수 체크가 필수더라고요. 저는 주간 샘플링 검증에 매주 2시간씩 투입하는데, 이게 사용자 신뢰를 지키는 가장 확실한 방법이었습니다.