← 返回 2026-01-13

Dr. Zero：无需训练数据的自进化搜索智能体 Dr. Zero: Self-Evolving Search Agents without Training Data

Zhenrui Yue, Kartikeya Upasani, Xianjun Yang, Suyu Ge, Shaoliang Nie, Yuning Mao, Zhe Liu, Dong Wang 📅 2026-01-11 👍 22 2026-07-13 08:35

GRPO 强化学习搜索智能体无数据学习自进化LLM

arXiv HuggingFace PDF

提出自进化框架Dr. Zero，无需数据即可训练强大搜索智能体

前置知识

Group Relative Policy Optimization (GRPO)

GRPO是一种基于组的强化学习算法，通过从同一提示生成多个响应来构建基线，从而估计优势函数。与PPO不同，GRPO不需要单独的值网络，而是使用组内响应的经验统计量（均值和标准差）来标准化奖励。具体来说，给定问题$x$，GRPO采样$n$个响应，计算每个响应的优势$A_i = (R_i - mean) / (std + delta)$，然后通过裁剪的策略梯度目标进行优化。这种方法在DeepSeek-Math等工作中被证明对LLM训练非常有效。

GRPO是本文solver训练的核心算法，理解其原理是理解HRPO改进的基础

Proposer-Solver自进化框架

这是一种双模型协同进化的设计模式。Proposer（提议者）负责生成训练问题，Solver（求解者）负责解答这些问题。两者从同一基础模型初始化，通过迭代训练相互促进：Proposer生成的问题用于训练Solver，而Solver的表现反过来为Proposer提供奖励信号，指导其生成更合适的问题。这种共生循环避免了对人工标注数据的依赖，类似于课程学习中教师出题、学生做题、教师根据学生水平调整题目难度的过程。

这是Dr. Zero的核心架构设计，理解proposer和solver如何协同进化是理解全文的关键

多跳推理（Multi-hop Reasoning）

多跳推理是指回答一个问题需要多个推理步骤，每一步都依赖于前一步的结果。例如，问题'A的创始人毕业于哪所大学？'需要两跳推理：第一跳找到A的创始人是谁，第二跳找到该创始人毕业于哪所大学。在搜索智能体的语境中，每一跳通常涉及一次搜索引擎查询。多跳问题相比单跳问题更具挑战性，因为模型需要正确地串联多个信息检索步骤，任何一步出错都会导致最终答案错误。

论文的核心目标之一是提升搜索智能体在多跳问题上的表现，这是现有无数据自进化方法的主要瓶颈

Hop-Grouped Relative Policy Optimization (HRPO)

HRPO是本文提出的核心优化算法，专门针对proposer训练设计。与GRPO为每个提示生成多个问题不同，HRPO按问题的跳数（hop count）对生成的问题进行聚类，然后在同类问题内计算相对优势。具体地，对于h跳问题集合，优势计算为A = (r - mean_group) / (std_group + delta)。这样做的好处是避免了GRPO中每个提示需要生成多个问题的嵌套采样开销，将计算成本降低到约四分之一。

HRPO是论文的核心技术贡献，解决了多轮工具使用场景下GRPO计算成本过高的问题

难度引导奖励（Difficulty-guided Reward）

这是为proposer设计的专用奖励函数，旨在同时激励可验证性（问题必须有解）和难度（问题不能太简单）。给定solver对问题的n次尝试中有k次回答正确，奖励定义为：当k=0（全错，问题太难）或k=n（全对，问题太简单）时给予惩罚，奖励在0 < k < n时最大化。具体公式为r = I(0 < k < n) * n / (n-1) + r_f，其中r_f是格式奖励。这意味着恰好有1个正确答案时奖励最高，随着正确答案数增加线性衰减。

这个奖励设计驱动proposer生成有挑战性但可解的问题，是自进化质量的关键保障

研究动机

现有自进化LLM方法在搜索智能体场景下存在两个根本性瓶颈。首先是问题多样性不足：现有方法（如R-Zero、SQLM）主要针对数学或代码等受限领域设计，生成的问题结构同质化严重，偏向简单的单跳问题。实验表明，这些方法在单跳任务上能取得一定提升，但在复杂的多跳查询上与有监督基线差距显著——例如R-Zero*在3B模型上的多跳平均得分仅为0.155，远低于有监督的Search-R1的0.289。其次是计算成本过高：标准GRPO算法需要嵌套采样——为每个提示生成m个问题，每个问题再采样n个回答，总计需要(m+1)乘以n次rollout。结合多轮搜索交互的高延迟，这种规模瓶颈使得现有方法在搜索智能体场景下变得计算上不可行。

本文的目标是本文的具体目标是设计一个完全无数据（data-free）的自进化框架，使搜索智能体能够仅依赖外部搜索引擎提供的监督信号，自主提升推理和搜索能力。具体而言，Dr. Zero要达到三个目标：第一，消除对人工标注数据、演示或答案的依赖；第二，让proposer能生成复杂多跳问题，而非局限于简单单跳问题；第三，大幅降低训练计算成本，使自进化在多轮工具使用场景下可行。

与已有工作不同的是，本文的独特切入角度在于三个层面的创新设计。在算法层面，提出HRPO替代标准GRPO，通过按跳数聚类相似问题来计算优势，避免嵌套采样，将计算成本降至约四分之一。在奖励设计层面，设计了难度引导奖励函数，同时惩罚问题太难（solver全错）和太简单（solver全对）的情况，激励proposer生成恰好处于solver能力边界的挑战性问题。在框架层面，通过多轮工具使用rollout管道，使proposer能够利用搜索引擎生成复杂的多跳问题，突破了现有方法局限于单跳问题的瓶颈。这三个创新共同构成了一个完整的、可扩展的无数据自进化范式。

核心方法

Dr. Zero的核心思路是一个迭代的proposer-solver共生进化循环。直觉上，可以类比为一对师生关系：老师（proposer）出题，学生（solver）做题，老师根据学生的答题表现调整出题难度。技术路线如下：首先从同一基础LLM初始化proposer和solver两个模型。然后进入迭代训练循环：(1) proposer利用外部搜索引擎生成多跳问答对；(2) solver对这些问题进行多次尝试，其正确率作为proposer的奖励信号；(3) 使用HRPO更新proposer，使其生成更有挑战性但可解的问题；(4) 使用GRPO更新solver，使其搜索和推理能力持续提升。随着solver变强，简单问题的奖励下降，迫使proposer探索更复杂的推理路径，形成自动课程学习。

Dr. Zero与已有方法的本质区别体现在两个核心创新点。第一个是HRPO算法：标准GRPO需要为每个提示生成多个问题再对每个问题采样多个回答（嵌套采样），而HRPO改为每个提示只生成一个问题，但将结构相似的问题（相同跳数）聚类，在组内计算相对优势。这将rollout数量从(m+1)*n降至1+n，减少约75%计算量，同时保持甚至超越GRPO的性能（平均0.326 vs 0.320）。第二个是难度引导奖励：不同于简单的二元正确/错误奖励，该奖励函数精确地将问题难度校准到solver的能力边界，避免了问题过难（无法学习）或过简（无学习信号）的极端情况。

方法步骤详情

Dr. Zero的训练流程包含以下具体步骤。第一步，proposer更新：(a) proposer接收一个初始文档和跳数n作为输入；(b) 通过多轮工具使用rollout，proposer生成包含n跳推理链的问答对，每跳之间使用搜索引擎获取信息；(c) 将生成的问题输入solver，采样5次回答，统计正确次数k；(d) 计算难度奖励和格式奖励（要求遵循think/tool/question/answer格式、正确使用工具、问题和答案可提取）；(e) 按跳数对问题分组，使用HRPO计算组内相对优势并更新proposer参数。第二步，solver更新：(a) 从proposer采样一批问答对；(b) solver对每个问题生成5个回答；(c) 使用GRPO计算优势并更新solver参数。这两个步骤交替进行，共进行3轮迭代，每轮proposer和solver各训练50步。默认使用4:3:2:1的比例分配1到4跳问题。

技术新颖性

Dr. Zero的技术新颖性体现在多个层面。首先，HRPO是对GRPO的重要改进，其核心洞察是：在自进化场景下，不同问题之间的结构相似性（相同跳数）可以作为构建基线的天然分组依据，这比为同一问题生成多个回答更有意义，因为问题生成的方差远大于回答生成的方差。其次，难度引导奖励函数的设计非常精巧，它不是简单的二元奖励，而是通过衰减函数将solver的通过率映射为连续的奖励信号，精确地将问题难度校准在solver的能力边界上。第三，多轮工具使用rollout管道使proposer能够利用搜索引擎生成需要多次信息检索才能回答的复杂问题，这在之前的无数据自进化工作中是前所未有的。最后，格式奖励r_f的引入（要求遵循特定的think/tool/question/answer格式）确保了生成数据的质量，消融实验显示移除格式奖励会导致平均性能从0.304下降到0.289。

**Figure 1**: The self-evolving LLM training framework (Huang et al., 2025a) that iteratively trains a proposer and a solver with minimal supervision.

**Figure 2**: The Dr. Zero self-evolution feedback loop. Guided by solver feedback, the proposer synthesizes verifiable and challenging queries, continuously enhancing the solver's search and reasoning capabilities.

实验结果

Dr. Zero在多个开放域问答基准上进行了全面评估，覆盖3个单跳数据集（NQ、TriviaQA、PopQA）和4个多跳数据集（HotpotQA、2WikiMQA、MuSiQue、Bamboogle）。在Qwen2.5-3B-Instruct上，Dr. Zero达到平均0.326的EM得分，与有监督的Search-R1（0.327）基本持平，且在NQ上显著超越Search-R1（0.397 vs 0.323，提升22.9%）。在7B模型上，Dr. Zero平均0.372，约为Search-R1（0.384）的97%，且在2WikiMQA上超越Search-R1（0.347 vs 0.326，提升6.4%）。与无数据基线相比，Dr. Zero在3B上超越SQLM*（0.233）和R-Zero*（0.256）分别39.9%和27.3%。消融实验显示每个组件都至关重要：移除格式奖励导致平均性能下降5%，移除初始文档导致性能下降19.5%，说明初始上下文对生成多样化问题至关重要。迭代实验表明性能在2-3轮后趋于稳定，3B模型在第3轮达到最佳0.326，7B在第2轮达到最佳0.372。

**Table 1**: Main results of Dr. Zero against few-shot/supervised methods.

**Table 2**: Performance comparison between Dr. Zero and data-free baseline methods.

**Table 3**: Learning dynamics of Dr. Zero with increasing iterations.

**Table 4**: Performance of Dr. Zero trained with different distributions of generated questions.

**Table 5**: Proposer (HRPO) hyperparameter settings.

**Table 6**: Solver (GRPO) hyperparameter settings.

**Table 7**: Ablation results of Dr. Zero.

**Table 8**: Comparison between HRPO and GRPO.

**Table 9**: Significance test of Dr. Zero against supervised methods.

**Figure 3**: Iterative reward dynamics of the proposer and solver in Dr. Zero.

**Figure 4**: Averaged entropy values and response lengths of Dr. Zero 3B during training.

查看结构化数据

任务	指标	本文	基线	提升
Natural Questions (NQ)	Exact Match	0.397 (3B) / 0.406 (7B)	Search-R1: 0.323 (3B) / 0.397 (7B)	3B: +22.9%相对提升
TriviaQA	Exact Match	0.572 (3B) / 0.608 (7B)	Search-R1: 0.537 (3B) / 0.606 (7B)	3B: +6.5%相对提升
PopQA	Exact Match	0.431 (3B) / 0.416 (7B)	Search-R1: 0.364 (3B) / 0.404 (7B)	3B: +18.4%相对提升
HotpotQA	Exact Match	0.298 (3B) / 0.362 (7B)	Search-R1: 0.308 (3B) / 0.380 (7B)	7B约为Search-R1的95%
2WikiMQA	Exact Match	0.291 (3B) / 0.347 (7B)	Search-R1: 0.336 (3B) / 0.326 (7B)	7B: +6.4%相对提升
MuSiQue	Exact Match	0.091 (3B) / 0.104 (7B)	Search-R1: 0.105 (3B) / 0.168 (7B)	7B约为Search-R1的62%
Bamboogle	Exact Match	0.200 (3B) / 0.360 (7B)	Search-R1: 0.315 (3B) / 0.408 (7B)	7B约为Search-R1的88%

局限与改进

论文揭示了多个重要的局限性。首先是性能天花板问题：3轮迭代后性能趋于稳定甚至下降（7B模型从第2轮的0.372降至第3轮的0.360），说明当前自进化方法存在固有的性能上限。其次是训练不稳定性：作者识别出不一致的token ID是常见的训练失败模式，尤其在7B模型上更频繁出现（如7B proposer第3轮的reward下降），这表明更大的模型在多轮搜索交互中更容易出现格式退化。第三是多跳能力的差距：虽然在单跳任务上Dr. Zero显著超越有监督基线，但在最具挑战性的多跳数据集MuSiQue上，7B模型仅达到Search-R1的62%，说明复杂多步推理仍是自进化方法的瓶颈。第四是跳数比例的权衡：4:3:2:1的比例对3B和7B模型都是最优的，但最优比例可能因模型规模而异，小模型更需要基础单跳能力，大模型则能从更多多跳训练中获益。最后是奖励hacking的风险：作者提到需要防范reward hacking和bias amplification，但在当前工作中尚未深入探索。

独立分析的弱点

从独立分析的角度，Dr. Zero存在几个值得关注的弱点。第一，HRPO的聚类策略相对粗糙——仅按跳数分组，但同一跳数内问题的难度差异可能很大（例如2跳问题可以是简单的实体链接，也可以是需要复杂推理的组合问题）。改进方向可以探索更细粒度的聚类特征，如搜索结果的稀疏度、推理链的复杂度等。第二，格式奖励r_f的设计较为启发式（四个二值子项求和，上限0.5），缺乏理论分析其对训练稳定性的影响。可以考虑自适应的格式奖励，根据训练阶段动态调整权重。第三，proposer和solver的交替训练是串行的，每轮各训练50步，这限制了训练效率。可以探索异步更新或更细粒度的交替策略。第四，当前框架依赖E5-base作为检索模型，检索质量可能成为瓶颈，尤其是在需要精确检索的多跳场景中。

未来方向

论文作者提出了几个重要的未来方向。第一是扩展自进化的稳定性，克服性能天花板和熵崩溃问题——当前方法在2-3轮后就趋于饱和，需要新的机制来维持长期进化动力。第二是防范reward hacking和bias amplification，在没有人类监督的情况下确保自进化过程的完整性和可靠性。第三是将框架扩展到更多任务类型，当前仅在QA任务上验证，可以探索代码生成、数学推理、规划等领域的应用。基于当前成果，还可以延伸出几个方向：(1) 探索更大模型（如13B、70B）上的自进化规律，论文已显示模型规模与最优跳数比例存在交互效应；(2) 引入人类反馈作为稀疏监督信号，在保持数据-free理念的同时提升进化质量；(3) 将HRPO推广到其他需要避免嵌套采样的场景，如多智能体训练；(4) 研究搜索工具本身的自进化，让检索策略也参与到进化循环中。

复现评估

从复现角度来看，Dr. Zero具有较好的可复现性。代码已开源在GitHub（https://github.com/facebookresearch/drzero），这大大降低了复现门槛。论文提供了详细的超参数配置（Table 5和Table 6），包括学习率（proposer: 5e-7/1e-6, solver: 1e-6）、batch size（256）、训练步数（每轮50步）、KL散度系数等。使用的基座模型Qwen2.5-3B/7B-Instruct是公开可获取的。检索系统使用E5-base模型编码英文Wikipedia dump，这些资源也都是公开的。主要的复现挑战在于：(1) 多轮工具使用rollout的实现复杂度较高，需要正确处理搜索工具调用、结果解析和格式校验；(2) 训练需要较大计算资源（论文未报告具体的GPU小时数，但从3轮各150步的规模推算，需要多卡训练）；(3) 训练存在不稳定性，需要仔细调参以避免失败模式。总体而言，有经验的研究团队应该能够复现论文的主要结果。

论文图表

Figure 5: System prompt and initial instructions for the proposer in Dr. Zero.

该图展示了proposer的完整系统提示和指令。提示要求proposer作为问题生成专家，基于提供的源文档生成恰好n跳的推理链。详细定义了hop的概念、生成流程（分析文档、设计推理链、搜索验证、输出格式），以及严格的规则（从文档开始、必须搜索、无剧透、链完整性等）。

该图展示了proposer的具体工作方式，是理解其如何生成多跳问题的关键，也是复现工作的重要参考。

Figure 6: System prompt and initial instructions for the solver in Dr. Zero.

该图展示了solver的完整系统提示和指令。提示要求solver先进行推理，如果缺乏知识则调用搜索引擎，搜索结果会在相应标签中返回，最终答案用answer标签包裹。格式比proposer简单，专注于回答问题而非生成问题。

该图展示了solver的工作方式，与Figure 5对比可以看出proposer和solver的不同角色设计。

Figure 7: Proposer example with hop = 1 and initial document title: Robert Holmes à Court.

该图展示了proposer生成1跳问题的示例。源文档提到Robert Holmes à Court在Massey University获得农业科学学士学位。Proposer直接从文档中提取信息，生成问题'At which university did Robert Holmes à Court graduate...'，答案为'Massey University'。这是最简单的情况，不需要搜索。

该示例展示了单跳问题的生成过程，作为基线帮助理解更复杂的多跳示例。

Figure 8: Proposer example with hop = 2 and initial document title: Equivalent carbon content.

该图展示了proposer生成2跳问题的示例。源文档提到'carbon equivalent'概念。Proposer首先识别Hop 1为'carbon equivalent'，然后搜索'carbon equivalent formula to determine spot weld failure'找到Hop 2，最终生成问题'What specific formula is used to determine if a spot weld will fail based on the carbon equivalent?'。需要1次搜索。

该示例展示了2跳问题的生成过程，说明了proposer如何通过搜索扩展推理链。

Figure 9: Proposer example with hop = 3 and initial document title: Steven Febey.

该图展示了proposer生成3跳问题的示例。源文档提到Steven Febey参加过2002年巴厘岛爆炸事件。Proposer进行2次搜索：第一次搜索在1988和2000年AFL总决赛都效力Melbourne Demons的球员，第二次搜索确认Robert Harvey符合这一条件。最终生成问题'Who is the only other active Melbourne Demons player to have played in both the 1988 and 2000 AFL Grand Finals?'。展示了proposer识别桥接实体的能力。

该示例展示了3跳问题的生成过程，体现了proposer将简单起点扩展为复杂多跳问题的能力。

Figure 10: Proposer example with hop = 4 and initial document title: Australian Labor Party (Australian Capital Territory Branch).

该图展示了proposer生成4跳问题的示例（一个不完全成功的案例）。源文档提到ACT Branch的历史。Proposer进行3次搜索，追踪从ACT Branch成立（1973年）到自治（1989年）再到立法议会首次开会的时间线。最终生成问题'In which year did the Australian Labor Party (ACT Branch) first sit as the Legislative Assembly?'。作者指出这个例子展示了潜在的失败模式，如指令偏离。

该示例展示了4跳问题的生成过程，同时也作为失败案例说明了复杂推理中的挑战。

Figure 11: Solver example for the question: Where was the place of burial of Charles Mathew's father?

该图展示了solver回答一个简单问题的过程。问题询问Charles Mathew父亲的埋葬地点。Solver进行1次搜索，根据搜索结果直接回答'Cork'。这是solver最简单的推理模式：单次搜索，直接回答。

该示例展示了solver的基础搜索和回答能力，作为理解更复杂solver行为的起点。

Figure 12: Solver example for the question: Where was the husband of Octavie Coudreau born?

该图展示了solver回答2跳问题的过程。问题询问Octavie Coudreau丈夫的出生地。Solver首先搜索找到丈夫是Henri Coudreau，然后搜索Henri Coudreau的出生地，最终回答'Sonnac'。展示了solver的多步推理和搜索能力。

该示例展示了solver的2跳推理过程，体现了其分解问题和迭代搜索的能力。

Figure 13: Solver example for the question: Which film has the director who died earlier, Gold For The Caesars or Heinz In The Moon?

该图展示了solver回答比较型多跳问题的过程。问题需要确定两部电影哪部的导演去世更早。Solver首先搜索两部电影的导演信息，找到'Heinz In The Moon'的导演Melvin Bernhardt去世于2015年，然后搜索'Gold for the Caesars'的导演Andres De Toth去世于2006年，最终回答'Gold for the Caesars'。展示了solver的复杂推理和多次搜索能力。

该示例展示了solver处理比较型复杂问题的能力，体现了其在多次搜索后进行综合推理的模式。

Figure 14: Solver example for the question: When did the people who first imported slaves to New York, come to the country where Lord of the Rings was filmed?

该图展示了一个solver未能完全成功回答的示例。问题需要多步推理：找到最早向纽约输入奴隶的人、确定《指环王》拍摄国家、找到这些人何时来到该国。Solver进行了多次搜索但最终未能给出完整答案，展示了在复杂多跳问题上的局限性。

该示例作为失败案例展示了solver的局限性，特别是在需要高度复杂推理链的问题上。