上下文窗口(深挖)
一句话理解
上下文窗口(Context Window)是模型在一次推理中能”看到”的最大 token 数量。从 GPT-1 的 512 tokens 到 2026 年 Gemini 3.5 Pro 的 2M tokens,上下文窗口的爆炸式增长正在重塑 AI 应用的设计范式——从”如何压缩信息塞进窗口”转变为”如何在更大窗口中组织信息”。
上下文窗口的演进
| 时间 | 模型 | 上下文窗口 | 关键突破 |
|---|---|---|---|
| 2018 | GPT-1 | 512 | 绝对位置编码 |
| 2019 | GPT-2 | 1,024 | 更大规模训练 |
| 2020 | GPT-3 | 2,048 | 扩展训练长度 |
| 2022 | GPT-3.5 | 4,096 | — |
| 2023 Q1 | GPT-4 | 8K / 32K | 分阶段训练 |
| 2023 Q2 | Claude 1 | 100K | 首次突破 100K |
| 2023 Q4 | Claude 2.1 | 200K | — |
| 2024 Q1 | Gemini 1.5 Pro | 1M | 首次突破 1M |
| 2024 Q2 | GPT-4o | 128K | — |
| 2024 Q3 | Claude 3.5 Sonnet | 200K | — |
| 2025 | GPT-5, DeepSeek-V3 | 128K-1M | 主流 128K+ |
| 2026 | Gemini 3.5 Pro, DeepSeek-V4 | 1M-2M | 1M+ tokens 成为新标准 |
长上下文的技术挑战
挑战一:注意力机制的 O(n^2) 复杂度
自注意力(Self-Attention)的计算复杂度是 O(n^2),其中 n 是序列长度。对于 1M tokens 的上下文:
这在实际中不可行。解决这个问题的技术路线包括:
稀疏注意力:不是每个 token 都关注所有 token,而是只关注一部分(如 Sliding Window、Longformer 的局部+全局模式)
线性注意力:用核函数近似注意力矩阵,将复杂度降到 O(n)(如 Performer、Linear Transformer)
FlashAttention:通过 IO-aware 的 kernel 融合,在 GPU 上高效计算精确注意力,将内存复杂度从 O(n^2) 降到 O(n)(FlashAttention-3 已支持 1M+ 序列)
Ring Attention:将长序列切分到多个 GPU 上,每个 GPU 计算一段,通过环形通信交换 KV 块
挑战二:KV Cache 的内存爆炸
自回归生成时,每生成一个 token,都需要所有已生成 token 的 Key 和 Value。KV Cache 的内存占用随序列长度线性增长:
对于 GPT-4 级别的模型(96 层,96 头,头维度 128,FP16),1M tokens 的 KV Cache 需要约 180 GB 显存。
KV Cache 优化技术:
| 技术 | 原理 | 压缩比 | 精度损失 |
|---|---|---|---|
| Multi-Query Attention (MQA) | 所有头共享一组 KV | 头数倍 | 小 |
| Grouped-Query Attention (GQA) | 分组共享 KV | 分组数倍 | 极小 |
| KV Cache 量化 | 用 INT8/INT4 存储 KV | 2-4x | 可控 |
| KV Cache 淘汰 | 丢弃不重要的 KV 对 | 动态 | 有(可能丢失信息) |
| LayerSkip | 部分层不存储 KV | 层数倍 | 小 |
挑战三:位置编码的泛化
绝对位置编码(如原始 Transformer 的 sinusoidal)不能泛化到训练时未见过的长度。解决方案:
- RoPE(旋转位置编码):通过旋转矩阵编码相对位置,天然支持外推。2026 年几乎所有主流模型都使用 RoPE 或其变体
- ALiBi:在注意力分数上直接加线性偏置,对长序列外推效果好
- YaRN:在 RoPE 基础上通过频域插值实现更优的外推
挑战四:Lost in the Middle
研究表明,模型对上下文窗口中间位置的信息利用率低,对开头和结尾的关注度最高。这个现象被称为”Lost in the Middle”。
应对策略:
- 将重要信息放在开头或结尾
- 在关键位置插入”检索提示”(如”注意:以下是关键信息”)
- 使用多轮检索,每轮聚焦不同段落
2026 年 1M+ tokens 的实用策略
策略一:信息组织优于信息压缩
在 4K-8K 时代,Prompt 工程的核心是”怎么压缩信息”。在 1M+ 时代,信息组织变得更重要——如何让模型高效地”浏览”大量信息:
- 结构化 Presentation:用标题、层级、索引组织长文档
- 前置摘要:在长文档开头放 200-500 tokens 的结构化摘要
- 分段标记:用明确的标记分隔不同段落,方便模型定位
策略二:渐进式加载
在 1M+ 窗口下,不是所有信息都需要一次性加载。漏斗架构(先摘要后全文)在长上下文时代依然有效,但”摘要”可以更详细(500-2000 tokens),“全文”可以一次加载更多。
策略三:Agent 驱动的多轮检索
Agent 在长文档中执行多轮检索——先扫描目录结构,再定位相关章节,最后精读关键段落。每一步都利用长上下文窗口的”容量”优势,但通过 Agent 的”推理”能力决定读什么。
策略四:成本意识
长上下文 = 更高的 API 成本。1M tokens 输入可能花费 $1-10(取决于模型)。在长上下文时代,“高效利用上下文”的经济学意义比”压缩上下文”更重要。
长上下文 vs 短上下文的应用场景
| 场景 | 短上下文(4K-32K) | 长上下文(128K-1M+) |
|---|---|---|
| 代码补全 | 足够 | 可以加载整个代码库 |
| 文档问答 | 需要 RAG 分块 | 可以直接加载全文 |
| 对话历史 | 需要总结旧对话 | 保留完整对话历史 |
| 长文档翻译 | 需要分段处理 | 一次性翻译整本书 |
| 代码库分析 | 需要 map-reduce | 加载整个 repo |
| 视频脚本分析 | 需要分段 | 一次性分析完整剧本 |
| 多轮 Agent 对话 | 需要压缩历史 | 保留完整轨迹 |
相关笔记
- 第9章 · Transformer 架构精讲 — Transformer 基础
- 注意力机制 (Attention Mechanism) — 注意力机制深入
- Context 工程 — Context 工程
- 漏斗架构 — 漏斗架构(摘要 → 全文)
- 深挖-状态空间模型 — SSM/Mamba(线性复杂度替代方案)
来源
- Dao et al., “FlashAttention-3: Fast and Accurate Attention with Asynchrony and Low-precision” (2024), https://arxiv.org/abs/2407.08608
- Liu et al., “Lost in the Middle: How Language Models Use Long Contexts” (2023), https://arxiv.org/abs/2307.03172
- Su et al., “RoFormer: Enhanced Transformer with Rotary Position Embedding” (2021), https://arxiv.org/abs/2104.09864
- Peng et al., “YaRN: Efficient Context Window Extension of Large Language Models” (2023), https://arxiv.org/abs/2309.00071
- Google DeepMind, “Gemini 1.5: Unlocking multimodal understanding across millions of tokens of context” (2024), https://arxiv.org/abs/2403.05530