上下文窗口（Context window）

什么是上下文窗口

上下文窗口（context window）是模型在生成回答时能够参照的全部文本，回答本身也算在里面，计量单位是 token ^[1]。Anthropic 把它比作模型的工作记忆（working memory），并把它与模型训练时所用的语料区分开来 ^[1]。这个区分很重要：语料是模型此前长期吸收的东西，窗口则是它此刻眼前摊开的那一部分。窗口不是一座知识仓库，而是一件事得以发生的场地。

窗口里装了什么

放进去的东西都占位置：系统提示（system prompt）、每一条消息（包括工具返回的结果）、图片和文档，以及各种工具的定义；这一轮的全部输出同样算数，扩展思考（extended thinking）的部分也在内 ^[1]。举个具体的例子就清楚了。让助手审一份长报告，光是说明要求就消耗掉一些 token，报告本身消耗得更多，助手可能调用的那些工具，其定义也要占地方，最后写出来的答复依然记在同一份额度上。看上去只是一个问题，实际上是层层叠叠的输入在争夺同一份配额。

有多大，卡在哪里

Anthropic 的文档给出的数字是：当前的旗舰模型为 100 万 token 的上下文窗口，较早的模型为 20 万 token；在 100 万 token 的模型上，单次请求最多可输出 12.8 万 token ^[1]。附件另有上限：100 万 token 的模型上，单次请求最多 600 张图片或 PDF 页面，20 万 token 的模型上为 100，且图像占用的 token 与其他输入一样计入预算 ^[1]。这条线是硬性的，不是可以商量的。如果光是输入本身就已经超出模型的上下文窗口，Anthropic 的 API 在所有模型上都会返回 400 invalid_request_error，提示「prompt is too long」^[1]。还有一点容易被误读：被缓存的前缀依然占据上下文窗口，所以缓存改变的是计费方式，而不是提示占用的空间 ^[1]。账单上打了折，窗口并不会因此变大。

塞得多不等于答得好

Anthropic 明确指出，上下文并非越多越好：随着 token 数量增长，准确率和召回率会下降，它把这一现象称为「上下文腐化」（context rot）^[1]。这种退化不只取决于数量，也取决于位置。Liu 等人的研究发现，当相关信息位于输入的开头或结尾时，语言模型的表现往往最好；如果需要它从中间把信息取出来，表现会明显变差 ^[2]。这项研究测试了多文档问答和键值检索两类任务，而且即便是专门为长上下文构建的模型，也能观察到这一效应 ^[2]。所以大窗口描述的是容量，而不是对窗口中每一段内容的均匀使用。放在长提示中间的信息，实际上最容易被漏掉。

为什么值得记住

对使用模型的人来说，上下文窗口是一份需要规划的预算。指令、检索来的文档、工具定义、图片和最终答案都从同一份额度里支出，一旦超出，请求会直接失败，而不是慢慢降级 ^[1]。又因为窗口填得越满准确率越低，中间位置的材料最不可靠 ^[1][2]，所以决定放什么、不放什么、剩下的东西摆在哪里，是设计工作的一部分，而不是事后的补充。规格表上写的那个数字只告诉你上限；模型逼近上限时的表现是另一个问题，而上面两条证据对这个问题给出的回答方向是一致的。