LiteResearcher: A Scalable Agentic RL Training Framework for Deep Research Agent

1 · 动机:为什么 deep research 的 RL 之前不 scale

1.1 历史脉络:从闭门 reasoning 到开放 web 的鸿沟

2024–2025 沿着 DeepSeek-R1 的 RLVR(reinforcement learning with verifiable rewards)路径,closed-world reasoning(数学、代码题)上 RL 已经能稳定地 scale——只要有 verifier、有合适难度,reward 曲线就一直涨。但一旦把 reasoning 接到外部世界(deep research 需要联网搜东西、读网页、跨源核对),先前所有工作(WebSailor、WebDancer、Search-R1、ZeroSearch 等)都遭遇了同一个困境: training saturation ——奖励曲线很快进入平台期,继续训反而下降。

论文给出的诊断很锋利: 瓶颈不在 RL 算法,在环境。就像 SWE-RL / R2E-Gym 把代码 agent 关进确定性的 sandbox 才让代码 RL 开始 scale,deep research 也需要一个"sandbox 化的 web"。

1.2 别的方案为什么不够

论文按"环境是怎么做的"把已有工作分成三类,每类各有结构性短板:

1.3 为什么这事并不平凡

看上去就是"把网爬下来 + 起个本地 search service",但要让训出来的策略不仅在虚拟世界 work、还能迁回 live web,需要解决几个互相纠缠的工程 + 算法问题:

• Corpus 与 task 必须 co-evolve。 如果先合成 task 再去爬网页,task 已经定了,corpus 是补丁;如果先爬完整 corpus 再合成 task,task 容易过度依赖局部信息源。本文做的是循环放大: 抽 QA → 用 question 当 query 抓相关页 → 扩 corpus → 再抽更复杂的 QA。
• 必须做"信源遮蔽" (Information Source Masking)。 否则 agent 学到的 policy 是"找当初合成 QA 用的那一页"——这是 corpus 内捷径,迁到 live web 立刻崩。本文每生成一个 QA 就从 corpus 删掉源页,逼 agent 必须从"周围相关页"去三角验证。
• 课程的轴是什么? 不是简单的 token 长度,而是 (a) 同时放大 max response length (32K → 48K) + 容许 turn 数 (40 → 60),让 agent 有空间学长 horizon;(b) 用 pass@8 当难度过滤器,只保留 1≤c≤7 的样本——零梯度 (c=0 或 c=8) 的题被丢掉。
• 本地 retrieval 必须和 live search 行为同构。 RAG 普遍用 chunk-level 索引,但 chunk 索引在 32M 页规模下会膨胀 10×、且和 commercial search engine 行为差异大。本文用页级索引 (page = title + summary 的单一向量),配合 BGE-M3 hybrid (dense + learned sparse) — 模仿真实 search engine 返回 page-level snippet 列表的行为。
• On-policy 与 long-horizon 的耦合。 多 turn ReAct 里,off-policy mini-batch 反复 update 会让早期 turn 的 trajectory 跟当前 policy mismatch 累积放大;本文实测 off-policy 训完掉到 66.8%,strict on-policy 到 68.9%。

2 · 背景速查

2.1 GRPO 复习

r_i(θ) = π_θ(o_i|q) / π_θrollout(o_i|q),没有 KL,没有 entropy。Advantage 是 group-normalized:Aᵢ = (rᵢ − mean) / std。本文严格 on-policy: 每个 rollout batch 用一次就丢。

3 · 架构总览: 三个支柱 + 一个虚拟世界

整个系统可以理解为三件事接力:

4 · 数据合成: 五种 atomic capability + 信源遮蔽

4.1 五种 atomic search capability

论文把"deep research"分解成五个原子能力。这是它的概念基石——后面 corpus 扩充、curriculum 都围绕"覆盖这五种"设计:

4.2 数据合成流水线 (重点: 信源遮蔽)

4.3 Worked example (合成视角): 那道 Fiat Tagliero 题怎么诞生的

反向论证: 如果不做信源遮蔽会怎样? agent 学到的最优策略是 "用 question 里的关键词组(modernist + Eritrea + 1938)直接搜",一击命中原始 Wikipedia 页。这条 policy 在 corpus 里 reward = 1,但迁到 live web 上当用户问真实问题(query 关键词不那么对齐时),立刻 fail —— 即所谓"corpus shortcut"。

5 · 本地 tool 环境: 32M 网页 + 页级索引

5.1 为什么用 page-level 而不是 chunk-level

这是个看似工程、实则关乎"虚拟世界保真度"的决策。常规 RAG 会把每页切成 ~512 token 的 chunk,每 chunk 独立 embed,这样精度更高(细粒度匹配)但:

• 32M 页 × 平均 20 chunks = 6.4 亿向量 → 索引体积 ≈ 1TB+,DiskANN 难以单机服务。
• 更关键: 真实 search engine (Google/Serper) 返回的就是 page-level snippet。chunk 索引让模型能拿到"页内某一段精准片段",这是它在 live web 上得不到的能力 — 训练时学会的 policy 会过拟合于 chunk 级精度。

所以 LiteResearcher 选 page = title + summary 单向量,索引大小压到 ~3 千万向量(约 100GB 量级),BGE-M3 hybrid (dense + learned sparse) 用 Milvus 融合,DiskANN + mmap 实现 ~150ms 查询延迟。Browse tool 单独用 PostgreSQL 存 Markdown 全文,1000 并发,~170ms 返页。

5.2 数字感受

整个 RL run 内累计 45.8M search + 27.4M browse = 73.2M tool call。如果走 Serper + Jina 的线上 API,光这部分账单 ~$59K (用便宜的 Serper) 到 $243K (SerpAPI)。本地化后 $0,而且 latency 10–46×,真正让 hundreds of concurrent rollout 成为可能。

6 · Curriculum RL: 难度过滤 + 两段式

6.1 难度轴是什么

论文 curriculum 不是 token 复杂度 / 题目长度,而是沿三轴同时升档:

6.2 为什么 pass@8 + 1≤c≤7 是关键

很简单的 GRPO 算法直觉: 如果 K=8 条 rollout 全对,A_i = (1−1)/0 全是 0,gradient = 0;全错也是 0。只有部分对部分错,才有 group-normalized advantage 来推策略动。所以 difficulty filter 的存在不是为了"加难度",而是为了保证每个 step 的 batch 里都有可学的对比信号。

反向论证: 如果不做 pass@8 过滤,Stage 1 训到 220 步时,corpus 里大量 direct-information 题已经全 pass,但 enumeration 题还全 fail,batch 里大半 sample 提供 0 gradient,等价于 batch size 缩水 + 信号高方差 → 训练 stuck。

6.3 严格 on-policy 的另一面

论文用一个对照实验把这一点说死了:

论文给的解释: long-horizon trajectory 上,policy lag 沿 turn 累积放大 — 一条 30-turn 的 rollout,在第 20 turn 时与 current θ 的 KL 已经远超普通 single-turn RL 的 mismatch。off-policy 复用相当于把这个 mismatch 的样本喂多次。

7 · Worked example: 一条 GAIA-style 题在虚拟世界中的 ReAct trace

选一道前面提的 aggregation 题: "In the Apollo Belvedere statue restoration project completed in October 2024, what was the material used by Andrea Felice, who employed traditional techniques, to create the replica that was used to replace the missing left hand of the original statue?"

反向论证: 如果数据合成时没遮蔽源页,那 turn 1 直接命中 Vatican 原页 → 1 turn 答完;模型从此学不到 "改 query 加约束 + cross-verify"。

8 · 实验关键结果与剖析

8.1 主表 (节选)

读法: 4B 在 GAIA 上 match Claude-4.5-Sonnet,超过 Tongyi 30B (70.9% → 71.3%);Xbench-DS 上 78% 超过 GPT-5-high 的 77.8%(开源最高)。WebWalker 上 72.7% 也压住 Tongyi 30B 的 72.2%。

8.2 SFT vs RL 拆解

论文的 SFT 用 Tongyi DeepResearch (30B) 当 teacher 蒸出 68K 条 trajectory。SFT 完成后 GAIA 只有 55.6% — 比老师本人 70.9% 低 15.3 个点(典型 distillation gap)。然后 RL 训练把这条曲线推到 71.3%,反而反超 teacher。

8.3 4B 何以胜 30B —— 论文的 attribution

把所有 ablation 拼起来,论文的因果链是:

1. 数据多样性: 73% 自合成 (覆盖 5 atomic) vs WebSailor 那种结构化合成 (只覆盖 multi-hop) → +8.1% GAIA (Table 4: 58.7 → 66.8)
2. 本地稳定环境: 700 步 monotonic 提升 vs AgentCPM 在 live web 训只 +3.8% / 整体 63.9%
3. 严格 on-policy: +2.1% GAIA over off-policy (66.75 → 68.89)
4. 两阶段 curriculum: +3.6% GAIA over Stage 1 plateau

合起来 ~+15.7% over SFT baseline。没有一项是新算法;每一项都是工程/方法论的设计。

8.4 "为什么不做 KL/entropy?"

这点论文一带而过但值得停一下: GRPO 默认有 KL 项约束 πθ ≈ π_ref。本文显式去掉。原因可能是: SFT init 已经离 base 很远,KL→ref 没意义;同时 outcome reward 噪声小、reward shaping 已由难度过滤替代,不需要 entropy 防 collapse。但这也意味着该 recipe 对 reward 设计非常敏感 — 没有 reward hacking 防护。

8.5 Long-context 是 4B 的真痛点

BrowseComp 任务 ~20+ 页/题,128K context 直接爆。论文用了一个memory mechanism: 64K 上限,撞限就调 summarization model 把每个旧 turn 压成一句话。这个 trick 把 BrowseComp 从 20.3% 推到 27.5%,但仍然弱于 30B 同行 (DeepSeek 67.6%)。模型容量在长 horizon 下确实是瓶颈—— 4B 能赢主要赢在 GAIA / Xbench 这种 ~10 turn 的中等长度任务。

9 · 与同类工作对比

对比要点:

• vs WebSailor: WebSailor 走的是"精心设计 multi-hop 合成图谱",本文反其道用"信源 scale + 简单合成"——结果 4B 反超 WebSailor 30B 接近 18 个点。这是论文最直接的 attribution。
• vs Tongyi 30B: 几乎是 8× 参数差,LiteResearcher 在 GAIA / WebWalker / Xbench 上全部追平或反超,只在 Frames (90.6 vs 83.1) 输 — Tongyi 工程优化和 scale 优势在长事实链上还在。
• vs SFR-DeepResearch: SFR 强调 "single agent + RL 就够",但其在 live web 训练,GAIA 66.0% 已经被本文 71.3% 拉开。
• vs AgentCPM-Explore (concurrent 4B baseline): 同样 4B,LiteResearcher 在所有 8 个 benchmark 全胜。AgentCPM 自己承认线上环境噪声让 RL 只 +3.8%,本文用本地环境实现 +15.7% — 这是两条工作的核心差异。
• vs DR-Venus (sibling note): 都是 4B 的 deep research 工作,角度互补 — 详见 01_DR-Venus_2604.19859.html。

10 · 局限 / 个人 take / 待验证问题

10.1 局限

• Long-context 是硬伤。BrowseComp 27.5% 仍弱于 30B 同行;memory summarization 是补丁不是解决方案。
• "虚拟世界 ↔ live web"的迁移性论文只用 final benchmark 验证,没做 distribution shift 的细粒度分析 — 比如 corpus 里没有的最新事件 (2025+) 上 policy 表现如何?
• 无 KL / entropy 的 GRPO 对 reward 设计极敏感。本文 LLM judge (Qwen3-30B-A3B) 的判错率是多少?有没有可被 hack 的模式?论文未量化。
• BGE-M3 自身是 fixed retriever。训练中 retriever 不更新,长期会成 ceiling — 真 web 用 Google 时排序逻辑不同,本地 ranker 学到的"哪些 query phrasing 检索效果好"的 policy 未必迁移。
• $220 的 Serper 投资被宣传为"零成本",但 corpus 扩张是离线一次性,如果要持续追加新内容(news / 时事题),边际成本会回来。
• 5 个 atomic capability 的覆盖均衡度: 数据 ablation 只对比 "ours vs multi-hop only",没拆开 5 个能力哪个对哪个 benchmark 提升最大。

10.2 个人 take

• 论文的"故事"对得上 SWE-RL 的成功 — 稳定的 sandbox 才让 RL scale,不是新 RL 算法的功劳。Deep research 这个领域之前没 sandbox,所以一直没起来。
• "page-level index"是个被低估的工程决策 — 它把"虚拟世界保真度"和"本地服务可行性"绑成一致,本质上是在主动选择"和真 search engine 行为同构"而非"检索精度最高"。
• 4B 反超 30B 的最强证据其实在 Table 9: SFT 后比 teacher 低 15 个点,RL 后高 0.4 个点 → RL 不是 "fine-tune teacher",是 "在 4B 能力空间内独立学到一种更紧凑的 policy"。这一点对 model-size scaling law 是个反例。
• 对 plane 上离线读者: 这篇值得抄的不是哪一行公式,是它的3-pillar 工程思路 — co-construct data/corpus、page-level mirror、curriculum-pass@K 过滤。这套设计模式可以直接迁移到 coding / scientific research / 客服等其他需要 deep tool-use 的 domain。

10.3 待验证问题

1. 把 corpus 扩到 100M+ 页(覆盖更多 long-tail domain)会继续涨吗,还是 4B 容量 saturate?
2. 把 Stage 2 之后再加 Stage 3 (64K context, 80 turns) 还会涨吗?Stage 1→2 +3.6% 之后是否进入新平台?
3. retriever (BGE-M3) 也加到 RL 训练循环里(joint 学 retriever),效果会怎样?
4. 5 个 atomic capability 的独立 ablation: 只去掉 enumeration 数据,enumeration benchmark 掉多少?
5. "信源遮蔽"的强度可调吗?如果只删一半源页,corpus shortcut 与多样性的 trade-off 在哪?
6. 把 LiteResearcher 的本地 tool 直接接到现有的 Search-R1 / WebSailor 上做 RL,能不能等比例提升?换言之,"环境"和"模型"的解耦程度。
7. LLM judge 改成基于 exact match / multiple-choice 后,reward variance 会怎么变?on-policy 是否还稳?

11 · 记忆点 (Memory points)