RAG 架构

原始素材：8-人工智能/8.11-rag.md

前言

为什么 ChatGPT 有时候会"一本正经地胡说八道"？ 大语言模型的知识来自训练数据，但训练数据有截止日期，也不包含你公司的内部文档。RAG（Retrieval-Augmented Generation，检索增强生成）就是解决这个问题的核心技术——让 AI 在回答之前，先去"查资料"。

这篇文章会带你学什么？

学完这章后，你将获得：

核心概念理解 ：明白 RAG 是什么、为什么需要它，以及它如何解决大模型的"幻觉"问题
完整流程认知 ：掌握从文档加载、分块、向量化到检索、生成的端到端流程
技术选型能力 ：了解不同分块策略、检索方法的优劣，能根据场景做出选择
架构演进视角 ：理解 RAG 从 Naive 到 Advanced 再到 Modular 的演进路线
实践决策能力 ：知道什么时候该用 RAG、什么时候该用微调

章节	内容	核心概念
第 1 章	RAG 基础流程	索引、检索、生成三阶段
第 2 章	文本分块策略	固定分块、语义分块、递归分块
第 3 章	检索技术	向量检索、关键词检索、混合检索
第 4 章	架构演进	Naive RAG → Advanced RAG → Modular RAG
第 5 章	RAG vs 微调	两种方案的适用场景对比

0. 全景图：为什么大模型需要"查资料"？

想象你是一个博学的教授，读过无数书籍。但如果有人问你"昨天公司的销售数据是多少"，你肯定答不上来——因为这些信息不在你读过的书里。

大语言模型面临的就是同样的困境：

知识有截止日期 ：GPT-4 的训练数据截止到某个时间点，之后发生的事它不知道
缺乏私有知识 ：你公司的内部文档、产品手册、客户数据，模型从未见过
容易产生幻觉 ：当模型不确定答案时，它倾向于"编造"一个看起来合理的回答

RAG 的核心思想

RAG 的解决方案非常直觉：在让模型回答之前，先帮它找到相关的参考资料 。就像开卷考试——你不需要记住所有知识，只需要知道去哪里找、怎么找。

RAG = 检索（Retrieval）+ 增强（Augmented）+ 生成（Generation）

1. RAG 基础流程：索引、检索、生成

RAG 的工作流程可以分为两个阶段：离线索引 和在线查询 。

离线阶段就像图书馆的编目工作——把所有书籍分类、编号、上架，方便日后查找。在线阶段则是读者来图书馆查资料的过程——根据问题找到相关书籍，然后综合信息给出回答。

三个核心阶段

索引阶段（Indexing） ：将原始文档加载、清洗、分块，然后通过嵌入模型转化为向量，存入向量数据库。这是一次性的准备工作。
检索阶段（Retrieval） ：用户提问时，将问题也转化为向量，在向量数据库中搜索最相似的文档片段。
生成阶段（Generation） ：将检索到的文档片段和用户问题一起拼接为 Prompt，交给大模型生成最终回答。

阶段	输入	输出	关键技术
索引	原始文档	向量数据库	文本分块、嵌入模型
检索	用户问题	Top-K 文档片段	向量相似度、重排序
生成	问题 + 上下文	最终回答	Prompt 工程、LLM

2. 文本分块：把大象装进冰箱

文本分块是 RAG 中最容易被忽视、却对效果影响最大的环节。为什么需要分块？因为大模型的上下文窗口有限，我们不可能把整本书塞进去。更重要的是，分块的质量直接决定了检索的质量 。

想象你在图书馆找一本书的某个知识点。如果整本书是一个"块"，检索到了也没用——你还是得翻遍全书。但如果按章节甚至段落分块，就能精准定位到你需要的内容。

分块演示：输入文本 使用示例文本 — 策略：固定大小（块大小 80 字符，重叠 20 字符）— 分块结果：0 个块

分块策略	优点	缺点	适用场景
固定大小分块	简单直接，实现成本低	可能切断语义	快速原型、简单文本
递归分块	保持语义完整性	实现稍复杂	通用场景（推荐起步方案）
语义分块	语义边界最准确	依赖嵌入模型，成本较高	高质量检索要求
文档结构分块	利用原生结构信息	依赖文档格式规范	Markdown/HTML 文档

没有"最好"的分块策略，只有最适合你数据的策略。一般建议从递归分块开始，chunk 大小 200-500 tokens，overlap 10-20%。

3. 检索技术：如何找到最相关的内容？

分块完成后，下一个关键问题是：用户提了一个问题，怎么从成千上万个文档片段中找到最相关的那几个？

这就像在一个巨大的图书馆里找书。你可以按书名关键词搜索（关键词检索），也可以描述你想要的内容让图书管理员帮你找（语义检索），最好的方式是两者结合（混合检索）。

检索 Pipeline：1. 查询编码 → 2. 向量搜索 → 3. 重排序 → 4. Top-K 选择

示例查询：如何申请年假？ | Redis 缓存穿透怎么解决？

以「查询编码」为例：将自然语言通过嵌入模型（如 text-embedding-ada-002）转化为高维向量。

步骤	输入	输出
① 查询文本	"如何申请年假？"	—
② 嵌入模型编码	↓	查询向量 `[0.12, -0.45, 0.78, 0.33, -0.21, 0.56, 0.89, -0.14, ...]`

检索方式	原理	优势	劣势
关键词检索（BM25）	基于词频和逆文档频率	精确匹配、速度快	无法理解语义、同义词失效
向量检索	基于嵌入向量的余弦相似度	理解语义、支持模糊匹配	对专有名词不敏感
混合检索	融合关键词和向量检索结果	兼顾精确和语义	需要调权重、复杂度高

重排序（Reranking）

检索到候选文档后，通常还需要一步"重排序"。初始检索追求召回率（尽量不遗漏），重排序追求精确率（把最相关的排到最前面）。常用的重排序模型有 Cohere Rerank、BGE Reranker 等，它们使用交叉编码器对 query-document 对进行精细打分。

4. 架构演进：从简单到智能

RAG 技术在短短两年内经历了三代演进，每一代都在解决上一代的痛点。

RAG 架构演进：v1 Naive RAG (2023) → v2 Advanced RAG (2024) → v3 Modular RAG (2025)

以「v1 Naive RAG」为例：最基础的 RAG 架构，流程简单直接：文档加载 → ✂️ 文本分块 → 向量化 → 检索 → 生成

✅ 优势	⚠️ 局限
实现简单，上手快	检索质量依赖分块策略
适合结构化知识库	无法处理复杂查询

三代 RAG 架构对比

Naive RAG（2023） ：最基础的"索引→检索→生成"流程，实现简单但效果有限。问题包括：检索质量不稳定、无法处理复杂查询、容易引入噪音上下文。
Advanced RAG（2024） ：在 Naive RAG 基础上增加了查询改写、混合检索、重排序、上下文压缩等优化环节，显著提升了检索精度和生成质量。
Modular RAG（2025） ：将 RAG 拆解为可插拔的模块，支持路由判断、自适应检索、自我反思等高级能力。可根据查询类型动态选择最优处理流程。

5. RAG vs 微调：该选哪个？

当你想让大模型掌握特定领域的知识时，通常有两条路：RAG 和微调（Fine-tuning）。它们不是互斥的，而是互补的。

打个比方：微调像是让学生上培训班 ，把知识内化到大脑里；RAG 像是给学生发参考书 ，考试时可以翻阅。两种方式各有优劣，关键看你的具体需求。

RAG vs 微调对比：维度对比 | 场景推荐

维度	RAG（检索增强生成）	Fine-tuning（微调）
知识更新速度	实时更新，修改文档即生效	需要重新训练，周期长
实施成本	搭建检索系统，成本适中	需要 GPU 资源和标注数据
回答风格控制	依赖 Prompt 工程	可深度定制输出风格
幻觉控制	有据可查，可追溯来源	仍可能产生幻觉
推理延迟	需要额外的检索步骤 ⏱️	直接生成，无额外开销
私有数据安全	数据留在本地，不进入模型	数据融入模型权重

一句话总结：RAG 像是给模型配了一个实时更新的参考书库，适合知识频繁变化的场景；微调像是让模型上了一门专业课，适合需要特定风格或领域深度的场景。实际项目中，两者常常结合使用。

维度	RAG	微调
知识更新	实时更新，改文档即可	需要重新训练
成本	低（无需 GPU 训练）	高（需要训练资源）
可解释性	高（可追溯来源）	低（知识内化在权重中）
适用场景	知识库问答、文档检索	风格迁移、特定任务优化
幻觉控制	较好（有参考依据）	一般（仍可能幻觉）

实践建议

大多数场景下，先试 RAG 。RAG 的优势在于：不需要训练、知识可实时更新、回答可追溯来源。只有当你需要改变模型的"行为模式"（比如输出格式、语言风格、推理方式）时，才考虑微调。最强的方案往往是 RAG + 微调 的组合。

总结

RAG 是当前让大模型"落地"最实用的技术之一。它的核心价值在于：让模型的回答有据可查、知识可实时更新、幻觉可有效控制。

回顾本章的关键要点：

RAG 解决的核心问题 ：大模型知识过时、缺乏私有数据、容易幻觉
三阶段流程 ：索引（离线准备）→ 检索（在线查找）→ 生成（综合回答）
分块是基础 ：分块质量直接决定检索质量，选择合适的分块策略至关重要
检索是关键 ：混合检索 + 重排序是目前效果最好的组合
架构在演进 ：从 Naive RAG 到 Modular RAG，系统越来越智能和灵活
RAG 和微调互补 ：大多数场景先试 RAG，需要改变模型行为时再考虑微调