端到端的训练，怎么复现 Deep ReSearch（下） ：前沿的产品形态
仅用于站内搜索，没有排版格式，具体信息请跳转上方微信公众号内链接
系列文章第三篇，前两篇见：
端到端的训练，怎么复现DeepReSearch（上）：先从DeepSearch做起
端到端的训练，怎么复现DeepReSearch（中）：围绕着”Deep”，解构Jina项目的实现
来到下篇，本文聚焦于各大厂最新的DeepResearch产品。虽然目前市面上已经有不少评测，但我们专注于从技术层面来“猜测”这些闭源产品的核心逻辑——通过分析它们的页面交互、官方博客、以及工程师的分享，来猜测它们背后的工作原理。我们在中篇中曾详细拆解过Jina的工作流，再简要回顾一下：
Jina构建了一个循环的任务处理流程，其中维护一个gaps问题列表（gap翻译成中文为”缺口”，这这里可以理解成，为了研究一个课题，会有很多子问题需要先解决，而且随着研究得越深，会有更多的缺口问题出现，不断补充到这个gaps列表中），在一个由模型自主判断的处理闭环中，每个step，系统从gaps列表中抽取一个问题，每个step由模型自主根据上下文信息，采取以下几种action之一：
搜索（Search）：基于当前问题联想生成searchquery并调用搜索引擎。
阅读（Visit）：从返回的搜索结果中决定重点阅读哪些url。
反思（Reflect）：判断当前内容是否仍存在gap，如果有，将新问题加入gaps。
回答（Answer）：针对当前问题进行回答。
这样一步步循环推进，直到gaps列表清空，或达到token限制。整个过程中，依靠系统systemmessage和knowledgemessage来进行上下文管理。
这种机制理论上已经能完成非常复杂的调研任务，但实际应用时会面临两个主要问题：
效率低：如果一个调研任务涉及的隐含问题很多，可能需要很多个step才能完成，速度慢。
上下文能力受限：当前大模型虽然有长上下文能力，但仍在记忆和生成长文本方面存在挑战。
那有没有办法解决呢。当然有，秘诀就是拆分+套娃。
我们可以把Jina的工作流当成一个“最小单元”。这个“最小单元”可以理解为：输入一个问题，经历搜索-阅读-反思-回答的闭环，得到一个高质量回答。
面对一个复杂问题，比如“写一篇关于XXX的长报告”，我们首先调用一个擅长规划的模型，将其拆解为多个章节、子问题：比如生成：第一章、第二章、第三章、第四章，接下来，每个章节都调用上面那个最小单元，独立完成自己的部分，最后由一个擅长总结信息和写作的模型生成长报告。不仅可以按照一级目录拆分，我们还可以多层套娃：章节1.1.1、1.1.2、1.2、2.1…先把3级问题解决，再解决2级问题…，最后完成整个报告的写作。
这个策略的好处是
局部优化效果：每个“最小单元”任务简单、明确，模型能更精准处理。
效率更高：并行处理每个子问题，整体速度加快。
模型能力解耦：可以将任务拆给不同擅长的模型——有的擅长写报告，有的擅长搜索推理，各司其职。
现在我们来看各大厂的DeepResearch产品，你会发现，都有这样的雏形。
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，本质也是不断推理、搜索、阅读。
link:https ://x.ai/news/grok-3
谷歌据我所知是第一个推出DeepResearc的公司。虽然在之前的版本中，Gemini系统表现略显不足，但随着3月底Gemini2.5Pro的发布，系统效果显著提升。
link:https ://gemini.google/overview/deep-research/
blog:https ://blog.google/products/gemini/google-gemini-deep-research/
Gemini的官网其实提到了很多干货的，比如提到在面对复杂的用户问题时，会首先制定一个详细的研究计划，将问题分解为一系列更小、更容易处理的子任务。接下来，系统会监督执行这些子任务，并灵活决定哪些任务可以并行处理，哪些需要按顺序完成。待收集到足够的信息后，Gemini会综合所有结果并生成一份详尽的报告。在生成报告的过程中，系统会批判性地评估收集到的信息，识别关键主题和不一致之处，并通过多轮自我审查提高报告的清晰度和细节。Gemini的上下文除去利用gemini1million的上下文的能力外，还结合了RAG技术，可能是先将相关的文章存储起来，然后在需要时通过向量检索进行召回。
这里，问示例问题，谷歌会先做方案，拆分问题，还要用户确认，然后再开始执行，
在这个例子中，首先会将“京东入局外卖的动因”、“市场格局与竞争态势”和“京东的潜在优势”这三个问题（对应问题1,2,3）放在一起进行搜索。
在制定下一步计划时，系统貌似继续研究问题4,5。然而，这个过程中并非所有的步骤都严格按顺序执行。例如这里，在获得第一步的搜索结果后，它的后续研究研究方向就变了，猜测是后续的研究方向可能会根据已获得的信息进行调整，研究过程显得非常灵活和动态。其次，看起来并不是所有开头的8个子问题都会被依次搜索。系统可能会根据前几步的结果，判断是否已经收集到了足够的信息，从而跳过某些问题，直接回答后续的问题。
从整体来看，虽然这些模型在细节上有所差异，但它们都依靠推理来分解任务并执行多个步骤。它们的主要差异体现在一些细节和执行流程上：
Genspark：该模型的特点是首先进行“计划”阶段，但在执行过程中似乎没有进行“反思”或“回答并评估回答”这两个步骤。
Grok：与Genspark相似，Grok同样缺乏“反思”及“回答并评估回答”这两个环节。
Gemini：作为一个更为成熟的产品，Gemini在执行时会先进行“计划”阶段，并且能够判断哪些子任务可以并行处理，哪些需要串行执行。在写作过程中，Gemini采用批判性写作方法：可能是在完成一个篇章后，使用另一个prompt来评估写作质量。如果生成的内容不符合预期，Gemini会重新生成。换句话说，Gemini将“尝试回答并评估回答”的步骤放在了最后写作过程中。此外，从谷歌的UI来看，Gemini不会实时渲染写作内容，而是在完成后一次性渲染，应该就是这个原因。
从生成内容的长度来看，Gemini输出的篇幅最长，个人觉得部分字眼有点啰嗦。尽管太短肯定不行，但过长的内容可能给用户带来阅读压力。
目前来看，jina、genspark、grok、Gemini、Openai的deepresearch，其实都不是严格意义上的端到端。真正端到端形态的，长的像是豆包目前的“深度思考”功能，如下图。豆包的深度思考实现了“边想边搜”的能力。在一条单一的思维链中，模型一边推理一边发起搜索请求，只需要维护一条持续生长的长链即可。
而目前不少厂商推出的DeepResearch功能，其实更偏向于端到端和固定工作流的中间形态。这些系统会先将任务抽象成若干个action，再依据预设的plan和上下文记忆，让llm自己决定当前step应该采取的action。从架构上看，这其实更像是“多轮对话系统”——每个step类似于一轮对话，由模型决定下一步要采取的行动。
不过，从工程实践的角度，这种“折中式”方案反而更加可控和高效，原因有以下几点：
提高效率与资源利用率：将任务拆解后，不同模型可以分工协作，各司其职。
例如：专门针对规划任务训练过的小模型负责规划，推理模型负责处理复杂推理，擅长写作的模型负责总结写作等生成任务。就像一个项目团队，有实习生、初级工程师和高级工程师，要把任务拆分，协同作业，更容易做成一个bigproject，而不是把所有活都交给最厉害的人干，一个人干完当然可以，但再厉害的人也无法面面兼顾，且会效率低下。
适当抽象和任务拆分，适合scaling：通过将任务中常见操作抽象为有限的action（例如：调用外部工具、读取结果、反思规划、尝试回答等），模型只需根据上下文动态选择合适的action。这种抽象之后，系统的可扩展性大大提升
在广度上：只需新增各类MCP（工具接口），如文献搜索、Google查询、Markdown自动生成等，就能不断拓展系统能力。
在深度上：可以通过强制执行多轮反思、设定token使用下限、对回答进行不同维度的评估等策略，确保模型深入思考、避免浮于表面。
这种机制下，我们更推崇的是一种理念：
LessControl,MoreTools/MCPs（不是0控制，而是适度控制+工具赋能）。
回到本系列的主题——模型究竟是如何训练的？
尽管在端到端的训练，怎么复现DeepReSearch（上）：先从DeepSearch做起中，我们讨论了一些论文中提出的训练思路，但中篇和下篇更多地专注于工作流的拆解，讲解了工程实现细节和设计理念，实际上并没有明确回答“如何训练”的核心问题。
因为训练问题本身非常复杂。
最近，姚顺雨老师在文章
TheSecondHalf|AI时代进入了下半场:https ://ysymyth.github.io/The-Second-Half/
中提出了一个重要观点，他认为“AI的下半场，学会定义问题/评估，比方法更重要”。这一观点让我深有共鸣。我们正面临着从“做题家”到“出卷人”的转变，因为现在的主流训练范式，“推理+强化学习（RL）”已经跑通了，只要我们能定义好如何在与环境交互时设计合适的奖励机制（当我们学会这个问题怎么定义怎么评估时，其实我们就多多少少知道奖励该怎么设计），用这种范式训练模型后就能让效果直接拔高。
然而，问题也随之而来：
“DeepResearch”这样的复杂应用为例，奖励到底应该如何设计呢？
这一点并不简单。举个例子，现在有两个报告：
报告1写作非常流畅、逻辑严谨，但引用不够丰富。
报告2写作较差，但引用信息丰富且权威。
我们应该给予哪份报告更多的奖励？对于DeepResearch这样的任务，我们需要更细粒度的评估标准，比如引用是否合理多样、报告中的公式计算是否准确、是否能够挖掘长尾信息等等等等。。并不是简单地给报告打一个0到10分的奖励就能解决问题。
这意味着，openai的训练数据既包括像简单的多跳问答这种有固定答案的任务，也包括更加开放式的写作任务。里面的”rubrics”（评分规则）我认为是最有价值的东西，是我最想拿到的东西。
因此，目前的建议是：最好结合有标准答案的任务（做rule-basedreward）与开放式任务（要专门训一个rewardmodel来奖励），将这两种类型的奖励混合使用。除此之外，其他的训练策略或许还需要社区更多的研究工作。
本系列分别探讨了DeepResearch系统的不同层次。在上篇中，我们讨论了端到端训练多跳搜索的方法；中篇通过拆解Jina项目，深入探讨了实现Deep的理念；下篇则对Genspark、Grok和Gemini等产品进行了对比。
目前市面上的DeepResearch已经具备一定能力，但说实话感觉离直接把报告当成一个专业分析师的报告还有一段距离，工程的优化是有上限的，未来需要更明确的训练方式来提升效果。
进技术交流群请添加AINLP小助手微信（id:ainlp2)
请备注具体方向+所用到的相关技术点
关于AINLP
AINLP是一个有趣有AI的自然语言处理社区，专注于AI、NLP、机器学习、深度学习、推荐算法等相关技术的分享，主题包括LLM、预训练模型、自动生成、文本摘要、智能问答、聊天机器人、机器翻译、知识图谱、推荐系统、计算广告、招聘信息、求职经验分享等，欢迎关注！加技术交流群请添加AINLP小助手微信(id：ainlp2)，备注工作/研究方向+加群目的。
