什么是 RAG
RAG（Retrieval-Augmented Generation，检索增强生成） 是一种让 LLM 在生成回答前，先从外部知识库检索相关信息的架构。
打个比方：
- 纯 LLM = 闭卷考试（只能靠训练时记住的知识）
- LLM + RAG = 开卷考试（可以翻参考资料再答题）
RAG 由三个阶段组成：
用户提问 → [1. 检索 Retrieve] → [2. 增强 Augment] → [3. 生成 Generate] → 回答
- 检索：把用户问题转为向量，在知识库中找最相关的文档片段
- 增强：把检索到的文档片段拼入 Prompt，作为上下文
- 生成：LLM 基于上下文生成回答
为什么需要 RAG
纯 LLM 有三大痛点，RAG 精准解决：
痛点 1：知识过时
问："2026 年最新的 GPT 模型是什么？"
LLM（训练截止 2024）："GPT-4 Turbo..."（过时）
RAG："检索到最新资料 → GPT-5.2..."（实时）
痛点 2：幻觉
问："我们公司的退货政策是什么？"
LLM："退货政策是 7 天无理由..."（编造）
RAG："根据知识库 → 退货政策是 30 天有理由..."（有据可查）
痛点 3：领域知识不足
问："公司内部 API 网关的鉴权流程是什么？"
LLM："通常 API 鉴权用 OAuth..."（通用，不精确）
RAG："根据内部文档 → 我们用的是自定义 JWT + 网关拦截..."（精确）
RAG 完整流程
阶段 1：知识库构建（离线）
文档 → 分块（Chunking）→ Embedding → 存入向量数据库
- 文档加载：PDF / Word / Markdown / HTML / 数据库
- 分块：把长文档切成 200-500 token 的片段
- Embedding：每个片段转为向量
- 存储：向量 + 原文存入向量数据库（Pinecone / Milvus / pgvector）
阶段 2：检索（在线）
用户问题 → Embedding → 向量数据库检索 → Top-K 相关片段
- 问题向量化：用与知识库相同的 Embedding 模型
- 相似度检索：余弦相似度找 Top-K（通常 K=3-5）
- 可选 Reranking：用 Cross-Encoder 重排序，提升精度
阶段 3：生成（在线）
Prompt = 系统指令 + 检索到的片段 + 用户问题
→ LLM 生成回答
Prompt 示例：
基于以下参考资料回答问题。如果资料中没有答案，说"根据现有资料无法回答"。
## 参考资料
{retrieved_chunks}
## 问题
{user_question}
RAG vs Fine-tuning
| 维度 | RAG | Fine-tuning |
|---|---|---|
| 解决什么 | 知识更新、事实准确 | 风格/格式/领域能力 |
| 改变参数 | ❌ | ✅ |
| 知识更新 | 更新数据库即可 | 需重新训练 |
| 实时性 | ✅ 实时 | ❌ 训练后固定 |
| 可溯源 | ✅ 标注来源 | ❌ 黑盒 |
| 幻觉控制 | ✅ 强 | ⚠️ 弱 |
| 成本 | 低（向量检索） | 中-高（训练） |
| 数据需求 | 原始文档 | 标注数据 |
| 适合 | 事实问答、知识库 | 风格定制、领域专精 |
最佳实践：两者结合。Fine-tune 模型风格与能力，RAG 提供实时事实。
Naive RAG vs Advanced RAG
Naive RAG（基础版）
最简单的 RAG，直接检索 + 生成：
问题 → Embedding → 检索 Top-5 → 拼入 Prompt → 生成
问题：
- 检索不准（语义偏差）
- 检索不全（漏关键信息）
- 上下文过长（浪费 token）
- 无引用标注（不可溯源）
Advanced RAG（进阶版）
在 Naive RAG 基础上增加优化：
检索前优化（Pre-retrieval）
| 优化 | 说明 |
|---|---|
| 查询改写 | 把口语化问题改为检索友好的关键词 |
| 查询扩展 | 生成多个变体查询，提升召回 |
| HyDE | 先让 LLM 生成假设答案，用答案去检索 |
检索优化（Retrieval）
| 优化 | 说明 |
|---|---|
| 混合检索 | 语义检索 + 关键词检索（BM25） |
| Reranking | Cross-Encoder 重排序 Top-20 → Top-5 |
| 多路召回 | 多个向量库 / 多种 Embedding 并行检索 |
| 元数据过滤 | 按 source/date/category 预筛 |
检索后优化（Post-retrieval）
| 优化 | 说明 |
|---|---|
| 上下文压缩 | 压缩检索片段，去冗余 |
| 上下文重排 | 把最相关的放前面（注意力衰减） |
| 引用标注 | 标注每个事实的来源片段 |
Modular RAG（模块化）
更高级的架构，支持：
- 路由：判断问题类型，走不同检索链
- 记忆：保留对话历史，支持多轮
- 工具调用：RAG + Agent，检索不足时调用外部 API
- 自纠正：生成后自检，不满意则重新检索
主流技术栈
Embedding 模型
| 模型 | 特点 | 适合 |
|---|---|---|
| OpenAI text-embedding-3-small | 通用、便宜 | 快速上线 |
| BGE-large-zh | 中文优秀、开源 | 中文场景 |
| Jina v2 | 支持 8K 长文本 | 长文档 |
详见 Embedding 详解。
向量数据库
| 数据库 | 特点 | 适合 |
|---|---|---|
| Pinecone | 托管 SaaS | 快速上线 |
| Milvus | 开源高性能 | 大规模 |
| pgvector | PG 扩展 | 已有 PG |
| Chroma | 轻量 | 原型 |
RAG 框架
| 框架 | 特点 | 适合 |
|---|---|---|
| LangChain | 代码灵活 | 开发者 |
| Dify | 可视化 | 非技术 |
| LlamaIndex | 专注 RAG | RAG 专精 |
| Haystack | 企业级 | 生产部署 |
详见 Dify vs LangChain 对比。
分块策略详解
分块是 RAG 质量的关键：
| 策略 | 方法 | 适合 |
|---|---|---|
| 固定长度 | 每 500 token 一块 | 简单通用 |
| 按段落 | 按自然段分 | 文章 |
| 按语义 | 模型检测边界 | 技术文档 |
| 滑动窗口 | 重叠 10-20% | 防边界丢失 |
| 递归分块 | 先大后小 | 层级文档 |
| 父子分块 | 检索小块，返回大块 | 精度+上下文 |
最佳实践：块大小 200-500 token，重叠 10-20%，按语义分块优于固定长度。
常见误区
- 误区 1：RAG 能解决一切。RAG 只解决"知识"问题，不解决"推理"问题，复杂推理仍需 CoT。
- 误区 2：检索越多越好。Top-K 过大反而引入噪声，K=3-5 最佳。
- 误区 3：Embedding 模型随便选。中文用 BGE/M3E 比用 OpenAI 效果好。
- 误区 4：分块越大越好。大块检索精度低，小块缺上下文，200-500 token 是甜点。
- 误区 5：RAG 不需要 Prompt 工程。检索到不等于用好，仍需好的 Prompt 指导 LLM 利用上下文。
- 误区 6：RAG 不会幻觉。RAG 降低幻觉但不消除，LLM 仍可能曲解检索内容。
- 误区 7：向量数据库越大越好。百万级以下用 pgvector 足够，别过度工程。
评估指标
| 指标 | 说明 | 目标 |
|---|---|---|
| 检索准确率 | Top-K 中包含正确答案的比例 | >90% |
| 检索召回率 | 所有正确答案被检索到的比例 | >85% |
| 回答准确率 | 回答与标准答案一致率 | >80% |
| 回答忠实度 | 回答是否基于检索内容（非幻觉） | >90% |
| 引用覆盖率 | 事实标注来源的比例 | 100% |
| 端到端延迟 | 检索+生成总耗时 | <3s |
与其他术语的关系
- LLM：大语言模型，RAG 的生成引擎
- Embedding：嵌入，RAG 检索的基础
- Fine-tuning：微调，与 RAG 互补
- Hallucination：幻觉，RAG 是缓解方案
- Token：token，RAG 的成本单位
小结
RAG 是企业 AI 应用最主流的架构：让 LLM 基于你的知识库回答问题，解决知识过时、幻觉、领域不足三大痛点。理解 RAG 的关键要点：
- 三阶段：检索 → 增强 → 生成
- 与 Fine-tuning 互补：RAG 管事实，Fine-tuning 管风格
- 分块是关键：200-500 token，按语义分块
- 混合检索最优：语义 + 关键词 + Reranking
- 可溯源是优势：每条回答标注来源
掌握 RAG，就掌握了企业 AI 应用的核心架构。从 Naive RAG 起步，按需升级到 Advanced RAG，是最高效的实践路径。