生成AIは知識を圧縮できるのに、
なぜ会話は圧縮できないのか

by
  • AIエージェントの利用枠は、作業した時間に比例して減るわけではありません。同じチャットを続けるほど、1ターンあたりに送られる入力が膨らんでいきます。
  • 学習データは重みに畳み込まれて固定サイズに収まりますが、会話履歴は毎回そのまま入力として渡し直されています。
  • 過去を固定サイズの状態にまとめる方式は、Transformerの前にRNNで試されて、細部を忘れる問題にぶつかりました。
  • KVキャッシュによって計算の再利用は行われています。それでも参照する量そのものは減らないので、要約による圧縮には別の役割があります。

関連記事

1. 残り半分の枠が、10分で消えた

AIエージェントで資料を作っていて、利用枠の減り方に戸惑ったことがあります。 最初の1時間で、週間の利用枠を50%使いました。 なら残りの50%で、あと1時間くらいは同じ調子で作業できるだろう。

1. 残り半分の枠が、10分で消えた

そう見積もって作業を続けたのですが、実際にはその半分が10分か15分で消えました。 途中で手が止まり、枠がリセットされるまで待つことになります。 同じような作業をしているのに、後半だけ急に高くつく。

もちろん、原因が会話の長さだけとは限りません。 使っているモデル、出力の長さ、ツールの呼び出し回数、作業そのものの複雑さでも変わります1。 ただ、チャットを切り替えず、コンテキストを圧縮せずに続けたときに減りが加速するのは、たしかな傾向としてあります。

1.1. 累積は指数関数ではなく、二乗で効く

1.1. 累積は指数関数ではなく、二乗で効く

このとき、よく「トークン消費が指数関数的に増える」と言われます。 実際の増え方は、指数関数ではありません。

1ターンごとに1,000トークンずつ会話が伸びるとします。 1ターン目の入力は1,000トークン、2ターン目は2,000トークン、3ターン目は3,000トークン。 100ターン目には100,000トークンを入力していることになります2。

累積の入力量は1,000×(1+2+…+100)で、5,050,000トークンです。 ターン数に対しておおむね二乗で増えていく形。 指数関数ほど極端ではないのに体感として「急に重くなった」と感じるのは、前半の傾きがゆるやかで、後半の1ターンが前半の10倍の入力を運んでいるからです。

2. AIが圧縮しているのは学習データであって、会話ではない

2. AIが圧縮しているのは学習データであって、会話ではない

ここで素朴な疑問が出てきます。 生成AIは、インターネット規模のテキストを学習しているはずです。 それだけの知識を扱えるのに、たかだか数万トークンのチャットで音を上げるのは、どうにも釣り合いが取れていない気がします3。

この違和感の正体は、学習データと会話履歴が、まったく別の場所に置かれていることにあります。

2.1. 学習データは重みに畳み込まれている

生成AIは、質問を受けるたびに学習データを検索しているわけではありません。 学習の段階で、大量のテキストから得られた傾向がweights（重み：パラメータの数値）に少しずつ書き込まれていきます。 学習が終われば、元のテキストはモデルの中に残っていません。

重みの数はあらかじめ決まっています。 何兆トークンを学習させても、モデルのファイルサイズは変わりません4。 膨大なデータが、固定サイズの数値の集まりへ畳み込まれている。

だから、モデルが「知っていること」を使うのにコストはほとんどかかりません。 すでに圧縮済みのものを、そのまま動かしているだけだからです。

2.2. 会話履歴は毎ターン渡し直される

一方、チャットの履歴はモデルの中に入りません。 あなたの1つ目の質問も、AIの1つ目の回答も、次のターンでは入力の一部として、また先頭から送られています5。

つまり、AIは会話を覚えているのではなく、毎回読み直しています。 context（コンテキスト：その推論で参照できる情報のまとまり）とは、記憶というより、毎回机の上に積み直される資料の束に近いものです。 束が厚くなれば、そのぶん読み込みが増えます。

こう考えると、さっきの利用枠の話は自然につながります。 前半の1ターンは薄い束を読んでいて、後半の1ターンは分厚い束を読んでいる。 作業の見た目は同じでも、運んでいる荷物の量が違うわけです。

3. 過去を一つの状態にまとめる道は、いちど試されて捨てられた

3. 過去を一つの状態にまとめる道は、いちど試されて捨てられた

それなら、会話履歴も学習データと同じように、固定サイズの何かへ圧縮してしまえばいいのではないか。 過去のやりとりをその都度まとめ直して、以後はそれだけを見る。 自然な発想ですし、実はこれ、Transformerが登場する前に試された道でもあります。

3.1. RNNの隠れ状態が忘れたもの

RNN（Recurrent Neural Network：再帰型ニューラルネットワーク）は、文章を先頭から1語ずつ読み込みながら、hidden state（隠れ状態：これまで読んだ内容を表す数値のまとまり）を更新していく仕組みです。 隠れ状態のサイズは固定です。 100語読んでも10,000語読んでも、持ち歩く状態の大きさは変わりません。

理屈のうえでは理想的に見えます。 どれだけ長い会話でも、コストは一定。

ただ、固定サイズに押し込むということは、新しい情報が入るたびに古い情報が薄まるということでもあります。 文章の冒頭で一度だけ出た固有名詞や数字が、後半では取り出せなくなる。 「長い依存関係を保てない」という問題として、長く研究の対象になっていました6。

3.2. Attentionは、古い情報を軽くする仕組みではない

Transformerが採ったのは、逆の方向です。 過去を無理に一つの状態へまとめるのをやめて、必要になったときに直接参照する。 それがAttention（アテンション：どの情報をどれだけ参照するかを計算する仕組み）です7。

ここはよく誤解されるところで、Attentionは「古い情報の重みを下げて、新しい情報の重みを上げる」仕組みではありません。 次の1トークンを生成するとき、過去のどのトークンが今の判断に効くかを、そのつど計算しています。 1万トークン前の一言でも、内容として効くなら強く参照されます。

冒頭で出した条件を最後まで守れるのは、この設計のおかげです。 そして同じ設計から、長い会話ほど参照対象が増え続けるという性質も出てきます。 忘れないことと、軽いことは、両立しませんでした。

4. 計算は再利用できても、参照対象は減らない

4. 計算は再利用できても、参照対象は減らない

とはいえ、毎ターンすべてをゼロから計算し直しているわけでもありません。 積み重なった地層のうち、下の方は前回と同じはずです8。

4.1. KVキャッシュとプロンプトキャッシュ

Transformerは、過去の各トークンについてKeyとValueと呼ばれる内部表現を計算します。 これを保存しておくのがKV cache（Key-Valueキャッシュ：計算済みの内部表現を取っておく仕組み）です。 新しいトークンを生成するときは、保存済みのKeyとValueを読みながら、新しい分だけを計算します。

同じ考え方は、ターンをまたいでも使えます。 1回目に送った内容と2回目の先頭部分が完全に一致するなら、そこは計算済みのものを使い回せる。 prompt caching（プロンプトキャッシュ）やprefix caching（プレフィックスキャッシュ）と呼ばれ、主要なAPIで提供されています9。 料金体系でも、キャッシュされた入力トークンは通常の入力より安く扱われることが多いです。

積み重なった部分は再利用できるのではないか、という直感は当たっています。 実際にその最適化は動いています。

4.2. compactやRAGが効いている場所は違う

では、なぜそれでも会話の圧縮が必要なのか。 キャッシュが効いても、10万トークンを参照できる状態そのものは維持しなければならないからです。

Attentionの計算は、参照対象が増えれば増えます。 課金上の入力トークン数も、キャッシュ済みの分が安くなるだけで、ゼロにはなりません。 計算を省くことと、読む量を減らすことは別の話。

/compactのような要約は、10万トークンを5,000トークンに書き換えて、参照対象そのものを減らします10。 RAG（Retrieval-Augmented Generation：必要な部分だけ検索して渡す方式）も、外部メモリも、サブエージェントに作業を切り出すのも、狙っている場所は同じです11。 どれも、Transformerが「過去を捨てない」と決めたことで引き受けた負担を、外側からどう軽くするかという工夫になっています。

会話が長くなると重くなるのは、実装の粗さではなく、忘れない設計を選んだことの裏側でした。 そう分かってしまうと、チャットを切り替えるという地味な操作の意味も変わってきます。 AIに何を残して何を捨てるかを、こちらが決めているわけです。

  1. Anthropicのヘルプでも、自動のコンテキスト管理が働くような長い会話は利用枠をより多く消費するため、上限に近づいたら新しい会話を始めるよう案内しています。 – How do usage and length limits work?
  2. Claude Codeのヘルプは、セッション内で最も速く膨らむのは会話履歴であり、過去のメッセージは新しいメッセージのたびに毎回送り直されると説明しています。 – Models, usage, and limits in Claude Code
  3. コンテキストウィンドウはモデルが一度に見られる情報量の上限で、システムプロンプト、読み込んだファイル、ツールの出力、会話履歴のすべてがここに収まります。 – Explore the context window
  4. Llama 3は15兆トークン以上のテキストで事前学習されましたが、公開されたモデル自体は80億パラメータと700億パラメータの2種類で、学習量が増えてもパラメータ数は設計時に決めた値のままです。 – Introducing Meta Llama 3
  5. Anthropicのプロンプトキャッシュの説明では、1回のリクエストが参照するのはツール定義、システムプロンプト、メッセージ列の全体とされていて、会話がまるごと毎回送られる前提になっています。 – Prompt caching
  6. Bengioらは1994年の論文で、捉えるべき依存関係の時間幅が長くなるほど勾配による学習が難しくなることを示し、効率的な学習と長期間の情報保持のあいだにトレードオフがあると指摘しました。 – Learning long-term dependencies with gradient descent is difficult
  7. 2017年の「Attention Is All You Need」は、再帰と畳み込みを完全に取り払い、アテンション機構だけで構成したTransformerを提案した論文です。 – Attention Is All You Need
  8. Anthropicの料金表では、キャッシュへの書き込みとキャッシュからの読み出しに、通常の入力トークン単価に対する別々の倍率が設定されています。 – Pricing – Claude Platform Docs
  9. OpenAIのAPIでは1,024トークン以上のプロンプトに対して自動でキャッシュが働き、直前と同じプレフィックスを処理したサーバーへリクエストを振り分けることで再利用しています。 – Prompt caching | OpenAI API
  10. APIのコンパクション機能では、会話の要約ブロックを作ったあと、それより前のコンテンツブロックをすべて破棄して要約から会話を続けます。 – Compaction – Claude Platform Docs
  11. 2020年のRAGの論文は、パラメータに畳み込まれた知識と、外部から検索して持ってくる知識を組み合わせる枠組みとして提案されました。 – Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks