企业官网建设流程全解析

模型一本正经地胡说八道，还说得特别自信，这大概是每个在做 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、采样次数 N=5 的条件下，准确率较高的答案一致性分数基本能到 0.9 以上，幻觉较多的答案一致性分数往往低于 0.6。两者区分度相当明显。

一致性方法还有一个变体，是让模型对同一个问题从不同视角重新生成，比如“请用不同的方式再次回答这个问题”，再比对两次结果的核心要点。这个变体比重复采样更省钱，但效果不如多次采样稳定。值得注意的是，一致性高只是幻觉的必要条件而非充分条件，模型完全可能每次都犯同一个错——这就是“一致性幻觉”，后面我会专门提到。

3.3 外部验证与结构化自检

第三种信号彻底跳出模型自身的判断，转而依赖外部事实源。

把模型回答里的关键断言抽出来，再拿这些断言去检索权威来源，比对是否一致。这个方案在 Agent 场景里天然有优势，因为 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 越大，一致性评估越可靠，但延迟和成本线性上涨。我在实际测试中，N=3 时区分度已经勉强可用，N=5 时效果明显变好，再往上收益就递减了。如果你的场景对延迟敏感，3 次起步可以先跑，后续再调高。

第二个是采样温度。如果温度太低，多次采样的结果几乎一样，一致性分数全部虚高，检测等于失效。我实测在温度 0.7 到 1.0 之间能获得足够多样性，低于 0.5 就不建议用于一致性检测了。

第三个是相似度阈值。判定两份答案“语义一致”的阈值，需要通过人工标注一小批样例来确定。我在某个事实问答场景里把阈值设为 0.82，低于这个值就算不一致。不同场景的答案特征不同，不要照搬别人的阈值。

第四个是工具结果的校验深度。简单方案是对比数值或关键字段是否相等。复杂方案是把工具返回的数据结构做成 schema，逐字段校验类型、范围、枚举是否合法。后者效果好得多，但需要工具侧配合提供规范的结构定义。

5.3 检测到幻觉之后的三种处理策略

检测不是目的，处理才是。我总结过三种常见的处理策略。

第一种是重试。对于低置信度的回答，用更保守的采样参数重试一次，比如把温度降到 0.3，同时追加一句提示“请基于工具返回的结果回答，不确定时请明确说明”。重试在很多情况下能显著提升答案质量，因为第一次生成时可能只是随机选了一条不太稳的路径。但重试成本不低，不能无限制循环，建议最多两次。

第二种是定向修订。如果检测发现的是某个局部断言有问题，比如某个数字与工具返回值不一致，可以针对该断言做局部重新生成，而不是推翻整段回答。这个策略能保住大部分正确内容，只在局部做修正，适合长文本生成的场景。实现上需要先把回答拆分成多个独立断言，逐条校验。

第三种是拒答和降级。当综合置信度过低且重试无效时，直接向用户表明无法回答并解释原因。有些开发者觉得拒答影响体验，但从长期使用的角度讲，一个“知道自己不知道”的系统比一个“永远自信但经常出错”的系统更值得信任。降级则是提供部分可确认的结论，同时明确标注“以下信息未经完整验证”，并附上置信度评分让用户自己判断。

6. 实操中避坑与效果提升记录

6.1 高频问题速查表

在多个项目里反复碰到的坑，我整理成一张速查表，按出现频率排个序。

6.2 几个让我印象深刻的教训

最后写几个让我印象很深的实战教训。

第一个教训是关于“数字类错误”的。有一个业务场景，模型输出的结论里包含大量统计数值。最初用语义一致性做检测，发现一致性分数相当高，因为模型每次都引用同样的错误数据，看起来“胸有成竹”。后来加入了一个简单的联动校验——回答里的关键指标如果和工具返回值的偏差超过一定范围就直接拦截，这类错误才真正被压住。这让我彻底放下了对纯自评信号的依赖。

第二个教训是置信度校准的工作量。有一次我偷懒，直接用模型 logprob 归一化之后定阈值，结果上线后反馈回来大量漏检案例。后来认真做了校准曲线，发现模型在低置信区间的实际正确率比预期低很多，修正后阈值整体往下调，漏检率才降下来。这个校准步骤没法省，数据量不足时至少也要定期做一轮人工抽样标注。

第三个教训是不要把所有幻觉问题都压在检测层解决。检测只能“拦截”问题，不能“修复”问题。后来我在 prompt 层面加了强约束：要求模型在引用工具结果时必须复述原始输出，且每次变换前先指出工具记录的原文。单这一项改动，幻觉出现频率就降了一截。检测层和处理层应该配合，上游少产生幻觉，下游才好治理。

第四个教训是成本预算。全套检测链路（多次采样加外部验证）跑满时，单次请求的 token 消耗大约是无检测方案的四到五倍。一开始没预埋分层设计，全部流量走重检测，账单一出来才发现不可行。后来按任务风险分了三级，只有高风险用户请求才启用完整检测，成本才算可控。

从实际操作的体会来说，幻觉检测和置信度评估这件事没有一劳永逸的解法，它是一个需要持续迭代的工程系统。先把信号接进来，再逐步做校准和分层，效果一定比我讲的任何一种“单点方案”都稳得多。