RAG（检索增强生成）知识体系详解
来源: 小林面试笔记 - xiaolinnote.com
整理时间: 2026-07-21
文档定位: 面向大模型面试准备与工程实践的系统性 RAG 知识整理
一、什么是 RAG？
1.1 核心定义
RAG 全称是 Retrieval-Augmented Generation（检索增强生成）。
它解决的核心问题是：LLM 的知识在训练完成后就固定了，无法覆盖私有数据或最新信息。RAG 的做法是在生成答案之前，先去外部知识库检索相关内容，然后把检索结果和用户问题一起交给 LLM，让它基于这些上下文来回答。
本质上是给 LLM 开了一个"开卷考试"的口子，不用再靠死记硬背。
1.2 RAG vs 微调（Fine-tuning）
| 维度 | RAG | 微调（Fine-tuning） |
|---|---|---|
| 知识存储 | 外部知识库（向量数据库） | 模型参数内部 |
| 更新方式 | 热更新，随时增删文档 | 需要重新训练模型 |
| 更新成本 | 极低 | 高昂（GPU + 时间） |
| 可解释性 | 答案可追溯到源文档 chunk | 黑盒，难以解释 |
| 幻觉控制 | 可通过限定 prompt 抑制 | 难以控制 |
| 适用场景 | 企业知识库、实时信息问答 | 领域风格适配、任务微调 |
二、RAG 完整工作流程
一个完整的 RAG 系统分为离线阶段和在线阶段，两个阶段分工明确。
2.1 离线阶段详解
📄 文档加载
将各种格式的原始数据读取进来：PDF、Word、Markdown、网页、数据库记录等。常用工具：
- LlamaIndex 的
DocumentLoader - LangChain 的
DocumentLoader - 支持几十种数据源格式，基本覆盖所有常见场景
✂️ 文档切割（Chunking）
为什么不直接把整篇文档存进去？
因为 Embedding 模型有最大输入长度限制（如 512 token），整篇文档太长无法向量化；而且检索粒度太粗，用户问一个细节问题，返回整篇文档不精准。
常见切割策略：
| 策略 | 描述 | 适用场景 |
|---|---|---|
| 固定大小切割 | 按 token 数等分，如每 512 token 一块 | 简单文档，实现快速 |
| 滑动窗口切割 | 相邻 chunk 有重叠（如各重叠 100 token） | 防止语义在边界被截断 |
| 递归切割 | 按段落→句子→词的优先级递归分割 | 尽量保持语义单元完整 |
| 语义切割 | 基于语义相似度变化确定切割点 | 对内容敏感度要求高的场景 |
🧮 Embedding 向量化（详见第三章）
Embedding 模型将一段文字转成高维数字向量（如 1536 维），核心特性是语义相近的文本，向量在空间中也相近。
💾 入库
将每个 chunk 的向量和原始文本存入向量数据库，常见选型：
- Chroma：轻量级，适合原型开发
- Milvus：高性能，适合生产环境大规模数据
- Qdrant：Rust 实现，性能优异
- Weaviate：自带向量化和混合搜索
- Pinecone：全托管云服务
2.2 在线阶段详解
🔄 Query 改写
用户的自然语言提问往往口语化、模糊或依赖上下文。例如：
- “上次说的那个方案怎么样？” → 检索系统不知道"上次"和"那个方案"是什么
Query 改写让 LLM 把用户问题改写成更适合检索的形式：
- 补全对话上下文
- 去除口语化表达
- 拆解复杂问题为多个子查询
🔍 向量检索（粗排）
将改写后的问题向量化，在向量库中做相似度搜索，找出距离最近的 Top-K 个 chunk：
- 速度极快（百万量级向量库，几十毫秒返回）
- 但精度有限，可能混入"看着近但不相关"的内容
📊 Rerank（精排）
使用 Cross-Encoder 模型对粗排结果深度排序：
- 把用户问题和每个候选 chunk 拼接，深度理解相关性
- 精排更准但更慢，通常对 Top-20 做精排，最终保留 Top-3 到 Top-5
📌 类比：粗排 = 在书架上快速扫一眼抽出可能相关的书；精排 = 一本本翻开读目录确认是否真正有用。
📝 生成
将"用户问题 + 精排后的 chunk"拼成 Prompt，交给 LLM 生成最终答案。Prompt 中通常明确限定：
“只根据提供的资料回答，资料里没有就说不知道”
三、Embedding 深度解析
3.1 Embedding 是什么？
Embedding 模型将自然语言文本映射为固定长度的浮点数向量。例如 1024 维的模型，无论输入是 10 个字还是 500 个字，输出都是长度为 1024 的数字列表。
核心特性：语义相近的文本，向量的余弦相似度高。
3.2 为什么用余弦相似度？
在高维空间中，向量长度（模长）受文本长度、表达强度等非语义因素影响。余弦相似度只看两个向量的方向（夹角），忽略长度：
- 方向一致 → 余弦值接近 1（语义相近）
- 方向正交 → 余弦值接近 0（语义无关）
- 方向相反 → 余弦值接近 -1（语义相反）
3.3 主流 Embedding 模型对比
| 模型 | 维度 | 中文支持 | 最大长度 | 特点 |
|---|---|---|---|---|
| BGE-M3 | 1024 | ⭐⭐⭐⭐⭐ | 8192 | 国产最强中文模型，支持稀疏+稠密混合检索 |
| BGE-large-zh | 1024 | ⭐⭐⭐⭐⭐ | 512 | 经典中文 Embedding |
| OpenAI text-embedding-3-small | 1536 | ⭐⭐⭐ | 8191 | 性价比高，支持降维 |
| OpenAI text-embedding-3-large | 3072 | ⭐⭐⭐ | 8191 | 精度最高，成本较高 |
| Jina Embeddings v3 | 1024 | ⭐⭐⭐⭐ | 8192 | 多语言，支持任务特定 Embedding |
3.4 评估 Embedding 模型
不要只看 MTEB 排行榜，一定要在自己的业务数据上做评估：
- Hit@K：Top-K 检索结果中包含正确答案的比例
- MRR（Mean Reciprocal Rank）：第一个正确答案的排名倒数均值
- NDCG：考虑排序位置的归一化折损累计增益
四、检索优化策略
4.1 向量检索 vs 关键词检索
| 维度 | 向量检索 | 关键词检索（BM25） |
|---|---|---|
| 原理 | 语义相似度 | 词频-逆文档频率 |
| 优势 | 处理同义词、近义词、不同表达 | 精确匹配，专有名词不丢 |
| 劣势 | 专有名词可能模糊匹配 | 无法理解同义词 |
| 典型实现 | FAISS / Milvus | Elasticsearch / Lucene |
4.2 多路召回
结合向量检索和关键词检索的优势，并行执行然后合并结果：
4.3 Rerank（精排）
为什么需要 Rerank？
向量检索只是比较两个向量的距离，没有深度理解查询和文档的语义关系。Rerank 使用 Cross-Encoder 结构，将用户问题和候选 chunk 拼接后深度计算相关性。
常用 Rerank 模型：
- BGE-Reranker（BAAI）
- Cohere Rerank
- Jina Reranker
五、图数据库增强 RAG
5.1 什么场景使用图数据库？
当知识之间存在复杂的关联关系时，传统的向量检索难以捕捉这种结构化的关联。典型场景：
| 场景 | 示例 |
|---|---|
| 知识图谱问答 | “张三是哪个部门的？他的上级是谁？” |
| 多跳推理 | “A 公司和 B 公司有什么竞争关系？” |
| 实体关系查询 | “治疗高血压的药物有哪些副作用？” |
| 文档层级结构 | 法律条文之间的引用关系 |
5.2 GraphRAG 架构
六、RAG 幻觉规避
6.1 幻觉的来源
- 检索不到相关内容：知识库中没有答案
- 检索到不相关内容：chunk 与问题无关但 LLM 强行关联
- LLM 自身幻觉：即使有正确的上下文，LLM 也可能"发挥"
- 上下文过长：相关信息被淹没在大量无关内容中
6.2 规避策略
| 策略 | 描述 |
|---|---|
| Prompt 约束 | 明确要求"只根据提供的资料回答，不知道就说不知道" |
| 相似度阈值过滤 | 低于阈值的 chunk 不送入 LLM |
| Rerank 精排 | 确保送入 LLM 的是最相关的 chunk |
| 答案校验 | 用另一个 LLM 检查答案是否与原文一致 |
| 引用溯源 | 要求 LLM 在回答中引用具体的 chunk 来源 |
| 知识库质量 | 确保知识库内容准确、完整、结构清晰 |
七、RAG 效果评估
7.1 评估维度
7.2 评估框架
| 框架 | 特点 |
|---|---|
| RAGAS | 专为 RAG 设计，评估忠实度、相关性、精度等 |
| TruLens | 提供 RAG 三角评估（答案相关性、上下文相关性、忠实度） |
| DeepEval | 支持多种 RAG 指标的单元测试式评估 |
| LangSmith | LangChain 生态，端到端追踪和评估 |
八、知识库动态更新
8.1 更新策略对比
| 方案 | 延迟 | 复杂度 | 适用场景 |
|---|---|---|---|
| 定时轮询 | 分钟-小时级 | 低 | 文档更新频率低 |
| Webhook 触发 | 秒级 | 中 | 数据源支持 Webhook |
| 消息队列（Kafka） | 秒级 | 中高 | 大规模高并发更新 |
| 全量重建 | 分钟-小时级 | 低 | 文档量小或结构大改 |
8.2 推荐方案
核心原则：
- ✅ 先删后增：修改操作先删除旧的所有 chunk，再重新入库
- ✅ Hash 检测：用内容 hash 判断文档是否变更
- ✅ Chunk ID 关联文档 ID：便于批量查找和删除
- ✅ 灰度更新：新版本并行写入，验证后切换，出问题秒级回滚
九、20 道 RAG 核心面试题
以下题目来自小林面试笔记，覆盖 RAG 面试全考点：
- 什么是 RAG？详细描述一个完整 RAG 系统的详细工作流程？
- 大模型的 RAG 主要用来解决什么问题？
- 相比直接微调 LLM，RAG 解决了什么问题？微调和 RAG 各自的优劣势是什么？
- RAG 中的文档是怎么存的？粒度是多大？详细说说文档切割（Chunking）策略？
- 怎么规避语义被切割掉的问题？
- 在 RAG 中 Embedding 究竟是什么？如何选择和评估一个 Embedding 模型？
- Embedding 有哪几种算法你了解过吗？
- 什么是向量数据库？有没有做过向量数据库的对比选型？
- 讲讲你用的向量数据库？数据量级是多大？性能如何？
- 你使用 RAG 给大模型一个输入，系统是怎样的工作流程？
- 请你介绍一下向量检索和关键词检索的区别？
- 如何润色用户的 Query（Query Rewrite）？目的是什么？
- 什么是多路召回？具体怎么做？
- RAG 检索优化策略有哪些？
- 了解哪些更复杂的 RAG 范式？
- 在什么场景下，你会选择使用图数据库来增强传统的向量检索？
- 如何规避 RAG 系统中大模型的幻觉？
- 怎么量化你的 RAG 效果？
- RAG 知识库如何实现动态与持续更新？
- 在实际落地中，你觉得 RAG 最难的地方是哪里？
📚 参考资料: 小林面试笔记 - RAG 面试题
评论区