上下文窗口（Context Window）
概述
上下文窗口 (Context Window) 是大语言模型在单次对话中能够记忆和处理的最大 Token 数量。它决定了模型能"看到"和"理解"多少信息。
简单理解：上下文窗口 = 模型的"短期记忆容量"
核心概念
1. 上下文窗口的组成
┌─────────────────────────────────────────────────────────┐
│ 上下文窗口 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 系统提示 │ │对话历史 │ │ 用户 │ │
│ │ System │ │ History │ │ Query │ │
│ │ Prompt │ │ │ │ │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ [========|============|============] │
│ └───────────────────────────────────────────────────┘ │
│ 总 Token 数 ≤ 上下文窗口 │
│ │
└─────────────────────────────────────────────────────────┘
2. 输入 vs 输出窗口
| 类型 | 说明 |
|---|---|
| 输入窗口 | 模型能接收的最大 Token 数 |
| 输出窗口 | 模型能生成的最大 Token 数（通常 < 输入） |
主流模型的上下文窗口
超长上下文模型 (>500K)
| 模型 | 上下文长度 | 发布时间 |
|---|---|---|
| Gemini 2.0 Pro | 2M tokens | 2025.02 |
| Gemini 1.5 Pro | 1M tokens | 2024.02 |
| GPT-5.2 | 1M tokens | 2024.12 |
| Claude 3 | 200K tokens | 2024.03 |
标准上下文模型 (100K-200K)
| 模型 | 上下文长度 |
|---|---|
| Claude Opus 4.5 | 200K |
| Claude Sonnet 4.5 | 200K |
| GPT-4o | 128K |
| GLM-4.7 | 128K |
中等上下文模型 (32K-100K)
| 模型 | 上下文长度 |
|---|---|
| GPT-4 | 32K / 8K |
| Claude 2 | 100K |
| Llama 3.1 | 128K |
小上下文模型 (<32K)
| 模型 | 上下文长度 |
|---|---|
| GPT-3.5 | 16K / 4K |
| 原始 Claude | 9K / 72K |
| Llama 2 | 4K |
上下文窗口的演进
2020 ────── 2022 ────── 2024 ────── 2026
│ │ │ │
2048 → 32K → 128K → 2M
(GPT-3) (GPT-4) (GPT-4 Turbo) (Gemini)
关键里程碑：
| 时间 | 模型 | 窗口大小 | 意义 |
|---|---|---|---|
| 2020.06 | GPT-3 | 2K | 首次大规模应用 |
| 2023.03 | GPT-4 | 32K | 长文本处理 |
| 2023.07 | Claude 2 | 100K | 超长上下文 |
| 2024.02 | Gemini 1.5 | 1M | 百万级突破 |
| 2025.02 | Gemini 2.0 | 2M | 当前最大 |
上下文窗口的作用
1. 代码分析
项目规模 所需窗口 推荐模型
────────────────────────────────────
单个文件 1K 任意
小型项目 50K-100K Claude, GPT-4
中型项目 200K-500K Gemini 1.5
大型项目 1M+ Gemini 2.0 Pro
全库分析 2M+ Gemini 2.0 Pro (需分块)
2. 文档处理
| 文档类型 | 长度 | 所需模型 |
|---|---|---|
| 短文章 | <5K tokens | 任意 |
| 长文章 | 20-50K tokens | Claude 3, GPT-4 |
| 书籍 | 100-500K tokens | Gemini 1.5, Claude 3 |
| 法律文档 | 500K-1M tokens | Gemini 2.0 Pro |
3. 多轮对话
对话轮数 平均Token/轮 总Token 需要模型
────────────────────────────────────────
10轮 500 5K 任意
50轮 500 25K Claude, GPT-4
100轮 500 50K Claude 3
500轮 500 250K Gemini 1.5+
上下文管理技术
1. 滑动窗口
原始上下文: [A][B][C][D][E][F][G][H][I][J]
窗口大小: 4
步骤1: [A][B][C][D]
步骤2: [B][C][D][E]
步骤3: [C][D][E][F]
步骤4: [D][E][F][G]
...
2. 重要性采样
完整上下文: [A][B][C][D][E][F][G][H][I][J]
重要性: ↑ ↑ ↑ ↑
保留: [A][C][E][G][I]
3. 分块处理
大文档: [==== ==== ==== ==== ==== ====]
↓
分块: [块1][块2][块3][块4][块5][块6]
↓
汇总: [摘要1][摘要2][摘要3][摘要4][摘要5][摘要6]
↓
最终: [综合摘要]
4. 向量检索 (RAG)
用户问题 → 向量化 → 检索相关片段 → 添加到上下文
↓
[系统提示] + [检索片段] + [用户问题]
↓
模型回答
超长上下文技术
1. 注意力机制优化
核心问题：传统注意力的复杂度是 O(n²)
| 技术 | 复杂度 | 说明 |
|---|---|---|
| Flash Attention | O(n²) | 优化内存访问 |
| Ring Attention | O(n²) | 块级计算 |
| Linear Attention | O(n) | 线性近似 |
2. 位置编码
| 技术 | 最大长度 | 说明 |
|---|---|---|
| 绝对位置编码 | 2048 | GPT-3 使用 |
| 相对位置编码 | 8192 | T5 使用 |
| RoPE (旋转位置) | ∞ | LLaMA, Gemini 使用 |
| ALiBi | ∞ | BLOOM 使用 |
3. KV Cache 压缩
原始 KV Cache: [==== ==== ==== ==== ====] (占用大量内存)
压缩后: [== == == == ==] (保留关键信息)
上下文窗口的最佳实践
1. 选择合适的模型
| 场景 | 推荐模型 | 窗口大小 |
|---|---|---|
| 简单对话 | GPT-4o-mini, Claude Haiku | 128K |
| 代码审查 | Claude Opus 4.5 | 200K |
| 全库分析 | Gemini 2.0 Pro | 2M |
| 文档问答 | Gemini 1.5 Pro | 1M |
2. 优化上下文使用
- 包含整个文件历史
+ 只包含当前修改的部分
- 重复发送相同信息
+ 使用引用或缓存
- 冗长的系统提示
+ 精简有效的提示词
3. 监控 Token 使用
import anthropic
client = anthropic.Anthropic()
# 检查 Token 使用
response = client.messages.count_tokens(
model="claude-3-opus-20240229",
text="你的内容..."
)
print(f"输入 Token: {response.input_tokens}")
print(f"窗口使用率: {response.input_tokens / 200000 * 100:.1f}%")
上下文窗口的局限性
1. 质量下降
当上下文接近窗口上限时，模型可能：
- 遗忘早期信息
- 回答质量下降
- 出现幻觉
2. 成本增加
Token 数量 ∝ API 成本
3. 延迟增加
上下文长度 → 推理时间
10K tokens → ~2秒
100K tokens → ~10秒
1M tokens → ~60秒+
参考资源
论文
- Transformer-XL - 超长上下文 Transformer
- Ring Attention - 块级注意力
- MegaByte - 百万级上下文
技术博客
文档更新时间：2025 年 12 月
