{"notes":[{"id":"model-evaluation/lost-in-the-middle","category":"model-evaluation","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"Lost in the Middle","subtitle":"U 形的诅咒","author":"Z. Yuan","paperDate":"2023-07-06","publishedOn":"2026-06-09","world":"external/lost-in-the-middle","paperTitle":"Lost in the Middle: How Language Models Use Long Contexts","paperUrl":"https://arxiv.org/abs/2307.03172","bibliography":{"title":"Lost in the Middle: How Language Models Use Long Contexts","authors":["Nelson F. Liu","Kevin Lin","John Hewitt","Ashwin Paranjape","Michele Bevilacqua","Fabio Petroni","Percy Liang"],"url":"https://arxiv.org/abs/2307.03172","pdfUrl":"https://arxiv.org/pdf/2307.03172v3","codeUrl":null,"preprint":{"id":"2307.03172","submittedOn":"2023-07-06","url":"https://arxiv.org/abs/2307.03172"},"publication":{"venue":"Transactions of the Association for Computational Linguistics","year":2024,"kind":"journal","url":"https://aclanthology.org/2024.tacl-1.9/"},"citation":"@misc{modelevaluationlostinthemiddle2023,\n  title = {{Lost in the Middle: How Language Models Use Long Contexts}},\n  author = {Nelson F. Liu and Kevin Lin and John Hewitt and Ashwin Paranjape and Michele Bevilacqua and Fabio Petroni and Percy Liang},\n  year = {2023},\n  eprint = {2307.03172},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2307.03172}\n}\n","citationPath":"/content/papers/citations/model-evaluation/lost-in-the-middle.77681ac150c1.bib"},"thumbnail":{"src":"/content/papers/assets/14c392ed0cd20cff36405d2cccc1e1d2e317e1c84de40c4eae37cde79f4a31e3.png","width":1278,"height":425},"locale":"zh-hans","path":"/content/papers/zh-hans/model-evaluation/lost-in-the-middle.eeda3e34f553.md","headings":[{"id":"定义问题","text":"定义问题","depth":2},{"id":"解决问题","text":"解决问题","depth":2},{"id":"多文档问答","text":"多文档问答","depth":3},{"id":"键值检索","text":"键值检索","depth":3},{"id":"受测模型","text":"受测模型","depth":3},{"id":"讨论","text":"讨论","depth":2},{"id":"u-形曲线","text":"U 形曲线","depth":3},{"id":"长版模型比较会用长上下文吗","text":"长版模型，比较会用长上下文吗？","depth":3},{"id":"连抄字符串都会失手","text":"连抄字符串都会失手","depth":3},{"id":"为什么会这样","text":"为什么会这样？","depth":3},{"id":"那多放一点文档呢","text":"那多放一点文档呢？","depth":3},{"id":"后来的故事","text":"后来的故事","depth":3},{"id":"结论","text":"结论","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"model-evaluation/nolima","relation":"citing","topic":""}]},{"id":"model-evaluation/nolima","category":"model-evaluation","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"NoLiMa","subtitle":"言外之意","author":"Z. Yuan","paperDate":"2025-02-07","publishedOn":"2026-07-30","paperTitle":"NoLiMa: Long-Context Evaluation Beyond Literal Matching","paperUrl":"https://arxiv.org/abs/2502.05167","bibliography":{"title":"NoLiMa: Long-Context Evaluation Beyond Literal Matching","authors":["Ali Modarressi","Hanieh Deilamsalehy","Franck Dernoncourt","Trung Bui","Ryan Rossi","Seunghyun Yoon","Hinrich Schütze"],"url":"https://arxiv.org/abs/2502.05167","pdfUrl":"https://arxiv.org/pdf/2502.05167v3","codeUrl":"https://github.com/adobe-research/NoLiMa","preprint":{"id":"2502.05167","submittedOn":"2025-02-07","url":"https://arxiv.org/abs/2502.05167"},"publication":{"venue":"ICML","year":2025,"kind":"conference","url":"https://proceedings.mlr.press/v267/modarressi25a.html"},"citation":"@misc{modelevaluationnolima2025,\n  title = {{NoLiMa: Long-Context Evaluation Beyond Literal Matching}},\n  author = {Ali Modarressi and Hanieh Deilamsalehy and Franck Dernoncourt and Trung Bui and Ryan Rossi and Seunghyun Yoon and Hinrich Schütze},\n  year = {2025},\n  eprint = {2502.05167},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2502.05167}\n}\n","citationPath":"/content/papers/citations/model-evaluation/nolima.264a4512e69f.bib"},"thumbnail":{"src":"/content/papers/assets/d3917196027c3729a255d140f88c8ddc4cf99d5ea087de73ead2f387a8befb47.png","width":1440,"height":919},"locale":"zh-hans","path":"/content/papers/zh-hans/model-evaluation/nolima.aafd75039807.md","headings":[{"id":"定义问题","text":"定义问题","depth":2},{"id":"解决问题","text":"解决问题","depth":2},{"id":"一根不会对字的针","text":"一根不会「对字」的针","depth":3},{"id":"把干草清干净","text":"把干草清干净","depth":3},{"id":"怎么算分","text":"怎么算分？","depth":3},{"id":"讨论","text":"讨论","depth":2},{"id":"主要结果","text":"主要结果","depth":3},{"id":"两跳比一跳难倒装比默认难","text":"两跳比一跳难，倒装比默认难","depth":3},{"id":"是位置的问题还是长度的问题","text":"是位置的问题，还是长度的问题？","depth":3},{"id":"让模型想一想有用吗","text":"让模型想一想，有用吗？","depth":3},{"id":"把字面线索放回去","text":"把字面线索放回去","depth":3},{"id":"新模型呢","text":"新模型呢？","depth":3},{"id":"结论","text":"结论","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"model-evaluation/lost-in-the-middle","relation":"referenced","topic":""}]}],"text":"2023 年，语言模型的上下文长度一路往上加。\n\nGPT-3.5-Turbo 出了 16K 版本，Claude 出了 100K 版本，开源社群也忙着把 LLaMA 的 2,048 token 拉长到 16K。宣传上的数字越来越大，大家也很自然地开始想：既然放得下，那就把更多文档塞进去吧。\n\n但「放得下」和「用得上」是两件事。\n\n一份文档放在提示词的第一段，和放在第十段，模型读到的机会一样吗？\n\n这篇来自 Stanford、UC Berkeley 与 Samaya AI 的论文（后来刊登于 TACL），就是在量这件事。结果画出来是一条 U 形曲线：答案放在开头或结尾，模型答得最好；放在中间，成绩明显下滑。\n\n## 定义问题\n\n作者想回答的问题很单纯：\n\n- **语言模型能不能稳定地使用长上下文里任何位置的信息？**\n\n如果能，那么把相关信息从第 1 段移到第 10 段，成绩应该几乎不变。\n\n这个想法给了一个很干净的实验设计：题目和答案都不动，只改两件事。\n\n1. **相关信息放在哪里。**\n2. **上下文有多长。**\n\n其他条件固定，看成绩怎么变。\n\n## 解决问题\n\n这是一篇评测论文，所谓的「解决」，是设计出能把位置效应单独拿出来量的实验。作者准备了两个任务：一个贴近实际 RAG 情境，另一个尽量拿掉语义，只剩下「找到相同字符串」。\n\n### 多文档问答\n\n第一个任务模仿当时很常见的生成式搜索：给模型一个问题和 $k$ 份文档，其中**只有一份**含有答案，其余 $k-1$ 份都是干扰文档。\n\n输入大概长这样（取自原论文 Figure 2，中间省略）：\n\n```text\nWrite a high-quality answer for the given question using only the provided search\nresults (some of which might be irrelevant).\n\nDocument [1](Title: Asian Americans in science and technology) Prize in physics for\ndiscovery of the subatomic particle J/ψ. Subrahmanyan Chandrasekhar shared...\nDocument [2](Title: List of Nobel laureates in Physics) The first Nobel Prize in\nPhysics was awarded in 1901 to Wilhelm Conrad Röntgen, of Germany, who received...\nDocument [3](Title: Scientist) and pursued through a unique method, was essentially\nin place. Ramón y Cajal won the Nobel Prize in 1906 for his remarkable...\n\nQuestion: who got the first nobel prize in physics\nAnswer:\n```\n\n正确答案是 Wilhelm Conrad Röntgen，藏在 Document [2]。\n\n题目来自 NaturalQuestions-Open，是真实的 Google 搜索查询，搭配人工从维基百科标出的答案。作者只取答案是一整个段落的 2,655 题。\n\n干扰文档不是随便抓的。作者用 Contriever 检索器找出和问题**最相关、但不含答案**的维基百科段落，按相关程度排序放进去。这些文档看起来都很像答案，模型得真的读懂才分得出来。\n\n接着就可以开始调整：\n\n- **改位置**：把含答案的那份文档，依序放到第 1、第 5、第 10……个位置。内容完全不变，只换顺序。\n- **改长度**：干扰文档从 9 份加到 19 份、29 份，总共 10、20、30 份文档，大约是 2K、4K、6K token。\n\n评分方式很宽松：模型的输出里只要出现任何一个标准答案，就算答对。\n\n\n> [!TIP]\n> \n> **另外两条参考线**\n> \n> 为了知道成绩的高低代表什么，作者还量了两个基准：\n> \n> - **Closed-book**：完全不给文档，只靠模型自己记得的知识作答。\n> - **Oracle**：只给那一份含答案的文档。\n> \n> 如果放了 20 份文档之后，成绩反而低于 closed-book，就代表这些文档不但没帮上忙，还把模型搞糊涂了。\n\n\n### 键值检索\n\n第二个任务把语义拿掉，只留下最基本的「找」。\n\n给模型一个 JSON 对象，里面有 $k$ 组键值对，每个键和值都是随机产生的 UUID。再给一个键，请模型回答对应的值：\n\n```text\nExtract the value corresponding to the specified key in the JSON object below.\n\nJSON data:\n{\"2a8d601d-1d69-4e64-9f90-8ad825a74195\": \"bb3ba2a5-7de8-434b-a86e-a88bb9fa7289\",\n \"a54e2eed-e625-4570-9f74-3624e77d6684\": \"d1ff29be-4e2a-4208-a182-0cea716be3d4\",\n \"9f4a92b9-5f69-4725-ba1e-403f08dea695\": \"703a7ce5-f17f-4e6d-b895-5836ba5ec71c\",\n ...}\n\nKey: \"9f4a92b9-5f69-4725-ba1e-403f08dea695\"\nCorresponding value:\n```\n\n这个任务只要求在上下文里找到一模一样的字符串，再把后面那串抄出来，不需要理解任何意思。作者用 75、140、300 组键值对，大约 4K、8K、16K token，每种 500 题。\n\n如果模型连这个都做不好，问题就不在「看不懂文档」，而在更基本的「找不到」。\n\n### 受测模型\n\n作者测了六个模型，其中两组是同一模型的短版和延长版：\n\n| 模型 | 最大上下文 | 说明 |\n| --- | --- | --- |\n| GPT-3.5-Turbo | 4K | OpenAI API |\n| GPT-3.5-Turbo (16K) | 16K | 同一模型的延长版 |\n| Claude-1.3 | 8K | Anthropic API |\n| Claude-1.3 (100K) | 100K | 同一模型的延长版 |\n| MPT-30B-Instruct | 8K | 开源，使用 ALiBi 位置编码 |\n| LongChat-13B (16K) | 16K | 开源，由 LLaMA-13B 的 2,048 延长到 16,384 |\n\nOpenAI 的模型使用 0613 版本，所有模型都用 greedy decoding，也就是每一步都选概率最高的 token。\n\n## 讨论\n\n### U 形曲线\n\n[![多文档问答中，答案文档位置与准确率的关系；10、20、30 份文档三种设置下，多数模型呈现 U 形曲线](/content/papers/assets/14c392ed0cd20cff36405d2cccc1e1d2e317e1c84de40c4eae37cde79f4a31e3.png)](/content/papers/assets/14c392ed0cd20cff36405d2cccc1e1d2e317e1c84de40c4eae37cde79f4a31e3.png)\n\n*原论文 Figure 5，取自 [**v3 PDF 第 5 页**](https://arxiv.org/pdf/2307.03172v3#page=5)。由左至右为 10、20、30 份文档；横轴是含答案文档的位置，越左越靠近开头。*\n\n先看中间那张，20 份文档、大约 4K token。\n\nGPT-3.5-Turbo 的线从左上角出发：答案在第 1 份时，准确率约 76%。往右移，一路掉到第 10 份附近的谷底，最后在第 20 份又爬回来一些。\n\n把附录的原始数字拿出来看会更清楚：\n\n| 答案文档位置 | 第 1 份 | 第 5 份 | 第 10 份 | 第 15 份 | 第 20 份 |\n| --- | ---: | ---: | ---: | ---: | ---: |\n| GPT-3.5-Turbo | 75.8% | 57.2% | 53.8% | 55.4% | 63.2% |\n\n*整理自原论文 Table 6（附录 G.2）。*\n\n再对照前面那两条参考线：GPT-3.5-Turbo 的 closed-book 准确率是 56.1%，oracle 是 88.3%。\n\n所以答案放在第 10 份时，53.8% 比完全不给文档还低。\n\n给了 20 份文档，其中明明有一份写着答案，模型的表现却比什么都不给还差。\n\n这就是论文标题的「lost in the middle」。作者把开头表现好叫做**首位偏差（primacy bias）**，结尾表现好叫做**近因偏差（recency bias）**。\n\n\n> [!NOTE]\n> \n> **人类也有类似的现象**\n> \n> 心理学里有个「序列位置效应」（serial-position effect）：让人记住一串清单再自由回想，最容易记得的是开头和结尾的项目。作者在相关研究一节也提到这种联系。\n> \n> 不过作者也说，在 Transformer 里看到这种现象有点出乎意料。自注意力在设计上可以直接看到任何位置的 token，技术上没有「距离越远越难看到」的限制。\n\n\n### 长版模型，比较会用长上下文吗？\n\nGPT-3.5-Turbo 有 4K 和 16K 两个版本，10 份和 20 份文档的设置两个都放得下。\n\n图上两条线几乎叠在一起。以 20 份文档、答案在第 1 份为例，两者分别是 75.8% 和 75.7%；在第 10 份，则是 53.8% 和 54.1%。Claude-1.3 和它的 100K 版本也是一样的情况。\n\n作者的结论是：**上下文更长的版本，不见得更会使用上下文**。它只是放得下更多东西，对于放得下的那些内容，用法和短版没有什么差别。\n\n### 连抄字符串都会失手\n\n[![键值检索任务中，要找的键所在位置与准确率；75、140、300 组键值对三种设置](/content/papers/assets/d5c6cdc14e580fa77e96f56fa8e44ce6e73030510903d8cd53891982597ae037.png)](/content/papers/assets/d5c6cdc14e580fa77e96f56fa8e44ce6e73030510903d8cd53891982597ae037.png)\n\n*原论文 Figure 7，取自 [**v3 PDF 第 7 页**](https://arxiv.org/pdf/2307.03172v3#page=7)。由左至右为 75、140、300 组键值对；横轴是要找的键所在位置。*\n\n键值检索的结果分成两群。\n\nClaude-1.3 和 Claude-1.3 (100K) 几乎在所有设置都接近 100%，曲线平平地贴在顶端。\n\n其他模型就没那么顺利了。看最右边的 300 组键值对：GPT-3.5-Turbo (16K) 在开头和结尾都接近满分，到了中间第 200 组附近掉到 45.6%。这个任务只需要找到完全相同的字符串，它还是会在中间失手。\n\nLongChat-13B (16K) 在 140 组时的曲线比较特别，前半段反而最差。作者观察后发现，当目标键放在开头时，它倾向写一段代码来「查找」这个键，而不是直接把值抄出来。\n\n### 为什么会这样？\n\n作者做了几组初步分析。\n\n1. **模型架构**。受测的开源模型都是 decoder-only，每个 token 只能看到前面的内容。作者另外测了两个 encoder-decoder 模型 Flan-T5-XXL 和 Flan-UL2。Flan-UL2 在训练长度 2,048 token 以内时，最好和最差的位置只差 1.9%；一旦输入超过训练长度，U 形曲线又出现了。作者推测，双向的 encoder 能让每份文档「看到」后面的文档，比较容易判断哪一份重要。\n\n2. **把问题放到前面**。decoder-only 模型读文档时还没看到问题，因为问题放在最后。那如果在文档前面也放一次问题呢？这招让键值检索几乎全部满分：GPT-3.5-Turbo (16K) 在 300 组键值对上达到 100%，没加之前最差是 45.6%。但在多文档问答上，成绩几乎没变。\n\n3. **指令微调**。指令数据通常把任务说明放在开头，会不会因此让模型偏重开头？作者比较了 MPT-30B 微调前后的版本，两者都有 U 形曲线。指令微调反而让最好和最差位置的差距，从将近 10% 缩小到约 4%。\n\n4. **模型大小**。附录里 Llama-2 的实验显示，7B 只有近因偏差，13B 和 70B 才出现完整的 U 形。\n\n另外还有几个排除其他解释的检查：把干扰文档换成随机抓的维基百科段落，成绩整体变高，但 U 形仍在；在指令里明说「搜索结果是随机排序的」并打乱干扰文档，趋势相同；GPT-4 在 500 题子集上的成绩比所有模型都高，曲线也还是 U 形。\n\n### 那多放一点文档呢？\n\n最后作者回到实际的 RAG 设置：用 Contriever 从维基百科检索 $k$ 份文档，全部放进提示词。这次不保证只有一份含答案，可能一份都没有，也可能好几份都有。\n\n[![检索文档数量增加时，Contriever 的召回率持续上升，但各模型的准确率很早就趋于平缓](/content/papers/assets/e49b7762340b5f14544176911003bf9bd877ecc9933dcaed2d30153d1a280c02.png)](/content/papers/assets/e49b7762340b5f14544176911003bf9bd877ecc9933dcaed2d30153d1a280c02.png)\n\n*原论文 Figure 11，取自 [**v3 PDF 第 10 页**](https://arxiv.org/pdf/2307.03172v3#page=10)。橙色虚线为检索器召回率，其余为各模型的准确率。*\n\n橙色那条是检索器的召回率，也就是前 $k$ 份文档里至少有一份含答案的比例。从 5 份到 50 份，它一路往上爬到快 90。\n\n但下面那几条模型准确率的线，大约 20 份之后就几乎平了。从 20 份加到 50 份，GPT-3.5-Turbo 只多约 1.5%，Claude-1.3 只多约 1%，输入长度却多了一倍多，延迟和费用也跟着增加。\n\n检索器找到了，模型没用上。\n\n作者据此提出两个方向：把相关文档**重排序**到靠近开头的位置，或是在适当时候**少取几份**。\n\n### 后来的故事\n\n这篇论文发表后几个月，长上下文的评测热闹了起来。\n\n2023 年 11 月，Greg Kamradt 做了一个很受欢迎的「大海捞针」（needle-in-a-haystack）测试：把一句和上下文格格不入的话，例如「在旧金山最棒的事，是在晴天吃个三明治、坐在 Dolores Park」，塞进一大堆 Paul Graham 的文章里，再问模型旧金山最好玩的是什么。\n\n这个测试的精神和本文的键值检索很像。不过，Anthropic 在 [**2023 年 12 月的说明**](https://claude.com/blog/claude-2-1-prompting)里提到，Claude 2.1 在这个测试中的失分，有一部分是因为模型被训练成「文档没有足够依据就不回答」，看到一句突兀的话，常常回答文档里没有明确答案。在回答开头补上一句「Here is the most relevant sentence in the context:」，原始评测的成绩从 27% 升到 98%。\n\n这提醒我们：测出来的分数低，原因不一定只有「位置」。模型的回答倾向、提示词写法，都可能混在同一个数字里。这篇论文用 closed-book、oracle、随机干扰和随机排序等设置逐一排除，也是为了把位置效应从其他因素里分开。\n\n## 结论\n\n这篇论文用控制位置与长度的实验，量出语言模型使用长上下文的一个弱点：\n\n1. **相关信息放在中间时，成绩明显下滑**。GPT-3.5-Turbo 在 20 份文档的设置下，从开头的 75.8% 掉到中间的 53.8%，比完全不给文档的 56.1% 还低。\n2. **上下文更长的版本，对放得下的内容用法差不多**。4K 和 16K 的 GPT-3.5-Turbo 曲线几乎重叠。\n3. **连单纯的字符串比对也会受影响**。在 300 组键值对中，GPT-3.5-Turbo (16K) 在中间的准确率掉到 45.6%。\n4. **多放文档的效益很快饱和**。从 20 份加到 50 份，准确率只多 1% 到 1.5%。\n\n这些结果来自 2023 年的模型。作者把它整理成一个评测标准：要说一个模型能稳定使用长上下文，就得证明它的成绩**几乎不受信息位置影响**，也就是最好和最差位置的差距要很小。\n\n对做 RAG 的人来说，这篇论文最实用的提醒是：检索到的文档放在哪里、放几份，同样会影响答案。\n\n至于现在的模型还会不会在中间迷路，就得拿新模型重新量一次了。\n","imageSizes":{"/content/papers/assets/14c392ed0cd20cff36405d2cccc1e1d2e317e1c84de40c4eae37cde79f4a31e3.png":{"width":1278,"height":425},"/content/papers/assets/d5c6cdc14e580fa77e96f56fa8e44ce6e73030510903d8cd53891982597ae037.png":{"width":1278,"height":425},"/content/papers/assets/e49b7762340b5f14544176911003bf9bd877ecc9933dcaed2d30153d1a280c02.png":{"width":644,"height":500}}}