上下文窗口详解：token、注意力，以及长上下文在哪里失灵

上下文窗口是现代 AI 里被引用最多、却最少被理解的数字之一。一个更大的窗口听上去一概更好，就像更多内存或更多存储听上去更好那样。事情没那么简单。上下文窗口是一个有着真实限制和一种安静失效模式的工作空间，而把它当成无限、完美的记忆，正是团队交付出会神秘地忘掉你三段之前所说之事的系统的方式。

本文用具体的话解释上下文窗口是什么、底层机制为何让长输入既昂贵又不完美，以及如何设计一个尊重这些限制、而非假装它们不存在的系统。

上下文窗口究竟是什么

语言模型不直接读字符或单词。它读的是 token——一块块文本，常常是一个词、一个词的一部分，或一个标点。一个粗略的经验法则是：一个 token 对应几个英文字符，所以一页文本是几百个 token。确切的映射取决于模型的分词器，但原则是稳定的：在模型看到任何东西之前，文本先变成一串 token。

上下文窗口是模型一次能考虑的最大 token 数——你提供的输入加上它生成的输出，共享同一个预算。模型在单次交互中"知道"的一切都活在这个窗口里：你的指令、你粘贴的文档、到目前为止的对话，以及正在写的答案。没有单独的长期记忆。当人们说模型"记得"聊天里更早的内容时，他们的意思是那些更早的文本还在窗口里。某样东西一旦落到窗口之外，模型就完全无从访问它了。

这是第一个经久的洞见：**上下文窗口是短期工作记忆，不是存储。**它不会持久，不会自行增长，而里面的任何东西都不保证会被用到。

注意力：引擎及其代价

要理解长上下文为何困难，你需要对注意力（attention）有点感觉——正是这个机制让模型把每个 token 与其他 token 关联起来。对它处理的每一个 token，模型都会权衡窗口里其他每个 token 应当对它有多大影响。这就是让模型能把一个代词连到它所指的名词、或把一个问题连到埋在文档更早处的相关句子的东西。

至关重要的性质，是那个代价如何增长。因为每个 token 都能关注其他每个 token，工作量大致随 token 数量的平方增长。把输入翻倍，你做的工作不是翻倍——而是大约翻了四倍。这就是为什么处理非常长的输入在时间和金钱上都格外昂贵，以及为什么上下文窗口有一个硬上限、而不是任意地大。这个平方律代价是对长度的一项根本性课税。各种技术能降低它，关于更高效的长上下文方法的研究也活跃且持续，但那股基本压力从不消失：更长的输入，关注起来是超线性地更昂贵。

token 是成本和限制的单位

因为一切都以 token 来度量，token 也是你将撞上的几乎每一个实际约束的单位：

• 你按 token 计费——在托管模型上，输入和输出都算。提示词里一份长文档，每次发送都花真金白银。
• **延迟追踪 token。**窗口里更多的 token 通常意味着更慢的响应，既因为有更多东西要读，也因为生成在争夺同一个预算。
• **窗口是共享的。**一份庞大的输入会给答案留下更少的余地。如果你把窗口塞满上下文，就可能把输出饿死。

由此得出一个实用的习惯：把 token 当成一笔你审慎花费的预算。用"以防万一"的材料给提示词加塞，并不是免费的保险——它花钱、增加延迟，而且正如下一节所解释的，还可能真的让答案更糟。

长上下文在哪里失灵：丢失的中段

这是最让人意外的失效模式。即便文本舒舒服服地装进窗口，模型也不会对它一视同仁地关注。一个被广泛观察到的模式是：模型对长输入开头和结尾的信息，比对埋在中段的信息利用得更可靠。把关键事实放在一份长文档的正中央，模型可能表现得像从没看见过它——尽管严格说来，它就在窗口里。

这意味着，一个大的上下文窗口并不保证模型会用上你放进去的一切。装得下和用得上是两回事。一份规格表上的容量数字告诉你什么装得下；它几乎不告诉你什么会被可靠地用上。

同一个效应解释了团队反复重新发现的一个反直觉结果：把更多文档塞进提示词，可能拉低而非抬高答案质量。更多无关文本稀释了注意力，并把相关部分推得更深、进入中段——那里最容易被错过。对上下文而言，越多不会自动越好，有时反而更糟。

为限制而设计，而非绕过限制

你无法废除这些约束，但你可以这样设计，让它们极少咬到你。统领性的原则很简单：放进去更少，并把对的东西放到它们会被看见的地方。

1. **检索，别倾倒。**与其粘贴整个知识库，不如只取来与当前问题相关的那几个段落，并只包含那些。这是检索增强系统的核心理念，它之所以存在，正是因为把一切都倒进去既昂贵又不可靠。
2. **位置很要紧。**把最重要的指令和最相关的证据放在提示词的开头或结尾附近，别埋在一大块文本的中段。
3. **概括过去。**在一段长对话里，定期把更早的轮次压缩成一段简短的摘要，而非把每个字都往前带。这让显著的事实留在窗口里，而不必把整个预算花在逐字记录上。
4. **给答案留余地。**为输出保留窗口的足够一部分。一个把窗口塞到满溢的提示词，可能截断或劣化响应。
5. **在你真实的长度上测试召回。**如果你的用例涉及长输入，搭一个小评测，把一个已知事实藏进一份逼真文档的中段，检查模型能否取回它。直接测量这个失效模式，而不是假定容量数字会保护你。

一个完整的例子

设想一个从产品手册作答的客服助手。幼稚的设计把整本手册粘进每个提示词，指望那个大窗口来应付。它会慢、会贵，而且——因为相关段落通常在中段某处——不可靠。有纪律的设计把手册建好索引，取出匹配用户问题的那两三个段落，把它们清楚地放在提示词末尾附近，并为答案留下充裕的余地。第二个系统更便宜、更快，而且更准确，尽管它用的只是可用上下文的一小部分。整个教训都在这一个例子里：把窗口用好，胜过把它填满。

总结

上下文窗口是模型的短期工作记忆，以 token 度量，在你的输入和它的输出之间共享。注意力是让它有用的东西，也因为其代价随长度的平方增长，是让它受限的东西。容量数字告诉你什么装得下，而非模型会可靠用上什么——而长输入中段那个被充分记录的弱点，意味着更多文本不等同于更好的答案。据此来设计：检索而非倾倒、把重要的东西摆到会被看见的地方、概括过去、留出作答的余地，并在你真实的长度上测试召回。尊重窗口限制的团队，从中得到的，比那些只是买一个更大窗口的团队更多。

来源说明：上下文窗口的大小，以及扩展它们的具体技术，变化都很快，所以本文聚焦于经久的机理。关于当前的容量和方法，请直接查阅官方模型文档和一手研究。