- • Deep Search：搜索的本质与难点
在深入研究 Deep Research 前，我们必须理解：Deep Search 是 Deep Research 的基石 。 搜索的本质在于找到全面和直接的信息。根据需求和场景，我们可以采用不同的实现方式：
结构化数据查询 ：编写 SQL 语句查询公司内部数据库
API 调用 ：使用关键词调用外部搜索 API（如 Google、Bing）
虚拟浏览器 ：通过 Operator 等工具模拟人类浏览网页
搜索任务的复杂度也呈不同等级递增，如单跳搜索 "哪吒 2 的导演是谁"、多跳搜索 "哪吒 2 的导演还导演过什么电影？"、偏向 deep research 的搜索 "研究《哪吒 2》在国际市场的接受度与文化输出效果，分析其对提升中国文化软实力的贡献"。
多跳搜索和深度研究型搜索的关键在于模仿人的思维链搜索 ：
-
- 模型首先根据问题进行初步推理，确定基础搜索方向
-
- 执行初始搜索，获取第一批信息
-
- 基于已获取的信息，进行下一轮推理，确定进一步的搜索方向
-
- 执行细化搜索，获取更精准的信息
-
- 不断迭代这个 "推理→搜索→推理" 的循环，直到收集足够信息 在这个过程中，每次搜索都建立在前一次搜索结果的基础上，形成一个连贯的推理链。
这就是为什么 Deep Search 是 Deep Research 的基石 ——只有掌握了这种迭代式、思维链式的搜索能力，才能支撑起完整的深度研究。
论文 1: Search-o1
在这里插入图片描述
Search-o1 是最近比较火的 WebThinker 项目的前身，它提出了一种新颖的方法，让大型语言模型在推理过程中能够主动进行网络搜索，从而增强其推理能力。与传统检索增强生成（RAG）系统相比，Search-o1 有两个关键创新点：
在这里插入图片描述
- • 核心组件一: 主动式检索增强生成机制
在这里插入图片描述
传统 RAG 通常是一次性的：在回答问题前进行一次检索，将检索结果放入上下文中。而 Search-o1 实现了动态的、多步骤的 检索机制：
- • 模型在推理过程中可以 识别自身知识的不足点
- • 当遇到知识不确定的情况时，模型会自动生成搜索查询，格式为
<|begin_search_query|>搜索词<|end_search_query|> - • 系统检测到这一标记后，暂停模型推理，执行网络搜索
- • 搜索结果被包装在
<|begin_search_result|>检索到的内容<|end_search_result|>标记中返回给模型 - • 模型继续推理，并可以根据需要多次重复这一过程。 Prompt 如下
- • Search-o1 的核心组件二:
Reason-in-Documents 模检索有一个很严重的问题，就是检索出来的内容可能很杂乱和很长，而现在的大模型处理长文本性能会下降，因此，论文剔除，用另外一个 Reason-in-Documents，把检索到的内容进行精炼，再放入到原有推理链中，从而缓解检索文档中存在冗余信息和 LLM 处理长文档的局限性。Prompt 如下
在这里插入图片描述
- • Search-o1 与传统 RAG 的区别
- • 检索触发机制 ：传统 RAG 是静态的、预先定义的；Search-o1 是动态的、由模型主动触发的
- • 检索频率 ：传统 RAG 通常进行一次性检索；Search-o1 支持多次、迭代式检索
- • 内容整合 ：传统 RAG 直接插入大量文档；Search-o1 经过精炼后仅保留关键信息
- • 推理连贯性 ：Search-o1 保持了推理流的连贯性，避免了传统 RAG 可能导致的推理中断
- • 示例说明 以下图论文中的示例为例，详细说明整个工作流程：
-
- 模型开始推理，遇到需要特定知识的环节
-
- 模型生成：
<|begin_search_query|> reaction of grignard reagent with aldehyde <|end_search_query|>
- 模型生成：
-
- 系统暂停模型推理，调用搜索引擎获取结果
-
- Reason-in-Documents 模块分析搜索结果，提取关键信息
-
- 精炼后的内容被包装在
<|begin_search_result|>提炼后的检索内容<|end_search_result|>中
- 精炼后的内容被包装在
-
- 模型继续推理，可能进行多轮搜索 - 精炼循环
-
- 最终生成完整且准确的答案 !
论文 2: 《DeepRetrieval: Hacking Real Search Engines and Retrievers with Large Language Models via Reinforcement Learning》
在这里插入图片描述
在这里插入图片描述
用强化学习来训练 query 改写
query 改写已被证实是检索流程中的关键步骤。当用户提交问题时，大型语言模型 (LLM) 通常会对其进行重新表述(称为增强查询)，然后再执行检索。DeepRetrieval 采用创新方法，利用强化学习 (RL) 而非传统的监督式微调 (SFT) 来优化这一关键步骤。
DeepRetrieval 的突出之处在于它能够通过 "试错" 方式直接学习，使用检索指标作为奖励，无需昂贵的监督数据。这种方法使模型能够针对实际性能指标进行优化，而不仅仅是模仿人工编写的查询。
在多种检索任务中进行了实验
论文中值得称赞的是，在五种不同的检索任务中展示的有效性，每种任务都需要不同的查询格式和奖励结构：
-
- Literature Searching (文献检索)
- • 定义 ：给定一个查询，从搜索引擎中检索相关文档。
- • 评估指标 ：Recall@K（在前 K 个结果中检索到的目标文档的百分比）
- • query 形态：采用医学专用的 PICO 检索语法
- • 例如："((达姆明) AND (围手术期 OR 血液转输 OR 去氨加压素 OR 抗凝剂)) AND (随机对照试验)"
- • 这种查询包含布尔运算符和专业术语，结构严谨
-
- Evidence-Seeking Retrieval (证据寻找检索)
- • 定义 ：给定一个问题，检索包含匹配答案候选项的文档。
- • 评估指标 ：H@N（第一个出现答案的文档排名是否在前 N 位）
- • query 形态 ：类似自然语言，如 "What is another term for the pivot mounting?"
-
- Classic Sparse Document Retrieval (经典稀疏文档检索)
- • 定义: 使用关键词匹配和布尔操作进行文档检索（如 BM25 算法）。
- • 评估指标 ：NDCG（归一化折扣累积增益，衡量排序质量）
- • query 形态 ：关键词和布尔表达式组合 - 例如："(李明 IS-A 人物 AND 李明 IS-A 在职) OR (李明 IS-A 人物 AND 李明 IS-A 失业)"
-
- Classic Dense Document Retrieval (经典密集文档检索)
- • 定义 ：使用查询和文档的语义向量表示进行检索。
- • 评估指标 ：同样使用 NDCG
- • query 形态 ：自然语言表述
- • 例如："量子计算的基本原理是什么？"
- • 系统会将这类查询转换为向量形式，通过语义相似度进行文章检索
-
- SQL Database Search (SQL 数据库检索)
- • 定义 ：根据自然语言查询生成 SQL 来检索数据库中的信息。
- • 评估指标 ：执行准确率（检索结果与目标答案的匹配程度）
- • quuey 形态 ：SQL 语句
- • 例如："SELECT 书名 FROM 图书表 WHERE 类型 !='诗歌'"
论文通过研究五种不同类型的检索任务，展示了强化学习在查询改写领域的通用有效性。这些任务包括专业文献检索、基于 BM25 的关键词匹配以及 SQL 生成等多种形式。作者的核心论点是：无论用户的初始 query 和最终改写的 query 的形式如何变化（自然语言到自然语言、专用语法到专用语法、或自然语言到 SQL），经过精心设计的强化学习训练都能显著提升查询改写的质量，从而大幅提高最终的检索效果。这一发现证明了强化学习方法在查询优化领域具有跨形式、跨领域的适用性和有效性。
奖励函数设计
既然是强化学习，那肯定是要涉及奖励的，论文针对 5 中不同的检索任务，也涉及了不同的 prompt 和奖励。
其中：
捕获任务特定的检索性能，
奖励符合所需输出结构的结果，
q 为用户原始的 query，
为模型新改写的 query。
这里以 Literature Search 和 Database Search 来举例，
- • Literature Search
- • Prompt 如下:
在这里插入图片描述
- • Format_reward 格式奖励：用户是否遵循 prompt 中要求的格式，如是否出现 "think> 70% 召回率得 + 5.0 分，0% 召回率得 - 3.5 分
- • SQL Database Search
- • Prompt 如下:
在这里插入图片描述
- • Format_reward 格式奖励：用户是否遵循 prompt 中要求的格式，如是否出现 "think> </think answer /answer 等 token，生成的 answer 中的 SQL 是否是合乎 SQL 语言的 SQL - Retrieval reward: 与标签答案的 SQL 执行的结果是否一致。 以下是所有 5 种检索任务的奖励设置。
在这里插入图片描述
论文 3: 《Search-R1: Training LLMs to Reason and Leverage Search Engines with Reinforcement Learning》
在这里插入图片描述
在这里插入图片描述
结合交错式多轮搜索引擎调用的文本生成
Search-R1 通过创新的五阶段交互流程实现知识检索与推理的深度融合：
-
- 1 初始问题解析阶段
当接收到用户问题时，模型首先在
<think>
思考标签内进行初步推理分析，识别当前知识储备中的信息缺口。
动态检索决策阶段
若推理过程中发现知识不足，模型将自主触发检索机制，通过
<search>查询内容</search>
格式生成精准搜索指令。
信息整合阶段
搜索引擎返回的结果会被结构化封装在
<information>
信息标签内，为后续推理提供可靠的外部知识输入。
迭代优化机制
系统支持多轮次检索 - 推理循环，模型可根据信息完备性动态决定是否发起新一轮检索，直至满足解答需求。 5. 5. 最终响应生成阶段
当判定信息充足时，模型直接通过
<answer>
答案标签输出简洁结论，无需附加解释说明。 以下为 Search-R1 的 prompt
在这里插入图片描述
与 Search-o1 不同的是，Search-R1 针对任务进行了强化学习的训练，Search-R1 没有 Search-o1 的 Reason-in-Documents 模块，检索到的内容是直接完整放到思维链中的。以下是 Search-o1 的例子，本质就是生成检索、返回内容、思考，不断循环，直到达到最终答案。
奖励函数设计
Search-R1 使用基于规则的奖励系统，只关注最终结果的正确性：
其中，EM 是精确匹配函数，
a_{\text{pred}} 是从回答中提取的答案，
a_{\text{gold}} 是标准答案。 这种简单的奖励设计避免了复杂的过程奖励和可能被 "黑客攻击" 的神经奖励模型。这个模型设计没有包含格式奖励，作者解释因为模型已经表现出良好的结构遵循能力。
论文 4: 《R1-Searcher: Incentivizing the Search Capability in LLMs via Reinforcement Learning》
在这里插入图片描述
两阶段的强化学习增强检索能力
R1-Searcher 引入了一个两阶段基于结果的强化学习方法，使 LLM 能够在推理过程中自主调用外部搜索系统：
第一阶段 (检索学习训练) ：通过检索奖励激励模型学习如何正确调用外部搜索，不关注答案准确性。
- • 检索奖励 (Retrieval Reward) :
- • 0.5 分：当模型至少执行一次检索操作
- • 0 分：未进行任何检索
- • 格式奖励 (Format Reward) :
- • 0.5 分：完全符合规定的输出格式标准
- • 0 分：格式不符合要求
- • 格式规范要求 ：
- • 思考过程必须封装在
<think>...</think>标签内 - • 最终答案必须封装在
<answer>...</answer>标签内 - • 检索查询必须使用
<begin_of_query>...</end_of_query>标签标记 - • 严格禁止未调用检索系统直接生成文档内容
- • 阶段总奖励 ：Rretrieval + Rformat (最高 1.0 分)
- • 第二阶段 (检索结果集成训练) ：在确保格式规范的基础上，提升模型有效利用检索信息解决问题的能力
- • 第二阶段删除了检索奖励，引入了答案奖励，同时保留格式奖励但调整了惩罚力度
- • 格式奖励 (Format Reward) :
- • 0 分：格式完全正确
- • -2 分：格式出现任何错误
- • (注：相比第一阶段，显著提高了格式错误的惩罚力度)
- • 答案奖励 (Answer Reward) :
- • 使用 F1 分数作为答案奖励：
Ranswer = 2 * IN / (PN + RN) - • 其中：
- • PN: 预测答案的词数
- • RN: 参考答案的词数
- • IN: 预测答案与参考答案的交集词数
- • 阶段总奖励 ：Format Reward + Answer Reward 这种两阶段设计通过分离关注点，先确保模型掌握正确的检索行为规范，再专注于提升答案质量，实现了检索能力与信息整合能力的阶梯式提升。
在这里插入图片描述
Search-o1、 Search-R1、R1-Searcher 的研究方向基本一致：构建长的搜索推理思维链，在思维链中不断调整搜索策略 。一个重要共识是，强化学习比监督微调 (SFT) 能带来更好的泛化性。 DeepRetrieval 虽然关注查询改写，但范围过窄，难以形成完整思维链。理想的查询改写应是思维链中的自然产物，而非单独训练的任务。 我们距离真正的 Deep Research 还有十分长的距离。完整的 Research 涉及更多挑战，如并行搜索、超长下文管理、研究目录编写、结论调整等。但正如开篇所述，先把 Search 做好，才能做好 Research 。
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 产品，你会发现，都有这样的雏形。
grok
接下来，我们试试 grok，本质也是不断推理、搜索、阅读。
Gemini
https://gemini.google/overview/deep-research/
Try Deep Research and our new experimental model in Gemini, your AI assistant
Gemini 的官网其实提到了很多干货的，比如提到在面对复杂的用户问题时，会首先制定一个详细的研究计划，将问题分解为一系列更小、更容易处理的子任务。接下来，系统会监督执行这些子任务，并灵活决定哪些任务可以并行处理，哪些需要按顺序完成 。待收集到足够的信息后，Gemini 会综合所有结果并生成一份详尽的报告。在生成报告的过程中，系统会批判性地评估收集到的信息，识别关键主题和不一致之处，并通过多轮自我审查提高报告的清晰度和细节 。Gemini 的上下文除去利用 gemini 1million 的上下文的能力外，还结合了 RAG 技术，可能是先将相关的文章存储起来，然后在需要时通过向量检索进行召回。
在这里插入图片描述
在这里插入图片描述
这里，问示例问题，谷歌会先做方案，拆分问题，还要用户确认，然后再开始执行，
在这里插入图片描述
在这个例子中，首先会将 “京东入局外卖的动因”、“市场格局与竞争态势” 和“京东的潜在优势”这三个问题（对应问题 1,2,3）放在一起进行搜索。
在制定下一步计划时，系统貌似继续研究问题 4,5。然而，这个过程中并非所有的步骤都严格按顺序执行。例如这里，在获得第一步的搜索结果后，它的后续研究研究方向就变了，猜测是后续的研究方向可能会根据已获得的信息进行调整，研究过程显得非常灵活和动态。其次，看起来并不是所有开头的 8 个子问题都会被依次搜索。系统可能会根据前几步的结果，判断是否已经收集到了足够的信息，从而跳过某些问题，直接回答后续的问题。
Genspark
Genspark 是一家由前百度高管景鲲和朱凯华于 2024 年创立的人工智能初创公司。该公司致力于通过多智能体框架（MoA）重塑传统搜索引擎体验，提供高效、个性化的信息搜索服务。
Introducing Genspark Deep Research v2
在 Genspark 的工作流程中，系统首先会调用一个名为 initial_plan 的工具，用来对问题进行初步规划。然而，这个规划过程更像是 Jina 中的 reflect 阶段，感觉它将问题扩展成多个子问题，并将这些子问题添加到待研究的 gaps_列表中。这些子问题并不立刻进行处理，而是通过反思不断调整和更新。
产品总结
从整体来看，虽然这些模型在细节上有所差异，但它们都依靠推理来分解任务并执行多个步骤。它们的主要差异体现在一些细节和执行流程上：
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 在近期的一次播客中就提到， 好的系统设计更倾向于多模型协同 ，“All-in-one” 并不一定是最优解
- • 适当抽象和任务拆分，适合 scaling ：通过将任务中常见操作抽象为有限的 action（例如：调用外部工具、读取结果、反思规划、尝试回答等），模型只需根据上下文动态选择合适的 action。这种抽象之后，系统的可扩展性大大提升
- • 在广度上 ：只需新增各类 MCP（工具接口），如文献搜索、Google 查询、Markdown 自动生成等，就能不断拓展系统能力。
- • 在深度上 ：可以通过强制执行多轮反思、设定 token 使用下限、对回答进行不同维度的评估等策略，确保模型深入思考、避免浮于表面。
这种机制下，我们更推崇的是一种理念：
Less Control, More Tools/MCPs （不是 0 控制，而是适度控制 + 工具赋能）。
- • 模型训练
中提出了一个重要观点，他认为 “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 ：先从 Deep Search 做起
Deep ReSearch前沿的产品形态