Agent · RL · arXiv 2505.04588

ZeroSearch：训练时用一个 LLM 假装成搜索引擎

用 RL 教 LLM 搜索，要反复调用真实搜索 API：费用高、返回文档质量又不可控。这篇论文把搜索引擎换成一个用 SFT 微调过的小模型，在训练里生成「有用」或「噪声」文档，再用课程式 rollout 让难度由易到难。推理时照样接真实 Google。

Tongyi Lab, Alibaba Group · arXiv 2505.04588 v3 arXiv 2505.04588v3 ↗

TL;DR · 30 秒抓住核心

训练一个「会搜索的智能体」，最贵的一环是环境：每次 rollout 都要真的去问搜索引擎。论文把它换成一个 SFT 微调的 LLM——提示词里写 useful 就生成能答对的文档，写 noisy 就生成「相关但答不上」的文档，文档质量因此变成可编程的旋钮。

在这个旋钮上，论文加了课程式 rollout：训练步数越往后，生成噪声文档的概率 p_i 越高（Eq. 1）。模型先学会输出格式和基本搜索，再被逐步推入能吵的检索环境。

默认模拟器是 SFT 过的 Qwen-2.5-14B-Instruct。在 Table 3 里，六对「同骨干、同算法」的对比中，ZeroSearch 的平均 EM 都高于真实搜索的 Search-R1。代价是模拟器要占 GPU：Table 8 里 14B 模拟器约 $70.8 GPU 成本，换掉 Google 约 $586.7 的 API 成本。

34.47 / 32.81

Qwen-2.5-3B-Base 策略模型：SFT-14B 模拟器 vs Google 的 Avg EM（Table 4）

$586.7 → $70.8

约 64,000 次查询的训练成本：真实 API vs 14B 模拟器

+1.65

六对 base/instruct 对比的 Avg EM 平均差值（百分点，本文计算；逐对见 06）

难的不是让 LLM 会搜，而是让它「练得起」搜索

读完你应该知道：把搜索引擎放进 RL 训练循环，会同时炸掉预算和训练稳定性。

给 LLM 接搜索，常见路线有三代：提示词工程（拆查询、多轮检索）、SFT（让小模型模仿搜索轨迹）、测试时扩展（推理时做 MCTS 之类的搜索树）。论文认为前两者太依赖提示与模型本身能力，后者推理开销大§1。

更近的一步是直接拿 RL 去训「什么时候搜、搜什么、拿到结果怎么用」。Search-R1、R1-Searcher、ReSearch 都走这条路；DeepResearcher 和 WebThinker 则直接与 Google 这类商业引擎交互，训练环境最接近真实§1。问题就出在这一步：

成本

rollout 是反复发生的

RL 要多次采样、多次 rollout，训练过程可能涉及数十万次搜索请求。每次都要付 API 钱，规模一上去费用就不可控§1。Table 8 给了一个小规模的账：约 64,000 次查询、约 12 小时，Google 路线的 API 成本是 $586.7。

质量

返回什么，你说了不算

真实引擎返回的文档质量不可预测，给训练注入噪声。文档太差，模型学不会正确理解任务；文档太好，后段训练又缺乏挑战Appendix A。这种「忽好忽坏」是 RL 不稳定的来源之一。

所以问题的真正形状是：能不能把「搜索环境」从外部服务搬进训练循环内部，让它的成本接近零、质量由训练者调节？

前人两条路：静态语料够稳定但不够真，真实引擎够真但不够稳

论文把相关工作切成两格，每一格各有一个结构性短板；ZeroSearch 要同时拿到两边的长处。

A 路

Search-R1 / R1-Searcher / ReSearch：本地静态语料

做法：在 Wikipedia 之类的静态本地语料上做检索，RL 只训搜索与推理行为§2.2。

长处：语料固定，环境可控。

短板：抓不住真实世界交互的复杂性——返回的是「检索到的片段」，而不是引擎在实时场景里给你的那套东西。

B 路

DeepResearcher / WebThinker：接真实商业引擎

做法：训练时直接与商业搜索引擎交互，环境最接近真实网页搜索§2.2。

长处：分布最真实。

短板：文档质量不可控 + API 成本高、受限流，系统规模被卡住。

论文的定位很明确：保留 B 路的「文档长什么样」的文本风格，但把生成方换成自己可控的模型。作者给的判断是——真实引擎和模拟 LLM 的主要差别只在返回内容的文本风格，而这种风格可以靠轻量 SFT 补上§1。

这也决定了论文只拿 Search-R1 做 RL 类基线：理由是不需要复杂奖励设计、数据筛选或复杂训练流水线，可以和模拟引擎做直接对等的比较§4.2。

核心方法：把「生成什么质量的文档」变成一个提示词开关

读完你应该知道：模拟器怎么被造出来、「useful / noisy」两个词到底控制了什么、以及为什么少了 SFT 就退化。

3.1 三步造出模拟器（Search Simulation Tuning）

收轨迹：让 LLM 以多轮方式和真实引擎交互，直到给出答案，从中抽成「查询—文档」对§3.3。
打标签：用 LLM 作裁判，逐条判断文档是否包含足够信息回答对应查询：够 → useful，不够 → noisy§3.3。
轻量 SFT：让模型学会按查询生成两类文档。提示词里还会带上问题和标准答案，用来拓宽模拟器的知识边界；微调后它就能在 rollout 时动态控制质量§3.3。

3.2 模拟模板（Table 2）

Table 2 的模板里，中括号中的 useful / noisy 是可替换的词，其余是固定上下文。

You are the Google search engine. Given a query, you need to generate five [useful / noisy] documents for the query. The user is trying to answer the question: [question] whose answer is [ground truth]. Each document should contain about 30 words, and these documents should contain [useful / noisy] information. Query: [query] [Useful / Noisy] Output:

Table 2：每次生成五篇约 30 词的文档；问题与标准答案也放进提示，帮助扩展模拟器的知识覆盖

策略模型一侧沿用 Search-R1 的多轮模板（Table 1）：<think> 推理、<search> 发起查询、<information> 接收模拟文档、<answer> 作答。检索文档数在所有方法里统一为 5§4.3。

3.3 SFT 到底带来了什么：Table 4 的模拟器对比

Table 4 固定策略模型为 Qwen-2.5-3B-Base，只换训练时的「搜索引擎」：从 Prompt-3B 到 SFT-14B，再到真实 Google。SFT 越好，最终策略越强。

训练用搜索引擎	NQ	TriviaQA	PopQA	HotpotQA	2Wiki	MuSiQue	Bamboogle	Avg
Base Model（不训练）	12.40	19.40	11.20	4.40	6.80	2.00	5.56	8.82
Prompt-3B	35.80	56.00	42.20	25.60	27.00	4.20	15.28	29.44
Prompt-7B	38.40	59.40	43.40	27.80	30.00	11.00	9.72	31.39
Prompt-14B	40.00	55.40	42.00	26.80	33.20	10.60	12.50	31.50
SFT-3B	37.00	55.20	43.00	30.20	28.20	10.00	9.72	30.47
SFT-7B	40.40	60.40	45.40	31.20	30.80	12.60	13.89	33.53
SFT-14B	43.00	61.60	41.40	33.80	34.60	13.00	13.89	34.47
Google	40.60	60.00	44.20	29.20	32.00	11.20	12.50	32.81

Table 4（原表数字，EM 指标；策略模型均为 Qwen-2.5-3B-Base；评测统一走 SerpAPI 的 Google）

逐对算清楚（百分点，基于 Table 4 的 Avg 列）：

同尺寸，SFT 胜过 Prompt：3B 差 +1.03（30.47 − 29.44）、7B 差 +2.14、14B 差 +2.97。论文的解释是 prompt 方式仍有明显的分布差距，SFT 才能把「生成真实风格文档」学进去§5.2。
与 Google 的距离：SFT-7B 比 Google 高 0.72 点，SFT-14B 高 1.66 点（34.47 − 32.81）；SFT-3B 反而低 2.34 点。也就是说「3B 就能训出可用搜索」成立，但「越过真实引擎」这条线在 7B 靠规模才被突破§5.2。

还有一组容易漏读的数：哪怕模拟器只有 Prompt-3B，策略模型也从 8.82 涨到 29.44，比 SFT-3B 低 2.34 点，但相对不训练的 Base 已经是一个量级的变化。所以干净环境的「有」比「多真」更重要一部分——这是论文自己强调的 Scalability 论点§1。

模拟器并非单调受益？7B / 14B 的个别列反向点开看数据与推断

看 Table 4 的单列：SFT-14B 的 PopQA 是 41.40，低于 SFT-7B 的 45.40，也低于 Prompt-7B 的 43.40；Prompt-14B 的 TriviaQA 55.40 也低于 Prompt-7B 的 59.40。也就是说，「更大更细调的模拟器」在 Avg 上更好，但不是每一列都更好。

推断（依据：Table 4 单列数字对比）14B 模拟器在生成「noisy」文档时可能更接近真实干扰分布，PopQA 这类依赖实体精确匹配的任务反而更敏感；但论文没有对这一列现象做解释，这里只作为读表时的注意点，不建议据此下结论。

训练：文档难度是一条从易到难的曲线，而不是固定难度

读完你应该知道：噪声概率 p_i 怎么随训练步数变、三组模型的实际曲线差多少、以及 Random 基线为什么输了。

rollout 时策略模型发出查询，模拟器按 p_i 决定生成 useful 还是 noisy 文档。论文用 Eq. 1 把「难度」写成训练步数的函数：

p_i = p_s + ( b^i/m − 1 ) / ( b − 1 ) · ( p_e − p_s )

Eq. 1 · i 当前步、m 总步数、b 指数底数（默认 4）、p_s/p_e 初始/最终噪声概率

把 x = i/m 拿掉看结构：(b^x − 1)/(b − 1) 是从 0 涨到 1 的曲线，x 很小时它就是 x 本身（线性起步），x 接近 1 时陡增。所以噪声比例前松后紧：前一半训练里模型主要在干净文档上学会格式和基本搜索，后段才被迫处理噪声§3.4。

训练进度 i / m 0.00

指数底数 b 4

noisy useful

当前噪声概率

拖动滑块看 p_i 的变化。

参考点：i/m = 0、0.25、0.5、0.75、1.0 处的 p_i（默认 b=4 时）。切换模型会更新 p_s/p_e，p_s/p_e 取自 Appendix F；m=200 步见 Appendix D。

建议这样读：先把滑块拖到 i/m = 0.5。Qwen-2.5-7B 的噪声概率此时正好是 0.25，而 Qwen-2.5-3B 在曲线末端的 p_e 也才 0.25——两条课程最后到达的难度不同，这是 Table 5/6 里 3B 组更容易接近「课程优势上限」的原因之一推断（依据：Appendix F 的 p_e 设定与 Table 6 中 3B 的课程/随机差距小于 LLaMA）。

Random 基线为什么输：Table 6

Table 6 里 Random 的意思是训练全程把噪声概率固定为 0.5，不是随机变§5.5。两个骨干上，课程组都比 Random 高：

Qwen-2.5-3B-Base

+1.88 点

Curriculum 34.47 vs Random 32.59（Table 6，Avg EM）

LLaMA-3.2-3B-Base

+1.23 点

Curriculum 36.07 vs Random 34.84（Table 6，Avg EM）

注意这两组只学了一门课：从干净到噪声。Random 的开局就是一半噪声，模型还没学会调格式就被噪声淹没，这正是论文所说的「先学会调用搜索、再面对噪声」§5.5。

手算两块：Eq. 1 与 Table 6 的差值点开核对 JS 与手算是否逐位一致

参数取自：p_s/p_e 取自 Appendix F；b 默认 4 取自 §3.4；Curriculum/Random 取自 Table 6。页面 JS 用 Math.pow(b, i/m) 实现，手算同样只用到 pow，步骤对齐。

① 7B 组，i/m = 0.25，b = 4：

p = 0.75 × (4^0.25 − 1) / (4 − 1) = 0.75 × (1.41421356 − 1) / 3 = 0.75 × 0.41421356 / 3 = 0.75 × 0.1380712 = 0.1035534 → 显示为 1036（×10⁻⁴）

② LLaMA 组，i/m = 0.5，b = 4：

p = 0.25 + (4^0.5 − 1) / (4 − 1) × (0.5 − 0.25) = 0.25 + (2 − 1) / 3 × 0.25 = 0.25 + 0.3333333 × 0.25 = 0.25 + 0.0833333 = 0.3333333 → 显示为 3333（×10⁻⁴）

Table 6 差值：

Qwen-2.5-3B-Base：34.47 − 32.59 = 1.88 点 LLaMA-3.2-3B-Base：36.07 − 34.84 = 1.23 点

页面卡片显示的 +1.88 与 +1.23 即上述两式结果，未做相对换算。

一条 rollout 里，谁在生成文档、谁在学

读完你应该知道：训练时模拟器是冻结的、只在跑的 token 上有梯度，以及为什么这对 PPO / GRPO 都成立。

论文 Figure 1 画的是「没有搜索引擎的 PPO / GRPO」：上面一行是 PPO 的价值模型 + GAE，下面一行是 GRPO 的组内奖励计算，两行的起点都是同一个Rollout Module：模拟 LLM 替代引擎。模拟器参数在整个训练中冻结§3.1。

Figure 1 的重绘：左侧策略模型与右侧冻结模拟器的交互被放进标准 RL 循环；下方两支是 PPO 与 GRPO 的差别。

三个工程细节决定了它跑得稳

奖励用 F1 而不是 EM：初版实验里 EM 奖励容易被打成「答案写长一点以扩大命中」的策略，即 reward hacking；改用 F1 平衡精确率和召回率。格式不加额外奖励，因为模型自己就稳定输出合规格式§3.5。
文档 token 不算损失：rollout 序列里既有策略模型的 token，也有模拟器给的文档 token。对后者不掩码会引入不稳定；LLaMA-3.2-3B 上的消融（Table 7）里，掩码 Avg 为 36.07，不掩码为 34.53，差 1.54 点§3.6。
server 与训练并行：实验中模拟器部署在 4×H20，RL 训练在另 4×H20；加更多 GPU 能提高模拟器生成吞吐、加速大规模 rollout§4.3 / §1。

算法侧只测了三种：REINFORCE、GRPO、PPO。以 Qwen-2.5-3B-Base 为策略模型时，Avg 分别为 34.47 / 33.17 / 32.67，REINFORCE 最高；论文说这与 Search-R1 的观察一致§5.4。

效果：六对模型全赢，但每一对的赢面并不一样大

读完你应该知道：与 Search-R1 的逐对差值分布、以 EM 为指标时哪些列并不占优，以及成本表的实际形状。

Table 3 的条件：七个数据集（NQ / TriviaQA / PopQA / HotpotQA / 2Wiki / MuSiQue / Bamboogle），训练集是 NQ + HotpotQA 合并；评测并非零样本——所用指标是 EM§4.1，返回文档数统一 5，评测全部走 SerpAPI 的 Google§4.3；默认模拟器为 SFT 过的 Qwen-2.5-14B-Instruct，默认算法 REINFORCE§4.3。基线中包含 Search-R1，也用真实 Google 做引擎。

6.1 ZeroSearch vs Search-R1：逐对差值

策略模型	ZeroSearch Avg	Search-R1 Avg	差值（点）
Qwen-2.5-7B-Base	40.93	39.51	+1.42
Qwen-2.5-7B-Instruct	39.08	38.17	+0.91
Qwen-2.5-3B-Base	34.47	32.81	+1.66
Qwen-2.5-3B-Instruct	31.70	28.13	+3.57
LLaMA-3.2-3B-Base	36.07	34.21	+1.86
LLaMA-3.2-3B-Instruct	30.98	30.48	+0.50

Table 3（EM，Avg 列为七数据集平均；差值由本页计算）

Search-R1（真实 Google） ZeroSearch（SFT-14B 模拟器）

数值逐字取自 Table 3 的 base 行。

读这张表要注意三点：

差值集中在一个点上下：六对差值 0.50–3.57 点，均值 +1.65，跨模型的总体标准差 0.97 点推断（由 Table 3 的 6 个差值计算；本身是描述统计，不是显著性检验）。最大的一对出现在 Qwen-2.5-3B-Instruct（+3.57）。
Avg 领先 ≠ 每一列领先：例如 Qwen-2.5-3B-Base 的 PopQA，ZeroSearch 41.40 低于 Search-R1 的 44.20；LLaMA-3.2-3B-Base 的 Bamboogle 15.28 对 19.44。论文的表述是「consistently outperforms baselines」§4.4，指的是每个骨干上的 Avg 行。
Instruct 版本的总分普遍低于 Base：六对里每种骨干的 Instruct 都比 Base 低 1.2–7.0 点，是模型家族本身的差别，不是方法差别。

6.2 成本：真正省下来的是什么

Table 8 的设定：约 64,000 次搜索请求、约 12 小时（Qwen-2.5-7B 骨干、batch 64、rollout 重复 5 次、200 步）Appendix D。API 按 SerpAPI 价格估，GPU 按 AWS 价格估。

模拟器	Queries	训练时长	GPU	API 成本	GPU 成本	总成本
SFT-3B	~64,000	~12 h	1 × A100	$0.0	$17.7	$17.7
SFT-7B	~64,000	~12 h	2 × A100	$0.0	$35.4	$35.4
SFT-14B	~64,000	~12 h	4 × A100	$0.0	$70.8	$70.8
Google	~64,000	~12 h	—	$586.7	$0.0	$586.7

Table 8（原表数字）

用默认的 SFT-14B 和 Google 比：总成本从 $586.7 降到 $70.8，绝对少 $515.9，相对 Google 降低 87.93%（515.9 / 586.7），约为原来的 1/8.29。注意这是「模拟器只跑这一份 RL 训练」的账；论文自己也提醒，模拟器 GPU 在 rollout 时用满、在策略更新时闲下来，存在闲置浪费Appendix D。

6.3 一笔容易误读的账：64,000 从哪来

Appendix D 写的是 batch 64 × rollout 重复 5 × 200 步，直接乘出来是 64,000 次查询；这恰好等于 batch 64 × 1,000 步。两组乘数是对得上的推断（64×5×200 = 64×1,000 = 64,000）。论文没有说明这两个数的对应关系，这里不作为确定结论。

边界：模拟器换掉了 API 账单，但换不掉「知识截止」和「GPU 闲置」

读完你应该知道：论文自己承认的局限有哪些，以及从数据能读出的额外限制。

paper

需要 GPU 承诺

论文 §6 的局限讨论很直接：模拟搜索 LLM 需要 GPU 服务器，虽然比商业 API 便宜，却增加了基础设施成本；Appendix D 进一步指出 GPU 利用率不均衡，建议让多个 RL 任务共享一个模拟器 server 来摊薄§6, Appendix D。

data

模拟器的知识边界靠「问题 + 答案」撑

模板里带上问题和标准答案，是为了扩宽模拟器的知识覆盖Table 2。这项设计的代价是：训练数据里模拟器「知道」答案，学习信号来自可用的答案而非真实的「无结果」。推断（依据：Table 2 模板把 ground truth 写进提示，而真实引擎不会）。在这种设定下，模型学到的「没有找到」行为可能偏少。

data

训练集与评测集不完全同分布

训练只用 NQ + HotpotQA 的合并集§4.3；七个评测集里 TriviaQA / PopQA / 2Wiki / MuSiQue / Bamboogle 都是 OOD。Table 4 里 SFT-14B vs Google 的反超本身是在这七个集子上测的，换一组难集需要重新核。

metric

指标只看答案对不对

论文的奖励只看答案准确率（F1），不加格式奖励，也不罚「瞎搜」§3.5。Fig 2c 显示训练中交互轮数随奖励一起上升再稳定§5.3——这意味着「用更少的搜索拿到同样答案」这种效率目标并不在它的优化里。

一句话：ZeroSearch 换掉的不是「真实网页」这件事，而是训练循环里对真实网页的不受控依赖。推理时模型依然面对 Google；模拟器在什么情况下比 Google 更适合做老师，取决于课程设计——Table 4 的 SFT-7B 与 Google 只差 0.72 点，这个差距比 14B 的「反超」更贴近这套方法的稳定预期。