★ FEATURED ARTICLE 1. RAG不是终点而是AI Search的起点1.1 一次线上问答暴露的真实天花板我做知识库问答系统有一段时间了最直观的感受是跑通一个RAG Demo很容易做好一个AI Search产品很难。RAG上线初期效果看着不错可一旦投入真实业务用户提的问题变复杂问题就藏不住了。举个我实际遇到的例子。某公司的内部运维库里有几百篇文档用户问“老版系统里订单号的生成逻辑是什么后来为什么要改成新规则”这个问题的关键不是“有没有这篇文档”而是需要把不同时期、不同文档里的信息串起来形成一条因果链路。传统RAG的做法是把问题向量化和文档片段做相似度匹配拿出Top-K个片段拼到大模型的prompt里让它生成答案。结果往往是——检索到的片段确实和“订单号”相关但只覆盖了其中一个环节另一个关键信息在另外一篇文档里没有被召回。模型只好根据手里残缺的证据把答案编得“看起来完整”。这不是个别现象的调参失误而是RAG在结构上的一个限制它默认“一次检索、一次生成”。当检索到的证据本身不够时它不会主动说“我再查一轮”而是硬着头皮作答。这也是我后来关注DeepSearch这类方案的根本原因——它想解决的就是RAG“只答不查”的尴尬。1.2 RAG解决的是“幻觉”和“时效”不是“深度”RAG的价值毋庸置疑。它把大模型无法实时获取、无法训练记忆的私有知识通过检索的方式临时补充进来。模型没见过你的内部文档你直接问它审批流程怎么走它只能一本正经地编把相关文档片段检索出来塞进上下文至少它有了依据。但RAG默认提供的是一种“浅层引用”能力——答案有出处出处未必完整答案不编了但可能只覆盖问题的一半。它解决了两件事一是降低幻觉让模型不再凭空发挥二是突破时效让知识可以随时更新不用重新训练模型。至于“多跳推理”“主动找证据”“不确定时继续查”这些都不在它默认能力范围内。我经常打一个比方RAG像是一个“翻书找答案的人”你问它什么它就翻一次书翻到哪页算哪页DeepSearch更像是“做调研的助手”它会先列一个查证清单发现线索不够就继续翻资料最后把多条线索核对好了再回答你。从RAG到DeepSearch本质上是从“被动喂资料”走向“主动查资料”的演进。2. 拆开RAG看一眼检索、重排与生成的真实配合逻辑2.1 文档切分决定检索质量的第一道闸门很多人以为RAG的核心是选一个大模型其实最先影响效果的是文档切分。切分方法不对后面再怎么调检索都是白费。固定长度切分最简单按256或512个字符硬切。但后果是一个完整的概念可能被拦腰截断比如“订单状态分为待支付、已支付、已发货……”被切成上下两半检索“已支付订单怎么处理”时就只能召回半截内容。我在某知识库项目里对比过固定长度切分在长文档场景下答案命中率比结构化切分明显低不少。我推荐的做法是标题感知切分先按文档的层级结构切保留章节标题并把标题作为chunk的上下文前缀。比如“第3章 订单异常处理”下面再分小节每个chunk都会带上这个标题信息。这样嵌入模型在做向量化时能理解这段文字所在的主题语境而不是孤零零的一段话。为什么chunk大小有这么大影响因为嵌入模型对长度敏感。chunk太长向量会被稀释语义信息被杂讯淹没chunk太短又可能丢失必要的上下文。常见的经验值是每个chunk保持在200到500字之间再配上相邻chunk的少量重叠防止边界内容被忽略。这里没有绝对最优必须拿真实业务文档做评测我见过不同语料库适合的chunk大小能差出一倍。2.2 召回与重排搜索结果“准不准”的真正胜负手切分完成后检索环节决定“能不能把相关材料找出来”。这里我踩过最大的坑是只用向量检索。向量检索也叫语义检索它把query和文档片段都映射到同一个向量空间用余弦相似度找最近邻。优点是能处理“词面不同、意思相近”的查询比如用户问“报销卡在哪”文档里写的是“费用审批阻塞节点”两者能匹配上。但缺点是它偶尔会把语义上“擦边”的内容拉高分数比如用户问“订单超时怎么退款”文档里反复出现“退款”二字的其他流程也会被召回。所以我在实际项目中用的是混合检索BM25字面匹配和向量语义匹配并行两个路线的结果合并后再进入重排阶段。BM25擅长精确匹配专有名词、编号、人名向量检索擅长理解意图两者互补。合并后的候选集可能有几十条不能直接丢给大模型这时就要上重排模型。重排阶段我强烈建议用交叉编码器类模型它对query和候选文档逐对打分精度远高于双塔式的向量检索。这一步很多人省略觉得“召回了反正大模型能挑”但实测下来跳过重排直接取Top-K长尾问题会非常明显——经常出现前几名的片段来自同一篇文档真正的关键信息排在十名开外。我通常的做法是向量召回Top-50BM25召回Top-20合并去重后交叉编码器精排再取Top-5或Top-8给大模型。这一套流程下来答案质量和稳定性都明显提升。2.3 生成的约束让大模型在事实轨道上作答检索做好了最后一关是生成。很多人以为把片段塞进prompt就完了结果模型还是会在答案里夹带私货。问题出在prompt约束不够。大模型的习惯是“尽力满足用户”如果片段信息不足它倾向于用训练时见过的常识来补全这就又绕回了幻觉。我的做法是在系统指令里写死几条规则只能使用检索片段中明确表达的事实不得补充外部知识。如果片段中的信息不足以回答必须明确回答“根据现有资料无法确认”。回答必须标注出处的片段编号便于用户溯源。表面看这几句话很简单实际效果却差别很大。没有约束的prompt答案流畅度很高但可靠性存疑加了约束之后模型“宁可不说也不乱说”的比例明显升高。这里还有一个容易忽略的点prompt里给模型的片段不能太长。上下文窗口再大塞进几十个chunk也会稀释注意力。给模型喂的应当是“精筛后的少量证据”而不是“大量的检索结果”。这也意味着重排结果的质量直接决定了生成效果的上限。3. RAG落地后我见过最多的问题检索不到、拼错证据、只答不查3.1 检索词与大模型提问词的语义鸿沟实际业务中第一个高频问题是“用户提法”和“文档写法”对不上。用户问的是“预算审批卡在哪个环节”文档里写的却是“费用报销流程节点”用户问“这台服务器为什么老宕机”运维文档里写的是“高负载下实例重启原因分析”。语义上明明是同一件事但字面差距很大。向量检索能解决一部分可它受限于嵌入模型的表达能力。遇到专业术语、内部黑话、缩写匹配效果会明显下降。我在某系统里曾经加过一个“同义词扩写”模块先让大模型把用户问题改写成几个不同的检索词再分别去查。效果有提升但也引入了额外延迟和成本。说到底这是检索问题需要组合手段去逼近而不是指望单一技术彻底解决。3.2 多跳问题单次检索的结构性局限比词面鸿沟更棘手的是多跳问题。什么叫多跳就是回答一个问题需要先查A才知道该查B最后才能得到C。我举个例子用户问“三月份的订单量为什么比二月份低”。完整推理链路是先查三月的订单数据发现主要跌幅出现在华东区再查华东区的运营日志发现是因为一次大促结束和物流调整。这三步必须依次推进每一步都依赖前一步的结果。单轮RAG完全处理不了这种问题。你只能让模型把“三月订单量为什么下降”作为一个整体问题去检索结果往往是只捞到一篇笼统的月报或者只命中“华东区物流调整”这一小段答案始终是片面的。更麻烦的是模型不会向你反馈“我找到的信息不够”它会默默地把残缺信息包装成完整结论。这是RAG在架构上的一个硬伤它把检索当成了“一次性动作”而不是“可迭代的过程”。哪怕重排阶段做得再精细第一步召回的集合本身就缺关键材料后续都是巧妇难为无米之炊。3.3 事实性错误与“看似合理的胡说”RAG还有一个特别隐蔽的问题证据拼接。模型可能在一次回答里引用两三个片段然后自己把多个片段的信息“合理想象”地连接起来。比如一个片段说“系统在2.0版本取消了自动对账功能”另一个片段说“3.0版本重新引入了对账模块”模型可能生成出“2.0取消后又改回了自动对账”的结论但真相可能是3.0用的是完全不同的技术方案。单个片段都是真的拼在一起却是错的。我做事实一致性评测时发现这种“片段级真、结论级假”的错误用常规的置信度打分很难捕捉。因为模型自己并不知道两个片段之间存在版本、逻辑上的冲突。想缓解这个问题只能在prompt中强调“片段间存在冲突时要在答案中明确指出而不是自行调和”同时搭配证据链展示让用户能回头核查。4. DeepSearch的解题思路让模型自己决定查什么、怎么查4.1 从“一次问答”到“多轮任务”规划层的出现前面说的这些痛点指向同一个方向需要让系统在回答前先有能力规划“怎么回答”。这正是DeepSearch类方案的核心改动。DeepSearch的定义还在快速演化中我对它的理解是一种具备多步推理、主动检索和自我校验能力的搜索范式。它和RAG最直观的区别在于——RAG把用户问题当成“一个查询”DeepSearch把用户问题当成“一个任务”。处理任务时模型先做规划这个问题需要哪些信息哪些我已经知道哪些需要去检索检索回来后够不够不够的话下一步该查什么这一步通常由一个规划模块来承担它可以是大模型直接输出子任务列表也可以是通过外部状态机控制流程。关键是“再来一轮”变成了一种正常操作而不是异常例外。我还注意到这类系统里有一个“评估当前信息充分性”的步骤这是RAG没有的。RAG默认检索结果就是够的DeepSearch则要求模型带着评估标准去判断——如果一个答案的证据链不完善它会继续往下查。4.2 工具调用的串联检索、计算、推理并行作业DeepSearch里的“搜索”不再是向量库一个来源。它的一个典型特征是工具调用模型可以自主选择检索工具、数据库、甚至代码执行环境。我用一个具体场景说明。用户问“过去半年我们的客户流失率是上升还是下降”如果只靠RAG检索文档能查到的是零散的报告结论很难给出一个有计算依据的数字。但DeepSearch式系统可以做这几步先从客户数据库查半年内的月度活跃用户数再让一个计算工具算出每个月的流失率最后找一份市场分析报告来补充可能的原因。“让模型决定调用什么工具、以什么顺序调用”这件事本质上是把大模型从“会说话的人”变成了“会做事的人”。这里的技术难点不在单个工具而在模型对“该用哪个工具、结果如何解读”的决策能力。实测中规划链路越长越容易出错所以早期设计时宁可每一步做小也别让模型一口气规划十个动作。4.3 证据链与置信度输出答案前先自检一步DeepSearch另一个值得关注的设计是在输出前加入自检环节。大模型生成完答案初稿后系统会做一轮核对每条结论在检索材料里有没有对应原文引用编号是不是真实存在有没有出现两条证据互相矛盾这一步的好处是能把“证据拼接导致的事实性错误”拦下一部分。如果自检时发现某条结论支撑不足系统可以回退到检索阶段补查而不是直接把有风险的答案发给用户。我见过一些系统在UI上同时展示“证据链”把每一步的检索来源、中间结论、最终答案串成一个可追踪的链路。这样做的代价也很明显多轮检索、多轮自检会大幅拉长响应时间。用户在传统搜索中习惯了“秒出结果”到了DeepSearch场景必须重新教育用户——你这是在“等待一个研究助手帮你做功课”而不是“点一次链接就跳转”。这也是DeepSearch目前更适合复杂任务、而非轻量查询的原因。5. 哪些场景真的需要DeepSearch哪些用RAG就足够5.1 用一张对比表看清两者的分工我在决定某系统架构时常用这张表来帮团队对齐预期维度传统RAGDeepSearch式搜索问题类型单轮、事实型问答多跳、分析型任务检索次数通常一次迭代多次自主判断工具来源固定的知识库片段知识库、数据库、搜索接口等推理要求低依赖上下文拼接高需要规划与中间推理证据链可引用具体片段多步证据链逐级追溯延迟表现秒级通常明显更长成本一次检索一次生成多轮检索多轮调用答案上限受限于首轮召回质量可通过迭代逼近完整答案这套对比看起来是“一个更高级”但实际上两者是不同取舍下的产物不存在谁完全取代谁。5.2 成本与延迟DeepSearch不是万能药我在实践中反复提醒过团队DeepSearch的每一次“更强”都会付出真金白银的成本。RAG模式下回答一个问题通常是一次向量检索加一次大模型生成延迟控制在两三秒内是可行的。到了DeepSearch模式一次问答可能包含问题拆解、三到五轮检索、多次模型推理、自检与修正加起来的调用次数可能十倍于RAG。如果业务指标里硬性要求“90%的请求三秒内返回”这类方案就很难直接上线。另外一个容易被忽略的成本是维护成本。工具调用、规划状态机、错误恢复、超时处理每个环节都比单轮RAG复杂。小团队在没有明确收益预期时一上来就做全量DeepSearch很容易陷入“demo很惊艳生产没人维护”的境地。5.3 混合架构在真实系统里如何组合两者所以我在落地时更倾向一套混合架构简单问题走RAG快速通道复杂问题走DeepSearch慢通道前面加一个路由判断。路由分类器可以是一个轻量模型也可以是大模型做一次快速分类。判断依据包括三块问题是否涉及多步推理例如问题里含有“为什么”“对比”“趋势”这类词是否依赖具体数据计算以及是否存在需要跨文档整合才能回答的线索。简单问题直接走RAG用户秒回复杂问题进入DeepSearch链路用户看到的是一个“正在分析”的过程而不是干等。这套混合设计方案在目标业务里最大的好处是让“快”和“深”同时成立。用户不会为搜索一次简单问题承受太长等待而真正复杂的问题又确实能得到更完整的答案。最重要的是它让团队可以在同一个产品里逐步积累DeepSearch的数据和评测结果等效果稳定后再扩大流量占比。6. 一步一步从RAG迁移到DeepSearch的实操路线6.1 先给RAG装上工具调用如果你现在只有一个RAG系统别急着推倒重来。第一步可以先把“检索”变成模型可调用的工具而不是它在prompt里被动接收上下文。具体做法是接入一个支持工具调用的模型接口定义一个类似search_knowledge_base(query, top_k)的函数。模型被问到问题时不再由外部逻辑强制做一次检索而是由模型自己决定“要不要查、查什么”。这一步的改动量不大但意义重大——它把“检索”从固定流程变成模型的一个可选项为后续循环迭代铺路。我在某项目里试过这个中间态效果很有意思模型在遇到知识库覆盖不到的问题时会有两种表现——一是反复用不同的关键词重查二是回答“没有足够信息”。这两种表现都比原来硬编答案要好得多。6.2 把单轮检索改成带反馈的循环检索下一步在工具调用基础上加入一个简单的循环控制逻辑。流程大致是模型根据用户问题生成一个检索词执行检索。将检索结果摘要返回给模型模型判断信息是否足够回答。如果不足模型拆解或调整检索词再执行下一轮。达到最大迭代次数我一般设为3轮后模型基于当前已有信息给出答案并标注哪些部分尚无证据。这里有个很关键的工程点必须有迭代上限和超时保护。否则遇到开放性问题模型可能一直查下去成本不可控。我见过的另一个实用技巧是每轮检索后让模型输出一句“当前缺少的信息是什么”这能明显提升下一轮检索的命中率。如果用的是现成的agent框架比如支持规划和反思的工具可以直接基于它的循环机制改造如果想自己控制用一个状态机分别维护“规划中、检索中、评估中、回答中”四种状态也能跑通。核心不在于用什么框架而在于“检索—评估—再检索”这个闭环真正建立起来。6.3 评估体系别只看RAG指标还要看任务完成率从RAG迁移到DeepSearch评估体系也要跟着变。RAG时代大家习惯看命中率、生成忠实度这类指标但DeepSearch系统里这些指标只能反映局部不能反映“任务是否被完整解决”。我给这类系统建议的评估维度是任务完成率复杂问题中模型是否给出了完整的答案还是只答了其中一部分。这是首要指标。证据引用命中率答案里的每条关键结论是否能精确追溯到引用的片段原文有没有张冠李戴。检索回报率每一轮检索中有多少轮确实为最终答案贡献了信息还是白走了几趟。端到端延迟与成本一个复杂任务的平均耗时和token消耗是否在可接受的商业范围内。评估集不要用现成公开集一测了事。我建议在业务语料基础上构建30到50条复杂问题覆盖“多跳推理”“跨文档对比”“数据计算”这几类每条问题都预先把标准答案的证据链整理好。这项工作最好让业务方一起参与标注因为技术同学自己标注容易漏掉业务上真正关心的判断逻辑。另外一个容易被忽视的点DeepSearch系统的错误模式比RAG更复杂——有的错在规划环节有的错在工具调用有的错在证据拼接。排查时如果只盯最终答案很难定位根因。我在排查时习惯给每次运行保存完整trace包含每一轮模型的思考、检索词、返回结果摘要和中间结论这样一旦出问题可以按链路逐步回溯。从我个人的实操体会来说从RAG走向DeepSearch并不是一次“升级”而是一次“架构思维切换”。RAG训练我们的是如何把检索和生成接好DeepSearch要求的则是如何让模型像人一样去查资料、判断线索、核对证据。这个方向还很新工程细节每天都在变化但大方向已经比较明确AI Search的下半场拼的不只是模型有多聪明更是检索、推理、验证这套闭环做得有多扎实。
阅读完成 · 觉得有帮助？
