LLM 的知识停在训练截止日，也不了解你的公司内部文档。RAG（Retrieval-Augmented Generation）解决的就是这个问题：先搜相关文档，再让模型基于文档回答。
为什么需要 RAG
用户: "我们公司的年假政策是什么？"
没有 RAG → 模型瞎编一个听起来合理的政策
有 RAG → 检索员工手册 → 基于真实文档回答 → 附引用来源三个典型场景：
- 企业知识库问答：制度、流程、产品文档
- 客服机器人：基于 FAQ 和产品手册
- 代码助手：基于你的代码仓库（Cursor 就在干这个）
完整流程（四步）
离线阶段（提前做） 在线阶段（用户提问时）
┌─────────────────────────┐ ┌─────────────────────────┐
│ 1. 文档分块 (Chunking) │ │ 4. 用户提问 │
│ 2. 向量化 (Embedding) │ │ ↓ │
│ 3. 存入向量数据库 │ │ 5. 问题也向量化 │
└─────────────────────────┘ │ ↓ │
│ 6. 检索最相似的文档块 │
│ ↓ │
│ 7. 文档 + 问题 → LLM │
│ ↓ │
│ 8. 生成回答（带引用） │
└─────────────────────────┘第一步：分块（Chunking）
把长文档切成小段（通常 200~1000 Token）：
员工手册.pdf (50 页)
→ Chunk 1: "年假规定：入职满一年享有 5 天年假……"
→ Chunk 2: "病假规定：每月最多 1 天，需提交……"
→ Chunk 3: "报销流程：填写报销单，附上发票……"分块策略影响检索质量——切太碎丢上下文，切太大检索不精准。
第二步：向量化（Embedding）
每个 Chunk 通过一个 Embedding 模型转成一串数字（向量）：
"年假 5 天" → [0.12, -0.34, 0.56, ..., 0.78] (1536 维)语义相近的文本，向量距离就近。这是 RAG 能「理解意思」而非「匹配关键词」的关键。
第三步：检索
用户问「年假几天」，问题也转成向量，在数据库里找 距离最近的几个 Chunk：
问题向量 → 最近邻搜索 → Top 3 Chunks:
1. "年假规定：入职满一年享有 5 天年假" (相似度 0.92)
2. "福利概述：包括年假、病假、婚假……" (相似度 0.78)
3. "请假流程：提前在系统提交申请……" (相似度 0.65)第四步：生成
把检索到的 Chunk 和问题一起塞给 LLM：
基于以下资料回答问题。如果资料中没有相关信息，请说「我不确定」。
资料：
[Chunk 1 内容]
[Chunk 2 内容]
问题：年假有几天？RAG 的常见翻车点
| 问题 | 原因 | 解法 |
|---|---|---|
| 搜不到相关内容 | 分块不合理 / Embedding 模型不匹配 | 调整 chunk size，换 Embedding 模型 |
| 搜到了但排名低 | 纯向量检索对精确匹配弱 | 加 混合检索（向量 + 关键词） |
| 回答还是不准 | 检索到的 chunk 不够 / 有干扰 | 加 Rerank 重排序，提高 Top-K 质量 |
| 文档更新了但答案没变 | 向量库没更新 | 建立文档变更 → 重新索引的流程 |
和「长上下文」的关系
「模型上下文窗口越来越大了，还要 RAG 吗？」
要。原因：
- 成本：塞 100 页文档进上下文，Token 费用是 RAG 检索的几十倍
- 精度：实验表明，RAG 精选相关段落 > 把整本文档塞进去
- 时效性：RAG 可以实时更新索引，不需要重新训练模型
小结
RAG = 检索 + 生成。先找到相关文档，再让 LLM 基于文档回答。它是目前 让 AI 使用私有数据 最主流、最实用的方案。
下一篇：当 AI 不只会「说」，还会「做」——Agent 入门。