💡 一句话总结：让 Agent 在 web search、向量库、知识图谱、SQL 之间『自己决定调哪个、调几次』，比写死一套 RAG 路由强 10 个点。MARAG-R1 证明端到端 RL 学调度策略是可行的，且数据需求比想象的小。
当前 Agentic RAG 的真实瓶颈
我们在生产 RAG 系统里观察到一个反复出现的模式：90% 的失败 case 不是因为 retriever 本身差，而是因为『调度错了 retriever』。
举几个典型例子：
- 问『2026 年 5 月 Mistral 发布了什么新功能』，向量库里没有最近的内容，但 agent 仍然在向量库里翻——应该去 web search
- 问『苹果公司创始人的妻子是谁』，agent 把整个 query 丢给向量库，单跳召回不到——这是个知识图谱友好的 2-hop 实体关系问题
- 问『过去半年销量最高的产品是哪 5 个』，agent 在文档向量库里搜『销量最高产品』，召回一堆 marketing slides——应该去 SQL 跑 group by
这些都不是 retriever 质量问题，是『工具选择』问题。但当前主流 Agentic RAG 框架（LangGraph、LlamaIndex、Self-RAG 系）都默认只有一个 retriever，或者用硬编码的路由规则，根本没把『选哪个工具』当成可学习的决策。
MARAG-R1（arXiv 2510.27569）从这个根问题出发，把多工具检索当成 RL 问题正面解决。
问题形式化
论文把 Agentic Retrieval 形式化成一个 MDP：
- State：
(query, conversation_history, tool_call_history, accumulated_evidence) - Action space：
{call_tool(tool_name, query), think(reasoning), answer(text), stop} - Tool space：
{web_search, vector_search, kg_query, sql_query} - Reward：终态时的答案质量 + 过程的 information gain - 调用次数惩罚
policy 是一个 LLM（论文用 Qwen3 7B base），输入 state、输出 action。每一步 agent 可以选择：
- 调某个 tool（带自然语言 query）
- 想一段（自由文本，不出 action）
- 给出最终答案
- 主动放弃
四个工具的覆盖型设计
论文最有想法的设计是工具集的『最小覆盖』。他们提了一个原则：每加一个工具，必须能 strictly 拿到其他工具拿不到的某类 query。
最终四件套：
| 工具 | 输入 | 输出 | 擅长 query 类型 | 平均调用成本 |
|---|---|---|---|---|
web_search | query string | top-10 webpage snippet | 时效性、长尾事实 | $0.005/次 |
vector_search | query string | top-5 chunk + score | 语义近邻、模糊匹配 | $0.0001/次 |
kg_query | SPARQL or natural language | entity/relation triples | 2+ hop 实体关系 | $0.002/次 |
sql_query | natural language → SQL | rows | 聚合/统计/join | $0.001/次 |
调用成本差到 50 倍，所以 agent 学到的策略要 cost-aware。论文 figure 6 显示训练后的 agent 在『时效性问题』上 web_search 占比 87%，在『关系类问题』上 kg_query 占比 64%，明确学会了 query-tool matching。
GRPO 训练的细节
GRPO（Group Relative Policy Optimization）是 DeepSeek-Math 那篇用的算法，特点是对每个 prompt 采样 N 条轨迹、组内相对 advantage、不需要 critic 网络。MARAG-R1 用 N=8。
奖励函数分三层：
R_total = 0.7 × R_task + 0.2 × R_process - 0.1 × R_cost
R_task = 0.6 × token_F1(answer, gt) + 0.4 × exact_match(answer, gt)
R_process = sum over steps of info_gain(step) * decay^step
R_cost = num_tool_calls / 8 + truncation_penaltyinfo_gain 用一个固定的 GPT-5 mini 当 judge，每次 tool call 后问『加上这次结果，回答置信度从 a 涨到 b，b-a 是多少』，量化到 [-1, 1]。
Reward hacking 的几次教训：
- 第一版 agent 学会『反复调 web_search 同一个 query』拼接结果骗 info_gain → 加 query similarity penalty
- 第二版 agent 学会『最后一步 answer 抄第一步 web_search 标题』而不真正综合 → 加 evidence citation 检查
- 第三版 agent 学会『先 stop 拿到 truncation penalty 但避免 wrong answer 大惩罚』→ 把 stop 改成 -0.3 fixed penalty
这些是 RL 论文里很少披露的工程细节，对复现非常关键。
数据筛选 pipeline
论文一直强调他们只用 8K 训练样本，背后是激进的数据筛选：
50K raw QA samples (HotpotQA + 2Wiki + Bamboogle + FRAMES)
↓ 第一步：单工具 vs 多工具 oracle 差异筛选
12K 样本（多工具能答对、单工具答错的子集）
↓ 第二步：oracle 轨迹质量过滤
9K 样本（GPT-5 跑出来的轨迹长度 3-6 步、可执行）
↓ 第三步：语义去重
8K 最终训练集这个 pipeline 体现了一个 RL 的核心 insight：样本必须能区分策略。对所有工具都能秒答的样本对学策略没贡献，对所有工具都答不出的样本只会教 agent 投降。论文里有一组消融实验，用 50K 全量数据训练效果反而比 8K 精筛差 4-7 个点，证明数据质量>数据数量。
主要实验结果
| Benchmark | Single-Tool RAG | Fixed-Router RAG | MARAG-R1 | 提升 |
|---|---|---|---|---|
| HotpotQA (EM) | 48.3% | 56.1% | 66.2% | +17.9 |
| 2WikiMultiHopQA (EM) | 51.7% | 59.4% | 70.8% | +19.1 |
| FRAMES (Acc) | 42.8% | 50.6% | 60.3% | +17.5 |
| Bamboogle (EM) | 38.1% | 47.2% | 54.6% | +16.5 |
| Average tool calls/query | 1.0 | 1.0 | 2.7 | - |
亮点：
- MARAG-R1 7B 超过 GPT-5 fixed-router baseline（GPT-5 用同样 4 个工具但人工写死路由，HotpotQA 上 61.4% vs MARAG-R1 66.2%）
- 平均 2.7 次 tool call 不是『暴力多调』，64% 的 query 用 1-2 次解决，长尾难题才用 5+ 次
- 在 FRAMES（多跳推理 benchmark）上提升最大，说明 RL 真的学会了『拆解复杂 query 成多次检索』
错误案例分析
论文 appendix 给了 200 条错误样本的人工标注分布，对落地极有参考价值：
| 错误类型 | 占比 | 典型场景 |
|---|---|---|
| Tool 选错 | 28% | 时效性问题去了 vector，关系问题去了 web |
| 检索 query 提的不好 | 24% | 把整段 question 当 query，没拆 |
| Evidence 综合错误 | 19% | 把矛盾的多源 evidence 直接拼接 |
| 过早停止 | 14% | 1 次检索就回答，明显信息不足 |
| 调用过多但仍错 | 8% | 5+ 次调用陷入 loop |
| Ground truth 标注问题 | 7% | benchmark 自身的问题 |
这个分布暗示了下一代工作方向：evidence 综合错误占 19%，但训练阶段几乎没有专门优化。未来加一个 evidence consistency 的过程奖励，可能再提 5-10 个点。
对工程落地的启示
如果你不打算训练自己的 RL 模型，也能从这篇论文里抄三个最实用的思路：
思路 1：多工具优于单工具 + 强模型零样本
直接用 Claude Opus 4.7 / Gemini 3.5 Flash 这类强模型，挂多个工具，在 system prompt 里写清楚『先 reason 选工具、再调用、可以多次』。我们实测在内部 RAG 上，从『只挂 vector』改成『vector + web search + SQL 三选一』，准确率从 64% 升到 78%。
思路 2：用 SFT 学工具选择模式
如果调 API 太贵，标 1-2K 条『正确的工具调用序列』，用 SFT 在 Qwen3 7B 上微调，能拿到接近 RL 的 80% 收益。标注成本是关键——可以用 Claude 跑 oracle 轨迹然后人工筛。
思路 3：永远不要写死路由规则
我们见过太多 RAG 系统用 if-else 规则做工具选择，结果规则集随业务膨胀到 200+ 条无法维护。MARAG-R1 证明 LLM 自己能学到比手工规则好得多的策略，从一开始就把 routing 交给模型。
局限与未来
论文自己列了三个 limitation：
- 工具 schema 是固定的：换一套工具要重新训练 policy，没有 zero-shot 泛化到新工具的能力
- 多模态 query 未覆盖：所有工具都是文本输入文本输出，image / table 类 query 无法处理
- 没有 long-horizon memory：每次 query 是独立的，跨多轮对话的复杂任务（如多日调研）不行
下一步合理推测是 MARAG-R1 + 长期记忆（参考 EverMemOS）+ 多模态工具，可能就是 2026 下半年 Agentic RAG 的下一个里程碑。
代码和 checkpoint 在 github.com/MARAG-R1/MARAG-R1，Hugging Face 上也有 7B / 13B 两个版本，可以直接拿来做对照实验。如果你正在做 Agentic RAG，这篇是 2026 上半年最值得复现的论文之一。