什么是Adaptive RAG
Adaptive RAG是“会根据当前推理状态动态决定是否继续检索”的 RAG。
普通 RAG 的基本流程通常是：
Question→Retrieve→Retrieved Docs→LLM→Answer
也就是问题一来，先检索一次，然后把检索结果塞给 LLM，最后生成答案。这种流程里的 retrieval 往往是预先固定的：不管问题简单还是复杂，基本都“先搜再答”。
而 Adaptive RAG 的核心是把“检索”变成一个动态决策过程。模型在推理过程中会不断判断：
现在需不需要检索？如果需要，还要进一步决定： 应该检索什么？以及 检索到的信息应该怎么加入当前推理？
动机
现有 Adaptive RAG 的两类主流做法：
第一类：直接让冻结的 LLM 自己决定要不要检索。
所谓 frozen LLM，就是主模型参数不更新。系统通常根据 LLM 的 uncertainty、置信度、特殊 token，或者直接通过 prompt 让它判断：“我现在是否需要外部信息？”
缺点：这种“什么时候搜、搜什么”的能力没有经过专门训练，也没有明确的监督信号告诉模型“这里应该检索”“这里不应该检索”。
第二类：直接训练 LLM 学会检索。
这类方法会通过 SFT 或 RL 去训练主 LLM，让它真正学会：When to retrieve，What to retrieve
缺点：训练成本很高
创新
因此需要一种在不修改LLM本身的情况下自适应检索，理想情况下，这种方法应该将检索控制从LLM中分离出来，实现独立学习，同时保持模型的泛化能力。
基于这一思想，作者提出了一种结构化的、即插即用的智能体检索策略SPALKE，用于改进RAG中的自适应检索和知识集成。
SPALKE 使用 the proxy model 逐步决定何时检索、检索什么，以及如何合并检索到的信息。在这个过程中，代理模型利用结构化知识图谱来更好地表达检索查询，并将相关信息整合到推理上下文中。
SPARKLE中的代理模型以代理的方式运行，承担不同的功能角色，每个角色都由有针对性的指令指导。这些角色充当专门的代理人，协同工作以支持适应性RAG过程。SPARKLE定义了三个agents：
(1)用于确定何时需要外部知识的检索决策代理，
(2)用于识别知识差距并生成目标搜索查询的查询形成代理，
(3)用于选择和集成相关信息的知识集成代理。
具体地说，在每个LLM的推理步骤中，检索决策代理根据当前上下文和 LLM 的中间思想来决定是否需要额外的知识。如果需要检索，则调用查询公式和知识集成代理以获得用于下一步推理的更新的上下文。
受先前采用基于知识图谱(KG)的推理链从噪声内容中识别有用信息的工作的启发，SPLICE从LLM的中间思想中提取了一个基于KG的推理链，提供了其推理轨迹的结构化和信息性表示。这种结构帮助查询公式代理更准确地识别用于定向检索的知识差距。此外，检索到的文档被分解成知识三元组，允许知识集成代理执行相关内容的细粒度选择以并入上下文中。
作者利用近端策略优化 proximal policy optimisation(PPO)来训练代理模型，同时保持检索器和LLM冻结。为了便于在训练过程中更有效地探索，我们提出了一种带有剪枝机制的 binary tree-
structured rollout strategy（二叉树结构卷出策略），该策略允许代理模型在探索多条推理路径的同时丢弃不被看好的分支。
定义
形式上，给定问题 q 和语料库，目标是通过一系列推理步骤生成答案 y。
形式上，我们将multi-agent Markov Decision Process (MDP) 过程定义为一个元组，其中 I = {1, 2, 3} 表示代理集合，Si 和 Ai 分别表示第 i 个智能体的状态空间和动作空间。 每个代理遵循其策略 πi : Si → Ai 根据其状态选择操作。直观上，状态可以被视为代理的输入，而动作对应于代理的输出。轨迹是代理随着时间与环境交互而生成的一系列状态和动作。R是系统级奖励函数，它提供反馈来指导代理之间的合作行为。
Agent Roles and Collaborative Strategy
Retrieval Decision Agent（解决：When to retrieve）
该代理确定每个推理步骤是否需要外部知识。在第 t 步，智能体观察到状态，其中ct表示由先前步骤中检索到的文档组成的当前上下文，r≤t是 LLM 在步骤t之前生成的中间思想。 根据这个状态，代理选择一个动作
，其中“是”表示后续推理需要检索，而“否”表示不需要外部知识。
Query Formulation Agent（解决：What to retrieve）
如果在步骤t需要检索，则激活查询制定代理以基于状态获得查询qt。 虽然可以直接根据 LLM 的想法生成查询，但由于 LLM 的想法中存在分散注意力或推测性内容，因此这种策略通常会导致性能不佳，例如：
这个例子说明了LLM的想法如何包含不确定性和推测性内容，从而很难直接提取准确的搜索查询。 为了解决这个问题，作者的查询公式代理首先构建了一个基于 KG 的推理链 gt ，它将 LLM 的思想抽象为一种结构化的形式，捕获基本的推理步骤，例如：
这种结构化的表示可以过滤掉干扰，从原始想法中提取、推测或不相关的信息，仅保留任务所需的核心推理步骤。 通过这样做，它使潜在的知识差距更加明确，使代理能够清楚地识别需要哪些附加信息来推进推理过程并相应地制定有针对性的搜索查询 qt。
Knowledge Integration Agent.
给定查询 qt，检索器返回文档列表 Dt ⊂ C，其中通常包含不相关的内容。 为了便于更细粒度地识别有用信息，SPARKLE 将每个文档分解为一组知识三元组。这种结构化表示通过减少文本噪声，可以对检索到的内容进行更精确的推理。知识集成代理观察状态，其中 Kt 是从 Dt 中提取的知识三元组的集合。 然后，它选择最能填补当前推理链中最重要空白的三元组。 给定选定的三元组，SPARKLE 将提取该三元组的源文档添加到上下文 ct，从而生成更新的上下文 ct+1 以供后续推理。
Collaborative Strategy（解决：How to integrate retrieved knowledge）
最后，我们介绍这些代理如何与LLM协作以支持自适应检索和推理。 给定问题 q 和初始上下文 c0，LLM 会生成第一个想法 。 然后，检索决策代理确定是否需要外部知识。 如果是，则激活查询制定和知识集成代理以获得更新的上下文c1以用于后续推理。 否则，上下文保持不变。 这个过程会迭代执行，直到法学硕士生成最终答案。
举例
Question：What is the 2010 population of the village where Smith Haven Mall was located?
Step 0：LLM 初始推理
LLM 已经知道：Smith Haven Mall→Lake GroveSmith。但是缺少： Lake Grove→population in 2010
Step 1：Retrieval Decision Agent
输入：
RD Agent 判断：当前回答是否需要外部知识？
输出：，表示： 需要检索；如果输出 No：直接让 LLM 继续推理。
Step 2：Query Formulation Agent
目标：根据当前推理缺口生成精准搜索 query。所以先构建 KG-based reasoning chain。
原始 thought 转换为：
unknown表示当前知识缺口。
根据 KG chain生成：qt="Lake Grove population 2010"
Step 3：Retriever 检索文档
返回：Document 1，Document 2，Document 3
Step 4：Knowledge Integration Agent
目标：从检索结果中选择真正能够填补 reasoning gap 的知识。
首先把 documents 转换成 knowledge triples
输入：① Question；② 当前 reasoning chain；③ Candidate triples；
Agent 判断哪个 triple 最能补充：<Lake Grove,population in 2010,unknown>
选择：Document 3的 knowledge triples
Step 5：更新 Context
SPARKLE不是直接把 triple 给 LLM。而是找到 triple 来源 document。加入C，得到新的Ct+1
Agentic Retrieval Policy
作者将训练过程构建为 RL 问题。 作者采用 PPO来训练代理模型，以学习提高答案生成性能的检索策略。
问题：
普通 PPO 只按照当前 policy 采样，容易陷入错误 retrieval 策略，探索不足。
方法：
训练阶段，在每个 Retrieval Decision 处强制展开两个动作：Retrieve vs No Retrieve
形成二叉决策树，收集多条 trajectory，并根据最终 reward 优化 proxy policy。
优化：
- pruning 删除重复分支的其中一个；
- 限制前 L 步展开避免指数增长。
作用：
提高 retrieval policy 的探索能力，使模型学会：“什么时候检索比不检索更好”。
Monte Carlo Reward Assignment
主要解决一个强化学习中的问题：
SPARKLE 有三个 Agent（RD、QF、KI），但是最终只有一个系统级奖励（answer 对不对），如何把这个最终奖励合理分配给三个 Agent 的每一步决策？
核心思想：
不直接平均分配最终 reward，而是通过 Monte Carlo 估计每个 action 对最终结果的贡献。
简单理解来说，它会问：
如果某个 Agent 的这个决策改变了，未来结果会怎样？
Monte Carlo 方法估计：在这个状态下采取这个动作，对最终 reward 的期望贡献，然后形成：
，用于训练。
总结：让 Proxy Model 自己尝试不同的检索策略（Binary Tree Rollout），看最终答案是否正确，然后通过 Monte Carlo 方法判断“哪一步决策贡献最大”，把奖励分给对应 Agent，最后用 PPO 让模型以后更倾向选择高奖励的检索行为。
公式理解
SPARKLE 有三个 Agent：π1=πRD，π2=πQF， π3=πKI。三个 Agent 共享一个 proxy model 参数θ。所以表示在状态
下，proxy model 选择动作
的概率。
Binary Tree Rollout 生成轨迹
SPARKLE形成 binary tree：，每条 trajectory 最终经过 LLM+Retriever 得到答案yτ
对于每条 trajectory，得到最终 reward
Monte Carlo Reward Assignment
对于 agent i 的 action估计（在当前状态采取这个动作，对最终 reward 的期望贡献。）最终得到训练数据：
（RL 样本）
计算 Advantage
PPO 不直接使用 reward，而使用 advantage：，
表示这个动作比平均水平好；
PPO 更新 Proxy Model
PPO 优化目标：
