agentic rag vs rag

做知识库问答的团队常卡在同一个岔路口：检索一次再生成已经能跑，但多跳问题、条件筛选、跨文档汇总总答不好。于是有人提出让模型自己决定搜几次、换个说法再搜。这篇不讨论概念定义，而是把两套链路的工程差别摊开——请求形态、延迟与成本分布、失败模式、日志要记什么、上线前怎么评测，最后给一份可对照的选型清单，说清各自在什么情况下不适用。

做知识库问答的团队常卡在同一个岔路口：检索一次再生成已经能跑，但多跳问题、条件筛选、跨文档汇总总答不好。于是有人提出让模型自己决定搜几次、换个说法再搜。这篇不讨论概念定义，而是把两套链路的工程差别摊开——请求形态、延迟与成本分布、失败模式、日志要记什么、上线前怎么评测。

判断的核心不是哪套架构更先进，而是你的问题分布和业务约束更适合哪一种。下面按链路结构、延迟成本、可控性与评测四个角度逐节拆，每节都给出可以照着做的动作和判断标准，最后给一份选型对照清单，说清各自在什么情况下不适用。

先看链路形状：单次检索 vs 多轮工具循环

传统 RAG 的链路是固定的三段：查询改写（可选）、一次检索、拼上下文生成。每次请求的步数和外部调用次数可预测，工程上容易做并发规划和超时预算。Agentic RAG 把检索包装成工具，由模型决定调不调、调几次、用哪个索引，回答之前可能经历多轮「搜—看—再搜」，请求长度与耗时不再固定。

判断起点不是谁更聪明，而是你的问题里有多少比例需要多跳推理、条件过滤或跨来源汇总。拿最近一段真实问题日志抽样分类，按「一次检索就能答对」和「明显要多次查」分两堆，比例偏向前者时，上 Agentic 的收益有限，反而要背额外的延迟和排错成本。

• 先抽样分类问题日志，算出「需要多轮检索」的占比，这个数字比任何架构讨论都实在；
• 如果占比很低，把精力放回检索质量本身，比如分块策略、改写质量、索引覆盖；
• 如果占比偏高，再考虑把检索工具化，但一开始就设好轮次上限；
• 无论选哪套，入口都要保留一条「单次检索」的退路，用于超时或异常时兜底。

延迟与成本的分布差别

固定链路的耗时集中在一次向量检索加一次生成，容易做超时预算和并发规划。Agentic 链路的耗时是长尾分布，多数请求接近普通 RAG，少数会翻好几倍，尾延迟直接决定用户体感。规划容量时要按尾部而不是均值来算，否则高峰期最先崩的就是它。

成本上要额外算上中间轮次的上下文累积：每多一轮，历史工具结果都要重新进上下文，token 消耗不是线性增长。具体的单价和用量口径到 /official-api 和 /tools/model-cost-calculator 按当时数字核算，别用记忆里的数估。

均值延迟

两套链路可能差不多，看均值会误判

尾延迟

Agentic 的 P95 往往是均值的好几倍，容量按它算

上下文累积

每多一轮，之前工具结果重复进上下文，成本非线性

降级开关

轮次或时长到线就退化成单次检索，不要继续试

失败模式不一样，排查方式也不一样

传统 RAG 的坏结果基本能归到三类：没召回、召回错、拼装超出预算，定位靠检索日志就能收敛。Agentic RAG 多出一层失败：工具选错、循环不收敛、半路放弃直接凭记忆回答，单看最终答案看不出是哪一步崩的。

所以必须记录每一轮的检索词、命中片段、模型决策理由，否则排错只能靠猜。给循环设硬上限（最大检索次数、总时长、总 token），到线就退化成单次检索兜底，而不是让它继续试。这三条上限值要写进配置，能在不发版的情况下调整。

1. 复现问题拿线上同一条问题重跑，确认是否稳定复现，不稳定说明是随机性导致
2. 看轮次日志检查每轮检索词是否偏离原问题，是否在同一个词上打转
3. 看决策理由确认模型是否误选了不该用的工具或索引
4. 看兜底是否触发确认上限有没有生效，没生效说明配置没读对
5. 归因分类把问题归到检索、决策、上下文三类，分别补测试

可控性：为什么很多团队最后退回固定链路

固定链路的输出格式、引用来源、延迟都能写进 SLA，适合对稳定性敏感的场景，比如对外客服、合规问答。Agentic 链路的输出是概率性的，同一个问题今天搜两次、明天搜一次，答案口径可能漂移，需要额外的一致性校验。

如果业务要求每句话都能指到原文，那么检索轮次越多，引用对齐的维护成本越高。这类场景不适合激进上 Agentic，除非你能接受在答案外挂一层人工或规则复核。反过来，内部研究助手、资料整理这类容错高的场景，Agentic 的收益更容易兑现。

上线前怎么评测：两套链路要用同一把尺子

准备一份固定问题集，覆盖单跳、多跳、需要条件过滤、无答案四类，两套链路跑同一批，否则结论不可比。指标至少三个：答案正确率、平均与尾部延迟、单次请求的 token 成本，只看正确率会漏掉后两项。

多跳题单独统计，这是 Agentic 最可能拉开差距的地方，也是它最容易「看起来对但过程错」的地方。评测集的构建方法与判分口径可参考 /benchmarks 和 /benchmarks/crowd-radar 的公开做法，别自己另起一套口径，否则团队之间没法对齐。

• 问题集要固定版本，改动要记录，否则历史结论失效；
• 单跳和多跳分开统计，混在一起会互相稀释；
• 无答案类必须包含，考察模型会不会硬编答案；
• 延迟按分位数看，不要只看平均；
• 成本按每次请求的 token 用量统计，不按总量；
• 评测结论要写清适用条件，换模型或换索引就得重跑。

折中路线：把 Agentic 收窄到特定分支

不必全量二选一，常见的做法是先做一次常规检索，命中分数高就直接生成，低才触发多轮检索。另一条折中是允许改写查询但限制次数，介于两者之间，工程改动小、风险可控。按问题类型路由也可以：事实型走固定链路，比较、汇总、多条件类走工具循环。

路由规则写在入口而不是交给模型自由裁量，这样行为可预期、可测试。这类分层思路与 /guides/rag-architecture-layers、/guides/rag-agent-tool-loop 讲的链路分层可以叠加使用，不冲突。关键是把「什么时候升级到多轮」写成明确条件，而不是靠提示词暗示。

选型对照清单：照着勾一遍再决定

下面这份清单按顺序勾，任意一项明显不满足，就先别急着切换，或者只做旁路验证。勾完还是拿不准，就先把两条链路并行跑一段时间，用真实问题集说话，而不是在会议室里争架构。

成本上能否接受同一问题的 token 消耗波动，具体预算口径到 /tools/token-price-calculator 按当时单价折算。日志和评测这两项经常被跳过，但恰恰是切换后最容易翻车的地方。

落地节奏：先影子跑，再放流量

第一步把 Agentic 链路接在旁路，线上请求仍走原链路，只记录它的答案与轮次，用于积累评测样本。第二步按固定比例放量，盯三个报警：单请求轮次超限、尾延迟超阈值、检索空手而归的比例。第三步按问题类型灰度，把表现稳定的一类先切过去，不稳定的留在旧链路。

迁移过程中接口层的超时、重试、降级配置同样要跟着改，这部分到 /guides/api-timeout-tuning 和 /guides/multi-model-routing-fallback 对照着调。整个节奏的目标不是尽快切完，而是每一步都有可回退的开关和可读的数据。

选型的答案不在架构对比表里，而在你最近一段时间真实问题日志的分布里。