原文：
https://towardsdatascience.com/your-1m-context-window-llm-is-less-powerful-than-you-think/

翻译：

@北方的郎

翻译的时候有小的优化，增加了一些论文中的图例

当前最先进的大语言模型（LLMs）已经能够处理极大的输入——它们的上下文窗口范围从 Claude 的 20 万 tokens 到 Gemini 1.5 Pro 的 200 万 tokens，相当于 280 到 2800 页的文本！这些巨大的上下文窗口似乎意味着，在大多数实际场景中，我们无需再担心输入是否会超过模型的能力限制。

然而，我们最新的研究发现：事实并非如此。
对于许多需要复杂上下文的任务来说，大模型的**“工作记忆”**在面对相对较小的输入时就可能出现过载——远早于上下文窗口被填满。

我们的论文提出了一个新的计算理论模型，用以解释为何会发生这种情况，并通过实验证明，该理论的预测与现实中的表现高度一致。这些发现也能解释先前报告中的大模型失败现象，比如：无法发现故事中的情节漏洞、理解长篇文本困难、或者在文档内容相似时回答错误的问题。

接下来我们通过以下几个关键问题来详细展开：

1. 如果超出了大模型的工作记忆，会发生什么？

直觉上，越是需要大量上下文来回答问题的任务，越要求模型能追踪和记住大量信息。随着需要被追踪的信息集（即“工作集”）不断扩大，模型犯错的概率也会迅速上升——因为它无法在有限的工作记忆中保留全部关键信息。

来看一个例子：我们想调试一段代码，判断变量 x7 的最终值是 "a" 还是 "b"：

x6 = "a"
x4 = "b"
x0 = x6
x2 = x4
x3 = x0
x8 = x2
x9 = x3
x7 = x3

这个变量追踪任务需要模型对上下文有完整把握，任何一行被忽略都可能导致错误的结果。我们对多个前沿大模型进行了实验，发现：随着变量数量的增加，它们的表现会退化为纯随机猜测：

LLMs 的性能在需要追踪的变量数量超过 5~10 个后迅速下降，最终逼近 50% 的随机猜测水平。

2. 我的任务是否需要大量工作记忆？

你也许想知道：你的任务是否也会受到工作记忆限制的影响。我们建议首先检查该任务是否类似于我们论文中分析的任务类型。我们将那些在我们的模型中需要大量工作记忆的任务称为 BAPO-hard（后面会解释该模型）。其中包括：

• 图可达性（Graph reachability）：如复杂摘要、实体追踪、变量推导、逻辑推理
• 多数派问题（Majority）：如评论分类、共识判断等
• 三元组推理（Triplet reasoning）：如从知识图谱中生成答案

相对地，也有 BAPO-easy 的任务：

• 最值选择（Min/Max）：如返回评论中最积极/最消极的一条
• 关键词查找（Needle-in-a-Haystack）：判断一个主题是否被提及

简单来说：
如果只需要跟踪一小段信息来回答问题，任务对工作记忆的要求就低（如查找关键词）。但如果答案几乎依赖于所有输入，且无法提前摘要，那么对工作记忆的要求就很高。

若你的任务不在上述列表中，可以自己判断是否可以通过模型的注意机制轻松查找答案，或者是否能在不提前知道问题的情况下进行合理摘要。如果都不行，那么很可能你的任务确实需要大量工作记忆，此时模型很容易失败。请不要以为“答案在上下文中存在”就等于“大模型能找出答案”。

3. 如果我的任务需要大量工作记忆，该怎么办？

如果你发现任务确实需要大量工作记忆，且模型表现不佳，可以尝试以下几种理论上有效的策略：

• 使用支持推理的模型（Reasoning-enabled models），并祈祷它不会提前耗尽 tokens。理论上，推理 tokens 能帮助模型解决任何 BAPO-hard 任务，但实际上所需 token 数量可能非常庞大（我们的实验证明了这一点）。即便是当前最好的推理模型，也会出错。
• 问题分解与简化。根据我们的理论，你可以将任务转化为一个中间表示更紧凑、对工作记忆要求更低的形式。
  例如：不要让模型处理整个 HTML，而是只提供渲染后的纯文本；在 RAG 场景中，也可以先对数据做预注释、预组合，使最终答案可以从更小的摘要中得出。
• 将耗费工作记忆的部分外包给外部工具。
  例如，不要直接问“评论中多数人的观点是什么”，而是先分别对每条评论进行分类（这是 BAPO-easy），再用 Python 汇总结果。

当然，上述方法并非对所有任务都适用，特别是当你无法将任务分解为低工作记忆的子任务时。这正是未来研究的一个重要方向。

4. 为什么某些任务需要大量工作记忆？

这一部分我们深入介绍理论。为分析哪些任务需要更多的工作记忆，我们构建了一个抽象模型来模拟 Transformer 是如何计算解的。通过它，我们可以证明某些任务在计算层面上是“困难”或“简单”的。

举个例子：你读完一本新书后，想回答一个关于它的问题。人类通常有两种策略：

1. 如果你有强大的工作记忆，记住了关键细节，就可以直接回答；
2. 如果记忆有限，只记住了大致情节，就可以翻回书中查找相关信息。

大模型也类似：
Transformer 模型会先读完整本书的内容，然后在看到问题时在“最后位置”给出回答。它可以通过“注意机制”关注书中相关位置（相当于翻页），或者提前将重要信息嵌入上下文中（相当于记住要点）。
但它不能再回过头去，重新带着问题重读整本书——因为因果注意机制（causal attention）只允许信息向前流动。

这意味着：不论人还是 AI，越大的“工作记忆”，越能在复杂情况下找出正确答案。

我们用 BAPO 模型（Bounded Attention Prefix Oracle）来形式化这个过程：

BAPO 模型中，任务的工作记忆由两个参数决定：

• a：前缀记忆带宽，可以预先携带的信息量（等于记住的内容）
• b：注意力带宽，可以回顾的 token 数量（等于可以“翻回去看”的页数）

任务的“工作记忆要求”即为这两个带宽的组合：(a, b)。两者之间存在权衡：你记得越多，就需要回顾越少，反之亦然。

如果任务的带宽需求是常量（即 a, b 属于 O(1)），它一般不会超出 LLM 的工作记忆能力；但若其带宽随输入大小增长（如序列长度、变量个数等），那么它最终就会超出模型能力范围，导致失败。

结论

对于基于 Transformer 的大语言模型来说，工作记忆是一个关键瓶颈。

在信息超过上下文窗口大小之前，Transformer 内部已经无法有效表示和流通这些信息。当前的长上下文评测大多集中在“查找关键词”类任务（即 BAPO-easy），所以无法真实反映模型在复杂推理任务上的表现。

我们的理论模型表明，像复杂摘要、代码追踪、矛盾检测等任务对模型而言是困难的，它们包含 BAPO-hard 子任务，对工作记忆的要求极高，也因此容易失败。

尽管上下文窗口的增长拓展了模型的应用场景，但也让任务本身更复杂，BAPO-hard 任务的比例将上升，从而带来更多失败。

我们提出了一些降低任务工作记忆需求的策略，例如使用推理 token，但它们本身也有局限性。我们期待未来的研究能带来更通用的解决方案，甚至可能探索超越 Transformer 的新架构。

参考资料

• 论文地址：https://arxiv.org/abs/2505.08140
• 代码地址：https://github.com/microsoft/bapo

注：你可能会问，如果一开始就给出问题，会改变任务的工作记忆需求吗？不会——详见论文说明。