模型一本正经地胡说八道还说得特别自信这大概是每个在做 Agent 的开发者都撞过的墙。你让 Agent 去查一个订单状态它工具调用返回的是“待支付”最终回答却告诉你“已发货”而且语气笃定得像刚查过物流一样。这就是 Agent 幻觉最典型的样子模型不是不知道正确答案而是它更愿意相信自己“脑补”出来的内容。这篇内容我会把 Agent 幻觉这件事从根上拆开——它到底是怎么产生的业界现在有哪些靠谱的检测手段以及置信度评估在这个体系里扮演什么角色。当然纯讲理论没意思我把自己在真实项目里踩过的坑、试过的方法也一并放进来。如果你是刚接触 Agent 开发不久或者正在被幻觉问题折磨得焦头烂额这篇内容可以当一份实战参考来用。1. 幻觉到底是什么Agent 的几种翻车现场1.1 三类最常见幻觉事实错误、逻辑断裂与上下文脱节说到幻觉很多人第一反应是“模型编造事实”。但在我实际接触过的 Agent 项目里幻觉远不止这一种我更愿意把它分成三类来看。第一类是事实性幻觉。模型给出的事实和真实世界对不上比如回答某个函数库的 API 用法把参数名写错了或者把某产品发布年份报错。这类幻觉最直观也最好理解。第二类是逻辑性幻觉。模型给出的推理链条前后矛盾或者中间某个步骤站不住脚。典型场景是 Agent 做多步任务规划时前面说“先调用接口 A 获取数据”后面又说“根据接口 B 的返回值直接做出判断”但根本没说明为什么 B 的数据能替代 A。这种幻觉不像事实错误那样一眼能看出来但对结果的影响往往更致命。第三类是上下文脱节幻觉。模型没有遵循系统提示或用户给定的约束。你明确告诉它“某一类操作不要执行”它还是做了工具明明返回了 JSON 格式的错误码模型在回答里对错误只字不提直接开始输出自己的推测。这类幻觉在 Agent 场景里出现频率极高因为模型面对的是多轮、多来源的信息很容易“迷失焦点”。我用一个比较通俗的类比来帮助理解模型就像一个记忆力很强但没有常识判断力的实习生。你问他一个你没查过的问题他为了让自己的回答听起来完整会主动把缺失的部分“补”上补得还很流利。正常人会坦诚说“这个我不确定需要查一下”但模型很少主动示弱它的训练目标让它倾向于给出一个看起来很完整的答案。1.2 为什么 Agent 比单次问答更容易出幻觉很多人有疑问单次对话的大模型也会幻觉为什么 Agent 场景更严重我在实际开发中的体会是Agent 把幻觉的“触发面”放大了。单次问答时模型的注意力基本只需要集中在用户的 query 和自己生成的内容上。但 Agent 不一样它需要处理系统提示、用户输入、工具执行结果、中间推理过程、还可能涉及长期记忆检索这些内容一字排开全塞进上下文里模型在生成时对每部分信息的依赖权重并不均衡。最容易出问题的地方就是工具调用结果。模型在预训练阶段见过海量“问题-回答”的文本但“工具返回的字段代表什么含义、该怎么用”这套逻辑在训练数据里并不充分。结果就是模型已经在心里预演好了一个“正确答案”当工具返回的内容和它预演的不一致时它经常会选择性地忽略工具结果继续按照自己的剧本输出。这非常像人脑的“确认偏误”——先有结论再找证据。多步任务还会产生误差累积的问题。Agent 执行一次复杂任务中间可能涉及四五次工具调用、多轮推理。每一步的推理都有一点微小偏差单独看可能无伤大雅但叠到最后整个结论可能已经完全偏离事实。这种误差累积式的幻觉在单次问答里基本不存在所以 Agent 的幻觉治理难度天然更高。2. 幻觉是怎么被“制造”出来的三层根源2.1 数据阶段的先天不足先从最底层的训练数据说起。大语言模型的知识主要来自预训练语料这个语料本身就不是一个可靠的事实数据库。语料里有网页内容、论坛讨论、用户生成内容天然包含了大量错误信息、过时信息和互相矛盾的说法。模型在训练时做的事情是学习这些文本的统计规律而不是像数据库一样做事实校验。所以它在“背诵”知识的同时也把语料里的错误一起学进去了。还有个问题也常被忽略知识截止时间。一个在某时间点前完成训练的模型对之后发生的事情一无所知。如果 Agent 依赖的只是模型参数里的知识用户问一个截止时间之后的事件模型只能靠推断“编”一个答案而且编得越流畅越像真的。这也是为什么现在的 Agent 架构里几乎都会引入外部检索或工具来弥补知识新鲜度的问题但外部信息引入后又会带来新的“该信谁”的问题。数据层面的不足还有一个隐蔽形式长尾知识覆盖不够。模型对热门知识的记忆通常比较牢固比如著名历史事件、常见公理这些在语料中出现频率高。但对专业领域的细粒度问题——某个特定框架的某个冷门参数、某个行业规范的具体条文——模型没见过足够多的相关内容只能靠“泛化”硬猜。硬猜的结果就是我们看到的幻觉。2.2 解码阶段的随机性与过度自信如果说数据问题是“先天不足”那解码机制就是“后天失调”。模型在生成文本时并不是在一本字典里查词而是逐词计算下一个 token 的概率分布。这个分布会受到解码参数的影响。温度参数调高低概率 token 被选中的概率增大输出更发散。Top-p 采样也会让模型在候选词之间做随机选择。这种随机性本来是为了让生成内容更丰富多样但副作用就是同一道问题模型每次生成的答案细节都可能不一样一旦某个概率不太高的 token 被选中后续的推理方向可能整个跑偏。更要命的是模型天然过度自信。语言模型输出“A 是 B”这个句子的时候确实给每个 token 分配了概率但这个概率反映的是“这个词在同类文本中出现的可能性有多大”而不是“这个事实在真实世界中为真的概率”。现实世界里一个说法只有真或假两种状态但模型的输出分布从来没有被训练得和这种真实状态对齐。我做置信度评估项目时对比过一个现象同一段错误的输出其 token 的平均概率未必比正确输出低多少有时候甚至更高。因为错误输出里包含的都是高频词、常见表达这些词的先验概率本来就高。如果不做校准直接拿概率当置信度你会发现模型对错误答案一样可以给出 0.9 以上的高置信度分数。2.3 Agent 架构里特有的累积错误Agent 场景里还有三类架构层面的幻觉催化因素值得单独拿出来说。第一类是系统提示与上下文的信息冲突。系统提示里写了“你是一个只能基于工具结果回答的助手”但用户问题本身已经包含了某些前提假设比如“帮我确认一下 2024 年某活动的举办地点”。如果工具返回的结果里没有涵盖用户问题时模型会自动“调和”两种信息补一个自认为合理的答案这个“补”的动作就是幻觉的开始。第二类是工具调用的格式与语义鸿沟。工具返回的数据通常是一段 JSON 或 XML格式是为机器设计的不是为语言模型设计的。模型需要先“理解”这段结构化文本再把它转化为自然语言表达。在这个过程中字段名含义模糊、嵌套层次复杂、时间格式不统一都会让模型产生错误解读。我见过一个项目里模型把 JSON 中的键名当成字段的实际含义用了键名和实际数据根本不是一回事结果整套回答都建在了错误理解之上。第三类是长期记忆和检索结果的污染。记忆模块里存储的历史信息本身可能包含之前某轮对话中模型产生的幻觉。当 Agent 在后续轮次检索到这段记忆时等于把幻觉当成了事实基础层层叠加虚构越来越牢固。这个现象被很多人称为“自污染”随着对话轮次增加会越来越严重。3. 幻觉检测的三种主流信号3.1 模型自置信度估计从概率到口头表态幻觉检测的第一步是找到能够反映模型“内心确信程度”的信号最常见的就是模型生成时的内在概率。具体做法是模型生成一段回答后把回答拆成 token 序列累计每个 token 的 log 概率再取平均。这个平均 log 概率就是一种自置信度分数。如果这个分数高说明回答中的词基本都在模型的高概率路径上模型“认为”这段回答顺着它的知识分布来写很自然。但注意这里说的是“自然”不是“正确”。另一种自置信度获取方式更直接让模型自己说。在 prompt 里让模型回答时同时输出一个确定程度比如“请回答并给出一个 0 到 1 之间的置信度”。这种方式得到的分数叫口头置信度。实际测试下来有个很有意思的现象模型在表达不确定性时往往比较保守但在错误答案上的口头置信度有时会虚高因为模型如果已经脑补了一个逻辑自洽的答案它自己会先被这个答案说服。纯粹的概率方法和口头置信度都有局限所以现在业界更推荐的做法是把它们当作底层信号再结合其他证据做综合判断而不是单独拿来下结论。3.2 语义一致性同一个问题多问几次自置信度的天然缺陷在于模型对“自己脑补出来的内容”也可能给出高概率。那有没有办法区分“基于知识生成的高概率”和“基于猜测生成的高概率”一个有效的思路是引入随机性做对照实验。这个方案参考了“多次采样一致性”的思路业界流传较广的一个代表性思路是让同一个模型在多次独立采样下回答同一个问题生成多份答案然后两两比较这些答案的语义是否一致。如果模型的多个采样结果在语义上高度一致说明模型的生成路径比较稳定它“心里有底”。反过来如果多次采样结果各说各话说明模型没有稳定的知识支撑只是随机挑了一条路走这类答案出幻觉的概率就很高。我在一个事实问答 Demo 上实测过这个方案。在温度设为 0.8、采样次数 N5 的条件下准确率较高的答案一致性分数基本能到 0.9 以上幻觉较多的答案一致性分数往往低于 0.6。两者区分度相当明显。一致性方法还有一个变体是让模型对同一个问题从不同视角重新生成比如“请用不同的方式再次回答这个问题”再比对两次结果的核心要点。这个变体比重复采样更省钱但效果不如多次采样稳定。值得注意的是一致性高只是幻觉的必要条件而非充分条件模型完全可能每次都犯同一个错——这就是“一致性幻觉”后面我会专门提到。3.3 外部验证与结构化自检第三种信号彻底跳出模型自身的判断转而依赖外部事实源。把模型回答里的关键断言抽出来再拿这些断言去检索权威来源比对是否一致。这个方案在 Agent 场景里天然有优势因为 Agent 的工具链里通常已经包含了检索模块只需要额外加一层“答案反向验证”的流程。比如 Agent 回答了某个指标数值就重新触发一次数据检索看返回结果和回答是否吻合。结构化自检则是从模型自身的推理过程中找破绽。让模型检查自己生成的推理链中是否存在跳跃结论、未经验证的假设或数值上的自相矛盾。实际效果取决于模型自身的推理能力如果模型逻辑能力本身不强自检也容易跟着错但作为成本最低的一道防线做总比不做强。整个信号体系用表格来梳理会更直观。信号名称获取方式典型优缺点适用场景token 平均 logprob生成时记录概率成本低但错误答案也可能高分轻量初筛口头置信度提示词要求输出分数直观但可能存在虚高混合评分的一部分采样一致性多次采样后比对语义校验效果好但延迟和成本高高价值问题的兜底校验外部检索验证抽取断言查证来源事实问题可靠但对主观问题无效事实型 Agent 任务结构化自检让模型自查推理链零额外资源消耗效果受模型能力限制长链路 Agent 任务4. 置信度评估别把“概率高”当成“一定对”4.1 校准置信度与准确率之间的对齐问题做置信度评估绕不开“校准”这个概念。校准的意思是模型给出的置信度数值要和它实际答对的概率对得上。比如置信度 0.8 的答案总体上应该有 80% 左右是对的置信度 0.6 的答案大约 60% 是对的。如果置信度 0.8 的答案正确率只有 60%那就是过度自信系统把大量幻觉答案误放行了。衡量校准质量的常用指标叫 ECE期望校准误差。它在概念上就是把置信度区间划分为若干桶分别统计每个桶内模型平均置信度和实际正确率的差距再做加权平均。ECE 越低说明置信度越可信。我在项目里见过最典型的过度自信样本长这样模型生成的错误答案平均 token 概率是 0.92但这类答案整体正确率只有 74%。也就是说按概率排序时幻觉答案和正确答案混杂在一起阈值完全切不干净。如果直接拿 0.9 当放行阈值你会把将近 30% 的错误答案放进生产环境。校准这个步骤看着抽象其实解决的是一个非常实际的问题在没有任何外部信号的情况下模型给出的数字到底能不能用来辅助决策答案通常是不能直接用必须先做修正。4.2 实操中置信度的计算与融合如果要在一个真实 Agent 系统里落地置信度评估我建议组合多个信号而不是依赖单一指标。一个比较成熟的组合方案包含三个分量。第一个分量是 token 概率的聚合值建议用 logprob 的均值而不直接用概率的几何均值因为直接累乘概率会随着句子长度增加产生数值下溢而且长句子的平均概率天然偏低。第二个分量是采样一致性分数可以通过计算多个采样答案之间的语义相似度获得。相似度计算可以先用嵌入模型把答案向量化再算余弦相似度也可以直接做词重叠统计后者更省资源。第三个分量是工具结果校验分数如果答案中包含调用了工具接口得到的数值就把答案里的数值和工具返回值逐一比对相符得 1 分不符得 0 分。三个分量算出来后用加权平均的方式合并成一个综合置信度。加权系数靠人工调建议一开始给 token 概率和采样一致性各 40% 的权重工具校验给 20%。跑一段时间拿到带标注的分析结果之后再根据实际表现调整权重。我自己经验的优先级排序是有外部校验信号时它的置信度参考价值远高于模型自评信号纯自评信号里一致性比概率更容易区分错误答案。需要特别注意融合之前每一步都要先做归一化不同来源的分数范围通常不一致信号质量差异也很大直接平均会拉低效果。4.3 阈值怎么定误报与漏报的平衡定阈值本质上是在两类错误之间找平衡。阈值定得高放行的答案更可靠但大量可用的正确回答被拦截系统的可用率下降。阈值定得低不会被误拦但幻觉会溜进生产环境。我的建议是先设定两类指标来引导阈值选择。一类是覆盖率阈值之上且实际正确的样本占全部正确样本的比例。另一类是幻觉漏检率阈值之上但实际错误的样本占全部错误样本的比例。理想情况下覆盖率越高、漏检率越低越好但两者往往互相牵制。实际操作中先在评测集上计算每个候选阈值对应的指标画一条“阈值-漏检率/覆盖率”曲线再结合业务容忍度选点。比如客服场景幻觉带来的负面影响是误导用户通常更严格而闲聊或头脑风暴场景错一两个没关系可以放宽阈值。我常用这样一个三层路由策略综合置信度高于 0.9 的回答直接返回0.7 到 0.9 之间的进入二次校验流程触发外部检索或者工具复验低于 0.7 的回答走拒答或澄清流程向用户说明无法确认信息请用户提供更多细节或自行核实。这套策略在事实型问答 Agent 上实际跑下来在保持约 90% 答案可用率的前提下人工审计出来的明显幻觉比例降到了原来的 1/3 以下。5. 落地一套幻觉检测链路从设计到实现5.1 检测链路的基本结构讲完理论我来拆解一个可以在工程上实现的检测链路。检测模块的输入是 Agent 生成的回答和中间过程信息输出是一个路由决策。链路分为信号采集、综合评估、决策路由三层。信号采集层负责收集上一节提到的几个底层信号。这里最需要注意的是采集动作不要干扰 Agent 原本的主链路。生成 logprob 在模型推理时顺手就能保存几乎零成本。但多次采样需要额外调用模型会显著增加延迟和 token 开销所以要通过开关控制只有高价值任务才启用。综合评估层把原始信号加工成标准化的分数。首先是清洗去掉无意义的填充段落、工具返回的原始 JSON 文本等噪声内容。然后是归一化把不同量纲的分数映射到 0 到 1 区间。最后是融合按权重合成综合置信度分数。决策路由层根据综合置信度和旁路规则输出最终动作。旁路规则可以覆盖一些特殊情况比如答案检测到明确的自相矛盾表述时直接打回或者涉及高危操作扣费、删除数据时即使置信度高也要求人工复核。5.2 关键模块的配置与权衡在真实落地里有几个配置参数需要认真取舍我逐一说明。第一个是采样次数 N。N 越大一致性评估越可靠但延迟和成本线性上涨。我在实际测试中N3 时区分度已经勉强可用N5 时效果明显变好再往上收益就递减了。如果你的场景对延迟敏感3 次起步可以先跑后续再调高。第二个是采样温度。如果温度太低多次采样的结果几乎一样一致性分数全部虚高检测等于失效。我实测在温度 0.7 到 1.0 之间能获得足够多样性低于 0.5 就不建议用于一致性检测了。第三个是相似度阈值。判定两份答案“语义一致”的阈值需要通过人工标注一小批样例来确定。我在某个事实问答场景里把阈值设为 0.82低于这个值就算不一致。不同场景的答案特征不同不要照搬别人的阈值。第四个是工具结果的校验深度。简单方案是对比数值或关键字段是否相等。复杂方案是把工具返回的数据结构做成 schema逐字段校验类型、范围、枚举是否合法。后者效果好得多但需要工具侧配合提供规范的结构定义。5.3 检测到幻觉之后的三种处理策略检测不是目的处理才是。我总结过三种常见的处理策略。第一种是重试。对于低置信度的回答用更保守的采样参数重试一次比如把温度降到 0.3同时追加一句提示“请基于工具返回的结果回答不确定时请明确说明”。重试在很多情况下能显著提升答案质量因为第一次生成时可能只是随机选了一条不太稳的路径。但重试成本不低不能无限制循环建议最多两次。第二种是定向修订。如果检测发现的是某个局部断言有问题比如某个数字与工具返回值不一致可以针对该断言做局部重新生成而不是推翻整段回答。这个策略能保住大部分正确内容只在局部做修正适合长文本生成的场景。实现上需要先把回答拆分成多个独立断言逐条校验。第三种是拒答和降级。当综合置信度过低且重试无效时直接向用户表明无法回答并解释原因。有些开发者觉得拒答影响体验但从长期使用的角度讲一个“知道自己不知道”的系统比一个“永远自信但经常出错”的系统更值得信任。降级则是提供部分可确认的结论同时明确标注“以下信息未经完整验证”并附上置信度评分让用户自己判断。6. 实操中避坑与效果提升记录6.1 高频问题速查表在多个项目里反复碰到的坑我整理成一张速查表按出现频率排个序。现象根因处理建议采样一致性很高但答案依然错误模型存在稳定的系统性偏好引入外部验证信号不要单靠一致性置信度阈值无论怎么调都切不干净校准不到位概率分布偏移先对置信度做校准再重新定阈值重试之后答案还是错的重试只是在同一前提下打转更换重试策略加入约束性提示或外部信息工具结果和回答数值对不上但检测没发现校验逻辑只对比了数值是否相等检查字段含义和单位建立字段映射关系检测模块拖慢了整体响应每次都做多次采样和外部验证按任务价值分级低风险任务只做轻量检测长答案局部错误全被漏掉全局置信度被其他部分的正确内容拉高把回答拆成多个断言逐条计算置信度6.2 几个让我印象深刻的教训最后写几个让我印象很深的实战教训。第一个教训是关于“数字类错误”的。有一个业务场景模型输出的结论里包含大量统计数值。最初用语义一致性做检测发现一致性分数相当高因为模型每次都引用同样的错误数据看起来“胸有成竹”。后来加入了一个简单的联动校验——回答里的关键指标如果和工具返回值的偏差超过一定范围就直接拦截这类错误才真正被压住。这让我彻底放下了对纯自评信号的依赖。第二个教训是置信度校准的工作量。有一次我偷懒直接用模型 logprob 归一化之后定阈值结果上线后反馈回来大量漏检案例。后来认真做了校准曲线发现模型在低置信区间的实际正确率比预期低很多修正后阈值整体往下调漏检率才降下来。这个校准步骤没法省数据量不足时至少也要定期做一轮人工抽样标注。第三个教训是不要把所有幻觉问题都压在检测层解决。检测只能“拦截”问题不能“修复”问题。后来我在 prompt 层面加了强约束要求模型在引用工具结果时必须复述原始输出且每次变换前先指出工具记录的原文。单这一项改动幻觉出现频率就降了一截。检测层和处理层应该配合上游少产生幻觉下游才好治理。第四个教训是成本预算。全套检测链路多次采样加外部验证跑满时单次请求的 token 消耗大约是无检测方案的四到五倍。一开始没预埋分层设计全部流量走重检测账单一出来才发现不可行。后来按任务风险分了三级只有高风险用户请求才启用完整检测成本才算可控。从实际操作的体会来说幻觉检测和置信度评估这件事没有一劳永逸的解法它是一个需要持续迭代的工程系统。先把信号接进来再逐步做校准和分层效果一定比我讲的任何一种“单点方案”都稳得多。