什么是 Context Window
Context Window（上下文窗口） 是 LLM 一次推理能处理的最大 token 数量，包含输入与输出。
打个比方：
- Context Window = 模型的"工作台大小"
- 工作台太小 → 一次只能放几页资料
- 工作台很大 → 一次能放整本书
用户输入 + 系统提示 + 历史对话 + 检索文档 + 模型输出 ≤ Context Window
主流模型的上下文窗口
| 模型 | 上下文窗口 | 约等于 |
|---|---|---|
| GPT-3 | 2K token | 1500 字中文 |
| GPT-4 | 8K token | 6000 字中文 |
| GPT-4 Turbo | 128K token | 10 万字中文 |
| GPT-4o | 128K token | 10 万字中文 |
| Claude 3 | 200K token | 15 万字中文 |
| Claude 3.5 Sonnet | 200K token | 15 万字中文 |
| Gemini 1.5 Pro | 2M token | 150 万字中文 |
| Gemini 1.5 Flash | 1M token | 75 万字中文 |
| Llama 3.1 | 128K token | 10 万字中文 |
趋势：从 2K 到 2M，3 年扩大了 1000 倍。
上下文窗口的构成
┌──────────────────────────────────────────┐
│ Context Window │
│ │
│ ┌─────────────┐ 系统提示（System） │
│ ├─────────────┤ 用户输入（User） │
│ ├─────────────┤ 历史对话（History） │
│ ├─────────────┤ 检索文档（RAG） │
│ ├─────────────┤ Few-shot 示例 │
│ ├─────────────┤ ← 剩余空间给输出 │
│ └─────────────┘ 模型输出（Output） │
│ │
│ 总和 ≤ Context Window │
└──────────────────────────────────────────┘
关键：输出也占窗口！若输入占 120K，输出只剩 8K（128K 模型）。
上下文窗口 vs 记忆
| 维度 | Context Window | Memory（记忆） |
|---|---|---|
| 时间范围 | 当前一次推理 | 跨会话 |
| 容量 | 有限（K-M 级） | 无限（外部存储） |
| 速度 | 快（模型内置） | 慢（需检索） |
| 实现 | 模型原生 | RAG / Memory MCP |
| 成本 | 占 token 计费 | 外部存储成本 |
关系：Context Window 是"短期记忆"，Memory 是"长期记忆"。详见 Agent 的记忆组件。
为什么上下文窗口重要
场景 1：长文档理解
任务：分析一份 50 页财报
2K 窗口：❌ 放不下，需分块处理
8K 窗口：❌ 放不下
128K 窗口：✅ 全文塞入，一次分析
2M 窗口：✅ 全文 + 历史财报对比
场景 2：多轮对话
对话第 1 轮：用户说了背景 A
对话第 10 轮：用户问"之前说的 A 是什么"
2K 窗口：❌ 第 1 轮已被挤出
128K 窗口：✅ 10 轮全在窗口内
场景 3：RAG
检索到 20 个文档片段，每个 500 token
2K 窗口：❌ 只能放 3 个片段
8K 窗口：⚠️ 放 15 个
128K 窗口：✅ 全放，还有余量
长上下文的挑战
挑战 1：中间遗忘（Lost in the Middle）
研究表明，LLM 对上下文开头和结尾的信息记忆最好，中间的信息容易遗忘：
[开头信息] → 记忆强
[中间信息] → 记忆弱 ← 容易遗漏
[结尾信息] → 记忆强
应对：关键信息放开头和结尾，中间放次要信息。
挑战 2：计算成本
注意力机制复杂度是 O(n²)：
| 窗口大小 | 相对计算量 | 延迟 |
|---|---|---|
| 4K | 1× | 快 |
| 32K | 64× | 中 |
| 128K | 1024× | 慢 |
| 1M | 65536× | 很慢 |
结论：窗口翻倍，计算量翻 4 倍。
挑战 3：费用
| 模型 | 输入价格 | 128K 输入费用 |
|---|---|---|
| GPT-4o | $2.5/1M | $0.32 |
| Claude 3.5 | $3/1M | $0.38 |
| Gemini 1.5 Pro | $1.25/1M | $0.16 |
每次请求塞满 128K，单次成本 $0.16-0.38。
挑战 4：质量下降
过长上下文可能导致：
- 指令遵循能力下降
- 幻觉率上升
- 推理质量降低
应对：不是越长越好，按需使用。
如何选择窗口大小
| 场景 | 推荐窗口 | 模型选择 |
|---|---|---|
| 简单问答 | 4K-8K | GPT-4o-mini |
| 多轮对话 | 32K+ | GPT-4o |
| 长文档分析 | 128K+ | GPT-4o / Claude 3.5 |
| 超长文档 | 200K+ | Claude 3.5 |
| 整本书 | 1M+ | Gemini 1.5 Pro |
| 代码仓库 | 128K+ | Claude 3.5 |
选型原则：
- 够用即可，不盲目追求最大
- 考虑延迟与成本
- 关键信息放开头/结尾
突破上下文窗口的方法
方法 1：RAG
把大文档存入向量数据库，只检索相关片段：
50 页文档（10 万 token）
→ 分块存入向量库
→ 检索 Top-5 片段（2500 token）
→ 塞入 8K 窗口即可
详见 RAG 详解。
方法 2：摘要压缩
先摘要再处理：
50 页文档 → LLM 生成 1 页摘要 → 用摘要做后续分析
方法 3：Map-Reduce
分块处理再合并：
50 页文档 → 分 10 块 → 每块独立分析 → 合并结论
方法 4：滑动窗口
只保留最近 N 轮对话：
对话历史 → 只保留最近 5 轮 → 旧对话丢弃或摘要
方法 5：Memory MCP
用 Memory MCP 把关键信息存入知识图谱，跨会话保持记忆。
常见误区
- 误区 1：窗口越大效果越好。过长上下文会导致"中间遗忘"和质量下降。
- 误区 2：窗口等于记忆。窗口是"短期工作记忆"，跨会话需 Memory。
- 误区 3：塞满窗口最高效。只放必要信息，减少噪声与成本。
- 误区 4：RAG 已过时（因为窗口够大）。RAG 仍更精确、更便宜、可溯源。
- 误区 5：所有模型窗口相同。不同模型窗口差异巨大（2K-2M）。
- 误区 6：输出不占窗口。输出也计入窗口，长输出会限制输入。
与其他术语的关系
- LLM：大语言模型，上下文窗口是其核心参数
- Token：token，窗口的计量单位
- RAG：检索增强，突破窗口限制的核心方案
- Agent：智能体，需管理上下文窗口
- Embedding：嵌入，RAG 的基础
小结
Context Window 是 LLM 的"工作台"：决定了模型一次能处理多少信息。理解它的关键要点：
- 输入+输出都占窗口：别忘给输出留空间
- 中间易遗忘：关键信息放开头和结尾
- 不是越长越好：按需选择，平衡质量与成本
- RAG 仍是主流：长窗口不替代 RAG，两者互补
从 2K 到 2M，上下文窗口的扩展正在重新定义 LLM 的能力边界。但无论窗口多大，精准的信息组织永远是高效使用 LLM 的核心。