模型在单次对话中可处理的文本最大量（以令牌为单位）。这包括您的输入和模型的输出。如果模型具有200K的上下文窗口，大约相当于15万字—相当于两本小说。
上下文窗口不是存储空间—它是工作内存。窗口中的每个token（你的系统提示、对话历史、粘贴的任何文档以及模型自身的输出）都在争夺相同的固定大小的预算。当人们说Claude有200K的上下文窗口或Gemini支持1M tokens时，这些数字包含了一切内容：输入和输出的总和。一个常见的错误是将上下文窗口当作可以塞满文档的数据库，并期望模型能完美检索。实际上，模型通过注意力机制处理上下文，而注意力机制既有计算上的限制，也有质量上的限制。
"迷失在中间"的问题是真实且有充分研究支持的。来自斯坦福大学等机构的研究表明，当将关键信息放在非常长的上下文中间时，模型在使用这些信息方面的表现明显不如放在开头或结尾的信息。这不是理论上的担忧—它直接影响你应该如何构建提示。如果你给模型输入50页的文档，请将最重要的部分放在开头和结尾，而不是埋在第25页。一些团队通过将文档分块并使用RAG仅检索相关片段，而不是将所有内容都放入上下文中，来绕过这个问题。
上下文窗口的大小已经显著增长。GPT-3于2020年发布时有4K tokens（大约3000个词）。到2024年，Claude提供了200K tokens，而Gemini 1.5 Pro则扩展到了1M tokens。Google的Gemini 2.5模型保持了百万token的窗口。但更大的窗口伴随着真实的权衡。延迟会增加，因为模型必须处理更多的token。成本会上升，因为大多数API提供商按处理的token收费。而且如前所述，检索任务的质量并不随上下文大小线性增长—1M token的窗口并不比200K token的窗口好5倍。
对于使用API的开发人员来说，上下文管理是一个核心的工程问题。长时间的对话会迅速消耗token。一次来回的聊天可能会消耗500–1000个token，这意味着4K token的模型在几次对话后就会用完空间。生产系统通过滑动窗口（丢弃最旧的消息）、摘要（将之前的对话压缩成较短的摘要）或混合方法来处理这个问题，混合方法使用RAG将参考材料卸载到向量数据库中，仅在需要时拉取相关片段。正确处理这一点往往是区分一个能运行的演示和一个能扩展的产品之间的关键。
一个容易让新手混淆的细节：上下文窗口的限制是针对token，而不是字符或单词。分词方式因模型和语言而异。英文文本平均每个token约4个字符，但代码可能更密集（变量名和语法会快速消耗token），而中文或印地语等非拉丁语系通常每个单词使用更多token。同一份文档在英文中可能消耗10K token，在日文中可能消耗15K token。大多数提供商都提供分词工具或库—Anthropic在API响应头中提供了token计数器，而OpenAI发布了tiktoken—因此你可以精确测量，而不是猜测。