rag和agentic rag是什么关系

很多人搭好一条「检索→拼接→生成」的链路后，发现多跳问题、模糊提问、跨文档对比还是答不好，于是听到 Agentic RAG 就想推翻重做。这篇不聊概念史，只讲两者的关系怎么理解、什么信号说明该升级、改造时先动哪一层、以及什么情况下老链路反而更划算，最后给一份可照着走的判断与落地清单。

很多人照着教程把「检索→拼接→生成」这条链路搭起来，跑通 demo 那一刻挺爽，可真拿几个业务问题一测就发现不对：需要串两份文档才能回答的、提问很模糊要靠猜的、跨文件做对比的，命中率立刻掉下来。这时候一搜，看到 Agentic RAG 这个词，第一反应往往是把现在这套推翻重做。

先别急。这篇不聊概念发展史，只讲清楚两件事：它们到底是什么关系，以及你手上的链路要不要动、先动哪一层。核心结论提前给：多数情况不是替换，是套壳。

先把关系说准：不是两代产品，是同一条链路的两种控制方式

传统 RAG 的流程是写死在代码里的：可选的一次查询改写、一次召回、一次重排、一次生成，控制权在你这边的编排逻辑里。Agentic RAG 换了个思路，把「要不要检索、检索几次、要不要换查询、资料够不够」这些决定交给模型，按工具调用的方式循环着做。

关键点在这儿：Agentic RAG 通常是把原来写死的检索步骤打包成一个可以被反复调用的工具，而不是换了另一套检索或向量算法。也就是说，它一般包含传统 RAG，底层召回和重排大概率还是你原来那套。

什么时候该上 Agentic：三个可观测信号

不用凭感觉拍板，看线上表现就有信号。下面三条只要中了一条，固定链路就大概率到了天花板；一条都不中，先别动。

• 回答里频繁出现「资料中没有找到相关内容」，但你手动一搜明明有——说明查询改写得不够，一次召回的命中率撑不住。
• 问题本身要求串起两份以上文档，比如「按 A 文档里的口径重新算一遍 B 表里的数」——固定链路只在开头检索一次，拿不到第二步该用的检索词。
• 同一个入口进来的问题很杂，简单事实问答和多步推理混在一起，一刀切的召回条数要么浪费要么不够。

反向条件也要说清楚：如果语料只有几百条、问题高度同质、单轮召回的准确率已经让你满意，那上 Agentic 只会让延迟和费用一起涨，这一类别上。什么算「满意」，别用感觉，拿一批固定问题跑命中率，具体怎么设基线和对照口径，到 /benchmarks 看当时的说明。

改造落地顺序：先动最小的那一层

决定要改了，也别一口气全上。按下面顺序推，每一步都能单独验证，出问题好回退。

1. 第一步：封装工具把现有检索包成一个工具，入参只留查询串和条数，出参带上来源标识。先别动召回和重排逻辑，只验证它能被重复调用、返回结果稳定。
2. 第二步：给循环加上限设最多几轮检索、单轮最多几条、总步数上限。超限就直接用已有资料作答，并在回答里写明资料不足。这一步不做，线上迟早出现自己跟自己聊到停不下来的请求。
3. 第三步：把「要不要检索」显式化闲聊、纯改写、格式转换这类请求不进检索分支，省掉一次无谓调用，也顺带把延迟拉回来一点。
4. 第四步：最后再加花活查询分解、结果反思这类动作放到最后。每加一个都要重跑同一批对照用例，确认是数据上变好，而不是你感觉变好。

注意第四步的适用边界：如果前两步还没跑稳，加再多分解和反思都是给一个漏水的桶刷漆。先用小批量固定用例把检索命中和轮数这两件事盯住。

工程账：延迟、并发、日志和评测怎么跟着改

从一次调用变成若干次串行调用，工程上的账要重算，不然上线第一天就会被打回。

延迟

首字时间天然变长，要给整体设一个总超时，并提前决定超时后是降级到单轮回答还是直接报错。

并发

一个请求会占用多次模型调用额度，按 QPS 估容量时要乘以平均轮数留余量，否则高峰会出现排队和超时互相叠加。

日志

至少能复盘每轮用了什么查询、召回了哪些片段、模型为什么决定再查一次，否则出问题只能猜。

评测

别只看最终答案，把「检索是否命中」「轮数是否合理」也记下来，用同一批用例做前后对比。

具体到选哪家模型、走哪个接口、延迟大概什么水平，这些是会变的数字，别照搬别人文章里的结论。到 /price-watch 看当前价格，到 /tools/speed-test 这类工具页跑一下自己网络环境下的实测，再决定。