大模型的上下文窗口是什么?这个限制的本质是什么?当对话或文档超出窗口时,有哪些常见的应对方案?

模型架构

答案要点 上下文窗口是模型一次推理能「看到」的最大 token 数,输入和输出共享这个额度 限制的本质:注意力计算量随长度平方增长 + 位置编码只在训练长度内可靠 + KV 缓存显存随长度线性增长 超窗后模型不会报错,而是最早的内容被截断,表现为「忘了前面说过的话」 三种经典应对:截断(简单粗暴)、摘要压缩(有损保留主干)、RAG(外挂检索,按需取用) 实际系统常三者组合:近期对话留原文、久远对话滚动摘要、知识库走 RAG 核心概念 上下文窗口(Context Window)是大模型在一次推理中能够处理的最大 token 数量,包括输入的全部内容(系统提示、历史对话、文档)和模型将要输出的内容,两者共享同一个额度。比如窗口 8K 的模型,输入占了 7K,输出最多只能再生成约 1K。 为什么会有这个限制?主要三个原因:一是自注意力的计算量随序列长度平方级增长,长度翻倍计算量约翻四倍;二是位置编码(让模型知道词的先后顺序的机制)在训练时只见过一定长度,超出后模型对位置关系「没概念」;三是推理时的 KV 缓存显存随长度线性增长,窗口越大越吃显存。 超出窗口的三种应对 | 方案 | 做法 | 适用与代价 | |------|------|-----------| | 截断 | 丢掉最早的对话或文档开头 | 实现最简单;关键信息可能被丢,用户感觉「失忆」 | | 摘要压缩 | 把久远内容总结成短摘要放回上下文 | 保留主干;细节丢失,摘要本身也要耗一次调用 | | RAG | 长资料切块存入向量库,提问时只检索最相关的几块塞进上下文 | 资料可以无限大;但引入「检索质量」这个新变量 | 实际工程的组合拳 成熟的对话系统通常是:最近几轮对话保留原文 + 更早的对话滚动摘要 + 领域知识走 RAG,三者拼成最终的 prompt。 入门后可以深入长上下文外推技术(RoPE 插值、YaRN),以及「窗口大了但中间内容记不住」的 Lost in the Middle 问题。

口语版讲法(约2分钟)

  • 一句话定义:输入输出共享的最大 token 额度
  • 比喻:模型的工作台,放不下就往下挤
  • 限制三层本质:平方计算量、位置编码、KV 缓存显存
  • 超窗三招:截断、摘要压缩、RAG
  • 埋钉子:窗口大不等于记得牢,Lost in the Middle

上下文窗口就是大模型一次推理最多能处理的 token 数量,注意是输入加输出共用一个额度。你可以把它想象成模型的工作台:桌面就那么大,系统提示、历史对话、你贴的文档、它要写的回答,全都得摊在这张桌子上,放不下就有东西被挤下去。 这个限制的本质有三层。第一,自注意力机制里每个 token 都要和其他所有 token 算一遍关系,计算量随长度平方增长,窗口翻倍,计算量差不多翻四倍。第二,位置编码,也就是让模型知道词序先后的机制,训练时只见过固定范围的长度,超出这个范围,模型对「谁在前谁在后」的感知就不可靠了。第三,推理时还有 KV 缓存,显存占用随长度线性涨,窗口开太大显存扛不住。所以窗口不是厂商故意抠门,背后是实打实的算力和显存代价。 超窗之后会发生什么?模型不会报错说「我记不住了」,而是最早的内容被悄悄截断,用户的体感就是聊着聊着,它把开头交代的设定忘了。应对方案主要三种。第一种是截断,直接丢最早的内容,实现最简单,但可能把关键信息丢掉。第二种是摘要压缩,每隔一段就把久远的对话总结成一小段摘要放回上下文,主干还在,细节没了。第三种是 RAG,也就是检索增强生成:把长资料切块存进向量库,每次提问时只把最相关的几块捞出来塞进窗口。这样资料本身可以无限大,窗口里永远只放当前需要的那部分。 实际做系统一般是组合拳:最近几轮对话保留原文,更早的滚动摘要,领域知识全部走 RAG。另外我还想补充一点,现在窗口越做越大,128K 甚至上百万,但研究发现窗口大不等于记得牢,模型对放在中间位置的信息利用率明显偏低,这个现象叫 Lost in the Middle。长上下文怎么外推、大窗口和 RAG 怎么取舍,是可以继续深挖的方向。

关键一句:上下文窗口是输入输出共享的 token 上限,本质是注意力平方计算量、位置编码范围、KV 缓存显存三重代价。

面试官可能的追问

  1. 【场景切入】用户要用你们的助手分析一份 300 页的合同,远超模型窗口,你会怎么设计,让它既能回答细节问题又不超窗?
  2. 【追问边界】现在有的模型窗口已经做到 1M token 了,是不是窗口够大就不需要 RAG 了?你怎么看这两者的关系?

同模块相关题目