理解大模型的上下文窗口：为什么你的长文档会被截断

当你把几百页的 PDF 喂给大语言模型时，它可能会先同意"我理解"，随后给出的答案却与原文矛盾。这不是模型变笨了——这是上下文窗口（Context Window）的硬限制。

什么是上下文窗口

上下文窗口是模型一次能"看到"的 token 总数。它包括：

- 你的输入（prompt + 上传的文档）

- 模型生成的回复

- 系统指令

典型的 128K token 窗口约等于 90,000 个中文字符。看起来很多，但一旦超过这个限制，旧信息就会被丢弃，且不可恢复。

为什么它会"遗忘"

模型使用滑动窗口机制：每处理一个新的 token，旧 token 会从注意力机制中逐渐淡出。这不是在某个点突然清空，而是逐步降低关注权重。结果就是你发现模型对文档前几页的细节提问时，给出了模糊甚至错误的回答。

实用的解决方案

1. 分段处理 + 结果聚合

不要一次性上传整份文档。将内容按章节拆分为多个短 prompt，分别处理，然后人工汇总结果。这在法律和医疗文档处理中最有效。

2. 使用支持检索的插件

许多平台提供"文档问答"功能，底层使用向量数据库（Vector DB）进行语义检索。系统先把你上传的文档切片向量化，然后针对你的问题只检索相关的段落，再喂给模型。这能保持高准确率，同时避免窗口限制。

3. 提问时明确引用位置

与其问"这篇文章说了什么"，不如问"关于第 3.2 节的内容，作者的主张是什么"。精确定位可以减少模型从大量无关信息中搜索的难度。

4. 压缩摘要

对超长文档，先用模型生成一个结构化摘要（保留标题、关键数据、结论），再基于摘要进行追问。这比直接追问原文的准确率更高。

选型建议

如果你经常处理长文档：

- 查看平台是否支持"文档对话"或"知识库"模式

- 确认 token 窗口是否真能容纳你的文档（注意 token 数 > 字符数）

- 对重要结论，用"分段处理"或"检索增强"方式验证

上下文窗口不是参数配置的门槛，而是当前架构的本质限制。了解它的运作方式，才能避免"模型什么都说"的错觉。

---

*本文不涉及具体厂商对比，仅讨论技术原理。*