Lost in the Middle現象とは｜RAG精度が落ちる仕組みと設計での対策

RAGの回答精度が伸び悩む原因の多くは、検索した文書をLLMにそのまま渡す設計にあります。LLMは入力の先頭と末尾を重視し中間を読み飛ばす「Lost in the Middle」という性質を持ち、上位で検索した根拠が中間に埋もれると回答へ反映されません。本記事では、この現象の仕組みから、チャンク設計・ハイブリッド検索・リランク・件数最適化・コンテキスト圧縮・プロンプトといったRAGの対策、そして精度評価の実務手順までを設計の観点で整理します。長文コンテキストモデルでも完全には解消しない前提で、どの対策をどの順で入れるべきかが分かります。

まとめ：中間軽視を前提に設計へ織り込むRAG精度改善の要点

Lost in the Middleは「起きる前提」で設計に織り込むのが、RAGの回答精度を底上げする近道です。検索で拾った文書を全件そのまま渡すのではなく、リランクで関連度順に並べ替え、最も重要な文書を入力の先頭と末尾へ寄せ、投入件数を3〜5件程度へ絞り込む。これだけで、中間に埋もれて無視されていた根拠が回答へ反映されやすくなります。

費用対効果の高い順序は、件数の最適化と並び替え、次に2段階リトリーバルとクロスエンコーダによるリランク、続いてハイブリッド検索とチャンク設計の見直し、必要に応じたコンテキスト圧縮です。仕上げに、正解文書の位置を変えて精度の動きを測る検証とLLM-as-a-judgeによる定量評価を回し、改善を継続します。各手法の根拠と勘所は以降の章で順に解説します。

Lost in the Middleとは何か——中間情報が埋もれる仕組み

Lost in the Middleは、LLMが長い入力のどの位置に重要情報があるかで性能が変わる現象です。RAGは複数の検索文書を一つの入力に詰め込むため、この性質の影響を最も受けやすい構成にあたります。まずは正体とアーキテクチャ上の要因を押さえます。

U字型注意バイアスと位置1から10で約20ポイント落ちた実測

LLMの注意は入力全体へ均等に向かず、先頭(primacy)と末尾(recency)に強く偏り、中間が薄くなるU字型のカーブを描きます。原因は記憶ではなくモデル構造にあり、Liu et al.（Stanford・UC Berkeley・Samaya AI、2023年発表／TACL 2024）が「Lost in the Middle」として体系的に示しました。実験では20件の文書のうち正解を含む1件だけ位置を動かし、先頭(位置1)や末尾(位置20)では高精度、中間付近(位置10)では正答率が約20ポイント低下したと報告されています。検索内容も文書数も同じで、位置だけが変わった点が重要です。RAGの回答品質が日によってばらつく、特定の質問だけ精度が落ちるといった症状は、この位置依存が原因のケースが少なくありません。

causal maskとRoPEが生む構造的要因

この偏りは設定ミスではなくTransformerの構造に由来します。一つはcausal mask(因果マスク)で、各トークンは自分より前しか参照できず、先頭付近のトークンが後続すべてから参照されて相対的に重みを集めます。もう一つは多くのモデルが採用する位置エンコーディングRoPEで、距離が離れるほど注意が減衰しやすくなります。位置バイアスの発生機序を理論的に扱った研究（arXiv:2502.01951, ICML 2025）は、causal maskが早い位置へ注意を偏らせること、causal maskとRoPEの減衰が層をまたいで競合することを示しました。原因が構造側にあるため、プロンプトの書き換えだけでは根本解決しないと理解しておくことが設計の出発点になります。

コンテキスト窓を広げても消えないcontext rot

「数百万トークンに対応したから全部入れれば良い」という発想は危険です。窓を広げても中間軽視は消えず、むしろ窓が大きいほど劣化が目立つ場合があります。入れた情報が増えるほど性能がじわじわ落ちる、いわゆるcontext rot(コンテキストの劣化)です。窓のサイズは「入れられる量」を示すだけで「使いこなせる量」を保証しません。長文モデルを採用しても、何を入れ何を捨てるかという検索・選別の設計は引き続き必須になります。典型的な失敗は、検索器が返した上位10〜20件をそのまま連結する素朴な構成で、関連度の低い文書(hard negative)が混ざり、肝心の根拠が中間に埋もれ、回答が一般論やハルシネーションへ流れます。

検索段階の対策——チャンク設計とハイブリッド検索

Lost in the Middleへの対策は生成の直前だけでなく、入力に何を載せるかを決める検索段階から始まります。良いチャンクと適切な検索手法は、そもそも中間に埋もれる無駄な文書を減らす土台です。

回答単位を意識したチャンク分割の粒度

チャンクは「一つの問いに答えるのに必要な情報が、過不足なく1片に収まる」粒度が理想です。細かすぎると文脈が切れて意味検索が外し、粗すぎると1片に複数論点が混ざってノイズと冗長さを抱えたまま中間に埋もれます。目安は、見出しや段落など文書本来の構造で区切って句点の途中で割らないこと、前後を少し重ねるオーバーラップを設けることです。分割単位の基本的な考え方はチャンク分割の手法と最適なサイズの解説もあわせて参照すると理解が深まります。

ベクトル検索とBM25を併用するハイブリッド構成

検索手法は単独ではなく、意味で探すベクトル検索と語句で探すキーワード検索(BM25)を組み合わせるハイブリッド構成が安定します。両者は得意領域が異なり、補い合うことで再現率が上がるためです。ベクトル検索は「申請」と「申し込み」のような言い換えに強い一方、「ISO 27001」や型番「RX-200」のような完全一致を要する語に弱く、社内文書ではこうした固有名詞・略語・エラーコードが回答の鍵になることが多いため、そこをBM25で確実に拾います。実装ではスコアを正規化して統合するか、Reciprocal Rank Fusion(RRF)で順位を融合する方法が一般的です。

ベクトル検索の基盤となる仕組みや選定の観点はベクトルデータベースの仕組みと選び方の解説で具体的に確認できます。まず片方で運用を始め、取りこぼしの傾向を見てから併用へ広げる進め方が現実的です。

メタデータ付与と前処理で検索ノイズを除去

チャンクに部署・文書種別・更新日などのメタデータを付け、検索時にフィルタすると無関係な文書を入口で除外できます。「最新の就業規則」という質問に対し更新日でフィルタすれば、旧版が中間に紛れ込む事故を防げます。前処理としてヘッダー・フッター・定型の免責文など回答に寄与しない反復テキストを除去しておくことも有効です。第1段階の検索で取得する件数(top-k)は、増やすと再現率が上がる反面ノイズも増えて後段の中間軽視を招くため、第1段階は再現率重視でやや多め(数十件)に拾い、後段のリランクと件数最適化で精度に変換する二段構えが定石になります。検索精度はモデルだけでなく、こうしたデータ整備に大きく左右されます。

並び替え・リランク・件数最適化による中間軽視の抑制

検索で良い文書を集めても、並べ方を誤れば中間に埋もれます。ここではU字型バイアスを逆手に取る並び替え、関連度を測り直すリランク、投入件数の最適化を扱います。学習を伴わず導入でき、費用対効果の高い対策です。

高スコア文書を先頭と末尾へ寄せる並び替え

U字型バイアスは弱点であると同時に利用できる性質でもあります。関連度スコアの高い文書を入力の先頭と末尾に配置し、低いものを中間へ送る並び替え(retrieval reordering)は、注意が集まる場所へ重要情報を置く発想です。Long-Context LLMsとRAGを扱った研究（arXiv:2410.05983, ICLR 2025）でも、関連度順に並べ替えた構成が標準的な順序を一貫して上回ると報告されています。スコア降順で「先頭→末尾→中間」へ交互に詰めるだけで実装でき、追加コストもほぼ発生しません。効果は文書数に依存し、取得件数が少ないと改善はわずか、件数が多いほど中間軽視とhard negativeの影響がともに強まるため一貫して効果が大きくなります。投入件数が数件にとどまる小規模構成では並び替え単体の優先度は低く、まず件数最適化で足りることが多いと判断できます。

広く拾い狭く絞る2段階リトリーバルとクロスエンコーダ

並び替えの前提として、関連度を正しく測る2段階リトリーバルを組みます。第1段階は軽量なベクトル検索やBM25で再現率重視に数十件を広く拾い、第2段階でクロスエンコーダのリランカーに通してクエリと各文書を突き合わせ、関連度を再採点します。埋め込み(バイエンコーダ)はクエリと文書を別々にベクトル化するため相互作用を捉えにくく再ランキングでは精度が頭打ちになりがちですが、クロスエンコーダは両者を一つの入力として同時に評価するため判定が精緻になります。第1段階の高速・大量検索はバイエンコーダ、第2段階の少数精鋭の採点はクロスエンコーダ、という使い分けが定石です。リランクは文書ごとに推論を走らせるためレイテンシが増えますが、第1段階で数十件に絞ってから渡す設計にしておけば対象が限定され、増加を抑えられます。即時性が重要な用途では軽量リランカーや件数の上限設定で調整します。

投入件数を3〜5件へ絞る件数最適化と逓減

最終的にプロンプトへ載せる文書は3〜5件程度に絞るのが実務上の出発点です。少数に絞ると各文書が注意を受けやすくなり、中間に埋もれる確率が下がります。研究では取得文書を増やすと性能が初めは伸び、その後はむしろ低下する逓減カーブが報告されており、単に数を増やしてもノイズと中間軽視で逆効果になり得ます。注意したいのは、より強力な検索器を使えば精度が上がるとは限らない点です。強い検索器ほど「関連はするが答えではない」紛らわしい文書(hard negative)を上位に集めやすく、これが生成を惑わせます。検索器の強化は、リランクと件数最適化を必ずセットにしてこそ効きます。件数は最初から多数を入れず、少数で精度を測り、不足があれば1件ずつ増やして変化を見る進め方が安全です。

LongLLMLinguaによるトークン圧縮と情報密度の向上

件数を絞っても各文書が長い場合は、コンテキスト圧縮が選択肢になります。代表例のLongLLMLingua（arXiv:2310.06839）は質問に関連の薄いトークンを削るプロンプト圧縮手法で、NaturalQuestionsで精度を最大21.4%向上させつつトークン量を約4分の1に抑えたと報告されています。圧縮は中間軽視そのものを直接消すわけではありませんが、入力を短く濃くして重要情報が薄まるのを防ぎ、コストとレイテンシも下げます。前段として、そもそも冗長・重複・矛盾する文書を除くコンテキストキュレーションも効きます。各文書が回答に固有の根拠を加えているかを基準に、重複は代表1件へ統合し、古い・矛盾する情報はメタデータや更新日で除外します。入れる前に「捨てる」工程を持つことが、後段の精度を底上げします。

生成側の緩和——プロンプトと注意バイアス補正

検索と並び替えを整えたうえで、生成側からも中間軽視を和らげられます。ただしプロンプトの工夫は補助であって主役ではありません。原因がcausal maskやRoPEという構造側にある以上、プロンプトだけに頼ると効果は頭打ちです。設計の主軸は検索・リランク・件数の工程に置き、以下は最後の数ポイントを取りに行く仕上げと位置づけます。

関連する一文を明示するプロンプトと指示の配置

最も手軽な対策は、プロンプトで注意の向け先を示すことです。Anthropicは2023年、Claude 2.1の長文コンテキストで「Here is the most relevant sentence in the context:(文脈中で最も関連する一文はこれです)」という一文を添えるだけで、正答率が27%から98%へ改善した事例を示しました。検索済みの根拠を回答冒頭で要約させる、引用を必須にするといった指示も同系統です。指示や前提の置き場所も効き、末尾近くに置くとrecencyで従われやすく、長い文書群の前に置いた指示は中間へ沈みます。重要な指示は文書群の直前と直後の両方に置く、質問を末尾に再掲する、といった配置が有効です。前章の文書並び替えと同じく、注意が集まる位置へ重要要素を置くという一貫した原則で整理できます。コストゼロで試せるため、最初に検証する価値があります。

Found-in-the-MiddleやIN2学習など構造側からの補正

プロンプトで届かない構造側の偏りには、注意バイアスを補正するアプローチがあります。Found-in-the-Middle（Hsieh et al., 2024, arXiv:2406.16008, ACL Findings）は、位置に起因する注意の偏りを較正して関連度に応じて中間の文書へも注意を向けさせる推論時の手法で、RAGの性能を既存手法比で最大15ポイント改善したと報告されています。追加学習なしで導入できる点が特徴です。より踏み込むと、位置エンコーディングを調整するMs-PoEや、中間情報の活用を学習させるIN2訓練といった学習・推論側の緩和策もあります。これらは中間軽視そのものを減らす方向で効果は大きい一方、モデルへの介入や追加学習を伴うため、自社でモデルを保有・微調整できる場合の選択肢です。APIモデルを利用する一般的なRAGでは、まず検索・並び替え・件数の設計で対処するのが現実的になります。

効果を測る——RAG精度評価とLost in the Middleの検証

対策を入れたら、効果を数値で確かめる仕組みが要ります。RAGの評価は単一の正答率では不十分で、工程ごとに分けて測ることがボトルネックの特定につながります。

検索・リランク・生成・E2Eの4層で測る評価設計

RAGの評価は、どの工程で精度が落ちているかを切り分けられるよう4つの層に分けて設計します。検索層が低ければチャンクや検索手法、生成層だけ低ければ並び替えやプロンプト、と原因を絞り込めます。とくにRecall@k(上位k件に正解文書が含まれる割合)が低ければ根拠を拾えておらずチャンク設計や検索手法の問題、再現率は十分なのに正答率が低いなら拾えた根拠が中間に埋もれている可能性が高く、並び替えやリランクの出番だと判断できます。

正解文書の位置を動かす再現テスト

Lost in the Middleの影響を自社環境で測るには、Liu et al.の実験を再現するのが確実です。正解を含む文書1件を用意し、ダミー文書群の中で位置を先頭・中間・末尾と変えながら、同じ質問への正答率を記録します。中間に置いたときだけ正答率が顕著に下がるなら、自社のRAGも中間軽視の影響下にあると判断できます。この簡易テストは並び替えやリランクを導入する前後の比較にも使え、対策の効果を可視化する実務的な手段になります。

LLM-as-a-judgeとA/Bによる継続モニタリング

回答の正誤や品質は人手評価が理想ですが、件数が多いと現実的でないため、LLMに採点させるLLM-as-a-judgeが有効です。正解例・根拠・評価基準を与え、忠実性や網羅性を点数化させることで改善前後の差を継続的に測れます。バイアスを避けるため評価基準を明文化し、複数回採点の平均を取るなどの工夫が要ります。評価は一度きりでなく、同一の評価用質問セット(ゴールデンセット)を固定し、並び替えの有無やリランク導入の前後で各層の指標を並べるA/B比較で施策ごとの寄与を明確にします。文書やモデルの更新で精度が劣化することもあるため、定期的な再評価を運用へ組み込むことが品質を長期で保つ前提です。具体的な進め方はLLM-as-a-Judgeによる評価設計の解説で確認すると、自社の評価フローへ落とし込みやすくなります。

長文コンテキストモデル時代にRAG設計を選ぶ判断基準

コンテキスト窓が巨大化した今、「RAGは不要では」という問いも生まれます。ここでは全件投入と検索併用のどちらを選ぶか、長文モデル時代ならではの判断軸を整理します。

全件投入か検索併用かを分ける文書量とコストの境界

判断の第一軸は対象文書の総量とコストです。参照範囲が数ページに収まり毎回ほぼ同じなら、全文をそのまま渡す構成が単純で有利です。一方、社内文書が数千件規模で質問ごとに参照箇所が変わるなら、検索で絞るRAGが不可欠になります。全件投入は窓に入っても毎回大量のトークンを処理するためコストとレイテンシが膨らみます。文書量・更新頻度・1問あたり許容コストの3点で寄せ先を決めると判断がぶれません。データ量が増えればhard negativeも増え検索件数の最適点も動くため、PoCで動いた設定を本番へそのまま流用せず、ゴールデンセットでの再評価と検索件数・リランクの再調整を必ず行います。

長文窓でも中間軽視が残る前提での設計の優先順位

前提として、窓を広げても中間軽視は残ります。したがって長文モデルを採用しても設計の優先順位は変わりません。第一に投入する情報を必要十分に絞ること、第二に重要情報を先頭と末尾へ配置すること、第三に評価で効果を確かめること、という順序です。「長文モデルだから全部入れる」という設計はcontext rotで精度を落とすリスクが高く、避けるべき選択です。最後に、自社データの性質に合わせて手法を使い分けます。製品型番・法令番号・エラーコードなど完全一致が重要な文書群ではBM25の比重を高め、概念や手順を問う相談的な質問が多いならベクトル検索を厚くし、混在する一般的な業務文書ではハイブリッド構成を基本に置きます。汎用の正解はなく、自社の質問ログと文書特性を見て使い分けることが、Lost in the Middle対策を含むRAG設計全体の精度を決めます。

よくある質問

Lost in the MiddleとRAG設計について、検討時によく挙がる疑問を整理しました。導入判断や優先順位づけの参考にしてください。

Lost in the MiddleはGPTやClaudeなど最新モデルでも起きますか？

はい、程度の差はあれ最新モデルでも観測されます。原因がcausal maskやRoPEといったTransformerの構造に由来するため、モデルが新しくなっても完全には消えません。新しいモデルや長文対応モデルで軽減される傾向はあるものの、入力が長く文書数が多いほど影響は残ります。「最新モデルだから対策不要」とは考えず、検証で自社環境の影響度を確かめることをおすすめします。

RAGの精度が低いとき、最初に見直すべき設計はどこですか？

まず投入している検索文書の件数と並び順を確認してください。上位10〜20件を全件そのまま渡しているなら、3〜5件への絞り込みと関連度順の並び替えだけで改善することが多いです。それでも不足する場合は検索層のRecall@kを測り、根拠を拾えていない(検索の問題)のか、拾えているが活かせていない(並び替え・生成の問題)のかを切り分けます。原因の所在を特定してから対策を選ぶと、遠回りを避けられます。

リランクとハイブリッド検索はどちらを先に導入すべきですか？

一般には、まず件数最適化と並び替えという低コストの対策から入り、次に2段階リトリーバルのリランクを導入する順序が費用対効果に優れます。ハイブリッド検索は、固有名詞や型番の取りこぼしが課題として見えてから追加すると無駄がありません。ただし、扱う文書に完全一致が必須の語が多い場合はハイブリッド検索を先に入れる判断もあり得ます。自社の取りこぼし傾向を評価で把握したうえで順序を決めてください。

コンテキスト窓が大きいモデルなら全文を入れた方が精度は上がりますか？

必ずしも上がりません。窓が大きくても中間軽視は残り、入れる情報が増えるほど精度がじわじわ落ちるcontext rotが起こり得ます。さらに毎回大量のトークンを処理するためコストとレイテンシも増えます。参照範囲が小さく固定的なら全文投入も選択肢ですが、文書量が多い業務用途では、検索で必要箇所を絞るRAGのほうが精度・コストの両面で有利になるのが一般的です。

Lost in the Middleの影響は、どうやって数値で確認できますか？

正解を含む文書1件を、ダミー文書群の先頭・中間・末尾と位置だけ変えて配置し、同じ質問への正答率を比較する簡易テストが有効です。中間に置いたときだけ正答率が明確に下がれば、自社のRAGも影響を受けていると判断できます。あわせて検索層のRecall@kと生成層の正答率を分けて測れば、根拠を拾えていないのか、拾えたが活かせていないのかも切り分けられます。対策の前後で同じテストを回せば効果も可視化できます。

関連記事

• チャンク分割とは｜RAGにおける文書分割の基礎：本記事のチャンク設計をより基礎から理解したい方向けの解説です。
• ベクトルデータベースの仕組みと選び方：検索段階の基盤となるベクトル検索・ベクトルDBを詳しく知りたい方に役立ちます。
• LLM-as-a-Judgeによる評価設計：RAGの精度評価をLLMで定量化する手順を具体的に補足します。