DR-Venus: Towards Frontier Edge-Scale Deep Research Agents with Only 10K Open Data

1 · 动机:为什么 edge-scale + 10K 这条路值得走

1.1 历史脉络:deep research 的"巨型化"惯性

2024 → 2026 的 deep research 赛道走的是越大越好的路线。Tongyi-DR-30B、WebSailor-V2-30B、DeepMiner-32B-RL、REDSearcher-30B-A3B 几乎清一色 30B 起步,要么 dense 要么 MoE A3B。原因看上去也合理:long-horizon 任务(BrowseComp 平均 ~50 turn,xBench-DS 也 30+ turn)对 reasoning depth 和 tool-use 稳定性都极挑剔,小模型做不到 200 turn 不"漂"。

但产业落地侧的现实反过来:

• Cost: 一次 BrowseComp 评测 30B 模型上 200 turn × 256K context,推理成本是 4B 的 ~10×;真要部署在企业内部的"研究助手",30B 是单卡装不下、双卡也勉强的尺寸。
• Latency: 长 trajectory 下 user 等不起;4B 在 H100 上单卡可达 100+ tok/s,30B-A3B 即使 MoE 仍要 2× 以上延迟。
• Privacy: 金融、医疗、法律领域的 deep research 不能把 query 送到 OpenAI / Gemini;边缘部署是硬需求。

过去的小模型尝试(WebSailor-7B、DeepDive-9B、WebExplorer-8B-RL、AgentCPM-Explore-4B)在 BrowseComp 上停留在 5–24 分,跟 30B 班级有 20+ 分差距。社区默认"小模型做不动 deep research",DR-Venus 的核心就是要打破这个默认。

1.2 为什么纯 SFT 对 deep research 不够 — 也为什么纯 RL 也不够

常见的两个极端方案各有死结,论文用一张对比表把它们都判了死刑:

1.3 为什么这事不平凡:三个深坑

"用 IG 当 turn reward"听上去简单,但在实际工程里有几个非平凡的复杂度:

1. Reward scale 不平衡。turn-level IG reward 是 log-prob 差,scale ~0.001 量级;outcome reward 是 0/1,normalize 后仍有数量级差。如果直接相加,IG 完全淹没 outcome 或反过来。论文设计了 IG-Scale 自适应缩放,在 outcome 弱(整 group 全错)时压低 IG 权重,避免被 IG 误导收敛到 local optimum。
2. Search vs browse 的 IG 不同质。search 给的 snippet 是噪声大的探索性信号,browse 才能拿到具体证据。如果对所有 turn 都算 IG,容易奖励"反复搜索但不深读"的捷径。论文的 browse-aware 分配把 IG 锁定在 browse turn 上,且把它归功到该 browse 之前的所有 search turn(类似 reverse credit),这是 DAPO/GRPO 都没考虑的。
3. Format penalty 的粒度。200-turn trajectory 里只要 1 个 turn format 错,trajectory-level format penalty 会把所有 199 个正确 turn 一起惩罚。turn-level format penalty 用 −λ_fmt 替换该 turn 的 reward,实现外科手术式监督。

这三件事 + IGPO 本身 + 数据 pipeline,组合起来才让 4B 跑得动 deep research。任意一项缺位都会塌。

2 · 背景速查

2.1 关键术语

2.2 GRPO → IGPO 的演化路径(一图回顾)

3 · 两阶段 recipe 全景图

论文的方法可以被压成下面这张图。注意 stage 1 输出的不是 checkpoint 本身,而是已经会做基本 tool use 的格式化 agent;stage 2 的核心是把这些 trajectory 的执行可靠性拉到能拿到 outcome reward 的地步。

4 · Stage-1: Agentic SFT 的四步数据清洗 + turn-aware 重采样

"为什么 10K 够"——单看数据量是不够的,关键是数据怎么用。论文的四步 pipeline 配合一个非平凡的重采样,把 9365 条有效 trajectory "扩容"到 18745 条分布上更长程的训练样本。

4.1 四步清洗(数字都是论文里的)

4.2 为什么 turn-aware 重采样这么管用

这是本文 SFT 阶段的核心 trick。一般"upsample 长样本"的方法在普通 SFT 里效果有限,但对 deep research 是正中靶心:

• BrowseComp 类任务 reward 完全集中在 long-horizon trajectory 上,trajectory 越长,该样本里"必须正确 plan / 不漂移 / 不 forget"的监督密度越高。
• 原始 dataset 的长度分布偏短(60% 在 0–50 turn),如果不重采样,模型容易被"短 trajectory 噪声"主导,学出"快答型"行为。
• 论文的 ablation:不重采样的版本在 BrowseComp 22.8 → 重采样 26.8(+4.0),BC-ZH 33.9 → 35.7(+1.8)。这是不改任何模型架构纯靠数据分布换回来的 4 个点。

4.3 Worked example: 一条 raw trajectory 的"清洗 → 重采样"轨迹

4.4 反向论证: 不做重采样会怎样

看 ablation:DR-Venus-4B-SFT (w/o Resampling) 在 BC 上只有 22.8。同样 9365 条数据,只是分布偏短,小模型就更倾向于"看完前 30 turn 直接 finalize"。这种偏好对 BrowseComp 致命——很多正确答案要 100+ turn 的 cross-source verification。

5 · Stage-2: IGPO + turn-level info-gain reward

SFT 给的是"会做"的 baseline,RL 要解决"做对"的稳定性。论文最有特色的就是奖励信号的设计——不是发明 RL 算法,是发明 dense reward。

5.1 IG reward 的物理直觉

定义重温(论文 Eq. 3):

把 ground truth answer g 包装成跟 model response 同 schema(<think>Now there's enough information to answer</think><answer>G</answer>),然后看模型 condition 在前 t turn 的 history 上,生成这串 g 的 log-prob 提升了多少。

• 提升 = 这一 turn 找到了有用证据 → 正 reward
• 下降 = 这一 turn 误导了模型(read 到无关页面、tool call 失败注入 noise)→ 负 reward
• 持平 = 这一 turn 啥也没干 → 0

关键:reward 的"密度" = trajectory 长度。200 turn 自动得到 200 个 reward signal,无需任何 reward model 也无需人工标注。这是把 GRPO 那种 "trajectory 一个 scalar reward" 直接变成 "每 turn 一个 reward"。

5.2 Browse-aware IG 分配

但 search turn 给的 reward 是噪声大的——一次 search 返回的是 snippet 列表,模型对 g 的 log-prob 可能小幅震荡。论文观察:browse turn 才是真正"读到证据"的 turn,IG 信号在 browse 上更可靠。

方案:

1. 只在 browse turn 计算 IG。
2. 把这个 IG 同时归功给 该 browse turn 自己 + 所有上一个 browse 之后的 search turn。

这相当于把 search 当作"在为下一次 browse 做准备工作",reward 来自 browse 的成功——一种粗粒度 credit 反向分配。

5.3 Turn-level format penalty

Eq. 4 简洁但 powerful:

具体实现:任何一个 turn 的 <think>...</think><tool_call>...</tool_call> schema 不合法、JSON 解析失败、tool name 错拼,就把那个 turn 的 reward替换成 −λ_fmt(论文用 1.0)。论文实测 λ_fmt = 1.0 是 IG/outcome 同尺度 normalize 之后的合理值。

对比 trajectory-level format penalty:后者会给整条 200 turn trajectory 一个 -1 的 scalar,即使只是第 87 turn 错了一个 JSON 引号——前 86 turn 的正确行为也被打压。turn-level 把惩罚 surgical 化,只罚那一 turn。

5.4 IG-Scale: 解决 reward 不平衡

归一化后 (Eq. 5),IG reward 和 outcome reward 都是 ~N(0,1) scale。但当 group 里全错(outcome 全 0,normalize 后 σ_O ≈ 0,μ_O = 0,数值上整组 r̃_O ≈ 0)时,outcome 完全失声,policy 被 IG 单独驱动,容易学到"refine reasoning 但永远不答对"的 local optimum。

IG-Scale 的做法(Eq. 6–8):

其中 η=0.3, δ=10⁻⁸, s_max=10。直觉:

• 当 outcome 强(M_O 大): s 大 → IG 被放大,turn 信号充分发力。
• 当 outcome 弱(M_O ≈ 0): s ≈ η/M_IG,小到 0.3 / 1 = 0.3 量级,压低 IG 影响,避免被噪声 IG 带跑。

"weak outcome → 谨慎更新"是经典的 RL 鲁棒性设计,这里把它做到了 turn-reward 缩放上。

6 · 公式拆解:从 IG reward 到 IGPO objective

6.1 各步公式 + 物理含义

6.2 IGPO objective 的梯度长什么样

Eq. 10 形式上跟 GRPO 完全一样,差异只在 advantage:

其中 ρ_i,k = π_θ(u_i,k|c_i,k) / π_θ_old(u_i,k|c_i,k) 是 token-level importance ratio,R̃_i,k 是该 token 所属 turn 的折扣累加 reward——同 turn 内所有 token 共享 R̃(论文明确说 "for tokens from turn t, we set R̃_i,k = R̃_i,t")。

等于说:turn 是 reward 单位,但 ratio / clip 是 token-level 算的;这是个干净的 hybrid granularity。

6.3 数值敏感性: γ 怎么影响 reward 累加

7 · Worked Example: 一个 BrowseComp 查询的 8-turn IG 轨迹

让我们看一个具体的 BrowseComp 风格问题怎么走完一条 trajectory,以及 IG reward 在每一 turn 长什么样。

Query:"一位在 1980 年代曾代表美国参加奥运会铁饼项目、退役后转入大学教练岗位、且其学生在 2000 年悉尼奥运会上拿过铁饼银牌的运动员叫什么名字?"
Ground truth (g): John Powell

设 baseline log π_θ(g | q) = −7.20(模型一开始毫无线索)。我们追踪 8 个 turn 的 IG。

关键观察:

1. turn 6 的 IG 负了 — 模型发现自己读到的页面跟 g 不符,这在 IG 框架里是正常信号:它说"这条 browse 让我对 g 的 confidence 反而下降",policy 学到"以后类似上下文不要走这条路"。
2. browse-aware 把 t=3 的 +2.10 平分给 t=1, 2, 3 —— 之前那两次 search query 被回溯地确认为"对最终找到 Powell Wikipedia 有用"。
3. 整条 trajectory 8 个 turn 拿到 4 个非零 reward(t=3, 6, 7 的 IG + t=8 的 outcome)。如果用 GRPO 的 trajectory-level reward,只有 t=8 一个 +1,前 7 turn 全是 0,GRPO 没法分辨"turn 1 的 search 是好还是坏"。
4. IG-Scale: 这一条 trajectory outcome = 1, group 里如果其它 trajectory 也是 1 居多,M_O 就大,IG 被放大;如果其它都失败(outcome=0),IG-Scale 会自动压低 IG 防止过激更新。

8 · 实验关键结果

8.1 主表(精简版)

读法:RL 在 6 项里 5 项跑赢 SFT(GAIA 是 -1.0,文中归因为 GAIA 偏知识问答而非 long-browse)。在 xBench-DS-2505 上,DR-Venus-4B-RL 74.7 已经触到 Tongyi-DR-30B 的 75.0,7.5× 的参数差被吃掉了。

8.2 GRPO vs IGPO ablation(最 load-bearing 的一张表)

这张表是论文的 punch line:同样 RL infra、同样数据、同样 base,GRPO 在 BrowseComp 上甚至退化(−1.5),IGPO 反而 +2.3。证明 long-horizon agentic RL 的瓶颈是 reward 信号设计而不是优化算法本身。

8.3 Pass@K 揭示的 capability ceiling

论文的 take:Pass@1 这种"reliability"指标低估了小模型的 capability ceiling。RL 主要把 Pass@1 / @2 拉起来——即 reliability;Pass@16 的 ceiling 反而 SFT 已经接近极限(BC-ZH SFT @16 = 78.5,RL @16 = 76.5,RL 略低,论文归因为 RL 数据全英文导致中文分布漂移)。

8.4 Tool use 分析:correct trajectory 的 browse ratio 更高

聚合数:overall browse ratio SFT 17.49% → RL 22.46%;correct trajectory 的 browse ratio 23.71% → 28.96%。RL 不是简单"少 search 多 browse",而是把 tool-use 行为校准到 success 模式上。xBench-DS-2510 上 SFT 反常("wrong browse 多于 correct browse"),RL 把这个反常修正了。

9 · 与同类工作对比

定位总结:DAPO 解决"RL 怎么稳定地训",IGPO/DR-Venus 解决"RL 信号怎么足够 dense"。两条线可以叠加 — 论文没做但理论上 DAPO 的 dynamic sampling + IGPO 的 turn-level IG 可以共存。

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

10.1 论文里 explicit 的局限

• RL 训练数据全英文,导致 BC-ZH Pass@K 大 K 上 RL 略输 SFT(distribution mismatch)。
• γ=0.95 / λ_fmt=1.0 / s_max=10 的超参没有 sensitivity ablation,工程上是手调出来的。
• 外部 tool 只暴露 search + browse,没探索 code execution / file ops 等更复杂动作,跟 GAIA 的某些子任务不完全契合(GAIA 上 RL 反而 -1.0)。

10.2 我的个人 take

• "4B + 10K"是论文最有价值的定位声明,而不是数字本身。它说明 deep research 不是"必须 30B"的赛道。这对端侧、私有部署是一个非常实用的论点。
• IGPO 不是 DR-Venus 发明的,但 DR-Venus 把它"产品化"。browse-aware 分配 + format penalty + IG-Scale 是把原始 IGPO 拉到能在 200-turn 长 trajectory 下不崩的关键工程胶水。
• turn-aware 重采样的 +4 在 BC 上 比 RL 的 +2.3 都大。这暗示 SFT 数据分布的工程价值被严重低估;社区在追 reward shaping 时容易忽视"我的训练分布到底长什么样"。
• Pass@K 揭示的 ceiling 是 future direction 信号:4B 模型 Pass@16 在 BC-ZH 已经 78.5,比 GPT-5 High Pass@1(65.0)高一截,说明 small model + verifier-based test-time scaling 是潜力巨大的研究方向(但本文没做这一步)。
• 对 GRPO 失败的解读值得警惕:论文说 "GRPO 在长 trajectory 上不行" 主要是因为 reward 太稀疏;但这并不证明 GRPO 算法本身不对——给它一个 dense reward(就像 IG 这样),GRPO objective(Eq. 10 几乎跟 IGPO 同形)也能 work。所以读论文时要分清"算法 vs reward 设计"。

10.3 待验证问题

1. IG-Scale 对结果到底贡献多少?论文用了它,但没单独 ablate。η=0.3 这个数字怎么来的?
2. browse-aware vs all-turn IG 的 ablation 缺失。如果在 search turn 也算 IG,效果是更差还是相当?
3. γ ∈ {0.9, 0.95, 0.99, 1.0} 的扫描没看到。在 200-turn 任务里,折扣窗口是关键超参。
4. SFT 数据如果不是 REDSearcher 而是 Tongyi-DR / WebSailor 的 trajectory,recipe 还成立吗?(数据源对 IG-reward 的相关性的影响)
5. RL 的 1K query-answer 对来源也是 REDSearcher,跟 SFT 数据存在分布同源性。如果 RL query 来自不同分布(BrowseComp 的 train split 等),还能稳定吗?
6. 4B 已经触到 Pass@16 = 78.5(BC-ZH),那 8B / 14B 在同 recipe 下的 Pass@K ceiling 是多少?有没有 diminishing returns 的拐点?

11 · Memory points (冷启动复述)