Agentic RAG把检索准确率拉高了40%

标准RAG（检索增强生成）的准确率卡在72%已经两年，而Agentic RAG的实验室数据能冲到92%。多出来的20个百分点，代价是单次查询成本翻3-7倍。

这笔账怎么算？今天拆清楚。

标准RAG的"单行道"困境

标准RAG的工作流程像一条传送带：用户提问→转成向量→去数据库捞最相似的文本块→扔给大模型生成答案。信息单向流动，没有回头路。

这种设计对付"退货政策是什么"这类问题足够用。文档结构清晰，关键词明确，向量相似度能精准命中。

但用户不会永远这么乖。ByteByteGo的工程师举了个典型场景：有人问"怎么处理税务"，系统根本分不清是个人所得税、企业增值税还是非营利组织的免税资格。向量检索只看语义相似，不解题意，捞回来的可能是"税务登记流程"而不是"季度申报截止日期"。

更麻烦的是证据分散。一个承包商问远程办公政策，答案可能拆在《远程办公管理办法》和《外包人员协议》两份文档里。标准RAG通常只取Top-K个文本块，K值设小了漏信息，设大了给大模型塞噪音。

最隐蔽的坑是"看起来对"。检索结果和查询字面相关，但实际答非所问。系统没有机制停下来检查："这堆材料真的能回答问题吗？"

Agentic RAG的"三思而后答"

Agentic RAG的核心改动很简单：在检索和生成之间塞进一个能决策的环节。这个环节可以重写查询、多次检索、评估结果质量，甚至决定要不要调用外部工具。

具体怎么运作？系统收到"怎么处理税务"之后，第一步不是急着去数据库捞，而是让Agent分析意图。Agent判断需要澄清，于是生成三个子查询：个人所得税申报流程、小微企业增值税优惠、501(c)(3)免税资格申请。三次检索并行执行，结果汇总后再交给大模型。

面对证据分散的问题，Agent会主动扩展检索策略。第一次检索只拿到远程办公的通用条款，Agent发现没提承包商特殊限制，于是追加查询"外包人员办公地点要求"，把两份文档的关键段落拼齐。

评估环节是Agentic RAG真正的护城河。系统会给检索结果打分：相关性够不够？信息完整度如何？有没有自相矛盾？分数不达标就触发二次检索，而不是硬着头皮生成。

这个"暂停-评估-决策"的循环，让Agentic RAG从流水线变成了有反馈控制的系统。

三种主流架构的取舍

目前落地的Agentic RAG主要有三种形态，成本和效果差距很大。

第一种是反射模式（Reflection），最轻量。系统生成答案后，让另一个Agent或同一模型的不同实例来挑刺。比如生成"税务处理步骤"后，评审Agent检查："步骤3提到的表格编号在检索材料里出现过吗？"发现没出处，打回重写。这种模式只增加一轮生成成本，延迟可控，但对检索阶段的错误无能为力。

第二种是路由模式（Routing），按问题类型分配不同检索策略。简单问题走标准RAG快速通道，复杂问题激活多跳检索或调用SQL数据库、API接口。ByteByteGo提到一个电商场景：问"订单状态"直接查向量库，问"过去30天退货率趋势"则路由到BI系统的SQL查询。路由决策本身需要一次模型调用，但能避免过度设计带来的浪费。

第三种是多Agent协作（Multi-Agent），最重也最灵活。多个专业化Agent分工：一个负责拆解问题，一个专攻法律文档检索，一个处理财务数据，还有一个专门验证事实一致性。每个Agent可以有自己的工具链和记忆窗口。这种模式在医疗、金融等高风险场景开始试点，但Token消耗是标准RAG的5-10倍，延迟以秒甚至分钟计。

成本账：准确率每涨1%，烧多少Token？

这是产品经理最头疼的部分。Agentic RAG的改进不是免费的，成本结构完全变了。

标准RAG的成本公式很干净：1次嵌入计算 + 1次向量检索 + 1次大模型生成。以GPT-4级别模型估算，单次查询约$0.002-0.005。

Agentic RAG的成本是变量：意图分析+子查询生成+多轮检索+结果评估+最终生成，每个环节都可能触发模型调用。反射模式增加30-50%成本，路由模式增加50-100%，多Agent协作直接翻3-7倍。

更隐蔽的是延迟成本。标准RAG响应时间800ms-1.5s，用户无感知。Agentic RAG的多轮交互很容易突破5秒阈值，进入"用户开始烦躁"区间。某金融科技公司的实测数据：路由模式平均2.3秒，多Agent模式8.7秒，后者用户流失率上升12%。

Token消耗还有长尾风险。Agent陷入"检索-不满意-再检索"的循环时，成本会指数级膨胀。没有设置硬上限的系统，遇到过单次查询烧掉$0.4的极端案例。

落地建议：什么时候该上Agentic RAG？

不是所有人都需要这套复杂系统。三个信号帮你判断：

第一，标准RAG的错误成本有多高？内部知识库问答错了可以容忍，医疗诊断建议错了就是事故。错误代价越大，越值得为准确率付费。

第二，查询的复杂分布如何？如果80%的问题都是"退货政策""安装步骤"这类直达题，Agentic RAG的边际收益极低。反之，如果用户经常问"比较A方案和B方案在C场景下的税务影响"，多跳检索的价值就凸显。

第三，有没有足够的工程资源维护？Agentic RAG不是调个参数就能跑，需要设计评估标准、调优决策阈值、监控循环终止条件。团队没3-5个熟练工程师，很容易做成半成品。

一个务实的折中方案：先用路由模式做分层，简单问题走高速通道，复杂问题进Agent流程。这样能把额外成本控制在可接受范围，同时覆盖关键场景。

某头部云厂商的客服系统就是这么设计的。70%的查询由标准RAG秒回，25%触发反射模式做事实核查，5%的疑难问题进入多Agent深度处理。整体成本只比纯标准RAG高40%，但准确率从71%提升到89%。

Agentic RAG的终极形态还在演化。有人尝试让Agent自己学习最优检索策略，有人研究如何用小型模型替代部分决策环节降本。唯一确定的是，"检索-生成"的边界正在被重新定义——系统不再被动搬运信息，而是主动追问、验证、组装答案。

你的业务场景里，有多少查询值得让AI多想几秒钟？