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流程
比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，大概率会浪费资源。
决策流程
我的建议
如果你是个人开发者或小团队
从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的第一步，也是很多人踩坑最多的一步。