幻觉并非根本原因：生产环境 AI 的调试方法论

当一名律师在联邦备案文件中引用不存在的法庭案例时，这一事件被广泛报道为“ChatGPT 产生了幻觉”。当一家咨询公司的政府报告中包含虚假脚注时，复盘报告写道“AI 伪造引文”。当一个医疗转录工具在医疗笔记中插入暴力语言时，解释仅仅是“模型产生了幻觉”。在每一个案例中，代价昂贵的失败都被归结为一个由三个词组成的根本原因，这使得修复变得不可能。

“模型产生了幻觉”在 AI 领域等同于在堆栈跟踪中写下“未知错误”。它描述了发生了什么，却没告诉你为什么发生或如何修复。每一次幻觉都有一个可诊断的原因——通常属于四个类别之一——且每个类别都需要不同的工程响应。理解这种区别的团队能够交付可以优雅降级的 AI 系统。而不理解的团队则在不断地通过提示词玩“打地鼠”游戏。

四个真实的根本原因

现代幻觉研究已经形成了一套对工程师直接有效的分类法。这些类别清晰地映射到你系统执行路径的不同环节，这意味着你可以独立地对它们进行检测，并在不触动模型的情况下修复它们。

检索失败（Retrieval failure） 是 RAG 系统中最常见的根本原因，也最容易诊断。你的检索器返回了实际上无法回答用户查询的文档——无论是由于查询与文档的语义不匹配、你所在领域的嵌入（embedding）质量问题，还是知识库过时。模型随后生成了听起来权威但缺乏依据的文本，因为它在缺乏相关证据的情况下补全了一个模式。其特征是，手动注入正确的文档就能让幻觉消失。模型本身并没有损坏。

上下文冲突（Conflicting context） 发生在你的检索流水线提取了相互矛盾的文档时，或者提取的事实与模型的参数化知识（即它在训练期间学到的内容）相冲突时。模型随后面临一个它并非为显式解决而设计的决策问题——它会挑选一个来源并自信地生成内容，而不会向调用者指出冲突。自我矛盾的输出——即模型在同一次回复中提出两个不相容的主张——就属于这一类。实体混淆也是如此，即模型将不同文档中两个名称相似的事物混为一谈。

提示词歧义（Prompt ambiguity） 是团队最常低估的根本原因。模糊的指令会产生理解间隙，模型会用统计学上最合理的后续内容来填补这个间隙——而这在事实层面可能是错误的。“描述 X 的现状”会诱发模型对它无法了解的现状产生幻觉。“总结公司取得的成就”在没有范围限制的情况下，会被编造的成就所填充。模型并不是在随机猜测；它正在做它被训练去做的事情，即在指令不明确的情况下生成流畅、符合主题的文本。

知识边界违规（Knowledge boundary violations） 是在模型实际认知的边缘发生的故障。训练截止日期是最明显的案例，但在实践中，问题更为隐蔽：模型经常在接近其知识边界时高估自己的自信度。一个训练到 2024 年初的模型不仅无法了解 2024 年中期的事件，它还会主动生成关于那个时期听起来很可信的错误信息，因为它有足够的上下文来生成流畅的文本，但没有足够的事实依据来保证准确性。罕见与常见关联的复合效应加剧了这一问题：模型看到的关于常见（有时是错误的）模式的文本比正确的罕见模式更多，于是它会倾向于向多数派产生幻觉。

一个正规的幻觉复盘报告是什么样的

好的和差的复盘报告之间的区别不在于洞察力，而在于检测工具（instrumentation）。只有在故障发生时记录了正确的数据，你才能进行根本原因分析。

任何 LLM 请求的最小生产环境追踪（trace）都应捕获：完整的提示词（包括系统消息）、所有检索到的文档及其检索评分、原始模型输出、可用的置信度评分，以及对于 Agent 系统而言完整的对话历史。没有这些，你就是在没有证据的情况下进行法医鉴定。

有了记录的追踪数据，调试工作流将遵循系统的执行路径：

从输入开始。用户的查询是否有歧义？一个理智的人读到它是否会产生多种解释？当任务需要事实检索时，提示词模板是否鼓励了推测（如“建议”、“想象”、“可能会”）？在你有意识地尝试以多种方式解释查询之前，提示词歧义通常是隐形的。

然后转向检索。检索到的文档是否真的包含了回答查询所需的信息？高检索评分并不意味着高相关性——你的嵌入模型可能学到的是浅层的表面相似性，而不是针对你特定领域的语义相关性。在发布任何 RAG 系统之前，请在留出的评估集上衡量检索的精确率（precision）和召回率（recall）。许多团队跳过了这一步，结果通过生产环境中的幻觉才发现了问题。

接着检查上下文一致性。检索到的文档是否相互矛盾？它们是否与模型可能从参数化知识中声称的内容相矛盾？如果你正在调试特定的故障，可以通过对相同上下文进行多次模型补全采样来测试这一点——高方差标志着上下文冲突或边界违规，而低方差则表明存在提示词歧义或检索失败。

最后，评估知识边界。该查询是否关于模型可靠知识范围之外的事件、事实或现状？这里的关键洞察是，模型无法可靠地自我报告其知识盲点——你必须通过针对训练分布边缘或之外的已知事实进行测试，从外部进行探测。

在用户看到之前进行检测

复盘很有用，但目标是在幻觉到达用户手中之前捕捉到它们。2025 年的生产系统会叠加多种检测方法，因为没有任何一种单一方法足够可靠。

语义熵 (Semantic entropy) 是在无法访问模型内部机制的情况下最科学的方法。其思路是针对同一个查询采样多次补全，然后测量模型回答在语义上的分歧程度。低熵（回答一致）表示模型有信心；高熵则表示模型不确定，这与幻觉的可能性强相关。关键在于测量语义分歧而非 Token 级别的差异——对同一个答案的改写应该被视为一致，而非分歧。

自我一致性检查 (Self-consistency checking) 是相同原理的轻量化实现。对于输出中的关键事实，生成多个独立的答案，并在它们相互矛盾时进行标记。这对于事实性陈述和数值答案的效果出奇地好。这种方法的计算成本较高，因此应选择性地应用于高风险输出。

LLM-as-judge 流程使用第二个模型来评估第一个模型的输出。验证器会检查输出中的主张是否得到检索上下文的支持，以及内部是否一致。在受控评估中，结合特定领域的评分标准，这种方法可以达到约 80% 的 F1 分数，但它增加了延迟和成本——而且评审员模型本身也可能产生幻觉。需要根据误报（拦截了正确答案）与漏报（让幻觉通过）的成本来调整阈值。

检索置信度阈值 是 RAG 系统中最廉价的检测机制。当你的 Top-k 检索结果得分都低于某个阈值时，无论模型如何处理，你都很可能会得到幻觉。在生成之前的检索阶段就标记这些情况，并返回“我没有关于此的可靠信息”的响应，而不是在低置信度下强行生成。用户认为承认不确定性比言之凿凿的编造更值得信赖。

四大类别，四种对策

分类体系之所以重要，是因为每个根本原因都有不同的解决方案，应用错误的修复方法会浪费工程精力。

检索失败 (Retrieval failure) 的对策：改进嵌入模型，添加交叉编码器 (cross-encoders) 进行重排序，结合稠密和稀疏检索（BM25 + 语义搜索），并持续测量代表性查询的检索质量。如果你的检索器带回的是无关文档，再多的提示词工程也救不了你。

上下文冲突 (Conflicting context) 的对策：在生成之前实施矛盾检测（标记包含矛盾事实的上下文集，并解决冲突或交由人工审核），添加一致性细化作为后处理步骤，对于高风险领域，在提示词中显式地解决冲突（“文档 A 说 X，文档 B 说 Y——在你的回答中承认这种不确定性”）。

提示词歧义 (Prompt ambiguity) 的对策：对复杂查询要求结构化输入（模板、必填字段、明确的范围参数），通过测量改写输入后的输出方差来测试提示词稳定性，并在以事实检索为目标时删除诱导推测的语言。像审计代码一样审计你的提示词：寻找歧义、边缘情况和未明确定义的行为。

知识边界违规 (Knowledge boundary violations) 的对策：按主题对查询进行标记，并按领域测量置信度分数，为时效性强的领域实施明确的知识截止免责声明，并为违反边界的查询设计优雅降级——仅返回检索到的上下文而不进行生成，而不是在低置信度下生成。对于基础模型覆盖薄弱的专业知识领域，考虑进行微调或领域适配。

你真正需要的观测栈

如果没有观测手段，这一切都无法运作。在生产环境中拥有最佳幻觉追踪记录的团队都有一个共同的基础设施模式：他们像对待任何其他分布式系统组件一样对待 LLM 调用，拥有完整的链路日志、单次请求元数据和异常检测。

每个 LLM 请求都应该生成一个追踪记录，其中包括：查询、检索到的上下文（带评分）、生成的输出、置信度指标、延迟以及所使用的模型。当检测到幻觉时——无论是自动检测还是通过用户报告——工程师需要能够深入查看完整的追踪记录，以确定哪个阶段失败了。没有这些，你就是在瞎猜。

基于主题的监控被低估了，但非常有效。幻觉率随领域不同而剧烈波动：一个模型可能在通用编程问题上很可靠，但在特定库的版本细节或最近的 API 更改上却不可靠。按主题细分你的监控可以揭示这些故障集群，以便你可以应用针对性的干预，而不是泛泛地修改提示词。

校准偏移 (Calibration drift) 监控是大多数团队在出问题之前都会忽略的一点。模型行为会随着时间而变化——通过微调、通过检索语料库的变动、通过用户群查询分布的变化。一个六个月前校准良好的系统现在可能已经发生了偏移。定期针对留存事实集进行评估，可以在演变为生产事故之前发现这一点。

将其视为一门工程学科

那些已经度过“幻觉危机”阶段的公司拥有一个共同的思维方式：他们将幻觉视为一个可衡量的工程问题，而不是 LLM 固有的缺陷。他们不追求零幻觉（这是不可能的）——他们追求在关键类别中降低幻觉率，并在置信度较低时实现快速检测和透明的降级。

这需要你应用处理任何生产可靠性问题时所采用的相同准则：衡量你的基准、识别主要的故障模式、实施针对性的修复、再次衡量。调试方法论是相同的；仪表化（instrumentation）要求是相同的；复盘（postmortem）文化也是相同的。不同之处在于故障分类学——检索、上下文、歧义、边界——以及针对随机系统（stochastic systems）的特定检测技术。

“模型产生了幻觉”可以留在面向用户的错误提示中，如果你必须以此来缓解冲击。但在你的工程复盘、故障单和回顾中：它永远不是根本原因。它只是调查的起点。

---

幻觉每年在直接事故中给行业造成超过 2.5 亿美元的损失——这一估计还不包括更难量化的信任侵蚀和用户流失。但是，系统性解决这一问题的工具和方法已经存在。在幻觉率可接受的团队与不可接受的团队之间，差距几乎从来不是模型质量。而是工程纪律：记录你需要的、检测你能检测的，并朝着一个具体的、可修复的原因进行调试。