上下文窗口是什么？为什么 128K 不等于能塞 128K

先这样答

上下文窗口是模型单次推理能处理的 token 数上限：系统提示、对话历史、检索来的文档、模型的回答，全部装在这一个窗口里，窗口外的内容模型完全看不见。窗口大小从早期的几 K 涨到现在常见的 128K 甚至更长，成了模型的招牌参数之一。

为什么 128K 不等于能塞 128K。第一，塞满有硬成本：注意力计算量随长度平方增长，缓存历史结果的 KV Cache 显存占用随长度上涨，延迟和费用都跟着上去。第二，塞满有效果损耗：多个评测反复观察到，把关键信息放在超长上下文的中段，模型的召回质量会下降；标称长度和「都看清、都用上」的有效长度之间有差距，位置编码的扩展方式和训练时长文本的占比都影响这个差距。所以标称 128K 是「能处理」，不是「都处理得好」。

实践上把窗口当预算花：只放当前任务需要的内容，关键信息放头尾，长文档先切先筛再进窗口。上下文工程做的就是这个取舍，不是能装多少，是怎么装才用得上。

面试官会怎么追问

• 「长上下文和 RAG 是替代关系吗？」 不是，是分工。窗口再长，成本和注意力稀释都在，把整个知识库塞进窗口又贵又不可靠。RAG 先把最相关的少数内容选出来，窗口负责装下这些精选，两者配合使用。
• 「对话历史超窗口了怎么办？」 必须裁剪或压缩：滑窗只留最近若干轮、把早期对话总结成摘要、把关键事实抽出来单独维护。选哪种取决于任务依赖历史的方式。
• 「为什么窗口越大越贵？」 每生成一个 token，都要对全部上下文做注意力，平方项随长度膨胀；KV Cache 的显存也线性上涨。窗口翻倍不只是容量翻倍，每一步的计算和显存都变贵。

回答的坑

• 把标称窗口当有效窗口。厂商标的长度是「能处理」不是「处理得好」，长上下文中段信息丢失是被反复验证的现象，别把关键内容埋在中间指望模型稳定引用。
• 只堆上下文不做管理。历史和文档无脑全塞，成本上去了，效果反而可能下降；上下文要设计和取舍，不是免费容器。