RUDA DIRECTOR · AI 깊이 이해하기 — 자율 시스템 설계까지 · CHAPTER 08
Model은 왜 모르는 것을 아는 것처럼 말하며, 시스템은 어디서 막아야 할까?
30초 답: AI Hallucination은 단순한 ‘기억 오류’가 아니다. Model이 충분한 근거 없이 그럴듯한 문장을 완성하거나, 주어진 근거를 잘못 읽거나, 근거가 허용한 범위보다 넓은 주장을 만들 때 발생한다. 따라서 해결책도 “더 오래 생각하게 하기” 하나가 아니라 근거 부재·근거 모순·추론 오류를 구분하고, 모르면 멈추며, claim 단위로 검증하는 시스템이어야 한다.
OpenAI는 Hallucination을 자신 있게 제시된 사실이 아닌 답변으로 설명하며, 정답률만 보상하는 Evaluation이 “모르겠다”보다 추측을 유리하게 만들 수 있다고 지적한다. Anthropic도 불확실성 표현, 직접 인용, claim별 citation, 외부 지식 제한을 완화책으로 제시하지만 완전 제거를 보장하지는 않는다. 이 글의 핵심 질문은 Model의 의도를 추측하는 것이 아니라, 어떤 출력이 어떤 근거 조건을 위반했는지 운영 가능한 규칙으로 판정하는 방법이다.
Hallucination의 경계: 무엇이고 무엇이 아닌가
이 글에서 Hallucination은 검증 가능한 사실 주장 중 거짓이거나, 제공된 증거로 뒷받침되지 않는 내용을 뜻한다. 이 정의는 창작의 상상, 선호의 차이, 불완전하지만 정직한 요약과 구분해야 한다.
| 현상 | 핵심 원인 | 판정 질문 |
|---|---|---|
| Unsupported claim | 근거가 없는데 사실처럼 확장 | 이 문장을 지지하는 source가 있는가? |
| Evidence contradiction | 근거와 다른 값·범위·날짜 | claim이 source의 필드와 일치하는가? |
| Reasoning error | 근거는 있지만 연결 논리가 틀림 | 전제에서 결론이 실제로 따라오는가? |
| Stale retrieval | 오래되거나 잘못된 문서를 사용 | 현재 Source of Truth가 맞는가? |
| Creative variation | 정답이 없는 창작적 선택 | 검증 가능한 사실을 약속했는가? |
Hallucination과 거짓말도 같지 않다. 거짓말은 대개 속이려는 의도를 전제하지만, 생성 Model의 사실 오류를 설명할 때 그런 의도를 가정할 근거는 없다. 제품 설계에서는 심리적 이름보다 출력과 증거의 관계를 기록하는 편이 디버깅에 유용하다.
발생 메커니즘: 문장 생성과 사실 검증은 같은 단계가 아니다
- Context 구성: Prompt, 검색 문서, Tool 결과, 대화 State가 입력된다.
- Candidate 생성: Model은 학습된 패턴과 현재 Context를 바탕으로 다음 Token을 연속적으로 선택한다.
- Claim 형성: 문장이 이름·날짜·수치·인과관계 같은 검증 가능한 주장을 포함한다.
- Evidence match: 시스템이 각 claim을 현재 Source of Truth, Tool 결과 또는 허용된 문서와 대조한다.
- Decision: 근거가 충분하면 수용하고, 없으면 retract·abstain·재검색·Human Review 중 하나로 보낸다.
문제는 2단계가 자연스러운 문장을 만드는 데 최적화되어 있어도 4단계가 자동으로 보장되지는 않는다는 데 있다. Sampling을 보수적으로 바꾸면 출력 변동성은 줄 수 있지만, 애초에 Context에 없는 사실이 생기는 문제까지 해결하지는 못한다. 마찬가지로 Reasoning Effort를 늘려도 누락된 evidence가 새로 생기지는 않는다.
합성 검증: 네 문장을 구조화된 근거와 대조해보면
아래는 실제 서비스나 실제 Model 출력이 아니라, Python 표준 라이브러리만 사용한 결정론적 구조 검증이다. 현재 정책 문서에는 적용 대상이 new_accounts, 시행일이 2026-10-15로 기록되어 있고 인상률 필드는 없다. 네 후보 claim을 동일한 validator에 넣었다.
| 후보 claim | 판정 | 이유 |
|---|---|---|
| A. 모든 계정 대상 | EVIDENCE_CONTRADICTION | 현재 근거는 신규 계정만 명시 |
| B. 10월 1일 시행 | STALE_SOURCE | 과거 문서 버전을 인용 |
| C. 12% 인상 | UNSUPPORTED_CLAIM | 검증 가능한 source_id가 없음 |
| D. 신규 계정, 10월 15일 | ACCEPT | 두 필드 모두 현재 근거와 일치 |
실행 결과: ACCEPT 1건, EVIDENCE_CONTRADICTION 1건, STALE_SOURCE 1건, UNSUPPORTED_CLAIM 1건이었다. 이 실험이 증명하는 것은 Model의 정확도가 아니다. 같은 ‘틀린 답’도 실패 원인을 분리해야 다음 조치가 달라진다는 구조적 사실이다. A는 claim 수정, B는 최신 문서 재조회, C는 근거 요청 또는 abstention, D는 통과가 적절하다.
검증 설계: 답변 전체가 아니라 claim 단위로 판정한다
긴 답변 하나에는 수십 개의 사실 claim이 섞일 수 있다. OpenAI의 SimpleQA 설명도 임의의 긴 응답에서는 factuality 측정이 어려워진다고 말한다. 따라서 “이 답변은 맞는가?”라는 단일 점수보다 다음 순서가 재현성이 높다.
- 이름·날짜·수치·상태·인과처럼 검증 가능한 claim을 분리한다.
- 각 claim에 source ID와 source revision을 연결한다.
- 직접 지지, 모순, 근거 없음, 판단 불가를 구분한다.
- 고위험 claim은 code check나 독립된 Human Review를 추가한다.
- 수정된 최종 답변과 거절·보류 이유를 Trace에 남긴다.
Citation이 있다는 사실만으로 충분하지 않다. 링크가 실제 claim을 지지하는지, 최신 문서인지, 인용 범위를 과장하지 않았는지까지 확인해야 한다. 특히 금액·권한·일정·안전처럼 결과 비용이 큰 영역에서는 “그럴듯함”을 통과 기준으로 사용할 수 없다.
자주 실패하는 다섯 가지 설계
- 무조건 답하게 한다. Accuracy만 평가하고 abstention을 실패로 취급하면, 모르는 경우에도 추측하는 편이 점수상 유리해진다.
- Reasoning Effort만 늘린다. 추론 단계가 늘어도 없는 근거가 생기지 않는다. Evidence acquisition과 reasoning을 분리해야 한다.
- RAG를 붙이면 끝이라고 본다. Retrieval이 오래된 문서나 잘못된 범위를 가져오면 근거가 오히려 오류에 권위를 부여한다.
- Citation 개수만 센다. 출처 존재 여부와 claim support 여부는 다르다. claim-level entailment를 확인해야 한다.
- 같은 출력으로 같은 출력을 승인한다. 독립된 근거나 결정론적 규칙 없이 자기검토만 반복하면 최초 가정을 그대로 강화할 수 있다.
Trade-off: 신뢰성을 얻는 대신 무엇을 지불하는가
| 선택 | 얻는 것 | 비용·위험 |
|---|---|---|
| Abstention 허용 | 근거 없는 추측 감소 | 응답 커버리지 감소 |
| 검색·Grounding | 최신 외부 근거 접근 | Latency, Context Token, Prompt Injection 표면 증가 |
| Claim-level 검증 | 오류 위치와 원인 추적 | 파싱·Schema·Observability 복잡도 증가 |
| 독립 Human Review | 고위험 판단의 책임성 | 시간·운영 Cost 증가 |
| Code 기반 검사 | 정확 필드의 빠른 반복 검증 | 열린 의미·미묘한 문맥에는 취약 |
가장 작은 유능한 구조는 위험도에 따라 달라진다. 저위험 요약은 citation과 abstention만으로 충분할 수 있다. 반면 결제·권한 변경·대외 공지라면 최신 source revision, exact-field validation, Approval까지 필요하다. 모든 답변에 가장 무거운 검증을 붙이면 Latency와 Cost가 커지고 실패 표면도 넓어진다.
언제 이 검증 파이프라인을 쓰지 말아야 하나
시, 캐릭터 설정, 아이디어 발산처럼 사실 정답을 약속하지 않는 창작에는 claim-level factual verification이 오히려 다양성을 해친다. 계산기·데이터베이스 조회처럼 답이 완전히 결정론적인 작업도 먼저 해당 Tool을 직접 호출하면 된다. 중요한 원칙은 모든 문장을 검증하는 것이 아니라, 사실성 약속과 실패 비용이 있는 claim만 정확히 검증하는 것이다.
실무 적용 원칙: 배포 전 일곱 질문
- 검증해야 할 사실 claim과 창작 문장을 구분했는가?
- 각 claim의 현재 Source of Truth와 revision을 식별할 수 있는가?
- 근거 없음, 근거 모순, 추론 오류, 오래된 source를 별도 상태로 남기는가?
- “모르겠다”, 재검색, clarification을 정상 결과로 허용하는가?
- Citation이 실제 claim을 지지하는지 확인하는가?
- 금액·권한·일정·안전 claim에 독립 검증 또는 Human Review가 있는가?
- Latency·Token·권한·보안 비용이 실패 위험에 비례하는가?
학습 결론: Hallucination을 하나의 Model 결함으로 묶으면 처방도 막연해진다. Evidence가 없으면 답하지 않고, Evidence가 오래됐으면 다시 가져오며, Evidence와 claim이 다르면 수정하고, 논리가 틀렸으면 reasoning을 검증해야 한다. 자율 시스템의 신뢰성은 “항상 답하는 능력”보다 어떤 조건에서 멈추고 무엇을 확인해야 하는지 아는 구조에서 시작한다.
공식 참고 자료
- OpenAI — Why language models hallucinate (확인: 2026-10-02)
- OpenAI — Introducing SimpleQA (확인: 2026-10-02)
- Anthropic — Reduce hallucinations (확인: 2026-10-02)
- Anthropic — Define success criteria and build evaluations (확인: 2026-10-02)
시리즈 탐색
Previous: Chapter 07 — Reasoning Effort란 무엇인가: 더 오래 계산하면 항상 정확해질까
Next: Chapter 09 — RAG와 Fine-tuning: 지식 문제를 어디서 고쳐야 하는가
Related: Chapter 06 — 같은 질문인데 AI 답변이 달라지는 이유: Temperature와 Sampling
Series start: Chapter 01 — LLM의 학습과 추론: 프롬프트를 고치면 모델도 배우는가