2026 年 4 月，Gemini 3 Pro 把上下文窗口推到 10M token；Opus 4.7 的 1M 窗口已成新标配。Hacker News 上一篇热帖宣称 “RAG is dead”，引来无数同行附议。但翻开生产系统的真实账单和延迟监控，你会发现 RAG 并没有死，反而在新的工具光谱中找到了更清晰的位置。
本文不重复 1M token 的营销话术，而是用第一性原理拆解：长上下文与 RAG 各自解决什么问题、各自的隐藏成本、什么时候该混合使用。
TL;DR
长上下文模型与 RAG 不是替代关系，是不同的工具。长上下文胜在一次性、全局性、小规模任务；RAG 胜在大规模、动态性、可审计任务。生产环境最优解几乎总是混合架构。本文给出 5 个决策维度（数据规模、查询频次、延迟、成本、溯源）与 3 种混合实现模板。
一、RAG 和长上下文到底解决什么问题
要理解两者的关系，先要看清各自解决的本质问题：
RAG 解决的核心问题：把 LLM 接入一个比训练数据更新、更专业、更可溯源的知识源。它有四个组件——文档切分、向量化、检索、生成——但灵魂是”让模型看到原本看不到的东西并能指明来源”。
长上下文解决的核心问题：让模型一次性处理更大的输入。它消除了”切分”的副作用——上下文跨段联想、长程依赖、全局推理变得可行。但它没有解决”如何让模型接触超出请求范围的知识”。
这是关键区别：RAG 是关于知识接入的，长上下文是关于单次请求容量的。混淆这两者，是”RAG 已死”论调的根源。
二、长上下文的隐藏代价
长上下文有四个常被低估的代价：
2.1 单次成本不可忽视
以 Opus 4.7 为例，无缓存的 1M token 输入价 5 美元。哪怕命中缓存（10% 折扣），也要 0.5 美元一次。一个高频查询服务每秒 100 次请求，按 100K 上下文计算：
| 模式 | 单次成本 | 月成本（100 QPS） |
|---|---|---|
| 长上下文（无缓存） | $0.50 | $1.3M |
| 长上下文（90% 缓存命中） | $0.05 | $130K |
| RAG（5K 上下文 + 检索） | $0.005 | $13K |
差距是 10-100 倍。即使缓存策略完美，RAG 在高频场景仍便宜一个数量级。
2.2 首 token 延迟难以接受
256K 输入的首 token 延迟约 8-12 秒（Opus 4.7 实测），1M 输入约 35-50 秒。对实时对话场景这是不可接受的。RAG 把检索 + 生成总延迟控制在 1-2 秒，差一个量级。
2.3 注意力衰减是物理规律
Anthropic 自己在 Opus 4.7 model card 里给出了 needle-in-haystack 数据：
| 上下文长度 | 精确召回率 | 跨文档推理准确率 |
|---|---|---|
| 32K | 99% | 92% |
| 128K | 95% | 84% |
| 512K | 88% | 71% |
| 1M | 76% | 58% |
注意”跨文档推理”那一列——纯检索 needle 还能维持较高水平，但需要综合多个 needle 的推理任务精度衰减更陡。这意味着 1M 上下文在复杂分析任务中实际可用范围是 200-300K，多出来的窗口是”看到了但用不好”。
2.4 调试与溯源近乎不可能
当一个长上下文 prompt 给出错误答案时，你几乎无法定位”哪段输入误导了模型”。RAG 有清晰的 retrieval log，可以追溯到具体 chunk；长上下文给的是一个黑盒答案。对合规、医疗、法律领域，可溯源是硬性要求，长上下文目前无法提供。
三、RAG 的隐藏代价
公平起见，RAG 也有自己的代价：
3.1 切分破坏语义
文档被切成 chunk 时，跨 chunk 的因果关系、长程指代会丢失。即使有 chunk 重叠和层级摘要，仍然不如完整阅读。这是 RAG 在”全局理解”任务上的天然劣势。
3.2 检索质量决定上限
检索召回的 top-K 决定了生成的天花板。embedding 偏向 lexical match，对同义改写、跨语言、抽象概念的召回都有缺陷。一个错误的检索结果，再强的生成模型也救不回来。
3.3 维护成本高
向量数据库、embedding 模型、reranker、chunk 策略——RAG 的栈比看起来复杂得多。一个生产级 RAG 至少需要：
- 持续的 chunk 优化（按文档类型调）
- embedding 模型重训（每 6-12 月）
- 评测集维护（防止性能漂移）
- 多源数据管理（增删改的一致性）
这些维护成本在小规模场景下不划算，导致很多团队转向长上下文也是合理的。
四、5 个决策维度
下面这张矩阵是我在多个生产系统总结出的决策维度：
| 维度 | 偏向 RAG | 偏向长上下文 | 偏向混合 |
|---|---|---|---|
| 数据规模 | >1GB | <200K token | 200K-1GB |
| 查询频次 | >1 QPS | <1 QPM | 介于之间 |
| 延迟要求 | <2s | 可容忍 10s+ | 1-5s |
| 溯源要求 | 强制 | 不需要 | 部分需要 |
| 全局推理 | 不需要 | 必须 | 部分需要 |
例如：
- 客服机器人：数据 50GB，QPS 100，延迟必须 <2s → 纯 RAG
- 季度财报分析：单次 80K 文档，QPM <1，可以等 30 秒 → 纯长上下文
- 代码审查 agent：仓库 500MB，QPM 10，需要溯源到具体文件 → 混合
五、三种混合架构
5.1 RAG-First, Long-Context-Refine
Query → RAG 召回 top-100 chunk
→ Reranker 选 top-30
→ 长上下文（150K）综合生成 → 答案适用场景：知识库大但单次查询需要深度综合。例如法律研究：召回相关案例，再用长上下文写综合意见书。
5.2 Tier-Based Routing
Query → 分类器（"简单事实" / "复杂分析"）
→ 简单 → RAG（top-5 chunk + 短上下文）
→ 复杂 → 长上下文（直接塞入相关全文）适用场景：高频简单 + 低频复杂的混合负载。例如内部知识助手：80% 是”X 项目负责人是谁”这类事实，走 RAG；20% 是”对比项目 A 和 B 的架构差异”，走长上下文。
5.3 Parallel Race
Query → 同时跑 RAG 路径与长上下文路径
→ Judge 模型对比两者答案
→ 输出更好的那一个适用场景：高价值低频任务，允许成本翻倍换准确率。例如医疗诊断辅助：两条路径独立给出建议，对比后输出。
六、长上下文不会”杀死” RAG，但会改变 RAG
回到那个标题：“RAG is dead?” 答案是否定的，但 RAG 的形态确实会改变：
- chunk 会变大：从过去的 512 token 升到 4K-16K，配合长上下文消化更多语境。
- rerank 会更重要：召回 top-K 中 K 从 5 变到 100-500，重排准确率成为新瓶颈。
- 检索会更稀疏：embedding + lexical hybrid 会成为标配，单纯向量检索的份额下降。
- 溯源会强化：每段输出都标注 chunk 来源会成为合规默认要求。
七、给工程师的现实建议
- 不要因为 1M 上下文上线就推翻你的 RAG。先评估成本/延迟/精度，多数情况下 RAG 仍是更好选择。
- 不要把所有 RAG 改成长上下文。这是一种过度反应，且会让账单失控。
- 从混合架构开始。即使一开始 95% 走 RAG、5% 走长上下文，也能在关键长尾任务上拿到提升。
- 建立你自己的评测集。社区 benchmark 不能代表你的业务，10-50 条真实查询的内部评测集比任何外部数据都有用。
- 观测注意力衰减。在你的实际任务上跑 needle-in-haystack 测试，找到模型的”可用上下文长度”。
总结
工具的革新不在于”替代”，而在于”扩展光谱”。1M token 上下文模型让 LLM 工具箱多了一种选项，但 RAG 仍然占据着”接入外部知识、控制成本、提供溯源”的位置。判断的关键不是”哪个更强”，而是”你的查询长什么样”。混合架构是几乎所有生产系统的最终答案，差异只在于混合的比例和策略。