多跳问题需要「先搜 A，看到结果再决定搜 B」。ReSearch 不标注任何推理步骤，直接把 <think>、<search>、<result>、<answer> 拼成一条 rollout，用 GRPO 优化最终答案的 F1；检索结果 token 在损失里被掩码，模型只为自己的思考与查询负责。 只在 MuSiQue 上训练；7B 模型在四个多跳基准上的平均提升为 15.81 个百分点 EM、17.56 个百分点 LJ（原文报告值；按 Table 2 复算，口径是四个基准对 Iter-RetGen 的绝对点差平均，见 §6.2）。
搜索不是前置步骤，而是推理链里的动作。 模型每写一个 <search>，环境就检索一次并把结果塞进 <result>；模型基于结果继续写 <think>，直到输出 <answer>。搜索的时机、查询词、迭代次数都由模型自己决定（§2.1、Figure 2）。
奖励只有两项：答案 F1 + 格式。 F1 非 0 时奖励就是 F1；F1 为 0 但格式正确给 0.1；格式也错给 0。没有过程奖励，也没有推理步骤标注（§2.3、Eq.2）。
只在 MuSiQue 上训练，评测四个基准。 训练集 19,938 条，2 个 epoch；评测 HotpotQA、2WikiMultiHopQA、MuSiQue、Bamboogle。原文报告 7B 的平均提升是 15.81 个百分点 EM、17.56 个百分点 LJ，32B 是 14.82 / 15.46 个百分点。按 Table 2 复算，这四个数是四个基准对 Iter-RetGen 的绝对点差平均，不是相对提升，也不是对每列最强基线的差值平均（详见 §6.2）。
案例里出现了自我纠错，但只是单例。 第一次搜「Martín Ramírez Pech」搜到同名画家，模型在下一段 <think> 里说「我似乎搜错了」，把查询改成「Martín Ramírez Pech political party」，再继续搜（Table 3）。论文把它作为定性证据，不是系统性评测。
传统 RAG 把检索当预处理；ReSearch 把检索当动作，让模型在推理过程中反复决定。
「《星际穿越》的导演的出生地的市长是谁？」这类问题需要三条依赖链：先找导演，再找出生地，再找市长。传统 RAG 通常在回答前检索一次或固定几次，把结果拼进上下文；它无法根据「第一次搜到了什么」动态决定「第二次搜什么」（§1）。
提示工程路线（Iter-RetGen、IRCoT）可以让模型多轮检索，但轮次与提示模板由人设计；模型是在「遵循流程」，不是在「学习策略」。监督微调路线需要标注推理步骤，成本高、规模受限。论文的切入点是：只给最终答案的对错，让模型在试错中自己学出「什么时候搜、搜什么」（§1、§2）。
Naive RAG 先检索再生成；Iter-RetGen 与 IRCoT 虽然迭代，但迭代规则由外部提示控制。模型没有把「搜索」当成自己的动作（§1、§3.1）。
要监督「第几步该搜什么」，需要人工写推理链。论文选择不标注过程，只用最终答案的 F1 与格式做奖励（§2.3）。
这个设定带来一个工程问题：rollout 里既有模型生成的 token，也有检索环境返回的 token。如果损失把检索结果也算进去，策略会被「环境写的文本」带偏。ReSearch 的做法是把 <result> 内的 token 全部掩码，只对 <think> 与 <search> 计算损失（§2.1）。
Table 2 的基线都是提示/RAG 方法；论文没有把 Search-R1 等 RL 搜索 Agent 放进同一张表。
不检索，直接用指令微调模型回答。多跳问题需要的事实往往不在参数里，因此 EM 最低（§3.1、Table 2）。
先用问题检索一次，把结果拼进上下文再生成。比不检索好，但仍然只有一轮，无法根据中间结果改写查询（§3.1）。
两者都做多轮检索与生成：Iter-RetGen 交替检索与生成，IRCoT 用思维链引导检索。轮次与提示由人设计，不是从奖励里学出来的（§3.1）。
ReSearch 与这些基线的差别不是「多搜几次」，而是「搜索策略由策略网络生成」。同一套 Qwen2.5 底座下，ReSearch 只在 MuSiQue 训练，却在 HotpotQA、2Wiki、Bamboogle 上也能用；这被论文称为泛化能力（§3.2）。
没有 SFT 冷启动，直接在 Qwen2.5 权重上做 GRPO；格式靠 prompt 约束，正确性靠 F1。
生成过程遇到 </search> 时暂停，把最近的查询送给检索器；检索结果包进 <result> 后拼回上下文，模型继续生成。这个过程循环到模型输出结束符或 <answer>（§2.1、Figure 2b）。
检索环境是 FlashRAG + E5-base-v2，知识库是 2018 年 12 月的 Wikipedia；每次查询取 top-5。训练与评测用同一个环境（§3.1）。这意味着模型学到的是「在这个 Wikipedia 检索器上怎么搜」 推断；换到真实网页搜索是否成立，论文没有实验（依据：§3.1 的训练与评测共用同一 FlashRAG + E5-base-v2 + 2018 Wikipedia 环境，未测试其他检索器或知识库）。
每个问题采样 5 条 rollout，用组内奖励的均值与标准差归一化出优势；目标函数带 clip 与 KL 惩罚，KL 系数 0.001，clip 比例 0.2（§2.1、Eq.1、Table 4）。相比 PPO，GRPO 不需要单独训练 critic，省一份模型与一份显存。
奖励是规则式的，没有奖励模型：
这个奖励的设计后果是：模型只要格式对，就能拿到 0.1 的「保底分」；一旦答案 F1 大于 0，奖励就变成连续的 F1，而不是 0/1。论文没有额外加长度惩罚或搜索次数惩罚；Figure 3 的搜索次数随训练上升，但论文没有给搜索次数的上限或成本约束（§3.3）。推断：奖励只来自最终答案 F1 与格式，模型可能倾向「多搜几次」而不是「更准地搜」（依据：§2.3 的 Eq.2 没有搜索次数/成本项，§3.3 未给上限）。
base 模型直接把模板拼在问题前；instruct 模型把模板作为 system prompt，再套 chat template。模板里给出一个完整的标签示例，要求模型用 <think>、<search>、<result>、<answer> 组织输出（§2.2、Table 1）。
论文强调模板「简单、简洁」，让模型在 RL 中自然延续，而不是靠复杂的格式约束。F1 为 0 但格式正确的 rollout 仍可拿到 0.1，这是格式保底奖励的用途（§2.2、§2.3、Eq.2）。
这是论文给出的全部训练开销信息；没有报告总 GPU 小时或费用。
共 64 张 H800，全参数优化 + gradient checkpointing（Appendix B）。论文没有给单卡显存、训练时长或总 GPU 小时。
只使用 MuSiQue 训练集，训练 2 个 epoch；batch size 256，学习率 1e-6，rollout 温度 1.0（§3.1、Table 4）。
知识库是 2018 年 12 月的 Wikipedia，检索器 E5-base-v2，每次取 top-5；索引与 embedding 由 FlashRAG 预处理（§3.1）。
HotpotQA 7,405 条、2Wiki 12,576 条、MuSiQue 2,417 条、Bamboogle 125 条；EM 与 LLM-as-a-Judge 并用（§3.1）。
论文没有做不同硬件、不同 batch size 或不同检索器数量的消融。推断：不能把 64 张 H800 的配置直接外推到更小或更大的集群（依据：Appendix B 只给 8×8 H800、全参数 + gradient checkpointing，未报告显存、并行策略或训练时长）。也没有报告训练总 token 数或检索调用次数。
上半是单条 rollout 的结构，下半是 GRPO 的组内比较；检索环境在 rollout 中间介入。
图里的回路是单条 rollout：模型在 <search> 处暂停，环境返回结果，模型继续。下面的组内比较是 GRPO 与 PPO 的关键差别：不需要 critic，直接用同一问题的一组 rollout 的奖励均值与标准差做基线（§2.1）。
先看四个基准的绝对值，再看对最强基线的差值，并说明原文 15.81 / 17.56 的复算口径；最后讨论训练曲线与案例。
Table 2 覆盖 Qwen2.5-7B 与 32B 的 base/instruct 四个起点。7B-Instruct 在 HotpotQA 上 EM 43.52%、LJ 63.62%；在 2Wiki 上 EM 47.59%、LJ 54.22%；在 MuSiQue 上 EM 22.30%、LJ 33.43%；在 Bamboogle 上 EM 42.40%、LJ 54.40%。32B-Instruct 的 Bamboogle EM 达到 56.80%，是 Bamboogle 列最高 EM。
| 模型 | HotpotQA | 2Wiki | MuSiQue | Bamboogle | ||||
|---|---|---|---|---|---|---|---|---|
| EM | LJ | EM | LJ | EM | LJ | EM | LJ | |
| Qwen2.5-7B(-Instruct) | ||||||||
| Naive Generation | 19.18 | 30.64 | 25.76 | 27.87 | 3.76 | 10.38 | 10.40 | 22.40 |
| Naive RAG | 31.90 | 49.59 | 25.78 | 29.52 | 6.21 | 12.78 | 20.80 | 32.00 |
| Iter-RetGen | 34.36 | 52.22 | 27.92 | 31.86 | 8.69 | 16.14 | 21.60 | 35.20 |
| IRCoT | 30.33 | 52.06 | 21.57 | 30.65 | 6.99 | 14.19 | 24.80 | 36.80 |
| ReSearch-Qwen-7B | 40.57 | 60.26 | 44.67 | 50.06 | 21.68 | 32.19 | 43.20 | 54.40 |
| ReSearch-Qwen-7B-Instruct | 43.52 | 63.62 | 47.59 | 54.22 | 22.30 | 33.43 | 42.40 | 54.40 |
| Qwen2.5-32B(-Instruct) | ||||||||
| Naive Generation | 24.63 | 38.26 | 27.23 | 29.68 | 6.12 | 14.23 | 18.40 | 29.60 |
| Naive RAG | 36.46 | 55.73 | 30.38 | 34.87 | 9.27 | 15.97 | 23.20 | 40.80 |
| Iter-RetGen | 39.81 | 58.80 | 33.64 | 38.22 | 12.49 | 20.11 | 29.60 | 44.80 |
| IRCoT | 28.44 | 55.44 | 13.53 | 29.50 | 7.82 | 18.20 | 31.20 | 47.20 |
| ReSearch-Qwen-32B | 42.77 | 64.27 | 38.52 | 45.59 | 26.40 | 37.57 | 54.40 | 66.40 |
| ReSearch-Qwen-32B-Instruct | 46.73 | 67.70 | 44.90 | 50.30 | 26.40 | 38.56 | 56.80 | 67.20 |
按每个基准的最强基线算，7B-Instruct 的 EM 差值是：HotpotQA 9.16、2Wiki 19.67、MuSiQue 13.61、Bamboogle 17.60 个百分点；LJ 差值是 11.40、22.36、17.29、17.60。32B-Instruct 的 EM 差值是 HotpotQA 6.92、2Wiki 11.26、MuSiQue 13.91、Bamboogle 25.60；LJ 差值是 8.90、12.08、18.45、20.00。注意这是页面图的“每列最强基线”口径；原文 §3.2 报告的 15.81 / 17.56 / 14.82 / 15.46 按 Table 2 复算，是四个基准对 Iter-RetGen 的绝对点差平均（原文未说明 Bamboogle 为何不用该列最强的 IRCoT），两套数的 Bamboogle 加数不同，复算见下方手算块。
7B 的最强 EM 基线：HotpotQA / 2Wiki / MuSiQue 都是 Iter-RetGen（34.36 / 27.92 / 8.69），Bamboogle 是 IRCoT（24.80）。7B-Instruct 减出来是 9.16 / 19.67 / 13.61 / 17.60。
32B 的最强 EM 基线：HotpotQA / 2Wiki / MuSiQue 都是 Iter-RetGen（39.81 / 33.64 / 12.49），Bamboogle 是 IRCoT（31.20）。32B-Instruct 减出来是 6.92 / 11.26 / 13.91 / 25.60。
原文 15.81 / 17.56 / 14.82 / 15.46 的复算：原文 §3.2 写的是 “the average improvement of ReSearch over the best baseline is 15.81% in exact match and 17.56% in LLM-as-a-judge, for Qwen2.5 model with 7B parameters. For Qwen2.5 model with 32B parameters, the average improvement is 14.82% in exact match and 15.46% in LLM-as-a-judge.”；但按 Table 2 复算，这四个数是四个基准对 Iter-RetGen 的绝对点差平均，单位是百分点：
页面图按“每列最强基线”算，Bamboogle 换成 IRCoT（7B EM 24.80 / 7B LJ 36.80 / 32B EM 31.20 / 32B LJ 47.20），所以图上的 Bamboogle 差值是 17.60 / 17.60 / 25.60 / 20.00，而不是原文平均值的加数 20.80 / 19.20 / 27.20 / 22.40。差异只来自基线切换；页面把两套口径并列，不把 15.81 等写成“相对提升”。
Figure 3 统计训练过程中的响应长度与搜索次数：四条曲线（7B/32B × base/instruct）的搜索次数都随训练步数上升；32B 的响应长度在前 20 步先下降，约 60 步后再上升（§3.3）。论文的解释是 32B 初始更依赖内部知识，收到奖励信号后才开始更多检索。Figure 3 没有标出每条曲线的具体数值，页面只引用趋势，不引用精确次数。
Table 3 的案例是「Martín Ramírez Pech 所属政党所在国家的 2018 年总统选举谁赢了」。第一次搜「Martín Ramírez Pech」返回同名画家的信息；模型在下一段 <think> 里说「我似乎搜错了」，把查询改成「Martín Ramírez Pech political party」，第二次搜到墨西哥工党，再搜「2018 Mexican presidential election」，最后答 Andrés Manuel López Obrador。整条轨迹用了三次 <search>（Table 3）。这是一个定性案例，论文没有统计这种自我纠错在测试集上的频率。
这些条件决定了 ReSearch 的结论能推广到哪一步。
知识库固定为 2018 年 12 月的 Wikipedia，检索器固定 E5-base-v2，top-5。没有真实网页搜索、没有多语言、没有时效性数据；换检索器或换知识库后的表现未测（§3.1）。
训练集 19,938 条，2 个 epoch。论文把跨 HotpotQA/2Wiki/Bamboogle 的结果称为泛化，但这些都是英文多跳 QA，任务形态接近；不能据此推断开放域研究或长文写作也能泛化 推断（§3.1、§3.2）。
奖励要求答案能被 F1 比较，适合事实型短答案；论文在 Appendix C 明确说，更长、更微妙的回答需要更复杂的奖励建模（Appendix C）。
Table 2 的基线是 Naive Generation、Naive RAG、Iter-RetGen、IRCoT，都是提示/RAG 方法；没有把 Search-R1 等 RL 训练方法放进同一张表。跨论文比较受底座、数据、检索环境影响，不能直接下结论（§3.1、Table 2）。
结果层面还有三条边界。第一，不是每个单元格都随 instruct 提升：7B-Instruct 的 Bamboogle EM 42.40 低于 7B 的 43.20。第二，论文的「8.9%–22.4% 绝对提升」与 Table 2 的 Bamboogle 差值 25.60 不一致：正文这句话对应 Figure 1，而 Table 2 的 32B-Instruct 56.80 对 IRCoT 31.20 差 25.60；页面把两处并列，不替作者消解。第三，训练曲线只给趋势：Figure 3 没有标出搜索次数的具体值，不能引用「从 1.5 涨到 3.5」这类读数。
方法层面最值得记住的是「检索结果掩码」：它让策略只为自己的思考与查询负责，不被环境文本带偏。代价是模型学不到「如何改写检索结果」，也不直接优化检索质量 推断；检索器的召回上限就是策略的上限（依据：§2.1 的损失掩码让 <result> token 不参与梯度，§2.3 的奖励只来自最终答案 F1 与格式，没有检索质量项）。