OpenResearcher：自建检索器与 96K 轨迹，长程深度研究的数据从哪来
OpenResearcher: A Fully Open Pipeline for Long-Horizon Deep Research Trajectory Synthesis
秒懂
- 它是什么？
- OpenResearcher 把长程深度研究拆成可复现的三段：11B token 语料上的自建检索器、GPT-OSS-120B 生成的 96K 轨迹、30B-A3B 蒸馏模型。它解决的是数据来源问题，不是推理框架问题。
- 适合谁用？
- OpenResearcher 适合已经确定要做深度研究能力、但被数据来源卡住的团队：自建检索器加 11B token 语料这条路，省掉的是外部 Search API 的调用成本和不可复现性，代价是语料与索引要自己维护。如果你只是想找一个开箱可用的搜索智能体，或者不想承担索引构建和存储，它不合适，直接用带搜索 API 的现成 agent 更省事。
- 能商用吗？
- 未经许可不能。GitHub 在这个仓库里没有找到许可证文件；没有许可证，默认即「保留所有权利」：你可以阅读代码，但不能复用。使用前请看看 README，或先征得作者同意。
- 还在维护吗？
- 在维护。仓库最近一次提交在 97 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的不是推理问题，是轨迹来源问题
长程深度研究的训练数据很难搞。一次完整的 research 过程可能包含上百轮工具调用，中间夹着检索、翻页、放弃、重查，这种轨迹既不能靠人工标注堆量，也很难用公开网页直接合成。OpenResearcher 的定位就在这里：README 把它描述为一条完全开放的管线，产出的是 DeepResearch 轨迹，而不是一个即插即用的搜索框。
目标读者比较明确。一类是手里有基座模型、想补上长程检索行为的研究团队；另一类是需要在内部复现评测、不想依赖闭源搜索接口的工程团队。README 给出的数字是 96K 条高质量轨迹，单条轨迹由 GPT-OSS-120B 配合原生 browser tools 生成，长度可达 100 轮以上。这个规模说明它是为训练而非演示准备的。
需要说清楚的是，仓库同时发布了模型权重、数据集、训练方法和评测框架四样东西，但四者的成熟度并不相同。模型和数据集有独立的 HuggingFace 入口，评测框架就在本仓库里，训练部分 README 标注为可选章节。把这条管线当成一个整体来评估，容易高估其中较弱的一环。
自建检索器替代外部 Search API，是这套设计的支点
README 在 Features 里写得很直接：轨迹在自建 retriever 上大规模生成，检索范围是一个专用的约 11B token 语料，因此不需要外部 Search API。这是整条管线里最关键的一个选择，也是它和多数深度研究项目的分界线。
换成外部搜索接口，问题会立刻出现。搜索结果的排序会随时间漂移，同一条轨迹今天能复现、下个月未必；调用量上去以后成本按次计费；更麻烦的是，轨迹里记录的检索动作无法在离线环境重放，评测和训练用的是两套不同的检索行为。自建检索器把这三件事一次性收进本地：语料固定，索引固定，检索结果可重放。
代价同样清楚。11B token 的语料需要下载、切分、建索引并长期保存，这部分工作量和存储开销不会因为省掉 API 费用而消失，只是从按次付费变成了自建运维。README 没有给出索引构建的耗时或硬件要求，也没有说明语料的具体来源构成，这两点在做容量规划时必须自己确认。
另一个细节是生成端。轨迹由 GPT-OSS-120B 配合 vLLM recipes 中记录的原生 browser tools 产生，也就是说生成阶段的工具调用形态和推理阶段是一致的，这为后续蒸馏提供了行为上的对齐基础。
从轨迹到 30B-A3B：蒸馏链条上的信息损耗
管线可以概括成三段数据流。第一段，在 11B token 语料上运行自建检索器，配合 GPT-OSS-120B 的原生 browser tools 交互，产出长程轨迹。第二段，把 96K 条轨迹整理成数据集发布。第三段，用这批数据蒸馏出一个 30B-A3B 的模型。README 提到论文里包含 distillation recipe，具体配比和超参需要看论文，仓库正文没有展开。
这条链条上有一个容易被忽略的损耗点。教师模型是 120B 级别，学生模型是 30B-A3B，激活参数更少。长程任务的特点是错误会累积：第 40 轮的一次误判，可能让后面 60 轮全部走偏。蒸馏能传递的是最终的行为序列，但教师模型在每一步的犹豫、回退和重新检索的动机，未必都能被学生模型学到。README 没有给出学生模型在轨迹长度维度上的性能衰减数据，只有聚合后的基准分数。
30B-A3B 这个规格本身是有意为之。总参数 30B、激活约 3B，意味着推理时的显存占用和延迟都落在可自托管区间，而不是必须走多卡集群。对于想在自己环境里跑深度研究的团队，这比一个更大的稠密模型更实用。
装起来跑通，靠的是两条不同的评测路径
README 的目录结构给出了实际的入口：Environment Setup 下分 Installation 与 Deep Research Benchmarks Preparation，然后是 Configuration、Quick Start、Benchmark OpenResearcher。评测部分给了两个并列示例，这两个示例恰好对应两种检索来源。
Example 1 是 BrowseComp-Plus 配合本地搜索引擎，走的就是自建检索这条路，需要先完成语料准备和索引搭建。Example 2 是 GAIA 配合 Serper API，README 明确标注为 No Local Search Needed。这个区分很实用：想快速验证模型行为、不想先搭索引的人，可以从 Example 2 入手；想复现论文里那条完全离线路径的人，必须走 Example 1。
配置项集中在 Configuration 一节，具体键名需要以仓库文件为准，README 正文只给出章节指引，没有逐一列出键值。Quick Commands 一节提供了可直接执行的命令集合，Evaluation 一节说明评测结果的产出方式。
这里有一个实际约束。两个示例依赖的检索后端不同，意味着评测环境需要同时准备本地索引和外部 API key，或者明确选定其中一条路径。README 没有说明两条路径的结果是否可直接比较，跨路径对比分数时要谨慎。
54.8% 这个数字该怎么读
README 给出的核心指标是 BrowseComp-Plus 上的 54.8% 准确率，并列出对比对象包括 GPT-4.1、Claude-Opus-4、Gemini-2.5-Pro、DeepSeek-R1 和 Tongyi-DeepResearch。仓库还单独发布了 Eval Logs 数据集，这一点比单纯贴一个分数更有价值，因为原始日志允许外部复核评测过程。
读这个数字需要几个前提。它是单一基准上的结果，README 另外提到在 BrowseComp、GAIA、xbench-DeepSearch 上也有表现，但正文只给出主表图片，没有把各基准的具体数值写进文字。因此 54.8% 不能直接外推成通用检索能力。
更关键的是检索条件。BrowseComp-Plus 配合的是本地搜索引擎，也就是模型在它训练时所用的那套语料和索引上作答。换一套检索后端，分数未必保持。README 没有给出跨检索器的迁移结果。如果你的生产环境用的是别的搜索源，这个数字的参考价值会明显下降，需要自己在目标检索器上重跑一次。
许可证与维护成本里没写清楚的部分
仓库元数据里的 License 字段是 unknown，README 正文也没有出现许可证段落或 SPDX 标识。这不是可以略过的细节。数据集、模型权重和代码可能适用不同的条款，而 HuggingFace 上的数据集和模型各有自己的页面，条款未必与仓库一致。在把 96K 轨迹或 30B-A3B 权重用于商业产品之前，需要逐个确认三处的授权状态。本文不提供法律意见，只指出这个空白确实存在。
维护成本主要落在语料这一侧。11B token 的语料一旦落地，就需要存储、索引和版本管理。语料更新意味着索引重建，索引重建意味着此前生成的轨迹在检索行为上不再严格可复现。README 没有描述语料版本与轨迹版本之间的对应机制，这是长期使用时会碰到的问题。
仓库最近一次推送时间在 2026 年 6 月，没有检索到正式 release。这意味着使用方式是以 main 分支为准，升级时需要自己比对提交差异，没有版本号可以锁定。对于要把这套管线接进生产流程的团队，建议在本地 fork 并固定一个提交哈希，而不是跟随 main 分支。
和直接用搜索 API 的 agent 比，差在哪
更常见的做法是搭一个带搜索 API 的 agent：模型在推理时实时调用外部搜索，拿到网页片段后继续推理。这类方案上手快，不需要维护语料，覆盖面跟随搜索引擎本身。区别在于可复现性和成本结构。
实时搜索的 agent，同一条 query 在不同时间会得到不同结果，评测分数会随搜索索引变化而波动，训练数据的采集也无法重放。OpenResearcher 走的是另一条路：把检索范围固定成一个约 11B token 的封闭语料，代价是覆盖面被这个语料的上限锁住。语料里没有的内容，模型再努力也检索不到。这是设计上的取舍，不是缺陷。
选择依据因此变得清晰。需要覆盖开放互联网、接受结果不可完全复现的场景，实时搜索 API 更合适。需要稳定复现、要控制单次检索成本、并且能接受语料边界的研究或训练场景，自建检索器这条路更划算。README 提到 NVIDIA 的 NeMo Data Designer 用 OpenResearcher 做深度研究轨迹生成，这属于后一类用途。
还有一点需要提醒。README 的 News 部分列出了论文、演示、下载量等信息，这些可以说明项目受到的关注，但不能替代对管线本身的判断。真正决定能否用的是语料规模、索引构建方式和评测入口这三样具体的东西。
编辑结论
OpenResearcher 适合已经确定要做深度研究能力、但被数据来源卡住的团队：自建检索器加 11B token 语料这条路，省掉的是外部 Search API 的调用成本和不可复现性，代价是语料与索引要自己维护。如果你只是想找一个开箱可用的搜索智能体，或者不想承担索引构建和存储，它不合适，直接用带搜索 API 的现成 agent 更省事。动手前先确认三件事：仓库里许可证标识是否已经补齐，Evaluation 一节给出的评测入口能否在你自己的检索器上跑通，以及 OpenResearcher-Corpus 的下载与索引规模是否落在你的磁盘预算内。
社区笔记