What is 上下文窗口?

Definition

上下文窗口（也称为上下文长度或序列长度）定义了语言模型在一次交互中能够处理的token总数上限——包括输入提示和生成的输出。拥有4,096 token上下文窗口的模型大约可以处理3,000个英文单词的输入和输出；拥有128,000 token窗口的模型可以处理相当于一本短篇小说的内容。

上下文窗口是在预训练期间固化到模型中的架构约束。它由位置编码方案和注意力矩阵的大小决定。在标准自注意力机制中，内存和计算随序列长度呈二次增长（O(n²)），这就是为什么上下文窗口在历史上一直受到限制。旋转位置嵌入（RoPE）、滑动窗口注意力和FlashAttention等现代技术使上下文窗口从早期模型的2K-4K token增长到最近架构的128K-1M token，同时保持资源使用可控。

对于微调来说，上下文窗口有实际的影响。每个训练样本必须能放入模型的上下文窗口——如果样本超出限制，它将被截断，可能丢失关键信息。训练上下文长度有时可以短于模型的最大值以节省内存（例如，在支持8,192的模型上用2,048 token训练），但代价是微调模型在超出训练长度的序列上可能表现不太可靠。

Why It Matters

上下文窗口决定了模型能实际执行哪些任务。摘要一份50页的文档需要足够大的上下文窗口来容纳整个文档加上摘要。多轮对话助手需要上下文来维护完整的对话历史。对于涉及长文档的企业应用——法律合同、医疗记录、代码库——上下文窗口长度通常是模型选择的决定性因素。此外，上下文窗口限制影响微调经济性：更长的训练样本每批次消耗更多GPU内存，增加训练成本。

How It Works

当文本提交给模型时，分词器将其转换为token ID序列。如果该序列超过上下文窗口，必须截断否则请求将失败。在处理过程中，注意力机制计算窗口内所有token之间的关系——每个token可以关注前面的每个token（在因果模型中）。位置嵌入编码每个token的位置，以便模型理解词序。在推理时，KV缓存存储之前生成token的注意力状态以避免冗余计算，但这个缓存随上下文长度线性增长，对于长序列可能占据GPU内存的主要部分。

Example Use Case

一家法律科技公司构建合同审查助手时发现，他们的平均合同长度为12,000 token。他们选择了拥有32K上下文窗口的基础模型，以轻松容纳完整合同加上系统提示和生成的分析。在微调期间，他们将最大序列长度设置为16,384 token（数据集中最长样本加上安全余量），以平衡训练内存使用和覆盖范围。在生产中，模型一次性处理整个合同，不会因截断而丢失关键条款。

Key Takeaways

• 上下文窗口限制了模型一次能处理的总token数（输入+输出）。
• 现代模型范围从4K到1M token，8K-128K最为常见。
• 注意力内存随序列长度呈二次增长，使长上下文成本高昂。
• 训练样本必须能放入上下文窗口，否则将被截断。
• 上下文窗口长度是文档密集型应用中模型选择的关键因素。