上下文窗口是什么?超了怎么办?

#入门 #基础概念 #上下文窗口 #context window #大模型上下文长度

搜索「摘要」匹配到口述回答，相关段落已展开。查看匹配内容 ↓

完整题目

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

本文目录

答案要点

上下文窗口是模型一次推理能「看到」的最大 token 数,输入和输出共享这个额度
限制的本质:注意力计算量随长度平方增长 + 位置编码只在训练长度内可靠 + KV 缓存显存随长度线性增长
超窗后模型不会报错,而是最早的内容被截断,表现为「忘了前面说过的话」
三种经典应对:截断(简单粗暴)、摘要压缩(有损保留主干)、RAG(外挂检索,按需取用)
实际系统常三者组合:近期对话留原文、久远对话滚动摘要、知识库走 RAG

核心概念

上下文窗口(Context Window)是大模型在一次推理中能够处理的最大 token 数量,包括输入的全部内容(系统提示、历史对话、文档)和模型将要输出的内容,两者共享同一个额度。比如窗口 8K 的模型,输入占了 7K,输出最多只能再生成约 1K。

为什么会有这个限制?主要三个原因:一是自注意力的计算量随序列长度平方级增长,长度翻倍计算量约翻四倍;二是位置编码(让模型知道词的先后顺序的机制)在训练时只见过一定长度,超出后模型对位置关系「没概念」;三是推理时的 KV 缓存显存随长度线性增长,窗口越大越吃显存。

超出窗口的三种应对

方案	做法	适用与代价

按学习路线查看教程、项目和面试题。

站内 RAG 在线实战

换一种问法，检查是否真正理解

场景切入

用户要用你们的助手分析一份 300 页的合同,远超模型窗口,你会怎么设计,让它既能回答细节问题又不超窗?

追问边界

现在有的模型窗口已经做到 1M token 了,是不是窗口够大就不需要 RAG 了?你怎么看这两者的关系?

练习口述回答 · 约2分钟

一句话定位：上下文窗口本质是注意力机制的计算和显存瓶颈
限制的三个原因：注意力平方增长、位置编码失效、KV缓存膨胀
三种应对方案及适用边界：截断、摘要、RAG
工程组合拳：近期原文+远期摘要+知识库RAG，以及一个业务例子

这道题其实在问大模型为什么记不住长对话，以及我们怎么绕开这个限制。上下文窗口本质是模型一次推理能看到的 token 上限，输入和输出共享这个额度。限制的根本原因有三个：一是自注意力计算量随长度平方增长，长度翻倍计算量翻四倍；二是位置编码只在训练长度内可靠，超了模型对位置关系就没概念了；三是推理时的 [[KV Cache]] 显存随长度线性增长，窗口越大越吃显存。

超窗后模型不会报错，而是最早的内容被截断，表现为忘了前面说过的话。应对方案我分三类讲。截断最简单，直接丢掉最早的内容，但关键信息可能被丢，用户感觉失忆。摘要压缩是把久远内容总结成短摘要放回上下文，保留主干但细节会丢，而且摘要本身也要耗一次模型调用。[[RAG]] 是把长资料[[切块]]存到[[向量库]]，提问时只检索最相关的几块塞进上下文，资料可以无限大，但引入了检索质量这个新变量。

实际落地很少只用一种。比如客服系统的退款场景，我会把最近几轮对话保留原文，更早的对话用滚动摘要压缩，产品政策这类静态知识走 RAG 检索。这里有个坑：摘要压缩的前提是摘要质量够好，如果模型摘要不准，关键细节丢失，用户反复问同一件事，体验会很差。所以上线我会特别关注摘要的召回率，用一批历史对话回放，看摘要后能不能回答核心问题。

如果窗口继续扩大，比如到了 128K 甚至更长，还会出现 Lost in the Middle 问题，模型对中间位置的内容注意力下降。要解决这个，就不能只靠增大窗口，还得配合位置编码的外推技术，比如 [[RoPE]] 插值或 YaRN。

所以我会把上下文窗口看成一种工程约束，不是越大越好，关键在于怎么在有限窗口里放最有效的信息。我更倾向用截断加 RAG 的组合，而不是盲目堆窗口。

截断	丢掉最早的对话或文档开头	实现最简单;关键信息可能被丢,用户感觉「失忆」
摘要压缩	把久远内容总结成短摘要放回上下文	保留主干;细节丢失,摘要本身也要耗一次调用
RAG	长资料切块存入向量库,提问时只检索最相关的几块塞进上下文	资料可以无限大;但引入「检索质量」这个新变量