窗口越大越好？斯坦福论文：答案藏在长上下文中间，模型反而不如不看

配图：AI 生成的概念示意图，非论文原图或实验数据。

TL;DR：2023 年，斯坦福等机构的研究者发现，把答案放在长输入的开头或结尾，模型答得最好；放在中间，准确率明显下降，在最差情况下甚至低于完全不给资料。这篇论文测的是当时的模型，输入长度在万级 token 量级，并没有测过百万 token。它说明的是“塞得进”不等于“用得好”，而不是“窗口越大越没用”。

这是 2023 年的老论文，不是今天的新闻。 论文《Lost in the Middle: How Language Models Use Long Contexts》2023 年 7 月 6 日发上 arXiv，作者包括 Nelson F. Liu、Percy Liang 等，后来发表在 TACL 2024 年第 12 卷。文中测试的是 GPT-3.5-Turbo、Claude-1.3、MPT-30B-Instruct、LongChat 等当时的模型，今天的模型表现需要另行评测。

他们怎么测的

论文设计了两个任务。

第一个是多文档问答：用 NaturalQuestions-Open 的问题（共 2655 条），给模型 10、20 或 30 篇维基百科段落，其中只有一篇含有答案，其余是检索出来的干扰段落。研究者只改变一件事：含答案的那篇排在第几位。

第二个是键值检索：给模型一大串 JSON 键值对，问其中某个键对应的值，是最简单的“找东西”任务。

结果：一条 U 形曲线

多文档问答里，模型的准确率随答案位置呈 U 形：答案在最前或最后时最好，在中间时最差。以 GPT-3.5-Turbo 的 10 篇文档设置为例，答案在第 1 位时准确率约 76.8%，在中间（第 5 位）约 61.2%。

更刺眼的是对照：不给任何文档、让模型凭记忆答题，GPT-3.5-Turbo 是 56.1%。论文写道，在 20 篇和 30 篇的设置里，最差情况的表现“低于完全没有输入文档”；20 篇文档、答案排在中间（第 10 位）时，GPT-3.5-Turbo 只有 53.8%。

键值检索更能说明问题：Claude-1.3 在测试长度下几乎全对，但 GPT-3.5-Turbo 等模型在键值对多到 140 或 300 对时，最容易在答案位于中间时出错。

几个附带发现

• 号称长上下文的版本（如 16K 版 GPT-3.5-Turbo）并没有明显摆脱这个问题。
• 编码器-解码器模型在训练时的长度内相当稳健，超出后同样出现 U 形。
• 指令微调不是原因：基础版 MPT-30B 也有 U 形，指令微调后最差情况的落差从近 10% 缩小到约 4%。
• 实际检索增强场景里，把检索文档从 20 篇增加到 50 篇，GPT-3.5-Turbo 只提升约 1.5%，Claude-1.3 约 1%。读者模型“吃不下”的速度，比检索召回上升得快。

为什么重要

这篇论文给“窗口越大越好”泼了一盆冷水：能放进去，和能用上，是两回事。对做 RAG 或长文档问答的人，实用的启发是少塞、把关键内容放在开头或结尾，别指望模型均匀地读完每一段。

但也别读过头：这是对 2023 年模型的结论，之后的模型和训练方法在不断改进，同类“大海捞针”测试的结果也在变。要判断某个新模型，还得看新的测评。

论文地址：arXiv:2307.03172