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 第二道防线知识检索增强生成RAGRAG几乎是当前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的回答做幻觉风险标注定期人工复核标注结果用来发现评测集之外的漏网之鱼。我实际用的评测输出表大致这样用例编号场景类型问题标准答案/约束Agent回答幻觉类型判定是否拦截C01事实核对某商品价格199元199元无否C02事实核对门店营业时间10:00-22:009:00-22:00事实性是C03上下文约束预算200元推荐200推荐305元商品忠实性是C04工具调用运单号123456789参数校验通过调用成功无否这张表跑完一个版本哪些环节还容易出幻觉一目了然。没有这个基础后面再花哨的治理手段都验证不了效果。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用起来才会越来越顺你不用提心吊胆看它在生产环境里乱说话。这套方法论拿回去先选一个高风险场景试点跑两轮迭代你会回来感谢自己的。
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 第二道防线知识检索增强生成RAGRAG几乎是当前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的回答做幻觉风险标注定期人工复核标注结果用来发现评测集之外的漏网之鱼。我实际用的评测输出表大致这样用例编号场景类型问题标准答案/约束Agent回答幻觉类型判定是否拦截C01事实核对某商品价格199元199元无否C02事实核对门店营业时间10:00-22:009:00-22:00事实性是C03上下文约束预算200元推荐200推荐305元商品忠实性是C04工具调用运单号123456789参数校验通过调用成功无否这张表跑完一个版本哪些环节还容易出幻觉一目了然。没有这个基础后面再花哨的治理手段都验证不了效果。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用起来才会越来越顺你不用提心吊胆看它在生产环境里乱说话。这套方法论拿回去先选一个高风险场景试点跑两轮迭代你会回来感谢自己的。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
