右缘准确率下降：为什么上下文窗口的最后 20% 是个陷阱

200K token 的上下文窗口并不是真正的 200K token 窗口。将其填满，你刚刚付费使用的模型就会悄然变成一个更糟糕的版本——这种退化并非发生在“迷失在中间（lost in the middle）”所预言的中间位置，而是在右侧边缘，也就是近因偏差（recency bias）本应拯救你的地方。包装盒上的标签卖给你的是余量；而硅片卖给你的却是悬崖。

这是一种大多数团队尚未内化的不同失效模式。“迷失在中间”训练了一代提示词工程师（prompt engineers），让他们习惯于将关键指令放在开头，将关键问题放在结尾，坚信首因效应（primacy）和近因效应（recency）能确保信号得以传递。然而，当利用率接近宣称的窗口极限时，这种启发式方法会悄然失效。这种下降并非逐渐的、线性的，也与模型在半满状态下的表现不对称。一旦超过某个随模型而异的利用率阈值，你就进入了一个不同的运行机制，在 30K 时有效的提示词结构在 180K 时会彻底失败。

经济上的诱惑让情况变得更糟。如果你刚刚为百万 token 的窗口付费，那么使用它的压力是巨大的——你会倾倒整个代码库，喂入每一张支持工单，交给它季度财报，并让它找出重点。结果就是，你会得到一个看似推导严密、实则自信错误的答案，而在审计时它会瞬间瓦解。

超越“迷失在中间”：一种不同的失效模式

2023 年最初的 Lost in the Middle 论文发现了一个 U 型性能曲线：模型在上下文的开头（首因偏差）和结尾（近因偏差）是可靠的，而中间部分则会下垂。这一发现足够稳健，以至于成为了提示词工程界的民间法则：系统指令放第一，问题放最后，中间塞入任何你必须提供的内容。

最近的研究表明，这种 U 型曲线仅在窗口填充率低于一半时才成立。Positional Biases Shift as Inputs Approach Context Window Limits (Veseli 等人，2025) 追踪了当你向宣称的上限推进时，曲线是如何变形的。超过 50% 的利用率后，首因偏差会显著减弱。超过 80% 后，曲线根本不再像 U 型。你面对的是一个原始的近因梯度——而且即便这个梯度，其绝对性能底线也远低于短上下文的基准水平。

翻译一下：过了半程点，你就不能再死守“结尾的信息是安全的”这种启发式法则了。结尾仍然是“最不坏”的区域，但“最不坏”并不等同于“好”。整个性能面都向下平移了。

Chroma 的 Context Rot 研究通过对 18 个前沿模型（包括 Claude Opus 4、Sonnet 4、GPT-4.1、GPT-4o、Gemini 2.5 Pro/Flash、Qwen3 变体等）的直白实证研究强化了这一点。随着输入长度的增加，每一个模型都出现了退化。不是部分，是每一个。在 1K token 时保持近乎完美准确度的任务，随着窗口填满，准确度会出现不可预测的跌落。有些模型跌落得缓慢且较晚；有些——尤其是 Gemini 变体——则在很早的时候就表现出剧烈的波动。Claude 的衰减最慢，尽管随着上下文变大，它有时会用拒绝回答来代替答案，这本身也是一种失效。

基准测试到底说了什么

从论文中提取汇总数据是很有价值的，因为营销与现实之间的差距比大多数团队想象的要大。

• RULER (NVIDIA) 测试了 17 个长上下文模型，发现虽然每个模型都宣称至少有 32K token 的上下文，但只有 4 个模型在 32K 时通过了定性性能阈值。其余模型在达到宣称的最大值之前就早已跌破及格线。论文提出了一个非常有用的术语——有效上下文长度（effective context length）：即你的模型在处理实际任务时的准确度不再可靠的那个临界点。
• NoLiMa 移除了“大海捞针（needle-in-a-haystack）”测试中容易被利用的字面关键词匹配捷径，并重新测试了 13 个宣称至少有 128K 窗口的模型。在 32K 时，13 个模型中有 11 个已经跌破了其短上下文基准性能的 50%。GPT-4o 作为表现最好的模型之一，在 32K 时也从短上下文的 99.3% 下降到了 69.7%。大多数模型永远无法接近其宣传的窗口利用率。
• Chroma 的上下文腐烂（context rot）分析显示，在所有测试的 18 个模型中，连贯、逻辑有序的文档实际上比打乱顺序的版本更损害检索准确度。连贯性会以某种方式集中注意力，从而使干扰项更具诱惑力。而随机性反而打破了这种魔咒。
• 来自 Databricks 的长上下文 RAG 基准测试显示，知名模型在非常特定的阈值处发生退化：Llama-3.1-405B 在超过 32K 后开始衰减，GPT-4-0125-preview 坚持到了 64K，而较新的 Claude 和 GPT 变体将拐点向后推了，但并未能消除它。

所有这些研究都呈现出一个模式：退化并非逐渐发生的。性能起初保持近乎完美，然后突然崩塌。一个额定 200K 的模型在处理非琐碎任务时，通常在超过约 130K（约为宣称上限的 65%）后就变得不可靠。一个额定 1M 的模型通常在超过 200K–300K 后就变得不可靠。你为之付费的宣传窗口的最后一部分，其实根本无法正常工作。

为什么右边缘会特别失效

有三种机制共同导致了右边缘性能下降，理解这些机制能让你预测特定部署的表现。

注意力稀释 (Attention dilution)。 Softmax 注意力会将权重归一化为所有 token 的概率分布。随着窗口被填满，每个单独 token 的权重都会缩减。位于 950K 位置的一个相关句子正与 999,999 个干扰 token 竞争。信号并没有增长 —— 而是底噪升高了。相关的片段仍然在那里，只是模型无法透过迷雾找到它。这就是为什么连贯的文档反而有害：连贯性会产生密集且看似合理的干扰项，看起来很像答案。

位置编码衰减 (Positional encoding decay)。 大多数现代开源模型使用某种形式的旋转位置嵌入 (RoPE)。RoPE 具有内置的长期衰减特性：两个 token 之间的距离越远，位置信号对它们的关联就越弱。前沿实验室通过各种插值 (interpolation) 和外推 (extrapolation) 技巧来扩展其宣称的上下文窗口，但这些技巧并不能干净利落地扩展有效窗口。这种扩展有时只是审美上的 —— 模型可以处理这些 token，只是无法可靠地将它们相互关联。

接近上限时的偏置偏移 (Bias shift near the ceiling)。 这是 Veseli et al. 的发现：一旦接近极限，通常保护 prompt 顶部的首因效应 (primacy bias) 就会消退。模型的有效注意力会向尾部塌缩。结合尾部本身的注意力稀释，你会遇到这样一种情况：窗口最后 10% 到 20% 的区域 —— 本应由近因效应 (recency bias) 确保安全的区域 —— 反而成了模型在绝对意义上表现最不稳定的区域。结尾仍然比中间好，但 180K 时的中间已经比 50K 时的中间更差了，所以“比中间好”并不是一个很高的标准。

实际结果是：右边缘掉队不是一个 bug，而是三种失败模式的交汇。你无法通过单一的提示词技巧来修复它。

按任务类型划分的安全边际

你应该根据任务难度，在脑海中为实际使用的广告窗口比例设定一个预算。随着模型的改进，具体的数字会发生变化，但排序是稳定的，且目前的粗略量级是站得住脚的。

• 精确字符串检索 (“找到这个 token”)。 最接近完美的长上下文任务。在准确率开始波动之前，假设你可以在前沿模型上使用大约 80% 的宣称窗口。这是大多数模型卡片隐式报告的基准。
• 语义检索 (在没有关键字匹配的情况下，找到回答该问题的段落)。 这是 NoLiMa 测试的内容。预算控制在宣称窗口的 40–50% 左右。许多模型在这种任务上，还没达到 32K 之前，其短上下文准确率就已经减半了。
• 多跳推理 (结合来自上下文中三个不同区域的事实)。 预算控制在 25–35%。每一次跳转都会复合检索失败率，因此错误是乘法堆叠的。200K 的窗口变成了 50K 左右的有效上限。
• 聚合与计数 (“这个日志中 X 出现了多少次”)。 最折磨人的类别。准确率在超过宣称窗口的 10–20% 后就可能崩塌。如果你有一个 1M token 的日志需要计数，模型可能是错误的工具 —— 你需要的是 SQL 或正则。
• 跨大型仓库的代码理解。 取决于具体任务，但假设为 30–40%。代码具有密集的交叉引用，即使表面任务听起来像检索，也会触发多跳失败模式。

这些是生产环境的保守默认值。根据你的评估 (evals) 结果来调整它们，而不是因为你的供应商营销页面更新了就去调整。

推论：如果在 200K 模型上，你进行多跳工作的实际有效预算约为 80K 上下文，那么使用较小的模型配合积极的检索，通常比使用塞满窗口的大型模型更便宜且更准确。大窗口的价值在于作为对抗上下文管理 bug 的缓冲区，而不是作为上下文管理的替代品。

当你确实需要用到大窗口时的提示词重构

有时你确实需要深入窗口的后半部分 —— 漫长的法律文件、整合的智能体状态、密集的会话历史。一些重构技术可以恢复可用的准确率，即使在有余量的情况下，作为一种规范也值得应用。

重复两次问题。 将指令放在顶部 —— 这样模型在阅读时就知道要找什么 —— 并在上下文的最底部再次重申。在高利用率下，首因效应减弱，因此你在短上下文中使用的仅置于顶部的布局不再足够。结尾的重申利用了在接近极限时依然强劲的唯一偏置。

缩短尾部。 如果你必须填满窗口，请保留最后一部分 —— 大约最后 5–10% 的 token —— 用于存储小体积、高精度的内容：问题、Schema、输出格式、允许使用的工具简表。不要让大宗文档挤进最后一段。尾部是珍贵的带宽，要慎重对待。

刻意打破连贯性。 Chroma 的发现（打乱的“大海捞针”表现优于连贯的）虽然反直觉但很有用。如果模型总是锁定在错误的、看似合理的段落上，考虑插入清晰的分节符 (--- DOCUMENT 14 ---)，甚至随机化检索包内的文档顺序。目标是防止上下文的叙事性绑架模型的注意力，使其偏离实际任务。

优先选择结构化数据而非散文。 在长上下文中，带有标签字段的 JSON、Markdown 表格和 XML 标记的部分，其表现明显优于信息密度相同的纯散文。当位置信号衰减时，结构化 token 充当了注意力机制可以捕捉的锚点。这种效果在 100K 时比在 10K 时更明显。

递归地进行总结和再总结。 对于多轮智能体循环，不要让原始历史无限制增长。将旧的回合压缩成简练的状态描述。你节省的 token 会将你的工作区域移回窗口的左半部分，那里整个性能表现更好。这就是 Anthropic 上下文工程指南的真正核心：目标不是用完窗口，而是让你的工作区域保持在窗口中有效的部位。

在实际任务中运行三种长度的评估。 短 (1K–4K)、中 (25K–50K) 和长 (宣称窗口的 80%)。如果你无法解释自己准确率曲线中的拐点，你就不知道自己的有效上下文在哪里结束，这篇文章中的任何预算数字都只是别人对你问题的猜测。

总结

在 2023 年中期到 2025 年中期之间，上下文窗口每年大约增长 30 倍。这确实非常有用 —— 100 万 token 的窗口已经存在，并且能完成 4K token 窗口无法做到的事情。但将宣传的上限视为你的可用上限，是目前生产环境 LLM 开发中最常见、也是代价最高昂的错误。标签告诉你模型 处理 了什么；有效上下文则告诉你模型 利用 了什么。

据此制定预算。测量你自己的拐点。保持提示词末尾部分的简洁与珍贵。如果你发现自己正打算将一个 90 万 token 的数据块塞进模型，仅仅因为发票显示你为此付了费 —— 请记住，窗口最后的 20% 是最有可能向你撒谎的部分。