长上下文里答案放中间，GPT-3.5 比不给文档还答得差？《Lost in the Middle》

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

TL;DR：斯坦福等机构的研究者发现，把相关信息放在长输入的开头或结尾，模型答得最好；放在中间，准确率明显下滑。在多文档问答里，GPT-3.5-Turbo 在最差位置的表现甚至低于完全不给文档的基线（56.1%）。这说明模型并不能稳健地利用整段长上下文，但不等于「长上下文没用」：多数位置上给文档仍然有帮助。

这是一篇 2023 年的老论文：arXiv 首版于 2023 年 7 月 6 日提交，后发表于 TACL 2024。文中测的是当时的模型，现在的模型表现未必相同，但它提出的测法至今仍被广泛沿用。

论文做了什么

作者是 Nelson F. Liu、Percy Liang 等人。他们设计了两个简单任务，专门考察「信息放在哪儿」的影响。

第一个是多文档问答：用 NaturalQuestions-Open 的 2655 个问题，给模型 10、20 或 30 段维基百科文本，其中只有一段含答案，其余是检索来的干扰段落。研究者只改变含答案那段的位置，其他不动。

第二个是键值检索：给模型一个由随机 UUID 组成的 JSON，含 75、140 或 300 个键值对，让它找出某个键对应的值。任务没有语义难度，纯粹考察「能不能找到」。

结果：U 形曲线

被测模型包括 MPT-30B-Instruct、LongChat-13B（16K）、GPT-3.5-Turbo（含 16K 版）和 Claude-1.3（含 100K 版）。几乎所有模型都呈现 U 形曲线：答案在开头或结尾时最好，在中间时最差。

最醒目的一条：GPT-3.5-Turbo 完全不给文档（闭卷）时准确率为 56.1%，而在 20 或 30 段文档、答案落在中间的设置里，表现会掉到这个数字以下。也就是说，塞进去一份含正确答案的文档，反而可能比什么都不给更糟。

长上下文版本也没有幸免：16K 或 100K 的模型，只要输入还装得下，表现与短版本相近，位置问题依旧。编码器-解码器模型（Flan-UL2、Flan-T5-XXL）在训练长度以内对位置较不敏感，超出后同样出现 U 形。

为什么值得在意

这项研究直接影响了检索增强生成（RAG）的做法。论文还发现，检索文档从 20 段增加到 50 段，读取端的准确率只涨一点点，读者能力先于检索召回饱和。作者因此建议对排序后的文档做重排或截断，而不是一味多塞。实际工程里，把最重要的材料放在提示的头尾，也成了常见做法。

需要留意的是：这是对 2023 年模型的结论，并非所有后来的模型都同样「迷路」。但「上下文窗口大，不等于用得好」这个提醒，依然成立。

论文地址：arXiv:2307.03172