Deep Research系统核心架构解析：对比传统RAG、多跳检索防漂移与面试指南

最近不断有朋友向我提出一个更深入的问题：如果用户不是问一个简单事实，而是提出一个复杂的综合性任务，例如“帮我写一份新能源汽车行业的竞争分析报告”，传统 RAG 系统还能胜任吗？

答案是：不能。

传统 RAG 本质上是单跳检索 —— 用户给一个问题，系统执行一次搜索，拼接一段上下文，然后大语言模型给出一次回答。整个过程是线性且一次性的，缺乏规划、反思与修正的能力。

而一份行业分析报告，需要的是多轮搜索、多维度信息整合、自我验证与矛盾消解。这超出了“检索-生成”的范畴，它需要一个能够自主规划、自主执行、自主纠偏的智能体（Agent）。

这就是当前备受关注的 Deep Research 系统。

在一次面试中，当被问及“Deep Research 与传统 RAG 的核心区别是什么”以及“如何在搜索了 20 个网页后防止规划路径跑偏”时，如果回答只停留在“搜的次数更多”，恐怕很难令面试官满意。真正的核心竞争力在于理解系统如何通过分层架构实现自主闭环。

今天，我们就来深度拆解 Deep Research，从架构设计到工程实现，再到面试应答。

一、传统 RAG vs Deep Research：本质区别在哪？

许多人认为 Deep Research 仅仅是“多搜几次、多写点字”，这种理解过于表面。两者的本质区别不在于搜索次数，而在于系统的自主性层级：

• 传统 RAG 是“被动应答”。用户提供一个查询（query），系统执行一次检索-生成流程，返回一个答案。整个过程是线性的、一次性的，没有规划、没有反思、没有修正。
• Deep Research 是“自主研究”。用户提出一个复杂任务（例如“分析 XX 行业竞争格局”），系统需要自主规划研究路径、决定搜索内容、判断信息是否充足、发现并修正矛盾，最终整合成结构化的报告。

一句话概括核心区别：传统 RAG 是一个“搜索工具”，而 Deep Research 是一个“研究助理”。

具体可以从以下五个维度进行对比：

• 任务复杂度。传统 RAG 处理单一问题（例如“等待期是多久”），Deep Research 处理复合任务，需要拆解为多个子问题逐一解决。
• 检索模式。传统 RAG 是单跳检索。Deep Research 是多跳迭代检索，第一轮搜索结果会触发新的搜索方向，形成一棵搜索树。
• 规划能力。传统 RAG 没有规划。Deep Research 拥有自主规划器，能将大任务分解成子任务树，并动态调整。
• 自我修正。传统 RAG 对搜索结果没有验证环节。Deep Research 在每一步搜索后都会进行反思，评估信息是否足够、有无矛盾、是否需要调整方向。
• 输出形式。传统 RAG 通常输出一段话。Deep Research 输出结构化的长报告，需要对数万字的素材进行信息压缩和逻辑组织。这涉及到复杂的系统设计考量。

二、Deep Research 的四大核心组件

一个成熟的 Deep Research 系统由四个关键组件构成，每一个都有其具体的工程实现。

组件一：自主规划器

这是系统的“总导演”。它收到任务后，不会立刻开始搜索，而是先生成一个多层次的任务树。

例如，对于用户输入“分析中国新能源汽车 2025 年的竞争格局”，规划器可能拆解为：

• 子任务 1：当前市场份额分布（比亚迪/特斯拉/蔚来/理想/小米等品牌各占多少）
• 子任务 2：各厂商核心技术路线对比（纯电/混动/增程式）
• 子任务 3：关键政策环境变化分析（补贴退坡/碳积分政策/出口限制）
• 子任务 4：上游供应链瓶颈分析（电池/芯片/稀土材料）
• 子任务 5：综合竞争分析与未来趋势预测

规划器的提示词（Prompt）核心逻辑如下：

PLANNER_PROMPT = """
你是一个研究规划专家。用户给了一个复杂的研究任务，
你需要将其拆解为3-7个子任务，每个子任务应该是一个明确的、可搜索的问题。

研究任务：{task}

要求：
1. 子任务之间要有逻辑递进关系（先事实后分析）
2. 每个子任务要足够具体，可以直接用于搜索
3. 最后一个子任务应该是综合分析/结论
4. 标注每个子任务的优先级（P0必须/P1重要/P2补充）

输出格式：
[子任务1] (P0) 具体问题描述
[子任务2] (P0) 具体问题描述
..."""

关键设计：动态规划而非静态规划。 初始计划不是一成不变的。例如，当子任务1搜索完成后，系统可能发现需要增加一个关于“小米SU7市场冲击”的子任务（因为搜索结果频繁提及但初始计划未覆盖）。规划器会根据每一步的搜索结果实时更新任务树。

组件二：检索与工具引擎

Deep Research 的检索不再只是“去向量数据库搜一下”。它需要调用多种工具，形成一个强大的工具箱，这是其实现深度研究的基础，也体现了现代 AI 应用的复杂性。

• 实时搜索引擎。通过 Google/Bing 等 API 获取最新的网页信息。与传统 RAG 主要依赖本地静态知识库不同，Deep Research 通常需要联网获取实时数据。
• 深度网页解析器。搜索引擎返回的是 URL 和摘要，但关键信息往往隐藏在网页正文、PDF 附件或图表中。需要对搜索结果进行深度解析——这可以复用成熟的文档解析技术。
• 代码解释器（沙箱）。搜索到的原始数据（如各厂商季度销量）可能需要进行计算（如同比增长率）或可视化（如市场份额饼图）。Deep Research 系统通常集成 Python 沙箱，让 LLM 编写代码处理数据。
• 本地知识库。如果企业拥有内部数据（如自家产品历史销售数据），也需要从本地 RAG 知识库中检索。这个模块与传统 RAG 完全一致——通常采用向量检索与 BM25 混合搜索，再经过 Rerank 模型精排。

组件三：反思与自我修正

这是 Deep Research 的“灵魂”，也是面试中最受关注的部分。

在每一个子任务搜索完成后，系统都会执行一轮“反思”：

REFLECTION_PROMPT = """
你是一个研究质量审查员。
一个研究助理刚刚完成了以下子任务的搜索：

子任务：{subtask}
搜索到的信息：
{search_results}

请从以下三个维度评估搜索质量：

1. 充分性：搜到的信息是否足够回答这个子任务？
   如果不够，缺少什么？需要补搜什么关键词？

2. 一致性：搜到的不同来源之间有没有矛盾？
   如果有，矛盾点是什么？哪个来源更可信？

3. 相关性：搜到的信息中有多少是跟子任务无关的噪音？
   需要过滤哪些内容？

输出格式：
- 充分性评分(1-5): X
- 一致性评分(1-5): X  
- 相关性评分(1-5): X
- 是否需要补搜: 是/否
- 补搜建议: [具体的新搜索词]
- 需要过滤的内容: [编号列表]"""

反思的三种结果与后续动作：

• 通过（三个维度评分均≥4分）。继续执行下一个子任务。
• 需要补搜（充分性评分<4分）。根据反思模块给出的补搜建议，生成新的搜索词，再进行一轮搜索。通常会设置补搜次数上限（如最多2次），以避免无限循环。
• 需要换方向（相关性评分<3分）。说明当前的搜索方向可能走偏了。系统会回退到规划器，让规划器重新调整该子任务的描述或整体搜索策略。

一个关键问题：如何防止规划路径跑偏？

这是面试中的高频追问。核心答案是实施双重锚定策略：

1. 目标锚定。在每一步反思中，都将用户的原始任务描述作为“锚点”传入 Prompt，让反思模块判断当前搜索方向是否偏离了最初目标。
2. 预算锚定。设置总搜索次数上限（例如最多30次）和单个子任务搜索上限（例如最多8次）。超过预算即强制进入下一子任务或直接进入信息整合阶段，防止系统在某个分支上过度发散。

组件四：长上下文整合

当所有子任务搜索完成后，系统可能已经积累了数万字的原始素材。直接将全部素材塞给 LLM 生成报告是不可行的——即使上下文窗口足够大，LLM 对超长输入的利用效率也会急剧下降（即“Lost in the Middle”问题）。

推荐的解决方案：分层摘要 + 大纲驱动生成。

• 第一步：子任务级摘要。对每个子任务的搜索结果分别生成一段 500-800 字的精炼摘要，保留关键数据、核心观点和来源引用。这一步将数万字压缩至几千字。
• 第二步：生成报告大纲。基于所有子任务的摘要，生成一份结构化的报告大纲（包含一级标题、二级标题及各节核心要点）。
• 第三步：分节生成报告正文。按照大纲，逐节生成报告正文。生成每一节时，仅输入该节对应的子任务摘要、相邻章节的摘要（保证上下文衔接）以及完整大纲（保证全局一致性）。
• 第四步：全文审校。对生成的完整报告进行一次最终审校，检查逻辑连贯性、数据一致性、引用完整性等。

三、与传统 RAG 的关系：不是替代，是升级

实际上，Deep Research 的许多子模块正是对传统 RAG 模块的复用与升级：

• 检索模块可直接复用。Deep Research 中的本地知识库检索与传统 RAG 完全相同。
• 文档解析模块可直接复用。Deep Research 对搜索到的 PDF 和网页进行解析，其技术栈与传统 RAG 中的文档解析方案一致。
• 评估体系可直接复用。Deep Research 反思模块中评估搜索结果质量所用的指标（相关性、覆盖率、一致性），与传统 RAG 的检索评估指标是同一套。

新增的核心部分是“规划”和“反思”这两个循环。 这是智能体（Agent）特有的能力——传统 RAG 没有任务规划（用户给什么就搜什么），也没有对搜索结果的反思（搜到什么就用什么）。Deep Research 在传统 RAG 的坚实基座上增加了这两个循环，使系统从“被动应答”进化为了“自主研究”。

因此，如果面试官问“你做过 RAG，如何将其扩展到 Deep Research？”，一个有力的回答是：“检索、解析、评估等基座模块可以直接复用。核心增量在于增加了规划器和反思循环，使系统具备了自主拆解复杂任务和动态自我纠偏的能力。” 想了解更多关于智能体架构的深入探讨，可以访问人工智能板块的讨论。

四、工业级实践中的三个关键设计

设计一：广度搜索 + 深度下钻的双循环策略

系统并非一次性搜完所有子任务。一个更高效的策略是分为两轮：

• 第一轮：广度搜索。对每个子任务各进行 2-3 次快速搜索，目的是快速获取各个方向的基本信息，摸清“地形”——了解哪些方向信息丰富，哪些方向存在信息缺口。
• 第二轮：深度下钻。根据第一轮的结果，对信息不足的关键方向进行深度搜索——更换搜索词、寻找不同数据源，甚至调用代码解释器处理原始数据。这一轮的目的是“填补空白”。

如何判断信息已饱和？ 当一个子任务连续两次补搜返回的新信息增量小于 10%（即与已有信息的重复度高于 90%）时，则认为该子任务信息已饱和，停止搜索。

设计二：多专家角色博弈

引入三种不同的角色，通过“博弈”提升最终报告的质量：

• 研究员 (Researcher)：负责执行搜索、整理原始素材。
• 审稿人 (Critic)：负责“挑刺”，指出报告初稿中的逻辑漏洞、数据矛盾、覆盖盲区。
• 撰稿人 (Writer)：负责最终成稿，需要综合研究员提供的素材和审稿人提出的修改意见。

实际流程可以是：研究员完成搜索 → 撰稿人生成初稿 → 审稿人审阅并提出修改意见 → 撰稿人修订 → 审稿人二次审阅。通常循环最多两轮，避免过度迭代导致效率低下。这种角色协同的设计模式，体现了复杂后端 & 架构中的协作思想。

设计三：构建评估闭环——如何衡量报告质量？

Deep Research 的输出是长篇报告，无法像传统 RAG 那样用简单的召回率（Recall@k）来评估。需要建立一套新的评估指标：

• 事实准确性。报告中的每一个数据点、论断是否都能在搜索结果中找到可追溯的来源。这本质上是“引用溯源”能力的延伸。
• 覆盖完整性。报告是否覆盖了任务要求的所有分析维度。可以用规划器最初生成的子任务列表作为检查清单（Checklist），逐一核对。
• 逻辑一致性。报告内部是否存在自相矛盾之处。可以利用 LLM 对报告全文进行一遍自动化矛盾检测。

五、面试中如何回答关于 Deep Research 的问题？

如果面试官提问“Deep Research 的核心挑战或难点是什么？”，可以按照以下框架组织答案（控制好时长）：

• 第一个难点：规划路径漂移（约30秒）。“智能体在迭代搜索过程中容易‘走偏’——例如，第一个子任务搜到了一个有趣但不核心的方向，系统可能会沿着这个方向一路深挖，逐渐偏离原始目标。我们的解法是‘双重锚定’：在每一步反思中都带入原始任务描述作为目标锚点，同时设置严格的搜索次数预算，防止智能体无限发散。”
• 第二个难点：长序列记忆遗忘（约20秒）。“在进行了多达20次网页搜索后，早期搜索结果中的关键信息容易被后续信息覆盖而‘遗忘’。我们的解法是实施‘分层摘要’——每个子任务搜索完成后立即生成摘要，后续的规划、反思与整合步骤都基于这些摘要进行，确保关键信息不丢失。”
• 第三个难点：海量素材的整合质量（约20秒）。“将数万字的零散素材整合成一份逻辑严密、结构清晰的长报告是一大挑战。若一次性全部输入给LLM，会加剧‘Lost in the Middle’问题。我们的解法是‘大纲驱动、分节生成’：先生成全局大纲，再依据大纲一节一节地撰写，每次只聚焦相关部分的摘要，最后进行全文一致性审校。”

如果面试官追问“Deep Research 与传统 RAG 的关系”（约10秒）。“本质上，Deep Research 是传统 RAG 的智能化升级。检索、解析、评估等基础模块可以直接复用。核心增量在于引入了规划器和反思循环，使系统具备了自主拆解任务和自我纠偏的 Agent 能力。”

写在最后

Deep Research 代表了 AI 在信息处理领域的演进方向：从“提供链接列表”到“提供结构化知识”，再到“提供深度洞察”。

然而，仔细剖析其架构后你会发现，它并非凭空创造的全新技术。其底层依赖的检索、文档解析、评估与溯源等核心模块，在成熟的 RAG 体系中均已具备。Deep Research 的本质，是在传统 RAG 的强大基座上，增加了“规划”与“反思”这两个高层控制循环，从而将系统从一个高效的“搜索工具”升级为一个主动的“研究助理”。

如果你已经深入理解了 RAG 的各个技术模块，那么掌握 Deep Research 将是水到渠成。它不是一个全新的、孤立的技术领域，而是 RAG 技术向更复杂、更自主应用场景的自然延伸与进化。更多关于数据、算力与模型训练的深度内容，欢迎在智能 & 数据 & 云板块与我们交流。