今回の論文
今回取り上げるのは、Nelson F. Liu、Kevin Lin、John Hewitt、Ashwin Paranjape、Michele Bevilacqua、Fabio Petroni、Percy Liangによる「Lost in the Middle: How Language Models Use Long Contexts」です。2024年にTransactions of the Association for Computational Linguistics（TACL）で発表され、MIT Pressから公開されています。研究分野は、LLMの長文処理能力の評価です。書誌情報と本文はACL Anthologyの論文ページから読めます。
選んだ理由は、モデルを再学習しなくても、入力の組み立て方と評価の仕方を見直すきっかけになるからです。社内文書QAで「検索は成功しているのに答えが間違う」というとき、検索器だけを調整しても原因に届かないかもしれません。本論文は、その切り分けに役立つ技術的な視点を与えてくれます。
どんな技術か
Lost in the Middleは、LLMが長い入力の先頭や末尾にある情報に比べ、中央の情報を使い損ねやすい現象を指します。論文の中心は新しい生成モデルではなく、根拠の位置と入力長を操作する評価方法です。長文対応を、入力できる量だけでなく、必要な情報を利用できるかで測ります。論文の概要
たとえば、同じ質問と同じ資料群を用意し、正解の根拠を含む資料だけを先頭・中央・末尾へ移動します。答えるべき内容が変わらないのに回答が変われば、資料の配置が品質へ影響しているとわかります。これは、RAGのプロンプトを作る際にも使える検証の考え方です。
課題
長文AIアプリでは、「関連資料を取り込めた」と「その資料から正しく答えられた」を別々に確認する必要があります。前者は検索や入力容量の問題、後者は生成器による根拠利用の問題です。二つを一つの正答率だけで見ていると、どちらを直すべきか判断しにくくなります。
たとえば社内規程の質問に、関連度の高い20件の文章を渡したとします。その中に正しい例外条件があっても、別の文章に書かれた一般則だけで答えてしまう可能性があります。検索の件数を増やすことは根拠を拾う機会を増やしますが、同時に読み分ける対象も増やします。
実務では、長い会話履歴、複数ファイルのコードレビュー、ツール実行ログなどでも同じ観点が必要です。ただし、これらの用途への影響は個別に測るべきで、論文の質問応答の結果だけから同じ低下率を予測することはできません。
用語解説
- コンテキストウィンドウ
- モデルが一度の推論で扱える入力と出力のトークン数の上限です。容量に収まることは実行の条件ですが、入力内の根拠を正しく使える保証にはならない、という区別が本記事の出発点です。
- RAG（検索拡張生成）
- 検索した資料をLLMへ渡し、その情報を使って回答を作る構成です。検索結果の順序や件数を変えられるため、根拠の位置が回答に与える影響を検証しやすい用途です。
- ディストラクタ
- 入力に混ぜる、正解の根拠にならない資料です。関連しそうな文章を混ぜることで、根拠を見つける難しさを調整できます。単なる無関係な文字列より実際の検索結果に近い負荷になります。
- Recall@k
- 上位k件の検索結果に必要な根拠が含まれる割合です。検索器を評価する指標であり、LLMがその根拠を使って正答する割合とは異なります。この二つを別々に測ると改善箇所を切り分けられます。
- 因果的attention
- 各トークンが自分より後のトークンを参照しない仕組みです。decoder-only型LLMでは、質問を資料の前にも置くと、資料を処理する段階で質問を参照できるようになります。ただし、その工夫の効果はタスクごとに評価が必要です。
技術の仕組み
根拠を固定して配置を変える
論文は、複数文書QAと、JSON内のキーに対応する値を取り出すタスクを使います。QAでは正解を含む1文書と他の文書を組み合わせ、順序と文書数を操作します。キー・値検索ではランダムな識別子を使い、知識で答える余地を抑えます。いずれも正解を含む生成出力の割合で評価します。論文本文・第2〜3節
この評価の重要な点は、位置を比較するときに資料の内容をそろえることです。先頭条件にだけ簡単な質問を入れたり、中央条件にだけ長い文書を入れたりすると、位置以外の差が混ざります。同じ質問から複数の配置を作り、対になる結果として比較すると解釈しやすくなります。
実装へ落とすときの処理順
著者の公開リポジトリには、資料本文、正解、根拠の識別情報を持つQAデータと、配置を変えたデータを作るスクリプトがあります。20文書の例では、0始まりの位置0・4・9・14・19に根拠を置く条件を生成できます。
自分のアプリで同じ考え方を試すなら、次の流れが扱いやすいです。
- 正解と根拠が確認できる質問を用意します。
- 質問ごとに固定した資料群を選びます。
- 根拠資料の位置だけを変えた入力を作ります。
- モデル、指示文、生成設定をそろえて回答を保存します。
- 位置ごとの正答率と、質問ごとの成功・失敗を比較します。
文書数を増やす比較は、位置を変える比較と分けて行います。入力が上限を超えて切り捨てられたケースも別扱いにします。根拠が入力から消えた失敗と、入力に残っている根拠を利用できなかった失敗を混ぜないためです。
質問の置き場所も比較対象にする
質問を資料の前後に置く条件は、資料を読む時点で何を探すべきか伝える工夫です。ただし、質問の重複はトークン数も変えます。アプリで検証する場合は、末尾だけ、先頭だけ、前後の三条件を区別し、正答率と入力コストを同時に記録すると判断しやすくなります。
実験と結果
QAにはNaturalQuestions-Openの2,655問を使い、MPT-30B-Instruct、LongChat-13B、GPT-3.5-Turbo、Claude-1.3などを評価しました。多くの条件で中央の根拠を使う正答率が低下しました。GPT-3.5-Turboでは20・30文書条件の最悪ケースで、資料なしの56.1%を下回っています。論文本文・第2節
質問を資料の前後に置くと、GPT-3.5-Turbo（16K）の300キー・値条件は、元の最悪位置の45.6%から100%になりました。一方、文書QAの位置依存は大きく改善していません。論文本文・第4.2節
結果を読む際に大切なのは、キー・値の取り出しと自然文からの回答生成を別の能力として扱うことです。前者を通過したモデルでも、関連資料を比較し、質問に合う答えへまとめる後者には失敗し得ます。簡単な情報探索テストだけで、社内文書QAの導入可否を決めるのは避けたいところです。
また、これらは論文で使われた当時のモデルと設定の結果です。現在のモデルの性能値として扱うべきではありません。引き継げるのは、同じ根拠を移動して頑健性を測る評価の考え方です。
何に使える？
以下は論文の評価方法を踏まえた応用案です。各用途で効果が実証されたという意味ではありません。
社内文書RAGの原因調査
正解資料だけなら答えられるのに、検索結果を全部渡すと失敗する質問を集めます。そこから根拠の位置を変えて再評価すれば、検索漏れと、生成器が根拠を使い損ねる問題を分けられます。
たとえば「経費申請の例外条件」を尋ねるテストで、例外規程を先頭・中央・末尾へ移します。配置に敏感なら、検索件数だけでなく、再順位付けや資料の選別も改善候補になります。
長い会話を扱うエージェント
履歴中にある利用者の条件が、ターン数の増加で使われなくなるかを検証できます。「出力はCSV」「対象期間は4月だけ」といった固定条件を異なる位置へ置き、同じ作業を実行させます。
失敗が増える場合は、必要な条件を専用の状態として持ち、毎回の入力へ明示する設計を試せます。これは応用上の仮説であり、会話の時間順や訂正関係を保つ必要があります。単純な並べ替えで会話の意味を壊さないことが重要です。
モデル更新時の回帰評価
モデルを交換する際、平均正答率だけでなく、中央に根拠を置いた条件も固定テストへ加えられます。普段の資料配置に偶然適合しているモデルと、配置が変わっても使えるモデルを比較する材料になります。
開発や事業へのヒント
小規模でも「根拠がある失敗」を集める
最初から大規模なベンチマークを作る必要はありません。実際の失敗質問から、正解の根拠が確認できるものを少数集め、同一資料群の配置違いを試すだけでも診断に使えます。ただし、少数例で得た改善をサービス全体の性能向上として宣伝することはできません。
実務では、根拠だけの入力、通常の検索結果、根拠を中央へ移した入力を並べて保存すると便利です。根拠だけでも失敗するなら質問やモデル能力を、通常入力で失敗するなら資料選別や配置を調べる、という次の行動につながります。
検索件数を品質とコストの両方で選ぶ
検索結果を多く渡すプランを、そのまま高品質プランと見なすのは早計です。5件、10件、20件と条件を変え、Recall@k、回答の正確さ、入力トークン数、遅延を比較する方が、プロダクトの予算配分を判断しやすくなります。
再順位付け、重複除去、根拠部分の抽出は比較候補です。ただし、短くする過程で例外条件や出典を落とせば逆効果です。情報を減らす処理を導入するときにも、元の文書に対する根拠の保持を確認してください。
平均値に加えて、位置ごとの弱さを見る
配置ごとの正答率が80%、55%、78%なら、平均値だけでは中央の弱さが伝わりません。これは説明用の仮例で、論文の数値ではありません。位置別の値と最低値を併記すると、長文機能をどの範囲まで提供するか判断できます。
今後注目したいのは、入力容量の拡大と併せて、根拠利用を安定させる学習・入力設計です。新モデルを採用する際にも、自社の文書形式と実際の長さで測れる評価データを持つことが継続的な改善につながります。
限界
この評価をそのまま本番品質の保証には使えません。論文の主なQA条件は1文書に答えがある構成なので、複数資料を統合する質問や、時系列で更新された規程には別のテストが必要です。日本語の社内文書への効果も、本記事の応用案だけでは判断できません。
評価コストは、質問数に配置条件と長さ条件を掛けた分だけ増えます。小規模な予備検証で候補を絞り、改善案を決めた後に幅広い質問で確認すると計算費を管理しやすくなります。試行ごとの生成の揺れがあるモデルでは、一度の成否だけで差を結論づけないことも必要です。
回答に正解文字列が入るだけでは、誤った説明や余計な断定を検出しきれません。実運用向けには、引用元が正しいか、例外条件を保っているか、資料に答えがない場合に回答を控えられるかも評価すべきです。
また、先頭へ移すべき根拠を事前に知っているのは評価環境ならではです。本番では検索スコアなどから選ぶため、並べ替え自体にも誤りがあります。配置だけを直せば解決するとは限りませんし、この評価だけでattentionのどの内部機構が原因かを特定することもできません。
よくある質問
Q. 長文対応モデルなら、RAGを使わず全文を渡せますか？
A. 入力容量に収まるなら技術的には可能ですが、必要な根拠を使えるかは別途評価します。全文入力と検索結果入力を、同じ質問の正答率、根拠引用、費用、遅延で比較すると、用途に合う構成を選べます。
Q. 重要な文書は先頭と末尾のどちらへ置けばよいですか？
A. 一律に決めず、使用モデルと質問で両方を比較してください。評価では正解資料がわかりますが、本番では推定した関連度に頼ります。再順位付けで上位になった資料をどこへ置くかまで含めて検証する必要があります。
Q. 質問を前後に繰り返せば解決しますか？
A. キー・値の取り出しでは有効な実験結果がありますが、文書QAにも同じ効果が出るとは限りません。本文で紹介した二つのタスクの違いを踏まえ、実際の文章で回答と根拠を確認してください。
Q. 日本語の業務文書でも同じ評価を使えますか？
A. 評価の考え方は使えます。日本語の質問と根拠資料を用意し、同じ内容のまま根拠の位置を変えます。ただし、複数資料が必要な質問では必要な資料をすべて保持し、文書順を変えても意味が変わらない条件を選んでください。
Q. 最初に何を記録すればよいですか？
A. 質問、正解、根拠資料のID、配置、入力長、モデルの識別情報、生成設定、出力を保存すると再比較できます。検索時の順位も残すと、検索器の問題と入力を組み立てる処理の問題を分けやすくなります。
今日の学び
この論文は、長文を入力できるLLMが、その中の情報を安定して利用できるかを扱いました。根拠の位置と入力長を変える評価によって、入力容量だけでは見えない弱点を調べています。開発へのヒントは、資料を増やす前に「根拠を渡せたか」と「根拠を使えたか」を分けて測り、検索と生成のどこを改善すべきか判断することです。