Context Windowとは？長い資料を渡せても、全部を同じように使えるとは限らない
Context Windowは、モデルが一度の処理で参照できるトークン列の範囲だ。利用者の質問だけでなく、会話履歴、資料、ツールの結果、生成中の文章も、モデルへ渡される文脈を占める。長い資料を丸ごと貼れば便利そうだが、入る量と、その中の情報を正しく使えるかは別の問題である。
「仕様上は長文を受け付けるのに、資料の真ん中に書いた条件だけ見落とす」という現象は、入力が長さの上限に収まっていることだけでは説明できない。文脈の設計では、トークン数と情報の見つけやすさの両方を見る必要がある。
単位は文字数ではなくトークン数
文章はトークナイザーでID列に分けられてからモデルへ入る。文字数が同じでも、言語、記号、コード、分かち方によってトークン数は変わる。したがって「日本語で何文字まで」と固定換算するのは危うい。実際に使うモデルのトークナイザーで数えるのが確実だ。
Context Windowの長さはモデルや提供サービスによって異なる。入力と出力をどのように上限へ数えるか、内部の制御用メッセージやツール呼び出しをどう扱うかも、実装の仕様を確認したい。説明用に総予算を8,000トークンと置いても、8,000トークンの資料を貼って、さらに長い回答を同じ予算で得られるとは限らない。これは特定の製品の上限値を示した例ではない。
上限を超えたとき、何が残るかを決める
入力が長すぎる場合、エラーにする、途中を切り詰める、古い会話を落とす、要約して置き換えるなどの処理が考えられる。どれが起こるかはアプリケーションやライブラリの設定次第だ。Hugging Face Transformersの前処理資料では、truncation=True によってモデルの最大入力長へ切り詰める設定と、その切り詰め方を示している。
切り詰めで重要な条件や例外が消えれば、モデルがその情報を使えないのは当然だ。長い会話を要約して引き継ぐ場合も、要約に残らなかった細部は元のまま参照できるわけではない。画面上で過去の会話が見えていることと、毎回すべてがモデルの入力へ渡されることも同義ではない。
範囲内でも、中央の情報を見落とすことがある
『Lost in the Middle』は、複数文書からの質問応答とKey-Value検索の実験で、関連情報の位置によってモデルの性能が変わることを調べた。評価したモデルでは、関連情報が入力の最初や最後にある場合より、中央にある場合の成績が低い傾向が観察された。これは「すべてのモデル、すべての課題で中央は必ず読めない」という法則ではない。しかし、最大長の宣伝値だけで長文利用の品質を判断できないことを示す。
資料を渡すときは、量を増やす前に、質問に関係する箇所を選ぶ。検索で該当部分を抽出し、出典が分かる形で渡す方法はRAGの入口になる。重要な制約は明確に書き、長い文脈のどこに置いたときも守れるかを、実際のタスクで確かめる。単に冒頭と末尾へ同じ文を複製すれば必ず解決するわけではない。
KV Cacheとは違う制限
KV Cacheは過去のKeyとValueを保存し、生成時の再計算を減らす仕組みだ。Context Windowは、モデルが扱うトークン列の範囲に関わる。キャッシュを使えば長い会話を無制限に覚えられるわけではないし、保存した情報が必ず適切に使われるわけでもない。
文脈を設計するときの順番は、まず必要な情報を選び、実際のトークン数と入出力の予算を確認し、そのうえで長文の中から必要な根拠を使えているか評価することだ。Context Windowは容量の指標であって、理解の保証ではない。