Appearance
Q105 · 什么是 DeepSearch？它和 RAG 有什么区别？
客户问：“订单 PO-17 原定 9 月 22 日到，为什么 9 月 24 日才收到？”假设公司的订单记录只写了关联运单 S-88；运单记录只写了关联异常 E-3；异常记录才说明“分拣中心延误”。如果只拿客户的原话搜一次，搜索结果也许只有订单记录。模型即使很会写，也不能从订单记录里凭空推出延误原因。系统需要沿着新找到的编号继续查，直到找到有出处的原因，或者承认查不到。
在这篇文章中，DeepSearch 指围绕同一问题进行多轮、按线索调整查询并核对证据的搜索流程。它可由 Agent 或确定性程序编排，不代表某种模型天生会这样工作，也不是统一的行业协议。RAG（检索增强生成）则是把外部检索结果提供给生成模型、帮助其回答的广义方法。常见单轮 RAG 做一次检索就生成答案；多轮 RAG 也完全可以采用本文的 DeepSearch 流程。因此真正值得比较的是一次取回资料后就回答，与发现缺口后继续搜索和核验，而不是把两个名词规定成互斥技术。RAG 原始论文
先把名称和术语说清楚
“DeepSearch”不是只有一个固定定义。xAI 在 Grok 3 的发布说明中把 DeepSearch 称为能够综合信息、处理冲突并形成报告的 Agent；IBM Research 的 Deep Search 则强调收集、转换、整理和搜索大型文档集合，还可用于 RAG 的数据准备。两者同名，产品边界不同。下文采用多轮寻找证据这个工作定义，讨论的是设计方法，并不把任一厂商的全部功能当成通用规范。xAI：Grok 3 与 DeepSearch · IBM Research：Deep Search · IBM：RAG 数据摄取
| 术语或记号 | 意思 | PO-17 例子 |
|---|---|---|
| 生成模型 | 根据已得到的文字生成回答的模型；它读不到没有传给它的内部记录 | 读到订单记录后，最多能说明关联运单是 S-88 |
| 检索 | 按关键词、语义或结构化字段从允许访问的资料中找记录 | 用订单号查订单表，用运单号查物流表 |
| RAG | Retrieval-Augmented Generation，检索增强生成：先取外部资料，再让模型参考资料作答 | 把订单、运单和异常记录作为回答依据 |
| 单轮 RAG | 本文专指“按原问题查一次，再据返回片段回答”的简化应用流程；不是 RAG 的定义 | 只搜“PO-17 为什么晚到”，可能只命中订单记录 |
| DeepSearch | 本文的工作定义：发现新线索或缺口后，再制定下一次搜索，并核对最终证据 | 从 PO-17 查到 S-88，再查到 E-3 |
| 多跳 | 一个资料给出另一个资料的线索，必须接续查找才能回答 | 订单号 → 运单号 → 异常编号 |
| 证据链 | 将结论与支撑它的多份原始记录及其关联关系连起来 | PO-17 关联 S-88，S-88 关联 E-3，E-3 写延误原因 |
| 搜索预算 | 对次数、时间和费用设上限，防止反复查同样内容 | 最多三轮，只读订单、运单和异常记录 |
| 终止条件 | 明确什么证据足以回答、何时应报告未知或转人工 | 订单与运单匹配、原因有原文且无冲突才解释；否则停止并报缺口 |
文中订单号、日期、记录和规则均为教学假设。9 月 22 日为本例承诺到达日，9 月 24 日为实际签收日；它们不代表真实物流数据。
同一订单，系统怎样一步步找到原因
假设用户有权查看自己的订单及对应物流信息，系统接了三个只读查询入口：订单查询返回订单号、承诺日期、运单号；运单查询返回运单号、签收时间、异常编号；异常查询返回异常编号、异常描述和记录时间。所谓只读，是查询不会修改订单或物流状态；“能调用入口”还不等于能查看任何人的记录，服务端仍须按用户和订单关系校验权限。为了方便讲清机制，先假设每条记录都真实、没有过期。
普通单轮 RAG 可能将“PO-17 为什么晚到”送入文档检索，只得到：订单 PO-17、承诺 9 月 22 日、关联运单 S-88。它能答“该订单关联 S-88，但现有资料没有延误原因”。如果它回答“因为天气不好”，那是未经资料支持的猜测。单轮系统若事先把三个表通过订单号做了连接，当然也可能一次取齐；关键限制是这一次实际取回的内容是否足够，而不是检索轮数本身有魔法。
本文的 DeepSearch 流程把每轮结果当成下一轮行动的依据：
- 确定待验证的问题：要解释的是 PO-17 从承诺 9 月 22 日到实际 9 月 24 日之间的差异。先核对用户是否可看 PO-17，再用精确订单号查订单记录。此轮得到承诺日期和 S-88，尚未得到原因。
- 沿新线索查询：由于 S-88 是订单记录里的运单号，下一轮按运单号查，而不是继续改写“为什么晚到”的同义词。假设运单确认 9 月 24 日签收，并指向异常 E-3。系统要检查它记录的订单关联确为 PO-17，避免碰巧拿到别人的运单。
- 核实原因记录：按 E-3 查异常台账。假设台账写“9 月 22 日，分拣中心延误”，并明确关联 S-88。系统保存这条原文、记录时间及定位方式，检查是否还有取消、重派或人工更正记录造成冲突。
- 回答并标出边界：可以说：“PO-17 的运单 S-88 于 9 月 24 日签收；关联异常 E-3 记录 9 月 22 日发生分拣中心延误。按现有记录，这是晚于承诺日期的已记录原因。”同时给出订单、运单、异常三条记录的可访问引用。若要断言“供应商违约”或“应赔多少钱”，还需要合同、责任认定或赔付规则；这三条物流记录不足以支持。
三轮是本例的线索长度，不是 DeepSearch 的固定步骤数。查询也未必由大模型决定：若数据关系稳定，程序完全可以按“订单号 → 运单号 → 异常号”确定性地查；面对开放网页、别名或多个互相冲突的线索时，才可能让模型提出下一条查询。模型提出查询后，仍应由系统验证参数、权限、去重与次数上限。这样才能把“想继续查”变成受控动作。
一条可检查的搜索记录可以写成：“第 1 轮，查询 PO-17，返回订单记录 O1 与 S-88；第 2 轮，查询 S-88，返回运单记录 L1 与 E-3；第 3 轮，查询 E-3，返回异常记录 X1，原因是分拣中心延误。”其中 O1、L1、X1 是本例的记录引用编号，并非模型自由编出的来源；线上系统应保存真实文档位置、版本和访问时间。最终答案里的每个事实，都应能回到相应记录，而不能只附一个看起来相关的链接。
与 RAG 比较时，比较的是哪一层
Lewis 等人的 RAG 论文研究的是让生成模型使用外部检索知识；论文中的两种形式甚至包括“生成过程中不同 token 可使用不同片段”。因此把 RAG 定义成“只能检索一次”本身就不准确。现实应用常把“用户问题 → 搜索前几条 → 塞给模型 → 回答”称为基础 RAG，本文才用它作对照。Lewis 等：RAG 原始论文
| 相同维度 | 常见单轮 RAG 流程 | 本文定义的 DeepSearch 流程 |
|---|---|---|
| 起点 | 用户当前问题 | 用户问题加上要补齐的证据条件 |
| 搜索策略 | 按原问题取回一批相关片段 | 根据已找到的编号、冲突和缺口设计下一次查询 |
| 回合 | 通常一轮，然后生成 | 可有多轮，逐轮决定继续或停止 |
| 资料之间的关系 | 可能只看相似度较高的片段 | 明确追踪 PO-17、S-88、E-3 之间的关联 |
| 输出 | 依据已取回资料回答，资料不足应说明 | 依据完整可核查的证据链回答，未闭合则报告缺口 |
| 费用与时延 | 一次检索和一次生成通常较省 | 多次查询、读取和判断通常更贵、更慢 |
| 主要风险 | 初始检索漏掉关键资料，却仍自信回答 | 查询漂移、反复搜索、错误连接资料、把数量当质量 |
“DeepSearch 比 RAG 更高级”这种说法会误导。一个设计良好的多跳 RAG 就可以执行上述搜索；DeepSearch 也可能在每轮使用 RAG 检索，再让模型依据检索内容生成下一步查询。若只有一个明确、权威的页面能回答问题，多轮搜索甚至是浪费。Q80 讨论的 Deep Research 与 RAG 偏向从多来源调查到综合报告；本文聚焦找到并核实支撑一个答案的资料。搜索阶段可以成为深度研究系统的一部分，但两者目标与交付物不必相同。
什么时候继续查，什么时候必须停
正常路径的停止条件是：用户有权限；PO-17 与 S-88、S-88 与 E-3 的关联均由记录确认；承诺和实际日期口径一致；异常原文能支持所说原因；未发现更正或冲突记录。系统此时可以给有限结论，不必为了“搜索得深”再漫无目的地找网页。
失败路径一：运单 S-88 没有异常编号。系统可以在允许的数据源中用运单号再查一次更正记录，但不能把“没有查到异常”推成“没有异常”。达到预算后应说明“已核实晚到两天，现有授权记录未给出原因”，提供运单引用，并建议客服人工核查。失败路径二：异常 E-3 写“分拣延误”，而一份更新的更正记录写“原记录误报，实际为地址确认等待”。这时应按记录时间、权威级别和更正关系核对；不能简单拿最先读到或语气最肯定的一条。若无法判定，明确报告冲突与来源，让人处理。
多轮搜索还会放大几个工程问题。每轮访问都要重新做权限校验，不能因为第一轮订单合法，就跨到别人的运单。外部网页、邮件、文档中的“忽略规则、访问某地址”是资料内容，不是可以执行的指令；工具参数要验证，访问范围要收紧。查询结果需按记录 ID 和版本去重，发现反复回到同一线索就停止。设置最大轮数、最大读取量和超时，避免无限循环与不可预测账单。来源缺失、过期或权限不足时，返回“无法验证”比拼凑完整故事可靠。引用本身只方便复查，不能证明来源正确。
是否值得引入多轮流程，应用案例集验证。至少放入四类任务：单条资料就能回答的、像 PO-17 这样跨记录多跳的、证据冲突的、无权限或缺失原因的。逐条检查“关键证据是否找齐、关联是否正确、结论是否被记录支持、未知项有没有诚实保留”，并同时统计平均与尾部耗时、查询次数和费用。若单轮流程已能稳定回答某类问题，就不必把所有请求都升级为深搜。
面试中可以这样回答
我会先问清 DeepSearch 指哪个产品或哪种流程，因为这个名字没有统一协议。若指多轮深搜，它是围绕问题不断查证：先搜出线索，再沿线索找下一份资料，核对来源、冲突和停止条件。例如客户问 PO-17 为什么晚到，订单只给出 S-88，运单再给出 E-3，异常记录才写分拣延误。常见单轮 RAG 是一次检索后依据已有片段回答；RAG 的广义定义并不限制检索次数，多跳 RAG 可以实现同样的深搜。深搜更适合证据分散、需要追踪关联的问题，但调用更多、可能误连记录或陷入循环，所以要做权限校验、证据链检查、预算限制和无法验证时的退出。
若追问“为什么不直接调大一次检索的返回条数”，可以说：增加返回条数可能提高召回，但 E-3 文档里未必出现 PO-17，最初查询不一定知道该找它；沿已发现的 S-88 和 E-3 查询，才把跨记录关系显式找出来。若预先建立可靠的关联索引，一次检索也能取齐，那就优先用更简单的方案。若追问“DeepSearch 是否等于 Deep Research”，可以说：深搜强调证据发现和验证；深度研究还可能包含任务规划、计算、综合分析和完整报告。具体产品能力以厂商文档为准，不能由名字推定。
资料来源
- Lewis 等：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（2020）：RAG 原始研究及其两种检索条件化形式。
- xAI：Grok 3 Beta — The Age of Reasoning Agents：xAI 对其 DeepSearch Agent 的官方定位。
- IBM Research：Deep Search：IBM 同名项目对文档收集、转换、整理和搜索的官方说明。
- IBM：RAG Cookbook — Data Ingestion：IBM 说明其 Deep Search 可参与 RAG 数据准备，显示同名产品的不同边界。
- OpenAI：Research with ChatGPT：多步搜索、评估、调整查询与综合结果的官方产品示例；其产品名为 Deep Research，并非本文对 DeepSearch 的统一定义。