上下文窗口（Context Window）

一句话 TL;DR：上下文窗口是大模型一次能"看到"的最大 token 数。它决定模型能处理多长的输入（文档、对话历史、检索结果）。从 GPT-3 的 2K 到 GPT-4 的 128K、Gemini 的 1M+，上下文窗口的扩展是大模型工程的主战场之一。但"能装"不等于"能用好"--长上下文有 lost-in-the-middle、注意力稀释等问题。

L1 · 一句话点破

上下文窗口：模型一次前向能处理的最大 token 数。 超过这个长度的内容模型"看不到"。

模型上下文窗口 = 8K token
用户输入 10K token -> 只能看到最后 8K（或截断、或压缩）

上下文窗口是模型的硬限制。它决定：

能处理多长的文档（单次推理）
能记住多长的对话历史
RAG 能塞多少检索结果
代码能分析多长的代码库

主流模型上下文窗口：

模型	上下文
GPT-3	2K
GPT-3.5	4K-16K
GPT-4	8K-128K
Claude 3	200K
Gemini 1.5	1M-2M
LLaMA-3	8K-128K

L2 · 通俗类比

工作记忆（短期记忆）的容量限制：

小上下文（2K）：能记住一页纸的内容。看长文档要反复翻页，前面看过的忘了。
中上下文（32K）：能记住一本书的一章。多数任务够用。
大上下文（128K）：能记住一本小书。整篇论文、整个代码文件都能装。
超大上下文（1M+）：能记住一套百科全书。整个代码库、整套文档都能装。

但"工作记忆大"不等于"用得好"。人脑即使能记很多，也可能"看着前面忘了后面"或"信息太多找不到重点"。模型同理：

lost in the middle：长上下文中间位置的信息容易被忽略
注意力稀释：上下文越长，每个 token 分到的"注意力"越少
成本激增：上下文翻倍，KV Cache 显存和计算量也大幅增加

所以"扩展上下文"和"用好上下文"是两个问题。前者是工程，后者是研究。

L3 · 正经定义

上下文窗口（Context Window）：模型一次前向能处理的最大 token 数 $T_{max}$。由架构和训练决定。

限制因素：

位置编码：RoPE 等位置编码在训练长度外泛化差
KV Cache 显存：$O(T)$ 增长，长上下文显存压力大
注意力计算：$O(T^2)$ 复杂度，长上下文计算慢（FlashAttention 缓解）
训练数据：长序列训练数据少，模型在长上下文上表现可能下降

扩展上下文的方法：

方法	思路	代表
训练时用长序列	直接在长序列上训练	GPT-4, Gemini
位置编码外推	修改 RoPE 支持更长	YaRN, PI
滑动窗口注意力	局部注意力 + 全局记忆	Longformer, BigBird
稀疏注意力	减少注意力计算	Sparse Transformer
分块处理	长文档切块分别处理	RAG
缓存压缩	KV Cache 压缩	H2O, StreamingLLM

长上下文的问题：

lost in the middle：Liu et al., 2023 发现模型对上下文中间位置信息利用率低
注意力稀释：上下文长，每个 token 分到的注意力少
成本：长上下文推理慢、显存大

参考资料：

L4 · 原理深挖

4.1 上下文窗口的限制因素

① 位置编码

Transformer 本身没有位置感知，需要位置编码。RoPE 是主流，但训练时只见过 $[0, T_{train}]$ 的位置，超出后泛化差。

扩展方法：

PI (Position Interpolation)：把长序列的位置"压缩"到训练范围内
YaRN：分段插值，更精细
NTK-aware：修改 RoPE 基频，外推更稳

这些方法让模型在不动架构的情况下扩展上下文，但效果不如原生训练长上下文。

② KV Cache 显存

自回归生成的 KV Cache 随序列长度线性增长。LLaMA-70B、128K 上下文、batch=1 时，KV Cache 可达数十 GB。

对策：

PagedAttention（vLLM）：分页管理，提升利用率
KV Cache 量化：FP16 -> INT8/INT4
KV Cache 驱逐：丢掉不重要的 KV（H2O, StreamingLLM）

③ 注意力计算

标准注意力 $O(T^2)$。128K 上下文注意力矩阵 $128K \times 128K$，显存和计算爆炸。

对策：

FlashAttention：分块计算，显存从 $O(T^2)$ 降到 $O(T)$，速度提升 2-4 倍
稀疏/滑动窗口注意力：只算局部或部分注意力
Ring Attention：分布式长上下文注意力

4.2 Lost in the Middle：长上下文的反直觉现象

Liu et al., 2023 - Lost in the Middle 发现：模型对长上下文中间位置的信息利用率低。

实验：把关键信息放在上下文的不同位置，看模型能否找到：

放在开头：准确率高
放在结尾：准确率高
放在中间：准确率显著下降

U 型曲线：

准确率
高 |*                                   *|
   | *                                 * |
   |  *                               *  |
低 |   ** ** ** ** ** ** ** ** ** ** **   |
   +-------------------------------------+
    开头           中间           结尾

原因（推测）：

注意力机制对开头和结尾的"锚定效应"
训练数据中重要信息常在开头/结尾
长上下文注意力稀释

对策：

重排：把重要信息放开头/结尾
RAG：只检索相关片段，避免长上下文
显式标记：用特殊 token 标记重要位置

Lost in the Middle 说明"长上下文"和"有效利用长上下文"是两回事。

4.3 RAG vs 长上下文：两种处理长文档的思路

长文档处理的两种思路：

① 长上下文（全塞进去）

长文档（200K）-> 全塞进模型上下文 -> 模型直接处理

优势：

模型看到全文，无信息丢失
简单，不需检索

劣势：

上下文不够大时不行（<文档长度）
推理慢、成本高
Lost in the Middle
注意力稀释

② RAG（检索相关片段）

长文档 -> 切 chunk -> 索引 -> 查询时检索 top-k -> 塞入上下文

优势：

不受文档长度限制
推理快、成本低
聚焦相关内容

劣势：

检索可能不准（漏召回）
chunk 切分可能丢上下文
多跳推理弱

实务权衡：

文档短（<上下文窗口）：直接塞，简单
文档长 + 单跳查询：RAG 高效
文档长 + 多跳推理：长上下文 + RAG 结合

2024-2025 的趋势：长上下文模型（1M+）出现，但 RAG 仍主流。原因：成本、lost-in-the-middle、注意力质量。长上下文 + RAG 结合是未来方向。

4.4 上下文窗口的扩展历程

GPT-3 (2020)：2K 上下文。受位置编码和显存限制。

GPT-3.5 (2022)：4K-16K。逐步扩展。

GPT-4 (2023)：8K-128K。原生训练 + 位置编码优化。

Claude 3 (2024)：200K。Anthropic 在长上下文上领先。

Gemini 1.5 (2024)：1M-2M。谷歌用 Ring Attention 等技术实现超长上下文。

LLaMA-3 (2024)：8K-128K。开源追赶闭源。

扩展上下文的工程难点：

训练数据：长序列训练数据少
显存：训练时 attention 矩阵大
位置编码：超长位置外推
质量：长上下文上模型质量可能下降

每扩展 10 倍上下文，工程难度指数级增长。

4.5 KV Cache 管理：长上下文的工程核心

长上下文推理的瓶颈是 KV Cache 显存（见 4.1）。多种优化：

① PagedAttention（vLLM）

见推理引擎。分页管理 KV Cache，显存利用率从 50% 到 95%。

② KV Cache 量化

把 KV Cache 从 FP16 量化到 INT8/INT4，显存减半/四分之一。代价是精度损失。

③ KV Cache 驱逐

只保留重要的 KV，丢掉不重要的：

StreamingLLM：保留开头（attention sink）+ 最近的 KV，丢弃中间
H2O：基于注意力分数动态驱逐
SnapKV：基于注意力模式选择重要 KV

这些方法让"无限长度"推理成为可能（虽质量有损）。

4.6 上下文窗口与定价

长上下文的成本：

输入 token 计费：128K 输入比 4K 输入贵 32 倍
推理慢：长上下文 prefill 慢
显存大：需更大 GPU

实务：

不要无脑塞长上下文：能用 RAG 就用 RAG
压缩 prompt：去掉无关内容
缓存共享前缀：Prefix Caching 见推理引擎

长上下文是"能力"也是"成本"，需按需使用。

L5 · 沿革与坑

沿革

2017：Transformer 原论文，注意力 $O(T^2)$，上下文受限。
2020：GPT-3 上下文 2K，被认为是合理上限。
2022：FlashAttention 出现，长上下文计算瓶颈缓解。
2023：GPT-4 128K、Claude 100K，长上下文成竞争点。
2023：Lost in the Middle 揭示长上下文质量问题。
2024：Claude 3 200K、Gemini 1.5 1M-2M、LLaMA-3 128K。上下文窗口数量级跃升。
2024-2025：长上下文 + RAG 结合成为主流。StreamingLLM、KV 驱逐等让"无限长度"推理成为可能。

常见误解

❌ 误解：上下文越长模型越聪明。 ✅ 真相：上下文长只是"能装更多"，不代表"用得好"。Lost in the Middle、注意力稀释让长上下文质量下降（4.2）。
❌ 误解：长上下文出现，RAG 没用了。 ✅ 真相：长上下文有成本、质量问题。RAG 仍主流，且与长上下文结合是趋势（4.3）。
❌ 误解：上下文窗口可以随便扩展。 ✅ 真相：受位置编码、KV Cache 显存、注意力计算、训练数据等多重限制。每扩展 10 倍工程难度指数级增长（4.4）。
❌ 误解：128K 上下文能装一本小说，所以能完美理解。 ✅ 真相：装下不代表理解。Lost in the Middle 让中间信息易丢。重要信息放开头/结尾更稳（4.2）。
❌ 误解：长上下文成本和短上下文差不多。 ✅ 真相：长上下文成本随长度增长（输入 token 计费、推理慢、显存大）。需按需使用（4.6）。
❌ 误解：KV Cache 占显存小。 ✅ 真相：长上下文 KV Cache 可达数十 GB，是大模型推理显存大头。PagedAttention、量化、驱逐等优化都针对它（4.5）。

面试怎么考

"什么是上下文窗口？受什么限制？" --一次前向能处理的最大 token 数。受位置编码、KV Cache 显存、注意力计算、训练数据限制（L1、4.1）。
"什么是 Lost in the Middle？" --长上下文中间位置信息利用率低，呈 U 型曲线。需把重要信息放开头/结尾（4.2）。
"RAG 和长上下文怎么选？" --短文档直接塞；长文档+单跳用 RAG；长文档+多跳用长上下文+RAG 结合（4.3）。
"怎么扩展上下文窗口？" --位置编码外推（YaRN、PI）、FlashAttention、KV Cache 管理、长序列训练（4.1、4.4）。
"KV Cache 在长上下文里有什么问题？" --显存 $O(T)$ 增长，长上下文显存压力大。PagedAttention、量化、驱逐等优化（4.5）。
"为什么长上下文成本高？" --输入 token 计费、推理慢（attention $O(T^2)$）、显存大（KV Cache）。需按需使用（4.6）。

延伸阅读

上一篇：CLIP -- 图文对齐的多模态 embedding。下一篇：倒排索引 -- 关键词检索的百年老树。

上下文窗口（Context Window） ​

L1 · 一句话点破 ​

L2 · 通俗类比 ​

L3 · 正经定义 ​

L4 · 原理深挖 ​

4.1 上下文窗口的限制因素 ​

4.2 Lost in the Middle：长上下文的反直觉现象 ​

4.3 RAG vs 长上下文：两种处理长文档的思路 ​

4.4 上下文窗口的扩展历程 ​

4.5 KV Cache 管理：长上下文的工程核心 ​

4.6 上下文窗口与定价 ​

L5 · 沿革与坑 ​

沿革 ​

常见误解 ​

面试怎么考 ​

延伸阅读 ​