Context Window

Context Window 是模型在一次调用里能处理的最大 token 数总和，这个限制来自模型架构的设计——Transformer 的自注意力机制计算复杂度与序列长度平方相关，所以不可能无限扩展。现代大模型的上下文窗口各不相同：Claude 3 系列是 200K token，某些开源模型是 32K，超长上下文的特殊版本能到 1M token。Context Window 既是机会也是约束：机会在于它决定了一次对话能塞进多少历史信息——长窗口意味着能保留完整的多轮对话历史，无需频繁压缩；约束则在于成本和策略。成本上，输入 token 按比例计费，长窗口加载完整历史会增加每次请求的成本；策略上，你需要决定"用滑动窗口保留近期对话"还是"用摘要压缩远期对话"。还有个容易忽视的现象叫"Lost in the Middle"：研究发现模型对上下文开头和结尾的内容最敏感，中间部分的重要信息容易被忽视，所以关键信息要放在对话的起始或末尾。

想象你的短期记忆空间有限——你一次最多能"记住"过去 3 小时的对话。超过这个时间的事就得用笔记（摘要）记下来，否则就永远忘了。如果对话很多，你要么增大记忆空间（付更多钱升级模型），要么定期整理笔记压缩内容。

一个客服 ChatBot 处理用户咨询，从第一条消息到现在已经 50 轮对话，共 8000 token。如果模型的 context window 只有 4K token，新问题加上这 8000 token 会超限，必须先用摘要压缩前面的讨论（如"用户之前问过订单状态、收货地址和退货流程"），才能继续对话；而如果模型支持 200K token，则可以保留完整历史，确保"记忆不丢失"。但完整历史会增加 API 成本，需要权衡。

• → Token / Tokenization· 分词
• → Sliding Window· 滑动窗口
• → Summarization / Compression· 摘要压缩