大模型的上下文窗口越大越好吗？Lost in the Middle 是什么？
面试怎么回答
窗口大不等于用得好。Lost in the Middle 研究发现关键信息放在长上下文开头或结尾时模型用得最好，放在中间效果明显下降，呈 U 形曲线；新模型进步很大，但上下文越长越难稳定使用关键信息的趋势仍在，特别是需要综合多处信息时。长上下文还带来成本、首 Token 延迟、KV Cache 显存和无关信息干扰的问题。标称窗口只是能接受的最大长度，效果要自己评测，最好用多处信息综合和真实业务长度的测试，而不只是大海捞针。工程上我会检索后重排只放最相关的内容，把关键指令和问题放在开头或结尾，用标签结构化分隔，压缩长历史，超长文档分段处理再汇总，并用评测集对比不同策略。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
模型的上下文窗口从 8K 涨到了 128K、1M，于是有人觉得「信息全塞进去就行了」。但实际效果往往不如预期：放进去的关键信息，模型就是没用上。面试官问这题，想看你知不知道长上下文的局限，以及工程上怎么应对。
Lost in the Middle
2023 年的一篇研究（《Lost in the Middle》）发现：当关键信息放在长上下文的开头或结尾时，模型使用得最好；放在中间时，效果明显下降，呈现一条 U 形曲线。
虽然后来的模型在长上下文能力上有了很大进步，但「上下文越长、信息越多，模型越难稳定地找到并使用关键信息」这个趋势依然存在，尤其是需要综合多处信息推理时。
上下文越大的其他代价
- 成本：输入 Token 按量计费，长上下文每次都要付费；
- 延迟：Prefill 时间随输入长度增加，首 Token 等待变长；
- 显存：KV Cache 随长度线性增长，私有化部署时并发下降；
- 干扰：无关信息、相互矛盾的信息越多，模型越容易被带偏。
「能放下」和「能用好」是两回事
厂商标称的窗口大小，是模型能接受的最大长度；在这个长度下效果能保持多好，需要自己评测。常见的测试方式：
- 大海捞针：在长文本的不同位置插入一条关键信息，测试能否找到。这只测检索能力，偏简单；
- 多处信息综合：答案需要结合上下文中几处不同位置的信息，更接近真实场景；
- 用自己的任务测：在实际业务的长度分布下评测准确率。
工程上的应对
- 少而精：检索后重排，只放最相关的内容；
- 位置安排：最重要的指令和信息放在开头或结尾，比如把用户的问题放在检索内容之后、在最后再强调一遍要求；
- 结构化：用标题、标签分隔不同来源的内容，帮助模型定位；
- 压缩和摘要：长对话历史、长文档先压缩；
- 分而治之：超长文档分段处理再汇总（map-reduce 的思路）；
- 评测驱动：不同的上下文策略在评测集上对比，而不是凭感觉。