企业官网建设流程全解析

最近很多人问我同一个问题：RAG（Retrieval-Augmented Generation，检索增强生成）到底该怎么学？网上的资料要么只讲最基础的向量库加Prompt拼接，要么一上来就甩一堆Agent框架，中间那段最关键的演进过程反而没人讲清楚。

这篇文章我想把这些年实际做RAG项目的经验整理成一条完整的技术脉络，从最朴素的Naive RAG一路讲到Agentic RAG。不是给你堆概念，而是讲清楚每一代方案到底解决了什么问题、引入了什么新麻烦、以及你在自己项目里该怎么选。不管你是刚接触RAG的新手，还是已经上过生产环境但总感觉效果不稳定的开发者，这条演进线应该能帮你定位到自己所在的位置，也看清楚下一步该往哪走。

1. 以Naive RAG为起点：这套架构的设计初衷与失效边界

1.1 先搞清楚RAG到底解决的是什么问题

大语言模型（LLM）有两个很让人头疼的毛病：一是知识有截止日期，你问它最近发生的事它只能瞎编；二是它特别自信，不知道也硬答，一本正经地胡说八道，也就是日常说的“幻觉”。

RAG的思路其实非常朴素：既然模型脑子里没有这些知识，那我们就先把知识存到外面，在回答用户问题之前，先把相关的资料片段查出来，拼到Prompt里告诉模型“这是参考答案，你看看再答”。这就是Naive RAG最经典的链路：先切分文档，再向量化存入向量库，用户提问后将问题向量化检索Top K相关片段，最后把片段拼接进Prompt交给LLM生成回答。

这个链路在2023年上半年确实解决了不少问题，很多RAG项目的MVP（最简可行产品）都是这么跑通的。我第一次把一个企业内部知识库接上这套链路时，效果已经明显优于直接裸问LLM，至少产品经理觉得“看起来像那么回事了”。

1.2 Naive RAG的三大典型失效场景

但你只要在真实场景里跑一段时间，就会开始经历各种翻车现场。我复盘下来，最常见的问题集中在三类场景，都是在某电商客服项目中实际见过的：

第一类是语义重合但关键实体被稀释的问题。用户问“退款一般几天到账”，文档库里的退款政策里同时包含“退款申请条件”“退款审核流程”“退款到账时间”等多个板块。按向量相似度召回时，整段文字里和“到账时间”相关的句子占比不高，语义向量被其他内容“稀释”，召回来的Top 3片段可能都在讲退款条件，真正回答用户问题的信息根本没被检索到。结果是模型答非所问，但它语气还特别笃定。

第二类是跨文档的多跳问题。用户问“我用的某型号主板的BIOS能不能支持某型号内存”，答案需要先查主板BIOS版本对应关系，再看这个版本是否支持该内存型号。知识库里这些信息分属两个不同的文档，Naive RAG一次只能检索一轮，拼进来的上下文大概率只有其中一段，LLM再聪明也推理不出来。

第三类是知识时效冲突。同一个知识库里面有新旧两版操作手册，新的说“流程A已改为自动执行”，旧的还在写“需要手动提交”。向量检索时两篇文章都召回来了，模型不知道谁新谁旧，回答就飘忽不定。

1.3 失效的根源：不是某一个环节坏了，而是链路没有反馈

遇到这些问题时，我一开始也以为是向量化模型不够好，换个更强的Embedding模型确实有点改善，但解决不了本质问题。后来想明白了：Naive RAG的问题不是单点质量问题，而是链路级的结构性缺陷——一次检索、一次拼接、直接生成，整个过程是单向的，没有校验、没有反馈、没有重试机制。

你可以把它想象成一个从不确认订单的外卖流程：顾客下单，厨房只凭第一感觉备菜，出餐直接送出去，凉了、错了、菜没了都没人管。它对外卖这个场景当然有点用，但复杂度稍微上来之后，问题就全都暴露出来了。这也是为什么后来业界开始对RAG链路的各个环节做精细化升级，催生了中间那一大波Advanced RAG和Modular RAG的演进。

2. 从Naive到Modular：检索链路上每一环都经历了什么升级

2.1 预检索阶段：问题改写的价值被严重低估

很多人优化RAG时，眼睛死死盯着召回环节，却忽视了最前面那个输入问题本身。Naive RAG默认用户的问题是一个完美的检索Query，但现实是用户问法口语化、指代不清、信息不全，拿这种Query直接去做向量检索，效果从源头就打折扣了。

这个阶段最常用的技术是查询改写（Query Rewriting）。最朴素的改写是让LLM把用户问题转成更规范、更完整的查询语句，比如把“那个能退吗”改写成“该商品在七天无理由退货范围内吗”。更进一步是HyDE（Hypothetical Document Embeddings）思路，让LLM先假装已经知道答案、写一段假设性的回答文档，再用这段文档去做相似度检索。我们实测下来，HyDE在很多文档风格偏规范的知识库里效果确实不错，因为它把“找相似的句子”变成了“找语义空间里更接近答案的区域”，检索命中率提升明显。

还有一种很实用的改写策略是子查询分解。当用户的问题明显包含多个子问题，比如“帮我比较A和B的售后政策差异”，直接用一个Query去检索很容易只偏向其中一方。把问题拆解成“A的售后政策”和“B的售后政策”分别检索，再汇总结果，效果稳定得多。

2.2 检索阶段：单一向量召回远远不够

向量检索的优势是理解语义，但它在精确关键词匹配上反而可能不如老牌的BM25。说得直白一点，用户问“订单状态在哪里看”，如果文档里恰好稳定的表述是“查询物流信息和配送进度”，语义上是一回事，但纯向量检索可能因为表述差异错过了这个最相关的内容。

业内现在几乎默认的答案是混合检索（Hybrid Search），向量召回加BM25关键词召回同时跑，再用一定策略融合两路结果。融合策略最简单的就是RRF（Reciprocal Rank Fusion），把多路结果的排名倒数值相加重新排序。我们项目里的实际感受是，混合检索召回的片段集合比单路向量召回“稳”很多，虽然不一定每次都能提升最终答案，但至少有效降低了“完全找不到相关信息”的概率。

另外还需要提到多路召回的概念。一个企业知识库往往不止一种数据源，FAQ库、产品手册、售后工单、内部Wiki，特征差异很大，粗暴地全部塞进一个向量库里再统一检索，效果一定差。按数据源分库，各自走合适的切分策略和检索策略，最后在融合层汇总，这才是Modular RAG“模块化”思想的精髓——不同模块选不同的最佳实践，而不是一套配置打天下。

2.3 后检索阶段：重排序和上下文扩展才是保命环节

召回回来的Top K不一定每条都准，甚至顺序也未必合理。LLM生成时会更关注Prompt靠前位置的上下文，如果最相关的片段排在第5位，模型可能就忽略掉了。所以重排序（Rerank）几乎是Advanced RAG里投入产出比最高的一个环节。

重排序模型会给召回片段逐条打分，把真正和用户问题强相关的片段排到最前面。我们的工程实践是两级策略：先用时效和渠道过滤掉明显不合适的（比如旧版本文档），再用重排序模型精排。模型选择上，算力充足可以用基于LLM的交互式重排序，效果最稳；在线服务求快的话，用双塔结构的轻量重排也能接受。重排序之后通常只保留最前面的Top 2到Top 3片段进Prompt，质量远好于一股脑塞Top 5进去。

同时还要处理一个隐蔽问题：向量检索的单元是文档切片，切片可能正好从一个话题的中腰截断，上下文不完整。常见解法是检索后向前后各扩展几个相邻片段，重新拼出一个更完整的语境窗口。这个操作成本极低，但对答案连贯性的提升非常直接。

2.4 这波升级的实质：每个环节变强了，但整体仍旧是流水线

走到这一步，RAG链路已经比Naive时代强了一大截，查询改写、混合检索、重排序、上下文扩展，每一环都有了成熟方案。这套东西现在依然是绝大多数生产级RAG项目的骨干配置，我甚至想说，如果你的RAG还没做过任何后检索优化，先把这一环补上，性价比远高于盲目追新架构。

但同时也得承认一个结构性天花板：这些升级全部发生在固定流水线内部。流程永远是“改写→检索→重排→拼接→生成”，不会因为检索结果不理想就再查一次，不会为了一个问题自动去查不同类型的数据源，也不会在生成过程中发现信息缺失后返工。流水线的工人（各环节模块）确实都变专业了，但整条流水线没有调度中枢，更不会自己做决策。

这就是下一阶段演进的真正动机——从“把流水线做得更好”转向“让系统自己决定怎么干活”。

3. Agentic RAG的本质：从固定流水线到会规划的执行者

3.1 一步关键转变：把流程控制权交给模型

Agentic RAG和前面所有RAG形态最大的区别，不是某一个模块变聪明了，而是整个系统的控制逻辑从“人写死的代码流程”变成了“模型实时做的决策”。

Naive和Advanced RAG的流程是你预先编码好的，先做什么后做什么固定不变。Agentic RAG则把每一步都变成了模型可以自主决定的行为：它先判断用户的问题到底需不需要查资料、如果需要查，该查哪一个或哪几个数据源、要不要拆分查询、收到检索结果后判断够不够回答、不够就再查一轮，甚至可以选择调用一个外部的计算工具。整个过程是一个带反馈循环的自主推理循环，而不是一次性的管道。

打个比方，Naive RAG像一个初级助理，接到客户诉求就原封不动转发给售后部门，转完就算交差。Agentic RAG更像一个资深助理，先判断客户是来退钱还是来投诉，再决定先查订单记录还是先翻售后政策，查完发现缺了物流信息，再去物流系统补查一遍，最后整理好信息给主管一个完整的答复建议。助理做的事还是那些事，但过程中的判断、纠错、多步骤安排，全是临场实时完成的。

3.2 核心能力拆解：Agent到底在哪些节点做决策

我拆过很多Agentic RAG系统的行为轨迹，核心决策点其实是有限的几个。掌握了这几个节点，你就能理解整套机制是怎么运作的。

第一个决策点是意图判断和路由。用户的Query是不是一个知识检索类问题？该走向量库、走SQL查询、还是直接让LLM回答就行？路由分类现在既可以用一个轻量分类模型预先判断，也可以直接让Agent用工具选择的方式自己决定。第二个决策点是检索计划生成。对于复杂问题，Agent会把主问题拆解成多个检索子任务，并给每个子任务指定合适的数据源。第三个决策点是多轮检索和结果评估。拿到检索结果之后，Agent会判断“这些材料够不够支撑我回答”，不够就重新组织查询再搜一轮，这个判断是整个ReAct式循环的核心。第四个决策点是生成后的自我检验。有的实现里Agent还会检查最终答案是否覆盖了用户所有诉求、是否存在自相矛盾，发现遗漏再补一轮检索。

3.3 一个完整的Agentic RAG循环长什么样

我用一个实际跑通过的简化循环来说明整个过程。用户输入了一个复杂问题，系统启动后首先是规划阶段，Agent分析问题结构，识别出需要检索的子主题和对应数据源。接着是工具选择，它从已注册的工具列表里选出检索器、文档库接口、SQL查询器、网络搜索接口里最合适的一组。然后是执行与观察，依次或并行调用工具，拿到检索结果作为“观察”输入。接着是反思与决策，Agent结合观察结果自问“这些信息是否覆盖了所有子主题”，如果发现缺失，就改写查询进入下一轮循环。如果评估已足够，就进入最后的生成阶段，汇总所有检索结果组织完整答案输出。

这里有两个工程细节非常关键。第一，必须设计“终止条件”，不然Agent可能在复杂问题上循环到超时。最常见的做法是限制最大轮数，同时设定一个置信度阈值，检索结果够了就早停。第二，每一步的工具调用建议“可观测、可回放”，把Agent每一步的决策和工具结果记录成轨迹日志。这个日志在调试时价值巨大，否则Agent就像个黑盒，出了问题根本没法定位是该改Prompt还是该换检索器。

3.4 和Naive RAG的架构对比：谁在控制流程，数据流向哪里

为了把差异说得更清楚，我从六个维度做了个对比，这也是我给团队做选型培训时用的表。

第一个维度是控制流，Naive RAG是固定的预定义流水线，Agentic RAG是模型驱动的动态决策流。第二个维度是单轮检索能力，Naive和Advanced只能做一次检索加生成，Agentic可以多轮迭代直到信息充分。第三个维度是多跳推理，Naive跨文档要碰运气，Agentic会主动规划子查询并按需检索。第四个维度是上下文管理，Naive把Top K片段一次性全塞进Prompt，容易超长也容易信息冗余，Agentic会按子任务分步维护需要的信息组合。第五个维度是成本与延迟，Naive最便宜也最快，Agentic多轮调用模型和检索器，成本和延迟都会明显上升。第六个维度是可解释性，Naive链路简单容易复盘，Agentic靠完整轨迹日志也能定位问题，但分析和调优复杂度明显更高。

3.5 代价与边界：Agentic不是银弹

Agentic RAG听着很美好，但它是有明确代价的，而且这几个代价在真实项目里常常劝退人。最直接的是延迟。每多一轮决策和检索，就多一次LLM调用加上检索耗时，复杂问题跑下来动辄十几秒甚至几十秒，用户根本等不起。其次是成本，多轮推理意味着Token消耗成倍增长，复杂Agent一次调用可能吃掉普通RAG二十倍的Token开销。再有就是可控性风险。给了模型自主调工具的权力，就必然要面对它“调用得对不对”的质疑，一旦某个工具返回异常数据，Agent可能沿着错误方向越走越远。

所以现在业内一个共识是：不要一上来就全场景上Agentic，而是先用它处理那些“单轮检索解决不了”的复杂问题，简单问题继续走轻量链路，把两者路由起来。这个思路我在自己的项目里验证下来非常稳，人性化地讲，能把钱花在最需要的地方。

4. 落地实战：选型判断、演进路径和最容易翻车的坑

4.1 四类场景该怎么选，直接给结论

被问得最多的一个问题是：我到底该用哪一代RAG方案？说实话，这不是选“最新最好的”，而是选“匹配当前瓶颈的”。我按四类典型场景给你一个可以直接抄的结论。

第一类，简单FAQ问答库，问题相对固定，答案都在单一文档里，Naive RAG加一个重排序就够了，完全没必要上Agentic。第二类，企业内部综合知识库，多个数据源、文档数量大、问题五花八门，建议至少上Advanced RAG：查询改写加混合检索加重排序，这套组合能覆盖八成的失败场景。第三类，跨系统跨文档的复杂问答，需要查知识库还要查订单系统数据才能回答，这类就必须上Agentic RAG了，因为只有多轮规划和多工具调用才能完成跨源信息拼装。第四类，实时性要求极高的场景，比如股价查询、库存查询，这类不太适合靠文档向量化兜底，更应该走“路由判定后直连API”的轻量Agent方案，而不是背着厚重知识库跑完整循环。

4.2 不同方案的性价比账要算清楚

很多团队决定要不要升级方案时，只看效果不看成本，我建议你算一笔实在的总账。Naive RAG的工程成本很低，两周内可以上线，单次问答成本几乎可以忽略，但它面对中等复杂度以上的问题时准确率下滑得很厉害。Advanced RAG的工程量中等，重点在于搭建重排序模型服务和设计查询改写策略，单次成本略有上升，但对简单和中等复杂度问题的效果提升非常明显，是当前性价比最高的一档。Agentic RAG工程量最大，需要做工具注册、流程编排、循环终止策略和详尽的轨迹日志，单次成本可能是Advanced的十倍以上，但它对复杂问题的解决能力是前两档完全不具备的。

所以我的判断标准很简单：如果你的失败样本里大部分是简单问题答错，先回头补Advanced；如果是复杂问题完全答不了，才值得上Agentic。

4.3 从Naive到Agentic的平滑演进路径

我不建议任何人从零直接搭一套完整Agentic RAG，那套系统牵涉太多，调试周期太长，很容易中途放弃。更务实的做法是沿着一条渐进路线走，每一步都能看到效果回报。

第一步先加重排序，这是最简单也是收益最明显的一个改动，把向量召回结果用重排序模型精排，很多答非所问的问题当场就消失了。第二步加查询改写和子查询分解，这一步能改善复杂问法和指代不清的输入，检索命中率上一个大台阶。第三步加检索路由，先判断这个问题走向量库、走SQL还是直接生成，这一步其实是进入Agent范畴的敲门砖，但控制面仍然比较简单。第四步才上完整的多轮Agent循环，让系统具备“检索后自评、不足再查”的能力。走完这四步，你实际上已经拥有了一个相当完整的Agentic RAG系统，而且每一步跨幅都不大，出了问题也很好回溯。

4.4 实测中最容易翻车的五个坑

第一个坑是给Agent的“自由度”太大，又没有兜底校验，它可能在错误的方向上反复检索，白白消耗大量Token。第二个坑是知识源的元数据严重缺失，Agent的评估与筛选能力再强，也分不清两篇冲突文档谁新谁旧、谁更权威，所以给文档打上版本时间、来源、可信度这些元数据，是Agentic方案有效的前提。第三个坑是评估指标没统一，很多人一个劲地调检索模块，但根本没有一套固定的测试问题集，改来改去也不知道是变好了还是变坏了。第四个坑是Prompt上下文越堆越长，多轮循环会把之前所有检索结果不断叠加，最后既浪费Token又干扰模型注意力，要主动压缩和筛选历史观察内容。第五个坑是把Agent的失败全归因于LLM能力不行，实测中很多所谓“模型不聪明”的问题，根源其实是工具返回信息格式混乱，模型根本提取不到关键点。

4.5 怎么判断自己的RAG系统还缺什么

给你一个我自己一直在用的排查方法：准备一组覆盖不同难度的测试问题集，至少包含二十个典型问题，包含简单事实类、单文档细节类、跨文档推导类、时效冲突类和否定类。定期拿这组问题喂给系统，把失败案例逐条聚类，看主要失败模式集中在哪一类。检索阶段彻底失败还是排了相关片段但顺序太差，是上下文不完整还是生成阶段逻辑错了。根据不同失败模式去对应地调整对应模块，这个排查闭环比盲目引入任何新架构都更有效。

最后分享一个实际切换后的观察

从Naive一路做到Agentic，我个人最大的感受是：方案升级不是技术炫技，而是被失败样本逼出来的。我们在一个内部系统里刚上完整Agent循环时，最直观的变化是复杂问题的成功率确实大幅提升，但与此同时，那些本来用轻量链路就能答好的简单问题，延迟和成本也被拖高了。后来加了路由规则，让简单问题走快车道，复杂问题才进Agent循环，整体体验才算真正稳定下来。

如果你目前还在Naive阶段，别急着追Agentic，先把手里的失败案例聚类看一遍，找到自己最痛的瓶颈，再沿着“重排序→查询改写→检索路由→多轮循环”这条路一步步走。RAG这个领域还会继续演进，但排查问题和做技术选型的思路，大致就是我上面写到的这些。到时候再看到新概念，你也不会慌，因为你知道它到底在解决哪个环节的什么问题。