context-degradation

コンテキスト劣化パターン

コンテキストの失敗が連鎖する前に診断して修正します。コンテキスト劣化は二値的ではなく、5つの明確で予測可能なパターン（Lost-in-Middle、汚染、混乱、衝突、注意散漫）を通じて現れる連続体です。各パターンには、特定の検出シグナルと軽減戦略があります。劣化を予測不可能な障害モードとしてではなく、測定可能なしきい値を持つ工学的な問題として扱ってください。

アクティブ化のタイミング

以下の場合にこのスキルをアクティブ化してください：

• 長い会話中にエージェントのパフォーマンスが予期せず低下した場合
• エージェントが不正確または無関係な出力を生成するケースをデバッグする場合
• 大規模なコンテキストを確実に処理する必要があるシステムを設計する場合
• 本番システム向けのコンテキストエンジニアリングの選択肢を評価する場合
• エージェントの出力における「Lost-in-Middle」現象を調査する場合
• エージェントの動作におけるコンテキスト関連の障害を分析する場合

他のスキルが担当する関連作業にはこのスキルをアクティブ化しないでください：

• アクティブな障害なしに基礎的なコンテキストの仕組みを説明する場合：context-fundamentals
• 障害パターンが特定された後にトークン効率の戦術を適用する場合：context-optimization
• 圧縮またはハンドオフサマリー戦略を設計する場合：context-compression
• プロンプト外部に大規模な出力、ログ、またはスクラッチ状態を保持する場合：filesystem-context

コアコンセプト

注意力のU字カーブに基づいてコンテキストの配置を構成します。先頭と末尾の位置は確実に注意が向けられますが、中間の位置は長いコンテキストの実験において実際に再現精度が低下します（claim-context-degradation-lost-middle-ruler）。これはモデルのバグではなく、注意メカニズムの結果です。最初のトークン（多くの場合BOS）は「注意のシンク」として機能し、不均衡な注意予算を吸収するため、コンテキストが長くなるにつれて中間のトークンへの注意が低下します。

コンテキスト汚染をサーキットブレーカーの問題として扱ってください。一度幻覚、ツールエラー、または誤った検索された事実がコンテキストに入ると、それらは自己参照を繰り返すことで増幅されます。汚染された目標セクションは、下流のすべての決定が誤った仮定を強化する原因となります。検出には主張の出所の追跡が必要です。回復には、汚染ポイントより前への切り捨て、または検証済みのコンテキストのみを使用した再起動が必要です。

コンテキストをロードする前に積極的にフィルタリングしてください。無関係なドキュメントが1つでもあれば、関連タスクのパフォーマンスが測定可能な形で低下します。モデルは無関係なコンテキストを「スキップ」できず、提供されたすべてのものに注意を向ける必要があり、関連コンテンツと無関係なコンテンツの間で注意の競合が生じます。すぐに関連する可能性はあるが、すぐには必要ない情報は、事前にロードするのではなく、ツールコールの背後に移動してください。

混乱を防ぐためにタスクコンテキストを分離してください。コンテキストに複数のタスクタイプが含まれているか、目的が切り替わる場合、モデルは間違ったタスクの制約を取り込み、異なるコンテキストに適したツールを呼び出し、または複数のソースからの要件を混在させます。別々のコンテキストウィンドウを使用した明示的なタスク分割により、相互汚染を排除します。

コンテキスト衝突は蓄積ではなく優先順位ルールで解決してください。コンテキストに複数の正しいが矛盾するソース（バージョン競合、視点の競合、マルチソース検索）が存在する場合、モデルはどれを適用するかを判断できません。矛盾を明示的にマークし、ソースの優先順位を確立し、コンテキストに入る前に古いバージョンをフィルタリングしてください。

詳細トピック

Lost-in-Middle：検出と配置戦略

重要な情報はコンテキストの先頭と末尾に配置し、決して中間には配置しないでください。U字型の注意曲線により、中間に配置された情報は再現精度が10〜40%低下します。4Kトークンを超えるコンテキストでは、この影響は顕著になります。

注意が向けられやすい位置に重要な調査結果を提示するサマリー構造を使用してください。明示的なセクションヘッダーと構造マーカーを追加します。これらは注意のアンカーを作成することで、モデルが長いコンテキストをナビゲートするのに役立ちます。ドキュメント全体を含める必要がある場合は、主要ポイントのサマリーを先頭に付け、重要な結論を末尾に追加してください。

Lost-in-Middleの症状を監視してください。正しい情報がコンテキストに存在するがモデルが無視する、応答が提供されたデータと矛盾する、またはモデルが長いプロンプトの前半で与えられた指示を「忘れる」。

コンテキスト汚染：防止と回復

外部入力がコンテキストに入る前に、すべてを検証してください。ツール出力、検索されたドキュメント、およびモデル生成のサマリーが3つの主要な汚染ベクトルです。それぞれが未検証の主張をもたらし、後続の推論はそれを真実として扱います。

以下のシグナルを通じて汚染を検出してください。以前は成功したタスクでの出力品質の低下、ツールのミスアライメント（間違ったツールまたはパラメータ）、および明示的な修正にもかかわらず持続する幻覚。これらがクラスター化した場合、モデルの能力の問題ではなく汚染を疑ってください。

汚染を除去するには、修正を上に重ねるのではなく、汚染されたコンテンツを削除することで回復してください。汚染ポイントより前に切り捨てるか、検証済みの情報のみを保持してクリーンなコンテキストで再起動するか、汚染されたセクションを明示的にマークしてゼロから再評価を要求します。汚染されたコンテキストに修正を重ねることがうまくいくことはほとんどありません。元のエラーは注意の重みを保持し続けます。

コンテキストの注意散漫：蓄積ではなくキュレーション

モデルが無関係なコンテンツを無視することに頼るのではなく、コンテキストに入るものをキュレーションしてください。研究によると、1つの注意散漫ドキュメントでも測定可能なパフォーマンス低下が引き起こされます。この影響は線形曲線ではなくステップ関数に従います。複数の注意散漫要素が問題を悪化させます。

検索されたドキュメントをロードする前に、関連性フィルタリングを適用してください。名前空間と構造的な整理を使用して、セクションの境界を明確にします。事前ロードよりもツールコールベースのアクセスを優先してください。参照資料を検索ツールの背後に保存し、現在の推論ステップに直接関連する場合にのみコンテキストに入るようにします。

コンテキスト混乱：タスクの分離

異なるタスクを別々のコンテキストウィンドウにセグメント化してください。コンテキスト混乱は注意散漫とは異なります。これは注意の希薄化だけでなく、モデルが現在のタスクに間違ったコンテキストの制約を適用することに関するものです。兆候には、クエリの間違った側面に対処する応答、異なるタスクに適したツール呼び出し、および複数のソースからの要件を混在させる出力が含まれます。

タスクコンテキスト間の明確な遷移を実装してください。タスクごとに目的、制約、ツール定義を分離する状態管理を使用します。単一セッション内でのタスク切り替えが避けられない場合は、現在のセグメントにどの制約が適用されるかを示す明示的な「コンテキストリセット」マーカーを使用します。

コンテキスト衝突：競合解決プロトコル

競合が発生する前にソースの優先順位ルールを確立してください。コンテキスト衝突は汚染とは異なります。情報の複数の部分が個々には正しいが、相互に矛盾している場合（バージョン競合、視点の違い、異なる事実を持つマルチソース検索）。

古い情報がコンテキストに入る前に除外するバージョンフィルタリングを実装してください。矛盾を回避できない場合は、構造化された競合アノテーションを使用して明示的にマークします。何が競合しているか、各主張のソース、およびどのソースが優先されるかを記載します。明示的な優先順位ルールがない場合、モデルは予測不能な方法で矛盾を解決します。

実証的なベンチマークとしきい値

これらのベンチマークを設計上の制約を設定するために使用しますが、普遍的な真実としてではありません。RULERスタイルの証拠は、宣伝されている長いコンテキストのサポートが、その長さでの満足のいくタスクパフォーマンスを保証しないことを示しています（claim-context-degradation-lost-middle-ruler）。完璧に近い針山の中の針のスコアは、現実世界の長いコンテキストパフォーマンスを予測しません。

モデル固有の劣化しきい値

劣化の開始はモデルファミリーとタスクタイプによって大きく異なります。一般的なルールとして、複雑な検索タスクでは、広告されているコンテキストウィンドウの60〜70%で劣化が始まると予想されます（RULERベンチマークでは、32K以上のコンテキストを主張するモデルのうち、その長さで満足のいくパフォーマンスを維持しているのはわずか50%でした）。キーパターン：

• 拡張思考を持つモデルは、ステップバイステップの検証を通じて幻覚を低減しますが、レイテンシとトークンコストが高くなります
• エージェント/コーディングに最適化されたモデルは、ツール出力が多いコンテキストに対して、より優れた注意管理を持つ傾向があります
• 非常に大きなコンテキストウィンドウ（1M以上）を持つモデルは、より多くの生のコンテキストを処理しますが、依然としてU字型の劣化曲線に従います。ウィンドウが大きくなっても問題はなくならず、遅延するだけです

公開されたベンチマークに頼るのではなく、特定のワークロードで劣化しきい値を常にベンチマークしてください。モデル固有のしきい値は、モデルが更新されるたびに古くなります（Gotcha 2を参照）。

直感に反する発見

コンテキスト戦略を設計する際には、これらの研究に裏付けられた驚きを考慮してください：

シャッフルされたコンテキストは、一貫したコンテキストよりも優れたパフォーマンスを発揮する可能性があります。 研究によると、無秩序な（シャッフルされた）干し草の山は、一部の検索タスクにおいて論理的に順序付けられたものよりも優れたパフォーマンスを発揮する可能性があります（claim-context-degradation-distractor-shuffled）。一貫したコンテキストは、検索を混乱させる誤った関連付けを作成する可能性がありますが、無秩序なコンテキストは完全一致を強制する可能性があります。より整理されたコンテキストが常により良い結果をもたらすと想定しないでください。両方の配置をテストしてください。

単一の注意散漫要素は、不釣り合いな影響を与えます。 1つの無関係なドキュメントによるパフォーマンス低下は、最初の1つの後にさらに注意散漫要素を追加した場合と比較して、不釣り合いに大きくなります。注意散漫の防止を二値的に扱ってください。コンテキストをクリーンに保つか、重大な劣化を受け入れるかのどちらかです。

低い針クエリの類似性は劣化を加速します。 異質なコンテンツ間の推論を必要とするタスクは、表面レベルの類似性が高いタスクよりも、コンテキスト長が長くなるとより速く劣化します。クエリと検索されたコンテンツ間のセマンティックな重複を最大化するように検索を設計してください。

より大きなコンテキストが害になる場合

より大きなコンテキストウィンドウがパフォーマンスを向上させると想定しないでください。パフォーマンスはモデル固有のしきい値まで安定しており、その後急速に劣化します。曲線は緩やかな傾斜ではなく、崖の端を持つ非線形です。多くのモデルでは、ウィンドウがはるかに大きなサイズをサポートしていても、意味のある劣化は8K〜16Kトークンで始まります。

コストを考慮してください。400Kトークンのコンテキストを処理するコストは、200Kと比較して線形ではなく、時間と計算の両方で指数関数的に高くなります。多くのアプリケーションでは、これにより大規模なコンテキスト処理は経済的に非現実的になります。

認知的ボトルネックを認識してください。無限のコンテキストがあっても、単一のモデルに数十の独立したタスクにわたって品質を維持させることは、より多くのコンテキストでは解決できない劣化を生み出します。コンテキストを拡大する代わりに、タスクをサブエージェントに分割してください。

実践的なガイダンス

4バケット軽減フレームワーク

アクティブな劣化パターンに基づいて、これらの4つの戦略を適用してください：

書き出す — スクラッチパッド、ファイルシステム、または外部ストレージを使用して、コンテキストをウィンドウの外に保存します。コンテキスト使用率がウィンドウの70%を超えた場合に使用します。これにより、アクティブなコンテキストをスリムに保ちながら、ツールコールを通じて情報へのアクセスを維持します。

選択する — 検索、フィルタリング、および優先順位付けを通じて、関連するコンテキストのみをウィンドウに取り込みます。注意散漫や混乱の症状が現れた場合に使用します。ロードする前に関連性スコアリングを適用し、利用可能なすべてを含めるのではなく、しきい値を下回るものは除外します。

圧縮する — 要約、抽象化、および観察マスキングを通じて、情報を保持しながらトークンを削減します。コンテキストは増加しているが、すべてのコンテンツが関連している場合に使用します。冗長なツール出力をコンパクトな構造化サマリーに置き換え、繰り返しパターンを単一の参照に抽象化します。

分離する — 単一のコンテキストが劣化しきい値を超えて増大するのを防ぐために、コンテキストをサブエージェントまたはセッションに分割します。混乱や衝突の症状が現れた場合、またはタスクが独立している場合に使用します。これは最も積極的な戦略ですが、複雑なマルチタスクシステムには最も効果的であることが多いです。

回復力のためのアーキテクチャパターン

ジャストインタイムのコンテキストローディングを実装します。現在の推論ステップが必要としたときにのみ情報を取得し、事前には取得しません。処理後に冗長なツール出力をコンパクトな参照に置き換えるために、観察マスキングを使用します。各エージェントがタスクに関連するコンテキストのみを保持するサブエージェントアーキテクチャをデプロイします。症状が現れた後ではなく、モデル固有の劣化開始しきい値をコンテキストが超える前に圧縮をトリガーします。

例

例1：劣化の検出

# 長い会話中にコンテキストが増加
ターン_1: 1000トークン
ターン_5: 8000トークン
ターン_10: 25000トークン
ターン_20: 60000トークン（劣化開始）
ターン_30: 90000トークン（重大な劣化）

例2：Lost-in-Middleの軽減

# 重要な情報を端に配置してコンテキストを整理

[現在のタスク]                      # 先頭
- 目標：四半期レポートの生成
- 期限：今週末

[詳細なコンテキスト]                  # 中間（注意が少ない）
- 50ページのデータ
- 複数の分析セクション
- 裏付けとなる証拠

[主な調査結果]                     # 末尾
- 収益が15%増加
- コストが8%削減
- リージョンAで成長

例3：コンテキスト汚染サーキットブレーカー

症状：エージェントが修正後も誤った検索された主張を引用し続ける
診断：汚染されたコンテキスト、指示欠落の問題ではない
アクション：
  1. 間違った主張が入った最初のターンを特定する
  2. そのポイントより前に切り捨てるか、再起動する
  3. 検証済みのソースのみを再ロードする
  4. 拒否された主張とソースの出所を記録する

例4：コンテキスト衝突アノテーション

競合：
  トピック：課金APIバージョン
  ソース_a：docs/v1.mdはエンドポイントが/chargesであると述べている
  ソース_b：docs/v2.mdはエンドポイントが/paymentsであると述べている
  優先順位：docs/v2.md
  理由：現在の本番バージョン

ガイドライン

1. 開発中にコンテキスト長とパフォーマンスの相関関係を監視する
2. 重要な情報をコンテキストの先頭または末尾に配置する
3. 劣化が深刻になる前に圧縮トリガーを実装する
4. コンテキストに追加する前に、検索されたドキュメントの正確性を検証する
5. バージョン管理を使用して、古い情報が競合を引き起こすのを防ぐ
6. 異なる目的間のコンテキスト混乱を防ぐためにタスクをセグメント化する
7. 突然の障害ではなく、段階的な劣化を想定して設計する