Lost in the Middle: How Language Models Use Long Contexts
Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, Percy Liang
cs.CL
2023-07-07
斯坦福把含答案的文档在十到三十篇检索结果里左右移动。GPT-3.5答案落在中间时低于闭卷基线56.1%，加长窗口几乎不改U形曲线。
2023 年模型已经能吃 4K、16K 甚至 100K token。检索增强生成和长文档问答把整页搜索结果塞进 prompt，窗口变长常被直接读成能力变强。这篇要测的是另一件事：相关信息在上下文里换个位置，模型还能不能稳定用上。
如果长上下文被稳健使用，答案在第 1 篇还是第 15 篇，分数不该大变。实验表明会大变，而且中间最差。
两条可控任务。
多文档问答取 NaturalQuestions-Open 里 2655 条长答案为段落的问题。上下文恰好 1 篇含答案，其余 k−1 篇是 Contriever 检索来的、不含标注答案的干扰段。k 取 10/20/30，大约 2K/4K/6K token。重排文档来移动答案位置，加干扰文档来加长上下文。指标是生成文本里是否出现任一标注答案。
键值检索更干净：一组随机 UUID 的 JSON，问某个 key 的 value。k 取 75/140/300 对，大约 4K/8K/16K token。几乎剥掉自然语言语义，只测能不能从上下文里精确取出匹配 token。
开源侧是 MPT-30B-Instruct（8K）和 LongChat-13B（16K）；闭源侧是 GPT-3.5-Turbo（4K 与 16K）和 Claude-1.3（8K 与 100K）。解码一律 greedy。另外用 Flan-T5-XXL、Flan-UL2 看编码器-解码器，用 MPT-30B 底座看指令微调是不是元凶。
多文档问答画出标准 U 形：答案在开头或末尾最好，中间最差。
| 模型 | 闭卷 | oracle | 20篇、答案在开头 | 20篇、答案在中间 |
| GPT-3.5-Turbo | 56.1% | 88.3% | 75.8% | 53.8% |
| GPT-3.5-Turbo (16K) | 56.0% | 88.6% | 75.7% | 54.1% |
| Claude-1.3 | 48.3% | 76.1% | 59.9% | 56.8% |
| LongChat-13B (16K) | 35.0% | 83.4% | 68.6% | 55.3% |
20 篇设定里 GPT-3.5 从开头 75.8% 掉到中间 53.8%，已经低于闭卷 56.1%。30 篇、16K 版本中间是 50.5%。4K 和 16K 两条曲线几乎重合，加长窗口本身没有让模型更会用上下文。
键值检索上 Claude-1.3 近乎满分，GPT-3.5 和 MPT 在 140/300 对时中间明显塌。把问题同时放在材料前和材料后，键值任务能拉到接近满分，多文档问答几乎不动。
Flan-UL2 在训练长度 2048 以内，最好最差只差 1.9 个点；超出训练长度后同样变成 U 形。MPT-30B 底座已经是 U 形，指令微调把落差从约 10 个点收到约 4 个点，形状还在。Llama-2 7B 主要吃近因，13B 和 70B 才同时出现首因和近因。
开放域问答里，检索召回还在随 k 上升，阅读准确率在大约 20 篇之后几乎不动：GPT-3.5 从 20 篇加到 50 篇大约多 1.5 个点，Claude 大约 1 个点。
上下文窗口的广告数字，和「能用上这些 token」不是一回事。RAG 里多捞文档可能在帮倒忙：干扰变多，答案还容易被挤到中间。更有效的操作是重排序，把可能有用的段落推到开头或结尾，或者该截断时截断。
评测长上下文模型，不能只报一个平均分。论文给的协议很硬：最好情况和最差情况的差距要小，才能声称稳健使用长上下文。
任务构造干净，也因此偏实验室。多文档设定永远恰好一篇含答案，真实检索经常是 0 篇或多篇。干扰段按相关性降序排列，可能和「搜索结果」先验缠在一起，随机打乱的附录里趋势仍在。评测看字符串是否命中标注答案，会漏掉改写。GPT-4 只跑了子集。模型都是 2023 年中的，后来专门针对长上下文的训练有没有把 U 形填平，这篇给不出答案。query-aware 救了键值、救不了问答，说明「找不到」只是一部分，「找到了不会用」是另一部分，机制仍不清楚。