RAG 完全指南：从基础概念、核心流程到 Advanced RAG 与 Modular RAG

RAG 完全指南：从基础概念、核心流程到 Advanced RAG 与 Modular RAG -- pd的后端笔记

文章目录

- [RAG 完全指南：从基础概念、核心流程到 Advanced RAG 与 Modular RAG -- pd的后端笔记](#RAG 完全指南：从基础概念、核心流程到 Advanced RAG 与 Modular RAG -- pd的后端笔记)
[什么是 RAG？](#什么是 RAG？)
- [🎯 一、RAG 到底解决了什么问题？](#🎯 一、RAG 到底解决了什么问题？)
- [🚀 二、RAG 的主要流程是什么？](#🚀 二、RAG 的主要流程是什么？)
- - 这个流程为什么有效？
- [🧠 三、RAG 的完整流程是怎么样的？](#🧠 三、RAG 的完整流程是怎么样的？)
- [1. 离线阶段：把知识变成"可检索"](#1. 离线阶段：把知识变成“可检索”)
- - [① 数据采集（Ingestion）](#① 数据采集（Ingestion）)
  - [② 数据清洗（Cleaning）](#② 数据清洗（Cleaning）)
  - [③ 文档切块（Chunking）](#③ 文档切块（Chunking）)
  - [④ 元数据提取（Metadata Enrichment）](#④ 元数据提取（Metadata Enrichment）)
  - [⑤ 向量化与建索引（Embedding + Indexing）](#⑤ 向量化与建索引（Embedding + Indexing）)
- [2. 在线阶段：把问题变成答案](#2. 在线阶段：把问题变成答案)
- - [① Query 理解与改写](#① Query 理解与改写)
  - [② Retriever 召回](#② Retriever 召回)
  - [③ Rerank 重排](#③ Rerank 重排)
  - [④ 上下文筛选与压缩](#④ 上下文筛选与压缩)
  - [⑤ Prompt Augmentation](#⑤ Prompt Augmentation)
  - [⑥ LLM 生成](#⑥ LLM 生成)
  - [⑦ 答案后处理与评估](#⑦ 答案后处理与评估)
- [📊 四、用一张图看懂 RAG 的完整生命周期](#📊 四、用一张图看懂 RAG 的完整生命周期)
- [🔧 五、什么是 Naive RAG？](#🔧 五、什么是 Naive RAG？)
- [🚀 六、什么是 Advanced RAG？](#🚀 六、什么是 Advanced RAG？)
- - [Advanced RAG 的核心目标](#Advanced RAG 的核心目标)
  - [1. 检索前增强](#1. 检索前增强)
  - [2. 检索阶段增强](#2. 检索阶段增强)
  - [3. 生成阶段增强](#3. 生成阶段增强)
  - 典型代表思路
  - [为什么说它比 Naive RAG 更强？](#为什么说它比 Naive RAG 更强？)
- [🧩 七、什么是 Modular RAG？](#🧩 七、什么是 Modular RAG？)
- - [Modular RAG 的核心思想](#Modular RAG 的核心思想)
  - [它和 Advanced RAG 的区别是什么？](#它和 Advanced RAG 的区别是什么？)
  - - [1. Advanced RAG 更像"增强版流水线"](#1. Advanced RAG 更像“增强版流水线”)
    - [2. Modular RAG 更像"可编排系统"](#2. Modular RAG 更像“可编排系统”)
  - [为什么 Modular RAG 越来越重要？](#为什么 Modular RAG 越来越重要？)
- [📊 八、Naive RAG、Advanced RAG、Modular RAG 对比](#📊 八、Naive RAG、Advanced RAG、Modular RAG 对比)
- [⚠️ 九、RAG 最容易踩的几个坑](#⚠️ 九、RAG 最容易踩的几个坑)
- - [误区 1：把 RAG 理解成"加个向量库就结束"](#误区 1：把 RAG 理解成“加个向量库就结束”)
  - [误区 2：检索越多越好](#误区 2：检索越多越好)
  - [误区 3：检索到了，模型就一定会用](#误区 3：检索到了，模型就一定会用)
  - [误区 4：所有场景都适合 RAG](#误区 4：所有场景都适合 RAG)
- [✅ 十、项目落地时怎么选？](#✅ 十、项目落地时怎么选？)
- - [场景 1：刚开始做知识库问答](#场景 1：刚开始做知识库问答)
  - [场景 2：已经能答，但准确率和稳定性一般](#场景 2：已经能答，但准确率和稳定性一般)
  - [场景 3：一个系统要支持多种知识任务](#场景 3：一个系统要支持多种知识任务)
- [🗣️ 十一、如果面试官问"什么是 RAG，Advanced RAG 和 Modular RAG 有什么区别？"](#🗣️ 十一、如果面试官问“什么是 RAG，Advanced RAG 和 Modular RAG 有什么区别？”)
- [📚 十二、几篇关键资料怎么对应理解？](#📚 十二、几篇关键资料怎么对应理解？)
- [📌 总结：一句话记住这四个问题](#📌 总结：一句话记住这四个问题)
- - [1. 什么是 RAG？](#1. 什么是 RAG？)
  - [2. RAG 的主要流程是什么？](#2. RAG 的主要流程是什么？)
  - [3. RAG 的完整流程是什么？](#3. RAG 的完整流程是什么？)
  - [4. 什么是 Advanced RAG 与 Modular RAG？](#4. 什么是 Advanced RAG 与 Modular RAG？)
- [🔗 参考资料](#🔗 参考资料)

什么是 RAG？

如果你最近在做 LLM 应用，几乎一定会遇到一个经典矛盾：

模型会说，但不一定"说得对"
模型很强，但知识可能过期
模型能回答通用问题，但一到企业私有知识、垂直领域知识，立刻就容易"胡编"

这就是为什么 RAG 变成了今天 AI 应用落地里的高频关键词。

简单说：

RAG（Retrieval-Augmented Generation，检索增强生成），就是在模型生成答案之前，先去外部知识库里"查资料"，再把查到的资料连同问题一起交给大模型生成答案。

它不是只靠模型参数里的"记忆"来回答，而是把 参数化知识（Parametric Knowledge） 和 外部非参数知识（Non-parametric Memory） 结合起来。

这也是 Lewis 等人在 2020 年原始 RAG 论文里的核心思想：

大模型负责理解、推理、组织语言
外部检索系统负责提供最新、可更新、可追溯的知识

所以你可以把 RAG 理解成一句话：

让 LLM 不再"闭卷考试"，而是先开卷检索，再基于证据作答。

🎯 一、RAG 到底解决了什么问题？

RAG 之所以火，不是因为它名字新，而是因为它真的打中了 LLM 落地中的几个核心痛点。

问题	纯 LLM 的典型表现	RAG 的价值
幻觉（Hallucination）	看起来很像真的，但其实是编的	用检索到的证据约束回答
知识过期	模型训练截止后发生的事情不知道	知识库可实时更新
私域知识缺失	企业文档、内部制度、项目资料不了解	接入内部知识库即可增强
可追溯性差	很难回答"你依据什么说的？"	可附带引用来源
微调成本高	每次知识更新都去微调成本太高	主要更新索引与文档，不必频繁训模型

所以，RAG 最常见的落地场景包括：

企业知识库问答
客服机器人 / 智能助手
法务、金融、医疗等高知识密度领域问答
代码库问答 / 文档问答
报告生成、调研总结、带引用的内容生成

🚀 二、RAG 的主要流程是什么？

如果你只想先抓住最核心的主干，那 RAG 的最小闭环其实只有 3 步：

接收用户问题
去知识库中检索相关内容
把"问题 + 检索结果"一起交给 LLM 生成答案

这就是最经典的 Retrieve -> Augment -> Generate。
用户问题
Retriever 检索器
相关文档片段 Top-K
Prompt Augmentation 提示增强
LLM 生成答案
返回结果 / 引用

这个流程为什么有效？

因为它把任务拆成了两个更擅长的子问题：

检索器 擅长"从海量知识里找相关证据"
生成器 擅长"理解问题、组织语言、整合上下文"

换句话说：

检索负责"找对资料"，生成负责"讲清答案"。

这也是 RAG 的本质分工。

🧠 三、RAG 的完整流程是怎么样的？

很多人第一次学 RAG，只看到在线问答阶段：

用户提问
检索文档
模型回答

但如果你真的要把 RAG 系统做成一个可上线、可维护、可扩展的工程系统，你会发现它其实至少分成两大阶段：

离线知识准备阶段（Offline Indexing）
在线问答生成阶段（Online Retrieval + Generation）

也就是说，真正完整的 RAG 不是一条短链路，而是一套"知识摄取 + 索引构建 + 在线检索 + 上下文组装 + 生成 + 评估反馈"的闭环系统。

1. 离线阶段：把知识变成"可检索"

离线阶段的目标只有一个：

把原始资料，处理成能被高效、准确召回的索引。

典型步骤如下：

① 数据采集（Ingestion）

知识源可能来自：

PDF / Word / Markdown / 网页
内部 Wiki / Confluence / Notion
数据库记录
API 返回结果
代码仓库 / 设计文档 / FAQ

② 数据清洗（Cleaning）

这一步通常会处理：

去噪声
去页眉页脚
去 HTML 标签
规范换行和标题层级
过滤重复文档

如果这一步做不好，后面检索召回会被"垃圾上下文"污染。

③ 文档切块（Chunking）

这是 RAG 系统最容易被低估、却最影响效果的一步。

因为大模型不能一次吞下整本手册，所以要把长文档切成较小片段（chunk）。

常见切块策略：

固定长度切块
滑动窗口切块
按标题/段落语义切块
结构化切块（章节、问答、表格、代码块分离）
父子块（Parent-Child Chunk）

④ 元数据提取（Metadata Enrichment）

给 chunk 打标签，例如：

文档标题
来源 URL
时间戳
作者
部门
文档类型
权限范围
章节路径

这一步的价值在于：

检索时可做过滤（例如只查某部门文档）
答案可回溯来源
后续 rerank 与召回融合更容易做

⑤ 向量化与建索引（Embedding + Indexing）

把 chunk 编码成向量，写入向量数据库或检索引擎，例如：

FAISS
Milvus
Weaviate
pgvector
Elasticsearch / OpenSearch（混合检索场景）

此时，知识才真正变成"可检索资产"。

2. 在线阶段：把问题变成答案

当用户提问后，RAG 系统真正开始工作。
原始问题
问题理解 / Query Rewrite
Retriever 召回
Reranker 重排
上下文筛选 / 压缩
Prompt 组装
LLM 生成
答案校验 / 引用附着
返回用户
日志 / 反馈 / 评估

下面我们逐层拆开。

① Query 理解与改写

很多时候，用户的问题并不适合直接拿去搜。

比如用户问：

"那个政策里关于试用期社保怎么说？"

这类问题有几个隐患：

关键词不完整
指代不清（"那个政策"是哪一个？）
表达口语化，不像检索 query

所以在线阶段第一步，往往不是立刻检索，而是：

query rewrite（问题改写）
query expansion（问题扩展）
multi-query（生成多个检索子问题）
意图识别 / 路由
时间、权限、部门条件补齐

② Retriever 召回

这一步负责从候选知识中捞出 Top-K 相关片段。

常见召回方式：

召回方式	原理	优点	局限
稀疏检索（BM25）	关键词匹配	快、可解释性强	语义泛化弱
稠密检索（Dense Retrieval）	向量相似度	语义匹配能力强	对 embedding 质量敏感
混合检索（Hybrid Search）	关键词 + 向量	兼顾召回率与精度	系统更复杂

③ Rerank 重排

Top-K 召回出来，并不代表顺序就是最优的。

所以很多高质量 RAG 都会加一层 Reranker：

先粗召回更多候选
再用更贵但更准的模型做重排
把最相关的片段放进有限上下文窗口

这是非常典型的工程思路：

第一阶段追求 Recall，第二阶段追求 Precision。

④ 上下文筛选与压缩

不是检索越多越好。

如果把一堆重复、无关、互相冲突的文本塞进 prompt，反而会出现：

关键信息被淹没
上下文窗口浪费
模型注意力分散
成本上升，答案还变差

所以在线阶段往往还会做：

去重
冲突段过滤
长文压缩
证据摘要
token budget 控制
按问题动态选择片段

⑤ Prompt Augmentation

这一步是"把检索证据组织成模型能吃的上下文"。

典型 prompt 结构可能是：

系统角色说明
用户问题
检索证据块
回答格式要求
是否必须引用来源
不知道时必须承认不知道

这一步决定的不是"有没有知识"，而是：

模型能不能正确使用这些知识。

⑥ LLM 生成

此时模型开始基于"问题 + 证据"生成答案。

生成阶段常见输出包括：

直接回答
带引用编号的回答
结构化 JSON
摘要 / 对比 / 报告
多轮对话式回答

⑦ 答案后处理与评估

真正成熟的系统通常不会在生成后直接结束，还会继续做：

引用附着
答案格式校验
敏感信息过滤
事实核验
用户反馈回收
线上日志分析
离线评测集回归

📊 四、用一张图看懂 RAG 的完整生命周期

在线问答生成
离线知识准备
知识库支持
文档采集
清洗与去噪
Chunk 切分
元数据增强
Embedding
索引构建 / 入库
用户问题
问题改写
召回 Retriever
重排 Reranker
上下文压缩
Prompt 组装
LLM 生成
引用 / 校验 / 返回
日志反馈与评估

到这里，你可以把完整 RAG 理解成：

离线阶段解决"知识怎么准备"，在线阶段解决"知识怎么被正确用起来"。

🔧 五、什么是 Naive RAG？

在讲 Advanced RAG 之前，要先有一个参照物。

所谓 Naive RAG（朴素 RAG），通常指最基础、最线性的 RAG 流程：

文档切块
建向量索引
用户提问
相似度检索 Top-K
把结果拼进 prompt
模型生成答案

它的优点很明显：

上手快
架构简单
原型验证成本低
很适合做第一个版本

但它的问题也同样明显：

query 不够好时，召回就容易偏
Top-K 片段可能相关但不够"最有用"
上下文长了会有噪声
没有多跳检索能力
没有自我校验与纠错能力
检索、生成、反馈之间基本是"单次直连"

所以朴素 RAG 通常能解决"有没有"的问题，却不一定能解决"好不好用"的问题。

🚀 六、什么是 Advanced RAG？

这里要特别说明一件事：

Advanced RAG 不是 Lewis 2020 原始论文里的标准术语。

它更常见于后续综述和工程讨论中，尤其是在 Gao 等人的 RAG Survey 里，RAG 被概括为 Naive RAG -> Advanced RAG -> Modular RAG 的演进路径。

所以，Advanced RAG 本质上不是某一个单独算法，而是一类"比朴素 RAG 更强"的增强型 RAG 设计。

Advanced RAG 的核心目标

一句话概括：

让"检索得更准、上下文更干净、生成更可信"。

它通常会在三个位置增强：

检索前增强（Pre-Retrieval）
检索中增强（Retrieval Stage）
生成前后增强（Post-Retrieval / Generation Stage）

1. 检索前增强

典型手段包括：

Query Rewrite
Query Expansion
Multi-Query Retrieval
HyDE(Hypothetical Document Embeddings) （先生成一个假设答案，再拿它去检索）
问题分解（复杂问题拆成多个子问题）

目标很直接：

别让用户原始问题直接决定检索质量，而是先把问题变成更适合召回的形式。

2. 检索阶段增强

这一步主要提升召回质量与证据覆盖度，例如：

Hybrid Search（BM25 + Dense）
多路召回融合
Reranker 重排
元数据过滤
Graph / KG 辅助检索
多跳检索（Multi-hop Retrieval）

3. 生成阶段增强

这一步主要解决"模型有没有正确使用证据"的问题，例如：

Context Compression
Evidence Selection
引用生成
自我反思 / 自我校验
迭代式检索生成
低置信度触发二次检索

典型代表思路

代表方向	核心思想	解决什么问题
Query Rewrite / Expansion	改写问题再检索	解决原始 query 太弱
Hybrid Retrieval	稀疏 + 稠密融合	同时提升关键词匹配与语义匹配
Reranking	二阶段重排	让有限上下文装入更优证据
Iterative / Active Retrieval	生成过程中按需继续检索	解决长文本、多跳、动态证据需求
Self-Reflection RAG	模型对证据和答案做反思	减少错误引用与低质量回答

为什么说它比 Naive RAG 更强？

因为朴素 RAG 的假设是：

"只要我检索到一些相关文本，模型自然就会用好它。"

而 Advanced RAG 认为这件事远没有那么简单：

检索结果可能相关但不充分
检索结果可能充分但排序不佳
排序不错但上下文过长
上下文不错但模型仍可能误用证据
模型甚至可能根本不需要检索，却被硬塞了一堆噪声

所以 Advanced RAG 的本质，是把"单次检索拼接"升级为"检索质量治理 + 上下文治理 + 生成可信度治理"。

🧩 七、什么是 Modular RAG？

如果说 Advanced RAG 强调的是"把单条链路做强"，那么 Modular RAG 强调的就是：

别把 RAG 看成一根固定水管，而要把它看成一组可自由拼装的能力模块。

这同样是 RAG survey 中的重要演进视角。

Modular RAG 的核心思想

它不再执着于固定流程：

Query -> Retrieve -> Generate

而是把 RAG 拆成若干独立模块，例如：

Query Router
Query Rewriter
Retriever
Hybrid Retriever
Reranker
Context Compressor
Memory Module
Tool Caller
Verifier
Citation Module
Feedback Loop
Knowledge Graph Retriever

这些模块可以按场景灵活组合，甚至形成：

分支
回路
条件触发
多跳推理链
多知识源融合

证据不足
证据充分
用户问题
Query Router
Query Rewrite
直接检索
Hybrid Retriever
Reranker
Context Compressor
LLM Generator
Verifier / Self-Check
最终答案 + 引用

它和 Advanced RAG 的区别是什么？

这是最容易混淆的一点。

1. Advanced RAG 更像"增强版流水线"

重点是把传统 RAG 的每一环做得更强：

召回更准
排序更好
上下文更干净
生成更可信

2. Modular RAG 更像"可编排系统"

重点不只是增强某一环，而是：

能不能按任务动态选择组件
能不能把检索、工具、记忆、验证、路由组合起来
能不能支持非线性、多阶段、可回环的执行路径

也就是说：

Advanced RAG 更关注"性能增强"，Modular RAG 更关注"系统架构与可编排性"。

为什么 Modular RAG 越来越重要？

因为真实业务不是只有一种问答。

例如同一个企业助手里，可能同时存在：

FAQ 类简单问答
需要 SQL 查询的数据问答
需要代码库检索的研发问答
需要知识图谱多跳推理的合规问答
需要长期对话记忆的 Copilot 场景

如果所有问题都走同一条 RAG 流水线，效果通常不会好。

所以 Modular RAG 适合做的是：

多场景统一平台
多知识源融合
工具调用 + RAG 混合系统
Agentic RAG / GraphRAG / Multi-hop RAG
需要长期演进的大型生产系统

📊 八、Naive RAG、Advanced RAG、Modular RAG 对比

维度	Naive RAG	Advanced RAG	Modular RAG
核心目标	先把 RAG 跑起来	提升检索与生成质量	让系统具备可组合、可扩展能力
典型流程	单次检索 + 单次生成	在线路上增加增强组件	把多个组件灵活编排成系统
架构形态	线性	更强的线性 / 轻度迭代	非线性、模块化、可回环
适合场景	Demo、POC、简单知识库	生产级高质量问答	复杂多场景平台化系统
主要问题	效果上限低	系统复杂度增加	协调成本、工程复杂度更高

所以三者不是"互相否定"的关系，而更像是一个演进谱系：

Naive RAG：先有
Advanced RAG：再变强
Modular RAG：再平台化、系统化

⚠️ 九、RAG 最容易踩的几个坑

误区 1：把 RAG 理解成"加个向量库就结束"

这是最常见的误解。

真正决定效果的，不只是向量库，而是整条链路：

chunk 怎么切
query 是否改写
召回是不是混合检索
是否有 rerank
上下文是否压缩
prompt 是否要求基于证据作答

误区 2：检索越多越好

错。

很多失败的 RAG，不是因为没检索到，而是因为检索太多、噪声太大。

误区 3：检索到了，模型就一定会用

也不对。

模型可能：

忽略证据
误读证据
错误整合多个片段
产生"看起来像引用、实际并不对应"的答案

误区 4：所有场景都适合 RAG

并不是。

如果问题本质上是：

需要事务型精确查询
需要执行工具 / API
需要长期状态记忆
需要复杂规划与多步动作

那你可能需要的是：

Tool Use
SQL Agent
Workflow Engine
Memory System
RAG + Agent 的混合架构

RAG 很强，但它不是万能胶。

✅ 十、项目落地时怎么选？

下面给一个非常实用的选择建议。

场景 1：刚开始做知识库问答

推荐：Naive RAG 起步，但预留升级接口

最小配置：

合理 chunking
embedding
向量检索
Top-K 拼接
明确的回答约束 prompt

场景 2：已经能答，但准确率和稳定性一般

场景 3：一个系统要支持多种知识任务

🗣️ 十一、如果面试官问"什么是 RAG，Advanced RAG 和 Modular RAG 有什么区别？"

你可以这样回答：

RAG 是检索增强生成，本质上是在 LLM 回答前先从外部知识库检索相关证据，再基于这些证据生成答案，用来缓解幻觉、知识过期和私域知识缺失问题。

最基础的 RAG 流程是：离线把文档切块、向量化并建索引；在线接收问题后做检索、上下文增强，再交给模型生成答案。

如果从系统演进看，Naive RAG 是最基础的单次检索加生成；Advanced RAG 是在 query 改写、混合检索、rerank、上下文压缩、自我反思等环节增强传统 RAG；Modular RAG 则更进一步，把 RAG 拆成多个可组合模块，让系统支持路由、工具调用、验证回环和多知识源编排，更适合复杂生产场景。

这段回答的好处是：

有定义
有流程
有演进脉络
有工程视角

面试里已经很够用了。

📚 十二、几篇关键资料怎么对应理解？

为了避免概念混淆，这里再帮你把几个术语和来源对应一下。

概念	更接近哪类来源	要点
RAG	Lewis et al., 2020 原始论文	提出参数化知识 + 非参数知识结合
Naive / Advanced / Modular RAG	Gao et al., RAG Survey	这是后续综述里的演进型分类
Active / Iterative RAG	FLARE 等工作	生成过程中按需继续检索
Self-Reflective RAG	Self-RAG 等工作	检索、生成、反思联合起来

所以要特别注意：

Advanced RAG / Modular RAG 更像"后来的系统分类视角"，不是最早 RAG 论文里的原生术语。

📌 总结：一句话记住这四个问题

1. 什么是 RAG？

RAG 就是：

先检索外部知识，再让 LLM 基于检索结果生成答案。

2. RAG 的主要流程是什么？

最小流程是：

问题 -> 检索 -> 上下文增强 -> 生成答案

3. RAG 的完整流程是什么？

完整流程包含两部分：

离线：采集、清洗、切块、向量化、建索引
在线：改写问题、召回、重排、压缩上下文、生成、校验、反馈

4. 什么是 Advanced RAG 与 Modular RAG？

Advanced RAG：把传统 RAG 做强，重点是检索质量、上下文质量、生成可信度
Modular RAG：把 RAG 做成可编排系统，重点是模块组合、动态路由、回环验证与系统扩展性

如果你只记一句话，可以记这个：

Naive RAG 是"能跑"，Advanced RAG 是"跑得更准"，Modular RAG 是"能支撑复杂生产系统持续演进"。

🔗 参考资料

Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks

https://arxiv.org/abs/2005.11401
Gao et al., Retrieval-Augmented Generation for Large Language Models: A Survey

https://arxiv.org/abs/2312.10997
Jiang et al., Active Retrieval Augmented Generation

https://arxiv.org/abs/2305.06983
Asai et al., Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection

https://arxiv.org/abs/2310.11511