Hallucination（幻觉）

什么是幻觉

幻觉（Hallucination）是指大模型生成的内容看起来正确但实际上是错误的。包括：

• 事实性幻觉 — 编造不存在的事实（"鲁迅于 1950 年获得诺贝尔文学奖"）
• 来源性幻觉 — 虚构引用来源（编造不存在的论文/URL）
• 能力性幻觉 — 声称能做做不到的事（"我可以访问互联网"）
• 代码幻觉 — 调用不存在的 API/函数/库

为什么会产生幻觉

根本原因：概率生成

大模型的本质是"预测下一个最可能的 token"。它不是在检索事实，而是在做概率推理。当训练数据中缺乏确切信息时，模型会根据语言模式生成"看起来合理"的内容。

关键认知：幻觉不是 bug，是 LLM 的架构特征。没有任何技术能 100% 消除它，只能压低发生率和影响范围。

具体原因

1. 训练数据不足 — 对某个话题了解不够，靠"猜"
2. 知识截止 — 训练数据有截止日期，不知道最新信息
3. 过度泛化 — 把某个领域的模式错误应用到另一个领域
4. 指令模糊 — 用户的问题不够明确，模型自由发挥
5. 上下文冲突 — 上下文中有矛盾信息，模型选择"自圆其说"
6. RLHF 的副作用 — 训练时被奖励"自信地回答"，于是不知道也硬答

幻觉的典型表现

1. 编造 API

用户：FastAPI 怎么做 WebSocket 广播？
模型：使用 FastAPI 的 broadcast() 方法...  ← 这个方法不存在

2. 虚构引用

用户：注意力机制最早是谁提出的？
模型：根据 Smith et al. (2017) 的论文...  ← 这篇论文不存在

3. 混淆概念

用户：MCP 和 A2A 有什么区别？
模型：MCP 是 Google 提出的...  ← MCP 是 Anthropic 提出的

4. 数字 / 单位幻觉

用户：GPT-4 的训练数据有多少 token？
模型：GPT-4 的训练数据约 13 万亿 token...  ← 数字凭感觉

主流幻觉评测基准

知道怎么衡量，才能比较不同方案。常用基准：

实务中不要只看一个基准。模型 A 在 TruthfulQA 高、SimpleQA 低，说明它"会拒答易错题但事实知识不丰富"——这跟你的业务匹配吗？

如何缓解幻觉

1. RAG（检索增强生成）

最有效的方法。在生成回答前先检索知识库，让模型基于真实文档回答。

用户提问 → 检索知识库 → 检索到的文档 + 问题 → 模型生成 → 引用来源

注意：RAG 降低而非消除幻觉。模型仍然可能：

• 忽略检索结果，按自己"知道的"答
• 把检索结果里的信息张冠李戴
• 检索没命中时强答

详见 RAG。

2. Grounded Generation：强制引用

在 prompt 里要求每一句话都标注来源，没有来源的不能说：

你必须严格遵守：
1. 只基于 <context> 内的信息回答
2. 每个事实陈述后用 [doc-1] [doc-2] 标注来源
3. 如果 context 里没有，回答"提供的资料未涵盖这一点"
4. 不要补充任何 context 外的"背景知识"

GPT-5 / Claude Sonnet 4 / Gemini 2.5 对此类指令服从度较高，老模型容易"指令听了一半"。

3. Verifier 二阶段

让另一个 LLM（甚至同一个 LLM 第二轮）专门检查首轮输出：

[生成 Agent]            [Verifier Agent]
回答 +  ─────────────►  逐句核对 context
引用                    输出：✓ 准确 / ✗ 幻觉句
                          ↓
                       有幻觉则要求重写

代价：token 翻倍 + 延迟翻倍。但对法律 / 医疗 / 金融场景是必要投入。

4. 要求标注不确定性

在 prompt 中要求模型标注信心程度：

回答时标注你的信心程度：
[确定] 基于事实的回答
[推测] 基于推理的推测
[不确定] 缺乏足够信息

5. 限定回答范围

如果不知道，直接说"我不知道"。
不要编造信息。
只基于提供的上下文回答。

6. 交叉验证

对同一问题多次提问（不同温度 / 不同 prompt 变体），比较答案的一致性。不一致的部分大概率含幻觉。

7. 使用推理模型

DeepSeek-R1、GPT-5、Claude Opus 4 thinking 等推理模型在回答前会先"想一想"，幻觉率显著低于非推理模型——但会用更多 token，按场景权衡。

8. 温度调低

将 temperature 设为 0 或 0.1，减少随机性，让模型更"保守"。

不同模型的幻觉率

生产环境检测 Pipeline

把"靠运气"变成"系统化防御"，典型四层：

用户问 → [1] Pre-Retrieval  → [2] Generation  → [3] Post-Check  → 返回
                ↓ 检索        ↓ grounded gen     ↓ 自动 verifier
                              ↓ 强制引用         ↓ 不通过 → 降级回复

具体配置：

经验值：加 Post-Check 一般能把幻觉率再压 30-50%，代价是延迟 +20-40%、成本 +50-80%。

开发者的幻觉检测清单

在应用中处理模型输出时，检查以下信号：

1. 回答中是否包含可验证的事实？→ 查证
2. 是否引用了 URL/论文/文档？→ 验证是否存在
3. 代码是否调用了 API/函数？→ 查文档确认
4. 回答是否与已知事实矛盾？→ 标记冲突
5. 模型是否说"我不知道"？→ 这是好信号，不要惩罚
6. 数字 / 日期 / 单位是否合理？→ 数量级粗算
7. 多次重复提问，结果是否稳定？→ 答案飘忽 = 高幻觉风险

常见误区

误区一：「加了 RAG 就不会幻觉了。」 RAG 解决的是「模型不知道」的问题，解决不了「模型从检索到的材料里推出一个材料没说的结论」。检索命中率高不等于回答正确——引用对了、结论错了是 RAG 场景里最常见的失败形态，所以「强制引用」必须与「Verifier 二阶段」配合使用，见上文第 2、3 节。

误区二：「把温度调到 0 就消灭幻觉了。」 温度为 0 只让输出更确定，不让它更正确。这是「随机性」与「事实性」两个维度被混为一谈的典型：采样更集中，模型照样会自信地给出它训练分布里本来就有的错误信息。

误区三：「幻觉率低的模型 = 用起来没有幻觉。」 幻觉率是基准口径下的数字，而你的任务分布不等于基准分布。照着横评榜单直接挑第一名，风险在于基准覆盖之外的领域（企业内部 API、私有数据、小语种）幻觉率可能完全不同。

误区四：「幻觉可以被彻底消除。」 不能。 LLM 的输出机制是逐 token 采样，不存在「如果不知道就说不知道」的内建开关。工程目标只能是「把幻觉压到可接受、并且可检测」，这也是本文把「检测 Pipeline」与「检测清单」放在缓解方案之后的原因——缓解与检测是两条腿，缺一条都会在生产上出问题。

误区五：「这只是一个模型质量问题。」 它同时是成本问题：幻觉越多，人工复核、回滚、二次调用的成本越高。评估一个模型的实际成本时，单位 token 价格乘以幻觉导致的重跑次数，往往比单价差异更能决定总账。

更新说明

• 2026-10-28 更新：新增本节「常见误区」，并把上文「如何缓解幻觉」的八种方法按作用面重新归类说明——检索类（RAG）解决知识缺失，生成类（Grounded / Verifier / 不确定性标注）解决表达失控，采样类（推理模型 / 温度）只影响随机性。三者不可互相替代，选型时应先看你的失败样本属于哪一类。
• 本文「不同模型的幻觉率」一节的数字保留采集时点口径，模型换代后不代表当前水位；跨代比较请回到同一评测版本。

延伸阅读

• 缓解方案：RAG（检索增强生成）
• 控制随机性：Temperature 与 Top-P
• 上下文组装：Context Engineering
• 行为微调：Fine-tuning vs RAG