1M tokens的上下文窗口，是不是意味着RAG过时了？
2026年，Gemini 2.5 Pro支持1M tokens上下文，Claude 4.5支持200K tokens，GPT-5支持256K tokens。这些数字意味着：你可以把整本《三体》三部曲塞进一个Prompt。
于是有人开始说：“RAG已死。直接把所有文档塞进Prompt就好了，为什么还要搞检索？”
但如果你真的把整个公司知识库（50万份文档）塞进Prompt，你会发现：成本爆炸、延迟爆炸、准确率下降。 RAG不仅没有死，反而比以往任何时候都更重要。
实测对比：长上下文 vs RAG
我用一个标准测试对两种方案做了对比：
测试任务：给定2000份技术文档（约500万tokens），回答100个不同难度的问题。
方案A：长上下文——把所有文档塞进Prompt，让LLM直接回答。 方案B：RAG——检索Top-5相关文档，作为上下文让LLM回答。
| 指标 | 长上下文 | RAG | 差距 |
|---|---|---|---|
| 输入Token | 5,000,000 | 5,000 | 1000x |
| 单次查询成本 | $25.00 | $0.025 | 1000x |
| 平均延迟 | 45秒 | 1.5秒 | 30x |
| 准确率（简单问题） | 98% | 97% | 几乎相同 |
| 准确率（复杂问题） | 72% | 85% | RAG胜 |
| 幻觉率 | 12% | 5% | RAG胜 |
关键发现：
- 长上下文的成本是RAG的1000倍。这不仅是钱的问题，更是"能不能规模化"的问题。
- 长上下文在复杂问题上的准确率反而更低。因为LLM在"大海捞针"——500万tokens中找到正确答案，比在5000 tokens中找到更难。
- 幻觉率更高。LLM在超长上下文中更容易"看错"或"编造"信息。
金句：长上下文让LLM"能看见"，但不等于"能看清"。500万tokens的上下文，LLM的注意力被稀释了。
什么时候用长上下文，什么时候用RAG？
用长上下文的场景：
- 单文档分析：分析一份100页的合同，长上下文比RAG更好（不需要担心分块破坏文档结构）
- 代码库理解：分析一个完整的代码仓库（200K tokens以内），长上下文能理解全局依赖关系
- 翻译和校对：需要保持全文一致性的任务
- 创意写作：需要LLM"记住"整篇小说的设定和人物
用RAG的场景：
- 大规模知识库：文档量超过1000份，长上下文的成本不可接受
- 高频查询：每天几十万次查询，长上下文会把账单烧穿
- 需要精确引用：RAG可以精确引用来源，长上下文很难
- 动态更新：知识库频繁更新，RAG可以增量更新索引，长上下文每次都要重新加载
金句：长上下文和RAG不是"二选一"，而是"分工合作"。长上下文处理"深度"，RAG处理"广度"。
混合方案：长上下文 + RAG的黄金组合
2026年的最佳实践是：用RAG做"粗筛"，用长上下文做"精读"。
具体做法：
- RAG检索Top-20相关文档
- 把这20份文档（约20K tokens）完整塞进长上下文窗口
- LLM在"完整文档"的上下文中生成答案
这个方案结合了两者的优势：RAG的"低成本检索"和长上下文的"深度理解"。
实测数据：混合方案在复杂问题上的准确率（91%）超过了纯RAG（85%）和纯长上下文（72%）。
金句：RAG没有死，它只是从"主角"变成了"配角"——负责检索，让长上下文负责理解。