Context Window

上下文窗口是模型对单次请求的工作记忆，以 token 计量（一个 token 大约是四分之三个单词）。所有内容都必须装进其中：你的系统 Prompt、对话历史、你粘进去的任何文档，以及模型生成的回答。一旦超出窗口，模型实际上就看不到溢出的部分。

即使窗口很大，「直接把所有东西放进 Prompt」也会因三个原因而失败。第一，成本：大多数提供商按 token 计费，所以把一份巨大的文档塞进每次调用会让账单成倍增长。第二，延迟：更多 token 意味着更慢的响应。第三，也是最不明显的，质量，模型对埋在很长上下文中间的信息关注得不那么可靠，所以更多并不总是更好。一个聚焦的 Prompt 往往胜过一个臃肿的。

这正是 RAG 存在的原因。你不是把整个语料库倒进窗口，而是只为每个问题检索出少数相关的文本块，并只发送这些。你获得了大型知识库的好处，却无需为在每次请求中处理全部内容而付费。上下文窗口是预算，检索和好的 Prompt 工程是你如何明智地花掉它。

那个让团队意外的「迷失在中间」效应，举个实际例子：一家公司把一份 40 页的政策文档粘进 Prompt，问了一个答案落在第 20 页的问题。即便整份文档在技术上都在窗口之内，模型仍然答错，因为对埋在长上下文中间的材料，注意力会衰减。同一个模型，只递给它检索抽出来的那两段相关文字，就答对了。更大的窗口没有修好这个问题；更精准的上下文修好了。当一个新模型带着抢眼的窗口尺寸发布时，这正是创始人会忽略的反直觉之处：更大的容量并不等于更高的可靠性。

实用的要点：把上下文窗口当作一项带价签的稀缺资源，而不是免费空间。更大的窗口降低了压力，却没有消除它，成本和延迟仍然随你放进去的内容而增长。我们在 人工智能 下有意围绕这个预算来设计。