RAG 综述（Gao et al. 2023）：把「检索 + 生成」这件事范式化

关联论文：2312.10997
作者：flyP
更新：2026-08-05（Jay 精修二读）

这是 2023 年下半年最被广泛引用的 RAG 综述。它给出的最大遗产不是某条具体公式，而是 「Naive / Advanced / Modular」三阶段范式 与 「Retrieval / Generation / Augmentation」三支柱矩阵——任何一个想做 RAG 的团队都可以拿这两张图当白板来对照自家系统。这是把 RAG 从一堆 trick 变成一门工程学科的关键论文。

一句话结论

本文系统梳理了 RAG 自 2020 年以来的演化，提出 三种范式（Naive RAG → Advanced RAG → Modular RAG）和 三大基础技术（检索、生成、增强），并配套了评测框架（RGB、RECKE、ARES 等）与未来研究方向。它把「在外面挂个向量数据库给 LLM 查」这件事讲成了一门有结构的方法论。

解决什么真问题

在 2023 年 ChatGPT 引爆行业之后，「RAG」几乎成了大模型应用的代名词——人人都在做，但人人做的都不一样：

有人塞 BM25，有人塞向量库；
有人 chunk 切到段落级，有人切到 token 级；
有人在检索后重排，有人直接 top-k 喂给 LLM；
有人 fusion 多个 query，有人直接让 LLM 自己改写 query。

学界和工程界急需一份统一语言和对照框架。本文回答的真问题是：

「我们都在做的 RAG，能不能像 CNN 那样有几条主线范式、几个基础模块、一套评测指标？本文试着给一份。」

核心方法（也就是论文的「结构」）

1. RAG 范式演进：Naive → Advanced → Modular

┌───────────────────────────────────────────────────────────────┐
│                                                                │
│  Naive RAG          Advanced RAG          Modular RAG         │
│  ──────────          ────────────          ───────────         │
│  Indexing        →   Pre-Retrieval     →   多种模块组合        │
│  Retrieval           Retrieval              (Rerank, Fusion,    │
│  Generation          Post-Retrieval           Memory, Routing)  │
│                       Generation                               │
└───────────────────────────────────────────────────────────────┘

Naive RAG（2020 年起）：最经典三步。RAG 范式始自 Lewis et al. 2020（RAG 论文），而非 2023。

Indexing:    文档 → 切 chunk → embedding → 向量库
Retrieval:   用户 query → embedding → top-k → chunks
Generation:  query + chunks → LLM → answer

局限： - 检索质量低（无 query 改写、无 hybrid search）； - 生成易幻觉（chunks 拼成长 prompt 后 LLM 注意力分散）； - 上下文塞得太多，token 成本飙升。

Advanced RAG（2023 上半年）：给 Naive 加零件。

Pre-Retrieval:    query 改写、HyDE、step-back prompting、query 分解
Retrieval:        hybrid (BM25 + dense)、small-to-big retrieval
Post-Retrieval:   rerank、context 压缩、citation 注入
Generation:       prompt 工程、instruction-tuning 反向影响检索器

关键贡献是把「优化信号贯穿整个流水线」：从 query 入口到生成出口，每一个环节都可调。这是今天所有「RAG 最佳实践」文章的祖系模板。

Modular RAG（2023 下半年开始）：把 Advanced RAG 拆成可替换模块，并允许非线性的检索-生成关系。

                   ┌──────────┐
                   │ Routing  │ ─► 选检索模块 / 选 LLM / 跳过
                   └──────────┘
        ┌─────────────┐    ┌─────────────┐
        │  Rerank     │    │  Fusion     │
        │  模块       │    │  模块       │
        └─────────────┘    └─────────────┘
                   ┌──────────┐
                   │ Memory   │ ─► 跨轮 / 跨 session 记忆
                   └──────────┘

Modular RAG 的两个标志性新能力： 1. Routing：根据 query 路由到「走 RAG」「走 LLM」「走工具调用」「走 SQL」等不同分支； 2. Memory 模块：把多轮对话、外部知识图谱、个人化记忆抽象为「可被 retrieve 的对象」，打破「chunk = 检索最小单位」的隐含假设。

2. 三大基础技术：Retrieval / Generation / Augmentation

论文把 RAG 系统抽象成三块支柱，每块都列了 2023 年的 SOTA 选项：

Retrieval（检索）

维度	选项
数据源	文本、表格、知识图谱、SQL、PDF/HTML、API 文档
切分粒度	token / sentence / paragraph / semantic chunk
Embedding	BM25、稀疏学习（SPLADE）、稠密（Contriever、E5、BGE）、ColBERT-style late interaction
索引	FAISS、HNSW、Pinecone、Milvus、Qdrant、Weaviate
检索范式	single-hop、multi-hop、step-wise、tree-like

Generation（生成）

LLM 选型：开源（Llama、Qwen、Mistral）vs 闭源（GPT-4、Claude）；
上下文管理：Lost-in-the-Middle、context 压缩、citation-aware generation；
输出控制：fact-grounding、refusal、structured output。

Augmentation（增强）

检索前：query 改写、HyDE、step-back、CoT-augmented；
检索后：reranking、compression、citation insertion；
训练时：retriever 与 generator 联合训练（如 RAG-Token、RAG-Sequence、Atlas、REALM）。

这张矩阵是本文对工程界最大贡献：你不再需要从零设计「我的 RAG 系统长啥样」，对着三个轴填具体方案就是一张可对比的图。

3. 评测框架

论文系统梳理了 2023 年的 RAG 评测方法，分为三类：

下游任务质量：QA 准确率、MultiHop、TriviaQA、HotpotQA 等传统 benchmark；
检索质量：Recall@k、MRR、NDCG，标准 IR 指标；
RAG-specific： - RGB（2024，论文配套提出）：把评测拆为「噪声鲁棒性、负面拒答、信息集成、反事实鲁棒性」四个轴； - RECKE（2023）：检索增强的事实核查，评估 RAG 在事实性核查任务上的表现； - ARES（2023）：用 LLM-as-judge 自动评估 RAG 三组件； - RAGAS（2023）：开源自动化评测框架，含 faithfulness、answer relevance、context relevance 三指标（⚠️ RAGAS 全称原文未明确给出，此处据官方 repo 展开为 Retrieval-Augmented Generation Assessment，实际请以作者官方定义为准）。

4. 关键论点

RAG vs Long Context：本文主张 RAG 与长上下文并非二选一，而是互补——RAG 提供「可追溯的精确知识」，长上下文提供「整体阅读感」，最佳系统应两者结合（Self-RAG、GraphRAG 等都属于这条路线）。
RAG 的三大挑战：噪声鲁棒性（retrieved chunks 不一定有用）、极端负样本拒答、跨 chunk 推理（multi-hop）。后续研究几乎都围绕这三个轴展开。

亮点与局限

亮点

范式化贡献：Naive / Advanced / Modular 三分法迅速成为学界与工业界的默认语言。v5 持续维护，是该方向最常被引用的 RAG 综述（⚠️ 原文引用量未逐篇核实，3700+ 为摘要口径，2023年12月发表的论文在 Aug 2026 前的实际被引量请以 Semantic Scholar 实时数据为准）。
结构化抽象：Retrieval / Generation / Augmentation 三轴可填表的设计，使读者可以在 5 分钟内定位自己的 RAG 系统属于哪一档。
评测配套：在介绍方法的同时，把「怎么测」也讲到——这是综述类论文中较少见的工程化做法。
持续维护：v1 (2023-12-18) 到 v5 (2024-03-27)，作者持续更新，吸纳同期最新工作（GraphRAG、Self-RAG、RAGAS、ARES 等）。这是一份活的综述。

局限

覆盖偏向 2023：v5 截止 2024-03 之后出现的多代理 RAG（Agentic RAG）、GraphRAG、HybridRAG、长上下文 RAG 等热门方向只是简单提及，未深入对比。
重「形」轻「理」：本文作为综述几乎不推导数学，主要是分类与归纳。如果你想要「为什么 RAG 能 work」的 deep theory，需要另看其他文献（如 Retrieval-Augmented Classification、Atlas 的可解释性研究）。
评测方法以英语为主：所有主流 benchmark 都基于英语任务，中文 RAG 评测（CRUD、ChineseRC、CMRC）覆盖薄弱。
系统视角偏浅：对生产 RAG 的运维（监控、A/B、缓存、增量更新、权限隔离、token 经济）几乎未提，更多停留在研究侧。
不深入分析 retriever vs LLM 的耦合：后续工作（如 Self-RAG、RA-DIT）证明检索器与生成器联合训练是显著提升的关键，本文未在这一点上展开。

对工程落地的启发

「三阶段 + 三轴」是你的 RAG 蓝图。任何 RAG 系统都可以画成「属于 Naive/Advanced/Modular 哪一档」「在检索/生成/增强三轴上各用哪种模块」。这张图直接驱动技术选型与团队分工。
Pre-Retrieval 与 Post-Retrieval 是性价比最高的优化带。事实是：绝大多数 Naive RAG 的失败不是 embedding 模型不行，而是 query 没改写好、rerank 没加、context 没压缩。从这两个口进去改 1 周，往往比换一个更强的 embedding 模型收益大。
Routing 模块是「从 RAG 到 AI Agent」的桥。当 query 类型多样时，Modular RAG 的 routing 直接就是 agent 的 dispatcher。Self-RAG、FLARE、GraphRAG 都可以理解为「带特殊 routing 策略的 Modular RAG」。
评测必须独立于产品。RAGAS、ARES 这类工具让你不用靠肉眼就能对比两版 prompt / 两版 chunk size。生产团队应该把评测当成 CI 的一环。
「RAG vs Fine-tuning vs Long Context」三选一是个伪问题。本文的实际口径是组合： - RAG 提供事实与可追溯性； - Fine-tuning 提供风格与格式； - Long Context 提供整体推理；

真正的工程问题是「在每一类任务上这三个的比例怎么配」。

与同方向工作的关系

直接上游：
REALM (Guu et al., 2020)：把 retrieval 与 LM 联合预训练；
RAG (Lewis et al., 2020)：end-to-end RAG 模型，被本文当作范式起点；
Atlas (Izacard et al., 2022)：few-shot retrieval-augmented LM；
RETRO (Borgeaud et al., 2022)：DeepMind 的检索增强 LM。
同期综述：
「A Survey on RAG」系列：本文是该方向最常被引用的版本，但同期还有 Zhao et al.「A Survey of Large Language Models」、Mialon et al.「Augmented Language Models」等互补综述。
直接下游 / 同代：
Self-RAG (2024)：在 Modular RAG 上加 self-reflection；
GraphRAG (Microsoft, 2024)：用知识图谱替代/补充向量库；
RAGAS / ARES / CRUD-RAG：评测工具；
Agentic RAG (2024-2025)：把 RAG 推到 agent 决策链里；
CRAG、Corrective-RAG (2024)：在 Modular 框架上加自纠错。

适合谁读

RAG 应用工程师：必读。三阶段 + 三轴就是你做技术选型和方案评审的语言。
AI 产品经理：读完前两章就能和工程师在「为什么我们不上 GraphRAG」这种话题上对话。
LLM 研究者：可作为索引，把 100 多篇 RAG 论文按三大模块对号入座。
教学场景：作为 RAG 入门综述非常合适，但建议同时配一篇应用实战文章（如 LlamaIndex 官方 cookbook）补足工程视角。

不确定处

各 RAG 方法在 RAGAS / RGB / ARES 上的具体得分本解读未逐项核对，文中给出的「RAG-specific 评测框架」主要是 2023 下半年到 2024 上半年的快照，原文 v5 的最终表格请回查论文 Table 2–Table 5。
「Modular RAG」的提出时间与首篇引用本文原文未在抓到的 abstract 中明确指认，业内普遍把 v3/v4 (2024-01) 视作该范式首次正式命名。
不同 RAG 范式的 token 经济（平均 prompt 长度 / 延迟 / 单次成本）原文未做系统 benchmark，本文中提到的「上下文塞得太多，token 成本飙升」属于观察性表述，不是数字结论。
引用量 3700+ 未逐篇核实，2023年12月发表的综述至 Aug 2026 约两年半积累，实时数据请以 Semantic Scholar 为准。

工程落地与核查（Jay）

生产 RAG 的五大工程坑

坑1：增量索引的 cache 失效

向量库增量更新（新增文档、删除文档）后，HNSW/IVF 等索引结构不会自动重建。旧文档的向量仍存在于图中，导致已删除内容仍被检索到。解法：定期重建索引，或使用可追加的 HNSW 变体（如 hnswlib 支持 batch 追加但需定期 optimize）。

# 用 hnswlib 做增量索引 + 定期重建
python -c "
import hnswlib
import numpy as np

# 初始化索引（dim=768, ef_construction=200, M=16）
idx = hnswlib.Index(space='cosine', dim=768)
idx.init_index(max_elements=100000, ef_construction=200, M=16)

# 增量追加（生产中定期执行，勿每条追加）
idx.add_items(new_vectors, new_ids)
# 新增数据 >10% 时触发重建，否则 recall 下降
# idx.set_ef(ef=256) # 查询时增大 ef 提升 recall
"

坑2：chunk size 与 recall 的隐性取舍

chunk 太大 → 上下文膨胀、token 成本高、Lost-in-the-Middle；chunk 太小 → 跨 chunk 推理失败（multi-hop）、上下文关联丢失。经验值：512 tokens 重叠 50 tokens 是大多数 QA 场景的起点，再按 recall@5 调优。

# 用 llama-index 快速验证不同 chunk size 的 recall
python -c "
from llama_index import SimpleDirectoryReader
from llama_index.text_splitter import TokenTextSplitter

splitter = TokenTextSplitter(chunk_size=512, chunk_overlap=50)
# 文档越多、领域越专业，chunk size 的敏感性越高
# 建议：跑 3 种 chunk_size (256/512/1024)，用 RAGAS faithfulness 对比
"

坑3：Hybrid Search 的稠密/稀疏权重是玄学

BM25 + dense embedding 的线性组合 score = alpha * bm25 + (1-alpha) * dense，alpha 全靠人工调，没有系统性方法。解法：用 RAGAS answer_relevance 搭 grid search，alpha 从 0.1 到 0.9 跑一遍选最优。

坑4：Rerank 引入的延迟

Cross-Encoder rerank 精度高但延迟大（通常 50-200ms/query）。生产解法：bi-encoder 粗排 top-100 → Cross-Encoder 精排 top-10，而非直接全量 Cross-Encoder。

坑5：向量漂移（Drift）

Embedding 模型更新后，旧向量与新向量不在同一语义空间，检索结果系统性偏移。解法：模型版本与向量库版本绑定，模型升级时重建向量库（或用「新向量追加、旧向量静默」的策略）。

最小可跑命令

# 用 LangChain + Chroma 搭一个 Advanced RAG（Pre-Retrieval query改写 + Rerank）
pip install langchain chromadb sentence-transformers rank_bm25 transformers

python << 'EOF'
from langchain_community.retrievers import BM25Retriever
from langchain_community.embeddings import SentenceTransformerEmbeddings
from langchain_community.vectorstores import Chroma
from langchain.retrievers import ContextualCompressionRetriever
from langchain.retrievers.document_compressors import CrossEncoderReranker
from langchain_community.document_compressors import CohereRerank
import os

# 1. Hybrid retrieval (BM25 + dense)
bm25_retriever = BM25Retriever.from_texts(texts, k=20)
embedding = SentenceTransformerEmbeddings(model_name="all-MiniLM-L6-v2")
vectorstore = Chroma.from_texts(texts, embedding, persist_directory="./chroma_db")
dense_retriever = vectorstore.as_retriever(search_kwargs={"k": 20})

# 2. Pre-Retrieval: query rewriting (用小模型做 query expansion)
# 生产建议替换为 GPT-4o / Claude-3.5 做 query expansion，效果明显好于小模型

# 3. Rerank: Cross-Encoder 精排 top-10
# 推荐用 Cohere（API key 需配置）或本地 HuggingFace Cross-Encoder
compressor = CohereRerank(top_n=10, cohere_api_key=os.environ["COHERE_API_KEY"])
compression_retriever = ContextualCompressionRetriever(
    base_compressor=compressor,
    base_retriever=dense_retriever
)

# 查询示例
docs = compression_retriever.invoke("用户关于 XX 问题的具体政策是什么")
print(docs[0].page_content[:200])
EOF

核查清单（部署 RAG 前必过）

检查项	状态
向量库版本与 embedding 模型版本绑定
有增量文档时的索引重建策略
不同 chunk_size 的 recall@5 基准数据
RAGAS faithfulness / answer_relevance 基线
BM25+dense 的 alpha 权重已 grid search 选定
Cross-Encoder rerank 延迟已压测（p99<200ms）
已删除文档的向量已清除（非仅软删除）
Citation 溯源链路完整（生产级必须）