환각 탐지는 모델의 문제가 아니라 아키텍처의 문제입니다

환각 탐지는 모델의 문제가 아니라 아키텍처의 문제입니다

매주 누군가는 더 나은 프롬프트(Prompt)나 더 화려한 검색 전략(Retrieval strategy)을 통해 환각(Hallucination) 발생률을 3% 줄이는 새로운 논문을 발표합니다. 그동안 실제 운영(Production) 환경에서는, 당신의 에이전트(Agent)가 환불이 처리되지 않았음에도 고객에게 환불이 완료되었다고 자신 있게 말해버립니다.

문제는 모델이 환각을 일으킨다는 것이 아닙니다. 문제는 당신의 시스템에 환각이 사용자에게 도달하기 전에 이를 **포착(Catch)**할 수 있는 아키텍처적 메커니즘이 없다는 것입니다.

환각을 모델 튜닝(Model tuning)의 문제로 취급하는 것을 멈추십시오. 이를 시스템 관측성(Systems observability)의 문제로 취급하기 시작해야 합니다.

운영 환경에서의 환각 3단계

운영 환경에서 에이전트를 실행해 온 제 경험에 따르면, 환각은 세 가지 범주로 나뉩니다:

1. 사실적 조작 (Factual fabrication) — 모델이 컨텍스트(Context)에 존재하지 않는 데이터를 지어내는 경우
2. 행동 환각 (Action hallucination) — 모델이 수행하지 않은 행동을 수행했다고 주장하는 경우
3. 상태 환각 (State hallucination) — 모델이 시스템의 현재 상태를 잘못 표현하는 경우

대부분의 팀은 1번만 생각합니다. 하지만 실제 운영상의 사고는 2번과 3번에서 발생합니다. 도구 호출(Tool call)이 조용히 실패했을 때 에이전트가 "데이터베이스를 업데이트했습니다"라고 말하거나, 확인조차 하지 않았는데 에이전트가 "배포 상태가 정상입니다"라고 말하는 식입니다.

이것들은 프롬프트 엔지니어링(Prompt engineering)의 문제가 아닙니다. 이것은 **검증 아키텍처 (Verification architecture)**의 문제입니다.

검증 레이어 패턴 (The Verification Layer Pattern)

해결책은 간단합니다. 에이전트의 주장과 시스템의 출력 사이에 검증 레이어(Verification layer)를 삽입하는 것입니다. 에이전트가 세상에 대해 내리는 모든 주장은 독립적으로 검증 가능해야 합니다.

실제 구현 모습은 다음과 같습니다:

import { AgentOutput, VerificationResult } from "./types";

interface ClaimExtractor {
...

핵심적인 통찰은 다음과 같습니다: 만약 당신의 에이전트가 검증 가능한 주장을 생성할 수 없다면, 그 자체로 하나의 신호(Signal)가 됩니다. "배포가 괜찮을 수도 있을 것 같습니다"라고 말하는 에이전트가, 상태 확인 엔드포인트(Health check endpoint)를 호출하지도 않고 "배포 상태가 정상입니다"라고 말하는 에이전트보다 실제로 더 신뢰할 수 있습니다.

실제로 효과가 있는 검증 전략 (Verification Strategies That Actually Work)

실행 주장(Action Claims)에 대한 도구 재실행 (Tool Replay)

에이전트가 특정 동작을 수행했다고 주장할 때, 해당 도구 호출(tool call)을 재실행하여 상태 변화(state change)를 검증하십시오:

async function verifyActionClaim(
  claim: Claim,
  ctx: ExecutionContext
...

사실 주장(Factual Claims)에 대한 근거 일치 (Grounding Match)

사실에 기반한 주장의 경우, 해당 정보가 에이전트에게 주어진 컨텍스트(context) 내에 존재하는지 확인하십시오:

async function verifyFactualClaim(
  claim: Claim,
  ctx: ExecutionContext
...

관측 가능성(Observability)의 관점

관측 가능성(observability) 없는 탐지는 무용지물입니다. 다음과 같은 항목들을 추적해야 합니다:

• 주장 유형별 환각률 (Hallucination rate by claim type) — 실행(action) 관련 환각이 증가하고 있는가?
• 검증 커버리지 (Verification coverage) — 에이전트 출력물 중 검증 가능한 주장(verifiable claims)이 포함된 비율은 얼마인가?
• 탐지 시간 (Time-to-detection) — 환각이 발생한 시점과 포착된 시점 사이의 간격은 어느 정도인가?
• 탈출률 (Escape rate) — 탐지되기 전에 사용자에게 도달한 환각의 비율

이 지점이 대부분의 팀이 실패하는 구간입니다. 그들은 탐지기(detector)를 구축하지만, 이를 계측(instrument)하지는 않습니다. 3주가 지나면, 환각률이 개선되고 있는지 악화되고 있는지조차 알 수 없게 됩니다.

불편한 진실

아무도 듣고 싶어 하지 않는 사실이 있습니다: 모델 계층(model layer)만으로는 환각 문제를 해결할 수 없습니다. 환각률이 0.1%인 모델이라 할지라도, 프로덕션 규모(production scale)에서는 하루에도 수천 번의 환각을 일으킬 것입니다.

질문은 "어떻게 하면 모델의 환각을 줄일 수 있을까?"가 아닙니다. 질문은 "환각이 문제가 되기 전에 포착될 수 있도록 시스템을 어떻게 설계(architect)할 것인가?"가 되어야 합니다.

이는 다음을 의미합니다:

• 모든 에이전트 출력물은 주장 추출(claim extraction) 과정을 거쳐야 함
• 모든 검증 가능한 주장은 검증을 거쳐야 함
• 검증 불가능한 모든 출력물은 인간의 검토(human review) 또는 보수적인 폴백(conservative fallback)을 위해 플래그(flag) 처리되어야 함
• 모든 탐지 이벤트는 평가 스위트(eval suite)로 피드백되어야 함

탐지에서 예방으로

마지막 단계입니다: 환각 탐지 데이터는 평가 인프라(evaluation infrastructure)로 직접 전달되어야 합니다. 포착된 모든 환각은 테스트 케이스(test case)가 됩니다. 발견된 모든 환각 패턴은 회귀 테스트 스위트(regression suite)가 됩니다.

이 지점에서 agent-eval과 같은 도구들이 매우 중요해집니다. 이러한 도구들은 실제 운영 환경(production)에서 발생한 환각(hallucination) 이벤트를 모든 배포 시마다 실행되는 결정론적 평가 케이스(deterministic eval cases)로 전환할 수 있게 해줍니다. 그리고 이러한 패턴을 시간이 지남에 따라 추적할 수 있는 관측성 계층(observability layer)을 찾고 있다면, AgentLens는 사용자가 알아차리기 전에 환각률(hallucination rate)이 드리프트(drift)되는 시점을 파악할 수 있도록 필요한 대시보드와 알림(alerting)을 제공합니다.

환각은 수정해야 할 버그가 아닙니다. 그것은 아키텍처적으로 대비해야 할 실패 모드(failure mode)입니다.

검증 계층(verification layer)을 구축하세요. 이를 계측(instrument)하세요. 당신의 평가(evals)가 운영 환경으로부터 학습하게 하세요. 그것이 바로 거짓말을 하지 않는 에이전트(agents)를 출시하는 방법입니다.