今天聊一篇最近很值得看的论文：AgenticRAG。
它表面上讲的是 RAG，但真正想解决的，其实是一个更底层的问题：传统检索流程里，LLM 没有机会参与检索决策。
论文标题是 AgenticRAG: Agentic Retrieval for Enterprise Knowledge Bases，核心思路是给大模型一组工具，让它可以自己判断何时查、查什么、查到哪一层。
先说传统 RAG 卡在哪
很多人对 RAG 的理解都很顺：先搜，再塞进 prompt，再让模型回答。
但这个流程默认了一个前提：检索在模型开始思考之前就已经结束了。
问题在于，真实企业场景里的问题，往往不是那种“一句关键词就能命中”的简单查询。
比如下面这些问题：
·“某个内部 API 升级后，为什么会出现权限校验失败？”
·“这个季度云服务成本上升，主要是哪个产品线拉高的？”
·“某条发布流水线偶发超时，是环境问题还是脚本问题？”
这类问题通常有三个特点：
第一，它们不是单点问题，而是多步推理问题。
第二，答案经常分散在不同文档、不同章节甚至不同表格里。
第三，单纯靠一次搜索返回的 snippet，根本看不出真正答案藏在哪里。
所以标准 RAG 常见的瓶颈不是“模型不会答”，而是“模型拿到的证据太死板”。
它只能被动接受检索系统吐出来的结果，没法继续追问：
“这份文档值得不值得继续看？”
“我能不能换个角度再搜一次？”
“这个结果只是提到了线索，还是已经包含答案？”
AgenticRAG 的想法很直接
AgenticRAG 的思路不是重做搜索引擎，而是把检索过程变成一个可迭代的推理过程。
也就是说，不再让搜索系统一次性把“最终候选”都决定好，而是让 LLM 在推理过程中动态选择下一步动作。
论文在现有企业搜索后面，加了一层轻量级工具层，主要是四个能力：
1）search
它负责做企业范围内的文档发现。
你可以把它理解成“先帮模型把可能相关的材料捞上来”，它会返回标题、摘要片段、文件元信息，以及一个可追踪的引用 ID。
2）find
它更像是“文档内搜索”。
如果模型已经知道自己要找的是某个术语、指标、配置项或者错误名，就可以直接在某份文档里精确定位，不需要重新全库检索。
3）open
它负责把文档内容打开到可阅读的窗口里。
这一步适合那种“我知道大概在这部分，但还得往下翻一翻”的情况，比如长文档里的某张表、某个章节、某一段说明。
4）summarize
它是上下文管理工具。
当推理链越来越长、对话 token 快撑爆时，系统会把当前已经确认的信息压缩保留，只留下关键引用，让模型还能继续往下查，而不是被上下文长度卡死。
它和传统 RAG 最大的不同
传统 RAG 像是：
搜索系统先把饭菜端上来，模型只能吃现成的。
AgenticRAG 更像是：
模型先拿到厨房权限，再决定要开哪扇柜门、拿哪种食材、先炒哪道菜。
论文里这个系统运行的是一个有上限的循环。
每一轮，模型看见当前对话和工具说明，然后决定是继续调用工具，还是直接输出最终答案。
如果到达最大轮数还没收束，系统会强制让它给出最终回答。
这类设计有个很现实的优点：
它不要求额外训练模型，也不要求你重建 embedding、重做图结构、或者为了这套流程专门清洗语料。
换句话说，只要企业原本就已经有文档索引，AgenticRAG 就可以直接接上去。
工具到底怎么协作
论文里最值得注意的一点，是它不是简单把搜索结果喂给模型，而是把检索拆成了“广度发现”和“深度阅读”两个阶段。
search 负责广度
search 会先帮模型发现候选文档。
而且它支持一次发多个改写后的 query，这样可以一次把多个角度都试一遍。
这个设计很像：问题不确定时，不要只赌一个问法，而是同时试几个可能方向。
find 和 open 负责深度
有些时候，模型已经知道关键词，就适合用 find 直接找。
有些时候，模型知道大概章节位置，那就用 open 把附近内容展开来看。
这两个工具的分工很清晰：一个偏“定位”，一个偏“阅读”。
summarize 负责控场
当上下文越来越长时，系统不会傻傻地把所有历史都硬塞给模型。
它会保留已经被引用的关键证据，清掉没用的中间过程，让模型可以把注意力集中在真正重要的部分。
论文为什么强调“无需微调”
这篇论文真正想传达的其实是一个系统工程观点：
企业检索问题，不一定非要靠训练一个更复杂的 retriever 才能解决。
它的重点不是“我又发明了一个更强的 embedding 模型”，而是：
·现有企业搜索栈能不能继续用；
·模型能不能在推理时自己调度工具；
·搜索、阅读、总结能不能形成闭环。
这个思路对企业场景特别实用。
因为很多企业系统不是没有搜索能力，而是搜索能力有了，但缺少一个会思考的使用者。
AgenticRAG 做的事情，本质上就是让 LLM 成为这个会思考的使用者。
三个实验看它到底强不强
论文主要在三个数据集上做了验证：BRIGHT、WixQA 和 FinanceBench。
BRIGHT：长文档检索
BRIGHT 更像是长篇资料里的“找对文档”问题。
结果里，AgenticRAG 在 BRIGHT 上拿到了 49.6 recall@1，比最好的 embedding 方法高了 21.8 个百分点。
这个提升很关键，因为它说明：
不是“换个更强 embedding 就够了”，而是“检索过程本身的组织方式”更重要。
WixQA：企业问答
WixQA 更接近真实支持和排障场景。
它考察的不是单句事实，而是多文档、多步骤的 procedural reasoning。
AgenticRAG 在这里拿到 0.96 factuality，明显高于传统检索方案。
FinanceBench：财报问答
FinanceBench 里全是长篇财务文件，平均一份文档一百多页。
AgenticRAG 在这个任务上做到 92% answer correctness，而直接把真实证据喂给模型的 oracle 结果是 94%。
也就是说，它已经非常接近“拿到正确证据时”的上限了。
它为什么比普通方法更有效
我觉得这篇论文最重要的结论不是“多了几个工具”，而是它把检索从一次性动作，变成了一个可迭代的决策过程。
传统方法常常假设：
·问题已经被正确改写；
·检索只要一次就够；
·排名结果一出来，模型就该直接回答。
但 AgenticRAG 的做法是：
·先粗搜；
·再判断；
·再深入；
·不够就换角度；
·需要时压缩上下文继续查。
这套流程更接近人类知识工作者的真实行为。
我们平时查资料也不是“搜一次就结束”，而是会先看目录、再看章节、再追关键词、再回到上下文里确认。
AgenticRAG 的本质，就是把这种行为结构化了。
我更看重的几个工程信号
这篇论文除了实验结果，还有几个很像产品思维的点值得注意。
1. 元数据很重要
文档标题、文件名、类型这些东西，别小看。
它们能帮助模型判断两个看起来很像的 snippet 到底是不是同一个文档脉络。
2. 行号比纯文本更有用
长文档里，知道“在第几行附近”这件事很值钱。
因为模型接下来就能精准跳转，而不是每次都从头翻。
3. 引用 ID 不能丢
一旦做上下文压缩，如果没有可追踪的引用 ID，模型很容易失去前面已经验证过的证据链。
保留引用，意味着它还能继续在原来的证据上往下挖。
4. 简单问题应该走普通路径
不是所有问题都适合 AgenticRAG。
简单问答继续用普通 RAG 就行；复杂、多跳、需要反复确认的问题，再交给 agent 流程。
这个混合路由思路非常实用。
最后怎么理解这篇论文
AgenticRAG 不是在说“RAG 终于被干掉了”，而是在说：
RAG 的关键，不只是检索结果好不好，而是检索过程能不能被模型自己调度。
它把“先搜后答”的固定管道，改成了“边想边搜边读”的动态闭环。
而且它做到了几个很难同时满足的目标：
·不需要重新训练检索器；
·能复用现有企业搜索；
·可以处理长文档和多跳问题；
·在多个基准上都有很强的提升。
如果你是在做企业知识库、文档问答、内部搜索、或者 RAG 系统，这篇论文的价值不只是“结果好看”，而是它给了一种可以落地的架构思路。
