100万トークンのコンテキストウィンドウ

100万トークンのウィンドウがあれば、コードベース全体、文書コーパス、数時間分の文字起こしを、検索システムなしでコンテキストに直接配置できます。これはコンテキスト内のすべてという約束です。モデルは情報量の少ない要約ではなく、生の素材をもとに推論します。

• リポジトリ全体を対象にした推論とリファクタリング。
• チャンク分割なしの文書横断的な統合。
• 初期の詳細を保持する、長期的な会話。

ただし、容量が大きいことと効果的に使えることは同じではありません。

公称のウィンドウサイズは上限であり、どの位置でも均一に想起できる保証ではありません。有効コンテキスト、つまりモデルが確実に検索して推論できる範囲は、通常それより小さく、位置によってばらつきます。

ウィンドウを、価値が均一ではない予算として扱います。中央の奥深くに埋め込まれたトークンよりも、端に近いトークンのほうが想起されやすくなります。

コンテキストの長さが増えるとアテンションのコストが増え、time-to-first-tokenも長くなります。100万トークンのプロンプトでは、回答が短くても、プリフィルのレイテンシーが数秒に及び、呼び出しごとのコストも相当な額になる可能性があります。

• 巨大なプロンプトでは、プリフィルがレイテンシーの大部分を占めます。
• 出力サイズにかかわらず、コストは入力トークン数に比例します。
• 必要のないコンテキストを詰め込むのは、モデルを混乱させるために料金を払うことです。

コンテキストを増やすと精度が下がることがあります。無関係な情報は注意を分散させ、モデルが引きずられる可能性のあるノイズを持ち込みます。特定の質問に対しては、ノイズの多い50万トークンのプロンプトより、焦点を絞った2万トークンのプロンプトのほうが優れていることがよくあります。

原則は、タスクに役立つものを含め、関連するかもしれないだけのものは除外することです。

検索では分断されてしまう全体的かつ横断的な推論が必要な場合は、長大なコンテキストが有効です。たとえば「リポジトリ全体でこの不変条件に違反している箇所をすべて見つける」「10件すべての契約書にある矛盾を調整する」といったタスクです。チャンク分割した検索では、チャンクをまたぐつながりを見落とす可能性があります。

統合には完全なコンテキストを使い、巨大なコーパスから特定の一点を探す検索にはリトリーバルを使います。

関連する割合がごく小さく、内容が安定している場合は、検索が有効です。5万ページすべてを詰め込み、モデルが見つけてくれることを期待するよりも、5万ページから関連する5ページを取得するほうが安価で高速であり、多くの場合に正確です。

• 静的なコーパスへの頻繁なクエリ → 一度インデックスを作成し、低コストで検索します。
• 一度限りの全体的な統合 → 長大なコンテキストを使います。

多くのシステムは両方を組み合わせます。検索で範囲を絞り、その後、長大なコンテキストで統合します。

位置によって想起率が変わるため、コンテンツをどこに配置するかは設計上の決定事項です。モデルが最もよく想起できる境界にタスクの指示と最重要の素材を置き、必ず使う事実をコンテキストの中央奥深くに埋め込まないようにします。

位置は、単純な連結順序の偶然に任せず、意図的に管理します。

埋め込んだ事実をモデルが使ったと決めつけてはいけません。検証してください。既知の深さに既知のカナリア情報を挿入して尋ね、深さごとの想起率を測定します。本番で信頼する前に、自分のプロンプト構成における自分のモデルの特性を把握します。

長時間にわたるエージェントセッションでは、コンテキストを無制限に増やしてはいけません。定期的にコンパクションを行い、古くなったターンを密度の高い状態オブジェクトに要約して、生の履歴を削除します。これにより信号を維持しながら予算を取り戻し、希薄化を減らせます。

蓄積はデフォルトであり、罠でもあります。コンパクションは規律です。

最も強力な設計は、複数の戦略を組み合わせます。焦点を絞った候補集合を検索し、意図的な位置に配置し、安定したプレフィックスをキャッシュし、会話をコンパクションします。長大なコンテキストは予算管理ツールキットの1つであり、エンジニアリングの代替ではありません。

• 縮小するために検索します。
• 見せるために配置します。
• 低コストにするためにキャッシュします。
• 維持するためにコンパクションします。

ウィンドウ全体を使う前に、次の点を確認します。

• タスクには全体的な推論が必要ですか、それとも一点検索ですか。一点検索ならリトリーバルを使います。
• 関連する割合は小さく、安定していますか。はい → リトリーバルまたはキャッシュを使います。
• 巨大なプリフィルのレイテンシーとコストは許容できますか。いいえ → 縮小します。
• 依存している深さで想起率を検証しましたか。まだなら、先に検証します。

容量は許可であって、計画ではありません。

静的な4万ページのアーカイブのうち、およそ3ページにしか存在しない、限定的な事実質問に答える必要があり、このクエリを1日に数千回実行するものとします。

巨大なウィンドウは、自由にすべてを想起できるものではなく、不均一な予算です。実効コンテキストは容量より小さく、レイテンシーとコストは入力に応じて増加し、無関係な情報は精度を薄めます。グローバルな統合には長大なコンテキストを、ピンポイントの情報には検索を、それ以外にはハイブリッド方式を使います。その際、重要な内容を想起されやすい位置に配置し、安定したプレフィックスをキャッシュし、長いセッションを圧縮し、埋もれた事実を信頼する前に必ず想起性能を検証します。