为什么需要 RAG¶
RAG 解决的冲突是：LLM 什么都知道一点，但什么都不够精确——它不是你公司内部的活百科。
这章解决什么问题¶
你打开 ChatGPT，问了一个关于你们公司内部流程的问题。它回答得非常有条理、非常自信，但——完全是错的。
这不是模型笨，而是它根本没见过你们公司的文档。LLM 的知识来自训练数据，而训练数据不可能包含你的私有信息。
那么，把整本产品手册塞进 Prompt 行不行？有两个问题：
- 上下文窗口有限——OpenAI 的上下文窗口从 8K 到 200K token 不等，但一本产品手册可能有几十万 token
- 信息密度不均——用户只想知道「怎么重置密码」，但你需要从几万字的文档里找到那一行
RAG 的思路就是换一个角度：不把所有文档塞进 Prompt，而是先找到最相关的那几段，再把它们给模型看。
核心概念¶
LLM 的三个天然局限¶
要理解为什么需要 RAG，先要理解 LLM 本身有哪些做不到的事：
局限 1：知识有截止日期
LLM 的训练数据有一个截止时间。GPT-4o 的知识截止于 2023 年 10 月左右。如果你问「2025 年发布的 iPhone 17 有什么新功能」，它不可能知道，因为训练时这台手机还没发布。
局限 2：看不到私有数据
你的公司文档、产品手册、用户协议、内部知识库——LLM 一概不知。它的训练数据来自互联网公开内容，不包含任何非公开信息。
局限 3：不知道的它会「编」
当 LLM 被问到不知道的问题时，它倾向于自信地给出看起来合理的错误答案。这种现象叫幻觉（Hallucination）。不是模型故意撒谎，而是它的工作机制就是「根据上下文预测最合理的下一个词」。如果没有相关信息，它会预测一个「听起来靠谱」的答案。
RAG 通过提供真实的参考资料来缓解这三个问题：用检索获取最新信息、用私有知识库补充模型盲区、用原文减少编造空间。
RAG 解决什么、不解决什么¶
RAG 擅长解决的场景
- 知识问答：用户问什么，你正好有文档
- 客服支持：基于产品手册回答用户问题
- 文档解读：从长篇合同中提取关键条款
- 私有数据处理：公司内部文档、研究报告、用户协议
- 知识库查询：结合已有数据库进行问答
RAG 不适合的场景
- 知识库里没有的内容：检索不到就是检索不到，RAG 变不出来
- 需要深度推理的问题：RAG 提供素材，但多步推理靠模型自身推理能力
- 格式转换 / 风格迁移：不需要外部知识，直接 LLM 即可
- 极低延迟场景：RAG 多一次检索调用，增加几十到几百毫秒
- 高频更新的知识：知识库更新不及时，RAG 反而给出过时答案
RAG vs 微调 vs 长上下文模型¶
| 维度 | RAG | 微调 (Fine-tuning) | 长上下文模型 |
|---|---|---|---|
| 知识更新 | ✅ 改知识库即可 | ❌ 需重新训练 | ✅ 直接塞入新内容 |
| 知识删除 | ✅ 删除知识库条目 | ❌ 无法「忘记」 | ✅ 不塞即可 |
| 知识透明度 | ✅ 可追踪来源 | ❌ 知识嵌入参数中 | ✅ 上下文可见 |
| 一次性成本 | 低（搭知识库） | 高（训练 + 标注数据） | 低 |
| 运行成本 | 中（检索 + 生成） | 低（只需生成） | 高（越长越贵） |
| 延迟 | 中 | 低 | 低 |
| 适合 | 知识密集型场景 | 能力/风格调整 | 长文档一次性分析 |
最小示例：一个具体场景的对比¶
假设你是一家 SaaS 公司的客服，用户问：「我们的订阅套餐能随时取消吗？」
不用 RAG：
``` LLM 凭训练数据回答： 大多数订阅服务都可以随时取消。建议你登录账户查看设置页面。
→ 错误！你们公司的政策是年付套餐只能 30 天内取消。 ```
用 RAG：
``` 用户问题：我们的订阅套餐能随时取消吗？
检索到的资料片段： "月付套餐可以随时取消，取消后下个计费周期不再扣费。 年付套餐在购买后 30 天内可以取消，超过 30 天需联系客服协商， 按剩余天数比例退款。"
LLM 生成的回答（基于资料）： 根据我们公司的订阅政策（来源：服务条款 - 取消政策）：
- 月付套餐：随时可取消，次月起不再扣费
- 年付套餐：购买后 30 天内可取消，超过 30 天需联系客服处理
需要我帮您操作取消吗？ ```
常见误区¶
误区 1：RAG 就必须用向量数据库
向量数据库是为大规模检索设计的工具。如果你的知识库只有几百条，用内存计算或 BM25 传统搜索也能实现 RAG。工具的选择取决于规模，不是定义。
误区 2：有了 RAG 模型就不会产生幻觉
RAG 能降低幻觉，但不能根除。如果检索回来的资料与问题无关，或者 LLM 忽略了资料里的信息，幻觉仍然可能出现。生成阶段的 Prompt 设计同样重要。
误区 3：RAG 不需要专门设计 Prompt
资料怎么拼、要不要标来源、先写资料还是先写问题——这些 Prompt 编排细节直接影响回答质量。一句「基于以上资料回答」和详细的约束条件，效果差别很大。
误区 4：既然有长上下文模型了，RAG 就不需要了
长上下文模型能一次性塞入更多内容，但「能塞」不等于「能找到」。研究表明，当上下文长度超过一定阈值后，模型对中间部分信息的关注度会显著下降。RAG 通过只保留最相关的片段来解决这个问题。
延伸阅读¶
- RAG 总览 —— 回到模块入口
- 什么是 LLM —— 理解 LLM 的能力和局限
- 为什么模型会胡说 —— 深入理解幻觉现象
- Chat、Copilot、Agent 与 Workflow —— RAG 与工具调用的协作
练习题¶
练习：为你的工作场景设计 RAG 方案
想一个你自己工作或学习中「需要频繁查资料」的场景，回答以下问题：
- 你的知识库来源是什么？（文档、Wiki、数据库、聊天记录？）
- 这些资料多久更新一次？更新后是否需要立刻反映在回答中？
- 用户最常问的 3 类问题是什么？
- 如果这些问题的答案就在知识库里但模型回答错了，最可能是哪个环节出了问题？
参考思路
- 如果知识库更新频繁（如产品手册每周更新），RAG 比微调更适合
- 如果用户的问题集中在少数几个主题上，可以针对性地优化切分策略
- 回答出错的常见原因：检索没找到正确片段（切分/Embedding 问题）> LLM 没正确使用资料（Prompt 问题）> 资料本身过时