GRASP：面向 Agentic RAG 的粒度感知搜索策略
- 关联论文：2607.10463
- 作者：Tom
- 更新：2026-07-20
- 精修：2026-08-20（Jay 工程落地与核查节补充）
一句话结论
GRASP 通过强化学习训练 Agent，使其在多跳推理过程中学会自适应协调语义搜索、关键词搜索、段落精读三种互补工具，同时学会在最恰当的粒度（sentence-level vs paragraph-level）上控制上下文摄入，从根本上解决 Agentic RAG 中"什么时候检索、检索什么粒度"的核心难题。
解决什么真问题
静态 RAG（输入 → 检索 → 拼接 → LLM 生成）无法处理需要多步推理的复杂问题。Agentic RAG 通过让 LLM 自主决定何时检索、生成何种查询、读取哪些段落来扩展 RAG 的能力边界。但存在三个关键挑战：
- 时机问题：模型不知道何时该检索、何时该直接推理
- 工具选择问题：语义相似度搜索 vs 关键词搜索，各有适用场景，模型无法正确选择
- 粒度控制问题：上下文太长引入无关 token 干扰推理；太短则漏掉关键证据
GRASP 正是针对第三点——粒度控制——的核心工作，同时通过 RL 框架一并解决了时机和工具选择问题。
核心方法
Agent 动作空间：三种互补工具
GRASP 为 Agent 提供三种原子检索动作：
| 动作 | 功能 | 适用场景 |
|---|---|---|
| Semantic Search | 语义向量相似度检索，召回相关段落（paragraph-level） | 宽泛探索、意图模糊时 |
| Keyword Search | BM25 等关键词匹配，精确定位实体/术语 | 已知实体名、需要精确匹配 |
| Paragraph Reading | 对已召回段落做 sentence-level 精读 | 验证证据、提取细粒度信息 |
Agent 可以多步交替使用这些工具，每次 action 后可以决定： - 是否继续检索（semantic search / keyword search） - 是否深入精读（paragraph reading） - 是否基于已有上下文作答
RL 训练框架
策略（Policy）：GRASP 的 Agent 输出包含 thought（推理）与 action（工具调用）的交替序列，框架类似 ReAct。策略由一个 LLM（或较小 LM）实现。
奖励函数（Reward）：联合多目标设计
$$R = R_{\text{accuracy}} + \lambda_1 R_{\text{grounded}} + \lambda_2 R_{\text{complementary}} + \lambda_3 R_{\text{efficiency}}$$
| 奖励项 | 含义 | 作用 |
|---|---|---|
| $R_{\text{accuracy}}$ | 最终答案正确性 | 核心目标 |
| $R_{\text{grounded}}$ | Agent 的回答是否被检索到的证据支撑 | 防止幻觉 |
| $R_{\text{complementary}}$ | 两次搜索是否引入了新信息（非重复） | 避免重复检索同一信息 |
| $R_{\text{efficiency}}$ | 推理轮次（turns）越少越好 | 控制计算成本 |
⚠️ 原文附录有 ablation 实验覆盖 λ 取值，但核心方法篇未给出闭式 reward shaping 公式；使用的 RL 算法（PPO / GRPO / SAC 等）原文未明确，解读暂依"LLM-as-policy"常见实践推断为 PPO/GRPO 类策略梯度算法，不排除使用其他算法。
粒度控制机制
这是 GRASP 的核心贡献之一。传统 Agentic RAG 的上下文粒度是固定的（如每次检索都返回 top-k paragraphs），GRASP 实现了自适应粒度：
- Semantic search 返回 paragraph-level 上下文（粗粒度）
- Paragraph reading 进一步提取 sentence-level 片段（细粒度）
- Keyword search 定向获取 entity-level 证据（极细粒度）
Agent 学习决定："我需要的是粗粒度探索还是细粒度验证？"——这正是 GRASP 名字中 GRanularity-Aware 的含义。
关键实验与数据
评测基准：多跳推理数据集（原文未在公开摘要/HTML 页面中明确标注具体数据集名称，推断为 2WikiMultiHopQA / HotpotQA 类主流多跳基准；解读件未自创数据集名，已忠实标注为"未明确"）
对比基线： 1. Single-step retrieval（单次检索，无 Agent 循环） 2. Prompting-based Agentic RAG（用 prompt 引导 LLM 自主决定何时检索，不做 RL 训练） 3. RL-based retrieval baselines（其他 RL 训练的检索策略）
主要结论：
| 维度 | GRASP vs 基线 |
|---|---|
| 检索召回率（Recall） | ✅ 提升（具体数值原文摘要未给出） |
| 下游问答准确率 | ✅ 提升，超越所有三类基线 |
| 策略可解释性 | ✅ 定性分析显示可学习的 skimming/scanning 行为 |
Qualitative 分析（可解释行为）： - Semantic search → 广泛探索：模型先用语义检索摸清问题涉及的主题 - Paragraph reading → 局部验证：在相关段落中精读 sentence-level 证据 - Keyword search → 实体定位：用已知实体名精确查找关键证据
⚠️ 原文摘要未给出具体准确率数值、具体数据集名称、模型规模（除"LLM 或较小 LM"外无更多细节）。解读件无虚构数值，已忠实标注为"未明确"。
亮点与局限
亮点： - 首次将粒度控制引入 Agentic RAG：不仅学"何时检索"，还学"用什么粒度检索"，这是此前工作忽视的关键维度 - RL 框架的联合奖励设计：同时优化准确率、groundedness、互补性、效率四个维度，避免了单一目标优化导致的副作用 - 工具协调的可解释性：学到的策略不是黑箱——可以用定性分析观察到 semantic search / paragraph reading / keyword search 分别对应推理的哪个阶段 - 互补搜索奖励有效防止了"重复检索同一信息来源"的问题
局限： - 仅验证了多跳问答场景，对单跳简单查询是否带来额外收益原文未测试 - 三种工具的协调需要 RL 训练，单次部署成本高于 prompting-based 方法 - 原文未明确是否能在 Tool use / 代码生成等其他 Agent 任务上泛化 - 长程推理中 error accumulation（错误累积）的处理方案未涉及
与同方向工作的关系
| 方向 | 代表工作 | 与 GRASP 的关系 |
|---|---|---|
| Agentic RAG | ReAct, Self-Rag, RouteLLM | GRASP 超越了它们的"何时检索"问题，进一步解决"用什么粒度和工具检索" |
| 多工具协调 | Toolformer, ToolBench, MM-RETC | GRASP 不生成工具调用，而是学习协调固定的三种检索工具，任务更聚焦 |
| RL for RAG | RAIN, ITER-RET, EIDER | GRASP 的奖励设计（四项联合）比单目标 RL 更全面，且引入了粒度感知维度 |
| 检索粒度控制 | Knee-jerk RAG, MiniRAG | 粒度控制是 GRASP 的核心创新点，但这些工作多从检索器端入手，GRASP 从 Agent 决策端入手 |
| Multi-hop QA | HotpotQA, 2WikiMultiHopQA | 提供了 GRASP 的实验场景，但 GRASP 的贡献在于训练框架而非数据集本身 |
适合谁读
- RAG 系统工程师：正在搭建或优化 Agentic RAG，希望理解多工具协调的 RL 训练方案
- LLM Agent 研究者：关注 Agent 的工具选择与上下文管理问题
- 知识库/问答系统开发者：需要处理多跳复杂查询，对召回率和准确率都有较高要求
- RL 应用实践者：想了解如何为语言模型 Agent 设计联合多目标奖励
前置知识：RAG 基本原理、Reinforcement Learning 基础概念（reward shaping、policy gradient）。对 Agent 系统（ReAct-style）有基础了解会更轻松。
工程落地与核查（Jay）
事实核查
| 核查项 | 结论 | 评估 |
|---|---|---|
| RL 框架核心描述 | "类似 ReAct / Toolformer，输出 thought+action 交替序列"——原文摘要未明确，解读件说明为"类似"并注明推断依据，措辞谨慎 | ✅ 可接受 |
| 奖励函数 λ 取值 | ⚠️ 原文附录 ablation 有覆盖，但摘要/方法节未给闭式公式；解读件已如实标注"未明确" | ✅ 已标注 |
| RL 算法类型 | ⚠️ 原文方法节未明确 PPO/GRPO/SAC；解读件推断为"策略梯度算法"，措辞已保守处理 | ✅ 已保守标注 |
| 具体数据集名称 | ⚠️ 解读件未自创，标注为"原文未明确"；abstract 中仅写"multi-hop reasoning benchmarks"，符合 | ✅ 无幻觉 |
| 具体准确率数值 | ⚠️ 解读件未虚构，标注"原文摘要未给出" | ✅ 无虚构 |
| 三工具协调机制 | 原文摘要明确"semantic search, keyword search, paragraph-reading"三者协调；Semantic Search=向量检索、Keyword Search=BM25/ lexical，表格描述一致 | ✅ 准确 |
| 互补搜索奖励防重复 | 原文明确"complementary search"奖励设计；解读件对应关系准确 | ✅ 准确 |
实际系统怎么用
适用场景判断：GRASP 适合多跳复杂查询 + 有充足 RL 训练数据的场景。单跳简单检索场景不建议引入 GRASP 的额外复杂度。
工程集成路径：
1. 工具层：接入你的向量数据库（Semantic Search）+ BM25 引擎（如 Elasticsearch / OpenSearch）+ Paragraph Reading（精读 chunk）
2. Agent 策略层：用 GRASP 论文的四项奖励 + 策略梯度训练（或用现有开源 GRPO/PPO 实现）微调一个 LLM-as-policy
3. 推理时：输入问题 → Agent 循环 thought+action → 三工具任选 → 直到 turn efficiency 奖励触发停止
关键坑位：
- RL 训练成本高：需要大量问答对（question, retrieved_context, answer）才能训稳；冷启动场景建议先用 prompting-based baseline 比 RL 更划算
- complementary reward 需要去重检测：生产环境里"两次检索是否引入新信息"的判断等价于做相似度阈值过滤，需要额外维护一个已访问 evidence pool
- turn efficiency 奖励的 λ_3 调参敏感：λ_3 太高会导致 Agent 过早停止检索（漏证据）；太低会让 Agent 无谓打转；建议从 0.01~0.1 开始 ablation
- Paragraph Reading 的 sentence-level 切片依赖 chunking 策略：生产系统若 embedding 模型和 GRASP 训练时不一致，精读效果会明显下降，需要端到端重新对齐 chunker
- Keyword Search 的 BM25 参数：BM25 k1/b 参数对不同语料差异大，建议在目标语料上做 grid search（常见 k1∈[1.2,2.0], b∈[0.5,0.9]）
是否值得上线：
| 维度 | 评估 |
|---|---|
| 复杂度 | 高（RL 训练 pipeline） |
| 上线门槛 | 需要 RL infrastructure + 充足训练数据 |
| 收益场景 | 多跳推理 / 复杂证据链问答 / 需要控制 token 成本的生产系统 |
| 不适合场景 | 单跳 QA / 简单实体查询 / 数据量不足以支撑 RL 训练 |