RAG检索增强生成

梓仁沐白

499人浏览 · 2026-03-24 14:40:39

梓仁沐白 · 2026-03-24 14:40:39 发布

**RAG（Retrieval-Augmented Generation，检索增强生成）**是一种将"信息检索 + 大模型生成"结合的技术框架。

核心思想：

让大模型在回答问题前，先从外部知识库中"查资料"，再基于这些资料生成答案。

为什么需要 RAG

大模型存在三个根本性限制：

问题	说明
知识截止	训练数据有时间截止，无法回答最新信息
幻觉	模型会"编造"看似合理但错误的答案
私有数据	企业内部文档、数据库无法训练进模型

RAG 通过"用时检索"解决这三个问题，同时相比微调，成本更低、更新更灵活、可溯源。

RAG 的整体流程

核心 Pipeline

用户问题
   ↓
向量化（Embedding）
   ↓
向量数据库检索（Top-K）
   ↓
拼接上下文（Prompt）
   ↓
大模型生成答案

“为提示词做推荐算法”

准备阶段（提问前）

需要对知识库数据进行预处理

分片（Chunking）

把文档切分成多个片段，是 RAG 质量的基础。

常见分片策略：

策略	方式	适用场景
固定大小	按字符数/Token 数截断	通用场景，实现简单
段落分割	按换行/空行切分	结构化文档
语义分割	检测语义边界后切分	质量要求高的场景
递归分割	先按大粒度，再按小粒度	长文档
按页面	PDF 等文档按页	报告、论文
按章节	提取目录结构	书籍、技术文档

Overlap（重叠）： 相邻片段之间保留一定重叠，避免关键信息恰好被切断：

[片段1: 前100字][重叠20字][片段2: 后100字]
                ↑
          两个片段都包含这20字

分片大小权衡：

太小 → 单片段信息不完整，缺乏上下文
太大 → 噪声多，检索精度下降，占用更多 context window

索引

通过 Embedding 模型 将片段文本转换成向量，存入向量数据库：

"苹果是一种水果" → [0.12, -0.34, 0.87, ..., 0.56]  (1536维)

同时通常也存储原始文本和 metadata（来源文件、页码、时间等），便于溯源。

问答阶段（提问后）

召回

将用户问题向量化，在向量数据库中查询最相近的 Top-K 片段。

向量相似度计算方法：

方法	公式	特点
余弦相似度	cos(A,B) = A·B / (‖A‖‖B‖)	最常用，不受向量长度影响
欧氏距离	√Σ(aᵢ-bᵢ)²	直观，但受量纲影响
点积	A·B = Σaᵢbᵢ	计算简单，适合归一化向量

召回策略不止向量检索：

稀疏检索（BM25）：基于关键词的传统检索，对专有名词、代码、ID 等精确匹配效果好
稠密检索（向量）：语义相似，能理解同义词和模糊查询
混合检索（Hybrid Search）：融合两者，用加权分数合并结果，综合效果最好

最终分数 = α × 向量相似度 + (1-α) × BM25 分数

重排（Rerank）

召回阶段返回 Top-K（例如 20 个），重排阶段从中精选 Top-N（例如 5 个）送入 LLM。

阶段	模型类型	原理	成本	准确率
召回	Bi-Encoder	问题和文档分别编码，用向量相似度比较	低（可预计算）	中
重排	Cross-Encoder	问题和文档拼接后一起编码，直接输出相关性分数	高（实时计算）	高

Cross-Encoder 更准确是因为它能看到问题和文档的交互，但无法预计算，不能用于大规模召回。

生成

将重排后的片段文本 + 用户问题，拼成 Prompt 发给 LLM：

你是一个问答助手。请根据以下参考资料回答用户问题。

参考资料：
[1] {片段1}
[2] {片段2}
[3] {片段3}

用户问题：{question}

请基于参考资料作答，如果资料中没有相关信息请如实说明。

Embedding 模型

Embedding 是将文本映射到高维向量空间的模型，语义相近的文本向量距离也近。

常用 Embedding 模型：

模型	提供方	维度	特点
text-embedding-3-large	OpenAI	3072	综合性能强
text-embedding-3-small	OpenAI	1536	性价比高
BAAI/bge-m3	智源	1024	多语言，开源
text-embedding-v3	阿里	1024	中文效果好
nomic-embed-text	Nomic	768	本地部署，开源

注意： 索引阶段和查询阶段必须使用同一个 Embedding 模型，否则向量空间不一致，检索会失效。

向量数据库

专门用于存储和高效检索高维向量的数据库。

数据库	特点	适用场景
Faiss	Meta 开源，纯内存，速度极快	研究/离线批量处理
Chroma	轻量，易上手，适合本地开发	原型开发、小规模
Milvus	分布式，功能完整，生产级	大规模生产环境
Qdrant	Rust 编写，性能好，云原生	生产环境
Pinecone	全托管云服务	不想运维向量数据库
Weaviate	支持多模态，内置向量化	多模态场景
pgvector	PostgreSQL 插件	已有 PG 数据库的系统

高级 RAG 技术

基础 RAG 在复杂场景下会遇到问题，催生了多种增强技术。

Query 改写 / 扩展

用户原始问题往往表达不够精确，可以先对问题进行处理：

HyDE（Hypothetical Document Embeddings）：让 LLM 先"假设"一个答案，用假设答案去检索（假设答案与真实文档更相似）
Query Expansion：将一个问题扩展成多个问法，分别检索后合并结果
Step-Back Prompting：将具体问题抽象成更宽泛的问题，先检索背景知识

用户：苹果公司 2023 年的营收是多少？
↓ HyDE
假设答案：苹果公司2023年营收约为3830亿美元...
↓ 用假设答案去检索，比用原始问题检索更准

多跳检索（Multi-Hop Retrieval）

复杂问题需要多轮检索，每次检索的结果作为下一次检索的依据：

问题：A 公司 CEO 的母校在哪个城市？
第1跳：检索 "A 公司 CEO 是谁" → 得到姓名
第2跳：检索 "XX 的母校" → 得到学校名
第3跳：检索 "XX 大学在哪" → 得到城市

Self-RAG

模型自己决定：

是否需要检索（避免不必要的检索）
检索到的内容是否相关
生成的答案是否有依据
答案是否完整

通过特殊 token 控制检索行为，比固定流程更灵活。

Contextual Compression

检索到的片段可能很长，但与问题相关的只有一部分，可以先压缩再送给 LLM：

原始片段：1000字的文档介绍公司历史
↓ 压缩（提取与问题相关的句子）
压缩后：仅保留与问题相关的3句话

Agentic RAG

将 RAG 与 Agent 结合，LLM 自主决定检索策略：

决定检索哪个知识库
决定检索几次
判断是否需要调用外部工具
整合多来源信息

RAG 的评估

评估维度

维度	定义	评估方法
检索准确率	检索到的文档是否真的相关	Precision@K, NDCG
忠实度（Faithfulness）	生成答案是否基于检索到的内容	判断是否"凭空捏造"
答案相关性	生成答案是否真的回答了问题	与标准答案对比
上下文召回率	相关文档是否都被检索到	Recall@K

常用评估框架

RAGAS：专为 RAG 设计的评估框架，可用 LLM 自动打分
TruLens：支持多种评估指标，有可视化界面
LangSmith：LangChain 生态的追踪和评估工具

常见问题与优化

检索不准确

原因	解决方案
分片粒度不合理	调整分片大小，引入 overlap
问题表述不清	加入 Query 改写步骤
语义偏差	混合检索（向量 + BM25）
Embedding 模型不匹配	换用更适合领域的模型

幻觉问题

LLM 在检索内容不足时仍可能编造内容，对策：

Prompt 中明确要求"资料中没有则如实说明"
对答案中的关键声明进行来源验证
使用 Self-RAG 让模型自我审查

上下文过长

送入 LLM 的片段过多会导致：推理慢、费用高、“迷失在中间”（Lost in the Middle）问题。

对策：

严格控制 Top-K 数量（通常 3-5 个）
加入重排步骤精选
使用 Contextual Compression 压缩片段

知识库更新

知识库内容变更时需要重新索引：

增量更新：只处理新增/修改的文档
版本管理：记录每个片段的来源版本
TTL 机制：对时效性强的内容设置过期时间

RAG vs 微调（Fine-tuning）

对比项	RAG	微调
知识更新	更新知识库即可，成本低	需要重新训练，成本高
知识来源	明确可溯源	融入权重，不可溯源
幻觉控制	有检索结果作为依据，相对可控	较难控制
领域适配	依赖检索质量	语言风格/格式可深度定制
私密数据	数据不进入模型，更安全	数据用于训练，有泄露风险
适用场景	知识问答、文档搜索	特定风格、格式、任务适配