AgenticRAG 的工程拐点

企业知识库里的 RAG，最容易翻车的地方，往往不是模型不会写答案，而是第一把检索没把证据捞上来。

用户问一句“这个条款在什么情况下适用”“某家公司利润率变化主要来自哪里”“排障步骤里前置条件是什么”，系统需要先从几千篇、几万篇内部文档里切出候选片段。传统 RAG 会把这批 snippet 一次性交给模型，然后期望模型基于这小包上下文给出可靠回答。

问题是，企业问题很少这么配合。一个答案可能散在产品手册、支持文档、财报 PDF、合规条款和历史邮件导出的知识页里；一个关键数字可能要先找到章节，再跳到表格，再回头读定义；一次检索返回的片段看起来相关，放回完整文档里却可能是反例、旧版本，或者只覆盖了条件的一半。

微软这篇 AgenticRAG 的思路很工程化：不要逼搜索栈在第一步做完所有判断。搜索栈负责高召回候选发现，推理模型负责后续精读、跳转、补证据和合并线索。它没有训练新模型，也没有要求企业重建知识图谱，而是在已有搜索基础设施之上，加了一层轻量级的 Agent harness。

一、RAG 的压力不该全压在第一把检索上

很多企业 RAG 系统的默认假设是：只要 embedding 足够好、rerank 足够强、chunk 切得足够聪明，模型就能拿到正确上下文。

这个方向当然有价值，但它把太多压力压在检索链路上了。

传统流水线大致是这样：

这套结构在 FAQ、短文档、事实型问答里很好用。用户问“某个功能在哪里配置”，搜索结果如果命中了对应帮助页，模型很快就能组织出答案。

但企业复杂问答经常不是一次检索能打穿的。它有几个典型特征：

真正麻烦的是，传统 RAG 只有一次“找证据”的机会。第一把检索如果偏了，后面模型语言能力再强，也只是在错误上下文里写得更流畅。

AgenticRAG 的调整点就在这里：把检索从一个前置步骤，改成一个可循环的阅读过程。

二、从一次检索到工具化阅读

AgenticRAG 更像一个会查资料的人。

它不会只看搜索结果第一页截图就开始写答案，而是会先搜索候选文档；发现不够，就进入某篇文档里找关键词；命中位置后，再打开附近上下文阅读；证据太多时，先压缩成工作记忆；最后带着引用输出答案。

微软把这套 harness 拆成四个工具：

• search：在企业语料库中发现相关文档，支持多条查询改写，每条最多返回 10 个候选，并做去重。
• find：在某个候选文档内部按关键词或语义模式定位片段，每个 pattern 最多返回 2 段，整体有 token 上限。
• open：打开某个文档的固定行窗口，默认每次读 1800 行，也可以从指定行号附近继续读。
• summarize：当上下文快满时，把已获得线索压缩成工作记忆，并保留关键 reference ID。

这张图里最重要的点，不是“Agent”这个名字，而是闭环。

模型每一步都会看到当前对话、已有工具结果和引用标识，然后自己决定下一步动作：继续 search，还是对某个文档 find，还是 open 深读，或者已经足够回答。

可以把它抽象成下面这个流程：

论文设置的默认最大迭代次数是 15。达到上限后，系统会强制模型基于已有信息完成回答。

如果上下文使用量接近 128K token 阈值，系统会触发 summarize，保留重要证据和引用，删除无关工具结果。这个设计很实在：让模型能持续查资料，同时不被上下文撑爆。

三、四个工具的真实分工

AgenticRAG 的工具并不复杂，甚至有点朴素。但企业系统里，朴素往往是优点。因为工具越简单，越容易做权限、日志、审计、超时和回放。

search：先把候选面铺开

search 对接已有企业搜索后端。在默认配置下，模型一次调用里最多可以给出 5 个 query reformulations。

比如用户问某家公司利润率变化，模型可能同时搜索：

• 指标名；
• 同义表达；
• 公司名 季度；
• 报表字段；
• management discussion 里的解释性文字。

每条查询最多返回 10 个结果。系统合并、去重，并给每个结果分配全局唯一 reference ID，格式类似 turnmsearchn。

这个 ID 很关键。后续 find 和 open 都基于它继续操作，避免模型只靠模糊标题引用文档。

多查询搜索主要提升效率。论文消融显示，去掉 multi-query search 后，Recall@1 没有明显崩掉，但平均工具调用从 4.79 上升到 6.79。也就是说，多查询让模型少绕路，用更少回合找到差不多质量的证据。

find：在长文档里快速定位

find 解决的是另一个现实问题：候选文档很长，但模型已经知道要找什么。

比如在一份财报里找 operating margin、capital expenditure、revenue growth；在支持文档里找 prerequisite、limitation、billing plan。

论文里的 find 默认是大小写不敏感的 substring matching，也可以启用 semantic find。每个 pattern 最多返回 2 个匹配片段，结果会去重，并截断在约 11K token 以内。

它不是为了替代全文阅读，而是把阅读位置缩小到关键区域。

这个动作很像人类读 PDF：先 Ctrl/Cmd F，找到大概位置，再回到上下文里判断含义。

open：从命中片段回到上下文

传统 RAG 经常给模型一段局部 chunk。问题是，企业文档里的关键判断往往藏在片段前后：

• 定义在上一节；
• 例外在下一段；
• 数字单位在表格脚注；
• 条款适用范围在章节标题；
• 当前内容可能属于旧版本说明。

open 的价值在于，它让模型从“命中一段文字”进入“阅读一段文档”。

默认每次返回 1800 行，并告诉模型当前查看的是哪一段，比如：

Viewing lines [0-1799] of 3000 lines

模型可以根据标题、表格、上一轮 find 的位置，继续从某个行号附近打开。

这一点对 PDF、手册、合规条款尤其重要。很多时候，不是模型不知道怎么推理，而是它根本没看到完整条件。

summarize：长链路里的安全阀

当模型反复 search、find、open，工具结果很快会堆满上下文。

AgenticRAG 在对话达到 90% token budget 时发出内部警告，到阈值时强制 summarize。

这里的摘要不是普通“总结一下”。它会要求模型记录当前推理状态，并指定需要保留的 reference ID。系统随后扫描工具消息，删除未被保留引用关联的内容。

这个设计看起来不如 Recall@1 那些数字亮眼，但在生产环境里很关键。

BRIGHT 这类单轮 benchmark 上，去掉 summarize 影响不大，因为很多任务还没跑到上下文极限。但真实企业问答往往有多轮追问，用户还会不断引用前文。系统能不能稳定跑久，很大程度取决于这种上下文压缩和引用保留机制。

四、企业 RAG 为什么更需要这套机制

公开网页搜索里，很多问题本来就可以靠一两个高质量页面回答。企业知识库更麻烦。

第一，企业文档长。

FinanceBench 里的金融文档平均约 143 页、约 11.7 万 token。BRIGHT 长文档设置里，Stack Overflow split 的平均文档长度超过 4 万 token。

这些内容一旦预切成 chunk，结构信息很容易被打散。标题、表格、上下文边界、脚注和版本说明，都会变得不稳定。

第二，企业问题常常是 situational query。

用户不会只问“定义是什么”，而是问：

如果 A 条件成立，但 B 步骤还没完成，这个流程该怎么走？

这类问题需要跨段落、跨文档、跨术语对齐。一次语义检索很容易找到相似文章，却漏掉关键前置条件。

第三，企业系统需要证据链。

回答要能指向文档、章节、引用，不能只给一个自然语言结论。AgenticRAG 里的 reference ID、line-numbered preview、candidate reference retention，本质上都是围绕“回答可追溯”设计的。

很多团队做到企业知识库这里会卡住：模型回答越来越像样，但用户一追问“依据在哪”，系统就开始虚。AgenticRAG 的价值不是让回答更会说，而是让回答能沿着证据链回放。

五、实验结果说明了什么

微软在三个任务上验证了 AgenticRAG：BRIGHT 长文档检索、WixQA 企业支持问答、FinanceBench 金融长文档问答。

这些实验覆盖了三个不同维度：

• 能不能找到正确文档；
• 能不能回答复杂支持问题；
• 能不能在金融长文档里找到并使用正确证据。

BRIGHT：长文档检索的收益很明显

BRIGHT 是 reasoning-intensive retrieval benchmark。论文使用 long-context setting：文档是完整网页，而不是预切片段。

数据覆盖 8 个领域：

• Biology
• Earth Science
• Economics
• Psychology
• Robotics
• Stack Overflow
• Sustainable Living
• Pony

总计 861 个 query、5650 篇文档，平均文档长度约 16280 token。Stack Overflow split 的文档尤其长，平均超过 40700 token。

核心指标是 Recall@1，也就是系统排第一的文档是否命中 gold document。

AgenticRAG with Claude Sonnet 4.5 达到 49.6% 平均 Recall@1，比 Qwen Embedding 的 27.8% 高 21.8 个百分点。GPT-5-mini 达到 43.5%，也高出 15.7 个百分点。

这个提升的原因并不神秘：在大语料、长文档、相关文档稀疏的场景里，一次检索很难把候选排准。模型通过多轮工具调用，可以先粗筛，再深入打开少量高价值文档。

但 Pony split 是个提醒。

Pony 的平均 gold docs 是 6.9，而 BRIGHT 整体平均只有 1.9。AgenticRAG 在这个 split 上仍然吃力，Claude 只有 7.1，GPT-5-mini 只有 4.8。

这说明当前 harness 更擅长深挖少数关键证据，不天然擅长“找全所有相关资料”。如果业务目标是资料汇编、竞品调研、知识盘点，可能需要 coverage-aware planning，而不能只靠深挖策略。

WixQA：企业支持问答更接近真实落地

WixQA 更接近企业客服和支持文档场景。问题通常是 procedural query，需要多步推理和多文章依赖。

论文使用两个子集：Expert Written 和 Simulated，每个都是 200 个 query。知识库规模是 6221 篇领域帮助文章。

在 Expert Written split 上，AgenticRAG with GPT-5-mini 的 factuality 达到 0.96。对比基线：E5 retrieval 是 0.85，BM25 是 0.83。

这个结果的意义不是简单“换了更强模型”。从图里可以看到，同样的生成模型配不同检索方式，agentic retrieval 普遍更稳。

支持问答要求模型先找到正确流程、前置条件、限制说明，再组织成回答。一次检索如果命中错误文章，或者漏掉一个依赖步骤，最终答案就可能不完整。

Simulated split 上差距更大。论文附录给出的结果是，AgenticRAG 达到 0.94 factuality，而 E5 GPT-4o 与 BM25 GPT-4o 都是 0.77。

这类问题通常更需要拆解。单条语义检索容易把最相关的一篇文档找出来，却漏掉完成答案所需的第二篇或第三篇。

FinanceBench：接近 oracle evidence 上限

FinanceBench 是更硬的长文档任务。

问题来自公开公司 filings，包括 10-K、10-Q、8-K 和 earnings reports。论文使用 150 个问题、84 份 ground documents；每份文档平均约 143 页、约 116715 token。

最扎眼的是 92.00%。

Oracle evidence 的意思是：直接把正确证据页给模型，跳过检索过程。AgenticRAG 距离这个上限只差 2 个百分点。

这说明一个很关键的变化：瓶颈从“模型会不会回答”，大幅转向“系统能不能把证据找对”。

金融文档里的问题常见两类：一类是找到某个 line item 或 ratio，另一类是解释 margin 变化、资本开支、收入结构。前者考验定位，后者考验上下文阅读和关系推理。

传统 RAG 的 24.24% 很像真实工程里的尴尬状态：模型语言能力够强，但证据没给对。

六、质量提升不是免费的

AgenticRAG 的代价主要是 token 和延迟。

论文统计了 end-to-end token cost，包括系统提示词、工具调用参数、工具结果、thinking tokens 和最终回答。

在 BRIGHT 上，AgenticRAG 平均每个 query 消耗 52.3K token；Single-shot Search 是 20.4K，成本约 2.6 倍。

但质量收益也很大：Claude Sonnet 4.5 with AgenticRAG 的 Recall@1 是 49.6%，Single-shot Search 只有 8.41%。

FinanceBench 更贵。AgenticRAG 平均每个 query 消耗 114.8K token，Single-shot 是 14.7K，成本约 7.8 倍。这也符合直觉：金融 PDF 长，问题需要深读，模型要打开更多上下文。

所以 AgenticRAG 不适合无脑替代所有 RAG。

更合理的做法是加一个 query router：

这是一个典型工程权衡：用更高 token、更长延迟，换更可靠的证据链。

如果业务是客服秒回，所有问题都走 AgenticRAG 可能体验很差；如果业务是法务条款问答，省这点成本反而可能不划算。

七、消融实验暴露了关键变量

论文的消融结果很有意思，因为它能帮助我们判断到底是哪部分在起作用。

最大贡献来自“从 single-shot search 切换到 agentic tool use”。

Single-shot Search 平均 Recall@1 只有 8.41%；完整 AgenticRAG with Claude Sonnet 4.5 达到 49.59%，with GPT-5-mini 达到 43.49%。

多查询搜索主要提升效率。去掉 Multi-query Search 后，GPT-5-mini 平均 Recall@1 是 44.84%，看起来还略高一点，但平均工具调用从 4.79 增到 6.79，search 从 3.39 增到 4.38，open 从 1.22 增到 2.16。

也就是说，质量接近，但绕路更多。

去掉 summarize 对 BRIGHT 影响很小，43.34% vs 43.49%。这不能说明 summarize 没价值，只能说明 BRIGHT 多数样本还没跑到上下文极限。真实企业会话里，summarize 更像生产安全阀。

更值得注意的是 semantic find。

去掉 semantic find 后，结果反而提升到 46.34%。论文解释是，lexical find fallback 对大多数文档内搜索已经够用，去掉 semantic find 可能降低延迟，让系统在同等预算里做更多 search/open。

这点很实用。企业系统里，别一上来就把所有工具做成最复杂版本。关键词、文件名、章节标题、行号这些老派工具，经常比花哨的语义定位更稳定、更可解释。

八、模型行为也会影响检索轨迹

论文还比较了不同模型使用工具的模式。

Claude Sonnet 4.5 更偏 exploitation：search 调用更少，open 更多，semantic find 更多。它倾向于选中候选后往深处读。

GPT-5-mini 更偏 exploration：search 调用更多，更倾向于改写查询、扩大候选面，而不是在单篇文档里反复 find。

这不是简单的高下问题，而是策略差异。

BRIGHT 里很多 query 的 gold document 很少，深挖高质量候选更占优势。如果任务是找全多份证据，广搜策略反而可能需要被加强。

产品上可以把这种差异显式变成策略：

• 证据稀疏、答案集中：鼓励 open 和 find；
• 证据分散、需要覆盖：鼓励更多 search 和候选聚合；
• 成本敏感：限制 open 次数，优先 find；
• 准确性敏感：允许更多窗口化阅读和二次验证；
• 用户要求“列出所有相关资料”：切换覆盖优先轨迹。

真正做系统时，不能只问“哪个模型更强”。更重要的是：这个模型倾向用什么方式查资料，它的工具调用习惯和你的业务目标是否匹配。

九、上线时最该关注的四个细节

论文里的 pre-production deployment 经验，比一些 benchmark 数字更值得工程团队看。

搜索结果要暴露元数据

标题、文件名、文件类型、版本、更新时间、部门、权限范围，这些 metadata 能帮助模型区分语义相近的 snippet。

企业文档里同名文件、旧版本、草稿、归档资料很多。没有 metadata，模型很容易把“历史说明”当成“当前规范”。

文档预览要有行号

Line-numbered preview 让模型可以锚定位置，下一次 open 直接跳到附近，而不是每次从头读。

这对长 PDF、财报、手册、日志类文档都很关键。

summarize 后要保留 reference ID

如果摘要只保留自然语言结论，不保留引用 ID，模型后续就没法继续打开原文。

保留 reference ID，本质上是保存书签。

这件事看起来小，但很多系统的上下文压缩会把引用关系压没，结果模型越聊越像“凭印象回答”。

必须有复杂查询路由器

简单问题进传统 RAG，复杂多意图查询进 AgenticRAG。

这个 hybrid approach 才能平衡体验、成本和模型可用性。

一个比较合理的路由判断可以包括：

• query 长度和条件数量；
• 是否出现比较、原因、前置条件、例外、影响等复杂意图；
• 是否需要多文档证据；
• 是否属于高风险业务域；
• 用户是否要求引用或出处；
• 历史检索置信度是否低。

十、它和 GraphRAG、Self-RAG 的位置不同

近两年 RAG 改进路线很多。

GraphRAG 强调先建知识图谱；RAPTOR 强调层级摘要树；Self-RAG 和 Corrective RAG 强调自评估与回退；PlanRAG、Search-o1 强调规划与搜索结合。

AgenticRAG 的位置更朴素：它是 inference-time harness。

企业文档已经在搜索后端里，模型只需要通过工具去查、找、读、总结。

这条路线牺牲了一些离线结构化收益，但换来几个工程优势：

• 不需要为每个企业语料构建专用图谱；
• 不需要训练或微调模型；
• 不需要大改现有权限和搜索系统；
• 语料更新快时，不必反复跑昂贵预处理；
• 可以按 query 复杂度动态启用；
• 更容易和现有审计、权限、日志体系结合。

如果企业文档高度结构化、关系稳定，GraphRAG 可能更适合。

如果文档变化快、权限复杂、已有搜索系统很强，AgenticRAG 这类轻量 harness 更容易落地。

这里没有绝对路线。工程上更常见的答案是混合：基础搜索做召回，图谱处理稳定关系，AgenticRAG 负责复杂查询的动态取证。

十一、几个更现实的落地判断

AgenticRAG 最适合作为高价值查询通道。

FAQ、短事实、单文档简单问答，用传统 RAG 更便宜。多文档、长文档、强引用需求，再交给 AgenticRAG。

工具返回格式比工具数量更关键。

reference ID、行号、文件 metadata、窗口范围、引用保留，这些字段决定模型能不能稳定规划下一步。很多失败不是模型不会推理，而是工具结果没有给它“可继续行动”的把手。

成本控制要内建在轨迹里。

最大迭代次数、每次 open 行数、find 返回片段数、search query 数、summarize 阈值，都应该成为可调参数。不同业务线可以有不同预算。

评测不能只看最终答案。

还要看：

• 证据命中率；
• 工具调用轨迹；
• 无效 open 比例；
• 重复 search 比例；
• 引用是否真的支撑答案；
• 超时率和平均 token 成本；
• summarize 后证据是否丢失。

否则系统可能“答对了”，但证据路径不可复现。对于企业系统，这种正确性并不稳。

简单关键词工具仍然有生命力。

semantic find 的消融结果提醒了一件事：复杂语义工具不一定总带来收益。企业系统不要低估 lexical search、文件名、章节标题、行号这些基础能力。

十二、边界也很清楚

AgenticRAG 的第一类局限是成本。

它靠多轮工具调用换质量，FinanceBench 上 7.8 倍 token 成本不是小数。生产系统必须做 query routing、预算控制、超时兜底和缓存。

第二类局限是 broad evidence retrieval。

Pony split 说明，当一个问题需要找很多份相关文档时，当前 harness 的深挖策略不够理想。未来可能需要 coverage-aware planning，先判断需要覆盖多少证据，再决定 search/open 比例。

第三类局限是工具和搜索后端强相关。

论文里的效果建立在可用的企业搜索、文档窗口读取、reference 追踪之上。如果后端索引质量差、文档解析乱、权限元数据缺失，Agent harness 也很难凭空补救。

第四类局限是评测场景还不等同于完整企业上线。

真实系统里会有多轮对话、用户打断、文档权限变化、旧版本污染、敏感信息过滤、延迟 SLA、审计要求。论文已经给出 pre-production 信号，但大规模部署还需要更多观测。

AgenticRAG 没有把企业 RAG 神秘化。它承认已有搜索栈很重要，也承认推理模型现在更会用工具，于是把两者分工重新摆了一下：搜索负责召回，模型负责逐步取证。

对做企业知识库的人来说，这比单纯“换一个 embedding 模型”更有启发。很多 RAG 系统卡住，embedding 能力只是原因之一，更大的结构性问题是：系统强迫检索在第一步就完成所有困难决策。

AgenticRAG 给了另一种结构：允许模型像人一样，一边查，一边读，一边修正搜索目标。

论文里 49.6% BRIGHT Recall@1、0.96 WixQA factuality、92% FinanceBench correctness 这些数字很亮眼，但更值得关注的是 FinanceBench 里的接近 oracle evidence 上限。

这意味着，只要工具链能把证据找对，现有推理模型已经接近可用。

下一步真正要拼的，是谁能把“找对证据”这件事做得稳定、可控、便宜。[DONE]