1. 幻觉是什么

严格说，幻觉（hallucination）指模型生成了流畅但不真实、无依据、与给定上下文不一致、或无法被外部证据支持的内容。它既可能是事实性错误，也可能是引用、出处、数字、代码 API、推理步骤、工具执行结果上的编造。

一、为什么模型会幻觉：根因一定要答到底层

1. 目标函数不是事实核验器

LLM 在预训练阶段学的是语言分布，而不是“真实世界校验规则”。它的本能是生成“看起来合理、接得下去”的 token 序列。于是当上下文缺证据、问题又逼着它必须给答案时，它非常容易走向高流畅度、低真实性的输出。这是最根的原因。

2. 训练数据本身就有噪声、过时与冲突

语料中包含错误信息、过时知识、不同立场、不同版本 API、不同时间点的事实。模型把这些都压缩进参数后，不会自动形成完全一致的真值库。于是你问一个细粒度事实、冷门版本问题、时间敏感问题时，它很可能混用旧知识与近似模式。

3. 上下文证据不足或上下文组织不当

很多所谓“模型幻觉”，其实根本原因是我们没给它足够证据，或把证据塞得太乱。比如：

• 检索召回错了文档；
• 关键信息埋在长上下文中间；
• 多个版本的业务规则同时出现；
• 系统提示要求必须回答，禁止说“不确定”。
  这种情况下，模型“编”出来的内容，某种意义上是系统设计在逼它编。

4. 解码随机性与长链误差积累

采样参数越发散，模型选择低概率 token 的机会越高；多步生成越长，局部小错越可能滚成整体大错。特别是长文本、复杂 SQL、长代码、工具串联计划，一步偏了，后面都跟着漂移。

5. 工具、检索和外部系统引入的新幻觉

到了 Agent 时代，幻觉不再只是“模型脑补”。还包括：

• 模型错误理解了工具返回；
• 工具本身返回脏数据；
• 模型声称工具执行成功，实际上并没有；
• 模型把未发生的外部动作说成已完成。
  Anthropic 在发布 Sonnet 4.6 时特别提到“fewer false claims of success”，这正说明在 Agent/代码场景里，“虚报完成”已经成为一种非常实际的幻觉类型。

二、怎么降低幻觉：面试要讲方法分层

第一层：任务定义层

最常见也最被忽略。
如果任务允许“不知道”，就明确允许；
如果需要证据，就要求“先找证据再回答”；
如果必须引用来源，就把 citation/evidence slot 放进输出 schema；
如果问题时间敏感，就要求调用搜索或检索。

你要让模型知道：没有证据时承认不确定，是被允许甚至被鼓励的。

第二层：上下文与检索层

降低幻觉最有效的方法之一，往往不是“改模型”，而是给更好的证据。包括：

• 提升检索召回与重排质量；
• 减少上下文噪声；
• 把关键证据放在更显著位置；
• 用结构化字段而不是大段原文堆叠；
• 对版本号、日期、实体名做显式突出。

Anthropic 的 reduce hallucinations 文档也强调让模型先提取证据、再作答的模式，这类“evidence-first”策略在长文档问答中很有用。

第三层：输出约束层

结构化输出并不会自动提高真实性，但可以强迫模型把“答案”和“依据”拆开。一个简单但很有效的 schema 设计是：

• answer；
• confidence / uncertainty note；
• evidence_ids；
• cannot_answer_reason。

当模型必须显式写出依据来源时，至少更容易被程序和评测发现它在编。

第四层：工具验证层

对时间敏感、事实敏感、高风险任务，不能只靠参数知识。应该：

• 调搜索；
• 查数据库；
• 走代码执行；
• 做二次校验；
• 必要时让 verifier model 或 rule engine 复核。

你在面试里如果能说“降低幻觉不是靠一个更聪明的模型，而是靠证据、验证和工作流设计”，会非常加分。

第五层：后评测与观测层

真正生产中，幻觉治理离不开数据闭环：

• 哪些问题类型最容易编；
• 哪些来源最不可靠；
• 哪些 prompt 促使模型过度自信；
• 哪些工具经常被误用；
• 哪些版本升级后出现回归。

也就是说，幻觉不是一次性解决，而是持续监控与回归测试对象。