Lost in the Middle

论文关注的不是“能塞多长”，而是“能不能真正用上”

长上下文模型发布时，最容易被宣传的一项能力就是“支持 32k、100k 甚至更长的上下文”。但对真实系统来说，真正关键的问题不是窗口上限，而是：

当关键信息被放进很长的上下文里，模型真的会把它找出来并正确利用吗？

《Lost in the Middle》给出的答案很尖锐：不一定。模型对上下文位置存在明显偏好，尤其容易利用开头和结尾的信息，而对中间位置的证据表现更差。这也是为什么很多 RAG 系统明明“召回到了正确文档”，最终回答依然不稳定。

实验设计：只改变证据位置，观察性能变化

这篇论文的实验思路非常干净。作者并没有让任务本身变复杂，而是尽量控制变量，只改变“答案相关证据放在上下文的哪个位置”。

他们主要考察了两类任务：

1. 多文档问答：把相关文档和若干干扰文档拼接成长上下文，观察模型能否从中找出正确证据。
2. 键值检索式任务：构造更可控的设置，测试模型是否能从长上下文中精确提取目标项。

在这个框架下，研究者可以比较：

• 当相关证据靠近开头时，模型表现如何。
• 当相关证据靠近结尾时，模型表现如何。
• 当相关证据被放到中段时，性能是否会系统性下降。

这种实验设计非常有力量，因为它直接把“长上下文能力”拆成了一个更具体的问题：位置鲁棒性。

核心结果：性能呈明显 U 形曲线

论文最出名的发现，就是模型性能随证据位置变化呈现出接近 U 形的趋势：

• 证据放在上下文前部，表现通常较好。
• 证据放在上下文后部，表现也往往不错。
• 证据放在中间区域，性能明显下滑。

这意味着模型并不是平均地“扫描”整段上下文，而是对边界区域存在偏好。换句话说，上下文窗口的扩大，只是让模型“能看到更多 token”，并不自动意味着模型“会公平地利用每个位置的信息”。

这点对产品特别重要。很多团队会误以为只要把检索结果全塞给模型，命中率自然会上升；论文提醒我们，长上下文本身也会引入新的排序问题。

为什么会出现“中间遗失”

论文主要是做现象刻画，但从机制上可以这样理解：

1. 位置偏置并没有消失

即便模型使用了现代位置编码，也不代表所有位置都同样容易被利用。训练数据中，很多任务天然更依赖开头指令和最近上下文，模型会形成偏置。

2. 注意力容量是稀缺资源

上下文越长，模型需要在越多 token 之间分配注意力。若没有额外机制帮助聚焦，中段信息更容易被噪声淹没。

3. 提示模板常常加剧边界效应

现实系统中，我们往往把任务说明放在最前面，把当前问题放在最后面。这样一来，中间的检索材料天然处于“最不显眼”的位置，模型更容易忽略它们。

对 RAG 系统的直接启示

这篇论文对 RAG 设计几乎是必读，因为它揭示了一个常见误区：召回成功 != 使用成功。

如果你在做检索增强生成，可以直接得到几条实践建议：

1. 不要只按相似度排序后原样拼接，应该显式考虑证据在 prompt 中的摆放位置。
2. 把最关键、最可信的证据放在靠前或靠后的位置，而不是平均分散。
3. 对核心证据做摘要或结构化抽取，减少模型必须在中段长文本里“自己找答案”的负担。
4. 在长文档场景中，优先做 chunk 级重排，再决定最终输入顺序。
5. 对特别重要的约束条件，可以通过标题、项目符号、重复引用等方式增加显著性。

如果把这篇论文和实际工程结合起来，可以把 RAG 管线理解为三层问题：

• 能不能召回到正确证据。
• 能不能把正确证据排到模型更容易用的位置。
• 能不能让模型在生成时稳定引用它。

很多线上问题，其实卡在第二层，而不是第一层。

对提示工程的启示

即使你不用 RAG，这篇论文对提示词设计也有帮助。几个常见策略包括：

• 把任务定义放前面，把最终问题放最后面，让模型在进入回答前再次聚焦。
• 如果中间必须放大量背景材料，最好加小标题、编号、引用标签，降低定位成本。
• 对必须命中的事实，优先在结尾再做一次压缩提醒。
• 如果证据很多，先让模型做“摘要/排序/选择”，再进入最终回答阶段。

这也是为什么很多高质量 agent 或长文档工作流会拆成多步，而不是一次把所有上下文扔进去直接问。

这篇论文的边界

虽然结论很有冲击力，但也要注意它的适用范围：

• 它刻画的是当时主流长上下文模型在特定任务上的表现，不代表所有新模型都一样严重。
• 论文关注的是“位置利用能力”，不是完整的系统设计；加入检索、重排、摘要、工具调用后，现象可以被部分缓解。
• 某些需要全局综合的任务，并不能简单通过“把答案放头尾”解决。

因此，这篇论文更像一个告警器：它提醒我们不要把上下文长度当作能力本身，而要继续验证模型是否真正具备位置鲁棒性。

一个更实用的阅读视角

如果你是工程师，可以把这篇论文读成一个检查清单：

• 我的系统是否把最重要证据放在了最容易被忽视的位置？
• 我是否把多个高相关 chunk 塞在中间却没有做显式重排？
• 我评测的是“召回率”，还是“最终回答是否真正使用了证据”？
• 当结果不稳定时，我排查过 prompt 排布问题吗？

如果你是研究者，这篇论文则是一个很好的起点，去思考更深层的问题：如何设计对位置更鲁棒的架构、训练目标与评测基准。

延伸阅读

• 如果你还不熟悉注意力为何会产生位置偏好，建议先看 Transformer 注意力机制入门。
• 如果你在做系统优化，可以继续看 KV Cache 与推理性能优化，理解长上下文为何不仅难用，而且昂贵。
• 想理解长上下文问题的架构根源，建议回到 Attention Is All You Need。