ハクソク

世界を動かす技術を、日本語で。

コンテキストロット：入力トークンの増加がLLMのパフォーマンスに与える影響

315日前原文(research.trychroma.com)

概要

  • 最新LLMは数百万トークンの長大なコンテキストウィンドウを実現
  • 代表的ベンチマークNIAHは単純な検索タスクであり、実用的な長文理解力を十分に測定できない
  • 入力長のみを変化させる実験で、モデル性能の非一様な劣化を確認
  • Needle-Question類似度やディストラクター、ハイスタック構造など複数要因が性能に影響
  • 実用上は「情報の有無」だけでなく「情報の提示方法」も重要

LLMの長大コンテキスト処理能力の現状と課題

  • 最新のLLM（例：Gemini 1.5 Pro、GPT-4.1、Llama 4）は 100万～1000万トークン級の入力長 に対応
  • 長大なコンテキスト対応モデルはNIAH（Needle in a Haystack）で 一見高性能 を示すが、これは単純な「文検索」タスク
  • NIAHは 語彙一致 による検索が中心であり、実際の応用で求められる 柔軟な意味理解や推論力 を十分に測れない

NIAHベンチマークの限界

  • NIAHはスケーラブルなテストだが、 実用的な長文タスクの要件を過小評価
  • NoLiMaやAbsenceBenchなど 語彙一致以外を求めるタスク では、入力長が増えると性能が大きく低下
  • MRCRやGraphwalks、Latent Listなど 複合的な長文タスク でも、入力長増加による性能劣化が顕著
  • タスク複雑性と入力長の影響を分離することが難しく、 純粋な「入力長」の影響評価が不足

実験設計と主な貢献

  • タスクの複雑性を一定に保ちつつ、入力長のみを変化 させることで、純粋な入力長の影響を評価
  • 18種類のLLM（クローズド・オープン両方）を対象に、 各種要因ごとの性能劣化パターン を網羅的に分析
  • 再現用コードベース を公開（https://github.com/chroma-core/context-rot）

分析対象の要因

  • Needle-Question類似度： 埋め込みコサイン類似度で定量化し、類似度低下で性能も低下
  • ディストラクター： 類似トピックの誤誘導文を混入し、数や内容で性能変動を観察
  • Needle-Haystack類似度： 異なるテーマ（Paul Grahamエッセイ、arXiv論文）間で比較
  • Haystack構造： 文章の論理的流れを維持した場合と、完全シャッフルした場合で性能比較

実験結果の要約

  • 入力長が増加するほど、 全モデルで一貫して性能が劣化
  • Needle-Question類似度が低いほど、劣化速度が加速
  • ディストラクターの影響は非一様 で、特定の誘導文が大きく性能を下げる場合あり
  • Needle-Haystack類似度の影響は一様でなく、さらなる調査が必要
  • Haystackの構造（論理的な流れ）の有無が、モデルの長文処理に明確な影響

詳細な評価条件

  • 針（Needle）タイプ・Haystackトピック・構造ごとに 8段階の入力長 と 11位置 で評価
  • 各モデルの 最大コンテキスト長 までテスト、温度=0で一貫性を確保
  • Qwenモデルでは YaRN法 で最大13万トークンまで拡張
  • 出力評価は GPT-4.1ジャッジ を用いて客観的に実施
  • タスク拒否や出力不能なケースはごく少数 で、結果から除外

実践的示唆と今後の課題

  • LLMの長文処理性能は 入力長・情報配置・文脈構造 に大きく左右
  • 現状の「情報が含まれていればよい」という前提は 誤り であり、 「どのように提示するか」 が重要
  • より現実的な長文ベンチマークや、 コンテキストエンジニアリング の重要性が増大

参考・関連リンク

  • Chroma Context Rot レポート全文・コードベース https://github.com/chroma-core/context-rot

主要モデル（GPT-4.1, Claude 4, Gemini 2.5, Qwen3等）でも、入力長が増えると性能が非一様に劣化する。 今後は単なる「情報の有無」ではなく、「情報の配置・提示方法」まで考慮した設計＝コンテキストエンジニアリングが不可欠。

Hackerたちの意見

確かに、これを実感してる。特に、Gemini Proを使って長文のテキストを参照する時、たくさんのドキュメントを一つのコンテキストウィンドウに入れると、最初にドキュメントを要約してから、その要約について質問する方が、サブドキュメントの全文をリクエストした時の答えが良くなる。要するに、RAGスタイルかシンプルなエージェントループがいいってことだね。同様に、個人的にはClaude CodeをOpusやSonnetで使うと、圧縮が進むほど悪化するのを感じてる。要約が悪くなるのか、コンテキストウィンドウに関係の薄いデータが増えるのかは分からないけど、コンテキストをクリアして関連ファイルを再読させると（たとえ圧縮で言及されて要約されていても）結果が良くなるんだよね。

└

NotebookLMを試したことある？これは基本的にバックグラウンドで多くのドキュメントをチャンク化して要約するアプリで、RAGを使ってフルコーパスとチャットできるんだ。

└

Geminiは、チャットがコンテキストの制限に達する前に、一貫性や推論能力を失うんだって。このレポートによると、いくつかの面では最高のモデルらしいよ。要するに、コンテキストエンジニアリングはまだまだ重要で、RAGは死んでないってこと。

└

最適なコーディングエージェントは、自動的にこれをやると思うんだ。必要なコードの部分、MCPの応答、リポジトリのマップなどを集めて（時には要約して）、新しい「チャット」に結果をまとめて、必要な部分だけを含むメッセージを作る感じ。実際、これが今やってることに近いんだけど、コンテキストが多い状況ではパフォーマンスが今まで試したどのエージェントや自動化されたワークフローよりも良いと感じてる。でも、やっぱり結構大変なんだよね。

└

「コンパクション」って、要するにトランスクリプトを要約することだよね？だから、エージェントが情報を失ってるから悪化するのは理解できるけど、コンテキストの劣化とは関係ないと思う。コンテキストの劣化を示すのは、自動コンパクトの閾値に近づいたときだよね？これで合ってる？

すごく面白い結果だし、記事も充実してる！たくさんの洞察があるね！メディアリテラシーの注意点：Chromaはベクターデータベースの会社だよ。

└

Chromaはベクトル検索、フルテキスト検索、正規表現検索を行うよ。そして、AIアプリケーションに典型的なマルチテナントワークロード向けに設計されてる。だから、単なる「ベクターデータベースの会社」じゃないんだ。

この効果はよく知られてるけど、まだあまり文書化されてないから、ここは素晴らしい仕事だね。実際、簡単にベンチマークできる以上に重要なんだ（この論文がそれをやってくれて嬉しいけど）。本当に役立つLLMアプリケーションは、モデルができることの境界に存在するんだ。つまり、実際の質問やタスクから数回論理的に「ジャンプ」する必要があるコンテキストの一部に注意を向けることだと思う。コンテキストの劣化問題は、こういう複雑なタスクではもっと悪化するんじゃないかな…実際、成功するために必要な論理的な「ジャンプ」が増えるごとに指数関数的に悪化すると思う。それぞれのジャンプが「注意の難しさ」を増加させ、長い・気を散らすコンテキストによってさらに悪化するんだ。

本当に必要なのは、コンテキストを簡単に整理する方法だと思う。もしモデルと一緒にチャット全体を手動で管理できたら、典型的な約20万トークンのコーディングセッションからもっと多くの情報を引き出せるはずなんだ。今は良いインスタンスが動いてるけど、モデルが2万トークンでつまずいて、そのセッションがひどく劣化しちゃった。切り捨てさせてくれ！

└

前のチェックポイントに戻すだけでも、すごい機能になるよね。

└

/compressは、ほとんどのCLIエージェントでこれを実行するためのコマンドだよ。

└

ローカルのLLMは、コンテキストを好きなように編集できるから、LLMが生成したレスポンスも含めて、後で自分が言ってほしいことを言ったと思わせることができる。これが正しい方向に進むのに役立つんだ。LLMをサービスとして提供しているものは、これを提供しないけど、そうすると検閲を簡単に回避できちゃうからね。

これは情報検索の一種の問題だけど、コンテキストの長さによるパフォーマンスの変化は、非検索の回答（例えば「このボタンを赤にするための編集されたコードは？」とか「上記のカテゴリーの中で‘…’はどれに該当する？」）では違うかもしれないと思う。前に注目した論文は「Many-Shot In-Context Learning」で、コンテキストに例を詰め込むことでパフォーマンスが大きく向上することが示されてた。やっぱり、LLMが異なるコンテキストの内容や長さでどう変わるかを知るためには、自分の問題をテストするのが重要だよね。長いコンテキストが常に悪いとは限らないと思う。

└

直感的には、推論が必要な質問は、直接的な検索の質問よりも常にパフォーマンスが悪いと思ってる。例外なしでね。特に否定的なことや気を散らす要素があるときは。君の言う通り、直感は測定じゃないから、関連する数字が見られるといいな。ICLは長いコンテキストのパフォーマンス低下とは別の現象で、共存できると思う。真ん中で迷うことが、異なる位置にある例のパフォーマンスに影響を与えるのと同じように。

体験的に言うと、新しい機能やコード変更についてCursorで会話が長くなるほど、出力が悪くなる感じがする。最良の結果は、明確で具体的な指示と、変更や機能のための計画を事前に立てて、編集する関連ファイルをコンテキストプロンプトに引き込むときに出るみたい。

└

同意！「探る -> 計画 -> コード -> テスト -> コミット」の流れが、ステップ間のコンテキストをクリアにしてくれるから、いい感じだよね。

私も同じような経験があるよ。動画のトランスクリプトを検索するプロジェクトに取り組んでるんだけど、これってしばしばすごく長いテキストになるんだ。GPT 4.1シリーズみたいなモデルは非常に大きなコンテキストウィンドウを持ってるから、RAGは必要ないと思ったけど、特に小さいモデルでは変な問題に気づくことがある。質問に答えずに、内容の一般的な要約を返すみたいなことがあるんだよね。

自分が開発したり使ったりしてきた、LLMのコンテキストサイズを減らすためのテクニックをいくつかまとめたよ。https://www.notion.so/LLM-Context-Engineering-21b814d6a64980... これらのうちいくつかは、ツールコールに重点を置いた社内のAIチャットアプリで使われてるんだ。

Claudeのコードは、自分のミスと俺の指示を区別する能力を失っちゃうんだよね。一度混乱すると、最初からやり直し。セッションが長くなるほど、ループに入ったり、テストがすでに壊れてるって決めつけて無視しちゃったりする。自分のプロンプトやコンテキストが悪いのは分かってるけど、最近のClaudeはIQが30ポイント下がったみたいに感じる。

└

自分のプロンプトやコンテキストが悪いのは分かってるけど、 これって、今みんなが内面化しちゃったガスライティングみたいに感じない？

無料のヒント：モデルはマルチショットの会話でコンテキストを整理したり、クリーンアップするように訓練できるよ。最終的に削除されたトークンの量と、最終的に確認可能な報酬は、確認可能なシグナルそのものなんだ。乾杯！