LLMが一度に処理できるトークン数を数万〜数百万規模に拡張した長大コンテキスト技術。書籍全体の要約や大規模コードベースの解析など、従来のモデルでは不可能だったタスクを実現する。
Long Context Window（ロングコンテキストウィンドウ）とは、大規模言語モデル（LLM）が一度の推論で参照・処理できるトークン数を、従来の数千〜数万トークンから数十万〜数百万トークン規模に拡張する技術群の総称である。GPT-4 Turboの128Kトークン、Claude 3の200Kトークン、Gemini 1.5 Proの100万トークンなど、2024年以降のフロンティアモデルでは長大コンテキストが標準機能となっている。
従来の4K〜8Kトークン制限では、以下のような実用的タスクに対応できなかった。
| コンテキスト長 | 相当するテキスト量 | 代表的モデル |
|---|---|---|
| 4K tokens | 約3,000語・A4約3枚 | GPT-3.5初期 |
| 32K tokens | 約24,000語・A4約25枚 | GPT-4初期 |
| 128K tokens | 約96,000語・小説1冊分 | GPT-4 Turbo |
| 200K tokens | 約150,000語・論文集 | Claude 3 |
| 1M tokens | 約750,000語・書籍数冊分 | Gemini 1.5 Pro |
| 10M tokens | 約7,500,000語・百科事典級 | Gemini 2.0（実験的） |
標準的なTransformerのSelf-Attentionは入力長Nに対してO(N²)の計算量とメモリを消費する。128Kトークンでは4Kトークン時の1,024倍の計算リソースが必要となり、そのままでは実用的な推論速度を維持できない。
学習時に見たことのない位置（たとえば学習は4Kまでだが推論時に128Kを入力）では、位置エンコーディングが破綻し出力品質が急激に劣化する。RoPE（Rotary Position Embedding）の周波数成分を調整するYaRN、NTK-Aware Scalingなどの手法がこの問題を解決する。
長コンテキストではKey-Valueキャッシュが巨大化し、GPUメモリを圧迫する。GQA（Grouped-Query Attention）やMQA（Multi-Query Attention）でKVヘッド数を削減する手法、PagedAttention（vLLM）で仮想メモリ的にKVキャッシュを管理する手法が実用化されている。
| 観点 | 詳細 |
|---|---|
| Lost in the Middle問題 | 長コンテキストの中央付近に配置された情報は検索精度が低下する傾向がある |
| コスト | トークン課金モデルでは入力トークン増加がそのままコスト増に直結する |
| レイテンシ | 長い入力はTime-to-First-Token（TTFT）を大幅に増加させる |
| 品質保証 | Needle-in-a-Haystack テストで性能を検証するが、実タスクとの相関は完全ではない |
Long ContextとRAG（Retrieval-Augmented Generation）は競合ではなく補完関係にある。
A1: 不要にはならない。100万トークンでも全社ドキュメント（数百万〜数千万トークン）は収まらず、コスト面でもRAGによる事前フィルタリングが有効である。両者を組み合わせる「Long Context + RAG」が現時点での最適解とされている。
A2: 必ずしもそうではない。不要な情報を大量に含めると「Lost in the Middle」問題やノイズの影響で精度が下がる場合がある。必要な情報を適切に選別してコンテキストに含めることが重要である。
A3: 代表的なベンチマークとしてNeedle-in-a-Haystack（NIAH）テスト、RULER、LongBenchがある。NIAHは特定の情報をランダムな位置に埋め込んで検索精度を測定し、RULERは多針検索・集約・追跡など複合タスクで評価する。