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

每隔六个月，就会有一款配备更大上下文窗口的模型问世。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% 的节省。但缓存只对静态的、重复的内容有效。每次请求都会变化的动态上下文无法从缓存中受益。

大上下文对延迟的影响被严重低估。同等工作负载下，从 RAG 流水线切换到长上下文配置，平均耗时可以从 1 秒飙升至 30–60 秒。首个 Token 的生成时间与正在处理的前缀长度成正比。一个 15 万 Token 的提示词即便有缓存也会更慢，没有缓存则会慢得令人望而却步。

2024 年底至 2025 年中，LLM API 的支出从 35 亿美元翻倍至 84 亿美元。其中有相当一部分，正是团队在朴素地扩大上下文长度而非精心筛选内容所导致的。

"有效"上下文究竟是多少

宣传的上下文窗口与实际有效的上下文窗口是两个不同的数字。一个声称支持 20 万 Token 的模型，通常在 13 万左右——约为宣传上限的 65%——就开始变得不可靠。一个 100 万 Token 的模型，在大约 60–70 万 Token 时仍能保持高质量召回，超过这个范围准确率便会下降。对于需要在全部输入上进行持续推理的复杂任务，部分研究表明有效上下文可能仅是宣传上限的 1%。

"大海捞针"（Needle in a Haystack）这类基准测试衡量的是狭义的词汇检索能力——模型是否能找到文档中隐藏的特定字符串。这是长上下文问题中最简单的版本。真实任务需要理解关系、解决矛盾并跨越多条证据进行推理。NoLiMa 和 AbsenceBench 等变体揭示了简单的"捞针"测试无法捕捉到的显著性能下降。

实用法则：复杂任务应将宣传上下文窗口的 60–70% 作为预算上限，超出部分视为不可靠区域。

精心筛选的上下文优于堆砌的上下文

做得好的团队并不是在 RAG 和长上下文之间作为竞争策略进行二选一，而是在二者之间进行路由。原则是一贯的：少而精的相关上下文，胜过多而杂的含干扰内容的上下文。

EMNLP 2024 关于"Self-Route"的研究——一种让模型自我判断是否需要完整上下文还是聚焦检索的框架——表明：将简单查询路由至聚焦检索、将复杂多跳问题路由至长上下文，在提高准确率的同时降低了计算成本。模型自身，在被赋予选择权时，在上下文足够时会主动选择更少的上下文。

LongLLMLingua 等提示词压缩工具在实现 94% 成本降低的同时，相比未压缩长上下文提升了 21.4% 的准确率。对于那些认为更多上下文等于更好答案的人，这个结果应该令人深思。系统性地移除低价值 Token、保留结构、优先呈现相关内容，在成本和质量两个维度上都优于朴素的堆砌方式。

生产部署最可靠的团队，把上下文当作记忆来对待：精心筛选、持续更新、有边界约束。而不是把它当硬盘：塞满所有可能相关的内容。

上下文工程才是真正的学科

上下文窗口军备竞赛制造了一种有用的幻觉——决定 LLM 应该知道什么这个难题，已经通过给它足够的空间来承载所有内容而被解决了。事实并非如此。这个难题只是被推迟到了推理时，在那里它以质量退化、延迟膨胀和难以调试的静默失败的形式显现出来。

上下文工程——决定什么进入窗口、放在哪里、如何压缩的学科——是区分可靠与不可靠 LLM 系统的更清晰分界线，胜过模型规模、基准分数或宣传的上下文长度。一项针对 1200 个生产部署的 2025 年分析发现，精简的上下文产出更聪明的结果，而那个百万 Token 的窗口是需要保持在其下方的天花板，而不是需要去利用的特性。

实际启示：在评估你的 AI 产品是否需要更大的上下文窗口之前，先审查你当前放入窗口的内容。有多少内容实际上被关注到了？有多少是噪声？如果你移除相关性排名后 50% 的内容，会发生什么？

"我们的模型开始出错了"，答案很少是"我们需要更多上下文"，而几乎总是"我们需要更好的上下文"。