大模型幻觉从哪来：机理分析与工程缓解手段

大模型幻觉不是 bug，而是概率生成机制在信息不足时的必然产物。本文区分四类幻觉，给出七种工程缓解手段，并强调「显式允许模型说不知道」是收益最高的一招。

幻觉不是 bug，是原理的必然结果

第一次遇到大模型一本正经地胡说八道时，很多人的第一反应是「这模型有 bug」。但如果你理解了它的工作原理，就会发现大模型幻觉几乎不可避免。

大语言模型的本质是一个下一个词的预测器。它做的事情，是根据前面的文本，计算出下一个最可能出现的词。这个机制有个关键特性：

它优化的是「看起来合理」，而不是「事实上正确」。

这两者大多数时候是重合的——因为在真实语料里，"水的沸点是"后面接"100 度"的概率远高于别的。但在模型没有把握的地方，它仍然会选出一个「语言上最通顺」的答案，而不是说「我不知道」。

这就是大模型幻觉的根源：模型没有「不知道」这个选项，除非你显式给它。

理解这一点非常重要，因为它决定了你该怎么应对——你不能指望换个更强的模型就彻底解决，你需要的是工程手段。

幻觉的四种类型

把它们分开看，你才能对症下药。

类型一：事实性幻觉

编造不存在的事实。比如虚构一篇论文、一个历史事件、一个人的履历。

成因：模型在训练数据里见过大量格式相似的表述，它学到了「格式」，但具体内容是自己填充的。

高危场景：学术引用、法律条文、医疗建议、财务数据。

类型二：忠实性幻觉

这个更隐蔽——模型有正确的资料，但回答时偏离了资料。

比如你给它一段产品说明，让它总结，它却加入了自己知道的、但不属于这份说明的内容。

成因：模型的训练知识与给定上下文发生了竞争，它没有严格地「只依据上下文」。

高危场景：所有 RAG 应用、文档摘要、翻译。

类型三：逻辑性幻觉

推理过程看起来合理，但步骤之间没有真正的因果联系。

成因：模型是在模仿「推理的样子」，而不是真的在执行逻辑运算。

高危场景：数学计算、多步推理、代码逻辑。

类型四：指令性幻觉

模型没有遵循指令。比如你要求输出 JSON，它却输出了自然语言；要求用中文，它答了英文。

这类常被归为「不听话」而非幻觉，但本质相同：模型在生成时，指令约束的权重不够高。

工程缓解手段

下面这些是按「性价比」排序的，建议从上往下用。

手段一：把「不知道」变成一个允许的答案

这是最简单也最有效的一招，但很多人不做。

在提示词里显式写：

如果资料中没有足够信息回答问题，请直接回答「根据现有资料无法确定」。
不要基于常识或推测补充。

模型之所以倾向编造，是因为它被训练成「要给出有用的回答」。你显式地告诉它「拒答也是合格回答」，它就敢说不知道了。

实测效果：在 RAG 场景里，仅这一条就能显著降低事实性幻觉。

手段二：要求引用来源

请在回答中标注每个事实依据的资料编号，格式如 [1][2]。

这一招有个隐含作用：它逼模型「回看」资料，而不是凭记忆作答。

而且对用户也有价值——能验证来源的答案，可信度高得多。

手段三：结构化输出约束

对于需要精确格式的场景，不要用自然语言描述格式，而是用 schema 强约束：

请以如下 JSON 格式输出：
{
  "answer": "string",
  "confidence": "high" | "medium" | "low",
  "sources": ["string"]
}

注意 confidence 字段——让模型自己标注把握程度，是个被低估的技巧。它在「我确定」和「我猜的」之间提供了信号。

手段四：降低温度参数

temperature 控制生成的随机性。

高温度（0.7–1.0）：更有创造性，也更爱编
低温度（0–0.3）：更保守，倾向于输出高概率内容

对于事实性任务，把温度调到 0 附近是标准做法。 这不是万灵药，但成本极低。

手段五：RAG——让模型有据可依

这是结构性方案。与其让模型凭记忆回答，不如先检索出相关原文，让它基于原文回答。

原理很简单：模型在「有明确依据」时，乱编的动机更弱。

但要注意：RAG 不能消除忠实性幻觉。模型仍可能偏离检索到的内容。所以 RAG 要配合手段一和手段二一起用。

关于 RAG 的完整实现，可以参考 RAG 实战：企业知识库问答系统搭建。

手段六：多轮验证与自检

让模型生成答案后，再让它自己检查一遍：

请检查上面的回答，标出其中任何没有资料支撑的陈述。

这叫 self-consistency 或 self-verification。它不完美（模型可能检查不出自己的错误），但在关键场景能过滤掉一部分问题。

更进一步的做法是让多个模型交叉验证，或者对同一问题多次采样看答案是否一致——如果不一致，说明模型没有把握。

手段七：把确定性任务交给代码

这是最重要的一条，也是最容易被忽略的。

有些事情模型天生不擅长，就不要硬让它做：

任务	错误做法	正确做法
算术	让模型算	让模型写代码，执行代码
日期计算	让模型推	调用日期库
数据查询	让模型背	工具调用查数据库
精确字符串匹配	让模型找	用正则或检索

模型擅长的是理解和生成语言，不是精确计算。把计算类任务交给工具（也就是 Function Calling），能从根本上消除这一类幻觉。

如何评估幻觉率

如果你在生产环境用大模型，你需要一个可量化的指标，否则「优化」就是盲目的。

构建测试集

准备 50–200 个问题，每个都要有明确的正确答案或标准依据。这需要人工标注，但这是必要投入。

定义评估维度

不要只判「对/错」，分层评估更有价值：

正确：答案正确且有依据
部分正确：主要事实对，但有细节错误
幻觉：编造了不存在的信息
拒答：正确地说「不知道」

注意「拒答」要单独统计。一个宁可拒答也不编造的系统，在很多场景下比一个爱编造的系统更可用。

自动化评估

可以用另一个模型来评估回答质量（LLM-as-judge），但要小心：评判模型自己也会幻觉。所以关键场景仍需人工抽检。

关于评测体系的搭建，LLM 评测与可观测性：把稳定性做出来有更系统的方法论。

一个反直觉的事实

幻觉率低 ≠ 系统可用性高。

举个例子，两个系统：

A 系统：80% 正确，15% 幻觉，5% 拒答
B 系统：60% 正确，2% 幻觉，38% 拒答

在医疗、法律这类错误代价极高的场景里，B 可能更可取——因为你宁愿它说不知道，也不要它编造。

所以优化目标不是「幻觉率最低」，而是「在你的业务场景里，错误的代价和拒答的代价哪个更高」。

这个判断只能由业务方做，技术人员不该替他们决定。

实践清单

如果你正在把大模型接进生产，这是一份可以直接用的检查清单：

提示词层面

[ ] 显式允许「不知道」，并给出标准拒答话术
[ ] 要求标注依据来源
[ ] 给出输出格式的 schema 或示例
[ ] 事实性任务使用低温度（0–0.3）

架构层面

[ ] 需要准确性的场景接入 RAG
[ ] 计算类任务改为工具调用，不让模型硬算
[ ] 关键结论做二次验证
[ ] 对高风险的输出加人工审核环节

监控层面

[ ] 建立带标准答案的测试集
[ ] 分层统计正确/部分正确/幻觉/拒答
[ ] 记录每次线上幻觉案例，反哺提示词优化
[ ] 版本迭代时回归测试，确认没有变得更糟

小结

幻觉不是模型「出故障」，而是概率生成机制在信息不足时的必然产物。

所以应对思路不是「等模型变强」，而是三层设防：

提示词层：允许拒答、要求引用、约束格式、降低温度
架构层：用 RAG 提供依据，用工具调用替代硬算
监控层：建立测试集量化评估，持续回归

其中我认为「显式允许模型说不知道」是被最多人忽略、收益却最高的一招。它只需要改一行提示词，就能显著减少编造。

最后记住那个反直觉的判断：优化目标不是幻觉率最低，而是让错误代价和拒答代价在你业务的权衡下最优。