コンテキストウィンドウを理解する:トークン、アテンション、そして長文脈が崩れる場所

コンテキストウィンドウは、現代のAIで最もよく引用され、最も理解されていない数値の一つです。それが大きいことは、RAMやストレージが多いことが良く聞こえるのと同じように、無条件に良く聞こえます。話はそう単純ではありません。コンテキストウィンドウは現実の限界と静かな失敗モードを持つ作業スペースであり、それを無限で完璧な記憶のように扱うことが、3段落前に伝えたことを不可解にも忘れるシステムをチームが出荷してしまう原因なのです。

この記事は、コンテキストウィンドウが具体的に何なのか、なぜその基盤となる仕組みが長い入力を高価で不完全なものにするのか、そしてその限界を存在しないふりをするのではなく尊重するシステムをどう設計するかを説明します。

コンテキストウィンドウとは実際に何か

言語モデルは文字や単語を直接読みません。トークンを読みます。トークンとはテキストの塊で、しばしば一つの単語、単語の一部、あるいは句読点です。大まかな目安として、トークンは英語の数文字に対応するので、1ページのテキストは数百トークンほどです。正確な対応はモデルのトークナイザーに依存しますが、原則は安定しています。モデルが何かを見る前に、テキストはトークンの並びになるのです。

コンテキストウィンドウは、モデルが一度に考慮できるトークンの最大数です。あなたが与える入力プラスそれが生成する出力が、同じ予算を分け合います。一度のやり取りでモデルが「知っている」すべて、すなわち指示、貼り付けた文書、これまでの会話、そして書かれつつある答えは、このウィンドウの中にあります。別個の長期記憶はありません。モデルがチャットの前のほうを「覚えている」と人が言うとき、それが意味するのは、前のテキストがまだウィンドウの中にあるということです。何かがその外に落ちた瞬間、モデルはそれにまったくアクセスできなくなります。

これが第一の揺るがぬ洞察です。コンテキストウィンドウは短期の作業記憶であって、ストレージではありません。 それは持続せず、自ら大きくはならず、その中の何も使われる保証はありません。

アテンション:エンジンとそのコスト

なぜ長い文脈が難しいかを理解するには、各トークンを他のトークンと関連づける仕組みであるアテンションの感覚が必要です。処理するすべてのトークンについて、モデルはウィンドウ内の他の各トークンがそれにどれだけ影響を与えるべきかを重み付けします。それが、モデルが代名詞をそれが指す名詞に、あるいは問いを文書の前のほうに埋もれた関連する文に結びつけることを可能にするのです。

決定的な性質は、そのコストがどう増えるかです。すべてのトークンが他のすべてのトークンにアテンドできるため、作業量はおおむねトークン数の2乗でスケールします。入力を倍にしても作業は倍にならず、おおよそ4倍になります。これが、非常に長い入力の処理が時間でも費用でも不釣り合いに高価である理由であり、コンテキストウィンドウが任意に大きくはなく固い上限を持つ理由です。この2乗則のコストは、長さに対する根本的な税金です。さまざまな技術がそれを減らし、より効率的な長文脈手法の研究は活発に続いていますが、基本的な圧力は決して消えません。長い入力は、アテンドするのに超線形的に高価なのです。

トークンはコストと限界の単位

すべてがトークンで測られるため、トークンはあなたがぶつかるほぼすべての実践的な制約の単位でもあります。

• トークンで課金されます。 ホスト型モデルでは入力も出力も課金されます。プロンプト内の長い文書は、送るたびに本当のお金がかかります。
• レイテンシはトークンを追います。 ウィンドウ内のトークンが多いほど、一般に応答は遅くなります。読むものが多いことと、生成が同じ予算を奪い合うことの両方によります。
• ウィンドウは共有されます。 巨大な入力は答えのための余地を減らします。コンテキストでウィンドウを満たせば、出力を飢えさせかねません。

実践的な習慣が導かれます。トークンを意図的に費やす予算として扱うのです。「念のため」の素材でプロンプトを水増しするのは無料の保険ではありません。お金がかかり、レイテンシを足し、そして次節が説明するように、実際に答えを悪くしうるのです。

長文脈が崩れる場所:失われる中間

これが、人々を最も驚かせる失敗モードです。テキストがウィンドウに余裕で収まるときでさえ、モデルはそのすべてに等しくアテンドするわけではありません。広く観察されるパターンは、モデルが長い入力の冒頭と末尾の情報を、中間に埋もれた情報よりも確実に使うというものです。決定的な事実を長い文書の中央に置くと、技術的にはまさにそこ、ウィンドウの中にあるにもかかわらず、モデルはそれを一度も見なかったかのように振る舞うかもしれません。

つまり、大きなコンテキストウィンドウは、入れたすべてをモデルが使うことを保証しません。収まることと使われることは別物です。データシート上の容量の数値は、何が収まるかを教えてくれます。何が確実に使われるかについては、ほとんど何も教えてくれません。

同じ効果が、チームが繰り返し再発見する直感に反する結果を説明します。プロンプトに文書を詰め込むほど、答えの質が上がるどころか下がりうるのです。無関係なテキストが増えるほどアテンションが薄まり、関連する部分を中間の奥へ押しやり、そこが最も見落とされやすいのです。コンテキストにおいては、多いことは自動的に良いわけではなく、ときに悪いのです。

限界を回避するのではなく、限界に向けて設計する

これらの制約をなくすことはできませんが、それがめったに噛みつかないよう設計することはできます。指導原則は単純です。入れる量を減らし、正しいものを見られる場所に置く。

1. 取得せよ、投げ込むな。 知識ベース全体を貼り付ける代わりに、今の問いに関連するひと握りの一節だけを取得し、それだけを含めます。これが検索拡張システムの核心的なアイデアであり、すべてを投げ込むことが高価でかつ当てにならないからこそ存在するのです。
2. 位置が重要。 最も重要な指示と最も関連する証拠を、長いブロックの中間に埋めるのではなく、プロンプトの冒頭か末尾の近くに置きます。
3. 過去を要約せよ。 長い会話では、一語残らず先へ運ぶのではなく、前のターンを定期的に短い要約に圧縮します。これにより、予算のすべてを記録に費やすことなく、要点をウィンドウ内に保てます。
4. 答えのための余地を残せ。 出力のためにウィンドウを十分に予約します。ウィンドウを縁まで満たすプロンプトは、応答を切り詰めたり劣化させたりしかねません。
5. 実際の長さで想起をテストせよ。 ユースケースが長い入力を含むなら、既知の事実を現実的な文書の中間に隠し、モデルがそれを取り出せるかを確認する小さな評価を作りましょう。容量の数値が守ってくれると仮定する代わりに、失敗モードを直接測るのです。

実例

製品マニュアルから答えるサポートアシスタントを想像してください。素朴な設計は、マニュアル全体をすべてのプロンプトに貼り付け、大きなウィンドウがそれを処理すると信じます。それは遅く、高価で、そして関連する段落はたいてい中間のどこかにあるため、当てになりません。規律ある設計は、マニュアルをインデックス化し、ユーザーの問いに合致する2、3の一節を取得し、それらをプロンプトの末尾近くに明確に配置し、答えのための余地を十分に残します。二つ目のシステムは、利用可能なコンテキストのはるかに小さな割合しか使わないにもかかわらず、より安く、より速く、かつより正確です。それが一つの実例に凝縮された教訓のすべてです。ウィンドウをうまく使うことは、満たすことに勝るのです。

まとめ

コンテキストウィンドウは、トークンで測られるモデルの短期作業記憶で、あなたの入力とその出力の間で共有されます。アテンションがそれを有用にし、そのコストが長さの2乗で増えるがゆえに、それを限定的にもします。容量の数値は何が収まるかを教えますが、モデルが何を確実に使うかは教えません。そして長い入力の中間における十分に文書化された弱点は、テキストが多いことが答えが良いことと同じではないことを意味します。それに応じて設計しましょう。投げ込むのではなく取得し、重要なものを見られる場所に配置し、過去を要約し、応答の余地を残し、実際の長さで想起をテストするのです。ウィンドウの限界を尊重するチームは、ただ大きいものを買うチームよりも、そこから多くを引き出します。

出典に関する注記:コンテキストウィンドウのサイズと、それを拡張する具体的な技術は急速に変化するため、この解説は揺るがぬ仕組みに焦点を当てています。現在の容量と手法については、公式のモデルドキュメントと一次研究を直接参照してください。