上下文长度军备竞赛：为什么填满窗口是错误的目标

每隔六个月，就会有一款配备更大上下文窗口的模型问世。GPT-4.1 达到了 100 万 Token，Gemini 2.5 紧随其后，达到 200 万，而 Llama 4 如今更是号称支持 1000 万 Token。隐含的承诺是：把所有内容都塞进去，不用再纠结该放什么，让模型自己搞定。

这个承诺在生产环境中站不住脚。一项 2024 年针对 18 个主流 LLM 的研究发现，随着输入长度增加，每一个模型的性能都出现下降——不是某些模型，而是每一个。上下文窗口是天花板，而非地板。把它当作地板来用的团队，正在以痛苦的方式发现这一点。

"上下文腐败"究竟是什么样的

Chroma 研究团队创造了"上下文腐败"（context rot）这个术语，用来描述一种普遍规律：无论相关信息是否存在，随着上下文长度的增长，LLM 的准确率会持续下降。仅仅检索 20 个文档（约 4000 个 Token），准确率就可能从 70–75% 的区间跌至 55–60%。这不是微小的退化——这是一种失效模式。

其机制源于架构本身。Transformer 注意力机制的计算复杂度是二次方的。在 10 万个 Token 时，模型需要处理大约 100 亿对的配对关系。注意力权重被稀释。语义相似但不相关的内容会主动干扰模型，而不是被过滤掉。更多的上下文意味着更多的干扰，而非更多的信息。

性能退化也不是渐进式的。模型通常能稳定保持性能，直到触及某个阈值，然后急剧下滑。一个在 5000 个 Token 下能可靠处理简单检索任务的模型，在需要全程专注于 1200 个 Token 进行复杂多步推理时，可能会失效。

"中间丢失"问题尚未解决

2023 年斯坦福大学的一项研究（2024 年发表于 TACL）记录了如今被称为"中间丢失"（Lost in the Middle）的问题。当相关信息被放置在长上下文的中间位置时，模型准确率会大幅下降。这种 U 形性能曲线在各模型中表现一致：开头部分表现强，结尾部分表现强，中间部分则不可靠。

数据触目惊心。早期和晚期上下文的准确率达到 85–95%，而中间部分跌至 76–82%。当 GPT-3.5-Turbo 无法可靠地关注到埋在上下文中间的文档时，其准确率降至 56.1%——甚至比该模型在没有任何文档的情况下直接作答（闭卷测试）的表现还差。

根本原因在于架构设计。大多数现代 LLM 使用的旋转位置编码（RoPE）引入了一种长距离衰减效应：距当前位置越远的 Token，所获得的注意力权重越小。"100 万 Token 上下文"并不意味着模型能对所有 100 万个 Token 同等关注，而是说模型在技术上可以接受这么多 Token，但注意力分布极度不均匀。

这不是一个会被修复补丁消除的 Bug。CARoPE、3D-RPE 和 DoPE 等变体正在逐步解决这一问题，但注意力机制的根本特性仍然偏好最近和最前的内容。信息的位置与信息本身同等重要。

你未曾预料到的延迟与成本

上下文窗口大小在时间和金钱上都有直接的非线性成本。在推理时，模型必须处理上下文中的每一个 Token；在 API 计费时，每个输入 Token 都要计费。这些不是抽象的担忧——它们决定了一个 AI 产品是否具备经济可行性。

提示词缓存对重复的前缀内容有所缓解。Anthropic 的缓存在命中时可将输入成本降低高达 90%，OpenAI 的自动缓存则提供 50% 的节省。但缓存只对静态的、重复的内容有效。每次请求都会变化的动态上下文无法从缓存中受益。

加载中…