GEO

コンテキストロット

コンテキストロットとは、入力コンテキストが長くなるにつれて、LLMの精度、指示への追従、引用の忠実性が徐々に低下する現象です。コンテキストウィンドウが100万トークンに達しても、実用的に使える精度はそれよりはるか手前で崩壊します。32k、128k、1万kの差は、マーケティングが示唆するよりもはるかに小さいのです。

コンテキストロットとは、入力コンテキストが長くなるにつれて、LLMの精度、指示への追従、引用の忠実性が徐々に低下する現象です。コンテキストウィンドウが100万トークンに達しても、実用的に使える精度はそれよりはるか手前で崩壊します。32k、128k、1万kの差は、マーケティングが示唆するよりもはるかに小さいのです。

なぜ重要なのか

ベンチマークは100万トークンのウィンドウを宣伝しますが、2025年以降の実証研究は異なる姿を描き出しています。Chroma、Anthropic、Databricksの評価は、同じモデルが同一タスクで8kでの95%の精度から64kではおよそ60%へと低下することを一貫して示しています。検索拡張生成(RAG)では、30個のチャンクを一度に詰め込んでも、通常は最初と最後の数個だけが使われ、中間は無視され(ロスト・イン・ザ・ミドル)、モデルは実際にはまったく使っていないコンテンツを「参照した」と主張することさえあります。コンテキストロットはGEOとRAGシステム設計における最大の隠れた落とし穴であり、「コンテキストが大きいほど回答が良くなる」という直感に真っ向から反します。

症状

中間の情報が無視される: コンテキストの中間に置かれた重要な事実が回答に反映されない一方で、冒頭と末尾のコンテンツは生き残ります。

指示のドリフト: 長いユーザーメッセージのあとで、システムプロンプトの指示が無視され始めます。トーン、形式、禁止事項のすべてが漏れ出します。

引用のハルシネーション: モデルが「上記の5番目の段落によると…」と述べるものの、そのような段落は存在しないか、内容が別のドキュメントから来ています。

保持の崩壊: 複数ターンの会話では、初期のコンテキストが実質的に忘れられます。4〜5ターン後には、モデルは以前の合意を見失います。

ツール呼び出しの脱落: 長いコンテキストで定義されたツールは使われる頻度が下がるか、誤った引数で呼び出されます。

なぜ起こるのか

アテンションの希薄化: すべてのトークンが他のすべてのトークンにアテンションを向けなければならないため、シーケンスが長くなるにつれてトークンあたりのシグナルが弱まります。

位置エンコーディングの限界: 学習された長さを超えると、位置情報は意味を失います。RoPEやALiBiは役立ちますが、完全には解決しません。

学習データの分布: 学習中に見るドキュメントのほとんどは短いものです。100万トークンのウィンドウがあっても、モデルが100万トークンのドキュメントで学習したわけではありません。

ニードル・イン・ヘイスタックの限界: 単純な検索タスクは長いコンテキストでも通過しますが、推論、統合、複数事実の統合ははるかに速く劣化します。

GEOへの示唆

アンサーエンジンは検索し、チャンク化し、統合し、取得したチャンクをLLMのコンテキストに積み重ねて回答を生成します。コンテキストロットが意味するのは次のことです。

上位チャンクが支配する: あなたのチャンクがリランキング後に上位1〜3に入らなければ、「コンテキスト内にある」としても実質的に引用されません。

短く自己完結したチャンクが勝つ: 長いチャンクはアテンションを希薄にします。100〜300語が最適な範囲です。

直接的な回答で始まる書き出しが重要: 質問に答える最初の段落は、コンテキストのどこに位置していても生き残ります。

引用の忠実性には検証が必要: 回答はグラウンディングされているように見える引用をハルシネーションすることがあります。事後処理によるチェックが必要です。

緩和策

コンテキストの圧縮: 生のドキュメントをコンテキストに放り込むのではなく、クエリを意識した要約を使って関連部分だけを抽出します。

積極的なリランキング: 30〜50件の候補を取得し、上位5〜10件にリランキングしてから、それらをコンテキストに入れます。

重要情報を意図的に配置する: 最も重要なチャンクを冒頭または末尾に置きます(中間を避ける)。

階層的な統合: map-reduce方式で、チャンクのサブグループを統合し、次にその要約を統合します。

コンテキスト予算を設定する: コンテキストをたとえば8kトークンに意図的に制限し、その範囲内で最適化します。

RAGの自動評価: LLM-as-judgeや埋め込みの類似度によって、回答と情報源チャンクの事実的な整合性を検証します。

よくある誤解

「コンテキストは大きいほど常に良い」: 宣伝されるウィンドウ ≠ 使えるウィンドウ。信頼できる実用上の限界は、表示された容量のおよそ10〜30%です。

「ニードル・イン・ヘイスタックを通過すれば長いコンテキストは機能する」: 単一事実の検索は簡単です。複数事実の推論ははるかに早く崩壊します。

「ファインチューニングで解決する」: ファインチューニングは多少役立ちますが、構造的な限界は残ります。システム設計のほうがより効果的な回避策です。

「新しいモデルは解決済み」: 2026年時点でも、フロンティアモデルでさえ32k〜64kトークンを超えると測定可能な劣化を示します。

よくある間違い

すべての検索結果をコンテキストに詰め込む: 上位30チャンクを生で貼り付けると、ロスト・イン・ザ・ミドルが確実に起こります。

システムプロンプトを末尾に置く: 長いユーザーメッセージのあとに置かれたシステムの指示は無視されます。冒頭に置きましょう。

コンテキストウィンドウのマーケティングを信じる: 100万トークンの宣伝は、100万トークンが使えることを意味しません。

RAGの検証を省略する: 「グラウンディングされているように見える」を基準にすると、ハルシネーションが蓄積します。

均一なチャンクサイズ: すべてのドキュメントを同一の長さに切ると意味が壊れます。セマンティックチャンキングを使いましょう。

Sources: