Appearance
AI 幻觉
AI 幻觉不是模型偶尔"发疯"，而是概率生成系统在缺少可靠依据时的天然风险。
Agent 可以多步执行任务。步骤越多，幻觉越容易悄悄积累，而且越难被发现。
本章目标
- 能区分事实性错误、过度推断、虚构引用等常见幻觉表现
- 理解为什么 Agent 多步执行会放大幻觉风险
- 理解为什么 RAG 和工具也只能降低幻觉，不能彻底消除
- 能把降低幻觉的方法映射到产品和工程设计上
什么是幻觉
Hallucination（幻觉）指的是：模型生成了看起来流畅、合理、甚至很自信，但实际上不准确、无依据或根本不存在的内容。
常见表现：
- 虚构引用：编造了论文标题、API 参数、数据来源
- 过度推断：资料只说了 A，模型却顺手得出了 B 的结论
- 把不确定说成确定："该项目于 2021 年发布"，但实际上资料没有提到具体时间
- 填空式发挥：问到了不知道的细节，用"听起来合理"的内容填充而不是说不知道
但幻觉不只是"说错了事实"。更准确地说，它是一种证据失真——模型输出的内容看上去建立在证据之上，实际上超出了证据、扭曲了证据，甚至根本没有证据。
这也是为什么幻觉特别危险。它不是胡言乱语式的错误，而是很像真的错误。
为什么会发生
根本原因：模型不是事实查询器，而是概率生成器。它的目标是生成最像答案的内容，不自动保证答案真实。
模型在每一步都只是预测"什么内容最像接下来应该出现的答案"。这对语言流畅性非常有效，但对真实性没有天然保障。只要上下文里缺了一块、证据链断了一段、用户语气又强烈要求给结论，模型就会倾向于把空白补满。
常见诱因：
- 上下文不足，没有对应资料，却要求给出回答
- 任务描述太开放，模型倾向于填满所有空白
- 用户强行要求"必须给答案"，模型只好编一个
- 多步任务中，上一步的推断被当作下一步的"事实"输入
幻觉不等于无知，它经常发生在“差一点就对”的地方
这一点很重要。很多人把幻觉理解成模型完全不知道，于是随口乱编。真实情况更麻烦。
大量幻觉都发生在模型"大方向是对的，但局部细节没根据"的时候。比如：
- 论文主题说对了，但作者名和年份编错了
- API 的主要用途说对了，但参数名补错了
- RAG 召回方向是对的，但模型多补了一句资料里没有的话
也就是说，幻觉常常不是 0 到 1 的胡编，而是 0.8 到 1 之间那一小段越界。正因为它离真实很近，所以更容易被人放过。
Agent 执行链路里幻觉为什么更危险
单步问答里，模型说错了一句话，用户能直接看到并发现问题。
Agent 多步执行时，幻觉会在链路中传播：
- Agent 第 2 步搜索后，模型总结了一段"检索到的内容"——但其实加入了模型的推断
- 第 3 步把这段内容当作事实，继续据此规划下一步
- 第 4 步的结论建立在第 2、3 步的错误之上
到了最终输出，错误已经被多次引用和"确认"，看起来非常可信，但源头早就跑偏了。
Agent 结果比单步问答更难审查，原因就在这里：幻觉不是一次明显的错误，而是分散在多步里、层层叠加的小偏差。
从单步错误到链路污染
如果用系统视角看，Agent 里的幻觉真正危险的地方，不只是它会出错，而是它会污染后续状态。
单步聊天里，一次错误通常停留在一句回答上；多步 Agent 里，一次错误可能进入：
- 下一轮 prompt
- 中间摘要
- 任务清单
- 工具参数
- 最终报告
一旦进入这些状态载体，它就不再只是"这一句说错了"，而是开始变成系统接下来继续依赖的输入。这个过程很像程序里的脏数据传播。最开始只是一个字段错了，后面整个链路都会带着它跑。
哪些场景最容易出幻觉
- 实时信息问答（模型训练截止日之后的事）
- 专业事实性问题（医疗、法律、技术细节）
- 要求给引用、参数名、版本号
- 开放式长回答
- 多步任务中的中间推断环节
对话前先问自己：我们各自知道什么
在设计 AI 对话或构建 AI 功能时，有一个四象限框架可以帮你快速判断当前场景的风险等级，以及该采取什么策略。
两个维度很简单：AI 知不知道 × 人知不知道。
| AI 知道 | AI 不知道 | |
|---|---|---|
| 人知道 | 象限 ①：最安全，用 AI 提效，人来验证 | 象限 ②：危险盲区，AI 可能幻觉，但人能发现 |
| 人不知道 | 象限 ③：纯信任区，AI 能补盲区，但人无力校验 | 象限 ④：双盲区，AI 在猜，人也不知对错 |
这四个象限对应的对话策略完全不同。
象限 ①：双方都知道
风险最低。AI 的回答可以拿来用，你也有能力验证它有没有说歪。典型场景：让模型帮你解释一段你写的代码、总结你看过的文档。
策略：正常使用，稍加复核。
象限 ②：人知道，AI 不知道
这里最容易发生幻觉，但同时也是你最有能力干预的位置。比如你在问 AI 你们公司的内部系统架构、某个私有 API 的具体参数、上周才改过的配置——这些 AI 的训练数据里根本没有，它很可能凑个"听起来合理的答案"。
策略：主动把你知道的信息补进 Prompt。 你知道 AI 不知道的事，这些信息就该写进上下文，而不是期待 AI 自己猜出来。这也是为什么 RAG 和 Tool Calling 优先解决的就是这个象限的问题——把你知道的真实信息喂给模型。
象限 ③：AI 知道，人不知道
这个象限是用 AI 来补自己盲区的价值所在，但同时也是最难校验的位置。你问 AI 一个自己不熟悉的领域问题，它的回答你无法直接判断对不对——因为你本来就不知道。
策略：设计可验证性，而不是直接信任。 要求 AI 给出引用来源，用结构化输出限制发挥空间，或者通过 Tool Calling 让 AI 去查真实数据而不是从记忆里生成。如果是高风险决策（医疗、法律、财务），引入人工审核。
象限 ④：双盲区
最危险。AI 不知道，你也不知道，结果就是 AI 会给出一个看起来有道理的答案，你没有能力判断真假，双方都在黑暗里。
策略：触发拒答机制，或者明确暴露不确定性。 一个可靠系统在这个象限里的正确行为是说"我不确定""当前没有足够信息"，而不是继续生成内容。如果你在产品里没有给模型设置这个"出口"，它在象限 ④ 里只能编。
这个框架不是要你在每次对话前做问卷，而是帮你在设计产品功能或调试 AI 行为时快速定位：当前失败的根因在哪个象限。
象限 ② 的问题，通常靠补上下文或接知识库解决。
象限 ③ 的问题，通常靠设计可审查的引用和校验机制解决。
象限 ④ 的问题，通常靠构建明确的拒答路径解决。
幻觉和创造性的区别
有时候模型"发挥"是对的，有时候是错的。区别在于：
- 创作任务：允许想象，虚构是预期行为
- 事实任务：必须有证据，虚构是幻觉
开发 AI 应用时，要先想清楚当前任务属于哪类，对应的幻觉容忍度完全不同。
幻觉、推断和不确定性表达要分开看
很多产品把这三件事混在一起，最后既不敢让模型推断，又拦不住它胡编。
其实它们不是一回事：
- 幻觉：没有依据，却装作有依据
- 推断：依据不完整，但明确告诉你这是推断
- 不确定性表达：系统承认当前证据不足，主动暴露边界
一个可靠系统，不是完全禁止推断，而是要让推断和事实长得不一样。用户要能看出来：这一句是资料明确写的，那一句只是模型基于现有信息做的判断。
为什么 RAG 也不能完全消灭幻觉
RAG 显著降低了幻觉，但仍然可能出现：
- 检索不到关键资料：你的向量库里根本没有对应内容，模型只好发挥
- 资料质量问题：检索到的资料本身过时或有误
- 上下文截断：资料太长，真正有用的部分被丢掉了
- 模型过度发挥：拿到资料后，在资料没写到的地方继续补充
常见误区：接了知识库就"解决了幻觉问题"。准确说法是：RAG 给模型提供了更多可靠依据，但模型仍然可能在依据之外生成内容。
换句话说，RAG 解决的是"证据供给"问题，不是"表达纪律"问题。
它让模型更有机会看到真实材料，但并不会自动强迫模型只待在材料边界内。真正决定模型会不会越界的，还包括 prompt 约束、上下文组织方式、引用设计、拒答机制，以及你有没有把推断和事实清楚区分开。
降低幻觉的四类方法
第一类是补充真实依据：接 RAG 从知识库检索、用 Tool Calling 实时查事实型数据、要求模型在回答里带出来源。第二类是约束输出：结构化输出限制模型乱发挥的空间，prompt 里明确"只基于资料回答、资料没有就说没有"。第三类是程序校验：校验 JSON 结构、字段类型、引用是否存在、关键结论是否符合规则。第四类是人在回路：对医疗、法律、财务这类高风险场景，模型的输出不能直接等同于可对外展示的内容，必须有人工审核。
为什么“校验”通常比“让模型更谨慎”更可靠
很多人面对幻觉，第一反应都是继续调 prompt，比如要求模型"更加严谨""不要编造""没有依据就别回答"。这些约束有帮助，但往往不够稳定。
更可靠的办法通常是把一部分正确性要求从模型内部转移到外部系统：
- 引用必须能落到真实文档
- JSON 字段必须能通过校验
- 时间、金额、编号必须满足规则
- 高风险结论必须经过第二道检查
原因很简单。模型的谨慎是一种统计倾向，校验是显式规则。前者能改善表现，后者才能真正拦截错误。
"不知道"为什么是系统必需项
很多系统的问题不是模型不知道，而是系统不允许它说不知道。这样模型就只能编。
一个可靠的 AI 产品应该允许这些状态：
- 不知道
- 资料不足，无法确认
- 以下是推断，不是事实
- 需要更多信息才能回答
对用户展示这些状态，实际上会提升信任感，而不是降低它。
这背后其实是在给系统增加一个合法出口。没有这个出口，模型就只能在"答出来"和"看起来失败"之间选一个；而一旦允许明确地说不知道、资料不足、需要更多信息，系统就有了不编造的生路。
工程上的正确态度
- 默认模型可能会错，而不是默认它是对的
- 事实问题尽量给来源，而不是只给结论
- 高风险结果必须校验（程序校验或人工审核）
- 对推断和事实做清晰区分，不要把两者混在一起展示给用户
- 多步任务里，每一步的中间结果都值得记录和复查
幻觉防控本质上是系统设计，不只是模型调教
这一章如果只留下一个判断，我希望是这个：幻觉不是靠一条神奇 prompt 消失的，它更像系统工程里的可靠性问题。
你需要同时管住几层：
- 证据从哪里来
- 证据以什么形式进入上下文
- 模型有没有被允许越界补完
- 错误能不能被外部校验拦住
- 高风险内容有没有第二道审查
一旦把幻觉理解成可靠性问题，你的思路就会变：不再追求"让模型永远别错"，而是设计一个即使模型会错，也不至于悄悄把错放大的系统。
接下来
- Prompt Injection 与 AI 安全：幻觉是内部风险，Prompt Injection 是外部风险。Agent 读取外部内容时，两者可能同时出现。
- AI 应用评测：如何系统性地发现幻觉、建立回归机制，而不是靠手动试。
从真实产品看幻觉防控
Claude Code 对幻觉问题有两个值得关注的工程选择（来自 Claude Code v2.1.88 源码）：
Verification Agent：Claude Code 内置了一个专门的 verificationAgent，在多 Agent 流程里负责验证其他 Agent 的实现结果。它的设计哲学写在系统提示词里：「验证意味着证明代码有效，而不只是确认它存在。」它会独立运行测试，怀疑地审视结果，不会只是橡皮图章地盖章通过。
这解决的是多步链路里的幻觉累积问题——不依赖实现者自我审查，而是引入独立验证者。和人类团队的 Code Review 逻辑相同：同一个人写代码和审查代码，错误很容易被跳过。
AskUserQuestionTool：当 Agent 没有足够信息继续推进时，它可以通过这个工具直接问用户，而不是凭猜测继续。这是"不知道就说不知道"在工具层面的工程实现，不靠 prompt 约束，而是给 Agent 提供了一个合法的「暂停并提问」出口。
两个设计共同体现的原则：幻觉防控不只靠模型自身的谨慎，更要靠系统架构上的结构性约束。
容易踩的坑
几个做产品时容易忽略的点：
幻觉最可怕的不是离谱，而是像真的。越接近真实边缘的错，越容易被放过。
RAG、工具、引用都不是“消灭幻觉”的魔法，它们只是把错误从黑盒里拖出来，变得可定位——但定位不等于消除。
多步 Agent 的风险不只是会出错，而是错误会进入中间状态并继续传播。上游一个小偏差，到下游可能已经面目全非。
“不知道”不是产品示弱，是系统诚实。诚实比虚假的完整更能积累用户信任。
真正有效的防控手段，大多来自外部校验、独立验证和边界设计，而不是继续要求模型“再严谨一点”。
下一章：Prompt Injection 与 AI 安全——Agent 主动读取外部内容时，外部文本里藏着的恶意指令是另一类风险。