为什么你的128K上下文窗口实际上不是：中部遗漏问题及如何衡量你真正拥有的容量

宣传的与可用上下文之间的差距比大多数团队意识到的要大

你的语言模型供应商声称有128,000个token。但你实际获得的——模型能可靠使用的信息——通常只是这个数字的一小部分。这个差距不是舍入误差。这是一个能工作的系统和一个在坚持掌握所有事实的同时自信地产生错误答案的系统之间的区别。

这不是一个新问题，但当组织在预算编制、模型评估或构建检索增强生成（RAG）系统时，仍然难以考虑到这一点。架构与你作对，不是因为模型本身有问题，而是因为注意力机制在高负载下的表现方式。

中部遗漏现象：研究实际显示的内容

大语言模型倾向于更可靠地使用上下文窗口开头和结尾的信息，而不是中间位置的信息 。这不是微妙的性能下降。这是可测量的、可重复的，并且存在于你现在可能在评估的最先进模型中。

这种效果反映了人类记忆研究中的一个模式： 人们倾向于更准确地回忆研究列表开头（首因效应）和结尾（近因效应）的项目，产生典型的U形曲线 。这种平行不是比喻性的—— 证据指向LLM的内在注意力偏差和架构偏差作为驱动这种行为的机制 。

这在实践中意味着什么？ 更大的上下文窗口不能保证完美的信息检索——它们为更多上下文提供空间，但不能对上下文的每个部分给予同等的关注 。一个拥有128K token的模型仍然可能错过位于第64,000个token位置的关键事实，而如果同样的事实出现在第500个或第127,500个token位置，它会正确处理。

性能断崖实际出现的地方

上下文衰减是指LLM随着输入长度增加而经历的可测量性能下降。Chroma对18个最先进的模型进行了测试，发现每一个都表现更差 。但这种性能下降在不同任务或不同模型间不是均匀的。

最近对5个开源和闭源LLM在数学、问答和编码任务上进行的系统实验显示，即使模型能够完美地检索所有相关信息，随着输入长度的增加，其性能仍会大幅下降（13.9%-85%），而这些长度仍远在模型声称的长度范围内 。

这是关键的区别：模型还没有耗尽token。它没有截断你的输入。它仍在处理你发送的所有内容。然而，当上下文变得更长时，其推理质量会明显下降。 团队经常假设他们的上下文窗口"足够大"。他们选择一个具有128K或1M token的模型，加载它，然后想知道为什么输出质量下降了。上下文衰减解释了原因：容量是错误的衡量标准 。

机制：为什么会这样

模型通常更依赖长上下文窗口的开头和结尾来理解任务并塑造答案 。架构上的罪魁祸首是 诸如RoPE衰减这样的位置偏差 ——这是告诉模型信息在序列中位置的数学编码。随着序列长度增加，模型的注意力模式越来越集中在边界处。

上下文窗口中间的信息与无关文本、重复短语和干扰项竞争 。即使在精心构建、噪声最小的场景中，处理长序列的巨大负荷也会拉低模型对中间部分的关注。

还有一个次要层面： 上下文衰减是随着输入上下文变长而逐渐发生的性能下降——更多的token输入，更差的输出，即使模型的上下文窗口还远未满载 。这不是关于达到硬限制。这是关于信噪比随着你添加token而降低，无论它们是否相关。

如何衡量实际可用的上下文：一个框架

停止将模型的宣传上下文窗口视为保证。开始测量。这是实际评估的样子：

1. 在不同位置进行测试，而不仅仅在容量处

在长度从750字到96,000字的不同文档中嵌入独特的事实，并在不同位置放置该事实以衡量位置如何影响检索准确性 。这复制了实际问题：你不关心模型理论上是否能处理128K token。你关心的是当完整上下文为100K时，它是否能可靠地从第40K位置提取信息。

2. 分别测量检索和推理

仅仅延长输入长度就会实质性地降低LLM的推理能力，即使模型仍能检索相关证据——插入最小干扰的空白不会阻止模型正确提取所有条件，但不过会导致它得出错误的答案 。你的评估需要区分"模型找到了正确的信息"和"模型在推理中正确使用了它"。这两者不是一回事。

3. 用真实噪声进行测试，而不是干净的场景

生产环境中的解决方案包括两阶段检索（宽泛召回+交叉编码器重新排名）、混合搜索（语义+BM25）和战略排序（顶部证据放在开头和结尾） 。但在实施这些修复之前，测量你的模型在有典型干扰项时的表现——冗余分块、过时信息、相互竞争的主张。

4. 对排序策略进行基准测试

最有效的方法是将排名最高的文档放在上下文窗口的开头和结尾，将排名较低的文档放在中间，利用模型的内在注意力偏差而不是与之对抗 。这不复杂。这只是简单地重新排列你的检索结果。但它有效。

对架构决策的实际影响

当团队将过多未过滤的上下文发送到模型并希望LLM能整理出来时，中部遗漏问题会变得更糟。更好的修复从提示组装之前开始：决定哪些上下文是可信的、当前的、相关的，并且具体到足以进入上下文窗口，删除重复块、陈旧定义、弱证据和松散相关的策略 。

这改变了决策框架。你不是在选择32K和128K模型。你是在选择上下文管理开销中的不同权衡。一个具有严格的上下文工程和战略重新排序的32K模型可能会超越一个充满嘈杂上下文的128K模型。

运营成本差异很大。 超载上下文会增加成本。LLM是无状态的，这意味着它们不保留过去对话的记忆——对于你发送的每条消息，整个对话历史都必须发送回模型 。你塞进上下文窗口的每个额外token，无论是否相关，都是你需要付费的token，也是你会产生的延迟。

这对你的团队意味着什么

容量是错误的衡量标准。信噪比是决定输出质量的因素 。当评估模型或构建RAG管道时，将宣传的上下文窗口视为天花板，而不是目标。测量有效上下文——精度对你的用例保持可接受的token部分——并围绕该数字设计你的系统。

测试位置敏感性。战略性地排名你的检索结果。无情地过滤。最重要的是：不要假设具有更大上下文窗口的模型能解决问题。它经常只是让问题变得更大。

指标	衡量的内容	为什么重要
宣传的上下文窗口	最大token容量（例如128K）	仅为上限；不能告诉你任何关于可用性能的信息
有效上下文长度	精度保持在阈值以上的token（例如85%）	你的用例的真实操作窗口
位置敏感性	基于信息放置的精度差异	显示U形降级；指导检索排序策略
有噪声的上下文检索准确性	模型是否在噪声中提取正确信息	将检索与推理隔离；显示问题是架构还是预处理
信噪比	上下文中相关与无关token的比率	比原始上下文大小更能预测输出质量