长上下文不是万能钥匙：100万token窗口，为什么你还是填不满

模型厂商标的上下文从32K卷到百万级，很多人第一反应是”那我把整个知识库全塞进去不就行了”。实践中这条路很少走得通，原因不在窗口大小，而在三笔账单。

账单一：注意力是有衰减的

研究里有个稳定的现象叫”lost in the middle”——把关键信息放在超长上下文的中段，模型调用它的概率明显低于放在开头或结尾。也就是说，窗口能装下100万token，不代表每个token都被平等对待。你塞得越满，真正重要的那几句越容易被淹没。

账单二：成本和延迟随长度线性放大

输入token是要计费的，百万token的上下文意味着每轮对话都在为那堆无关内容付费。而且长上下文的首token延迟会明显拉高，交互体验变差。如果这个任务是高频的，账单会非常难看。

账单三：维护性差

RAG方案里知识库更新，你只改一条；全量塞上下文方案里，知识一变就要重新组织超长提示，版本管理迅速失控。

那长上下文该用在哪

它并非没用，恰恰在”跨文档推理”上无可替代。比如把一份合同和它的三份附件一起交给模型找矛盾条款、把整个季度财报和会议记录对照检查——这类需全局把握、无法切片的任务，RAG反而会切断关联，长上下文表现更好。

判断标准很简单：如果答案依赖片段之间的远距离关系，用长上下文；如果答案依赖若干独立事实的检索，用RAG。

一个务实的混合架构

成熟的团队几乎都在混用：先用检索把候选范围从几万条压到几十条，再把这几十条拼进中等长度上下文做推理；只有少数需要全局观的复杂任务才直接上超长窗口。这样既保住精度，又把成本和延迟压在可控区间。

别被窗口数字牵着走。上下文是预算，不是容量。花在刀刃上的token，永远比塞满的token更值钱。