Ch09 Transformer

上下文窗口(深挖)

一句话理解

上下文窗口(Context Window)是模型在一次推理中能”看到”的最大 token 数量。从 GPT-1 的 512 tokens 到 2026 年 Gemini 3.5 Pro 的 2M tokens,上下文窗口的爆炸式增长正在重塑 AI 应用的设计范式——从”如何压缩信息塞进窗口”转变为”如何在更大窗口中组织信息”。

上下文窗口的演进

时间模型上下文窗口关键突破
2018GPT-1512绝对位置编码
2019GPT-21,024更大规模训练
2020GPT-32,048扩展训练长度
2022GPT-3.54,096—
2023 Q1GPT-48K / 32K分阶段训练
2023 Q2Claude 1100K首次突破 100K
2023 Q4Claude 2.1200K—
2024 Q1Gemini 1.5 Pro1M首次突破 1M
2024 Q2GPT-4o128K—
2024 Q3Claude 3.5 Sonnet200K—
2025GPT-5, DeepSeek-V3128K-1M主流 128K+
2026Gemini 3.5 Pro, DeepSeek-V41M-2M1M+ 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 存储 KV2-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 对话需要压缩历史保留完整轨迹

相关笔记

来源

关联8

知识图谱

局部图谱 · 点节点跳转