知乎：https://zhuanlan.zhihu.com/p/1898699101354332848
（已授权）
系列文章第三篇，前两篇见：
- 端到端的训练，怎么复现 Deep ReSearch（上） ：先从 Deep Search 做起
- 端到端的训练，怎么复现 Deep ReSearch（中） ：围绕着"Deep"，解构 Jina 项目的实现
来到下篇，本文聚焦于各大厂最新的 Deep Research 产品 。虽然目前市面上已经有不少评测，但我们专注于从技术层面来“猜测”这些闭源产品的核心逻辑——通过分析它们的页面交互、官方博客、以及工程师的分享，来猜测它们背后的工作原理。 我们在中篇中曾详细拆解过 Jina 的工作流，再简要回顾一下：
Jina 构建了一个循环的任务处理流程，其中维护一个 gaps 问题列表 （gap 翻译成中文为"缺口"，这这里可以理解成，为了研究一个课题，会有很多子问题需要先解决，而且随着研究得越深，会有更多的缺口问题出现，不断补充到这个 gaps 列表中），在一个由模型自主判断的处理闭环中，每个 step，系统从gaps 列表中抽取一个问题，每个 step 由模型自主根据上下文信息，采取以下几种 action之一：
- 搜索（Search） ：基于当前问题联想生成search query 并调用搜索引擎。
- 阅读（Visit） ：从返回的搜索结果中决定重点阅读哪些 url。
- 反思（Reflect） ：判断当前内容是否仍存在 gap，如果有，将新问题加入 gaps。
- 回答（Answer） ：针对当前问题进行回答。
这样一步步循环推进，直到 gaps 列表清空，或达到 token 限制。整个过程中，依靠系统 system message 和 knowledge message 来进行上下文管理。
这种机制理论上已经能完成非常复杂的调研任务，但实际应用时会面临两个主要问题：
- 效率低 ：如果一个调研任务涉及的隐含问题很多，可能需要很多个 step 才能完成，速度慢。
- 上下文能力受限 ：当前大模型虽然有长上下文能力，但仍在记忆和生成长文本方面存在挑战。
那有没有办法解决呢。当然有，秘诀就是拆分 + 套娃 。
我们可以把 Jina 的工作流当成一个“最小单元”。这个“最小单元”可以理解为：输入一个问题，经历搜索-阅读-反思-回答的闭环，得到一个高质量回答。
面对一个复杂问题，比如“写一篇关于 XXX 的长报告”，我们首先调用一个擅长规划的模型，将其拆解为多个章节、子问题：比如生成：第一章、第二章、第三章、第四章，接下来，每个章节都调用上面那个最小单元，独立完成自己的部分，最后由一个擅长总结信息和写作的模型生成长报告。 不仅可以按照一级目录拆分，我们还可以多层套娃：章节 1.1.1、1.1.2、 1.2、 2.1... 先把 3 级问题解决，再解决 2 级问题...，最后完成整个报告的写作。
这个策略的好处是
- 局部优化效果 ：每个“最小单元”任务简单、明确，模型能更精准处理。
- 效率更高 ：并行处理每个子问题，整体速度加快。
- 模型能力解耦 ：可以将任务拆给不同擅长的模型 —— 有的擅长写报告，有的擅长搜索推理，各司其职。
现在我们来看各大厂的 Deep Research 产品，你会发现，都有这样的雏形。
不同厂家的 deep research
Genspark
Genspark 是一家由前百度高管景鲲和朱凯华于2024年创立的人工智能初创公司。该公司致力于通过多智能体框架（MoA）重塑传统搜索引擎体验，提供高效、个性化的信息搜索服务。
link: https://www.genspark.ai/
blog: https://mainfunc.ai/blog/genspark\_autopilot\_agent\_deep\_research\_v2
在 Genspark 的工作流程中，系统首先会调用一个名为 initial_plan 的工具，用来对问题进行初步规划。然而，这个规划过程更像是 Jina 中的 reflect 阶段，感觉它将问题扩展成多个子问题，并将这些子问题添加到待研究的 gaps_列表中。这些子问题并不立刻进行处理，而是通过反思不断调整和更新。
接下来，Genspark 进入了一个循环的过程，包括搜索、阅读和推理。与 Jina 的方法不同的是，在这个循环过程中，系统可以对 gaps 列表中的多个问题同时进行搜索。例如，第一个红框对应的是上面 plan 的问题1，第二个红框对应的是问题2,3,4。整个流程是不断反复推理、搜索和阅读的过程，直到系统认为信息已经足够完备，才会开始写作。
grok
接下来，我们试试 grok，本质也是不断推理、搜索、阅读。
link: https://x.ai/news/grok-3
Gemini
谷歌据我所知是第一个推出Deep Researc的公司。虽然在之前的版本中，Gemini系统表现略显不足，但随着3月底Gemini 2.5 Pro的发布，系统效果显著提升。
link: https://gemini.google/overview/deep-research/
blog: https://blog.google/products/gemini/google-gemini-deep-research/
Gemini 的官网其实提到了很多干货的，比如提到在面对复杂的用户问题时，会首先制定一个详细的研究计划，将问题分解为一系列更小、更容易处理的子任务。接下来，系统会监督执行这些子任务，并灵活决定哪些任务可以并行处理，哪些需要按顺序完成 。待收集到足够的信息后，Gemini会综合所有结果并生成一份详尽的报告。在生成报告的过程中，系统会批判性地评估收集到的信息，识别关键主题和不一致之处，并通过多轮自我审查提高报告的清晰度和细节 。Gemini的上下文除去利用gemini 1million的上下文的能力外，还结合了RAG技术，可能是先将相关的文章存储起来，然后在需要时通过向量检索进行召回。
这里，问示例问题，谷歌会先做方案，拆分问题，还要用户确认，然后再开始执行，
在这个例子中，首先会将“京东入局外卖的动因”、“市场格局与竞争态势”和“京东的潜在优势”这三个问题（对应问题1,2,3）放在一起进行搜索。
在制定下一步计划时，系统貌似继续研究问题4,5。然而，这个过程中并非所有的步骤都严格按顺序执行。例如这里，在获得第一步的搜索结果后，它的后续研究研究方向就变了，猜测是后续的研究方向可能会根据已获得的信息进行调整，研究过程显得非常灵活和动态。其次，看起来并不是所有开头的8个子问题都会被依次搜索。系统可能会根据前几步的结果，判断是否已经收集到了足够的信息，从而跳过某些问题，直接回答后续的问题。
产品总结
从整体来看，虽然这些模型在细节上有所差异，但它们都依靠推理来分解任务并执行多个步骤。它们的主要差异体现在一些细节和执行流程上：
- Genspark ：该模型的特点是首先进行“计划”阶段，但在执行过程中似乎没有进行“反思”或“回答并评估回答”这两个步骤。
- Grok ：与Genspark相似，Grok同样缺乏“反思”及“回答并评估回答”这两个环节。
- Gemini ：作为一个更为成熟的产品，Gemini在执行时会先进行“计划”阶段，并且能够判断哪些子任务可以并行处理，哪些需要串行执行。在写作过程中，Gemini采用批判性写作方法：可能是在完成一个篇章后，使用另一个prompt来评估写作质量。如果生成的内容不符合预期，Gemini会重新生成。换句话说，Gemini将“尝试回答并评估回答”的步骤放在了最后写作过程中。此外，从谷歌的UI来看，Gemini不会实时渲染写作内容，而是在完成后一次性渲染，应该就是这个原因。
从生成内容的长度来看，Gemini输出的篇幅最长，个人觉得部分字眼有点啰嗦。尽管太短肯定不行，但过长的内容可能给用户带来阅读压力。
端到端 vs 固定工作流：两者的折中方案
目前来看，jina 、 genspark 、 grok 、 Gemini 、 Openai的deep research，其实都不是严格意义上的端到端。 真正端到端形态的，长的像是豆包目前的“深度思考”功能 ，如下图。豆包的深度思考实现了“边想边搜”的能力。在一条单一的思维链中，模型一边推理一边发起搜索请求，只需要维护一条持续生长的长链即可 。
而目前不少厂商推出的Deep Research功能，其实更偏向于端到端和固定工作流的中间形态。这些系统会先将任务抽象成若干个action，再依据预设的 plan 和上下文记忆，让llm自己决定当前step应该采取的 action。从架构上看，这其实更像是“多轮对话系统 ”——每个 step 类似于一轮对话，由模型决定下一步要采取的行动。
不过，从工程实践的角度，这种“折中式”方案反而更加可控和高效 ，原因有以下几点：
- 提高效率与资源利用率 ：将任务拆解后，不同模型可以分工协作，各司其职。
- 例如：专门针对规划任务训练过的小模型负责规划，推理模型负责处理复杂推理，擅长写作的模型负责总结写作等生成任务。 就像一个项目团队，有实习生、初级工程师和高级工程师，要把任务拆分，协同作业，更容易做成一个 big project，而不是把所有活都交给最厉害的人干，一个人干完当然可以，但再厉害的人也无法面面兼顾，且会效率低下 。
- OpenAI 的 CPO Kevin Weil 在近期的一次https://www.youtube.com/watch?v=scsW6\_2SPC4 中就提到， 好的系统设计更倾向于多模型协同 ，“All-in-one”并不一定是最优解
- 适当抽象和任务拆分，适合 scaling ：通过将任务中常见操作抽象为有限的 action（例如：调用外部工具、读取结果、反思规划、尝试回答等），模型只需根据上下文动态选择合适的 action。这种抽象之后，系统的可扩展性大大提升
- 在广度上 ：只需新增各类 MCP（工具接口），如文献搜索、Google 查询、Markdown 自动生成等，就能不断拓展系统能力。
- 在深度上 ：可以通过强制执行多轮反思、设定 token 使用下限、对回答进行不同维度的评估等策略，确保模型深入思考、避免浮于表面。
这种机制下，我们更推崇的是一种理念：
Less Control, More Tools/MCPs （不是 0 控制，而是适度控制 + 工具赋能）。
模型怎么训练啊
回到本系列的主题——模型究竟是如何训练的？
尽管在 端到端的训练，怎么复现 Deep ReSearch（上） ：先从 Deep Search 做起 中，我们讨论了一些论文中提出的训练思路，但中篇和下篇更多地专注于工作流的拆解，讲解了工程实现细节和设计理念，实际上并没有明确回答“如何训练”的核心问题。
因为训练问题本身非常复杂。
最近，姚顺雨老师在文章
The Second Half|AI 时代进入了下半场: https://ysymyth.github.io/The-Second-Half/
中提出了一个重要观点，他认为“AI 的下半场，学会定义问题/评估，比方法更重要 ”。这一观点让我深有共鸣。我们正面临着从“做题家”到“出卷人”的转变，因为现在的主流训练范式，“推理 + 强化学习（RL）”已经跑通了 ，只要我们能定义好如何在与环境交互时设计合适的奖励机制（当我们学会这个问题怎么定义怎么评估时，其实我们就多多少少知道奖励该怎么设计），用这种范式训练模型后就能让效果直接拔高。
然而，问题也随之而来：
“Deep Research”这样的复杂应用为例，奖励到底应该如何设计呢？
这一点并不简单。举个例子，现在有两个报告：
- 报告 1 写作非常流畅、逻辑严谨，但引用不够丰富。
- 报告 2 写作较差，但引用信息丰富且权威。
我们应该给予哪份报告更多的奖励？对于 Deep Research 这样的任务，我们需要更细粒度的评估标准，比如引用是否合理多样、报告中的公式计算是否准确、是否能够挖掘长尾信息等等等等 。。并不是简单地给报告打一个0到10分的奖励就能解决问题。
OpenAI 的 Deep Research 在他们的 system-card 中展示了训练数据和方法。他们的训练数据集涵盖了从有标准答案的“objective auto-gradable tasks with ground truth answers”到“more open-ended tasks with accompanying rubrics for grading”。在训练过程中，他们使用思维链模型作为评分器，将模型的输出与标准答案或评分标准进行对比评分。
这意味着，openai的训练数据既包括像简单的多跳问答这种有固定答案的任务，也包括更加开放式的写作任务。里面的"rubrics"（评分规则）我认为是最有价值的东西，是我最想拿到的东西 。
字节最近发布的一篇论文《Exploring Data Scaling Trends and Effects in Reinforcement Learning from Human Feedback》也讨论了RL 的训练问题。论文指出，基于规则的设计更容易帮助模型学习到 fine-grained 的信息，不容易遭受“reward hacking”。而纯开放式任务则可能被模型“钻空子”，只学会表面技巧，忽视了任务的深层价值，因此只能学习到coarse grained信息。DeepSeek-R1 的最后强化学习阶段，也是通过混合使用基于规则的奖励和开放的奖励模型来进行训练。
因此，目前的建议是：最好结合有标准答案的任务（做 rule-based reward）与开放式任务（要专门训一个reward model来奖励） ，将这两种类型的奖励混合使用。除此之外，其他的训练策略或许还需要社区更多的研究工作。
写在最后
本系列分别探讨了 Deep Research 系统的不同层次。在上篇中，我们讨论了端到端训练多跳搜索的方法；中篇通过拆解 Jina 项目，深入探讨了实现 Deep 的理念；下篇则对 Genspark、Grok 和 Gemini 等产品进行了对比。
目前市面上的 Deep Research 已经具备一定能力，但说实话感觉离直接把报告当成一个专业分析师的报告还有一段距离，工程的优化是有上限的，未来需要更明确的训练方式来提升效果。
PS：看到这里，如果觉得不错，可以来个点赞 、在看 、关注 。 给公众号添加【星标⭐️】不迷路！您的支持是我坚持的最大动力！
欢迎多多关注公众号「刘聪NLP」，加入交流群，交个朋友吧，一起学习，一起进步！