把一份 200 页的合同丢给大模型，开头记得清清楚楚，中间的关键条款却漏了——问题多半出在「上下文窗口」。它决定了模型一次能「看到」多少内容，也解释了为什么「支持长文本」和「长文本都可靠」是两回事。这篇讲清窗口的工作机制、三种典型失效场景和对应的处理办法。
窗口是什么：一次能看到的量
大模型读文本之前，先把它切成 token——可以理解为一个个词片段，中文里一个字大致对应一到两个 token。上下文窗口就是单次对话里，你的问题、上传的文档、之前的回答加在一起，能放进模型计算的 token 总量上限。好比一张桌子：桌面多大，就能同时摊开多少材料；摊不下的，要么传不进去，要么在多轮对话里被最早的内容挤出去。
窗口大小和模型参数量是两个独立的指标。参数量影响模型的能力上限，窗口影响单次能处理的内容量，7B 和 70B 的参数差别里不包含窗口信息，小窗口的大参数模型完全可能存在。选型时两个都要看，别只比一个数。
装得下，不等于记得住
就算内容全部塞进了窗口，模型对中间部分的注意力也会变弱，业内把这种现象叫「中间遗忘」：开头和结尾记得牢，中段容易丢。所以在窗口边缘反复试探没有意义——哪怕标称能装 20 万 token，也不代表第 15 万 token 处的条款能被准确引用。
多轮长对话还有第二个问题：早期信息会「出窗」。对话进行到几十轮之后，第一轮聊过的内容可能已经被挤出去，模型不是忘了，是根本看不见了。这时它如果还顺着早期的话题往下答，多半是在猜。
三种典型失效场景
场景一：整篇长文档丢进去就问「总结一下」，总结里出现的是开头和结尾的高频内容，中段的关键条款、数据表格容易被略过。场景二：多轮长对话，前面聊定的前提条件后面悄悄变了，模型浑然不觉，产出自相矛盾。场景三：关键要求埋在材料中间，你把最重要的指令写在第 3 页，它的注意力落在首尾，这条要求的权重就被稀释了。
还有一类容易被忽略的情况：文档超出窗口被自动截断。上传时没报错，它也正常回答了，但后半篇根本没参与计算。验证办法很简单，问它「这份文档的最后一节讲了什么」，答不上来或者答得含糊，就说明发生了截断，老老实实分段处理。
四个可以照做的做法
一是分段：长文档按章节切开，逐段提问，每段控制在窗口的零头。二是先摘要后细问：先让它给全文提纲，确认结构没读错，再针对具体章节追问。三是关键点前置：问题写在消息最前面，文档材料放后面，指令别埋在材料里。四是要求标出处：让它每条结论标注章节或页码，一方面方便你回原文核对，另一方面它会因为要给出处而少编。
场景对照表
| 情况 | 发生了什么 | 应对 | 判断标准 |
|---|---|---|---|
| 整篇 200 页文档直接提问 | 中段注意力弱，总结偏向首尾 | 按章节分段，先问结构再问细节 | 抽查中段一个条款能否准确引用 |
| 对话超过几十轮 | 早期内容出窗，模型在猜 | 阶段性让它复述结论，开新对话粘贴回去 | 复述第一轮的前提，看是否一致 |
| 关键指令埋在材料中间 | 指令权重被稀释 | 指令放消息首行，材料另起 | 对照产出，检查是否漏掉指令项 |
| 上传后答案文不对题 | 文件解析失败，比如扫描件 | 换可复制文本的格式重传 | 让它复述文档标题，验证解析成功 |
表里最后一列值得单独说：验证一个工具的长文本能力，用自己的文档试一次，比看任何参数都有用。
反过来，窗口也不是越大越好。窗口翻倍，单次请求的计算量随之上升，等待时间变长，不少服务还会对超长输入单独计费。多数日常任务实际用到的内容量并不大，几百到几千 token 就够，按自己的真实文档长度选，比追求数字上限划算。
选工具时，窗口怎么比
第一，别只看标称数字。各模型的窗口在快速变大，「标称能装多少」和「实际记得多准」是两回事，具体以官方最新版本说明为准。第二，窗口往往和版本、额度绑在一起，免费版和付费版的差别经常就落在这里，长文档需求重的话，先看清楚用的那一档给的是什么窗口。第三，警惕第三方套壳应用虚标参数，认准官方入口和官方说明。第四，窗口大通常意味着处理更慢，长输入会拉长等待时间，生成速度的差别在长文档场景会被放大，赶时间的话要把这一项算进去。
上下文窗口速查
- 窗口是单次能处理的 token 总量上限，多轮对话共享
- 装得下不等于记得住，中段注意力天然弱
- 分段、先摘要、关键点前置、要求标出处
- 比窗口不如实测：用自己的长文档试一次
