RAG 原理与整体架构

32.1 大模型的三块短板

大模型很聪明，但它有几个天生的毛病。

知识有截止日期。 模型训练完就定格了，之后发生的事它不知道。问它今年发布的新产品，它只能编。

容易一本正经地胡说。 模型不知道答案时不会说不知道，而是会流畅地编一个。这种编造叫幻觉，是生产环境最头疼的问题。

没有你的私域知识。 公司内部文档、产品手册、最新法规，模型都没见过。它对你业务的理解，可能还不如一个实习生。

针对这三块短板，业界有几种解法。微调成本高、周期长，换一次知识要重训一次。提示词工程只能在已有知识上做文章，解决不了知识缺失。真正被广泛采用的，是 RAG。

32.2 RAG 是什么

RAG 的全称是 Retrieval Augmented Generation，中文叫检索增强生成。

核心思想一句话：回答之前，先查资料。 用户提问后，系统先从外部知识库检索相关文档，把文档内容拼进提示词，再让模型基于这些内容回答。

模型不需要”记住”你的知识，它只需要”读懂”你喂给它的资料。知识更新了，换一批资料就行，模型一行代码不用改。

RAG 的效果有数据支撑。答案有据可依，幻觉大幅减少；知识实时可换，成本显著低于微调。这也是它成为 AI 应用标配的原因。

32.3 检索→增强→生成

一个标准的 RAG 流程分三步。

第一步，检索（Retrieval）。 用户提问”我们的退款政策是什么”，系统把问题转成向量，去向量数据库里找出语义最相近的几段文档。这一步用的是第 19 章讲的 EmbeddingModel 和向量相似度。

第二步，增强（Augmentation）。 把检索到的文档内容拼到提示词里，形成”上下文 + 问题”的完整输入。增强用的模板一般会写明：只依据上下文回答，上下文里没有就直说不知道。

第三步，生成（Generation）。 模型读取增强后的提示词，生成最终回答。模型回答时引用的是刚检索到的资料，而不是训练时的旧知识。

整个流程可以用一句代码概括：先 similaritySearch 查出相关文档，再让模型基于上下文回答。

32.4 Spring AI 的 RAG 组件全景

Spring AI 把 RAG 拆成了几个可替换的组件。理解每个组件的职责，后面几章学起来就顺了。

组件	职责	章节
EmbeddingModel	把文本转成向量，检索和入库都靠它	第 19 章
DocumentReader	读取 PDF、Word、网页等原始文件	第 33 章
DocumentTransformer	拆分长文本、提取关键词等加工	第 33 章
VectorStore	存向量、做相似度检索的统一接口	第 34、35 章
QuestionAnswerAdvisor	自动完成”检索+增强”，接入 ChatClient	第 37 章
RetrievalAugmentationAdvisor	可编排的模块化 RAG 流程	第 37 章

这些组件的名字你可能不熟，但它们的分工很好记：读进来（Reader）、切小块（Splitter）、存进去（VectorStore）、查出来（Advisor）。

数据在组件间以 Document 对象流转。它装着正文、元数据和可选的媒体内容，从读取到入库始终是同一个对象，链路清晰。

和微调、MCP 的分工

RAG 不是唯一的知识接入手段，和另外两个方案放在一起看，边界更清楚。

微调是让模型把知识”记在脑子里”，适合风格、格式、专业术语的固化。但它成本高、周期长，知识一变就要重训，不适合频繁更新的内容。

MCP（模型上下文协议）让模型按需调用外部工具和数据源，适合拿实时数据，比如股价、天气。RAG 查的是静态文档库，MCP 查的是动态服务，两者互补而不是替代。

RAG 的定位是私域静态知识：文档更新了，重跑一遍入库管道就行，模型本身不用动。知识量中等、更新频繁、答案要求可追溯的场景，RAG 是最划算的选择。

32.5 第一个 RAG 代码

先看一段最小可用的 RAG 代码，感受整体流程。前提是数据已经通过 ETL 管道存进了 VectorStore，这部分第 33 章讲。

import org.springframework.ai.chat.client.ChatClient;
import org.springframework.ai.chat.client.advisor.vectorstore.QuestionAnswerAdvisor;
import org.springframework.ai.vectorstore.VectorStore;

@Service
public class RagService {

    private final ChatClient chatClient;

    public RagService(ChatClient.Builder builder, VectorStore vectorStore) {
        QuestionAnswerAdvisor qaAdvisor = QuestionAnswerAdvisor.builder(vectorStore).build();
        this.chatClient = builder
                .defaultAdvisors(qaAdvisor)
                .build();
    }

    public String ask(String question) {
        return chatClient.prompt(question).call().content();
    }
}

用户问一句，QuestionAnswerAdvisor 就自动做一轮相似度检索，把结果塞进提示词。业务代码里看不到检索逻辑，这正是 Spring AI 的封装风格。

32.6 模块化 RAG 架构

简单场景用 QuestionAnswerAdvisor 够了。复杂场景需要更精细的控制，Spring AI 参考了模块化 RAG 论文的思路，把流程拆成四个阶段。

Pre-Retrieval（检索前）。 加工用户问题，让检索更准。问题太模糊就改写（Rewrite），太长就压缩（Compression），语言不匹配就翻译（Translation），还可以一次扩成多个问题（MultiQuery）。

Retrieval（检索）。 从向量库、搜索引擎、知识图谱等数据源取文档。Spring AI 里对应 VectorStoreDocumentRetriever，支持 topK、相似度阈值和元数据过滤。

Post-Retrieval（检索后）。 加工检索结果。文档多了会稀释重点，可以重排、去重、压缩内容，缓解”lost in the middle”问题——模型对中间位置的上下文记得最差。

Generation（生成）。 把处理好的上下文拼进提示词，交给模型。对应 ContextualQueryAugmenter，默认上下文为空时不让模型硬答，也可以放开。

这四个阶段对应 RetrievalAugmentationAdvisor 的四个配置入口。第 37 章会逐个演示。

32.7 RAG 不是银弹

RAG 解决”知识缺失”，但它也有代价。每次回答都要多一次检索，延迟变高。检索质量差时，喂给模型的上下文是错的，回答反而更糟。数据没切好，关键信息被切成两半，怎么都检索不到。

所以 RAG 系统的瓶颈常常不在模型，而在数据管道和检索质量。文档没切好、向量库选错、检索参数没调，都会直接拉低回答质量。这也是为什么接下来几章，ETL 管道、向量库接入、检索优化要挨个讲清楚。

32.8 小结

RAG 通过”先查资料再回答”解决大模型的三大短板。流程是检索、增强、生成三步，Spring AI 用 EmbeddingModel、VectorStore、DocumentReader、Splitter 和 Advisor 把每一步都封装成了可替换的组件。下一章看数据怎么进向量库，也就是 ETL 管道。