企业官网建设流程全解析

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-50，BM25召回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 用一张对比表看清两者的分工

我在决定某系统架构时，常用这张表来帮团队对齐预期：

这套对比看起来是“一个更高级”，但实际上两者是不同取舍下的产物，不存在谁完全取代谁。

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 把单轮检索改成带反馈的循环检索

下一步，在工具调用基础上加入一个简单的循环控制逻辑。流程大致是：

1. 模型根据用户问题生成一个检索词，执行检索。
2. 将检索结果摘要返回给模型，模型判断信息是否足够回答。
3. 如果不足，模型拆解或调整检索词，再执行下一轮。
4. 达到最大迭代次数（我一般设为3轮）后，模型基于当前已有信息给出答案，并标注哪些部分尚无证据。

这里有个很关键的工程点：必须有迭代上限和超时保护。否则遇到开放性问题，模型可能一直查下去，成本不可控。我见过的另一个实用技巧是每轮检索后，让模型输出一句“当前缺少的信息是什么”，这能明显提升下一轮检索的命中率。

如果用的是现成的agent框架，比如支持规划和反思的工具，可以直接基于它的循环机制改造；如果想自己控制，用一个状态机分别维护“规划中、检索中、评估中、回答中”四种状态，也能跑通。核心不在于用什么框架，而在于“检索—评估—再检索”这个闭环真正建立起来。

6.3 评估体系：别只看RAG指标，还要看任务完成率

从RAG迁移到DeepSearch，评估体系也要跟着变。RAG时代大家习惯看命中率、生成忠实度这类指标，但DeepSearch系统里，这些指标只能反映局部，不能反映“任务是否被完整解决”。

我给这类系统建议的评估维度是：

• 任务完成率：复杂问题中，模型是否给出了完整的答案，还是只答了其中一部分。这是首要指标。
• 证据引用命中率：答案里的每条关键结论，是否能精确追溯到引用的片段原文，有没有张冠李戴。
• 检索回报率：每一轮检索中，有多少轮确实为最终答案贡献了信息，还是白走了几趟。
• 端到端延迟与成本：一个复杂任务的平均耗时和token消耗，是否在可接受的商业范围内。

评估集不要用现成公开集一测了事。我建议在业务语料基础上构建30到50条复杂问题，覆盖“多跳推理”“跨文档对比”“数据计算”这几类，每条问题都预先把标准答案的证据链整理好。这项工作最好让业务方一起参与标注，因为技术同学自己标注，容易漏掉业务上真正关心的判断逻辑。

另外一个容易被忽视的点：DeepSearch系统的错误模式比RAG更复杂——有的错在规划环节，有的错在工具调用，有的错在证据拼接。排查时如果只盯最终答案，很难定位根因。我在排查时习惯给每次运行保存完整trace，包含每一轮模型的思考、检索词、返回结果摘要和中间结论，这样一旦出问题，可以按链路逐步回溯。

从我个人的实操体会来说，从RAG走向DeepSearch并不是一次“升级”，而是一次“架构思维切换”。RAG训练我们的是如何把检索和生成接好，DeepSearch要求的则是如何让模型像人一样去查资料、判断线索、核对证据。这个方向还很新，工程细节每天都在变化，但大方向已经比较明确：AI Search的下半场，拼的不只是模型有多聪明，更是检索、推理、验证这套闭环做得有多扎实。