做AI应用开发的人这两年恐怕没人能绕开幻觉这两个字。明明给模型喂了资料它还是能一本正经地编出根本不存在的结论而且编得越自信越让人头疼。RAG检索增强生成是被寄予厚望的方案之一但我在实际项目中试过之后发现它远远不是终点——固定流程的检索拼接在面对复杂问题时照样翻车。于是我开始把Agent智能体引进来让模型自己决定什么时候查、查什么、怎么用查到的信息这一套组合下来幻觉率才真正被压到了可控范围。这篇文章不打算讲那种RAGAgent很强大的空话而是把我从方案选型、架构设计、代码实现到线上排障的完整过程拆开来讲。如果你正在做一个对答案准确性要求很高的AI应用或者你已经被幻觉问题折磨得想摔键盘这篇文章应该能给你几条真正能落地的思路。1. 先说清楚幻觉到底是怎么来的为什么RAG单独搞不定1.1 幻觉的三大来源要想治幻觉先得知道它从哪来。我的理解里生成式大模型的幻觉问题其实有三个独立来源它们混在一起造成了我们看到的一本正经胡说八道。第一个来源是训练阶段的知识截断。任何模型的知识都停留在训练数据截止那一刻之后发生的事它一概不知。你问它某个新政策、新产品的参数它根本没有对应的知识实体只能靠语言习惯强行生成一个看起来合理的回答。这属于知识缺位型幻觉最典型的表现是回答流畅但细节全错。第二个来源是生成阶段的概率采样。大模型本质上是逐token预测下一个词的概率分布它选择高概率词并不等于选择正确词。当某个话题在训练语料里出现频率足够高模型会对编造这件事产生极高的置信度——它见过一万次类似的问法就敢给你编一个从来没存在过的答案。这种自信型幻觉最可怕因为答案的措辞越顺滑用户越难分辨真假。第三个来源是检索阶段的语义错配。即使在RAG系统里检索器返回的内容也未必和用户问题真正相关。向量检索只负责语义相似它把问题和小段落映射到向量空间算距离但语义相似不等于事实正确更不等于逻辑完整。如果检索回来的内容是错的、过时的、或者只是看起来相关生成模型就会无意识地把它缝进答案里这就形成了污染型幻觉。1.2 单靠RAG解决不了的三类场景传统的RAG流程很直白用户提问系统拿问题去向量库检索top-k段落拼到上下文里让模型生成。这个流程在单轮事实问答场景下效果不错但一旦遇到下面三类场景就会失灵。第一类是需要多步推理才能回答的问题。比如用户问某公司今年在A城市发布了哪些支持B功能的产品——你得先检索出该公司今年的所有产品再筛选出A城市发布的再匹配B功能最后汇总。传统的一次检索一次生成根本没法完成这种链式推理因为中间的每一步都依赖上一步的结果。第二类是检索结果本身不够用的问题。当知识库里没有直接答案时标准RAG会强行用残碎片段生成回答编造自然发生。合理的做法是先判断知识缺口在哪然后再补一次检索或者明确告诉用户资料不足。但固定流程的RAG没有这种判断能力。第三类是回答之后没人检查的问题。标准RAG生成完就结束了输出的内容是否严格来自检索段落、引用是否对得上完全没人验证。模型把上下文里一段无关文字当作论据用了系统也不会有任何察觉。1.3 引入Agent的真正动机Agent的价值恰恰体现在上面三个盲区。它给模型装上了元认知在回答之前想想要不要查资料回答之后回头检查一下引用对不对。这种计划-执行-验证的能力才是把幻觉压下去的关键。我见过很多人把Agent理解成会调用工具的聊天机器人这个理解太窄了。Agent的核心在于ReAct循环——推理Reason驱动行动Act观察行动结果后再推理。每一步行动的结果都会影响下一步决策这就让检索从一次性操作变成了可迭代的决策过程。更重要的是Agent天然支持验证这个动作。你可以在生成结束后让模型自己检查我引用的文档标号是否真实存在我的回答是否严格基于检索片段如果有不确定的内容要不要再查一次这种自我反思机制是传统RAG结构上就不具备的。2. 整体架构从固定检索流程到自主决策智能体2.1 系统三层结构我最后落地的方案整体上分了三层路由层、检索层、生成验证层。这个分层不是为了好看而是为了把要不要查怎么查怎么证明回答是对的三个问题彻底分开处理。路由层解决要不要查。用户的问题不是每一个都需要检索的聊家常、问常识、让模型做头脑风暴这种场景应该直接用模型自身能力回答检索反而会引入噪音。我用一个轻量级意图分类器来判定这个问题是闲聊、是常识问答、是内部知识问答、还是需要实时数据查询。只有落到后两类才触发检索流程。检索层解决怎么查。它不是一个孤立的向量库而是挂载了多个数据源的工具集本地文档知识库、外部搜索API、结构化数据库查询接口。Agent的核心决策逻辑在这一层集中体现——它要根据问题的需求决定检索哪一个或哪几个工具以及检索之后怎么整合结果。生成验证层解决怎么证明回答是对的。这一步我要求模型在回答时标注引用来源并在输出前执行一轮自我检查。检查不通过就触发新一轮检索形成闭环。后面我会展开讲这个验证机制的具体设计。2.2 主控循环设计在主控循环里我用的是ReAct模式的改进版。每次循环包含四个步骤思考当前状态、选择下一个动作、执行动作并获取观测结果、把结果追加到上下文。这个循环一直持续到模型认为问题已经被回答且验证通过或者触发了最大迭代限制。这里有一个非常关键的设计观察结果必须被当作事实对待而不是参考。我要求模型在回答中引用对应的[文档编号]这些编号必须是观测结果里真实存在的。如果模型引用了一个虚构的编号验证阶段就能立刻发现。这相当于给模型戴了一个必须说人话的枷锁让它的输出始终锚定在检索证据上。主控循环的停止条件也很重要。我设置了两个出口一是模型在思考阶段明确输出信息充分可以作答二是达到最大步数上限。在调试阶段我建议把最大步数上限设置成5-6轮太少了复杂问题查不完太多了延迟和成本都会失控。2.3 工具集规划工具集的规划有一个容易被忽略的原则工具的粒度要配合模型的选择能力。你把工具划分得太粗比如只给一个查询知识库模型就无法表达我要查A产品的参数和我要查B产品的销量这样的精细意图划分得太细又会让模型在选择时反复犹豫反而拉长决策链。我实际用的工具划分方案是某个产品知识文档的向量检索工具、实时订单数据的SQL查询工具、外部公开信息的网页检索工具、以及一个无操作出口。前三个覆盖不同的数据类型第四个给模型一个不用调用工具的合法选择。每个工具的描述字段要写得足够具体这一点我踩过坑。模型选择工具靠的是工具描述里的语义匹配描述太笼统它就会选错。比如查询产品知识和查询实时销量如果描述含糊模型在复杂问题上很容易两个都选或者选错。我的经验是描述里带上典型的用法示例传入产品型号返回该型号支持的参数列表——模型一看就懂这是干什么的。3. 核心模块的实操要点路由、检索、验证一个都不能少3.1 路由与意图识别路由层看似简单但它决定了整个系统的效率上限。如果一个闲聊问题被错误路由到了检索流程白白浪费一次工具调用还把返回的无关内容污染进上下文。我在路由设计上用了两个关键策略。第一个策略是给意图分类器加上明确的few-shot示例。只告诉模型你有四类意图远远不够它会对边界情况感到困惑。我给了它每个意图两到三个典型问题示例覆盖了常规表述和模糊表述。比如内部知识问答类下面既写了我们公司的报销流程是什么也写了还记得之前在项目纪要里定的排期吗——后者就是典型的模糊表达。第二个策略是加置信度阈值。分类器输出四类意图的置信度分布只有最高置信度超过阈值我一般设0.85才进入对应流程如果置信度不够就不触发检索直接用模型原回答同时附上一句这是根据通用知识做出的回答。这个兜底策略虽然保守但避免了路由层主动制造污染。提示路由层的模型选择尽量用快一点的轻量模型。路由不需要多深的推理抢的是延迟。我用一个大模型做路由的时候延迟直接多加了600毫秒体感非常明显。3.2 多路检索与重排序进入检索层后首要任务是保证查回来的东西真的有用。向量检索本身是召回的思路它只负责把语义相近的内容拎回来并不判断质量。我处理的方法是所有检索结果统一过一个重排序环节。重排序我使用的是交叉编码器方案。它把问题和候选文档拼在一起用一个专门的模型计算相关性分数比向量相似度准确得多。实际使用的分数阈值可以这样算先用一批好问题和坏问题对这个平台调参挑出误杀率和误放率平衡点的临界分数我目前线上采用的是0.35低于它的直接丢弃绝不进上下文。这一步显著降低了污染型幻觉的产生概率。多路检索还有一个组合细节。当Agent决定既要查产品文档又要查实时销量时两路返回的结果会合在一起重排序。这里我加了来源标识符每个段落前面[Doc A]-这种前缀是必须有的。这是为了让生成阶段更容易正确引用也让后端的溯源检查有据可依。没有来源标识的检索结果在验证阶段会被直接判定为非法证据。3.3 生成、溯源与自我验证生成阶段是我改造最重的地方。我给模型的指令里加了一条严格约束答案的每一句话必须至少对应一个[文档编号]没有编号支撑的内容一律不许出现在回答里。这句约束看似简单实际上把模型的随机生成空间大幅压缩了。为了进一步降低自由发挥空间我把生成温度调到了0.1。加了引用约束再把温度调低模型的输出会更保守更倾向用检索片段里的原话来组织答案。代价是回答的措辞会显得有点死板不够活泛。但在事实问答场景里准确性的优先级远高于文采这个取舍是值得的。自我验证我用的是LLM as Judge的思路但不是让模型自己给自己打分——自答自判会存在系统性偏差。我的做法是让一个独立的验证模型检查三个东西每个编号是否真实存在于观测结果里每个编号的内容是否真的支撑了对应的句子有没有核心问题点被跳过了。如果验证模型的结论是有编号不存在或支撑不足就触发一轮新的检索与修正循环。注意验证模型的角色要和生成模型分开。同一个模型既生成又检查它倾向于为自己的输出辩护检查形同虚设。哪怕用同一个基座模型也要在提示词里把角色定义彻底区分开。3.4 关键参数配置参考很多人在这个环节最需要一份可以抄作业的参数表我把我目前线上运行比较稳定的一套参数列出来注意它依赖数据规模和业务场景照搬时要测自己的数据。参数推荐值设计意图温度 temperature0.1压缩生成多样性紧贴检索证据检索候选数 top_k20保证召回率让重排序有足够选择空间重排序阈值0.35过滤低相关片段防止上下文污染最终上下文引用数3-5控制上下文长度避免模型注意力分散最大ReAct步数6平衡复杂问题处理能力和延迟成本路由置信度阈值0.85防止误路由和上下文污染验证循环上限2防止无休止的自我怀疑和延迟膨胀还有一个参数容易被忽略每轮检索返回给模型的段落数量上限。我每轮最多给4段因为这个数量下的注意力分配最稳。给太多段落模型会把精力花在无关细节上反而更容易产生缝合错误——把两个不同来源的内容缝到一起编出一个两边都不支持的结论。4. 我在实际项目中踩过的坑高频故障与排查实录4.1 检索命中率低导致的硬编造上线初期我遇到的第一个大坑就是检索命中率低。案例分析发现用户经常问产品参数里有的内容但向量检索就是召不回相关段落。排查到最后问题出在切片策略上我把长文档按固定长度切片一段500个字符没有考虑语义边界结果把完整的产品参数表从中间切断了。对切片策略调整后命中率有明显上升先识别文档里的标题层级按章节边界切分章节过长的再按段落边界细分段落中途遇到表格、列表这种结构化内容单独把表格作为一个检索块。这么改完之后同一问题的检索命中率提升了一截模型需要编的情况自然就少了。4.2 反思循环失控另一个高频故障是反思循环的出入口。某一次版本上线后系统在部分复杂问题上反复触发重新检索-验证不通过-再次检索直到触达最大步数才停止单次请求耗时直接飙到十几秒。抓日志一看原来是提示词里对支撑不足的定义有歧义验证器经常把答案缺少文档编号当作证据不足于是死不放手。最后我把验证条件改成用显式的检查清单第一看标号是否存在第二看编号内容是否覆盖核心论点第三看是否有未作答的子问题。每一步都要输出是/否只有全部为是才允许结束循环。这个改动让平均循环次数从4.3次降到了2.1次延迟随之回落。验证循环用布尔判断代替直觉判断是根治反思瘫痪的关键。4.3 上下文窗口的隐性膨胀这个问题很隐蔽是我在追踪token消耗时发现的。每轮ReAct循环都会把上一步的轨迹思考动作观测追加进上下文看起来每轮只有几百token但连续6轮之后老轨迹占了大量窗口导致真正承载答案生成的空间被挤压生成质量反而下降。我的解法是定期压缩历史轨迹每轮开始前把上一轮的思考部分丢弃只保留动作观测结果。思考部分对后续决策的影响远小于观测结果丢弃它既不损害决策质量又大幅节省token。这个压缩动作让我在同等预算下能把最大步数从6提高到8而不会撑爆上下文。4.4 工具调用格式不稳定工具调用的格式问题也是必经之劫。我一开始用的是纯文本格式让模型输出要调用的工具名和参数但模型偶尔会漏掉参数、多出前缀、或者用自然语言绕圈子一旦解析失败整个循环就卡死。后来我强制要求输出严格的JSON对象格式并加了重复解析的容错逻辑解析失败时不再让模型补充说明而是把报错信息和原问题打包要求模型再次输出符合JSON格式的动作。这个格式纠偏机制上线后工具调用的解析成功率从91%提到了99%以上。5. 这套方案到底值不值得上评估门禁与适用边界5.1 成本与延迟账要算清楚把Agent引入RAG性能和准确率确实上来了但代价也一样明显。我在真实项目里做过一个统计对比同样一批问题传统RAG单次请求平均消耗token约2200而RAGAgent的方案平均消耗约4700翻了一倍多延迟也从平均1.2秒涨到了2.8秒。如果你当前应用对延迟和成本有硬约束这个账必须在动手前就算明白。这并不代表该放弃Agent方案。我的思路是给系统加一道难度评估门禁简单问题直接走轻量RAG流程只有系统判定为复杂问题才升级到Agent流程。这个分级策略让日常请求的平均成本只增加了25%代价不过是多一次路由判断。5.2 什么样的场景最适合这套方案根据我的实践经验RAGAgent的组合在不同场景下的收益差异非常大。我做了一个适用度评估表供参考场景类型传统RAG效果RAGAgent效果是否值得单轮事实问答良好良好收益有限需要多步推理的问答偏差良好非常值得多条件交叉筛选偏差良好非常值得实时数据静态文档混合查询差良好必须上高吞吐客服场景良好一般需加分级策略如果你做的是高吞吐、问题模式高度重复的场景Agent带来的额外推理成本会显得非常扎眼但如果你做的是知识的深度问答、跨数据源的复杂查询这类场景Agent带来的准确性提升是压倒性的。5.3 上线前必须评估的三个指标把系统做出来只是第一步上线前我强烈建议团队先盯死三个指标。第一个是引用准确性。抽查验证回答里的引用编号是不是真的指向了正确段落。引用对齐抽查在最初的两周里非常有必要它能直接反映整套检索链路是不是真的在起作用。我验证过几次模型回答看着合理但引用的内容是张冠李戴的情况比例不低。第二个是无引用断言率。统计回答里有百分之多少的陈述找不到对应的引用来源。这个指标超过3%就要警惕了说明模型还在偷偷自由发挥。第三个是兜底话术触发率。当检索内容不足以支撑回答时系统有没有老老实实说资料不足还是硬着头皮胡编。兜底话术的触发率可以不高但只要触发时说的是真话系统的可信度就能立住。按照我个人做几个项目的经验这三个指标里面引用准确性的权重最大。因为很多幻觉问题表面上是回答错误根源却是引用错乱。把引用链路管住了幻觉问题的七成就算治好了。最后再分享两个判断我踩过不少轮子之后最大的感受是RAG与Agent的结合本质上不是给模型加功能而是给模型设置了一套可以自证清白的思考流程。它不再是被动地把检索内容塞进上下文而是主动地找证据、用证据、查证据。这套机制不能从根本上消除概率模型的随机性但它能保证模型每一次的自由发挥都处在可控范围内。如果你正在为幻觉问题焦头烂额我的建议是不要试图一次性把Agent系统做完美。先架构出一个最小闭环——路由、一次检索、引用生成、一次验证——跑起来之后再慢慢加反思轮次、多路检索、复杂工具集。方案的价值需要在真实问题的检验中逐步释放步子太急系统容易乱反而误事。