コンテキストウィンドウとは何か、そしてなぜ枯渇してしまうのか？
コンテキストウィンドウは、モデルが一度に見ることができるすべてのこと — あなたのプロンプト、会話、取得した文書、そしてその返答 — を指します。ここでは、それがどのように測定されるか、なぜ長いだけが必ずしも良いとは限らないか、そして制限に達したときにどうするべきかを説明します。
ひとことで言うと
AIモデルのコンテキストウィンドウとは何ですか？
コンテキストウィンドウは、モデルが一度のリクエストで考慮できるテキストの最大量（トークン数で測定）です。システム指示、これまでの会話、貼り付けたドキュメント、生成中の回答を含みます。合計が制限を超えると、何かを削除したり要約したりしなければなりません。
要点
- ウィンドウは単語数ではなくトークンで測られます。英語では約0.75単語につき1トークンですが、韓国語や日本語でははるかに少ない文字数で1トークンとなります。
- すべてが同じ予算を共有しています：指示、履歴、添付ファイル、ツール定義、出力です。
- モデルは長いコンテキストの先頭や末尾を中間よりも信頼性高く活用するため、配置が重要です。
- コストとレイテンシは送信するトークン数に比例し、そのためキャッシュと取得は全体を貼り付けるよりも一般的に優れている。
言語モデルとのすべての会話には、一度にどれだけの情報を見ることができるかというハードリミットがあります。そのリミットがコンテキストウィンドウであり、人々が報告する奇妙な振る舞いのほとんど――モデルが言ったことを「忘れる」、添付ファイルを無視する、途中で話の筋を見失う――は、これに起因しています。
単語ではなくトークン
モデルは文字や単語を読み取るわけではありません。テキストはまずトークンに分割されます。これは、トークナイザーが学習した一般的な断片です。英語では、トークンは平均して約4文字なので、1,000トークンは約750単語に相当します。
この比率は普遍的ではありません。トークナイザーのトレーニング分布から外れるスクリプトは、より細かく断片化されます。
| テキスト | おおよそのトークン数 |
|---|---|
The quick brown fox (19文字、英語) | 約4 |
안녕하세요 반갑습니다 (11文字、韓国語) | 約10 |
こんにちは、はじめまして (12文字、日本語) | 約11 |
| 4スペースでインデントされたコード行 | インデントレベルごとに1トークン |
実用的な結果：韓国語または日本語のドキュメントは、同じ表示長さの英語のドキュメントよりもウィンドウを顕著に多く消費し、リクエストあたりのコストも比例して高くなります。
スペースを争うもの
ウィンドウを「貼り付けられるドキュメントの長さ」と考えるのは魅力的です。実際には共有された予算です。
- システムプロンプト――アシスタントの振る舞いを定義する指示。
- モデルがツールを呼び出せる場合、ツールの定義。詳細なスキーマを持つ多数のツールは、何も言わないうちに数千トークンに達することがあります。
- 会話履歴、通常は各ターンで完全に再送信されます。
- 添付または取得されたドキュメント。
- 出力。 ほとんどのAPIでは、生成されたトークンも同じ予算から消費されるため、非常に長い入力は長い回答のためのスペースを残さないことがあります。
大きなPDFを添付して、切り詰められた応答を受け取ったことがあるなら、これが理由です。
長いからといって一様に良いわけではない
長いコンテキストの振る舞いに関する研究――最も影響力のあるのは『Lost in the Middle』――は、一貫したパターンを発見しました。モデルは、長い入力の最初または最後に配置された事実を、中間に埋もれた事実よりもはるかに確実に取得します。曲線はU字型であり、ウィンドウが大きくなっても完全に平坦にはなりません。
これに直接従う3つのルールがあります。
- 指示を最初に、直接の質問を最後に置く。 モデルが最もよく注意を払う2つの位置です。
- パディングしない。 同じ20ページを含む200ページよりも、関連する20ページの方が優れています。
- 現実的な長さでテストする。 5,000トークンで機能するプロンプトは、100,000トークンでは静かに劣化する可能性があります。
ベンダーの「針のむしろ」ベンチマーク――長いドキュメントに1つの文を隠してモデルにそれを見つけさせる――は、簡単なケースを測定します。単一の独特な事実を取得することは、入力全体に広がる資料を推論することよりもはるかに簡単です。
コスト、レイテンシ、キャッシング
リクエストごとに、送信するトークンに対して料金が発生します。20ターンの会話で再送信される100,000トークンのコンテキストは、ユーザーが20の短い質問を入力したとしても、200万入力トークンになります。
2つのメカニズムがその負担を軽減します。
- プロンプトキャッシング。 プロバイダーは、リクエストの変更されないプレフィックス（システムプロンプト、ツールの定義、長いドキュメント）をキャッシュし、キャッシュヒットに対してはるかに少なく請求できます。これは、プレフィックスがバイト単位で同一である場合にのみ機能するため、安定した素材を最初に、揮発性の素材（タイムスタンプ、ユーザー名）を最後に配置します。
- バッチ処理。 対話的でない作業の場合、バッチAPIは通常、結果の遅延と引き換えに大幅に安価になります。
レイテンシも同様の形状をたどります。最初のトークンまでの時間は入力長とともに増加するため、短いプロンプトで即時的に感じられるチャットは、大きなファイルを添付すると遅く感じられます。
リミットに達したときの対処法
貼り付けるのではなく取得する。 ドキュメントをインデックス化し、質問に関連する数ページを取得して送信します。リクエストは小さく、安価で、正確なままです。これがRetrieval-Augmented Generationの主張全体です。
履歴を要約する。 これまでに確立された決定事項や事実のコンパクトな要約で、古いターンを置き換えます。最も最近のターンはそのままにしておきます――そこが直接の話題がある場所です。
タスクを分割する。 2つの集中的なリクエストは、通常、1つの巨大なリクエストよりも優れています。抽出してから分析。ドキュメントごと、その後結合。
ツールをトリムする。 モデルがこのタスクに3つのツールしか必要ない場合、30個を送信しないでください。
最適化する前に測定する。 実際の要求でトークンを数えます。システムプロンプトや使用されていないツールのスキーマが、ユーザーのドキュメントではなく、ウィンドウの大部分を消費していることに、チームは日常的に驚いています。
コンテキストウィンドウは、最大化すべき機能ではありません。それは意図的に費やすべき予算です。
よくある質問
- 20万トーケンのコンテキストウィンドウに何語収容できますか？
- 約15万語、または普通の散文で約500ページに相当します。韓国語、日本語、中国語は文字あたりのトークン数が多いため、同じ上限に対してはかなり少ないページ数になると期待されます。
- より大きなコンテキストウィンドウがあれば、RAGは不要になるのか？
- いいえ。大きなウィンドウを使うと検索がやりやすくなりますが、毎回500ページを送信すると遅くてコストがかかり、非常に長い入力の中央では正確さがまだ低下します。検索はリクエストを小さく的を絞ったものに保ちます。
- 会話がウィンドウを超えるとどうなるの？
- アプリケーションは介入しなければならない — 通常は最古のターンを削除したり、要約したり、取得ストアに移動させたりする。モデル自体はウィンドウ外の情報を見ることはできない。
- 私の長い会話が時間とともになぜ高くなるのか？
- ほとんどの API は、各ターンで全体の会話を再送するため、入力は各交互に増加します。プロンプトキャッシュにより繰り返しのプレフィックスのコストが軽減されますが、トークンはまだ処理されます。