背景：为什么需要 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 已死？”——2025 年的争论与新结论
2024–2025 年，随着模型上下文窗口从 128K 扩展到 1M+，业界出现“长上下文会杀死 RAG”的论调。2025 年的一批评测给出了更冷静的共识——没有银弹，RAG 与长上下文是互补关系，并在 2026 年上半年进一步巩固：
- 有效上下文小于标称值：NVIDIA 的 RULER 与 NoLiMa 等基准显示，多数宣称 128K 上下文的模型在无位置线索时性能早早衰减——NoLiMa 发现 13 个模型中 11 个在 32K 处就跌到短上下文性能的 50% 以下，CoT 与推理模型也救不回来（NoLiMa, ICML 2025）。
- 成本与延迟差距显著：有 2025–2026 年的实测对比显示，长上下文方案单次查询成本可达 RAG 的约 26 倍；RAG 的延迟基本恒定，长上下文则随输入长度线性增长（IntuitionLabs 对比）。
- 任务类型决定胜负：LaRA（ICML 2025，2326 条用例、4 类任务）表明，长上下文在跨段落比较与推理任务上更强（强模型尤甚）；RAG 在幻觉抑制、恰当拒绝上更稳——长上下文模型更容易“不该答时也硬答”，RAG 的聚焦上下文反而支持正确弃权（LaRA）。
- 生产共识是融合：RAGFlow 的 2025 年终综述把趋势概括为 “From RAG to Context”——用检索做粗筛、用长上下文做精读，配合 Prompt Caching 摊薄长上下文成本（RAGFlow 2025 综述）。到 2026 年，“检索粗筛 + 长上下文精读 + Prompt Caching”已是开源框架模板与新商业产品的默认形态；推理模型普及后思考 token 随输入长度增长，直接把整本语料塞进推理模型的成本进一步抬高，检索粗筛的价值不降反升。
推理时代：从静态 RAG 到 Agentic 检索
2025 年 DeepSeek-R1 之后，推理模型改变了检索的交互方式：
- 模型不再“一次性给出一个查询”，而是在推理过程中自主决定何时检索、检索什么（Search-R1、ReSearch 等工作用强化学习训练这种能力，见 Search-R1）。
- 朴素 RAG 升级为 Agentic RAG：查询路由、迭代检索、子问题分解、检索结果反思成为标配能力；有行业评测显示在 multi-hop 问题上，迭代式 Agent 相比单次 RAG 的准确率可从 34% 提升到 78%，代价是延迟与 token 成本数倍增长（Agentic RAG 综述）。
- Anthropic 在 Claude Code 中弃用早期向量检索、转向 Agentic 的 grep 式交互检索（2025 年 5 月公开分享），被视为这一转向的标志性事件。
到 2026 年，Agentic RAG 已从论文范式变成生产默认形态：Router + 受预算约束的迭代循环进入 LangGraph、LlamaIndex Workflows、Dify 等主流编排框架的标准模板，配套产出是评估对象的改变——从“单次问答”扩展为“检索轨迹”（每轮查询是什么、反思是否有效、停止时机是否合理），以及 grader/critique 节点（对每轮检索结果自动打分）成为循环的标准组件。
因此，本主题所讨论的 RAG，已经不只是“向量库 + LLM”，而是以检索为核心能力之一的 Agentic 知识系统。
RAG 的适用边界
RAG 适合：
- 答案可以从已有文档中推导出来的任务。
- 需要引用来源、可审计的场景（客服、医疗、法律、金融）。
- 知识更新频率高、版本多的业务。
RAG 不太适合：
- 需要大量创造性构思、无需事实依据的生成任务。
- 文档极度稀缺，检索召回几乎为零的场景。
- 对延迟极端敏感且无法容忍检索开销的交互。
典型落地场景
- 企业知识问答：员工手册、技术文档、产品规格。
- 智能客服：基于帮助中心文章回答用户问题，并给出引用。
- 代码助手：检索内部代码库、API 文档后生成调用示例；Agentic 检索（grep、文件浏览）已成为 Coding Agent 的主流知识获取方式。
- 合规与审计：检索政策条款，判断操作是否符合规定。
- Research Agent：多轮检索、摘要、对比，辅助研究报告生成——OpenAI Deep Research、Perplexity 等产品的核心链路都是“搜索 + 推理”循环。
- 视觉文档问答：合同、财报、研报等版式复杂的 PDF，通过视觉检索（如 ColPali）绕过脆弱的 OCR/解析流水线。
小结
RAG 的出现不是为了“让模型更聪明”，而是为了让模型在回答之前能够查到、选对、用对外部知识。2025 年之后，这句话需要加上后半句：还要让模型（或 Agent）自己决定何时查、怎么查、查完信不信；到 2026 年，后半句已经从前沿探索变成工程标配。接下来我们将从 chunking、embedding、检索、重排、生成增强到评估，逐步拆解这条流水线的每个环节。