用AI大模型处理一份长文档，前几页问过的问题，翻到后面再问一遍，回答可能就变了。这不是模型“态度不好”，而是上下文这件事，比宣传里说的要复杂。
过去一年，上下文窗口几乎成了模型更新的固定项目。几十万、上百万token的容量被反复提起，仿佛只要把整本书、整个代码库塞进去，问题就解决了一半。但真正用起来的人会发现，装得下和用得上，是两件事。
窗口变大之后，注意力并没有同步变大
上下文窗口可以理解为模型一次能“看见”的文字总量。容量扩大，最直接的好处是不用反复切分材料，长对话也不容易被截断。可模型在处理这些内容时，并不是均匀用力。越靠前、越靠后的信息，和中间部分的信息，被调用的难易程度并不相同。一些开发者把这种现象叫作“中间遗忘”，说法未必严谨，但它描述的体验很真实：关键信息藏在长文中间，模型有时候就是接不住。
这也解释了一个常见困惑——明明资料都放进去了，回答却像没看过。问题不在于容量不够，而在于模型能否在需要的那一刻，把相关内容准确地找出来、用上去。容量是仓库面积，检索和推理才是搬运工。
长上下文不是免费的
另一个容易被忽略的点是成本。上下文越长，推理时需要的计算量通常越大，响应速度也更慢。对个人用户来说，这可能只是多等几秒；对把它们接入业务流程的团队来说，就是实打实的账单和延迟。
于是出现了一种反向操作：不是拼命塞满窗口，而是主动做减法。先把材料压缩、摘出要点，再交给AI大模型处理；或者把任务拆成几轮，每轮只给必要的信息。这种做法看起来不够“先进”，却往往更稳。上下文能力是工具，不是目标，用多少取决于任务，而不是取决于上限在哪。
“记住”与“理解”之间还有距离
还有一种误解值得澄清。上下文窗口里的内容，并不等于模型已经学会了。它更像是一次性的工作台：这一轮对话结束，工作台就清空了。想让模型长期记住某些偏好或规则，靠的是另外的机制，比如外部知识库、检索增强，或者在系统层面给出稳定指令。
所以，当有人问“AI大模型能不能记住我们公司所有资料”，答案通常要分两层：一次对话里能不能用上，和长期能不能稳定调用，是不同的问题。前者靠上下文，后者靠工程。
对普通使用者来说，比较实用的做法是：把最重要的信息放在开头或结尾，明确告诉模型要先看什么；长文档分段处理，别指望一次问完所有细节；对关键结论做交叉验证，而不是默认它会记住全部。
上下文窗口还会继续变大，这几乎是可以预期的。但真正决定使用体验的，可能不是数字又多了多少，而是模型在长材料里找到那一段的能力，以及我们是否愿意承认：容量只是起点，不是答案。