上下文窗口越大越好？模型中间信息丢失的真相

一个看似简单的失败案例

一个客服机器人的流程简单到几乎无可挑剔：检索文档，取排名前二十的段落，塞进提示词，问题放在最后。答案就藏在第十一段里——它确实在，位置没丢，总长度也远未超限。但机器人给出的回复是：没有找到相关信息。

没有东西缺失。所有内容都在上下文窗口内。模型只是没有用它。

这不是工程失误，而是大模型一个被反复验证的结构性弱点。它指向一个关键认知：上下文窗口的容量，和模型实际有效利用信息的能力，是两件事。

Lost in the Middle：被位置决定的信息利用率

关于这个现象，有一篇被广泛引用的论文，叫 Lost in the Middle，发表于 2023 年。研究者的实验设计很直接：把唯一有用的那段内容藏在大量无关段落中间，然后不断移动它的位置。

结果呈现出清晰的 U 形曲线。当关键信息位于上下文的开头或结尾时，模型的准确率最高；一旦把它放到中间，准确率就明显下降——有时甚至低于模型完全不给任何文档时的表现。

换句话说，给模型更多上下文，如果关键内容落在中间，反而可能比什么都不给更糟。

这个规律在后续的很多复现实验中被反复观察到。更新的模型确实在这件事上有改善，但没有一个做到完美。更麻烦的是，没有任何模型会主动告诉你它跳过了什么。

Lost in the Middle 指的是大语言模型在处理长上下文时，对中间位置信息的检索与利用能力显著下降的现象。论文全称为 Lost in the Middle: How Language Models Use Long Contexts（Liu et al., 2023），由斯坦福大学等机构的研究者完成。实验采用「多文档问答」（multi-document QA）和「键值检索」（key-value retrieval）两类任务，通过控制唯一相关信息在输入中的位置，系统测量模型的准确率变化。结论是：模型对首尾位置的信息最敏感，中段信息则容易被忽略。这一现象与 Transformer 的注意力机制有关——软注意力在长序列上会被大量 token 稀释，且训练数据中的位置分布也可能导致模型对中段形成偏差。

长窗口是一个承诺，但不是一份保证

很多团队在选型时会把上下文长度当作核心指标：128K、200K、1M tokens。数字越大战胜一切。但 Lost in the Middle 揭示的真相是：

一个大的上下文窗口，是对「什么能装进去」的承诺，而不是对「什么会被同等仔细地读到」的承诺。

模型在处理长上下文时，注意力分布是不均匀的。开头和结尾天然占据优势，中间区域则容易被稀释。这就像一条长长的走廊：模型会检查进来的那扇门，也会检查即将离开的那扇门，但走廊中段发生了什么，它未必留意。

所以，不要把关键信息藏在半路。

上下文窗口（context window） 指的是大模型单次推理能够接收的最大 token 数量，包括输入提示词和生成内容。早期 GPT-3 为 4K token，如今主流模型已达 128K 甚至 1M token。窗口越大，理论上可容纳的文档、对话历史、代码库就越多。但「能装进去」与「能有效处理」是两条不同的能力曲线：窗口大小主要由位置编码（如 RoPE、ALiBi）和注意力实现（如 FlashAttention、稀疏注意力）决定，而信息利用率则取决于模型在训练中是否见过类似的长距离依赖模式。因此，选型时不能只看窗口数字，还要结合具体任务做位置敏感性测试。

解法：不是塞更多，而是送更少

既然问题出在信息利用效率，而不是容量，那么修复方向就很明确——减少送入的内容量，而不是增加。

以下是几个可以直接落地的策略：

1. 不要因为「装得下」就送满

二十个段落被选中，往往不是因为它们都相关，而是因为二十个恰好能塞进去。这不该是理由。对检索结果做更严格的排序，设置一个经过实际测试的分数阈值，低于它的直接砍掉。

2. 五个精准段落胜过二十个混杂段落

如果正确答案埋在二十段中间，模型很可能错过它。但如果只送五个高质量段落，且正确的那一段排在最前面，命中率会显著提升。质量优先于数量。

3. 把最强的内容放在开头

基于 U 形曲线的规律，最相关的段落应该放在上下文的最前面。这是模型注意力最集中的位置之一。

4. 问题靠近结尾，必要时重复

把用户问题放在上下文末尾，紧接在文档之后。如果提示词很长，可以在结尾处再复述一遍问题，强化模型的关注点。

5. 不要让检索顺序决定一切

当顺序对结果有影响时，不要直接把搜索返回的原始顺序塞进去。主动重排，把最重要的内容放到注意力高地。

RAG（Retrieval-Augmented Generation，检索增强生成） 是当前缓解长上下文弱点的主流架构：先从外部知识库检索相关片段，再将它们与用户问题一起送入模型。RAG 的核心质量取决于检索器（常见为稠密向量检索，如基于 embedding 的相似度搜索）和重排序器（reranker）。如果检索阶段返回大量低相关段落，就会人为制造「Lost in the Middle」的陷阱。因此，文中提到的阈值过滤、重排序、控制段落数量，本质上都是在优化 RAG 的输入质量，而非单纯依赖模型的窗口容量。

测量方法：一个你从未跑过的实验

上述策略是否有效，不应该靠直觉判断。有一个简单的验证方法：

拿一个已知答案的问题，把包含正确答案的段落分别放在上下文的开头、中间、结尾，各跑一次。如果三次的答案不一致，你就发现了一个你的评测基准从未告诉你的问题。

很多团队的标准评测集只关心「模型能不能答对」，但不关心「答案在上下文中的位置」。这恰恰是生产环境中出问题的高发地带。

长上下文时代的真正功课

长上下文窗口是真实的技术进步，它让更多应用场景成为可能。但它不是万能药。把更多东西塞进去，不等于模型会更好地使用它们。

真正需要做的，是重新审视整个检索与提示词构造的链路：排序是否合理、阈值是否经过验证、关键信息是否放在了注意力高地、问题是否足够靠近结尾。

长上下文是一条长长的走廊。模型会看它进来的门，也会看它离开的门。别把最重要的东西藏在走廊中段。