AutoRefine：检索之后先提炼，再继续想

这一节建立问题：search-during-think 范式把检索和推理交替起来，但缺少一个显式的证据整理步骤。

RAG 的常见流程是：模型发现问题需要外部知识 → 发一次搜索 → 拿到若干文档 → 直接在这些文档上生成答案。论文把这种范式叫 search-during-think。它比“不检索”强，但有两个结构性弱点。

第一，文档是噪声和信号的混合物。检索器按相关性返回 top-k 文档，其中可能包含错误实体、过时信息、与问题无关的段落。模型没有显式的“先筛再答”步骤，噪声会直接进入后续推理，错误答案因此被放大。论文 Figure 1(a) 的例子是“David Beckham 最后效力的球队的主场在哪”：同一篇文档先写他出道于 Manchester United，末尾才写他最后效力 Paris Saint-Germain；直接读文档的 previous method 搜 Manchester United、答 Old Trafford，AutoRefine 先 refine 出“David Beckham's last professional team was Paris Saint-Germain”，再答 Parc des Princes。

第二，奖励只落在最终答案上。如果只用答案正确性做 RL 奖励，一条轨迹只有最后 0/1 或 F1 一个标量；中间“有没有找到关键证据”没有被单独评价。对多跳问题，这会让模型难以学习“先找到中间实体，再用它去搜下一步”的行为。

AutoRefine 的切入点不是换检索器，也不是换更大模型，而是在轨迹里加一个 <refine> 动作，并给这个动作单独设计奖励。检索仍然由同一个 E5 检索器完成，变化发生在模型如何使用检索结果。

看懂 Table 1 的分组，才知道 0.405 是和谁比。

这些方法的共同点是：模型学会在推理中调用搜索，但检索回来的文档仍然被直接拼进上下文。AutoRefine 的区别只在模板和奖励：模板多一个 <refine>，奖励多一个 RRet。论文没有换检索器，也没有换底座，这让消融能比较干净地归因到这两个改动。

这一节拆两件事：refine 在轨迹里长什么样，奖励怎么算。

轨迹：think → search → documents → refine → … → answer

一条轨迹由若干步组成，每步可以是一个 <think>、一个 <search>、一个 <documents>、一个 <refine> 或最终的 <answer>。<search> 产生查询，检索器返回文档；文档被放进上下文后，模型必须先写一个 <refine> 块，把与问题相关的证据提炼出来，再决定继续搜索还是作答。

这个模板强制模型在“读文档”和“用文档”之间插入一个可观察的中间产物。refine 文本既是下一步推理的上下文，也是检索奖励的评估对象。

答案奖励：F1

RAns 把预测答案与标准答案都看成词集合，用 F1 计算重叠：

检索奖励：refine 是否覆盖标准答案

RRet 是一个二值指示函数：把整条轨迹里所有 <refine> 块的内容拼成 orefine，如果标准答案的每个词都出现在其中，就给 1，否则给 0。公式 (2)：

组合奖励：先保答案，再给部分学分

总奖励 ROverall 不是简单相加，而是分段函数：

论文在 Appendix C.3 对比了线性组合 RAns + RRet 和这个非线性设计，结论是非线性更好；作者假设是线性组合会过度强调中间行为。这个消融只在附录报告，主表没有展开。

优化：GRPO，检索文档的 loss 被 mask

训练用 GRPO。每个问题采样一组 G 条轨迹，用组内相对优势更新策略；检索回来的文档 token 不参与 loss，只有模型自己生成的 think/search/refine/answer token 参与。这样模型学到的是“怎么搜、怎么提炼、怎么答”，而不是“怎么复述文档”。

这一节说明数据、超参数和评测口径；原文有两处训练步数/版本口径需要并列。

底座。主实验用 Qwen2.5-3B 的 Base 与 Instruct 两个版本；v5 另加 Qwen2.5-7B 的规模消融（Table 3）。检索器固定为 E5-base-v2，知识源是 2018 年 12 月的 Wikipedia dump，每次查询取 top-3 文档。

数据。训练集由 NQ 与 HotpotQA 的 train split 合并，共 169,615 条；评测集由七个数据集的 test/dev split 合并，共 51,713 条。NQ、TriviaQA、PopQA、Bamboogle 用 test split；HotpotQA、2Wiki、Musique 没有 test split，用 dev split。

训练配置。8 张 A100-80GB，全参数微调，FSDP + BF16；学习率 1×10⁻⁶，无 warmup；batch 256，micro-batch 64；每条数据采样 5 条 rollout；每条 rollout 最多 5 次搜索；检索文档拼接后截断到 512 token（这是训练截断口径，§3.3.2 的 ≥600 是分析口径）；max response 2048；KL 系数 β=0.001，clip ratio ε=0.2，group size G=5。Table 5 未逐项转录，页面只引用上述超参数数值。

步数口径。Appendix B.1 正文写 “trained for 200 steps”，Table 5 的超参数表写 “Total Training Steps 250”。页面并列两处，不替原文选一个。推断 这可能是正文未随表更新，但没有原文依据，不能确定。

统计。v5 的 Appendix C.2 用 3 个随机种子重跑，报告 mean ± std 并做 T-test：AutoRefine 对 ReSearch 的 p=5.49×10⁻⁶，对 Search-R1 的 p=2.85×10⁻⁶，原文写 p≪0.01。Table 7 的三种子均值（AutoRefine Avg 0.408±0.014）与 Table 1 的点值（0.405）略有差异，页面分别标注，不混用。Table 7 未转录，页面只引用 AutoRefine 的三种子 Avg 与 p 值。

这张图只画单条轨迹的控制流；reward 在轨迹结束后统一计算。

这一节按主表、消融、规模、外部 refiner 分开看；不同表的运行次数与口径不同，不混用。

主结果：Qwen2.5-3B

AutoRefine-Base 的平均 EM 是 0.405；表内最强基线是 Search-R1-Instruct 的 0.336，绝对高 0.069，相对高 20.54%。同底座 Search-R1-Base 是 0.312，绝对高 0.093，相对高 29.81%。论文 §1 引言（§5 结论亦同）写的 “6.9% higher” 对应的是 0.069 这个绝对点差，不是相对 6.9%。

多跳的增量更大，但相对口径要看清。AutoRefine-Base 在 2Wiki 是 0.393，Search-R1-Base 是 0.274，绝对高 0.119，相对高 43.43%。Musique 上 0.157 对 0.066，是 2.38 倍。论文正文另写“2Wiki 提升 0.083、相对 21%；Musique 提升 0.045、相对 26.7%”，分母用的是 AutoRefine 自己的分数（0.083/0.393=21.12%，0.045/0.169=26.63%），不是基线。这两个差值的减式是 0.083 = 0.393（AutoRefine-Base 2Wiki）− 0.310（Search-R1-Instruct 2Wiki），0.045 = 0.169（AutoRefine-Instruct Musique）− 0.124（Search-R1-Instruct Musique）；由表内数字可见，论文这里混用了 Base 与 Instruct 两个 variant。紧接着的 0.119/43.43% 则是同 variant：0.393（AutoRefine-Base）− 0.274（Search-R1-Base）。两种口径并列，不替原文统一。

消融：检索奖励和 refine 各自贡献多少

Table 2 在 Base 上去掉检索奖励，平均从 0.405 降到 0.376（−0.029）；再去掉 refine，降到 0.312（再 −0.064）。Instruct 上对应 0.396 → 0.360（−0.036）→ 0.333（再 −0.027）。本页只引用 Table 2 的 Avg 列，逐基准列未转录。两个组件都不是装饰：单独去掉检索奖励就掉 2.9 个点，连 refine 一起去掉掉 9.3 个点。

规模：7B 也涨，但幅度略小

v5 的 Table 3 加了 Qwen2.5-7B。AutoRefine-7B 的 EM/F1/CEM 平均是 0.455/0.536/0.486，Search-R1-7B 是 0.408/0.483/0.443，绝对高 0.047/0.053/0.043。3B 上对应高 0.093/0.111/0.101。原文的结论是 7B 的增益约 0.05，略低于 3B；这与表内数字一致。

外部 refiner：加一个摘要器不够

Table 4 给 Search-R1 外接 BART 或 Qwen 摘要器。BART 版平均 0.317，比 Search-R1 的 0.312 只高 0.005；Qwen summary 版 0.328，高 0.016；Qwen summary+plan 版反而降到 0.301。AutoRefine 的 0.405 比最好的外部 refiner（0.328）高 0.077。论文的解释是：外部摘要器只做摘要，AutoRefine 还学会“内省缺什么、下一步搜什么”。

统计与检索深度

Appendix C.2 的三种子实验给了 mean ± std 和 T-test：AutoRefine 对 ReSearch p=5.49×10⁻⁶，对 Search-R1 p=2.85×10⁻⁶，原文写 p≪0.01。检索深度 k 从 1 到 7 变化时，AutoRefine 相对基线的平均增益在 0.04–0.1 之间，峰值 0.09 出现在 k=5；这些是正文对 Figure 6 的概括，页面没有逐点转录曲线。

发现 1：refine 把上下文压短，但保留答案词

论文对 Figure 5(a)(b) 的正文描述是：refine 块大约 100–200 token，检索文档（documents 块）至少约 600 token；同时 refine 动作的成功率与 <search> 动作接近。页面不把这些正文数值当表格数字，只引用正文的近似区间。机制上，RRet 要求标准答案的词出现在 refine 文本里，这直接逼着模型保留关键实体，而不是写一段泛泛的摘要。推断（由公式 (2) 的覆盖条件反推）

发现 2：单跳涨得少，多跳涨得多

Base 上 NQ 0.467 对 Search-R1-Base 0.421（+0.046），TriviaQA 0.620 对 0.583（+0.037），PopQA 0.450 对 0.413（+0.037）；多跳的 2Wiki 是 +0.119，Musique 是 +0.091（0.157−0.066）。单跳问题通常一次搜索就能拿到答案，refine 的边际收益小；多跳问题需要把上一轮的证据整理成下一轮的查询，refine 的作用更大。这与论文的动机一致，但论文没有做“单跳/多跳分别训练”的对照，不能把差异完全归因于任务类型。推断

这些限制决定了 0.405 能推广到哪里，以及“refine 更聪明”是否等于“系统更可用”。

指标覆盖有限。主表用 EM；v5 的 Table 3 加了 F1 与 CEM，但仍以短答案 QA 为主。长答案、开放式生成、需要引用来源的任务没有实验。EM 对同义改写很苛刻，F1 也只能看词重叠，不能判断事实一致性。

奖励可以被“提取”而不是“理解”。RRet 只检查标准答案的词是否出现在 refine 文本里。如果标准答案是一个短实体，模型可以把含答案词的文本甚至整篇文档抄进 refine 拿到奖励，而不一定理解它。论文用“refine 在原始文档之后、答案之前”的模板降低这种风险，但没有做 reward hacking 实验。推断

训练步数有两处写法。Appendix B.1 写 200 steps，Table 5 写 250 steps。页面并列两处；这不影响主表数字，但复现时需要确认以哪个为准。

什么时候别用：如果任务只需要一次检索、答案是一句短事实，refine 的额外生成可能是多余开销；如果知识源必须实时更新，2018 年快照不适合；如果需要引用级可追溯性，refine 文本不是引用，仍需额外做来源对齐。反过来，在多跳、文档噪声大、答案需要跨文档整合的任务里，AutoRefine 的思路最直接：先把证据整理成可检查的中间文本，再继续推理。