{"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":"ja","path":"/content/papers/ja/model-evaluation/lost-in-the-middle.d37a07c26237.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":"ja","path":"/content/papers/ja/model-evaluation/nolima.1519dbfc193d.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":"2ホップは1ホップより難しく倒置形は通常形より難しい","text":"2ホップは1ホップより難しく、倒置形は通常形より難しい","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同じ文書をプロンプトの1番目に置いたときと10番目に置いたとき、モデルが使う可能性は同じでしょうか。\n\nStanford、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$件の文書を渡し、**答えを含む文書は1件だけ**、残り$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検索クエリに、Wikipediaで人手により付けた答えを対応させたものです。著者らは、答えのアノテーションが一つの段落全体となっている2,655問を選びました。\n\n妨害文書も適当に選びません。Contrieverで、質問に**強く関連するが答えを含まない**Wikipedia段落を探し、関連度順に並べます。どれも答えらしく見えるため、モデルは読んで区別する必要があります。\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**：答えを含む1件だけを渡す。\n> \n> 20件を渡した成績がclosed-bookより下なら、その文書群は役立つどころかモデルを混乱させています。\n\n\n### キーと値の検索\n\n二つ目は意味を取り除き、最も基本的な「探す」だけを残します。\n\n$k$組のキーと値を持つJSONオブジェクトを渡します。キーも値もランダムな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\nGPT-3.5-Turboのclosed-book精度は56.1%、oracleは88.3%です。\n\nつまり10番目の53.8%は、文書を一切渡さない場合より低くなっています。\n\n20件のうち1件には確実に答えがあるのに、何も渡さない方がうまく答えられるのです。\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ほかの説明を除く確認もしています。妨害文書をランダムなWikipedia段落へ変えると全体の成績は上がりますが、U字は残ります。「検索結果はランダム順」と明記し、妨害文書を並べ替えても同じ傾向です。500問の部分集合でGPT-4は全モデルを上回りましたが、曲線はやはりU字でした。\n\n### 文書をもっと増やすとどうなるか\n\n最後に、実際のRAG設定へ戻ります。ContrieverでWikipediaから$k$件を取り、すべてプロンプトへ入れます。今度は答えを含む文書が1件とは限らず、0件の場合も複数の場合もあります。\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$件に答えを含む文書が少なくとも1件ある質問の割合です。5件から50件へ増やすと、90近くまで上がります。\n\n一方、モデルの精度は20件前後でほぼ横ばいです。20件から50件へ増やしても、GPT-3.5-Turboは約1.5%、Claude-1.3は約1%の改善です。入力長は2倍以上となり、遅延と料金も増えます。\n\n検索器は見つけたのに、モデルが使えません。\n\n著者らは、関連文書を冒頭近くへ**再順位付け**することと、適切な場合に**検索件数を減らす**ことを提案します。\n\n### その後の話\n\n発表から数か月後、長文コンテキストの評価が活発になりました。\n\n2023年11月、Greg Kamradtの「干し草の山から針を探す」（needle-in-a-haystack）テストが人気になりました。大量のPaul Grahamの文章に、「サンフランシスコで一番良い過ごし方は、晴れた日にサンドイッチを食べてDolores Parkに座ること」といった場違いな一文を挿入し、サンフランシスコで何をするのが一番楽しいか尋ねます。\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. **関連情報が中央にあると大きく下がる**。20件のGPT-3.5-Turboは、冒頭75.8%から中央53.8%へ落ち、文書なしの56.1%も下回ります。\n2. **長い版も、両方に収まる内容の使い方は似ている**。4K版と16K版の曲線はほぼ重なります。\n3. **単純な文字列照合も影響を受ける**。300組のキー検索では、GPT-3.5-Turbo (16K)の中央の精度が45.6%へ落ちます。\n4. **文書を増やす効果はすぐ飽和する**。20件から50件への増加で、精度の伸びは1～1.5%だけです。\n\n対象は2023年のモデルです。著者らはこれを評価基準へ整理しました。長いコンテキストを安定して使えると主張するなら、成績が**情報の位置にほとんど左右されず**、最良位置と最悪位置の差が小さいことを示す必要があります。\n\nRAGを作る側への実用的な教訓は、検索した文書をどこへ置くか、何件入れるかも答えに影響することです。\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}}}