RAG（Retrieval-Augmented Generation）学习笔记

一、什么是 RAG

RAG（检索增强生成） 是一种将信息检索与大语言模型生成相结合的技术范式。核心思路很简单：在让 LLM 回答问题之前，先从外部知识库中检索相关内容，把检索到的内容作为上下文喂给模型，再让模型基于这些真实数据生成回答。

1.1 为什么需要 RAG

LLM 存在几个固有缺陷：

RAG 通过外部检索来弥补这些问题，让 LLM 的回答有据可查、实时更新。

1.2 RAG vs Fine-tuning vs Prompt Engineering

实际项目中，这三者经常组合使用。

二、RAG 基本架构

2.1 标准流程

1
2
3
4
5
6
7
8
9
10
11

用户提问
  ↓
Query 处理（改写、扩展）
  ↓
检索（Retrieval）—— 从知识库中找到相关文档片段
  ↓
上下文组装 —— 将检索结果拼入 Prompt
  ↓
LLM 生成回答
  ↓
输出（附带来源引用）

2.2 两大阶段

离线阶段（Indexing）

把原始数据变成可检索的知识库：

1

原始文档 → 文档切分（Chunking） → 向量化（Embedding） → 存入向量数据库

在线阶段（Querying）

用户提问时的实时流程：

1

用户问题 → 问题向量化 → 向量相似度检索 → 上下文拼装 → LLM 生成

三、核心组件详解

3.1 文档切分（Chunking）

切分策略直接影响检索质量。

关键参数：

• chunk_size：每个片段的大小，通常 256～1024 tokens
• chunk_overlap：相邻片段重叠区域，通常为 chunk_size 的 10%～20%

1
2
3
4
5
6
7
8
9

# LangChain 递归字符切分示例
from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50,
    separators=["\n\n", "\n", "。", ".", " ", ""]
)
chunks = splitter.split_text(document)

经验法则：chunk 太大→检索不精准，带入太多噪声；chunk 太小→丢失上下文，回答不完整。需要根据实际数据调优。

3.2 向量化（Embedding）

将文本转为固定维度的稠密向量，用于相似度计算。

常见 Embedding 模型：

1
2
3
4
5
6
7
8
9

# OpenAI Embedding 示例
from openai import OpenAI

client = OpenAI()
response = client.embeddings.create(
    model="text-embedding-3-small",
    input="RAG 是检索增强生成技术"
)
embedding = response.data[0].embedding  # 1536维向量

3.3 向量数据库

存储和检索向量的专用数据库。

相似度度量方法：

• 余弦相似度（Cosine Similarity）：最常用，衡量方向相似性
• 欧氏距离（L2）：衡量绝对距离
• 内积（Inner Product）：与余弦类似，向量需归一化

3.4 检索策略

基础检索

向量检索（Dense Retrieval）：将 query 向量化，在向量数据库中找最近邻。

1
2
3

# 伪代码：基础向量检索
query_embedding = embed(user_query)
results = vector_db.search(query_embedding, top_k=5)

进阶检索

混合检索（Hybrid Search）：结合向量检索和关键词检索（BM25），取长补短。

1
2
3

Query ──→ 向量检索 → 结果A
     └──→ BM25检索 → 结果B
                  → 融合排序（RRF/加权） → 最终结果

多路召回 + 重排序（Retrieve & Re-rank）：

1

Query → 多种检索策略 → 粗排候选集 → Cross-Encoder重排序 → 精排结果

重排序模型（如 bge-reranker、Cohere Rerank）对 query-document 对进行深度相关性打分，显著提升精度。

3.5 上下文组装与生成

将检索到的内容组装进 Prompt，交给 LLM 生成。

常见 Prompt 模板：

1
2
3
4
5
6
7
8
9
10

你是一个知识问答助手。请根据以下参考资料回答用户的问题。
如果参考资料中没有相关信息，请如实说明，不要编造。

## 参考资料
{retrieved_contexts}

## 用户问题
{user_query}

## 回答

关键点：

• 明确告知模型”基于参考资料回答”，减少幻觉
• 添加”不知道就说不知道”的指令
• 控制注入上下文的总量，避免超过模型窗口限制

四、RAG 进阶技术

4.1 Query 改写与扩展

用户原始提问往往不是最优的检索 query。

1
2
3
4

# HyDE 示例
hypothetical_answer = llm.generate(f"请回答: {user_query}")
# 用假设回答的 embedding 去检索，而不是用原始问题
results = vector_db.search(embed(hypothetical_answer), top_k=5)

4.2 图谱 RAG（GraphRAG）

微软提出的 GraphRAG 方法，用知识图谱增强检索。

流程：

1. 从文档中抽取实体和关系，构建知识图谱
2. 对图谱进行社区检测，生成不同层级的摘要
3. 查询时同时利用向量检索和图谱结构进行推理

优势：擅长回答需要跨文档推理的全局性问题（如”总结所有文档的主要观点”）。

4.3 自适应 RAG（Adaptive / Self-RAG）

让模型自主判断是否需要检索：

1
2
3
4
5

用户问题 → LLM 判断是否需要检索
              ├── 不需要 → 直接回答
              └── 需要 → 检索 → 评估检索结果相关性
                            ├── 相关 → 生成回答
                            └── 不相关 → 换策略重新检索

Self-RAG 论文引入了反思令牌（Reflection Tokens），让模型在生成过程中自评检索质量和回答可靠性。

4.4 嵌套/多跳 RAG（Multi-hop RAG）

处理需要多步推理的复杂问题：

1
2
3

问题："A公司的创始人还在B公司任职吗？"
  → 第1跳：检索 A公司创始人是谁 → 得到"张三"
  → 第2跳：检索 张三是否在B公司任职 → 得到答案

4.5 Agentic RAG

将 RAG 作为 Agent 的工具之一，由 Agent 自主规划检索策略。

1
2
3
4

用户问题 → Agent 思考
           → 决定调用哪个检索工具（向量库/搜索引擎/数据库）
           → 分析结果，决定是否需要再次检索
           → 综合所有信息生成最终回答

工具定义示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

tools = [
    {
        "name": "search_internal_docs",
        "description": "搜索公司内部文档库",
        "parameters": {"query": "str", "top_k": "int"}
    },
    {
        "name": "search_web",
        "description": "搜索互联网获取最新信息",
        "parameters": {"query": "str"}
    },
    {
        "name": "query_database",
        "description": "查询结构化数据库",
        "parameters": {"sql": "str"}
    }
]

五、评估体系

5.1 检索质量评估

5.2 生成质量评估

RAGAS 框架是 RAG 评估的主流方案：

1
2
3
4
5
6
7
8

# RAGAS 评估示例
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision

results = evaluate(
    dataset=eval_dataset,
    metrics=[faithfulness, answer_relevancy, context_precision]
)

5.3 端到端评估

最终的评估还是要回归业务场景：

• 人工评估：抽样打分，准确率、完整性、流畅度
• LLM-as-Judge：用强模型评估弱模型的输出
• A/B 测试：线上对比不同 RAG 方案的用户满意度

六、工程实践要点

6.1 数据处理

• 数据清洗：去除乱码、重复内容、格式噪声
• 元数据标注：为每个 chunk 添加来源、时间、分类等元数据，支持过滤检索
• 多格式解析：PDF、Word、HTML、Markdown、表格、图片（OCR）各有解析方案

6.2 性能优化

6.3 常见问题与对策

6.4 技术选型参考

原型验证（快速起步）：

• Embedding: OpenAI text-embedding-3-small
• 向量库: Chroma / FAISS
• 框架: LangChain / LlamaIndex

生产部署：

• Embedding: BGE / GTE（可自部署，数据不出域）
• 向量库: Milvus / Weaviate / pgvector
• 框架: LlamaIndex（更灵活）或自建 Pipeline
• 重排序: bge-reranker-v2-m3 / Cohere Rerank

七、主流框架对比

八、学习资源

论文

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（RAG 原始论文，Facebook AI，2020）
• Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection
• GraphRAG: Unlocking LLM Discovery on Complex Data（Microsoft，2024）

实践项目

• LangChain RAG 模板：官方提供了多种 RAG 架构的参考实现
• LlamaIndex 官方示例：覆盖从基础到进阶的各类 RAG 模式
• RAGAS：RAG 评估框架，附带完整评估示例

这篇笔记梳理了 RAG 从基础概念到进阶实践的知识体系。RAG 的本质就是”让 LLM 先查资料再回答”，看似简单，但每个环节（切分、向量化、检索、生成、评估）都有大量工程细节。建议从最简单的向量检索 RAG 起步，遇到具体问题再逐步引入进阶技术——不要一上来就搞 GraphRAG + Agent + Multi-hop，过度的复杂度往往是 RAG 项目失败的原因。