コンテキストウィンドウとコンテキスト長の違い
「コンテキストウィンドウ」と「コンテキスト長」は、同義語として使われることがよくあります。情報源が両者を区別している場合、ウィンドウは最大容量、長さは現在使用されている量を指します。
ここでは、次の3つの数値を区別する必要があります。
- 最大コンテキストウィンドウ：モデルまたはエンドポイントについて公称されている容量。
- 現在のコンテキスト長：特定のリクエストと応答に含まれるトークン数。
- 信頼性のある実用コンテキスト：モデルがあなたのタスクに対して十分に活用できる量。
3つ目の数値は、固定された仕様ではありません。モデル、タスク、関連情報の配置、そして注意を奪い合う無関係な情報の量によって変わります。
コンテキストウィンドウの仕組み
アプリケーションは、リクエストに含める情報を組み立てます。これには次のようなものが含まれます。
- システム指示と開発者指示
- 過去のユーザーとアシスタントのメッセージ
- 現在のメッセージ
- 検索で取得した文章や添付文書
- ツールの説明とツールの実行結果
- 書式設定と特殊な制御トークン
トークナイザーは、それらの情報をモデルが処理する「トークン」に変換します。次に「大規模言語モデル」は、一度に1トークンずつ応答を生成します。生成された各トークンは、次のトークンを生成する際に利用できる系列の一部となるため、出力にも容量が必要です。
後続のチャットターンでは、通常、アプリケーションが過去の情報の一部を再び送信します。履歴をそのまま保持することもあれば、古いターンを削除したり、関連する文章だけを取得したり、古い情報を要約で置き換えたりすることもあります。独立したメモリ機能によってリクエスト間で情報を保存できる場合もありますが、その保存領域自体はコンテキストウィンドウではありません。モデルが情報を利用するには、その情報を現在のコンテキストに含める必要があります。
上限に達したときの挙動はさまざまです。APIがサイズ超過のリクエストを拒否する場合もあれば、チャット製品が最も古い情報を削除したり、要約したりする場合もあります。生成が上限に達した時点で停止することもあります。正確なモデルとエンドポイントについては、ドキュメントを確認してください。
具体例
モデルに仮想的な12,000トークンの共有コンテキストウィンドウがあるとします。
- 非表示の指示：700トークン
- ツール定義：800トークン
- 保持されたチャットと文書：6,500トークン
- 現在のリクエスト：1,000トークン
入力の合計は9,000トークンです。応答には最大3,000トークンを使用できます。
ここで、エンドポイントに別途2,000トークンの出力上限があるとします。共有ウィンドウには3,000トークン分の余裕がありますが、応答に使用できるのは2,000トークンまでです。実際の上限は、適用される制約のうち最初に到達したものになります。
アプリケーションが6,500トークンの履歴を1,500トークンの要約に圧縮すると、入力は4,000トークンになります。これにより余裕は増えますが、コンテキストウィンドウが大きくなったわけではありません。過去の情報を別の、より小さい表現に置き換えたのであり、要約から省かれた詳細はリクエストから失われます。
コンテキストウィンドウが重要な理由
ウィンドウは、モデルが一度に検討できる元情報の量を制限します。長い契約書を1回のリクエストで送信できるか、長時間の会話の一貫性を保てるか、あるいはコーディングアシスタントに問題解決に必要なリポジトリの十分な部分を与えられるかに影響します。
また、出力の計画にも影響します。利用可能な容量のほぼすべてを入力で埋めると、回答に使える余地が少なくなります。そのためアプリケーションは、履歴や検索で取得したテキストをどれだけ含めるか決める前に、出力用の予算を確保することがよくあります。
コンテキストが増えると、コストも発生します。入力が長いほど通常は処理時間と計算量が増え、多くのAPIではトークン単位で料金がかかります。無関係なコンテキストがあると、有用な根拠を見つけにくくなることもあります。最良のリクエストは、必ずしも最も多くの情報を含むものではありません。必要な回答のための余地を残しつつ、関連する情報を十分に含むものです。
大きなウィンドウは優れた記憶力ではない
コンテキストウィンドウが測るのは容量であって、永続的な記憶、知識、知能ではありません。モデルは文章を受け付けても、そのすべての部分を同じようにうまく使えるとは限りません。
制御された長文コンテキストの研究では、関連情報が同じ情報であっても中央に埋もれている場合より、冒頭または末尾にある場合のほうが、モデルの性能が高くなることが確認されています。結果はモデルやタスクによって異なりますが、実務上の教訓は明確です。公称された最大値が示すのは何を収められるかであって、モデルが何を完全に想起したり推論したりできるかではありません。
プロンプトキャッシュによって、この区別が変わることもありません。プレフィックスを再利用する際の処理量や料金を削減できる場合はありますが、キャッシュされた情報もモデルのコンテキスト容量に算入されることがあります。
コンテキストウィンドウは、知識カットオフとも異なります。コンテキストウィンドウは、この応答中に利用できる情報を制限します。一方、知識カットオフは、学習中に取り込まれた情報の時点上の境界を表します。
次に読むもの
上限に対してテキストがどのように数えられるかを理解するには、「AIにおけるトークンとは？」を参照してください。「LLMとは？」では、1トークンずつ生成するモデルのプロセスにおけるコンテキストウィンドウの位置付けを説明しています。コンテキスト容量と最も混同されやすい上限については、「コンテキストウィンドウと知識カットオフの違い」を読んでください。