上下文窗口与长文本
上下文窗口（Context Window）是大模型一次能"看到"的信息总量，以 token 数衡量。它决定了模型能处理多少信息，是衡量模型实用性的关键指标。本章深入探讨上下文窗口的技术原理、扩展方法和长文本处理的挑战。
上下文窗口（Context Window）是大模型一次能"看到"的信息总量，以 token 数衡量。它决定了模型能处理多少信息，是衡量模型实用性的关键指标。本章深入探讨上下文窗口的技术原理、扩展方法和长文本处理的挑战。
建议完成第 02 章
上下文窗口的演进、长上下文的技术挑战、长上下文扩展技术
能力扩展 · 大模型关键能力
文章导航
点击图中节点可定位到对应正文。
引言
上下文窗口（Context Window）是大模型一次能"看到"的信息总量，以 token 数衡量。它决定了模型能处理多少信息，是衡量模型实用性的关键指标。本章深入探讨上下文窗口的技术原理、扩展方法和长文本处理的挑战。
1. 上下文窗口的演进
1.1 历史增长
| 模型 | 时间 | 上下文窗口 |
|---|---|---|
| GPT-2 | 2019 | 1,024 |
| GPT-3 | 2020 | 2,048 |
| GPT-3.5 | 2022 | 4,096 |
| GPT-4 | 2023.03 | 8,192 → 32,768 |
| Claude 2 | 2023.07 | 100,000 |
| GPT-4 Turbo | 2023.11 | 128,000 |
| Gemini 1.5 Pro | 2024.02 | 1,000,000 → 2,000,000 |
| Claude 3.5 Sonnet | 2024 | 200,000 |
| LLaMA 3.1 | 2024 | 128,000 |
1.2 上下文大小的直觉理解
把公式、变量和含义拆开呈现，便于对照阅读。
4K tokens≈ 3,000 英文单词 ≈ 5 页文档32K tokens≈ 24,000 英文单词 ≈ 40 页文档 ≈ 一本小册子128K tokens ≈ 96,000 英文单词 ≈ 160 页文档 ≈ 一本书1M tokens≈ 750,000 英文单词 ≈ 1,250 页 ≈ 约 5 本书2M tokens≈ 1,500,000 英文单词 ≈ 1 小时视频的字幕2. 长上下文的技术挑战
2.1 计算复杂度
标准自注意力的计算复杂度是 O(n²)，其中 n 是序列长度：
根据原图的箭头、并列、分层与循环关系选择对应图形；可展开核对原文结构。
查看原文结构
序列长度 4K → 注意力矩阵 4K × 4K = 1600 万
序列长度 128K → 注意力矩阵 128K × 128K = 163 亿
序列长度 1M → 注意力矩阵 1M × 1M = 1 万亿根据原图的箭头、并列、分层与循环关系选择对应图形；可展开核对原文结构。
查看原文结构
→ 上下文窗口每翻 10 倍，计算量增加 100 倍2.2 KV Cache 内存
根据原图的箭头、并列、分层与循环关系选择对应图形；可展开核对原文结构。
查看原文结构
4K tokens → ~10 GB
128K tokens → ~320 GB
1M tokens → ~2.5 TB（需要数十张 GPU）2.3 "大海捞针"问题（Needle in a Haystack）
当上下文窗口很长时，模型可能无法准确找到中间位置的信息：
根据原图的箭头、并列、分层与循环关系选择对应图形；可展开核对原文结构。
查看原文结构
表现："U 型曲线"
├── 开头部分：记得好（因为注意力天然关注开头）
├── 中间部分：容易遗忘（"中间迷失"现象）
└── 结尾部分：记得好（因为是最近的输入）3. 长上下文扩展技术
3.1 位置编码外推
问题： 模型的 RoPE 位置编码在训练时只见过一定范围内的位置，超出后性能急剧下降。
解决方案：
| 方法 | 原理 | 效果 |
|---|---|---|
| NTK-aware Scaling | 调整 RoPE 频率使训练位置范围覆盖更大 | 可外推 2-4 倍 |
| YaRN | 结合多种缩放策略 | 可外推 4-8 倍 |
| Dynamic NTK | 根据实际序列长度动态调整 | 自适应外推 |
3.2 稀疏注意力
并非所有 token 对都需要互相计算注意力：
根据原图的箭头、并列、分层与循环关系选择对应图形；可展开核对原文结构。
查看原文结构
标准注意力：每个 token 关注所有其他 token → O(n²)根据原图的箭头、并列、分层与循环关系选择对应图形；可展开核对原文结构。
查看原文结构
组合策略（如 Longformer）：
局部窗口 + 全局 token + 随机采样 → O(n)3.3 Ring Attention
将长序列分割到多个 GPU 上并行处理：
根据原图的箭头、并列、分层与循环关系选择对应图形；可展开核对原文结构。
查看原文结构
通过环形通信（Ring Communication）交换 K/V
→ 每个 GPU 只需要存储 1/4 的 KV Cache
→ 理论上可以无限扩展上下文3.4 线性注意力
将注意力的 O(n²) 复杂度降到 O(n)：
根据原图的箭头、并列、分层与循环关系选择对应图形；可展开核对原文结构。
查看原文结构
标准注意力：softmax(QK^T)V → O(n²d)
线性注意力：φ(Q)(φ(K)^TV) → O(nd²)根据原图的箭头、并列、分层与循环关系选择对应图形；可展开核对原文结构。
查看原文结构
φ 是核函数近似
→ 当 d < n 时（即序列很长时），线性注意力更快4. 实际应用中的长文本策略
4.1 分块处理（Chunking）
根据原图的箭头、并列、分层与循环关系选择对应图形；可展开核对原文结构。
查看原文结构
长文档 → 分成多个块 → 分别处理 → 汇总结果4.2 层次化摘要
根据原图的箭头、并列、分层与循环关系选择对应图形；可展开核对原文结构。
查看原文结构
长文档
├── 第 1 章 → 摘要 A
├── 第 2 章 → 摘要 B
└── 第 3 章 → 摘要 C
↓
[摘要 A + B + C] → 全局摘要
↓
用户问题 → 在全局摘要 + 局部摘要中检索 → 回答4.3 RAG + 长上下文
将 RAG 与长上下文结合使用：
- RAG 负责从海量文档中检索相关内容
- 长上下文窗口负责同时理解多个检索结果
- 二者互补：RAG 解决"信息过多"，长上下文解决"单次理解深度"
5. 不同场景的上下文需求
| 场景 | 需要的上下文 | 推荐方案 |
|---|---|---|
| 简单问答 | 4K-8K | 任何模型 |
| 代码分析 | 32K-128K | Claude 3.5 / GPT-4 Turbo |
| 文档分析 | 32K-200K | Claude 3.5 Sonnet |
| 书籍理解 | 128K-1M | Gemini 1.5 Pro |
| 视频理解 | 1M-2M | Gemini 1.5 Pro |
| 代码库分析 | 128K-1M | Claude 3.5 + RAG |
6. 本章小结
| 要点 | 说明 |
|---|---|
| 上下文窗口 | 从 4K 增长到 2M，仍在快速扩展 |
| 计算瓶颈 | O(n²) 复杂度，KV Cache 内存爆炸 |
| 扩展方法 | 位置编码外推、稀疏注意力、Ring Attention |
| "中间迷失" | 模型对中间位置信息的关注度不足 |
| 实用策略 | 分块处理、层次摘要、RAG + 长上下文 |
相关章节
- Transformer 架构深度剖析 — 注意力机制是长上下文计算瓶颈的根源
- 检索增强生成（RAG） — 长文本处理的替代与互补方案
- 记忆系统 — Agent 如何在有限上下文中管理长期记忆
延伸阅读
- Liu, N.F. et al. (2023). "Lost in the Middle: How Language Models Use Long Contexts". TACL
- Chen, S. et al. (2023). "LongLoRA: Efficient Fine-tuning of Long-Context Large Language Models". ICLR
- Liu, H. et al. (2023). "Ring Attention with Blockwise Transformers for Near-Infinite Context". arXiv