上下文窗口与上下文长度
术语上下文窗口和上下文长度经常被用作同义词。如果某个来源对两者加以区分，那么窗口指最大容量，而长度指当前正在使用的数量。
因此，有三个数值值得区分：
- 最大上下文窗口：模型或端点所宣传的容量。
- 当前上下文长度：某个请求及其响应中所占用的令牌数量。
- 可靠可用的上下文：模型能够针对你的任务有效使用的数量。
第三个数值不是固定的规格。它取决于模型、任务、相关细节的位置，以及有多少无关内容在争夺模型的注意力。
上下文窗口如何工作
应用会为请求整理相关内容，其中可能包括：
- 系统指令和开发者指令
- 此前的用户消息和助手消息
- 当前消息
- 检索到的段落或附加文档
- 工具描述和工具结果
- 格式化内容和特殊控制令牌
分词器会将这些内容转换为模型处理的令牌。随后，大型语言模型会一次生成一个令牌来生成响应。每个生成的令牌都会成为生成下一个令牌时可用序列的一部分，因此输出也需要占用空间。
在后续的聊天轮次中，应用通常会再次发送选定的早期内容。它可以保留完整历史记录、删除较早的轮次、仅检索相关段落，或用摘要替换较早的内容。独立的记忆功能可以在请求之间存储信息，但这种存储本身不是上下文窗口。信息必须被带入当前上下文，模型才能使用它。
达到边界时的行为各不相同。API 可能会拒绝超出大小限制的请求；聊天产品可能会删除最早的内容或对其进行摘要；生成过程可能会在达到限制时停止。请查阅适用于具体模型和端点的文档。
一个具体示例
假设某个模型有一个理论上的 12,000 令牌共享上下文窗口：
- 隐藏指令：700 个令牌
- 工具定义：800 个令牌
- 保留的聊天记录和文档：6,500 个令牌
- 当前请求：1,000 个令牌
输入总量为 9,000 个令牌。响应最多还可使用 3,000 个令牌。
现在假设该端点另有 2,000 个令牌的输出限制。尽管共享窗口中还剩 3,000 个令牌，响应最多也只能使用 2,000 个令牌。实际限制取决于最先达到的适用约束。
如果应用将 6,500 个令牌的历史记录压缩为 1,500 个令牌的摘要，输入就会减少到 4,000 个令牌。这样会腾出更多空间，但并不意味着上下文窗口变大了。这只是早期内容的另一种、更小的表示；摘要中省略的细节已不在请求中。
为什么上下文窗口很重要
上下文窗口限制了模型一次可以考虑多少源材料。它会影响你能否在一次请求中提交一份很长的合同、保持长时间对话的连贯性，或为编码助手提供足够多的代码库内容来解决问题。
它还会影响输出规划。如果输入占满了几乎全部可用容量，可能就没有足够空间生成答案。因此，应用通常会在决定加入多少历史记录或检索文本之前，先预留输出预算。
更多上下文也会带来成本。较长的输入通常需要更多时间和计算资源来处理，而且许多 API 按令牌收费。无关上下文可能会让有用证据更难被识别。最好的请求不一定是内容最全面的请求；它应包含足够的相关材料，并为所需响应留出空间。
更大的窗口不等于更好的记忆
上下文窗口衡量的是容量，而不是持久记忆、知识或智能。模型可以接受一段内容，但不一定能同样有效地使用其中的每一部分。
受控的长上下文研究发现，当相关信息位于开头或结尾附近时，模型的表现可能优于相关信息被埋在中间的情况。结果会因模型和任务而异，但实际结论是稳定的：宣传的最大容量告诉你能够装入多少内容，而不代表模型能够完美记住或推理其中的内容。
提示缓存不会改变这一差异。它可能减少重复使用前缀时所需的工作量或费用，但缓存的内容仍可能计入模型的上下文容量。
上下文窗口也不同于知识截止时间。上下文窗口限制的是本次响应期间可用的内容；知识截止时间描述的是训练过程中学到的信息所涵盖的时间边界。
接下来阅读什么
阅读什么是 AI 中的令牌？以了解文本如何计入限制。阅读什么是 LLM？以了解上下文窗口如何融入模型一次生成一个令牌的过程。对于最常与上下文容量混淆的限制，请阅读上下文窗口与知识截止时间的区别。