一句话定义
上下文窗口是模型单次前向能接收的最大 token 数，包括系统提示、对话历史、检索内容和待生成的输出。
为什么有上限
- 标准注意力的计算量随序列长度呈平方增长，长度翻倍，注意力开销约变成四倍。
- 解码时要保存历史 token 的 KV Cache，显存占用随长度线性增长。
- 训练时的位置分布有限，模型没见过更长距离的位置组合，直接外推效果会下降。
因此上下文长度既是模型能力，也是工程成本。
窗口里装了什么
系统提示、对话历史、检索片段、当前问题和输出预留共享同一个 token 预算。多塞历史或检索，就会挤掉输出空间；超出窗口的内容不会进入注意力。
扩展手段
- 位置编码外推：通过 RoPE 插值、调整频率底数等方式，让模型适应更长位置。
- 高效注意力：稀疏、分块、线性注意力等降低长序列计算成本。
- 缓存管理：分页、压缩、丢弃低价值历史，控制 KV Cache 增长。
- 训练阶段加长：在更长序列上继续训练，让模型真正学会利用远距离信息。
标称长度 ≠ 有效长度
模型能接收 128K token，不代表它能把 128K 里的每个细节都用好。常见现象是中间位置的信息容易被忽略（所谓「迷失在中间」），关键内容放在开头或结尾通常更可靠。
与 RAG 的关系
RAG 把外部知识检索后放进上下文，适合知识更新频繁或私域数据场景；扩大上下文窗口则适合一次性读入长文档。两者不是替代关系，实际系统经常同时使用。
用在哪里
- 长文档问答、代码库理解、多轮客服：先判断该扩窗口、做 RAG，还是截断历史。
- 一次性读完整材料、需要跨段推理时用长窗口；知识频繁更新、需要引用时优先 RAG。
- 成本敏感时不要盲目开满窗口，注意标称长度和实际有效利用的差距。
常见误区
- 窗口越大越好：更长上下文意味着更贵、更慢，也更难稳定利用。
- 把资料全部塞进去就等于模型都记住了。
- 上下文长度和模型参数量是两件独立的事。