LLM 환각 측정 (분류체계, 정량지표, 평가파이프라인, 모니터링)

프롬프트를 잘 다듬으면 LLM 환각이 줄어든다고 생각하시는 분들 많으시죠? 저도 처음엔 그렇게 믿었습니다. 그런데 실제로 금융 도메인 RAG 시스템을 운영해보니, 프롬프트 수정은 그냥 증상 완화에 불과했습니다. 환각(Hallucination)이 언제, 얼마나, 왜 발생하는지를 숫자로 파악하지 못하면 결국 같은 실수가 반복됩니다. 이 글은 환각을 측정 가능한 엔지니어링 문제로 바꾸는 방법을 다룹니다.

환각 분류체계 — 유형을 모르면 측정도 못 합니다

일반적으로 LLM 환각을 그냥 "틀린 답변"으로 뭉뚱그려 보는 시각도 있는데, 실제로 써보니 오류의 성격이 완전히 달라서 같은 잣대로 재면 곤란합니다. 유형을 구분해야 비로소 어떤 지표를 적용할지 결정할 수 있습니다.

크게 두 갈래로 나뉩니다. 첫 번째는 사실적 환각(Factuality Hallucination)입니다. 여기서 사실적 환각이란 세상에 존재하는 일반적 지식과 모순되거나, 아예 없는 논문·인물·수치를 날조하는 경우를 말합니다. 제가 직접 겪은 사례로는 실존하지 않는 판례 번호를 그럴듯하게 인용하는 일이 있었는데, 이게 법률 도메인에서 얼마나 치명적인지는 말할 필요도 없겠죠.

두 번째는 충실성 환각(Faithfulness Hallucination)입니다. 충실성 환각이란 모델에게 직접 제공한 참조 문서의 내용과 정면으로 배치되는 답변을 생성하거나, 프롬프트가 명시한 제약 범위를 벗어나 자의적으로 추론하는 현상입니다. 쉽게 말해 "네가 준 자료에도 없는 말을 지어낸다"는 뜻입니다. RAG 시스템에서 특히 자주 보이는 유형이라 저도 가장 먼저 이 부분부터 측정 체계를 잡았습니다.

이 두 유형은 검증 방식 자체가 다릅니다. 사실적 환각은 외부 지식 베이스나 위키데이터 같은 구조화된 데이터와 대조해야 하고, 충실성 환각은 제공된 컨텍스트 청크와 생성 문장 사이의 논리적 관계를 분석해야 합니다. 이걸 혼용하면 점수 자체가 의미를 잃습니다.

요약: 환각은 사실적 환각과 충실성 환각으로 구분되며, 유형에 따라 검증 방식이 달라지므로 분류 체계 수립이 측정의 출발점입니다.

정량지표 — BLEU·ROUGE가 왜 답이 아닌지 직접 확인했습니다

많은 분들이 BLEU나 ROUGE 점수로 LLM 품질을 재려 합니다. 저도 초기에 그렇게 시작했는데, 솔직히 이건 예상 밖이었습니다. 같은 의미의 문장도 단어가 조금만 바뀌면 점수가 뚝 떨어지고, 반대로 사실과 정반대되는 내용인데 어휘가 겹치면 점수가 올라가는 경우를 직접 목격했습니다. 의미론적 사실성을 평가하는 데 어휘 일치율 지표는 구조적 한계가 있습니다.

현재 실무에서 제가 핵심으로 쓰는 지표는 세 가지입니다.

• Ragas Faithfulness Score: RAG 파이프라인에서 생성된 답변을 원자 단위의 명제(Atomic Proposition)로 쪼갠 뒤, 각 명제가 참조 컨텍스트로부터 논리적으로 지지받는 비율을 0~1 사이 수치로 나타냅니다. 여기서 원자 단위 명제란 하나의 팩트만 담은 단순 평서문을 말합니다. 복잡한 복문 하나를 그대로 평가하면 사실인 부분과 거짓인 부분이 뒤섞여 점수가 흐려지기 때문에 반드시 이 분해 단계가 선행되어야 합니다.
• NLI(자연어 추론) 기반 모순율: 사전 학습된 NLI 모델, 예를 들어 DeBERTa-v3 같은 모델을 활용해 참조 문서(Premise)와 생성 문장(Hypothesis) 사이의 관계를 함의·중립·모순 세 클래스로 분류합니다. NLI란 두 문장 사이의 논리적 함의 관계를 자동 판단하는 자연어 처리 기술입니다. 모순(Contradiction) 확률의 가중 평균이 곧 환각 심각도 점수가 됩니다.
• 자체 일관성(Self-Consistency): 동일 질문을 온도(Temperature) 파라미터 0.7 이상으로 여러 번 반복 생성한 뒤, 답변들이 의미적으로 수렴하는지 분산되는지를 봅니다. 답변이 서로 엇갈릴수록 시맨틱 엔트로피(Semantic Entropy)가 높아지고 환각 위험 신호로 해석합니다.

이 세 지표를 조합하면 단일 메트릭으로는 포착하지 못하는 다층적 오류를 잡아낼 수 있습니다. 제 경험상 Faithfulness 점수가 높아도 NLI 모순율이 튀는 케이스가 분명히 존재했고, 그 두 지표가 동시에 이상치를 보일 때 실제 치명적인 오류가 몰려 있었습니다(출처: Ragas 공식 문서).

요약: BLEU·ROUGE는 의미 기반 사실성 평가에 부적합하며, Ragas Faithfulness·NLI 모순율·Self-Consistency를 조합한 다층 지표가 실전에서 더 정밀합니다.

평가 파이프라인 — 자동화 없이 거버넌스는 허상입니다

지표를 정의해놓고 매번 수동으로 평가하는 것은 현실적으로 불가능합니다. 저도 초기에 스프레드시트로 샘플링 검수를 했다가 금방 포기했습니다. 트래픽이 조금만 늘어도 감당이 안 됩니다. 결국 평가 자체를 파이프라인으로 자동화하는 것이 핵심입니다.

자동화 파이프라인은 크게 세 계층으로 구성하는 것이 효과적입니다. 1계층에서는 RAG 컨텍스트와 원자적 명제 사이의 NLI 추론 점수 및 Ragas Faithfulness를 계산합니다. 2계층에서는 NER(개체명 인식) 모델로 고유명사·날짜·수치 같은 엔티티를 추출하고 원본 데이터셋과 값 일치 여부를 대조합니다. 여기서 NER이란 텍스트에서 사람 이름, 기관명, 날짜 등 의미 있는 고유 개체를 자동으로 인식하는 기술입니다. 3계층에서는 GPT-4o나 Claude 같은 별도 심사 모델에 Chain-of-Thought 프롬프트를 주입해 논리적 비약이나 거짓 주장을 최종 감사합니다.

여기서 제가 실제로 운영하며 가장 중요하게 본 부분은 임계값 설정입니다. 종합 신뢰도 점수가 0.85 미만일 경우, 답변을 사용자에게 노출하지 않고 "제공된 문서에서 명확한 근거를 찾을 수 없습니다"라는 안전 응답으로 폴백(Fallback) 처리하도록 했습니다. 폴백이란 시스템이 기준을 충족하지 못할 때 안전한 기본 응답으로 전환하는 처리 방식을 말합니다. 처음엔 이 임계값 때문에 답변 거부율이 높아져 팀 내에서 논란이 됐는데, 실제로 거부된 케이스를 사후 검토해보니 80% 이상에서 실제 오류가 포함돼 있었습니다. 임계값은 타협하지 않길 잘했다 싶습니다.

프레임워크 선택은 목적에 따라 갈립니다. RAG 성능 전반을 평가하려면 Ragas가 직관적이고, CI/CD 파이프라인에 유닛 테스트처럼 끼워 넣으려면 DeepEval이 Pytest 기반이라 편합니다. 실시간 대시보드가 필요하다면 TruLens가 OpenTelemetry 연동을 지원해서 유용합니다(출처: DeepEval 공식 문서).

요약: 환각 평가는 3계층 자동화 파이프라인으로 구성해야 하며, 신뢰도 임계값 기반 폴백 처리가 실운영에서 품질을 지키는 핵심 장치입니다.

모니터링 — 한 번 세팅하고 잊으면 바로 무너집니다

파이프라인을 구축하고 나서 방심한 적이 있었습니다. 임베딩 모델을 교체하면서 RAG 파라미터도 함께 바꿨는데, 배포 전 환각 평가 스코어를 따로 돌리지 않았습니다. 결과는 특정 도메인 질문에서 Faithfulness 점수가 0.91에서 0.73으로 뚝 떨어졌고, 이걸 이틀이 지나서야 파악했습니다. 그 이후로 프롬프트나 모델 파라미터를 바꿀 때마다 골든 데이터셋(Golden Dataset) 500개 이상에 대해 환각 평가를 자동으로 돌리고 점수가 하락하면 배포를 차단하는 회귀 테스트를 CI/CD에 묶어놨습니다. 여기서 골든 데이터셋이란 정답이 미리 검증된 기준 질문-답변 쌍의 집합으로, 모델 성능 변화를 일관되게 추적하는 데 사용됩니다.

장기 운영에서 또 하나 놓치기 쉬운 게 데이터 드리프트입니다. 데이터 드리프트란 시간이 지나며 실제 입력 데이터의 분포가 모델이 학습하거나 검증된 시점과 달라지는 현상입니다. 특정 도메인의 용어나 트렌드가 바뀌면 참조 지식 베이스가 낡아지고, 그게 고스란히 환각 발생률 상승으로 나타납니다. 저는 일자별·도메인별 환각 발생률 추이를 시계열 대시보드로 모니터링하고, 특정 카테고리에서 점수가 급변하면 해당 도메인의 지식 베이스를 즉시 갱신하는 프로세스를 정착시켰습니다.

모니터링은 기술이 아니라 문화의 문제라고 생각합니다. 숫자를 볼 수 있는 대시보드가 있어도 아무도 보지 않으면 없는 것과 같습니다. 팀 단위로 주간 환각 지표 리뷰를 의제로 올리는 것, 그게 결국 거버넌스를 살아있게 만드는 가장 현실적인 방법이었습니다.

요약: 모델·파라미터 변경 시마다 골든 데이터셋 기반 회귀 테스트를 CI/CD에 통합하고, 데이터 드리프트를 지속 추적하는 것이 장기 운영 품질을 지키는 핵심입니다.

자주 묻는 질문

Q. LLM 환각을 완전히 없앨 수 있나요?

A. 완전히 0으로 만드는 것은 현재 기술로는 불가능합니다. LLM은 확률론적으로 다음 토큰을 예측하는 구조라, 근본적으로 불확실성을 내포합니다. 다만 정량적 평가 프레임워크를 통해 발생 빈도와 심각도를 측정하고, 임계값 기반 폴백 처리로 치명적인 오류가 사용자에게 노출되는 것을 막는 방식으로 실질적인 위험을 통제할 수 있습니다.

Q. Ragas랑 DeepEval 중에 뭘 먼저 써야 하나요?

A. RAG 파이프라인을 운영 중이라면 Ragas를 먼저 도입하는 것이 자연스럽습니다. Faithfulness·Answer Relevance·Context Recall 같은 RAG 특화 지표를 바로 쓸 수 있어서 초기 셋업 비용이 낮습니다. 반면 이미 CI/CD 파이프라인이 구축된 조직이라면 Pytest 기반으로 유닛 테스트처럼 끼워 쓸 수 있는 DeepEval이 실용적입니다. 제 경험상 두 도구는 대체재가 아니라 보완재에 가깝습니다.

Q. NLI 모델을 직접 운영하려면 인프라가 얼마나 필요한가요?

A. DeBERTa-v3 계열 NLI 모델은 파라미터 규모가 상대적으로 작아서 GPU 한 장으로도 실시간 추론이 가능합니다. 온프레미스 운영이 부담스럽다면 Hugging Face Inference Endpoints처럼 서버리스 추론 API를 활용하는 방식도 현실적인 선택입니다. 다만 트래픽 규모에 따라 비용이 달라지므로, 초기에는 샘플링 평가 방식으로 시작하고 이후 전수 평가로 확장하는 단계적 접근을 권장합니다.

Q. 골든 데이터셋은 어떻게 만들어야 하나요?

A. 도메인 전문가가 직접 작성한 정답 쌍이 가장 신뢰도가 높습니다. 초기에는 최소 500개를 목표로 하되, 실제 서비스에서 자주 등장하는 질문 유형과 실패 사례를 우선 포함시키는 것이 중요합니다. 일반적으로 균일하게 샘플링하는 것보다 오류가 집중된 도메인과 엣지 케이스를 의도적으로 과표집하는 것이 회귀 테스트의 검출력을 높이는 데 효과적입니다.

결론

LLM 환각은 피할 수 없는 문제가 아니라, 측정하지 않아서 통제하지 못하는 문제입니다. 분류 체계를 세우고, 의미 기반 지표로 수치화하고, 파이프라인으로 자동화하고, 지속적으로 모니터링하는 이 네 단계가 맞물려 돌아갈 때 비로소 환각은 "재수 없으면 터지는 사고"에서 "관리 가능한 엔지니어링 변수"로 바뀝니다.

다음 단계로는 Ragas나 DeepEval을 작은 규모의 파일럿 프로젝트에 붙여보시기를 권합니다. 지표 하나라도 실제 데이터에서 움직이는 걸 직접 보고 나면, 어디서 어떻게 확장할지가 훨씬 선명하게 보입니다. 저도 그렇게 시작했습니다.

참고: 출처: Ragas 공식 문서 — Faithfulness 지표 / 출처: DeepEval 공식 문서