企业官网建设流程全解析

AI Agent的幻觉问题及解决方案

打开我的编辑器准备写这篇复盘时，我想起上个月某个智能客服项目上线前，测试同学甩给我的一张截图。用户问的是你们平台支不支持API接入，Agent一本正经地回答我们平台深度集成了区块链溯源和联邦学习技术。先不说用户一脸懵，光是那个虚构功能，就够我们开发组在需求评审会上反复解释三遍。那个场景之后，我就决定把团队在幻觉问题上踩过的坑、试过的办法完整整理出来。这篇文章不聊泛泛的原理，只聊我们在实际项目中怎么定位、怎么治理、怎么验证，希望能让同样被幻觉折腾的团队少走几步弯路。

1. 幻觉问题的本质拆解：它到底错在了哪里

1.1 幻觉不只是说谎这么简单

很多人一提幻觉，第一反应是模型在撒谎。但实际上，幻觉在AI Agent里的表现远比单车撒谎复杂得多。我习惯把幻觉分为三类：

第一类是事实性幻觉，模型生成的内容与已知事实相悖。比如用户问北京到上海的直线距离，Agent回答约2000公里，实际数据应该是1084公里。这种最直接，也最容易通过知识库检索来缓解。

第二类是忠实性幻觉，模型没有遵循用户指令或上下文约束。用户明确说不要推荐价格超过5000元的商品，Agent却在推荐清单里放进去一台8000元的笔记本。这种问题不完全是模型知识错误，更多是指令跟随能力没到位。

第三类是逻辑性幻觉，模型的推理过程或步骤之间存在断裂。比如Agent分析某公司营收增长原因，先说A产品线贡献最大，后面总结时又说B产品线是主要推力，前后的因果链完全对不上。

这三类幻觉在真实场景中经常交织出现在同一段回答里，给排查带来不小麻烦。如果不把幻觉的类别先拆清楚，后面做方案选型很容易走偏。

1.2 幻觉产生的核心根源：概率生成与信息压缩

要说为什么大模型会产生幻觉，得从它的工作机制说起。基于Transformer架构的语言模型，本质上是一个概率系统，它在每个token生成位置上计算整个词表上的概率分布，然后采样或选取最优token。也就是说，模型输出的是最可能的词，而不是经过验证的真实答案。

这和人类写回忆录有些相似。回忆的本质是对过去信息的压缩与重构，每次回忆都会融入当下的经验和情绪。当Agent生成回答时，它在高维空间里检索训练阶段学到的参数化记忆，这个过程天然存在信息损失。知识一旦被压缩进模型权重，保存的就不再是原始数据，而是一个统计分布。分布覆盖不到的地方，模型就会拿邻近概念来顶替，于是幻觉就出现了。

还有一个关键点常被忽视，Agent的幻觉会和工具调用互相放大。Agent先判断需要调取外部数据，这是Request阶段；模型生成工具参数时产生错误，这是参数幻觉；工具返回数据后，Agent在Summarize阶段概括错误，形成二次幻觉。所以AI Agent的幻觉治理，不能只看最后生成的文本，还要盯住全链路各个环节。

1.3 为什么AI Agent的幻觉比普通对话幻觉更危险

单纯的ChatGPT产生幻觉，影响是用户得到了一段不可信的文字。AI Agent产生幻觉，影响会通过工具调用直接作用于真实系统。比如让Agent查询订单状态，参数写错了单号，业务系统可能返回错误信息；让Agent自动发送营销邮件，幻觉生成的客户名称如果不在库里，可能导致发送失败甚至误发。

我参与过的一个自动化报表项目里，Agent在拼SQL时虚构了一个数据库中不存在的字段，最初的版本没有做SQL校验，结果跑出来的报表数据全错了。这种幻觉就不只是文字问题，它扩展到了数据层和业务层，治理难度指数级上升。

所以做AI Agent不是把大模型接上API就完事，幻觉治理应该被当做一个安全工程来做。

2. 幻觉治理的技术路线全景：从源头到集成层的四级防线

2.1 第一道防线：优化模型本身的约束能力

刚开始接触幻觉问题时，我的第一反应是换更强的模型。说实话，模型基础能力确实是幻觉率的一个决定因素，但不是唯一因素。即使是最新的大模型，在缺乏外部知识支撑的开放领域里，照样会自信地编造内容。

模型层面的治理手段大致有这几种：

一是微调。用一批针对特定领域的优质数据对模型进行继续训练，让模型学会在不知道答案时承认不知道，而不是强行生成。我在一个法律咨询项目里做过类似微调，训练数据中加入了大量无法回答的问题样本，模型学会了输出需要核实后再回复。这里有个关键点，微调数据质量要远重要于数量，数据里如果残留了幻觉样本，模型会学得更像。

二是提示词约束。这是最轻量的办法，在各家接口的system prompt里写明：只能基于以下参考内容作答，若没有相关信息，请明确回复信息不足。这种约束有效，但只能降低概率，不能消灭幻觉。我实测过，即使加了严格的指令，模型在小概率下还是会自作主张补全信息。

三是解码参数调整。把temperature调低，比如调到0.1甚至0，模型倾向于选择高概率token，幻觉率会明显下降。但低温也会带来副作用，回答变得机械和保守，一些开放式任务的效果会变差。

这层防线的作用是降低幻觉发生的概率，而不是彻底解决。真正要彻底解决，需要把重心放在后三层。

2.2 第二道防线：知识检索增强生成（RAG）

RAG几乎是当前AI Agent解决事实性幻觉的标配方案。核心思路是：不让模型凭参数化记忆作答，而是先检索外部知识库，把检索到的资料和用户问题一起交给模型生成回答。

我在一个电商知识库项目里用RAG做过对比测试。只用模型直接回复，领域问题的正确率约为76%；接入RAG后，同等模型在相同测试集上的正确率提升到92%。幻觉率从14%下降到不足4%。效果明显，但不是没有坑。

RAG最关键的环节是检索质量。如果检索出的文档与问题无关，模型要么拒绝回答，要么被迫基于错误上下文生成，幻觉率反而上升。这里有几个实操要点：

第一，切分粒度要合适。一个大文件直接丢给向量模型，检索容易把不相关的内容混进来。切得太碎，比如一句话一段，又容易丢失上下文语义。我通常的做法是把文档按语义段落切分，每段控制在200到500个token之间，同时用标题层级做父子结构，让检索结果带上上层上下文。

第二，重排技术一定要加上。向量数据库检索出的TopK结果只是初步候选，直接用Top1或Top5送入大模型往往不是最优。我会接一个重排序模型，重新计算候选文档和问题的相关性，再把最高分文档送入生成。实测重排后，回答准确度能再涨三到五个点。

第三，检索源的准入过滤要做。我见过一个项目，把所有互联网页面都灌进知识库，结果聊天气派的Agent在购物推荐场景里从一篇旅游攻略里扒出景点门票价格来推荐商品。源头脏，后面再强的模型也救不回来。

2.3 第三道防线：Agent工作流的确定性改造

RAG解决了知识来源问题，但Agent执行过程中的决策路径还会引入幻觉。尤其是Agent自由调用工具时，模型自行决定调用哪个工具、传什么参数，这种自由本身就是幻觉重灾区。

解决思路是把Agent的工作流尽量改造成可控制的编排模式。我把它称为从Full-Auto模式向Semi-Auto模式的收敛。

拿一个典型场景举例：用户要求Agent查询物流信息。Full-Auto模式下，Agent自行规划步骤：分析问题、选择工具、生成参数、调用API、整理结果。只要参数生成这一步出问题，后续全是错的。Semi-Auto模式则是预先设计好节点，先让Agent做意图分类，再根据分类路径走固定的工具调用模板，参数用规则校验后再放行。

我在一个内部物流查询Agent项目里做了这种改造。原来是Agent自由调用物流查询接口，参数来自模型的自然语言理解，结果偶尔把运单号识别成其他数字。改造后，运单号先经过正则规则校验，长度、格式符合标准才允许调用查询接口，否则直接返回请输入正确的运单号。这个改动让查询成功率从80%出头提升到了98%以上。

这种确定性改造的本质，是把高风险的自由生成环节替换成可控的逻辑判断。Agent仍然负责理解和表达，但关键操作必须经过规则闸门。

2.4 第四道防线：输出侧的多维校验

就算前面三道防线全做了，模型仍然有小概率漏出幻觉内容。所以输出侧校验不是可选项，而是必须项。

输出校验的思路是：模型生成完之后，我们再拿另一个校验器去检查它。这个校验器可以是规则引擎，也可以是另一个模型，通常叫验证器或Judge。验证器做两件事：一是检查生成内容是否忠实于给定的参考上下文；二是检查生成内容是否与已知事实矛盾。

具体落地时，我在项目里常用三种校验方式：

第一种是规则校验，适合有明确格式约束的场景。比如生成的结果是JSON结构，规则里检查字段是否存在、类型是否正确、枚举值是否合法。这种校验成本低、速度快，能在毫秒级拦截明显的结构性幻觉。

第二种是上下文忠实度校验。把模型生成的回答和它引用的参考文档做语义相似度对比，如果回答中的关键信息在参考文档中找不到对应表述，就判定存在幻觉风险。可以专门用NLI模型判断回答是否被参考文档蕴含，也可以用大模型自身当判官，让模型检查回答有无超出参考范围的内容。

第三种是事实数据库比对。适合结果可以被结构化信号验证的场景。比如Agent生成了一个城市人口数据，校验器直接查统计年鉴数据库，对不上就拦截。

这套多维校验体系我们搭完之后，测试集上的最终幻觉率降到了1%以下。代价是增加了响应延迟和算力开销，所以实际部署时要根据场景做取舍。

3. 实战记录：一个零售行业AI Agent的幻觉治理全流程

3.1 项目背景与症状

去年底，我给某区域连锁零售企业做智能导购Agent，产品形态是小程序里的对话式购物助手。用户问什么值得买、有没有优惠、这个店铺营业到几点，Agent来回答。

上线第一周，运营同学就反馈了几个问题。用户问某款奶粉有没有货，Agent回答说有货，可用户下单时系统提示缺货。用户问门店营业时间，Agent回答早上九点到晚上十点，实际上门店是早上十点开门。用户问周末有什么活动，Agent照着知识库里上上个月的活动方案回答，里面的商品都已经下架了。

这类问题在传统文档问答里不常见，在我们这个Agent里却扎堆出现。因为Agent不只是问答，它还要理解门店、库存、价签、促销计划，全都有动态变化。静态知识库根本覆盖不了。

3.2 第一轮改造：接入实时数据源和RAG

我先是给Agent接了实时库存接口，把库存查询从知识库搬到了API调用。同时保留商品简介、门店信息这些偏静态的数据在RAG知识库中。

这个改动很直接，原本静态的知识库变成了动态数据的API调用加知识库的双通道。用户问在不在货，Agent去查实时库存；用户问商品参数，Agent去知识库检索。两边的结果再一起喂给生成模块。

这一轮改造后，缺货误报的问题基本消失，门店营业时间因为来源于API，也准确了。但新的问题又暴露出来。

3.3 第二轮改造：记住对话中的上下文约束

用户连续提问时，Agent的上下文管理出现了幻觉。一个典型场景是，用户先说我要买200元以内的保温杯，然后问哪个牌子保温效果好，Agent推荐了一款三百多元的知名品牌。推荐的产品本身没错，但违背了用户上一轮设定的价格约束。

这种上下文约束幻觉，原因在于系统并没有把历史对话里的关键约束抽取出来结构化保存。模型在长对话里对早期约束的记忆会衰减，生成时会优先满足当前轮次的需求。

解决方式是为Agent加了一层对话状态跟踪机制。每轮对话结束后，系统抽取用户的关键约束，比如价格上限、品牌偏好、功能要求，保存成结构化槽位。生成回答时，约束状态被强注入提示词，优先级高于模型自由发挥的空间。这层机制上线后，上下文约束类幻觉下降了接近六成。

3.4 第三轮改造：幻觉检测器的效果验证

最后一步，我给Agent加了一个独立的幻觉检测模块。当时团队选择用大模型当判官，同时辅以规则引擎做结构校验。

判官模型拿到的任务是：给定对话历史和Agent生成的回答，判断回答是否与事实一致、是否忠实于参考上下文。判官模型的输入输出格式：

{ "conversation_id": "123456", "agent_answer": "...", "reference": "...", "verdict": "pass", "risk_type": "none", "reasons": [] }

如果verdict是fail，系统会拦截回答，不让它直接展示给用户，而是走备选回复流程，比如抱歉，我需要再核实一下相关信息或者转向人工客服。

这套检测器在测试集上跑下来，检测准确率大约88%，误伤率约4%。误伤会牺牲一部分正常回答，所以我又调了一版宽松规则，只有risk_type为high的内容才拦截，中低风险只做标注不下架。这个平衡点的选择取决于业务对错误说法的容忍度。

三轮改造完成后，运营那边的投诉量从一天七八条降到一周两三条。用户侧没有感知到Agent变笨，反而觉得回答变可靠了很多。

3.5 过程中踩过的几个坑

第一坑：RAG知识库里的过期内容比没有更坑。我把旧活动方案全部下线后，Agent的表现反而更稳定，因为它不再从过时信息里捡知识了。

第二坑：判定模型的系统提示词不能写得太严。太严会把生成的正常信息都判成幻觉，误杀率飙升。需要不断调阈值和修正prompt。

第三坑：动态数据API的返回格式要稳定，否则Agent解析失败后，会用训练数据里的知识来补位，反而制造幻觉。这个我们在库存接口返回异常时，强制Agent回复暂时无法查询，而不是让它编一个数字。

第四坑：链式调用别贪多。之前想让Agent先查库存再查价格再查优惠，每一步都会引入一次幻觉风险。后来把能合并的API合并，把不需要模型决定路径的节点改成规则路由，整个系统的可靠性提升非常明显。

4. 幻觉检测与评估体系：没有评测就没有治理

4.1 为什么需要一套专门的评测集

幻觉治理最大的难点不在方案落地，而在你不知道改完真的变好了还是变坏了。AI生成的文本没有标准答案可以比对，主观评价又不稳定。所以我特别强调，幻觉治理项目一定要从第一天开始搭评测体系。

我建议团队维护一个三类测试集：

第一类是事实核对集。每道题都带一个可以核对的参考答案，或者带一个权威的知识源内容。比如门店营业时间，答案就是API返回数据。这类数据能测出事实性幻觉。

第二类是上下文约束集。构造多轮对话用例，前几轮埋下约束条件，后几轮考察Agent是否还遵守约束。比如第一轮说只要红色的，第二轮说考虑长款，第三轮问推荐哪款，正确答案必须同时满足红色和长款。

第三类是工具调用集。专门测试Agent调用工具时的参数正确性，比如给出的运单号、商品ID、日期格式是否准确。

这类评测集不是一次性工作，每个迭代版本都要跑一遍，形成前后对比数据，才比较好判断某次改动是正收益还是负收益。

4.2 自动评测的落地方式

自动评测落地我一般分两步走。第一步做离线批量评测，把测试集喂给Agent，拿到所有输出，然后让评测模块统一打分。打分模块可以是规则匹配，也可以是判官模型，两种结合最佳。第二步做线上监控，实时采样线上对话，对Agent的回答做幻觉风险标注，定期人工复核标注结果，用来发现评测集之外的漏网之鱼。

我实际用的评测输出表大致这样：

这张表跑完一个版本，哪些环节还容易出幻觉一目了然。没有这个基础，后面再花哨的治理手段都验证不了效果。

4.3 主观评估与可接受幻觉率

自动评测覆盖不了所有情况，还需要人工抽检。每轮迭代我从线上日志里随机抽200条对话，人工标注Agent回答里有没有幻觉，然后计算幻觉率和累计柱子图。这类抽检比较耗时，但能暴露自动评测没发现的问题，比如语气问题、过度承诺问题、不适当的推诿问题。

还要讨论一点，幻觉率不是越低越好。把幻觉率压到0通常意味着Agent极度保守，会导致大量正常问题回复无法回答。要在用户体验和风险控制之间取得平衡，一般建议把幻觉率控制在一个可接受的范围内，比如3%以下是相对健康的水平。

5. 工具与模型选型：我们做幻觉治理时用的技术栈

5.1 向量库与检索层选型

RAG是幻觉治理的第一大重型武器，向量库的选择影响检索质量。我在小规模项目里用过开源向量库，数据量几万条以下时性能足够，部署简单、零成本。数据量上来以后，我更倾向用专业向量数据库，高并发查询和过滤能力更强，也自带一些检索相关的内置策略。

如果对技术栈没有特殊要求，我建议从开源向量库起步，先跑通流程再考虑迁移。如果团队已经在用某个云厂商，顺带用它的向量检索服务就好，省得维护多套系统。

5.2 判官模型的选择：大模型还是专用小模型

幻觉检测器用什么模型，我实际测试过两条路线。

路线一是直接用闭源大模型当判官，优势是理解力强，对复杂语义关系的判断比较准。缺点是API调用费用高，响应延迟大，不适合高频检测。

路线二是用开源小模型微调成专门的NLI判官，优势是延迟低、成本低，能嵌入到业务主链路。缺点是能力上限有限，对复杂逻辑关联的判断弱一些。

我的建议是分层使用：线上实时校验用一套快速但保守的规则加小模型，离线深度巡检或者高风险场景复核用强能力大模型判官。两套联动，成本和准确率能取得比较好的平衡。

5.3 带工具调用能力的模型框架选择

Agent的推理和调度框架会影响幻觉治理的难度。有些框架内置了工具调用的结构化输出机制，函数参数严格按照JSON Schema生成，这类框架天然降低了参数幻觉的概率。

我搭Agent的习惯是，先把工具声明写成严格的JSON Schema，字段类型、枚举值、必填与否都写清楚。模型生成工具调用时，框架强制校验Schema，非法调用直接拒绝。这个门槛不高，但能挡住一批参数幻觉。

5.4 一个关键经验：不要高估模型自我纠错能力

很多团队问我，能不能让Agent先自问自答验证一遍再输出？我先说结论：有一定帮助，但效果有限。

所谓自我一致性验证，就是让模型针对同一个问题生成多个回答，然后投票选一致性最高的。这个方法在开放生成场景里能过滤一部分随机幻觉。但问题在于，模型所有采样版本共享同样的参数化知识，错误答案经常是稳定复现而非随机波动，投票也投不出正确结果。

所以我更推荐交叉验证，拿外部工具、外部知识库或独立判官模型来判断，而不是让Agent自我思辨来验证。外部信息作为独立证据源，才能打破模型自身知识的封闭循环。

6. 未来展望：幻觉治理的下一步演进方向

6.1 从工程治理到模型能力的内生进步

幻觉治理当前的很多方案属于外挂式工程手段：RAG是外挂知识源，校验器是外挂裁判，规则引擎是外挂闸门。这些方案能拦住幻觉，但没有改变模型本身的认知方式。

我在关注两个方向的演进。一是模型在训练阶段就引入更多事实型数据和检索能力，让模型天生知道何时需要查外部资料，何时可以直接作答。二是模型对自身知识边界的感知能力越来越强，能更准确地区分已知和未知。这条路还长，但比工程外挂更有希望从根源上压低幻觉。

6.2 Agent记忆与工具使用的协同治理

目前的美好愿景是Agent的长期记忆模块和工具调用链形成协同，记忆模块能记住哪些信息来自可靠外部源、哪些来自模型推断，在生成时优先使用可信度更高的信息。工具调用也会记录成功率，Agent会慢慢学会更信任那些稳定好用的工具。这套协同如果能做出来，幻觉治理会从单点拦截变成系统性的过程治理。

6.3 幻觉评估标准的统一

现在各家团队的幻觉测试集各做各的，指标定义不一致，横向对比很差。我希望能看到更多公开的、结构化的幻觉评测基准，覆盖事实核对、上下文约束、工具调用等多个维度。有了统一标尺，幻觉治理的进展会更透明，行业整体水平也会提升得更快。

我自己也在项目中积累了一套私有评测集和一套评测流水线，每次Agent版本迭代跑一遍，把幻觉率的变化当核心指标看待。这套流程如果可以沉淀成开源方案，激励价值还是不小的。

最后说一下我个人的体会。AI Agent幻觉治理这件事，没有一招制敌的方案，它更像一个持续对抗的过程。你今天堵住了知识源的问题，明天模型可能会因为上下文过长而丢约束；你今天修好了参数幻觉，后天真说不定工具返回格式一变，新幻觉又冒出来。所以别追求完美，追求可控。把评测集搭好，把拦截机制做起来，把阈值调到业务能接受的水平，然后在迭代中不断收口。Agent用起来才会越来越顺，你不用提心吊胆看它在生产环境里乱说话。这套方法论拿回去，先选一个高风险场景试点，跑两轮迭代，你会回来感谢自己的。