大家好，我是晴天。今天为大家分享微软 Copilot Studio 团队最新的一篇论文——AgenticRAG。

论文链接：[2605.05538] AgenticRAG: Agentic Retrieval for Enterprise Knowledge Bases
作者：Susheel Suresh, Hazel Mak, Shangpo Chou 等（Microsoft）
发表时间：2026 年 5 月

---

🔥 标准 RAG 的根本问题

传统 RAG 架构的逻辑很直观：

用户提问 → 搜索系统检索相关文档 → 把文档塞进 prompt → LLM 生成答案

这个架构有一个被广泛忽视的根本假设：检索决定在 LLM 开始推理之前就已经做完了。

LLM 接收的是一个固定的文档候选集，没有机会说：

• "这个文档看起来有用，让我进去翻一翻"

• "这几条结果都不对，让我换个角度再搜一次"

对于简单的知识查询（比如"Python 的 list 怎么反转"），这个架构完全没问题。但在企业场景里，知识工作者的查询往往更加复杂，比如：

查询类型	新示例
技术调试	"Kubernetes Pod 一直 Pending，怎么排查资源配额问题？"
数据分析	"去年 Q4 的 AWS 账单里，EC2 实例占了多少比例？"
流程咨询	"新员工入职账号开通需要走哪些审批流程？"

这些查询有两个核心特点：

1. 高度情境化：需要结合多个上下文才能理解真实意图

2. 答案分散：答案往往分散在多份长文档的不同章节里

标准搜索栈擅长关键词匹配和简单查询，但处理不了这种需要多步推理的复杂信息需求。

HyDE、查询改写、多路召回、重排序……这些增强技术确实提升了检索覆盖度，但它们都保留了同一个架构假设：检索决策在推理开始前就已经定好了。

---

💡 AgenticRAG 的核心思想

AgenticRAG 的核心思想极其朴素：不要让搜索系统替 LLM 做决定，给 LLM 工具，让它自己决定搜什么、看什么、翻到哪里。

具体来说，论文在现有企业搜索栈之上，加了一层轻量级的 Agent 工具框架，包含四个工具：

四个工具详解

工具	功能	关键特性	适用场景
search	企业级文档发现	最多并行 5 条查询改写，返回 snippet+ 元数据+reference ID	初步广泛候选发现
find	文档内精准搜索	给定 reference ID + 关键词模式，支持词汇/语义匹配	"知道要找什么"（比如找某个配置参数）
open	滚动窗口文档阅读	每次 1800 行窗口，可指定行号跳转	"知道要看哪里"（比如某个报错日志附近）
summarize	上下文压缩	128K 预算时触发，选择性保留引用 ID	token 爆炸时合并发现

推理循环设计

整个系统运行在一个有界迭代循环中（默认最多 15 轮）：

每一轮： LLM 看到对话历史 + 工具 schema ├─ 选择调用工具 → 追加结果到对话 → 继续下一轮 └─ 直接输出最终答案 → 终止

终止条件只有两个：

1. 模型主动输出文本回答

2. 达到最大迭代次数，强制生成回答

这个设计有一个关键优势：完全不需要模型微调、自定义嵌入模型、图构建或语料预处理。只要企业搜索栈已经把文档索引好，直接套上这个工具框架就能用。

---

🔬 方法细节

搜索结果如何被利用

search 返回的是snippet 预览，不包含完整文档内容。这意味着模型看到搜索结果后，需要做出判断：哪些文档值得深入查看？用什么方式查看？

这里有两个精度工具可以选：

场景	工具	示例
"知道要找什么"	find	"在这份 API 文档里找到 rate_limit 这个参数"
"知道要看哪里"	open	"打开这个日志文档的第 300 行附近，看看那个错误码说明"

论文通过 system prompt 引导模型正确使用工具：

• "先搜索再回答"

• "片段不够就用 find 或 open 深入"

• "不要重复搜索，复用之前的结果"

多查询并行搜索

search 工具的一个设计亮点：模型可以在一次 tool call 中同时发出最多 5 条查询改写，结果去重后合并返回。

消融实验表明：

• 性能影响几乎为零：44.84% vs 49.59%

• 效率显著提升：平均工具调用从 6.79 降到 4.79，减少 29%

多条查询并行执行比多轮串行更节省迭代次数。

上下文管理机制

四个工具中，每次调用可以加载约 11K token 的文档内容。如果推理链很长，128K 的上下文窗口很容易被用完。

AgenticRAG 的解决方案是两阶段触发：

对话达到 90% 预算 (115.2K) → 发出内部警告 对话达到 100% 预算 (128K) → 强制触发 summarize

summarize 的核心机制不是简单截断，而是选择性保留：

• 模型标注哪些引用 ID 需要保留

• 系统扫描工具消息，删除未被引用的内容

• LLM 可以持续深入调查，不用担心上下文爆炸

---

🎯 Claude 和 GPT-5-mini 的策略差异

论文在消融中发现了一个有趣的现象：两个模型展现了不同的"探索 - 利用"策略。

策略倾向	Claude Sonnet 4.5	GPT-5-mini
总体风格	偏利用 (Exploitation)	偏探索 (Exploration)
search 调用	2.51 次	3.39 次
open 调用	1.54 次	1.22 次
语义 find	0.42 次	0.14 次 (3 倍差异)
策略总结	搜少量候选 → 选最相关的深入阅读	广撒网 → 多条改写查询覆盖

在 BRIGHT 长文档场景中（每个查询平均只有约 1.9 个相关文档，分散在 5650 个长文档中），利用策略更有效：

• Claude 在 8 个领域中 7 个领先 GPT-5-mini

• 总体 recall@1 高出 6.1 个百分点

---

📊 效果：5.9 倍提升从哪里来

BRIGHT 长文档检索

方法	recall@1
BM25	11.4%
Qwen 嵌入	27.8%
Voyage 嵌入	24.5%
ReDI（推理增强）	26.0%
AgenticRAG + GPT-5-mini	43.5%
AgenticRAG + Claude Sonnet 4.5	49.6%

Claude Sonnet 4.5 比最优嵌入基线高出 21.8 个百分点。在经济学、地球科学、机器人学领域，提升超过 30 个百分点。

关键消融：单次搜索 vs Agent 工具

配置	recall@1
单次搜索（底层企业搜索栈）	8.41%
+ 完整 Agent 工具（Claude）	49.59%
+ 完整 Agent 工具（GPT-5-mini）	43.49%
提升倍数	5.9× / 5.2×

这是论文最重要的发现：底层搜索栈的质量差异在 Agent 能力面前几乎消失了。不需要换更好的嵌入模型、不需要训练重排序器——给 LLM 工具让它自己推理就行。

WixQA 企业 QA

在需要多文档推理的企业支持场景中：

• GPT-5-mini + AgenticRAG 达到 0.96 的事实性分数

• 比最佳基线（E5 嵌入，0.85）相对提升 13%

• 在模拟查询集上，提升更大：0.94 vs 0.77，相对提升 22%

FinanceBench 财报问答

84 份长篇财报（平均 143 页、117K token）：

• GPT-5-mini + AgenticRAG 达到 92% 正确率

• Oracle（直接给真实证据）的正确率是 94%

• AgenticRAG 仅差 2 个百分点，几乎摸到了理论上限

Token 成本

指标	BRIGHT
平均 token 使用	52.3K/query
单次搜索 token	20.4K/query
成本倍数	2.6×
召回提升倍数	5.9×
平均工具调用	4.48-4.79 次

2.6 倍开销换来 5.9 倍召回提升——这个性价比相当不错。

---

💻 观点：预生产部署的四条设计经验

论文最有价值的部分之一，是微软从预生产部署中总结的四条设计经验：

1. 搜索结果展示文档元数据

标题、文件名、文件类型帮助模型区分语义相似的 snippet，避免重复搜索。比如看到"config.yaml"和"config.json"就知道是两个不同的配置文件。

2. 行号预览

让模型锚定内容位置，在后续 open 调用中精准跳转。比如看到"第 450 行"就能直接定位到对应代码段。

3. 摘要后保留引用 ID

压缩上下文后，模型仍然可以继续深入调查之前发现的高价值候选。不会因为上下文清理就丢失了之前的发现。

4. 混合路由

查询类型	路由策略	理由
简单查询	传统 RAG	快、便宜
复杂查询	Agent RAG	慢、准

这是生产环境的关键取舍。如果做企业知识库，这个路由策略可以直接参考。

---

🚀 总结

AgenticRAG 的核心贡献是系统级创新：一个轻量级的推理时工具 harness，让推理 LLM 能够自主驱动检索过程。

优势	说明
性能提升显著	BRIGHT +21.8 pp, WixQA +13%, FinanceBench 92%
部署友好	无需微调，复用现有搜索基础设施
企业适配	保留文档访问控制，无需语料导出训练
效率可接受	2.6× token 成本带来 5.9× recall 提升

这篇文章为企业级 RAG 系统提供了一个可实际部署的新范式，特别适合需要深度多步推理的复杂信息检索任务。

这篇论文已经在微软 Copilot Studio 进入预生产评估。从学术结果到产品落地，间隔可能比想象的更短。如果你正在做 RAG 相关的开