환각은 느낌의 문제가 아니다: 에이전트 출력에서 근거 없는 주장을 실제로 탐지하는 방법

제가 대화하는 모든 팀은 자신들의 에이전트가 "가끔 환각 (hallucination)을 일으킨다"고 말하지만, 그 빈도가 얼마나 되는지 말할 수 있는 팀은 거의 없습니다. 발생하는 것을 아는 것과 그것을 셀 수 있는 것 사이의 그 간극이 바로 문제의 핵심입니다. 느낌으로만 감지되는 실패 모드(failure mode)는 수정할 수도, 차단할 수도, 심지어 추세를 파악할 수도 없습니다.

제가 옹호하고자 하는 의견은 다음과 같습니다: 환각 탐지 (hallucination detection)는 모델 품질의 문제가 아니라, 계측 (instrumentation)의 문제입니다. 여러분이 이를 측정할 수 없는 이유는 에이전트가 실행을 마치는 순간 증거를 버려버렸기 때문입니다. 근거 없는 주장을 탐지하려면 에이전트가 무엇을 주장하도록 허용되었는지를 알아야 하며, 이는 최종 답변 문자열이 아니라 도구 출력 (tool outputs)과 검색된 컨텍스트 (retrieved context)에 존재합니다. 이것들을 캡처하지 않는다면, 여러분이 작성하는 모든 환각 체크는 추측에 불과합니다.

에이전트 시스템에서 환각이 실제로 무엇인지, 왜 대중적인 탐지 방법들이 일반적인 사례를 놓치는지, 그리고 어떻게 CI(지속적 통합)에 넣을 수 있는 수치를 연결할 수 있는지 설명하겠습니다.

"환각"은 하나의 코트를 입은 세 가지 서로 다른 버그입니다

이 단어는 과부하되어 있으며, 이러한 과부하 때문에 탐지 노력이 헤매게 됩니다. 도구를 사용하는 에이전트(tool-using agent)에서는 사람들이 하나로 묶어서 생각하는 최소 세 가지의 뚜렷한 실패 유형이 있습니다:

1. 파라메트릭 누수 (Parametric leakage). 에이전트가 주어진 도구 결과 대신 학습 데이터 메모리로부터 답변합니다. 답변이 심지어 정확할 수도 있지만, 이는 여러분이 근거를 제공한 데이터를 사용했기 때문이 아니라 운 좋게 맞은 것입니다. 내일 동일한 코드 경로가 자신 있게 틀린 답변을 내놓더라도 여러분은 그 이유를 알 수 없습니다.
2. 조작된 근거 (Fabricated grounding). 에이전트가 검색된 컨텍스트 어디에도 나타나지 않는 출처, 레코드 ID, 필드 또는 숫자를 인용합니다. 이것은 근거가 있는 것처럼 보이기 때문에 위험합니다. 출처가 있는 주장의 형태를 갖추고 있습니다.
3. 지원되지 않는 합성 (Unsupported synthesis). 개별 사실은 모두 컨텍스트에 존재하지만, 에이전트가 이를 결합하여 출처가 결코 내지 않은 결론을 도출합니다. 단일 토큰(token)이 조작된 것은 아니지만, *추론 (inference)*이 조작된 것입니다.

이러한 현상들은 서로 다른 탐지기(detectors)를 필요로 합니다. 이들을 하나의 "환각 점수 (hallucination score)" 아래로 묶어버리면 아무도 신뢰하지 않는 수치를 얻게 됩니다. 왜냐하면 운 좋게 맞았지만 근거가 없는 답변과, 지어낸 고객 ID를 혼동하기 때문입니다. 환각을 측정하기 위한 첫 번째 단계는 환각을 단일 지표로 취급하기를 거부하는 것입니다.

"모델에게 환각을 했는지 물어보는 것"이 가장 취약한 선택지인 이유

가장 흔한 탐지 방식은 출력을 다시 LLM에 전달하고 "이것이 문맥에 충실한가요?"라고 묻는 것입니다. 이는 단 한 번의 API 호출로 가능하기 때문에 매력적입니다. 하지만 여러분이 정말로 신경 써야 하는 바로 그 실패 사례들을 그대로 통과시켜 버릴 가능성이 가장 높은 방법이기도 합니다.

자기 일관성 (self-consistency) 변형 방식 — 답변을 다섯 번 샘플링하여 불일치를 표시하는 방식 — 은 불안정한 (unstable) 환각은 잡아내지만, 안정적인 (stable) 환각은 놓칩니다. 만약 에이전트가 파라미터 메모리 (parametric memory)로부터 매번 동일한 잘못된 사실을 안정적으로 유출한다면, 다섯 번의 샘플이 모두 일치하게 되고 여러분의 탐지기는 높은 신뢰도를 보고할 것입니다. 모델이 재현 가능하게 틀린 것이며, 일관성이 여러분의 신호가 된 것입니다. 이것은 예외적인 사례가 아닙니다; 실제 운영 환경에서 발생하는 가장 흔한 환각입니다.

모델을 판사로 사용하는 충실도 점수 산정 (Model-as-judge faithfulness scoring)은 진정으로 유용합니다. 하지만 이는 실제로 판단이 필요한 모호한 사례인, 근거 없는 합성 (unsupported synthesis)에 대해서만 유효합니다. 나머지 두 가지 경우에는 LLM이 전혀 필요하지 않습니다. 집합 멤버십 (set membership)이 필요할 뿐입니다. 그리고 완전히 설명할 수 있는 결정론적 검사 (deterministic check)는, 설명할 수 없는 판사의 0.7점보다 언제나 더 낫습니다.

근거를 유지하면 근거 확인 (Grounding)이 가능해진다

여기에 핵심 기술이 있으며, 이는 거의 당혹스러울 정도로 기계적입니다: 출력에서 검증 가능한 주장들을 추출하고, 에이전트가 검색한 실제 텍스트와 각 주장을 대조하는 것입니다. 문제는 — 이것이 실제로 구현하기 어려운 근본적인 이유인데 — 검증을 하고자 하는 시점에는 "에이전트가 검색한 실제 텍스트"가 대개 이미 사라져 버렸다는 점입니다.

이것이 바로 제가 추적(tracing)과 평가(evaluation)를 두 개의 도구로 분리하기보다 하나의 워크플로우로 다루는 이유입니다. AgentLens는 실행 추적을 포착합니다: 원시 출력과 함께 모든 도구 호출, 모델에 실제로 입력된 해결된 컨텍스트, 최종 답변 — 에이전트가 접근할 수 있었던 전체 근거 진실 기록(ground-truth record)입니다. agent-eval은 나머지 절반입니다: 이 추적과 출력을 받아 근거 확인(grounding checks)을 실행하고, 빌드에 게이트를 걸 수 있는 합격/불합격 판결을 반환합니다. 이 두 가지의 조합이 핵심입니다. AgentLens가 소스를 보관해야만 agent-eval이 클레임을 소스와 비교하여 확인할 수 있습니다. 추적 기록 없이 작동하는 충실도 점수 계산기(faithfulness scorer)는 모델에게 스스로 '느낌으로 확인'하도록 요청하는 것과 같으며 — 바로 우리가 해결하려는 문제입니다.

캡처된 추적 위에서 계층형 탐지기(layered detector)가 어떻게 작동하는지 살펴보겠습니다:

import { getTrace } from "agentlens";
import { defineScorer } from "agent-eval";

...

여기에 있는 두 가지 설계 결정이 전체 시스템을 좌우하며, 저는 이 둘 모두를 옹호할 것입니다.

결정론적 탐지기(deterministic detector)가 먼저 실행되며 제가 가장 신뢰하는 부분입니다. 조작된 참조 ID나 지어낸 달러 금액은 판단의 문제가 아닙니다 — 주장되는 ID는 도구 출력에 나타나거나 그렇지 않습니다. 이것은 9.1점짜리 심사위원의 판정이 아니라 String.includes 문제입니다. 절대 오류가 없으며, 비용이 들지 않고, 실패할 경우 정확히 근거 없는 토큰을 알려줍니다. 고객에게 노출되는 가장 무서운 환각(hallucinations) 대부분은 이 범주에 속하며, LLM 루프 없이도 포착할 수 있습니다.

심사위원 지침(judge instruction)은 명시적으로 '정확하지만 근거가 없는 것'을 실패로 정의합니다. 이것이 매개변수 누출(parametric leakage)을 잡아내는 경계선입니다. 순진한 충실도 프롬프트는 정확한 답변에 보상하기 때문에, 운 좋게 발생한 메모리 누출도 통과시킵니다.

단 한 번의 실행 결과가 "이 출력은 근거가 있습니다"라고 말해주는 것은 거의 가치가 없습니다. 왜냐하면 환각 (hallucination)은 단일 답변의 속성이 아니라 분포 (distribution)의 속성이기 때문입니다. 중요한 숫자는 바로 _비율Ŀ_ 입니다. 즉, 프로덕션 실행 중 어느 정도의 비율이 근거 없는 주장을 내뱉는지, 그리고 시간이 지남에 따라 그 기울기가 어떻게 변하는지가 중요합니다.

이 지점에서 트레이스 (trace)를 보관하는 것이 두 번째로 빛을 발합니다. 모든 AgentLens 트레이스는 증거를 인라인 (inline)으로 포함하고 있기 때문에, 에이전트를 다시 호출하지 않고도 과거 프로덕션 트래픽의 일정 기간에 대해 이러한 탐지기들을 재실행하여 비율의 변화를 관찰할 수 있습니다.

import { queryTraces } from "agentlens";
import { runScorers } from "agent-eval";

...

이제 "에이전트가 가끔 환각을 일으킵니다"라는 말은 "지난주 실행의 3.1%가 근거 없는 주장을 내뱉었으며, 이는 1.8%에서 상승한 수치입니다. 여기 트레이스 ID들이 있습니다"라는 말로 바뀝니다. 이것은 대시보드에 올리고, 릴리스 (release) 여부를 결정하는 게이트로 삼고, 회의론자에게 제시할 수 있는 숫자입니다. 평가 (eval)는 당신에게 비율을 제공하며, 플래그가 지정된 각 실행 뒤에 있는 트레이스는 해당 주장이 나왔어야 했으나 나오지 않은 구체적인 도구 출력 (tool output)을 제공합니다. 당신은 환각이 문제인지 아닌지에 대해 논쟁하는 것을 멈추고, 환각이 발생한 단계로 클릭하여 들어가는 것을 시작하게 됩니다.

핵심 요약 (The takeaway)

환각을 언어 모델의 내재적이고 측정 불가능한 속성으로 취급하는 것을 멈추고, 당신이 도구화 (instrument)하는 것을 잊어버린 근거 확인 (grounding check) 절차로 취급하기 시작하십시오. 환각을 세 가지 실제 실패 모드로 나누십시오. 조절자 (judge) 없이도 결정론적인 집합 멤버십 확인 (set-membership checks)을 통해 조작된 참조와 파라메트릭 누출 (parametric leakage)을 잡아내십시오. 모델을 조절자로 사용하는 방식은 진정으로 모호한 합성 (synthesis) 사례를 위해서만 남겨두십시오. 그리고 트레이스를 캡처하십시오. 왜냐하면 이러한 모든 확인 작업은 에이전트가 실제로 본 증거 없이는 불가능하기 때문입니다.

에이전트는 특정하고 알 수 있는 비율로 환각을 일으킵니다. 당신이 자신의 환각 비율을 모르는 유일한 이유는 증거가 사라지게 두었기 때문입니다. AgentLens로 경로를 캡처하고, agent-eval로 근거를 점수화하십시오. 그러면 막연한 느낌 (vibe)이 숫자가 됩니다. 그리고 숫자는 당신이 실제로 해결할 수 있는 유일한 형태의 문제입니다.