--- title: "08-RAG三代进化史与架构选型" created: 2026-05-14 tags: - 博客 --- # RAG三代进化史与架构选型 还记得诺基亚那个年代吗？手机只能打电话发短信，拍照是奢侈功能，像素还低得可怜。后来有了智能机，拍照能力一代比一代强——从单摄到双摄，从双摄到三摄，从普通拍照到AI算法加持。 RAG技术的演进也是类似的路子。 从最初的"能用就行"，到后来的"用得更好"，再到现在的"灵活可扩展"，RAG经历了三代演进。搞懂这三代的区别，你才能在实际项目中做出正确的架构选型。 ## 第一代：Naive RAG——能跑就行 ### 这是什么 Naive RAG，也叫基础RAG，是最原始、最标准的实现方式。 流程非常直接： - 把文档切块 - 转成向量存起来 - 用户问问题时，检索最相似的几块 - 把检索结果和问题一起发给大模型 没有花里胡哨的优化，就是最朴素的"检索+生成"。 ### 适合什么场景 - **快速验证想法**：老板说下周要看demo，你没时间搞复杂架构 - **数据量不大**：几百篇文档，用户量也不多 - **对效果要求不高**：能回答个大概就行，不追求极致准确 ### 有什么问题 用过之后你会发现，问题还挺多： **检索不准** 用户问"服务器宕机怎么处理"，检索出来的可能是"服务器配置说明"——沾点边，但不是用户真正想要的。 **噪音太多** 检索返回5条结果，可能只有2条真正有用，其他3条是凑数的。大模型看了这些"噪音"，回答质量也会下降。 **问题理解差** 用户说"上次那个问题怎么解决的"，系统根本不知道"那个问题"指的是啥。 **无法处理复杂问题** 用户问"对比一下A产品和B产品的优缺点"，这需要同时检索两个产品的信息并做对比分析，Naive RAG搞不定。 ### 小结 Naive RAG就像功能机时代的手机——能打电话，能发短信，基本功能都有。但想拍出好照片？想上网冲浪？那肯定得升级换代了。 > 很多团队在验证阶段就直接搭建复杂的Advanced RAG，结果投入大量时间，却发现需求本身还没想清楚。建议先用Naive RAG跑通业务流程，再针对暴露出的具体问题逐步优化。 ## 第二代：Advanced RAG——把每个环节都优化一遍 ### 这是什么 Advanced RAG是在Naive RAG基础上的增强版本。核心思路是：**既然基础版本有这么多问题，那就把每个环节都优化一遍。** 这也是目前大部分企业生产环境用得最多的RAG范式。 ### 都优化了哪些环节 **检索前：问题重写** 用户的输入往往不够精确，需要在检索前做一番处理： - **扩充问题**："服务器挂了"→"服务器宕机故障排查方法是什么" - **消除指代**："上次那个问题"→ 结合对话历史，补全具体是什么问题 - **拆分问题**："A和B的区别"→ 拆成"A的特点"+"B的特点"两个子问题分别检索 **检索中：混合检索** 单纯的向量检索有时候不够用。 比如用户问"BUG-2024-0312的处理进度"，这种精确的编号，向量检索可能找不到。 混合检索的思路是：**向量检索 + 关键词检索，两条腿走路。** - 向量检索：理解语义，"服务器挂了"能匹配到"服务器故障" - 关键词检索：精确匹配，"BUG-2024-0312"一个字都不能差 两边的结果融合起来，覆盖面就大了。 **检索后：重排序** 检索返回10条结果，可能前5条里有3条是真正相关的，后5条里也有2条是相关的。 重排序的作用是：**用更精细的模型，把检索结果重新打分排序，让最相关的排在最前面。** 常用的方法有： - **RRF算法**：简单高效，根据排名计算得分 - **ReRank模型**：用专门的语义匹配模型重新打分 **生成时：上下文优化** 检索结果塞给大模型之前，还可以做一些处理： - **压缩上下文**：文档块太长的话，提取关键信息，减少干扰 - **去除重复**：多个文档块内容重复的部分去掉 - **排序优化**：最相关的放在最前面，大模型会更关注前面的内容 ### 典型的Advanced RAG流程 ![[7-Blog/AI技术/RAG详细解析/assets/FowZJl8GE2UColhLB2LKV9w0WZnr-73049f4b.png]] 比Naive RAG多了好几步，但每一步都在提升最终效果。 ### 效果提升有多大 以我的实际经验来说，从Naive RAG升级到Advanced RAG，回答准确率能提升20%-40%，具体看你的数据和场景。 特别是问题重写和重排序这两个环节，投入产出比很高。 > 在Advanced RAG的所有优化中，**问题重写**和**重排序**是投入产出比最高的两项。即使其他环节还没做完善，优先实现这两个往往能带来最明显的效果提升。 ### 小结 Advanced RAG就像智能手机时代的进化——单摄变双摄，加上HDR、夜景模式、AI优化。硬件基础没变，但通过各种软件优化，拍照效果上了一个台阶。 ## 第三代：Modular RAG——乐高积木式架构 ### 这是什么 Modular RAG是目前较新的工程化形态。 核心思想是：**把RAG的各个环节拆成独立的模块，像乐高积木一样自由组合。** ### 为什么需要模块化 Advanced RAG虽然效果好，但有个问题——流程是固定的。 实际业务场景千差万别： - 有的场景需要重排序，有的不需要 - 有的场景需要问题重写，有的用户输入已经很规范 - 有的场景需要多知识库路由，有的只有一个知识库 - 有的场景需要结合知识图谱，有的纯文本就够了 如果每个场景都要改一遍代码，维护成本太高了。 模块化的好处是：**每个功能都是独立的模块，需要什么就插什么，不需要就拔掉。** ### 模块化架构长什么样 一个典型的Modular RAG会把系统拆分成这些模块： | 模块 | 职责 | 是否必需 | | --- | --- | --- | | 查询转换模块 | 问题改写、扩展、分解 | 可选 | | 路由模块 | 根据问题类型分发到不同处理流程 | 可选 | | 检索模块 | 从知识库检索相关内容 | 必需 | | 重排序模块 | 对检索结果重新排序 | 可选 | | 上下文构建模块 | 筛选、拼接、压缩检索结果 | 必需 | | 生成模块 | 大模型生成回答 | 必需 | | 后处理模块 | 格式化输出、添加引用来源 | 可选 | ### 模块化带来的灵活性 **场景一：简单问答** 用户输入很规范，知识库也只有一个，不需要花里胡哨的优化。 启用模块：检索 → 上下文构建 → 生成 **场景二：企业复杂场景** 用户输入可能很口语化，有多个知识库，需要高准确率。 启用模块：查询转换 → 路由 → 检索 → 重排序 → 上下文构建 → 生成 → 后处理 **场景三：实时性要求高** 要求极低延迟，可以牺牲一点准确率。 启用模块：检索 → 生成（跳过所有优化环节） ### 模块化的其他好处 **独立升级** 重排序效果不好？换一个重排序模型，其他模块不用动。 **灵活扩展** 想加一个"敏感词过滤"模块？直接插到生成模块后面就行。 **团队协作** 不同的人负责不同的模块，职责清晰，互不干扰。 ### 小结 Modular RAG就像模块化手机的概念——主板是固定的，但摄像头、电池、屏幕都可以换。虽然模块化手机最终没流行起来，但模块化架构在软件领域是真香。 ## 三代对比：到底是选哪个？ | 维度 | Naive RAG | Advanced RAG | Modular RAG | | --- | --- | --- | --- | | 复杂度 | 低 | 中 | 高 | | 效果 | 一般 | 良好 | 优秀（取决于配置） | | 开发成本 | 1-2天 | 1-2周 | 2-4周 | | 维护成本 | 低 | 中 | 初期高，长期低 | | 灵活性 | 差 | 一般 | 优秀 | | 适用阶段 | POC验证 | 生产环境 | 大规模/多场景 | > 选型的核心考量是**当前阶段的主要矛盾**：是要快速验证，还是要稳定上线，还是要长期维护多个场景？对应选择Naive、Advanced、Modular。不要超前投入——还在验证期就搭Modular RAG，大概率会浪费资源。 ### 决策流程 ![[7-Blog/AI技术/RAG详细解析/assets/FtMOIG2rWZXsJl7bef9AImSaVA-Q-d2a38e19.png]] ### 我的建议 **如果你是个人开发者或小团队** 从Naive RAG开始，遇到具体问题再针对性优化。比如检索不准，就加重排序；问题理解差，就加问题重写。逐步演进到Advanced RAG。 **如果你在中大型公司** 直接上Advanced RAG。大部分公司的需求用Advanced RAG都能满足，而且有成熟的方案可以参考。 **如果你要做RAG平台** 考虑Modular RAG。一次投入，长期受益。平台化之后，不同业务线可以根据自己的需求灵活配置。 ## Spring AI对RAG的支持情况 接下来，该看看Java生态下的技术选型了。 ### Spring AI的RAG能力 Spring AI目前对RAG的支持还处于**能用但不够完善**的阶段： **已经支持的**： - 多种DocumentReader（PDF、Word、Markdown等） - 多种向量数据库（PGVector、Milvus、Chroma等） - 基础的相似度检索 - QuestionAnswerAdvisor（简化版RAG流程） **还不够完善的**： - 混合检索需要自己实现 - 重排序需要自己实现 - 问题重写需要自己实现 - 模块化编排能力弱 ### 实际项目中怎么办 两条路： **路线一：Spring AI + 自研补充** 用Spring AI做基础的文档处理和向量存储，检索优化部分自己写。后面的文章会详细讲怎么实现混合检索、重排序这些。 **路线二：LangChain4J / LlamaIndex** 如果团队对Python也熟悉，可以考虑混合架构。用LangChain或LlamaIndex做RAG核心逻辑，Java做业务层。 ### 一个务实的建议 别纠结于框架，**核心逻辑自己掌握最重要**。 框架会变，版本会升级，API会改。但RAG的核心原理是稳定的：检索、重排、生成，这些概念不会变。 把原理搞透，换任何框架都能快速上手。 > Spring AI目前对混合检索、重排序、问题改写的支持还不完善，需要自己补充实现。但这并不影响使用——把原理搞清楚，缺少的能力自己实现就行。核心逻辑掌握了，换哪个框架都不怕。 ## 小结 这篇文章讲了三件事： - **RAG的三代演进**：从Naive到Advanced到Modular，越来越强大也越来越复杂 - **各代的适用场景**：验证想法用Naive，生产环境用Advanced，平台化用Modular - **技术选型建议**：Spring AI能用但不够完善，核心逻辑要自己掌握 下一篇开始进入实战环节，讲文档预处理——RAG的第一步，也是很多人踩坑最多的一步。