几乎所有用过大模型的人都遇到过幻觉。它会编一个不存在的论文给一个看起来很真的 API用很肯定的语气解释一个其实错了的结论甚至把一段没有发生过的历史讲得有时间、有地点、有因果。很多人把这件事简单归因为“模型不准”。这个说法不算错但太粗了。因为它没有解释三个更关键的问题为什么模型会把错误说得这么像真的为什么同一个问题有时候答得很好有时候又会胡说为什么加了 RAG、工具、长上下文以后幻觉还是没有完全消失一句话先压住幻觉不是模型偶尔坏掉而是大语言模型的生成方式、训练目标、上下文材料和系统边界共同作用的结果。如果你把大模型当成数据库它就很容易让你失望。它不是在硬盘里查一条事实再返回给你而是在给定上下文里预测下一段最可能出现的文本。这个机制很强因为它能泛化、能推理、能写作、能迁移。它也有代价当材料不足、边界不清、验证缺失时它会生成“看起来合理”的答案而不是自动停下来承认不知道。所以理解幻觉不能只看模型。要同时看训练、推理、上下文、工具和产品设计。模型不是知识库而是概率生成器先从最底层说起。大语言模型训练时做的核心任务是根据前面的 token 预测下一个 token。你可以把它理解成一种极其复杂的补全系统给它一段上下文它判断后面最可能接什么。这并不意味着它“只会接龙”。规模足够大以后预测下一个 token 会逼出很多能力语法、事实、常识、推理模式、代码结构、写作风格、任务格式。因为要预测得好模型必须在参数里压缩大量关于世界和语言的统计规律。但这里有一个关键差别模型学到的是“什么文本在什么上下文里更可能出现”不是“哪一条事实在外部世界里一定为真”。比如你问某某公司 2028 年发布的 X 系统有哪些核心功能如果这个系统不存在理想回答应该是“我没有可靠信息。”但从文本生成角度看问题本身很像一个正常的技术介绍请求。模型可能会根据类似产品的常见功能生成一组看起来合理的模块权限管理、数据同步、智能分析、自动化流程、监控面板。这些内容可能都“像真的”因为它们符合技术文章的语言模式。但它们不一定是真的。这就是幻觉的第一层来源语言合理性不等于事实真实性。人类读者很容易被流畅文本骗过。因为我们习惯把清晰、有结构、有术语的表达和“懂”绑定在一起。但对模型来说流畅只是生成目标的一部分。它可以在没有事实支撑时继续保持流畅。为什么模型不直接说“不知道”很多人会问既然不知道为什么不承认原因也不复杂默认训练目标并不天然奖励“停下来”。预训练阶段模型看到的大量文本都是问题后面接答案、标题后面接正文、代码注释后面接实现。它学到的基本倾向是补全而不是拒答。后面的指令微调和人类反馈会让模型更会遵守指令也更愿意表达不确定性。但这只是改变倾向不是给模型装了一个完美的事实检测器。尤其在下面几类场景里模型更容易硬答用户的问题形式非常像常规问答问题里暗示某件事已经存在上下文里有一些相似但不完全相关的材料用户要求“详细说明”“列出步骤”“给出参考”系统没有要求模型先验证再回答没有工具可以查证或者工具结果没有被正确使用。比如用户问“A2A 取代 MCP 后企业应该怎么迁移”这个问题本身已经塞进了一个前提A2A 取代了 MCP。模型如果没有认真检查前提就可能顺着这个前提继续写迁移方案。这类幻觉不一定是模型不知道概念而是它没有把“检查问题前提”当成当前任务的第一步。所以很多幻觉不是从答案开始错而是从问题里的假设开始错。幻觉有好几种不是一种病工程上讨论幻觉最好先把类型分开。不同类型的原因和解决办法不一样。第一类是事实型幻觉。模型编造论文、作者、时间、公司产品、法律条文、API 参数、命令选项都属于这一类。它的问题是外部事实没有被可靠查证。第二类是引用型幻觉。模型给出看起来很正式的参考资料、链接、文件路径、章节编号但这些引用并不存在或者存在但内容对不上。这在写研究综述、法律分析、技术文档时特别危险。第三类是推理型幻觉。材料是真的但模型中间推理错了。它可能漏掉一个条件混淆因果把相关性当成必然性或者在多步计算里走偏。第四类是上下文型幻觉。模型没有外部编造而是误读了你给它的材料。比如把旧版本文档当成当前版本把错误日志里的历史失败当成最新失败把用户提供的反例当成规则。第五类是工具型幻觉。模型声称“已经查询过数据库”“测试已经通过”“文件已经修改”但实际工具没有执行、执行失败或者返回结果不是它说的那样。Agent 场景里这类问题非常常见。第六类是边界型幻觉。模型把自己不能做的事说成能做把没有权限的动作说成已经完成把估计说成结论把建议说成事实。这些问题表面都叫幻觉但根因不一样。你不能用一个 prompt 修所有问题。事实型幻觉需要检索和引用。推理型幻觉需要分步验证。上下文型幻觉需要上下文管理。工具型幻觉需要 Harness 记录真实执行结果。边界型幻觉需要产品层的权限和状态设计。RAG 为什么不能彻底消灭幻觉很多人以为只要加了 RAG模型就不会幻觉。这个判断太乐观了。RAG 解决的是“模型回答时有没有拿到相关资料”。但从资料到答案中间还有很多环节会出错。第一检索可能没找对。向量召回看的是语义相似不是事实等价。用户问“退款规则”系统可能召回“退货规则”用户问“最新接口”系统可能召回旧版本文档用户问一个边界条件召回结果可能只覆盖常规流程。第二资料可能互相冲突。企业知识库里经常同时存在旧文档、新文档、草稿、会议纪要、客服口径。模型看到多份材料后如果系统没有告诉它优先级它可能自己拼一个折中答案。第三模型可能不用资料。有些回答里模型会先被自己的先验带跑再选择性引用上下文。它不是恶意而是生成过程本来就会把上下文和参数知识混在一起。第四资料可能被污染。如果外部网页、用户输入、工单内容里混入提示注入模型可能把“忽略之前规则”这类文本当成指令而不是当成待分析材料。第五答案缺少可验证引用。即使检索到了正确片段如果最终回答没有标注依据用户也无法判断哪些结论来自资料哪些是模型推断。所以 RAG 不是“防幻觉开关”。更准确地说RAG 降低了模型缺材料时编答案的概率但它没有自动解决检索质量、材料冲突、引用约束和答案验证。一个比较可靠的 RAG 系统通常不只是向量数据库加模型而是还要有 query rewrite、metadata filter、rerank、版本优先级、引用校验、答案约束和失败兜底。长上下文也不是万能药另一个常见误解是既然模型上下文越来越长那把所有材料都塞进去就行了。长上下文确实有价值。它减少了切分和召回带来的信息丢失也让模型能直接比较多份材料。但长上下文不等于无限注意力。材料越多噪声也越多。模型可能在前文看到一个过期规则在后文看到一个新规则然后没有正确处理优先级。它也可能因为上下文太长忽略中间某个关键限制。长上下文更像是给模型一个更大的桌面不是给它一个自动整理好的资料室。如果你把所有日志、所有文档、所有历史对话都堆上去模型仍然需要知道哪些材料是最新的哪些材料可信度更高哪些材料只是用户输入不是系统规则哪些材料是失败输出不应该当成事实哪些内容必须引用哪些只能作为背景答案应该在材料不足时停止而不是猜。这就是 Context Engineering 的位置。它不是简单扩上下文而是决定什么信息在什么时候以什么结构进入上下文。Agent 里的幻觉更危险普通 Chatbot 幻觉最坏通常是答错。Agent 幻觉可能会做错。因为 Agent 不只生成文本它还会调用工具、修改文件、查数据库、发消息、触发流程。只要模型把“我觉得应该这样”变成动作幻觉就会进入现实系统。比如一个代码 Agent 看到测试失败误判根因然后改了错误模块。一个客服 Agent 误读退款规则给用户承诺了不该承诺的补偿。一个数据 Agent 把 SQL 查询结果解释错生成了错误经营结论。一个运维 Agent 把告警噪声当成根因重启了不该重启的服务。这类问题不能只靠“请你谨慎”解决。因为模型即使谨慎也需要系统给它边界。好的 Agent Harness 至少要做几件事工具真实执行结果必须回填不能让模型凭空声称完成高风险动作要人工确认读写权限分开默认只读每一步动作要有 trace关键结论要绑定证据连续失败要停止而不是循环尝试最终输出要区分事实、推断和建议。Agent 的幻觉治理本质上是软件工程问题。模型只是其中一个环节。怎么减少幻觉完全消灭幻觉不现实但可以显著降低概率和影响范围。第一明确要求模型区分事实和推断。不要只说“回答准确一点”。更好的约束是“只基于给定材料回答材料没有覆盖时说不知道推断必须标注为推断。”第二给模型可靠材料而不是只给问题。事实密集型任务不要裸问模型。用检索、数据库、文档、工具把答案依据放进上下文。第三要求引用来源。尤其是法律、财务、医疗、技术 API、公司制度、学术综述。没有来源的结论最多只能当草稿。第四把工具结果和模型表述解耦。工具返回什么系统就记录什么。模型可以解释工具结果但不能伪造工具结果。第五对高风险输出做验证。代码要跑测试SQL 要限制权限金额要二次校验外发内容要人工确认重要事实要二次检索。第六设计“不知道”的出口。很多系统只设计了成功路径没有设计材料不足时怎么回答。结果模型只能硬编。一个可靠系统应该允许模型返回信息不足、需要更多材料、需要人工判断。第七保留失败样本做 eval。幻觉不是靠感觉优化的。把真实出错案例做成评测集每次改 prompt、改检索、换模型都跑一遍。一个比较实用的判断当你看到一次幻觉不要先问“模型为什么这么笨”。先问四个工程问题第一模型回答这个问题时有没有拿到足够材料第二材料里有没有冲突、过期、噪声或注入第三系统有没有要求它引用依据和承认不确定第四答案有没有经过工具、规则或测试验证如果这四个问题都没有处理好幻觉不是意外而是迟早会发生。很多 AI 应用的失败不是因为模型能力完全不够而是因为系统把模型放在了一个“必须猜”的位置上。模型不知道事实却被要求给确定答案。模型没有工具却被要求确认最新状态。模型没有权限信息却被要求判断能不能执行。模型没有测试结果却被要求保证代码正确。这种设计里幻觉不是模型的异常行为而是产品的默认路径。最后总结一下大模型幻觉不是一个单点问题。它来自模型的概率生成机制来自训练目标对流畅回答的偏好来自上下文材料不足或污染来自检索和工具链的不可靠也来自产品没有给“不知道”和“待验证”留下出口。所以解决幻觉也不能只靠一句 prompt。更可靠的做法是让模型少猜一点让系统多验证一点。事实问题给来源工具动作给记录高风险决策给确认长期优化靠 eval。一句话总结幻觉不是要靠模型“变诚实”才能解决而是要靠系统不要逼模型在没有证据时装作确定。