{"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-hant","path":"/content/papers/zh-hant/model-evaluation/lost-in-the-middle.d75958a2f86a.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-hant","path":"/content/papers/zh-hant/model-evaluation/nolima.af8e9ff8d896.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}}}