模型的上下文窗口这几年一路飙升，从几千 token 到几万、几十万，再到号称百万级。很多人由此得出一个直觉：上下文越长越好，以后把整个知识库、整本书、整个代码库塞进去就行，RAG 这类检索方案要被淘汰了。
这个直觉一半对一半错。“能装下”和“用得好”是两回事。 大量实测(社区复现的 needle-in-a-haystack 类实验、各家模型的长上下文评测)反复显示：随着上下文变长，模型利用信息的能力会以可预测的方式下降。这篇文章讲清长上下文的三类真实失效模式，以及该怎么根据场景做选择。
上下文窗口是“能放多少”，不是“能用好多少”——两者的差距正是本文要讲的。
失效模式一：中间信息被忽略(Lost in the Middle)
这是最著名的长上下文失效模式。把关键信息放在一段长上下文的不同位置做测试，会发现一个稳定规律：模型对开头和结尾的信息记得清楚，对中间的信息容易漏。 上下文越长，中间那段“记忆洼地”越明显。
现实含义很直接：你把一份 20 万字的资料一股脑塞进去，指望模型综合利用全部内容——但埋在中段的那个关键数字、那条关键约束，它很可能视而不见，还答得一脸笃定。这不是模型偷懒，是注意力机制在超长序列上的固有特性。
应对：关键信息别放中间。系统指令、最重要的材料放在开头或结尾；如果必须放长文档，把最相关的片段前置(这本质上又回到了“先检索再喂”的思路)。
失效模式二：干扰内容拉低准确率
第二类失效更隐蔽。就算模型能“找到”信息，上下文里无关内容越多，它的判断越容易被带偏。 塞进去的 50 页里只有 2 页相关，那 48 页不是中性的背景板——它们会稀释注意力、提供误导性的关联、诱发不该有的联想。
一个反直觉的结论：给模型“刚好够用”的精准上下文，往往比给它“全部相关材料”效果更好。 更多的信息不总是更好的信息。这也是为什么一个检索得当、只喂 5 段精准内容的 RAG，常常打得过把整份文档硬塞的长上下文——前者给的是信噪比高的输入。
给“刚好够用的精准上下文”，常常胜过“塞进全部相关材料”——信噪比比信息量更重要。
失效模式三：成本和延迟的隐形税
前两类是质量问题，这一类是钱和时间问题，而且经常被忽略。
- 成本：输入 token 是要付费的。每次请求都塞进 20 万 token，即便有 Prompt Caching 缓解重复前缀，变化部分和缓存写入仍是真金白银。用 RAG 只喂几千 token 相关内容，成本可能是前者的零头。
- 延迟：上下文越长，处理越慢，首字延迟和总时长都上升。交互式场景里，让用户等一份超长上下文处理完，体验很差。
- 窗口上限：再大的窗口也有边界，真实企业知识库可以远超任何窗口。指望“全塞进去”在规模上就不成立。
换句话说，即便长上下文质量够用，无脑用长上下文也是一种浪费——为你其实用不到的信息付费、让用户为此等待。
那到底什么时候用长上下文，什么时候用 RAG
两者不是替代关系，而是各有适用区间。一张表说清：
| 场景 | 更适合 | 原因 |
|---|---|---|
| 单份文档深度问答/总结(几万字内) | 长上下文 | 内容不大，全塞进去省去检索复杂度，还能全局理解 |
| 海量知识库(远超窗口) | RAG | 装不下，必须检索 |
| 需要引用具体来源 | RAG | 检索天然带来源，长上下文难追溯 |
| 知识频繁更新 | RAG | 改数据即可，不必每次重塞 |
| 需要跨全文的全局推理 | 长上下文 | 检索会切碎全局关联 |
| 成本/延迟敏感的高频调用 | RAG | 只喂相关片段，便宜且快 |
| 一次性分析(合同审阅、长文改写) | 长上下文 | 用完即走，不值得建检索 |
一个越来越常见的实践是两者结合：先用 RAG 从海量数据里检索出相关的一批文档，再把这批(可能几万 token)完整喂给长上下文模型做深度综合。检索负责“从大海里捞对的桶”，长上下文负责“把这桶水喝透”。这比纯 RAG(片段太碎)和纯长上下文(装不下、信噪比低)都更稳。
主流实践是结合：RAG 从海量数据捞出相关文档，长上下文再对这批内容做深度综合。
怎么验证你的场景该用哪个
别信“长上下文能力很强”这种笼统说法，拿你的真实任务测：
- 做一个针对性小实验：把关键信息埋在长上下文的不同位置(开头/中间/结尾)，看模型能不能稳定答对。中段掉分明显，就说明你的场景吃“中间被忽略”的亏；
- 对比信噪比：同一批问题，一次喂全文，一次只喂人工挑出的相关段落，比准确率。后者更好就该上检索；
- 算账：按真实请求量，把长上下文方案和 RAG 方案的 token 成本、延迟都算出来。质量接近时，便宜快的胜。
这套验证方法和《如何评测一个大模型》一脉相承——用你自己的数据说话，别用别人的 benchmark 替你决策。
适用人群与常见误区
适合在做 RAG 与长上下文技术选型、或纠结“要不要上检索”的开发者和架构师。几个常见误区：
- “窗口够大就不用 RAG 了”：忽略了中间被忽略、信噪比、成本延迟三笔账。窗口大小解决的是“能不能放”，没解决“用不用得好、划不划算”;
- “上下文越满越好”：恰恰相反，精准的少量上下文往往优于塞满的大量上下文；
- “长上下文模型的官方长度就是有效长度”：标称窗口和“能稳定利用的有效长度”经常有差距，以你自己的实测为准。
常见问题
Q：百万 token 窗口的模型，是不是这些问题都解决了？ A：更大的窗口和更好的训练确实在改善“中间被忽略”，部分模型的长上下文利用率明显提升。但信噪比和成本延迟是结构性的——塞进更多无关内容依然稀释判断、依然更贵更慢。窗口变大降低了“装不下”的问题，没消除“用不好、不划算”的问题。
Q：代码库能整个塞进长上下文让 AI 理解吗？ A：小项目可以，体验很好；大项目会同时撞上窗口上限和信噪比问题。主流工具的做法是代码检索+按需读取，而非全量塞入，思路和 RAG 一致。参见《AI 编程接入现有项目》。
Q：那我该先试长上下文还是先上 RAG? A：内容量小、一次性用，先试长上下文，简单；内容量大、要复用、要来源、成本敏感，上 RAG。拿不准就按上文的三步验证测一测，让数据决定。
小结
长上下文更强吗？在“单份文档、全局理解、一次性任务”上，是；但“能装下”绝不等于“用得好”——中间信息被忽略、无关内容拉低准确率、成本延迟飙升，是三笔逃不掉的账。聪明的做法不是二选一，而是按场景选择，或让 RAG 负责“捞对内容”、长上下文负责“读透内容”。记住一句：给模型刚好够用的精准上下文，几乎总是胜过塞给它一切。