2.3 幻觉从哪来，什么时候必然发生
一句话结论：幻觉不是模型的"bug"，而是「用概率预测代替事实判断」这个机制的必然副产物。你无法消除它，但可以预判它在什么时候发生，并用工程手段把它压到可接受的水平。
读这篇之前
需要先读 2.1（模型在预测下一个 Token）。这一篇是把 2.1 的机制推论到底：既然它在算概率，那"说错"就是结构性的，而不是偶发的。
一、先看幻觉长什么样
幻觉（hallucination）指模型生成看似合理但实际错误的内容。它有几个典型形态，危害程度递增：
| 形态 | 例子 | 危害 |
|---|---|---|
| 事实错误 | 把某功能说成另一个模型有的 | 中：好查 |
| 张冠李戴 | 把 A 团队的方案说成 B 团队的 | 中：需交叉验证 |
| 虚构引用 | 编出一个不存在的论文、链接、API | 高：看起来很可信，无法点击验证 |
| 虚构细节 | 编出具体的数字、版本号、参数名 | 高：会被直接抄进代码 |
| 过度自信 | 用"肯定是""就是这样"包装不确定内容 | 最高：击穿读者的怀疑机制 |
最后一种最危险，因为它不是内容错，而是姿态错——它让你失去了本来会有的怀疑。
二、从机制推：幻觉为什么必然
回到 2.1 的核心结论：模型在做的事是预测下一个 Token，优化目标是"像不像训练数据里该出现的样子"，而不是"这个陈述是否为真"。
这个机制推出三层必然性：
必然性一：没有"真值"这个优化目标
模型从未被直接训练去"判断真假"，它被训练去"生成合理的续写"。所以当训练数据里关于某话题的内容稀疏或矛盾时，它只能生成"最像样的那一个"——而不是"正确的那一个"。
必然性二：流畅性与准确性是两套机制
模型的输出在语言层面永远是流畅的，因为流畅性是它被优化的第一目标。这意味着"读起来很顺"完全不能作为准确性的证据。 恰恰相反，越是读起来顺、结构整齐、术语密集的段落，越容易被误信。
必然性三：细节越具体，越容易编
通用概念在训练数据里出现无数次，模型说得基本不会错。但具体的数字、版本号、函数签名、配置项名称出现的频率低得多，模型只能按"这个位置通常长什么样"来填——于是就编了。
一条可直接用的判据：越是具体、越是罕见、越是最近的内容，幻觉概率越高。
三、什么时候必然发生：五个高危场景
按上一条判据，可以列出幻觉的高危区。这不是概率问题，而是结构上一定会出错：
| # | 场景 | 为什么会错 | 典型表现 |
|---|---|---|---|
| 1 | 训练数据之后的事 | 模型知识在训练时冻结，之后发生的一切它都不知道 | 编造新版本特性、新 API |
| 2 | 小众/私有领域 | 训练数据里几乎没有，只能瞎猜 | 编造内部系统名、私有框架用法 |
| 3 | 精确数值与标识符 | 具体值出现频率低，按"位置习惯"填 | 编版本号、端口号、参数默认值 |
| 4 | 不存在的引用 | 论文标题、链接的"形状"很规律，容易生成 | 编出不存在的文献与 URL |
| 5 | 你暗示了答案的提问 | 你的问法里已经含了错误前提，它顺着说 | "为什么 X 比 Y 快？"（默认 X 更快） |
第 5 条最容易被忽略：带有错误前提的问题，模型常常顺着前提往下答，而不是纠正前提。 这在技术上不是幻觉，而是"顺从"，但后果一样。
四、Agent 场景下幻觉更危险的两个原因
普通对话里，幻觉的后果是"你被误导"。但在 Agent 里，它会被放大：
原因一：幻觉会变成"行动"
一个 Chatbot 编造一个不存在的函数名，你顶多困惑。但一个 Agent 编造一个不存在的命令并真的执行了它，可能造成真实损害。
这就是为什么第 14 章要强调「不可逆动作必须有校验」。
原因二：一次幻觉会污染后续所有轮次
模型编造的一个错误结论，一旦进入上下文，后续每一轮都会把它当作既定事实使用。错误被"记住"了。
这也是为什么「让模型先勘误再用」比「让模型先猜再改」更可靠。
五、工程上怎么压：六层防线
幻觉不能消除，但可以用分层防御把危害压到可接受。从便宜到昂贵排列：
| 层 | 手段 | 成本 | 效果 |
|---|---|---|---|
| 1. 换问题 | 别问"是什么"，让它从给定材料里找 | 极低 | 高 |
| 2. 给证据 | 把权威原文放进上下文（RAG） | 低 | 高 |
| 3. 要引用 | 要求每句结论标注出处，"找不到就说找不到" | 低 | 高 |
| 4. 要自检 | 让它先列结论，再逐条核对依据 | 中 | 中 |
| 5. 外部校验 | 用工具/代码/schema 校验输出 | 中 | 高（针对具体类型） |
| 6. 评估回归 | 建评测集，改动前后对比（第 13 章） | 高 | 长期最关键 |
第 1 层最值得先说清
"别问它知道什么，问它材料里写了什么" —— 这一个思维转变能消掉大部分幻觉。
❌ 差："LangGraph 的 checkpointer 怎么用？" → 它可能编
✅ 好："根据下面这份文档，checkpointer 怎么用？【贴文档】" → 它只能引
代价是你要准备材料——而这正是 RAG（第 7 章）存在的意义。
第 3 层的关键在于"允许说不知道"
必须显式给模型"放弃"的出口。如果你只要求它回答，它就会编；如果你明确允许它说"材料中未提及"，它编造的动机就下降了。
这不是玄学，而是因为「说不知道」在它的训练数据里也是被奖励的行为之一——你需要把它激活。
六、动手：五个幻觉高危场景的实测
理论说"越具体越容易编"，这里是五个可以直接测的例子。
| # | 提问 | 预期幻觉形态 |
|---|---|---|
| 1 | "某框架 v3.2.1 的 setTimeout 默认值是多少？" |
编一个具体毫秒数 |
| 2 | "给我 3 篇 2026 年关于 X 的论文" | 编标题与作者（看起来很真） |
| 3 | "这个内部系统的 API 路径是什么？" | 编一个符合命名习惯的路径 |
| 4 | "为什么 X 比 Y 快 30%？" | 顺着前提答，不质疑"30%" |
| 5 | "按 RFC 9999 的规定…" | 编造条款内容 |
五个都能在 10 分钟内测出来，而且都能用同一种方式防住。
三种防法的效果对比
| 防法 | 对场景 1-3 | 对场景 4 | 对场景 5 |
|---|---|---|---|
| 贴材料再问 | ✅ 有效 | ⚠️ 部分 | ✅ 有效 |
| 要求引用 | ✅ 有效 | ❌ 无效 | ✅ 有效 |
| 允许说不知道 | ✅ 有效 | ⚠️ 部分 | ✅ 有效 |
| 让它先质疑前提 | —— | ✅ 有效 | —— |
场景 4 需要特殊处理：显式要求"先检查问题中的前提是否成立"。
请先判断这个问题里的前提是否成立。
如果"X 比 Y 快 30%"这个前提无法确认，先指出这一点，再回答。
一个可复用的提示模板
只使用下面材料回答。
每条结论后标注来源片段编号。
材料中没有的内容，输出「材料中未提及」，不要推测。
如果问题中的前提与材料冲突，先指出冲突再回答。
材料：
{...}
这段模板能同时防住五个场景中的四个——剩下"前提错误"那一类，靠最后一句。
七、常见误区
误区一：换个更强的模型就能解决幻觉。
更强的模型幻觉更少，但不会归零，因为根源在机制。而且在细分领域，强模型的幻觉可能更"自信"。
误区二：幻觉就是"胡说八道"，一眼能看出来。
恰恰相反。高价值幻觉的特征是完全合理、术语准确、结构整齐——它骗的就是有知识的人。
误区三：加了 RAG 就没有幻觉了。
RAG 只是给了它证据。它仍可能读错证据、张冠李戴、或把证据外的内容混进来。所以第 3 层（要引用）依然必要。
误区四：让模型"仔细一点""不要编造"就行。
口头要求效果有限。结构化的约束（必须引用、找不到就明说、输出必须通过 schema 校验） 才有效。
误区五：幻觉是概率问题，多试几次取共识就行。
多次采样能提高"多数正确"的概率，但如果模型在某个点上系统性错误，多试几次会得到一致地错。共识不能替代事实核查。
八、把防线画成图
flowchart TD
A["提问"] --> B{"能否限定在给定材料内？"}
B -->|能| C["RAG：先给证据再问"]
B -->|不能| D["明确允许说'不知道'"]
C --> E["要求逐句标注引用"]
D --> E
E --> F{"输出可否机器校验？"}
F -->|能| G["schema / 代码 / 工具校验"]
F -->|不能| H["人工抽查 + 评测回归"]
G --> I["进入上下文"]
H --> I
I --> J["注意：错误会被后续轮次继承"]
关键在最后一句：幻觉一旦进入上下文，就会变成后续推理的"事实"。所以防线要放在"进上下文之前"，而不是之后。
九、一个反直觉的结论：幻觉与"聪明"不相关
很多人以为"模型越强，幻觉越少"。部分正确，但有一个陷阱。
| 现象 | 原因 |
|---|---|
| 强模型在通用知识上幻觉更少 | 知识覆盖更全 |
| 强模型在细分领域可能更自信地编 | 它更擅长"生成像样的答案" |
| 强模型更容易骗过评审 | 表述更流畅、结构更完整 |
第三条最危险：因为它意味着你的 LLM 评审器（13.2）也会被一起骗过。
实践含义：
不要用"看起来专业"作为质量信号。
要用"能不能在材料里找到依据"作为信号。
这也是 7.5 讲"归因"的原因——可追溯的答案才可信，而"流畅"从来不是可信的证据。
一个可落地的判断规则
如果一条结论无法指向某个具体来源（材料片段、工具结果、原文），
就把它当作「待核实」，不进最终产出。
这条规则可以做成流程：在生成最终答案前，先让模型为每条结论标注来源，标不出来的删掉或降级。
十、RAG 场景的幻觉：一个特例
加了 RAG 之后，幻觉不会消失，而是换了一种形态。
| 形态 | 表现 | 为什么 |
|---|---|---|
| 材料外扩展 | 材料说 A，它补了 A 的"原因" | 模型倾向于把话说完整 |
| 张冠李戴 | 把材料 B 的内容归到 A | 检索片段混在一起 |
| 过度概括 | 从一条特例推出普遍结论 | 归纳是模型的强项，也是编造源 |
| 引用错位 | 引用了真实片段，但结论不由它支持 | 引用只看"像不像" |
第二种和第四种是 RAG 特有的，也最难发现——因为引用的片段确实存在。
检测方法：抽查 20 条答案，逐条核对"引用的片段是否真的支持这条结论"。这个检查常常能发现 10-20% 的问题。
十一、给你的项目的三条硬规则
| # | 规则 | 理由 |
|---|---|---|
| 1 | 结论必须可指向来源 | 无来源即待核实（第九节） |
| 2 | 明确允许"未提及" | 不给出口它就会编 |
| 3 | 具体数值一律外部校验 | 版本号、参数、价格最易编 |
第 3 条最实用：凡是"具体数字"类的输出，不要让模型直接给，而是让它调用工具查（或者由代码填）。
11、下一篇
幻觉是从"预测 Token"直接推出来的必然结果。那么另一个相关问题：既然模型每次输出都是从一个概率分布里抽样，这个抽样过程可不可以调？调了会怎样？
下一篇讲采样参数——温度、top-p 这些旋钮到底在控制什么，以及它们如何直接决定一个 Agent 的稳定性。