"窗口"这个词，我越用越觉得它害人。它是那种听着毫无门槛、谁都能秒懂的说法，可恰恰是那点直觉上的"懂"，把整套机制的形状带偏了。
你真把它当窗子看——一扇窗，窗外的东西都该看得见——那长对话里的现象就没法解释。你跟模型聊了四十分钟，回头提一句半小时前交代过的细节，它接不上。你翻聊天记录，那句话明明就在上下文里躺着，可它对此毫无反应。更见鬼的是，窗口越做越大，这种状况反而更频繁。窗户变宽了，看出去的东西更糊了。
先给个简化版，不算精确但够用：context window 是 token 总量的硬上限，提示词、对话历史、模型正在吐出来的回复，全共用同一份预算。你发一句长的，它回一句长的，两边从同一个池子里扣钱。池子满了，最早进池的被推出去，给新来的腾地方。这条是死的，没有商量。
但"推出去"这个词，把机制带偏了。
模型并没有"忘掉"那些先来的内容，它只是看不见了。忘掉是一个状态变化，滑出窗口是一个位置变化——内容还在聊天记录里，还在它的参数里，只是这一次推理的瞬间，它不在模型够得着的那片工作台上。这里最容易被搞混的是"记忆"和"上下文窗口"这俩词：记忆是应用层做的跨会话保存，窗口是单次推理时能用的信息。技术上分得清清楚楚，普通用户分不清，因为你观察到的现象长得一样：它就是接不上。
可这俩机制有一个实际的差别，分岔就在这儿：滑出窗口的内容不会触发任何"寻找"动作。模型不知道"我看不见了"，更不会主动去别处翻。这个"不会主动找"，就是后来为什么会有 RAG 的根——思路朴素得近乎笨拙：既然你看不见窗口外的，那我在动笔之前先检索一遍，把最相关的几段挑出来，塞进窗口里给你看。绕过了窗口的物理边界，不是把窗口变大，是不让无关的东西占坑。聪明，但有先决条件：检索得把对的东西挑出来。挑错了，后面生成再厉害，也是对着错的那几页材料写作业。
好，那我不搞 RAG，就等窗口变大，问题总没了吧？这就拐到"窗口"真正坑人的地方了——它让你默认窗口里所有东西是均匀被看见的。其实不是。
lost in the middle 不是边缘结论了。我见过一个从业者在 dev.to 评论区分享自己实测的数据：5 万 token 上下的上下文，同一个事实放在 30% 的位置和放在 80% 的位置，检索类任务的准确率能差 15 个百分点。同一段内容，同一个模型，挪了个位置，差这么多。模型并没有在看窗口里的所有东西，它只是对开头和结尾特别上心，中间那一段，基本是半读半不读地混过去。窗口越大，中段越长，注意力被稀释得越匀——新增的那几万 token 不是帮你记得更多，是把原本记得清的也搅浑了。
"窗口"这个说法到这儿就该收工了。它管的是容量，装不装得下；注意力才管的是能力，看没看到。这俩是结构上完全不同的约束，被塞进了同一个词里。所以你看工具商攀比上下文窗口数字的时候，心里自己打个折：大窗口解决的是"装得下"，解决不了"用得好"。后者天生不归窗口管。
窗口是个成本概念，注意力才是能力概念。懂了这两个没绑在一起，往后你再看到任何"上下文越长=记性越好"的说法，该不该信，你自己心里有数了。
再往下就是 attention 在长文本里为什么两头重中间虚，那条线够单独拆一篇的。坑先留着，改天填。
