あなたの128Kコンテキストウィンドウが実は128Kではない理由：中間喪失問題と実際に使える容量を測定する方法

広告上の容量と実際に使用可能な容量のギャップは、多くのチームが認識するより大きい

言語モデルベンダーは128,000トークンを謳っていますが、実際に得られるもの—モデルが確実に使用する情報—はしばしばその数値の一部に過ぎません。この差異は単なる丸め誤差ではありません。動作するシステムと、自信を持って誤った回答を生成しながら、すべての事実を持っていると主張するシステムの違いなのです。

これは新しい問題ではありませんが、組織がモデル予算、評価、レトリーバル拡張生成（RAG）システム構築時に依然として考慮に入れるのに苦労している問題です。アーキテクチャがあなたに対して機能しないのは、モデルが壊れているからではなく、注意メカニズムが負荷下でどのように動作するかによるものです。

中間喪失現象：研究が実際に示していること

LLMは、コンテキストウィンドウの中間に配置された情報よりも、開始部分と終了部分の情報をより確実に使用する傾向を示します。これは微妙な劣化ではありません。それは測定可能で、再現可能で、あなたがおそらく今評価している最先端モデルにも存在します。

この効果は人間の記憶研究のパターンを反映しています：人々は、研究リストの開始部分（初頭効果）と終了部分（最近性効果）のアイテムをより高い精度で想起する傾向があり、特性的なU字形曲線を生み出します。この並列は比喩的ではありません。LLMの内在的な注意バイアスと建築上のバイアスの役割が、この動作を駆動するメカニズムであることを示す証拠があります。

これは実際には何を意味するのでしょうか？大きなコンテキストウィンドウは完全な想起を保証しません—それはより多くのコンテキスト用のスペースを提供しますが、そのコンテキストのすべての部分に等しい注意を与えません。128Kトークンを持つモデルでも、トークン64,000の位置に配置された重要な事実を見逃す可能性がある一方で、トークン500またはトークン127,500に現れた同じ事実は正しく処理します。

パフォーマンス低下が実際に現れる場所

コンテキスト劣化は、入力長が増加するにつれてLLMが経験する測定可能なパフォーマンス低下であり、Chromaが18の最先端モデルをテストしたところ、すべてが悪化することが判明しました。しかし、この劣化はすべてのタスクやすべてのモデルで均一ではありません。

数学、質問応答、コーディングタスクに関する5つのオープンソース・クローズドソースLLMにわたる最近の体系的な実験では、モデルがすべての関連情報を完全に取得できる場合でも、入力長が増加するにつれて、モデルの主張する長さ内にとどまりながら、パフォーマンスが実質的に（13.9%～85%）低下することが明らかになりました。

これは重大な区別です：モデルはトークンを使い果たしていません。入力を切り詰めていません。送信したものすべてを処理しています。それでも、コンテキストが長くなるにつれて推論品質が測定可能に低下します。チームは日常的に、彼らのコンテキストウィンドウが「十分に大きい」と仮定しています。彼らは128Kまたは1Mトークンのモデルを選択し、それを読み込み、出力品質がなぜ低下するのか疑問に思います。コンテキスト劣化はその理由を説明します：容量は間違ったメトリクスなのです。

メカニズム：これはなぜ起こるのか

モデルは、タスクを理解し、回答を形成するために、長いコンテキストウィンドウの開始部分と終了部分により多く依存する傾向があります。建築上の犯人は、RoPE減衰のような位置バイアス—情報がシーケンスのどこに位置するかをモデルに伝える数学的エンコーディングです。シーケンス長が増加するにつれて、モデルの注意パターンは境界部分に集中するようになります。

コンテキストウィンドウの中央の情報は、無関係なテキスト、繰り返されるフレーズ、および気を散らすもとの競合に直面します。ノイズが最小限の慎重に構築されたシナリオでも、長いシーケンスを処理する単純な重みがモデルの焦点を中間部分から引き離します。

二次的なレイヤーがあります：コンテキスト劣化は、入力コンテキストが長くなるにつれて段階的に発生するパフォーマンス低下です—より多くのトークンが入力され、より悪い出力が出ます。モデルのコンテキストウィンドウが満杯に近くなくても。これはハード制限に達することについてではありません。トークンが関連しているかどうかに関わらず、トークンを追加するにつれてシグナル・ノイズ比が悪化することです。

実際に使用可能なコンテキストを測定する方法：フレームワーク

モデルの広告上のコンテキストウィンドウを保証として扱うのはやめてください。測定を開始してください。実用的な評価は次のようになります：

1. 容量だけでなく、異なる位置でテストする

750語から96,000語までのさまざまな長さのドキュメント内に一意の事実を埋め込み、その事実を異なる位置に配置して、配置がどのように取得精度に影響したかを測定します。これは現実の問題を複製します：モデルが理論上128Kトークンを処理できるかどうかについて気にかけません。フルコンテキストが100Kの場合、位置40Kから確実に情報を抽出できるかどうかについて気にかけます。

2. 推論とは別に取得を測定する

入力長を拡張するだけで、モデルがまだ関連する証拠を取得できる場合でも、LLMの推論機能が実質的に低下します—最小限の気を散らされない空白を挿入しても、モデルがすべての条件を正しく抽出することを防ぎませんが、それでも誤った回答に至る原因になります。評価では、「モデルが正しい情報を見つけた」と「モデルが推論で正しくそれを使用した」を区別する必要があります。これらは同じではありません。

3. クリーンなシナリオではなく、現実的なノイズでテストする

本番環境での修正には、2段階取得（広いリコール+クロスエンコーダ再ランキング）、ハイブリッド検索（セマンティック+BM25）、および戦略的順序付け（上位証拠を開始と終了に配置）が含まれます。しかし、これらの修正を実装する前に、典型的な気を散らすもと—冗長なチャンク、古い情報、競合する主張—を使用してモデルがどのようにパフォーマンスするかを測定してください。

4. 順序付けし戦略をベンチマークする

最も効果的なアプローチは、最も高いランクの文書をコンテキストウィンドウの開始部分と終了部分に配置し、低いランクの文書を中央に配置します。これはモデルの固有の注意バイアスを活用しており、それに対抗するのではなく。これは複雑ではありません。それは取得結果の単純な並び直しです。しかしそれは機能します。

アーキテクチャ決定に対する実用的な含意

中間喪失問題は、チームが多すぎるフィルタリングされていないコンテキストをモデルに送信し、LLMがそれを整理することを期待する場合に悪化します。より良い修正は、プロンプトアセンブリの前に開始されます：信頼できる、現在の、関連性のある、特定のコンテキストがコンテキストウィンドウに入る程度かを決定し、重複するチャンク、古い定義、弱い証拠、および緩く関連するポリシーを削除します。

これは決定を再構成します。32Kモデルと128Kモデルのいずれかを選択するのではなく、コンテキスト管理オーバーヘッドの異なるトレードオフを選択しています。規律のあるコンテキストエンジニアリングと戦略的な順序付けを持つ32Kモデルは、ノイズの多いコンテキストで満たされた128Kモデルをしのぎます。

運用上の費用差は重大です。コンテキストを過負荷にすると、コストが増加します。LLMはステートレスです。つまり、過去の会話の記憶を持たないということです—送信するすべてのメッセージについて、会話履歴全体をモデルに送り返す必要があります。コンテキストウィンドウに押し込むすべての追加トークン—関連があるかどうかに関わらず—は、支払っているトークンであり、発生させている遅延です。

あなたのチームにとってこれが意味すること

容量は間違ったメトリクスです。シグナル・ノイズ比が出力品質を決定するものです。モデルを評価するか、RAGパイプラインを構築する場合、広告上のコンテキストウィンドウを目標ではなく上限として扱ってください。有効なコンテキスト—精度がユースケースに対して許容可能なままのトークンの部分—を測定し、その数を中心にシステムを設計してください。

位置感度をテストしてください。取得結果を戦略的にランク付けしてください。厳密にフィルタリングしてください。そして最も重要なこと：より大きなコンテキストウィンドウを持つモデルが問題を解決すると仮定しないでください。それはしばしばそれをより大きくするだけです。

メトリクス	測定対象	重要な理由
広告上のコンテキストウィンドウ	最大トークン容量（例：128K）	上限のみ。使用可能なパフォーマンスについては何も教えません
有効なコンテキスト長	精度がしきい値を上回ったままのトークン（例：85%）	ユースケースの実際の動作ウィンドウ
位置感度	情報配置に基づく精度差異	U字形劣化を明らかにします。取得順序付けし戦略を知らせます
コンテキスト肥大化での取得精度	モデルがノイズの中で正しい情報を抽出するかどうか	取得を推論から分離します。問題がアーキテクチャまたは前処理かを示します
シグナル・ノイズ比	コンテキスト内の関連トークンと無関係なトークンの比率	生のコンテキストサイズよりも出力品質をより予測可能にします