RAG 真的过时了吗
从 2024 下半年开始，"RAG is dead" 的讨论在 X 和技术博客上反复出现。但读完一圈下来你会发现：RAG 没死，只是被分流了。三件事同时发生让 RAG 的"必要性边界"在收缩——
① 上下文窗口爆炸
Claude 4 / Gemini 1.5 Pro 已支持 1M+ token 上下文，足够装下一整本厚书。"知识库放不下"这个 RAG 最早的核心理由，对中小型语料已经不成立。
② Prompt Caching 普及
Anthropic、OpenAI、DeepSeek 都上线了 Prompt Caching，缓存命中后输入 token 价格降到 1/10。"重复送 chunk 太贵"也不再是必然问题。
③ Agent 学会自己检索
Claude Code、Cursor、Devin 这类 Coding Agent 几乎不用向量库——它们直接 grep、读文件、调工具。检索从"预处理流水线"变成了"运行时工具调用"。
RAG 的真正护城河
但当语料是海量的、动态的、异构的（千万级文档、每天新增、混合 PDF/扫描件/数据库），向量检索仍是不可替代的入口。RAG 没死，它只是不再是默认答案。
朴素 RAG 的六个结构性痛点
把第 1–10 章学到的东西串起来看，传统 RAG 流水线积累的痛点其实可以归成六类。它们不是"调一调参就能解决"的工程问题，而是架构层面的固有缺陷——这也是替代方向出现的根本原因。
| 痛点 | 表现 | 根因 | 对应替代方向 |
|---|---|---|---|
| Token 消耗大 | 每次查询都要把检索到的 5–10 个 chunk 送进 prompt，长会话场景下 token 烧得飞快 | RAG 是"无状态注入"——每轮对话都重新送一遍上下文 | CAG / Prompt Caching |
| 检索召回率脆弱 | 用户换个问法就找不到答案；多跳推理（"A 引用的 B 提到的 C"）召回率惨不忍睹 | Top-K 向量相似度是"一锤子买卖"，不会迭代 | Agentic RAG |
| 分块即损伤 | 切到第 800 个字符正好跨过一个表格、一段公式、一张架构图的图注 | 切片是为了塞进窗口，但切完就丢了文档结构和视觉布局 | 长上下文 / ColPali 视觉检索 |
| 语义检索撞不到关键词 | 用户搜 "ERR_42103" 错误码，向量检索返回一堆"系统错误概念"的文档，就是不返回那条具体日志 | 稠密向量擅长语义、不擅长精确匹配 | 混合检索（BM25 + Vector，第 6 章已涵盖） |
| 关系查询无能 | "找出所有引用了这篇论文且发表于 2024 年后的工作"——纯向量库没法做 | 向量是欧氏/余弦距离，没有图结构 | GraphRAG |
| 流水线脆弱、调试困难 | 分块 → Embedding → 检索 → Rerank → 生成，任何一环出问题最终答案都烂，但日志看不出来是哪一环 | 线性流水线缺少 self-correction | Agentic RAG / 评估闭环（第 9 章） |
很多人把 RAG token 消耗大归咎于"检索回来的 chunk 太多"。其实真正的浪费在多轮对话：用户在同一个文档上连问 10 个问题，RAG 会把同一批 chunk 重新塞进 prompt 10 次。这不是"该不该 RAG"的问题，而是"为什么我们重复送相同前缀"——这正是 Prompt Caching / CAG 直接解决的场景。下一章 第 12 章 CAG 与长上下文 会展开。
四大替代/进化方向地图
把 2024–2026 年活跃的所有技术路线汇总起来，可以归成四个方向。它们不是互斥的——一个生产系统经常同时用到三个。先看全景：
方向 ① CAG / 长上下文
核心思路：把整个知识库一次性塞进上下文窗口，配合 Prompt Caching 缓存 KV 状态，省掉运行时检索。
解决痛点：Token 消耗大、分块即损伤、流水线脆弱。
适合场景：知识库< 1M token、稳定不常更新（产品手册、法规、内部 wiki）。
方向 ② Agentic RAG
核心思路：把"一次检索"拆成多 agent 协作——查询分解、迭代检索、自验证、反思重检索。
解决痛点：多跳推理失败、召回率脆弱、流水线缺少 self-correction。
适合场景：复杂查询、企业知识图谱、需要跨多个文档综合的研究型问答。
方向 ③ Context Engineering
核心思路：不靠"先建索引再检索"——直接给 Agent 配上 grep / read_file / web_search 等工具，让它运行时自己决定看什么。
解决痛点：分块即损伤、语义检索不精确、流水线脆弱。
适合场景：Coding Agent、个人助手、可枚举的文件系统/代码库。
展开：第 13 章，参考 Cursor 的 @codebase 机制
方向 ④ GraphRAG / 多模态
核心思路：给检索加上"结构"——知识图谱处理实体关系，视觉模型处理排版/图表。
解决痛点：关系查询无能、分块即损伤（特别是 PDF 表格图表）。
适合场景：企业知识图谱、PDF/扫描件密集的领域（医疗、法律、金融研报）。
展开：第 13 章，深入推荐 ColPali 视觉文档检索教程
四个方向的横向对比
| 维度 | 传统 RAG | CAG / 长上下文 | Agentic RAG | Context Engineering | GraphRAG |
|---|---|---|---|---|---|
| 知识库规模 | 千万级 | < 1M token | 千万级 | 可枚举文件树 | 百万级 + 关系 |
| 更新频率 | 分钟级 | 需重建缓存 | 分钟级 | 实时（直接读文件） | 小时级 |
| 单次查询成本 | 中（token + 检索） | 低（缓存命中后） | 高（多轮 LLM 调用） | 中（多次工具调用） | 中 |
| 多跳推理 | 差 | 中（窗口内可推理） | 强 | 强 | 强（图遍历原生） |
| 延迟 | 低（200–500ms） | 低（缓存命中） | 高（5–30s） | 中（1–5s） | 中 |
| 工程复杂度 | 中 | 低 | 高 | 中 | 高 |
选型决策树
没有银弹。下面这棵树把"该用哪个方向"压缩到 4 个问题：
┌─────────────────────────────────────────────────────────┐
│ Q1：知识库总 token 数 < 模型上下文窗口的 80%？ │
│ │
│ 是 ──┬─→ Q2：稳定不常更新（< 每周 1 次）？ │
│ │ 是 ──→ ✅ CAG / 长上下文 + Prompt Caching │
│ │ 否 ──→ ⚠️ 用 RAG，但启用 Caching │
│ │ │
│ 否 ──┴─→ Q3：查询是"找事实" 还是"做研究"？ │
│ 事实 ──→ Q4：需要跨文档关系吗？ │
│ 否 ──→ ✅ 传统 RAG（混合检索） │
│ 是 ──→ ✅ GraphRAG │
│ 研究 ──→ ✅ Agentic RAG │
│ │
│ Q5（独立）：是 Coding Agent / 文件系统问答？ │
│ ✅ Context Engineering（直接读文件） │
└─────────────────────────────────────────────────────────┘
举个例子：一个企业法律助手系统的最终架构很可能是——
① 用 ColPali 处理 PDF 合同（视觉检索保留版式）
② 用 GraphRAG 处理"这个条款引用了哪些先例"的关系查询
③ 用 Prompt Caching 缓存常用法规全文（CAG 思路）
④ 在最外层用 Agentic RAG 编排：分解问题 → 决定调哪个检索源 → 综合答案
所以本章后面两章不是"教你换一种方案"，而是"给你工具箱里多放几把锤子"。
这三章（11/12/13）怎么读
本章（第 11 章）
给你地图和决策框架。读完你应该能回答：我现在的 RAG 系统该不该改？改哪条路？
下一章（第 12 章）
CAG 与长上下文实战。Prompt Caching 怎么打、KV cache 命中条件、CAG 论文的核心结论、token 成本怎么算回本。
第 13 章
Agentic RAG 与 Context Engineering。LangGraph 实现的查询规划 + 自反思检索、ColPali 视觉检索、GraphRAG 实体抽取、Coding Agent 不用 RAG 的工程范式。
站内推荐配套教程
读完这三章后，按你的方向选一个深入：
• Anthropic API（Prompt Caching 第 6 章）
• LangGraph（多 agent 编排）
• ColPali（视觉文档检索）
• DSPy（声明式优化检索流水线）
本章小结
- RAG 没有过时，但它从"AI 应用的默认基础设施"变成了"工具箱里的一种选择"
- 朴素 RAG 的六个结构性痛点：token 消耗、召回率脆弱、分块损伤、关键词丢失、关系查询无能、流水线脆弱
- 四个替代/进化方向：CAG（成本）、Agentic RAG（质量）、Context Engineering（直接性）、GraphRAG/多模态（结构）
- 真实系统往往混合使用，不要把它们看成互斥的"换技术"
- 选型核心问题：知识库大小、更新频率、查询类型、是否涉及关系/版式