幻觉

一句话理解：幻觉是模型生成了“看起来合理但不真实”的内容；它无法被彻底消除，只能通过“给事实来源、允许说不知道、要求引用、由程序验证”层层压低，并按风险决定哪些输出必须经过核查。

在 Chatbot 里，幻觉是一句错话；在 Agent 里，幻觉可能是一个错误的退款、一封发给客户的错误通知，或者一句“已为您成功修改订单状态”——而实际上什么都没发生。能执行动作的系统，对幻觉的容忍度要低得多。

好消息是，幻觉不是玄学。理解它从哪里来，就能在产品设计的每一层放上对应的防线。

下图把本课要讲的防线串成一条链路：

幻觉从哪里来

回到 LLM 如何工作 的核心：模型预测的是“最像会出现的下一段文字”，而不是查证后的事实。以下几种情况最容易出问题：

诱因	发生了什么	客服 / 销售场景中的例子
知识缺失	问题超出训练数据，模型用“合理的样子”补齐	编造一条内部系统里并不存在的订单状态
知识模糊	见过相关内容但记不精确	把某项退换货政策的时限记错
被问题带偏	问题里的错误前提被当成事实接受	“为什么这笔订单被系统取消了？”（其实没有取消）
上下文不足或过载	需要的数据没给，或被大量无关内容淹没	订单日志只给了前 20 条，模型推断“一直没人处理”
倾向给出完整答案	后训练让模型更愿意回答而不是说“不知道”	查不到支付记录时仍给出“已支付”的结论
长链推理累积误差	早期一步小错被后续步骤放大	算错了一个环比，最终归因全部跑偏

对 Agent 来说，还有两种特有的幻觉值得单独点名：

• 动作幻觉：声称调用了工具或完成了动作，实际上没有调用、调用失败，或参数不对。
• 结果幻觉：工具返回了数据，但模型在总结时“改写”了事实，例如把“预计 9 月 18 日发货”说成“已发货”。

防线一：让事实有来源

最根本的办法是 不让模型靠记忆回答事实性问题。

• 工具优先：订单状态、库存、价格、支付记录，一律通过工具实时查询，见 工具调用。
• 检索增强：制度、手册、产品文档通过 RAG 检索相关片段放进上下文。
• 限定知识范围：在指令里明确“只依据提供的数据与文档回答，不使用你的一般知识补充事实”。
• 长文档先摘引再分析：Anthropic 官方建议，处理长文档时先让模型逐字摘出相关原文，再基于摘录完成任务，用原文把回答“钉住”。

一个客服场景的指令片段：

<rules>
- 订单状态、发货记录、支付信息只能来自工具返回的结果，不要根据经验推测。
- 如果工具没有返回某项信息，明确写“系统中未查到该信息”，不要补全。
- 给出问题原因时，逐条列出支撑它的订单记录（时间 + 事件）。
</rules>

防线二：允许“不知道”，并把它设计成产品路径

模型倾向于给出完整答案，一个原因是它很少被明确允许“不回答”。官方文档把“允许 Claude 说不知道”列为最基础的降低幻觉策略。但只在提示词里写一句还不够，拒答要成为产品里的一条正式路径：

在 结构化输出 里，这体现为 无法判断 这样的枚举值、confidence 字段和 need_human_review 标记。在界面上，它体现为清晰的“未能确认”状态，而不是一句含糊的道歉。

防线三：引用与验证

引用让结论可追溯。 要求模型为每个结论标注来源，是让人和程序都能核对的前提。Claude API 提供了原生的 Citations 功能：在 document 内容块上设置 citations: {"enabled": true}，返回的文本会附带引用信息，包括被引用的原文 cited_text 和它在文档中的位置。官方说明引用指针保证指向你提供的文档，但请注意：引用真实存在，不等于结论正确理解了原文，关键场景仍需核对。另外，Citations 与结构化输出不能同时开启，否则返回 400。

验证让错误在执行前被拦下。 按可靠性从高到低排列：

验证方式	例子	可靠性
程序校验	结论里的订单号、金额、时间必须在工具结果中存在	高，优先使用
动作结果回读	声称改了工单状态，就再查一次工单确认	高，Agent 必备
交叉核对	同一问题多次生成或用不同来源比对，不一致即标记	中
模型自查 / 模型互评	让另一个调用逐条找原文支撑，找不到就删除该结论	中，适合文本类输出
人工审核	高风险输出进入审批队列	高，但成本高

以 SEO 诊断 Agent 为例，模型报告“页面缺少 meta description”时，程序可以直接解析 HTML 验证这一条是否属实，几毫秒就能完成，比任何提示词技巧都可靠。验证的系统方法见 验证与错误恢复。

按风险分级处理

不是所有输出都需要同等力度的防护。按“出错的代价”分级：

风险等级	输出类型	建议的防线组合
低	头脑风暴、文案初稿、内部摘要	基本指令 + 用户自行判断
中	给客户的解释、分析报告、诊断建议	工具 / 检索提供事实 + 引用 + 允许不知道
高	金额、承诺、合规结论、会触发执行的判断	以上全部 + 程序校验 + 人工审批

高风险动作的审批设计见 Human-in-the-loop。

常见误区

• “换一个更强的模型，幻觉问题就解决了。” 更强的模型确实更少编造，但机制没变。只要系统依赖模型记忆事实、没有验证，就一定会在某个比例上出错。
• “在提示词里写‘不要编造’就够了。” 这句话有帮助，但远远不够。模型并不总能分辨自己在编造，必须提供事实来源和外部验证。
• “有引用就可信。” 引用证明来源存在，不证明理解正确。关键结论要核对引用内容是否真的支持结论。

产品经理检查清单

• 这个功能中，哪些输出是事实性的？每一类事实从哪里来：工具、检索，还是模型记忆？
• 当数据缺失时，产品期望的行为是什么？界面上如何呈现“无法确认”？
• 哪些结论需要附带引用或证据？用户在哪里能查看？
• 哪些输出在交给用户或触发执行前必须经过程序校验？校验规则是什么？
• 评测集里是否包含“应该拒答”的用例？拒答率和错误回答率是否都在监控？

练习

为「公司知识库 Agent」做一次幻觉压力测试（约 60 分钟）：

1. 准备一份 2–3 页的内部文档（例如退换货政策）。
2. 设计 10 个问题：4 个文档中有明确答案，3 个文档中没有答案，3 个带有错误前提（例如“为什么定制商品可以 30 天无理由退货？”，而文档规定不可以）。
3. 先用最简单的提示词测试，记录编造和被带偏的次数；再加入“只依据文档、允许说不知道、每个结论附原文引用”的指令重测。
4. 对比两轮结果，写下还有哪些错误必须靠程序校验或人工审核才能拦住。

延伸阅读

• Reduce hallucinations：允许不确定、先摘引再分析、引用核验等官方策略。
• Citations：Claude 原生引用功能的用法与限制。

下一步

除了文本，Agent 还经常需要读图片、PDF 和屏幕截图。下一课「多模态」讲这些内容如何进入模型，以及它对 Agent 意味着什么。