完整题目
大模型的上下文窗口是什么?这个限制的本质是什么?当对话或文档超出窗口时,有哪些常见的应对方案?
本文目录
答案要点
- 上下文窗口是模型一次推理能「看到」的最大 token 数,输入和输出共享这个额度
- 限制的本质:注意力计算量随长度平方增长 + 位置编码只在训练长度内可靠 + KV 缓存显存随长度线性增长
- 超窗后模型不会报错,而是最早的内容被截断,表现为「忘了前面说过的话」
- 三种经典应对:截断(简单粗暴)、摘要压缩(有损保留主干)、RAG(外挂检索,按需取用)
- 实际系统常三者组合:近期对话留原文、久远对话滚动摘要、知识库走 RAG
核心概念
上下文窗口(Context Window)是大模型在一次推理中能够处理的最大 token 数量,包括输入的全部内容(系统提示、历史对话、文档)和模型将要输出的内容,两者共享同一个额度。比如窗口 8K 的模型,输入占了 7K,输出最多只能再生成约 1K。
为什么会有这个限制?主要三个原因:一是自注意力的计算量随序列长度平方级增长,长度翻倍计算量约翻四倍;二是位置编码(让模型知道词的先后顺序的机制)在训练时只见过一定长度,超出后模型对位置关系「没概念」;三是推理时的 KV 缓存显存随长度线性增长,窗口越大越吃显存。
超出窗口的三种应对
| 方案 | 做法 | 适用与代价 |
|---|---|---|
| 截断 | 丢掉最早的对话或文档开头 | 实现最简单;关键信息可能被丢,用户感觉「失忆」 |
| 摘要压缩 | 把久远内容总结成短摘要放回上下文 | 保留主干;细节丢失,摘要本身也要耗一次调用 |
| RAG | 长资料切块存入向量库,提问时只检索最相关的几块塞进上下文 | 资料可以无限大;但引入「检索质量」这个新变量 |
实际工程的组合拳
成熟的对话系统通常是:最近几轮对话保留原文 + 更早的对话滚动摘要 + 领域知识走 RAG,三者拼成最终的 prompt。
入门后可以深入长上下文外推技术(RoPE 插值、YaRN),以及「窗口大了但中间内容记不住」的 Lost in the Middle 问题。
换一种问法，检查是否真正理解
场景切入
用户要用你们的助手分析一份 300 页的合同,远超模型窗口,你会怎么设计,让它既能回答细节问题又不超窗?
追问边界
现在有的模型窗口已经做到 1M token 了,是不是窗口够大就不需要 RAG 了?你怎么看这两者的关系?
练习口述回答 · 约2分钟
- 一句话定位：上下文窗口本质是注意力机制的计算和显存瓶颈
- 限制的三个原因：注意力平方增长、位置编码失效、KV缓存膨胀
- 三种应对方案及适用边界：截断、摘要、RAG
- 工程组合拳：近期原文+远期摘要+知识库RAG，以及一个业务例子
这道题其实在问大模型为什么记不住长对话，以及我们怎么绕开这个限制。上下文窗口本质是模型一次推理能看到的 token 上限，输入和输出共享这个额度。限制的根本原因有三个：一是自注意力计算量随长度平方增长，长度翻倍计算量翻四倍；二是位置编码只在训练长度内可靠，超了模型对位置关系就没概念了；三是推理时的 [[KV Cache]] 显存随长度线性增长，窗口越大越吃显存。
超窗后模型不会报错，而是最早的内容被截断，表现为忘了前面说过的话。应对方案我分三类讲。截断最简单，直接丢掉最早的内容，但关键信息可能被丢，用户感觉失忆。摘要压缩是把久远内容总结成短摘要放回上下文，保留主干但细节会丢，而且摘要本身也要耗一次模型调用。[[RAG]] 是把长资料[[切块]]存到[[向量库]]，提问时只检索最相关的几块塞进上下文，资料可以无限大，但引入了检索质量这个新变量。
实际落地很少只用一种。比如客服系统的退款场景，我会把最近几轮对话保留原文，更早的对话用滚动摘要压缩，产品政策这类静态知识走 RAG 检索。这里有个坑：摘要压缩的前提是摘要质量够好，如果模型摘要不准，关键细节丢失，用户反复问同一件事，体验会很差。所以上线我会特别关注摘要的召回率，用一批历史对话回放，看摘要后能不能回答核心问题。
如果窗口继续扩大，比如到了 128K 甚至更长，还会出现 Lost in the Middle 问题，模型对中间位置的内容注意力下降。要解决这个，就不能只靠增大窗口，还得配合位置编码的外推技术，比如 [[RoPE]] 插值或 YaRN。
所以我会把上下文窗口看成一种工程约束，不是越大越好，关键在于怎么在有限窗口里放最有效的信息。我更倾向用截断加 RAG 的组合，而不是盲目堆窗口。