背景：为什么需要 RAG
大语言模型（LLM）在通用语言能力上表现惊人，但在企业落地时却反复遇到三类问题：知识过时、事实幻觉、私域信息缺失。RAG 正是为了在不重新训练模型的前提下，把最新、最相关、最可信的知识注入生成过程。
从 Prompt Engineering 到 RAG
| 阶段 | 做法 | 优点 | 局限 |
|---|---|---|---|
| Prompt Engineering | 在提示词里直接补充背景知识 | 零成本、见效快 | 上下文长度有限，知识无法动态更新 |
| Fine-tuning | 用领域数据继续训练模型参数 | 风格与领域知识内化 | 训练成本高，知识仍随模型版本固化 |
| RAG | 在生成前检索外部文档片段 | 知识实时、可溯源、可治理 | 需要额外检索基础设施与工程投入 |
RAG 并不是替代 Fine-tuning，而是与之互补：Fine-tuning 负责“模型能力”与“输出风格”，RAG 负责“事实来源”与“动态知识”。
LLM 需要 RAG 的三类场景
知识时效性
- 模型训练数据有截止日期，无法回答“今天股价”“本周发布”类问题。
- RAG 把企业知识库、数据库、API 结果实时接入。
事实幻觉
- LLM 会“自信地胡说”。RAG 通过检索到的原文片段约束生成内容，并提供引用（citation）供用户核验。
私域与专业知识
- 内部文档、设计稿、代码、会议记录不会出现在公网预训练语料中。
- RAG 让这些数据成为可检索的知识源。
RAG vs 长上下文 vs 持续预训练
| 方案 | 核心思想 | 何时选 |
|---|---|---|
| RAG | 检索少量相关片段后生成 | 大多数问答、客服、合规场景 |
| 长上下文（Long Context） | 直接把整本书/整份报告塞进 prompt | 需要全局推理、章节间依赖强的任务 |
| 持续预训练（Continual Pre-training） | 定期用新语料更新模型参数 | 领域术语、语言风格需要深度内化 |
长上下文可以降低检索失误，但无法解决“知识每天都在变”和“私域数据不能公开训练”的问题；持续预训练成本最高，适合 RAG 仍然回答不好的深层领域问题。
RAG 的适用边界
RAG 适合：
- 答案可以从已有文档中推导出来的任务。
- 需要引用来源、可审计的场景（客服、医疗、法律、金融）。
- 知识更新频率高、版本多的业务。
RAG 不太适合：
- 需要大量创造性构思、无需事实依据的生成任务。
- 文档极度稀缺，检索召回几乎为零的场景。
- 对延迟极端敏感且无法容忍检索开销的交互。
典型落地场景
- 企业知识问答：员工手册、技术文档、产品规格。
- 智能客服：基于帮助中心文章回答用户问题，并给出引用。
- 代码助手：检索内部代码库、API 文档后生成调用示例。
- 合规与审计：检索政策条款，判断操作是否符合规定。
- Research Agent：多轮检索、摘要、对比，辅助研究报告生成。
小结
RAG 的出现不是为了“让模型更聪明”，而是为了让模型在回答之前能够查到、选对、用对外部知识。接下来我们将从 chunking、embedding、检索、重排、生成增强到评估，逐步拆解这条流水线的每个环节。