上下文窗口：从“工作记忆”到能力边界
摘要: 上下文窗口作为 LLM 的「工作记忆」，其容量直接决定了模型处理长文档、多轮对话和大型代码库的能力边界。本文从上下文窗口的基本定义与三种典型应用场景出发，深入剖析了 Attention 机制 O(n²) 计算复杂度对窗口扩展的根本制约，以及 Flash Attention 等工程优化未能改变的数学本质。在此基础上，本文详细讨论了 Lost in the Middle 现象——LLM 对上下文中间位置信息的系统性忽视——及其对 Prompt 设计的实践启示。最后，系统对比了 NTK-aware Scaling、YaRN 和 RoPE 线性插值三种核心扩展技术的原理与适用场景。全文为理解长上下文的性能边界、技术取舍与工程最佳实践提供了完整框架。
1. 定义与意义
上下文窗口（Context Window） 是 LLM 一次能够处理的最大 token 数。它就像模型的"工作记忆"——在这个窗口内的所有信息，模型都可以同时参考；窗口之外的，模型完全不可见。
上下文窗口 = 模型的"视野范围"
窗口边界（如 128K tokens）
┌──────────────────────────────────────────────────┐
│ Token₁ Token₂ Token₃ ... Token 100 ... Token 128000 │ ← 模型能"看到"
└──────────────────────────────────────────────────┘
↑ 窗口之外：模型无法知晓
Token 128001 Token 128002 ...为什么窗口大小如此关键？
三个实际场景说明：
- 长文档分析：分析一份 5 万字的合同，如果窗口只有 4K（约 3000 字），你需要把合同切成十几个片段分批送入，每段之间模型会"忘记"上下文，无法建立跨段落的关联。
- 多轮对话：与你聊了 50 轮，如果窗口不够大，模型只能"记住"最近几轮，前面的对话内容会被"遗忘"。
- 代码库理解：一个中等项目可能有几十万行代码。128K 上下文才能让模型一次性理解整个项目的结构。
3. 上下文窗口与注意力复杂度的关系：O(n²) 难题
上下文窗口并非越大越好，因为标准 Attention 机制的计算量和显存占用随 token 数平方级增长：
Attention 计算 QKᵀ 矩阵：
n = 4K tokens: 4096 × 4096 = 16,777,216 次点积运算 (~1,670 万)
n = 32K tokens: 32768 × 32768 = 1,073,741,824 次 (~10 亿)
n = 128K tokens: 131072 × 131072 = 17,179,869,184 次 (~171 亿)
n = 1M tokens: 1,000,000² = 1,000,000,000,000 次 (~1 万亿！)
每层都要算一次！x 96 层（GPT-3）→ 天文数字QKᵀ 矩阵大小示意图：
n=4K ████ (小方块)
n=8K ████████
n=16K ████████████████
n=32K ████████████████████████████████
n=1M ██████████████████████████████████████████████... (巨大)
← 边长 = token 数，面积 = token 数² = 计算量 →
图中每个像素代表一对 token 之间的一对注意力分数计算这就是"长上下文 = 贵"的根本原因。
处理 128K token 上下文的计算量是处理 4K 的 1024 倍。Flash Attention 通过分块计算降低 IO 开销，但并未改变 O(n²) 的数学本质。
4. Lost in the Middle 现象
Lost in the Middle（中间信息丢失） 是 2023 年由斯坦福、伯克利和 Samaya 团队在论文中系统揭示的现象：当上下文变长时，LLM 对中间位置的信息提取能力显著下降，对开头和结尾的信息则保持较好。
Lost in the Middle 效应示意（信息提取准确率随位置变化）：
准确率
↑
│ ● 开头：85%
│ ●─┐
│ │ 准确率持续下降...
│ │ ┌─●
│ └───────────────┘ 结尾：82%
│ 中间：仅 40-60%
└────────────────────────────────────→ 信息在上下文中的位置
开头 结尾
（数据来源：Lost in the Middle, Liu et al., 2023）这意味着：你不能想当然地把最重要的信息放在上下文中间的某个位置——模型可能几乎"读"不到它。
实用的缓解策略：
- 将关键信息（指令、约束条件）放在上下文的开头或结尾
- 在长文档中多次重复关键约束
- 使用 RAG 时，将检索到的相关片段放在 prompt 的前后两端
5. 长上下文的优化技术
业界已发展出多种技术，能够在无需重新训练或仅需轻量微调的情况下，将上下文窗口大幅扩展至数倍甚至数十倍。
核心都是围绕 RoPE（旋转位置编码） 的改进：
RoPE 核心公式回顾：旋转角度 θᵢ = base^{-2i/d}
位置 m 和位置 n 的注意力分数 ∝ cos((m-n)θ)
训练时见过的最大距离 = L_train（如 4096）
测试时外推的距离 = L_test（如 16384，远超训练）
直接外推的问题：模型没见过这么大的 (m-n)，注意力模式崩溃三种核心扩展技术对比：
| 技术 | 核心做法 | 效果 | 代表模型 |
|---|---|---|---|
| NTK-aware Scaling | 改变 RoPE 的 base 频率（如从 10000 改到 500000），让高频维度对长距离更敏感 | 4K → 16K 不微调即可用 | Llama 生态广泛使用 |
| YaRN（Yet another RoPE extensioN） | NTK + 按维度分组缩放 + 温度调节 softmax | 4K → 128K，无需微调 | LLaMA 2 4K→128K |
| RoPE 线性插值 | 将位置索引线性压缩（m → m × L_train/L_test） | 简单直接，但需微调 | Meta Llama 早期扩展 |
| 训练时扩展 | 直接在更长序列上训练（如 CodeLlama 用 16K 训练） | 效果最好 | GPT-4、Claude |
NTK-aware Scaling 的直观类比：
将收音机从"本地频率"调到"短波频率"——调谐旋钮（base 值）一转，
以前只能收到近距离台（4K token 内），现在能收到远距离台（32K token 外）。
模型参数本身没变，只是"收听参数"调整了。一句话总结
长上下文是 2024-26 年 LLM 最核心的能力之一，但它的代价是 O(n²) 计算和 Lost in the Middle 效应。
在应用设计中，能用完 128K 是例外而非常态，合理的上下文管理和压缩往往比单纯追求更大窗口更重要。