一、RAG 的起源与核心思想

2020 年，Meta AI 研究团队（Lewis et al.）在 NeurIPS 发表论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》，首次提出了 RAG（Retrieval-Augmented Generation，检索增强生成）的完整框架。这篇论文的核心洞察是：将大规模语言模型的参数化知识与可更新的非参数化知识存储分离，通过检索机制动态获取外部知识。

传统的语言模型将知识编码在模型权重中，更新知识需要重新训练。RAG 打破了这一限制——检索组件负责从外部知识库中提取相关信息，生成组件负责基于检索结果组织回答。这意味着知识库可以独立于模型进行更新，而无需触达模型参数。

RAG 的架构包含三个核心环节的循环：

  1. 检索（Retrieval）：将用户查询编码为向量，在知识库中找出最相关的文档
  2. 增强（Augmentation）：将检索到的文档与原始查询一起注入生成模型的上下文
  3. 生成（Generation）：基于增强后的上下文，生成最终的回答

二、两种生成模式：RAG-Token 与 RAG-Sequence

原论文提出了两种生成变体，核心差异在于如何对多个检索文档做概率融合。

RAG-Sequence 的做法是：对每个文档分别生成完整回答，然后对所有文档的生成概率做边际化，最终输出概率最高的完整序列。这种模式保守、稳健，适合需要强一致性回答的场景。

RAG-Token 则更进一步，允许模型在生成每个 token 时选择不同的文档——在序列第三个 token 可以依据文档 A，在第五个 token 可以依据文档 B。这带来了更细粒度的注意力分配，但也更难训练和调试。

实际测试中，两种变体在开放域问答上的表现几乎相同（见下表），但 RAG-Token 的实现复杂度显著更高，目前主流开源实现和商业系统大多基于 RAG-Sequence 思路。

数据集RAG-TokenRAG-Sequence仅检索（DPR）仅生成（BART）
NaturalQuestions44.144.139.828.2
TriviaQA56.856.852.632.3
CuratedTrec50.050.043.339.9
MS MARCO47.747.742.039.8
FEVER68.168.162.558.4

数据来源：Lewis et al., NeurIPS 2020

三、关键技术组件

3.1 检索器：双塔架构与对比学习

RAG 的检索组件基于 DPR（Dense Passage Retriever）架构，使用两个独立的 BERT 编码器分别处理查询和文档，将它们投影到同一个向量空间。相关性由向量点积衡量。

训练目标是对比学习：最大化正样本（查询-相关文档对）的相似度，最小化负样本（查询-不相关文档）的相似度。这种训练方式使检索器学会捕捉语义相关性，而不仅仅是词法重叠。

检索策略的选择直接影响生成质量的上限：

  • 稀疏检索（BM25）：基于词频和逆文档频率的传统算法，对精确术语匹配强，但无法处理同义词和语义相关性
  • 密集检索（Dense Retrieval）：基于嵌入向量的语义匹配，能处理表述变化，但对领域术语和专业概念有时表现欠佳
  • 混合检索（Hybrid Search）：同时运行 BM25 和向量检索，用 Reciprocal Rank Fusion（RRF）等方法融合结果，兼得两者之长，是目前生产系统的常见选择

3.2 生成器：注意力与复制机制

生成组件通常是 Sequence-to-Sequence 模型（BART、T5 或更现代的 Llama 架构）。关键设计在于：生成模型不仅看到了原始查询，还看到了检索文档的内容。

具体实现上，检索文档的 token 被作为额外上下文传入解码器 Attention 层。模型可以通过 复制机制（Copy Mechanism） 直接从检索文档中复制 factual spans 到输出中，这大幅降低了幻觉（hallucination）风险——模型不需要凭空记住事实，只需学会从上下文中选取。

3.3 向量索引基础设施

大规模向量检索需要专门的索引结构。FAISS（Facebook AI Similarity Search）和 HNSW（Hierarchical Navigable Small World）是两种最广泛使用的方案：

  • FAISS：支持 IVF（倒排文件索引）和 PQ（乘积量化）压缩，适合数十亿级向量规模
  • HNSW：基于图的近似最近邻搜索，查询速度快、精度高，但内存占用较大

向量数据库的选择通常取决于具体场景：Pinecone、Weaviate、Qdrant 等云原生向量数据库内置了上述索引算法，并提供了元数据过滤、稠密/稀疏混合检索等高级特性。

四、RAG 的评估体系

RAG 系统评估比普通语言模型复杂，因为涉及两个能力维度：检索质量和生成质量。

4.1 经典 QA 基准

开放域问答系统长期使用以下基准：

  • NaturalQuestions：来自真实 Google 搜索的问答对，答案标注自 Wikipedia，使用 Exact Match（EM）和 F1 评分
  • TriviaQA：从网页爬取的 trivia 问题，规模更大、噪声更多
  • PopQA：基于 Wikidata 单跳查询构建，专门测试实体知识
  • PubHealth：医学问答，需要多跳推理能力
  • FEVER：事实核查任务，验证模型能否判断声明是否被 Wikipedia 支持或反驳

这些基准主要评估端到端问答正确性，但无法揭示 RAG 系统失败的具体原因——是检索没找到正确文档，还是生成器没有正确理解检索结果？

4.2 RAGAS：自动评估检索增强生成

RAGAS（Retrieval-Augended Generation Assessment）由 Es et al. 在 2023 年提出，采用 LLM-as-Judge 的方式评估 RAG 系统，无需人工标注参考答案。RAGAS 聚焦四个维度：

Faithfulness（忠实度）：生成答案中的事实陈述是否都能在检索到的上下文中找到依据。这是衡量幻觉程度的核心指标——系统可能给出了流畅但错误的回答，忠实度会捕捉到这一点。

Answer Relevance（回答相关性）：生成的回答是否真正回应了用户问题。低相关性意味着答非所问，即使内容正确也无用。

Context Precision（上下文精确度）：检索结果中相关性最高的文档是否被排在最前面。如果正确答案埋在检索列表底部，生成器可能忽略它。

Context Recall（上下文召回率）：检索到的上下文是否涵盖了回答问题所需的全部相关信息。召回率不足意味着生成器基于不完整信息作答。

RAGAS 的评估流程是：用 LLM 分别评判上述每个维度，通过精心设计的提示词让模型输出结构化的评分和解释。这套方法已被 LangChain、LangSmith 等主流框架采纳为默认评估方案。

4.3 用 LLM 做 Judge 的实践

LangChain 文档中记录的实践方法是：设计专门的 grading prompt，要求 LLM 对「生成答案」与「标准答案」进行逐点对比，输出包含二值判断（正确/错误）和解释的结构化结果。

Given a question, ground truth answer, and generated answer, evaluate:
1. Does the generated answer contain the key facts from the ground truth?
2. Does it introduce any facts not supported by the context?
3. Rate overall correctness 1-5 and explain.

这种方法的优点是不需要大量人工标注，适合快速迭代。但需要注意 LLM judge 自身的偏见和随机性——同一系统两次评估可能得到略有差异的结果。实践中通常多次采样取平均，或使用更强大的模型（如 GPT-4）作为 judge。

五、生产级实践：常见陷阱与优化

原型演示效果往往不错，真正进入生产后会出现一系列新问题。

5.1 Chunking：分块策略决定检索粒度

Chunking 是将文档切分为可检索单元。

RecursiveCharacterTextSplitter 是 LangChain 等框架的默认推荐，按递归字符边界（段落→句子→单词）切分，尽量保持语义单元完整。典型配置：

# 细粒度 chunks（适合需要精准检索的场景）
chunk_size = 250 tokens
chunk_overlap = 0

# 粗粒度 chunks（适合上下文信息丰富的场景）
chunk_size = 1000 tokens
chunk_overlap = 200

Chunk size 的权衡：

Chunk 大小优点缺点
小（128-256 tokens）检索精度高、噪声少上下文信息不足，生成回答可能片面
中等（500-800 tokens）平衡精度与上下文需要 overlap 以防关键信息被切断
大（1000+ tokens）丰富上下文，生成质量稳定检索精度下降，有效信息密度低

一个常见错误是用固定字符数切分而忽略语义边界——比如把一句完整的话从中间切开，导致检索到的片段缺失关键主语或宾语。RecursiveCharacterTextSplitter 的价值就在于优先保证语义完整性。

领域自适应也很关键。通用分块策略在法律文档、医疗记录、技术规范等专业化内容上往往表现不佳。实践中可以训练专门的语义分割模型，或者在分块后加入领域关键词匹配做二次过滤。

5.2 Embedding 模型选型

Embedding 模型的选择对检索质量影响极大。一些关键指标：

模型维度特点
OpenAI text-embedding-3-large3072MTEB 基准领先，通用场景首选
Cohere Embed1024多语言支持强，API 稳定
BGE-large-en1024开源可商用，中英表现优秀
E5 / E5-mistral1024专为主题搜索优化

通用 Embedding 在领域内容上经常力不从心。例如，通用模型可能将「CRISPR-Cas9 基因编辑技术」简单归类为一般生物学术语，而领域自适应模型能理解其在遗传疾病治疗中的具体应用场景。

解决方案包括：用领域数据微调 Embedding 模型（对比学习框架下相对便宜），或者在向量检索后加一层基于 BM25 的关键词过滤做补充验证。

5.3 检索优化三板斧

即使 Chunking 和 Embedding 都做对了，检索结果仍可能因为查询表述与文档表述的差异而失败。三个最有效的优化手段：

Query Rewriting（查询重写）：用户的自然语言问题往往与知识库文档的表述方式不同。Query Rewriting 用 LLM 将用户问题改写为更接近知识库风格的查询，或者分解为多个子查询分别检索。

Re-ranking（重排序）：初检阶段用向量相似度快速筛选候选文档（Top-K，K 通常取 50-100），然后用 Cross-Encoder 做精细化排序。Cross-Encoder 将 query 和 document 一起输入编码器，计算更精准的相关性分数，但速度比向量检索慢一个数量级，所以通常只重排少量候选。

Retrieval Validation（检索验证）：在将检索结果送入生成器之前，用一个轻量级 LLM 判断文档是否真正相关。如果大多数文档不相关，说明查询本身或知识库有问题，应该触发 query rewrite 而不是盲目生成。

5.4 幻觉监控

常见误解是有了检索就不会产生幻觉。实际生成器仍可能：没有正确理解检索到的上下文、过度依赖参数化记忆而忽略检索结果、在多个检索文档冲突时选择错误的那个。

Faithfulness 指标正是为监控这一问题设计的。生产系统中，建议持续采集 Faithfulness 分数，如果出现系统性下降（比如某段时间检索质量下降导致上下文整体不相关），应该触发告警和人工审查。

六、技术选型：RAG vs 长上下文 vs 微调

理解 RAG 与其他技术路线的边界，才能做出正确选择。

6.1 RAG vs 长上下文窗口

以 GPT-4 128K 和 Claude 200K 为代表的长上下文窗口模型，可以将整个文档塞入提示词中，理论上有完美检索的能力。但实际表现与理想有差距。

Lost-in-the-Middle 是大模型在长上下文中的一个经典问题：相关关键信息如果埋在上下文中间位置，模型对它的注意力显著低于首尾位置的内容。研究表明，当关键信息位于上下文正中时，模型的召回率可能下降 20-30%。

成本对比也值得关注：长上下文调用的推理成本随上下文长度呈二次方增长（Attention 机制），而 RAG 的检索成本基本恒定，即使知识库规模很大也能保持稳定。

维度RAG长上下文
推理成本稳定可控随上下文增长显著上升
知识更新无需重训，替换索引即可需要重新组织文档
幻觉风险低（基于检索上下文）中（取决于模型对上下文的理解）
适用文档规模任意规模（通过索引横向扩展）受限于上下文窗口（通常 < 200K tokens）
关键信息召回依赖检索质量受 Lost-in-the-Middle 影响

当文档集合很大、知识频繁更新、需要引用溯源时，RAG 是更优选择。当单文档不超过上下文窗口的 30-40%（给对话和推理留足空间）、且上下文整体相关性均匀时，长上下文更简单。

6.2 RAG vs Fine-tuning

Fine-tuning（微调）更新的是模型权重，本质上是在教模型「如何行事」而不是「知道什么」。这是两条完全不同的能力轴。

RAG 的优势在于：知识可更新（换知识库无需重训）、可解释性强（引用检索文档即可说明答案来源）、对小模型友好（7B 参数模型配合强检索器可以媲美 70B 参数模型的纯参数记忆效果）。

Fine-tuning 的真正价值在于：行为调教——格式化输出、特定领域术语使用、对话风格控制、复杂推理模式学习。Fine-tuning 不适合存储大量事实性知识，原因很简单：更新知识需要重新微调，而每次微调成本高昂，且存在灾难性遗忘风险。

实际推荐：对知识密集型任务，用 RAG 处理知识存储，用少量微调（LoRA 等参数高效微调）调教行为风格——这是目前最常见的生产架构。

6.3 决策矩阵

场景推荐方案
知识库频繁更新（新闻、产品文档）RAG
需要引用溯源（法律、医疗）RAG
小模型要达到大模型效果RAG + 小模型
单文档，问答位置不确定长上下文
格式化/风格控制Fine-tuning
领域推理模式学习Fine-tuning
知识密集 + 行为调教RAG + Fine-tuning

七、前沿进展（2024-2025）

7.1 Self-RAG：让模型学会自判断

Self-RAG（Asai et al., ICLR 2024）是 RAG 演进中的重要一步。核心创新是引入反射 token，让生成模型自己判断何时检索、检索结果是否可用、回答质量如何。

具体来说，Self-RAG 在输出中插入四类特殊 token：

  • [Retrieval] / [No Retrieval]：模型决定是否需要检索
  • [Correct] / [Incorrect]：模型评判检索到的文档是否与问题相关
  • [Supported] / [Partially supported]：模型判断回答是否被上下文支持
  • [Utility]：模型给回答的整体有用性打分

Self-RAG 训练了 Llama-2 7B 模型，在多个基准上显著超过标准 RAG：

模型PopQAPubHealthARC-Challenge
Self-RAG (7B)31.867.975.2
标准 RAG29.559.473.9
Llama2 + RAG26.255.968.9

Self-RAG 的最大价值在于减少不必要的检索——传统 RAG 对每个问题都执行检索，而 Self-RAG 可以判断某些问题不需要检索，直接从参数知识回答。这不仅节省计算成本，更减少了错误检索带来的噪声。

7.2 Corrective RAG（CRAG）：自动纠错检索结果

CRAG（Yan et al., 2024）针对检索可能返回错误文档的问题，设计了一套自纠正机制。

CRAG 在检索后增加一个 自反思层，对每篇文档做三分类：

  • Correct：文档相关且准确 → 直接使用
  • Incorrect：文档不相关或与问题矛盾 → 触发 Web 搜索，用外部结果替换
  • Ambiguous：文档部分相关但不完整 → 补充检索更多上下文

CRAG 的关键创新不是「拒绝」错误检索，而是主动替换——当内部知识库检索失败时，自动转向 Web 搜索补全。这在需要高度准确性的场景（如医疗问答、法律咨询）中价值显著。

7.3 Agentic RAG：LLM 作为编排引擎

Agentic RAG 将 LLM 提升为 RAG 流水线的编排者（Orchestrator），而非仅仅是被动的问题回答者。

在 LangChain/LangGraph 的实现中，Agentic RAG 使用条件边（Conditional Edge）构建有向无环图（DAG）：

用户问题 → LLM 判断是否需要检索
    ├─ [不需要检索] → 直接回答
    └─ [需要检索] → retrieve 节点
        → gradeDocuments 节点（LLM 评判文档相关性）
            ├─ [相关] → generate 节点 → 输出答案
            └─ [不相关] → rewrite 节点 → 改写查询 → 重新检索

这实现了几个关键能力：

  • 条件检索：简单事实问题不需要检索，节省成本
  • 查询改写：对检索结果不满意时，用 LLM 分析失败原因并优化查询
  • 多步检索：复杂问题可以分解为多个子查询，逐步逼近答案
  • 自我纠错：通过 gradeDocuments 的反馈循环，在生成之前就拦截低质量检索

Agentic RAG 是当前 RAG 架构中最活跃的发展方向，因为它天然契合 Agent 系统的设计哲学——让模型拥有工具调用能力、自主决策能力和自我纠错能力。

八、总结与展望

RAG 自 2020 年提出至今，技术演进有两条清晰的主线。

一条是架构复杂度的上升：早期「检索+生成」的串联结构，逐步演化为 Agentic RAG 的条件分支、反馈循环、多步推理。另一条是自我感知能力的增强：Self-RAG 引入了反射 token，让模型能判断检索是否必要；CRAG 则在检索结果不满意时自动转向 Web 搜索。

展望未来，RAG 的发展方向可能包括：

  • 多模态 RAG：将图像、表格、代码块纳入检索和生成范围
  • 结构化知识融合：将知识图谱与向量检索结合，提供更可靠的推理链路
  • RAG 与 Long Context 的融合：在单个文档内部用 Long Context，多文档之间用 RAG，兼顾精度与广度
  • 实时知识更新：流式知识库更新与增量索引，使 RAG 能够近乎实时地纳入新知识

掌握 RAG 的底层原理、评估调优方法，以及 Self-RAG、CRAG、Agentic RAG 等前沿进展，是构建可靠知识密集型应用的关键能力。

参考资料