长上下文时代，RAG 还需要吗

当模型的上下文窗口从 4K 涨到 100K、200K 甚至百万 token，一个流行的论调出现了："直接把所有文档塞进上下文就行了，RAG 没用了。" 这个想法听起来合理（窗口够大干嘛还要检索），但真到生产，答案复杂得多。

一、先承认长上下文确实改变了一些事

长上下文确实解决了过去必须 RAG 才能做的事：

• 一次性读完一两个长文档：以前要切片检索，现在直接塞进去。
• 少样本学习：给几十个示例不用精挑细选，多塞几个。
• 复杂单文档任务：读一份合同/论文做分析，全塞进去比检索准。

对于"文档量不大、能装进窗口"的场景，长上下文让事情变简单了——确实可以不上 RAG。

二、但生产场景，RAG 仍不可替代

可一旦规模上来（几百、几千、几万份文档），全塞就不现实了，RAG 仍然必要。四个原因：

1. 成本。 这是最直接的一击。每次请求把百万 token 塞进上下文，成本是"检索后喂 5K token"的几百倍。一个企业知识库日均上万次查询，全塞 token 费用会爆炸。长上下文的价格随请求数线性增长，RAG 只取相关片段，成本可控。

2. 召回精度（lost in the middle）。 上下文越长，模型对中间内容的注意力越稀释——大量研究证实"中间内容会被忽略"。把 100 份文档全塞，模型未必比"检索出最相关的 3 份"答得准。精准检索 + 少量精喂，质量常常优于全塞。

3. 更新。 知识库会变（文档新增/修改/删除）。RAG 改个数据源、重建索引即可；长上下文要重新准备"塞进去的全量"，且历史会话里的旧内容没法改。动态知识，RAG 天然友好。

4. 可追溯。 RAG 每条答案能追溯到具体文档片段（带引用）。长上下文全塞，模型答了，你不知道它"看了哪段、依据是什么"。需要引用/审计的场景，RAG 不可替代。

三、一张决策表

你的场景是?
├ 文档量小(能进窗口)、单文档深度任务
│    → 长上下文,别上 RAG(简单就好)
├ 文档量大(>窗口)、知识会变、要引用
│    → RAG,别全塞
└ 介于两者之间
     → 混合: RAG 召回 + 必要时把召回的完整文档塞进去

经验法则：文档量 < 10 份、且不常变 → 长上下文够；上百份以上、动态、要引用 → RAG。

四、混合：真正的最优解

生产里最聪明的做法不是二选一，而是RAG 做召回 + 长上下文做精读：

query → RAG 召回最相关的 N 份文档(粗筛)
      → 把这 N 份完整塞进长上下文(精读,不切片)
      → 模型基于完整文档回答

这结合两者优势：

• RAG 解决"从万份里找相关"（成本、召回、可追溯）。
• 长上下文解决"读完整文档不切片"（避免切片破坏语义，质量更高）。

特别是对"多跳推理"（答案要综合几份文档的细节），这种"RAG 选文档 + 长上下文读全文"远优于纯切片 RAG。

五、长上下文的隐藏成本

除了直接 token 费用，长上下文还有几个隐藏成本：

• 延迟。输入越长，首 token 时间越长（prefill 要算更多）。长上下文应用体感更慢。
• 缓存友好度。长上下文如果前缀不稳定，prompt caching 命中率低，成本进一步上升。
• 错误调试更难。百万 token 里模型答错，你不知道是哪段干扰了它。

所以"窗口够大就全塞"在工程上往往不优。

六、RAG 自己也在进化

长上下文在进步，RAG 也在：

• 更好的切分 + rerank，让召回质量逼近全塞。
• 小到-big 检索：召回小片段、喂完整父文档（结合长上下文）。
• Agentic RAG：让 Agent 自主决定"要不要再查、查什么"，弥补静态检索的不足。

RAG 没有被长上下文淘汰，而是和长上下文融合进化。

七、一个常见误判

"我文档不多，用长上下文全塞吧"——听起来省事，但等业务起来：

• 用户量上来，token 账单爆炸（每次请求全塞）。
• 文档开始更新，发现"全塞"的版本管理很乱。
• 要给答案加引用，发现全塞模式下没法追溯。

短期能用，规模化必翻车。 多数项目最终还是要回到 RAG 或 RAG+长上下文混合。

小结

长上下文不是 RAG 的终结者，而是让 RAG 更好的工具。它们各自甜区明确：

• 长上下文：文档量小、单文档深度任务、不常变。
• RAG：文档量大、动态、要引用、要控成本。
• 混合（RAG 召回 + 长上下文精读）：生产场景的最优解。

记住一句：长上下文是"读"的能力变强了，不是"找"的能力变强了。 当知识量大到"装不下"或"找不对"，RAG 仍然是必需——它解决的问题（从海量里找相关）从来没有被长上下文解决。把两者组合用，才是当前生产级 AI 应用的正确姿势。