OpenSeeker-v2: Pushing the Limits of Search Agents with Informative and High-Difficulty Trajectories
工业界训练前沿搜索 Agent 的「标准菜谱」是 PT→CPT→SFT→RL 的重资源管线。本文反其道而行之，证明只要用「高信息量+高难度」轨迹，纯 SFT 也能达到 SOTA。三个简单的数据合成改动是关键：扩大知识图谱以丰富探索、扩大工具集、严格过滤低步数轨迹。仅 10.6k 数据上训练 30B 规模 ReAct agent，BrowseComp 46.0%、BrowseComp-ZH 58.1%、HLE 34.6%、xbench-DeepSearch 76.0%，全面 SOTA。
INSIGHT对于生成式搜索/Agent 落地，本工作把「复杂 RL pipeline」破除为可复用的工程问题——重点不在 RL，而在轨迹质量。社区/UGC 搜索若想做 DeepSearch 风格的复杂查询分解，可以先按本文的三条数据合成原则建一条 SFT-only 基线：(1) 知识图谱越大召回越多样；(2) 工具集大小决定 agent 行动空间；(3) 严格过滤低步数轨迹避免 shortcut。这是一条比「先 PT 再 CPT 再 RL」低 10x 成本的复制路径。
1. 问题与动机
OpenSeeker-v2 直面"前沿搜索 Agent 训练被工业巨头垄断"这一现实：训练一个 SOTA 的 Deep Search agent 通常意味着 PT→CPT→SFT→RL 的重资源管线，学术与中小团队无法复现。论文的核心立论是："这条管线真的必要吗，还是数据质量足够时纯 SFT 就够？"作者指出，OpenSeeker-v1 等先前工作虽然探索过 SFT 路径，但它们使用的合成轨迹要么太短、要么知识图覆盖太窄，给模型"shortcut 解题"留下了空间——很多问题靠简单关键词匹配就能解，导致模型学不到长程多步推理。在 BrowseComp / BrowseComp-ZH / Humanity's Last Exam / xbench 这种需要"持续在网页上探索"的 benchmark 上，先前 SFT 模型与重 RL 流程之间存在显著差距。本文要回答的具体问题是：在不引入 CPT 与 RL 的情况下，仅通过提升合成数据的"难度+信息量"，能否让 SFT 训出 SOTA 的搜索 Agent？这一问题对学术界与企业内部"复制工业级搜索 Agent"都有直接意义。
2. 方法详解
Base 模型与运行范式：基于 Qwen3-30B-A3B-Thinking-2507（总参 30B、激活 3B 的 MoE），256k 上下文，运行在 ReAct 范式下，单条轨迹最多允许 200 次工具调用。这一选择本身就反映了团队的核心判断——选 thinking-friendly + 长上下文的 base，让模型能"想深+查多"。
数据合成的三个关键改动（核心方法贡献）：
- Scaling Knowledge Graph Size：把每条合成数据所依托的知识子图从 k 个节点放大到 K 个节点，让证据图拓扑更丰富、强制模型做多跳推理而非单跳查找；
- Expanding Tool Set：在 v1 工具集基础上扩张工具种类，使 agent 能学到更灵活、功能更丰富的解题模式（搜索、浏览、抽取、对比等组合）；
- Strict Low-Step Filtering：硬过滤掉工具调用次数低于 T_min 的"直接命中型"轨迹——这些"shortcut 数据"看起来是正例其实在教模型偷懒。
训练设置：仅 10.6k SFT 样本，无 CPT、无 RL。论文未给出 optimizer/学习率/batch size/硬件的具体数字（这是论文实证披露层面的薄弱点）。
轨迹统计佐证设计动机：合成轨迹平均工具调用步数 64.67（v2）vs 46.97（v1）vs 36.01（RedSearcher），直接量化"任务难度上升"。这是三条改动的最直观体现：扩图+扩工具+过滤短轨迹，自然产出更长、信息更密的训练样本。
3. 核心技术贡献
- 数据难度替代 RL：把"复杂的 RL pipeline"问题降维成"高质量数据合成"问题。前者技术栈深、需要 reward model + rollout，后者只需把图扩大、工具加多、滤掉简单样本。这是一条让学术团队也能跑出 SOTA Agent 的实操路径。
- 三条简单可复现的合成原则：图大小、工具数量、最小步数，每一条都对应一个在 v1 上做不到的"长尾难度"，且互为正交。任何团队都可以单独 ablate 验证。
- Trajectory Length 作为难度指标：用平均工具步数定量衡量数据难度，给后续工作提供了可比较的标尺。
- 挑战 Scaling 假设：在 30B 参数下，10.6k SFT 数据居然能击败 671B DeepSeek-V3.1（BrowseComp 46.0% vs 30.0%）和 Claude-4.5-Sonnet（24.1%）——证明对于 deep search 这类任务，"训练数据轨迹质量"的影响可能远大于参数规模。
4. 实验结果分析
主表（30B-sized agents, ReAct）：
| Benchmark | OpenSeeker-v2 | Tongyi DeepResearch | Δ |
|---|---|---|---|
| BrowseComp | 46.0% | 43.4% | +2.6 |
| BrowseComp-ZH | 58.1% | 46.7% | +11.4 |
| Humanity's Last Exam | 34.6% | 32.9% | +1.7 |
| xbench | 78.0% | 75.0% | +3.0 |
最显著的提升在 BrowseComp-ZH（+11.4）——中文长程搜索本身是行业弱点，论文的"扩图+严格过滤"在中文知识图上效果尤为突出，说明数据难度论对低资源语种提升更大。
与 v1 对比（同 base 系列）：BrowseComp 29.5%→46.0%（+16.5），BrowseComp-ZH 48.4%→58.1%（+9.7），xbench 74.0%→78.0%（+4.0）。增益不是来自 base 模型升级，而是来自数据合成改造——这是论文最有说服力的对照。
惊人发现：OpenSeeker-v2 在 BrowseComp 上以 30B 击败 671B DeepSeek-V3.1（30.0%）与 Claude-4.5-Sonnet（24.1%），说明在"网页深度搜索"这类高度依赖工具使用模式的任务上，参数规模并非主导因素，反而是"是否在长程多步轨迹上充分训练过"决定上限。
实验局限：论文没有给出三条数据合成改动各自的 ablation（图扩大单独贡献多少、工具扩张单独贡献多少、低步过滤单独贡献多少），这是它的方法学短板。
5. 局限与未来方向
论文未设独立"限制"章节，但隐含约束清晰：
- 模型规模仅 30B：未尝试 70B/100B+，扩到更大规模数据是否仍 SOTA 未知；
- 基准只 4 个：BrowseComp 系列+HLE+xbench 都是"网页深搜"型，不能覆盖代码搜索、企业知识库搜索、垂直领域多模态搜索等长尾场景；
- 训练超参未披露：无 learning rate / batch / 训练步数等关键数字，复现门槛高于论文宣称；
- 缺少线上 A/B：所有结果都是离线 benchmark，没有真实搜索产品线上对比；
- 三条数据改动未做 ablation：哪一条贡献多少不清楚，给后续优化方向留了未解的空白。
6. 工业实践意义
对社区/UGC 搜索做"DeepSearch 风格复杂查询分解"的实践有三条直接启示：
- 先建一条 SFT-only 基线：不要急着上 RL。按 OpenSeeker-v2 的三条原则合成 1 万条轨迹（扩大业务知识图 → 扩工具集 → 过滤短轨迹），用 30B 级 thinking 模型 SFT，作为"DeepSearch v1"。论文证明这条路径在多个公开 benchmark 上能击败 RL 重型方案——对中小团队是 10x 成本下降。
- 数据质量比数据量重要：10.6k 数据胜过百万级 RL rollout，背后是"每条轨迹都强制走多步推理 + 多工具组合"。社区搜索可以模仿：把热门帖、问答、评论组成的"业务知识图"作为合成基底，强制每条轨迹必须跨 5 个以上节点+至少 3 种工具，过滤掉"直接搜关键词找答案"的简单样本。
- 部署考量：30B-A3B 激活 3B 的 MoE 推理对工业部署相对友好（A3B vs Dense 70B+ 显存压力差很多），但 64 步以上的工具调用链对延迟影响显著（每步 1-2s 网页 fetch+LLM 推理），社区搜索若要做实时 DeepSearch，需要分级触发（仅高复杂度 query 走 64 步链路，简单 query 走 1-step 兜底）。论文未给延迟数字，落地团队需要自测。
可借鉴的"避免坑"：论文未做三项数据合成改动的 ablation，落地团队应该在自己业务上做 ablation——某些场景下"扩工具集"提升很小（业务工具天然有限），重点应放在"扩图+过滤短轨迹"。
Tencent