コンテキストウィンドウ（Context Window）とは、大規模言語モデルが一度に処理できるトークン数の上限であり、単一の入力および生成テキストの長さを規定するものです。この仕組みは、モデルが一度に読み込めるドキュメント、会話、コードの長さを直接決定し、VRAMの使用量や推論コストにも影響を与えます。ウィンドウサイズは初期の数千トークンから、今日では数十万から百万規模まで拡大していますが、その本質は「能力」ではなく「容量」です。つまり、収容できることと、それを有効活用できることは異なります。

この用語はTransformerベースの言語モデルの普及に伴って定着しました。2020年、GPT-3の論文では入力上限を2048トークンと固定設定としており、以降「コンテキストウィンドウ」はモデル仕様を記述する際の一般的な用語となりました。各社のウィンドウサイズは、モデル比較表における重要な指標の一つとなりました。

しかし、比較表にあるこの数値はあくまで容量の上限を示すものであり、実際の利用可能なレベルを必ずしも反映していません。「収容できること」と「有効活用できること」は別物です。2023年、Liu氏らは論文《Lost in the Middle: How Language Models Use Long Contexts》で古典的な検証を行いました。複数文書のQ&Aやキー・バリュールックアップのタスクにおいて、重要な情報が冒頭または末尾にある場合にモデルのパフォーマンスが最も良く、長いテキストの中間部分にある場合に性能が著しく低下し、全体として「U字型」のカーブを描くことが示されました。専門的な長文コンテキスト対応モデルであっても、この傾向を免れることはできませんでした。メカニズム的には、標準的なアテンション機構の計算量はシーケンス長に対して二次的に増加し、KVキャッシュもウィンドウサイズに比例して線形に膨張するため、「ウィンドウを大きくする」ことはより高いVRAM使用量と遅延コストを意味します。研究者たちは位置エンコーディングの補外や検索による圧縮などの手法でこれを緩和しており、一般的なエンジニアリング上の解決策は検索拡張生成（RAG）です。まず長いドキュメントをチャンクに分割し、必要に応じて検索してから、最も関連性の高いフラグメントをウィンドウ内に配置します。エンジニアリング上の教訓は明確です。重要な情報は冒頭または末尾に配置すべきであり、長いドキュメントはまず検索してからモデルに与えるべきです。