コンテキストウィンドウ

概要

コンテキストウィンドウは、1つのリクエストに対するモデルのワーキングメモリであり、一度に考慮できるトークンの最大数です。これは、システムプロンプト、会話の過去のすべてのやり取り、プロンプトに配置されたドキュメント、新しいメッセージ、およびモデルが生成している回答など、すべてによって共有されます。収まりきらないものは単に認識されません。

ウィンドウは急速に拡大しており、初期のモデルの数千トークンから数十万トークンへ、そして現在のいくつかのモデルでは約100万トークンに達しています。このサイズはモデルの構築およびトレーニング方法によって固定されており、ファインチューニングによって変更されることはありません。

仕組み

Transformerは入力を並列に読み込み、すべてのレイヤーにおいて、アテンションと呼ばれるメカニズムを通じて各トークンが過去のすべてのトークンを参照できるようにします。これにより、会話のずっと前の詳細に基づいて回答することが可能になります。また、これが長いコンテキストが高コストになる理由でもあります。標準的なアテンションでは、計算量は長さの2乗に比例して増加し、生成中に会話を保持するために使用されるメモリはトークンごとに増加します。

回答もカウントされます。モデルが128,000トークンのウィンドウを持ち、入力が126,000トークンの長さである場合、回答に残されるのはわずか2,000トークンです。また、ほとんどのAPIでは出力の長さにも別途上限が設けられています。

規模の大きさが質の高さとは限らない

モデルは長い入力を受け入れることができますが、そのすべてを有効に活用できるとは限りません。長いコンテキストに関する研究では、モデルは入力の中間に埋もれた情報よりも、最初と最後にある情報をより確実に利用すること、そして非常に長いウィンドウを謳う多くのモデルが、明記された制限に達するずっと前に精度を落とすことが分かっています。トレーニングと使用のどちらにおいても、通常は、不必要に長いコンテキストよりも、短く関連性の高いコンテキストの方が優れた結果をもたらします。

1サンプルあたりのトレーニング制限

トレーニングには2つ目の制限が加わります。それは1サンプルあたりのトークン制限であり、プロバイダーがトレーニングの対象とする単一レコードの最大長です。長いレコードでのトレーニングは、回答を生成する場合よりもはるかに多くのメモリを必要とするため、この制限はモデルのコンテキストウィンドウよりも小さいことがよくあります。制限を超えたレコードは、短縮するか除外する必要があります。

よくある間違い

• 大きなコンテキストウィンドウを持つモデルが、同じく長いレコードでトレーニングされると思い込むこと。
• 入力とともに回答もウィンドウ内に収める必要があることを忘れること。
• コンテキストは多ければ多いほど良いという理論に基づき、利用可能なすべてのドキュメントをプロンプトに詰め込むこと。
• 最も古いやり取りをトリミングすれば有用なターゲットを保持できたにもかかわらず、長い会話を完全に除外してしまうこと。

参考文献および関連資料

外部ソースは新しいタブで開きます。

1. 01Lost in the Middle: How Language Models Use Long Contexts↗Liu et al., 2023 · arXiv · arxiv.org長い入力の中間にある情報が最も不確実に利用されることを示しています。
2. 02RULER: What's the Real Context Size of Your Long-Context Language Models?↗Hsieh et al., 2024 · arXiv · arxiv.orgモデルが謳っているウィンドウサイズをどれほど下回る範囲で信頼性を維持できるかを測定します。
3. 03Attention Is All You Need↗Vaswani et al., 2017 · arXiv · arxiv.orgコンテキスト全体に対するアテンションの概念の由来となったTransformerの論文です。
4. 04Context windows↗Claude Platform Docs · platform.claude.com入力と出力がウィンドウをどのように共有するかについてのプロバイダーの説明です。

関連する概念