Agentic OS 技術スタックを下から読む 第7回：大半を、もっと軽い仕組みに置き換える ―― ハイブリッドという組み立て

前回まで、長い文脈を扱うときの工夫を見てきた。

そこでは、すべてをそのまま見るのではなく、見る範囲を制限したり、遠くを粗く扱ったり、保存する情報を減らしたりした。どれも目的は同じだった。長くなるほど重くなる計算と記憶を、どうにか抑えることだった。

ただし、それらは基本的には注意機構の中での工夫だった。

過去をキーとバリューとして持ち、いまのトークンがそれらを参照する。その枠組みは保ったまま、どこを見るか、どれだけ見るか、何を残すかを調整していた。

今回は、もう一歩進む。

注意の層そのものの大半を、別の軽い仕組みに置き換える。全注意を少し近似するのではなく、層の役割そのものを組み替える。

全注意は強いが、長文脈では高い

全注意の強さは、考え方としてはわかりやすい。

ある位置のトークンが、過去のすべてのトークンを見られる。遠くに出てきた名前、条件、約束、コード片、前提を、あとから直接参照できる。

この性質は強い。細かい照合に向いている。離れた場所にある情報同士を結びやすい。文章の前半で出た一点を、後半で正確に拾い直すような処理にも向いている。

だが、その強さには代償がある。

過去をすべて参照できるようにするには、過去の各トークンについて、参照用の情報を保存しておく必要がある。文脈が伸びれば、保存する量も伸びる。さらに、新しいトークンを処理するたびに、その長くなった過去を読む必要が出てくる。

つまり、長文脈では、全注意の強さがそのまま重さになる。

短い文脈では問題にならなかったものが、長い履歴を抱えると効いてくる。前回まで見てきた工夫は、この重さをどう減らすかという話だった。

過去を、固定サイズの状態に畳む

ここで、別の発想が出てくる。

過去をすべて保存するのではなく、過去を一つの状態に畳み込みながら進む。

新しいトークンが来る。モデルは、そのトークンと、これまで持っていた状態を使って、新しい状態を作る。次のトークンでは、その更新済みの状態をまた使う。こうして、一歩ずつ読み進める。

重要なのは、この状態の大きさが固定だということだ。

文脈が千トークンでも、一万トークンでも、持ち歩く状態の大きさは基本的に変わらない。過去のすべてのトークンを並べて持つのではなく、読み進めながら内部状態へ圧縮していく。

この形なら、文脈が伸びても、保存する量は増えにくい。読み出しも、毎回巨大な過去全体を相手にする必要がない。長い入力を流し込むときのコストを、かなり安定させやすい。

一トークンずつ状態を更新しながら読む、という発想自体は新しいものではない。昔からある。だが、昔のままでは、いまの大規模なモデルの中核を置き換えるには弱かった。

そこで、現代の大規模モデルで使えるように、状態の持ち方、更新の仕方、層としての組み込み方が鍛え直されている。そう考えるとわかりやすい。

ここで目指しているのは、過去をすべて棚に並べておくことではない。読みながら要点を内部に持ち替えていくことだ。

ただし、畳むと細部が薄れる

もちろん、うまい話だけではない。

固定サイズの状態に過去を畳むということは、どこかで情報を捨てているということでもある。文脈が長くなっても状態の大きさが増えないなら、すべての細部をそのまま保存しているわけではない。

これは、要約しながら本を読むのに似ている。

流れや主題は残る。何が重要だったかも、ある程度は残せる。だが、遠いページに一度だけ出てきた具体的な単語を、あとから一字一句正確に思い出すのは難しくなる。

全注意は違う。過去の各位置を、参照可能な形で残している。だから、遠くにある細部を直接引きに行ける。もちろんコストは高いが、そのぶん精密な長距離参照に強い。

固定サイズの状態に畳む方式では、この力が弱くなりやすい。

遠い過去の具体的な一点を、あとからピンポイントで取り出す。前に出た識別子をそのまま再利用する。長い文書の冒頭にあった条件を、終盤で正確に照合する。こうした処理では、畳み込みの途中で細部が薄れることがある。

ここでも、前回までと同じ構図が出てくる。

安くするためには、何かを近似する。今回近似しているのは、注意の見方だけではない。過去そのものの持ち方だ。

だから混ぜる

では、全部を固定サイズの状態に置き換えればよいのか。

そうはならない。

軽い仕組みには軽い仕組みのよさがある。だが、全注意には全注意のよさがある。特に、遠くの細部をそのまま参照する力は捨てにくい。

そこで、実際の設計では混ぜる。

多くの層は、固定サイズの状態で前に進む軽い仕組みにする。文脈が伸びてもコストが増えにくい層が、日常的な処理を担う。

そのうえで、数層おきに、全注意に近い重い層を挟む。

こうすると、すべての層で過去全体を見に行く必要はない。大半の層は安く進む。一方で、ときどき入る重い層が、遠くの情報を直接拾う役割を持つ。

これは、前に見た役割分担ともつながっている。

近くの情報は軽く扱う。遠くの情報は、必要なところで重く扱う。以前はこれを、注意の範囲やパターンの中で見ていた。今回はそれを、層の種類そのものの分担として見ることになる。

大半を軽くし、要所に重い層を残す。

この割合が、効率と参照力のつまみになる。

重い層を多く入れれば、細かい参照には強くなりやすい。そのかわり、長文脈での軽さは薄れる。重い層を減らせば、長く走らせやすくなる。そのかわり、遠くの一点を正確に引く力は落ちやすい。

ここには絶対的な正解はない。

何を重視するかで変わる。長いログを大量に読み流すのか。短めでも精密な照合をしたいのか。あるいは、その中間を狙うのか。構造の選び方は、用途と切り離せない。

軽い構造は、賢さの保証ではない

ここで注意したいことがある。

この種のハイブリッドな構造の主な狙いは、長い文脈を安く扱うことだ。つまり、効率の設計である。

同じ条件で、全注意のモデルをいつも性能で上回る、という話ではない。

全注意は重いが、強い。特に、過去を細かく参照する能力では、素直な強さがある。軽い構造は、その一部を別の形で近似する。だから、長文脈で扱える量やコストでは有利になり得るが、すべての能力で有利になるとは限らない。

もう一つ、実装上の事情もある。

いま広く使われている推論基盤は、長い時間をかけて全注意向けに最適化されてきた。計算の並べ方、メモリの使い方、専用の高速化手法、運用上の経験が積み上がっている。

一方、新しい構造は、理屈の上では軽くても、それを本当に速く動かすための実装がまだ育ちきっていない場合がある。

構造として筋がよいことと、現実の推論環境でいつも速いことは同じではない。モデルの形だけでなく、それを支える実装、ハードウェア、ソフトウェアの成熟度まで含めて、実際の速さは決まる。

だから、ここで見るべきなのは、単純な勝ち負けではない。

全注意を中心にした設計とは違う場所に、効率の可能性がある。その可能性を使うには、どの能力を残し、どこを近似し、どの実装で動かすかまで考える必要がある。

Agentic OS への含意

Agentic OS の視点から見ると、この話はかなり重要になる。

エージェントは、一回の質問に答えるだけではない。長く走る。ログを持つ。作業履歴を持つ。過去の判断、途中の失敗、ユーザーの好み、外部ツールの結果を抱えながら進む。

そのとき、文脈が伸びるたびに状態が増え続ける構造は重い。

固定サイズの状態に畳みながら進める仕組みは、ここで魅力的に見える。長い履歴を読ませても、内部で持ち歩く量が増えにくいからだ。長時間動くエージェントにとって、これは大きな性質になる。

だが、それだけでは足りない。

エージェントには、過去の具体的な決定を正確に引き直す場面がある。

以前ユーザーが何を許可したのか。どのファイルを変更したのか。どの設計を採用し、どれを捨てたのか。あるエラーに対して、前回どの対処を試したのか。

こうした情報は、雰囲気として残っていればよいものではない。正確に必要になる。

固定サイズの状態に畳む方式だけに頼ると、この精密さが不足することがある。長く走るほど、細部は内部状態の中で薄れやすい。

だから、二つの補い方が必要になる。

一つは、モデルの中に重い参照層を残すことだ。大半を軽くしても、要所で過去を直接見る層を持たせる。これにより、完全な圧縮だけに頼らない構造にする。

もう一つは、モデルの外に記憶と検索の仕組みを置くことだ。

過去の決定、作業ログ、文書、コード、会話履歴を外部に保存する。そして必要なときに検索して、現在の文脈へ戻す。これは、あとで扱う記憶や検索の層につながる。

つまり、モデル内部の構造をどう選ぶかは、それ単体では決まらない。

モデルがどこまで内部状態で持つのか。どこから外部記憶に任せるのか。検索で戻す情報はどれか。正確さが必要なものは、どの層で保証するのか。

これらは一つながりの設計になる。

ここまでで、モデル層を効率の側から一通り見てきた。

最初は、全注意の重さが問題だった。次に、長文脈でその重さをどう近似するかを見た。そして今回は、注意の層そのものの大半を軽い仕組みに置き換え、必要なところに重い層を残すという組み立てを見た。

繰り返しになるが、これは魔法ではない。

安くするには、何かを近似する。近似すれば、どこかに苦手が出る。だから、全部を一つの仕組みに任せるのではなく、役割を分ける。

次回は、少し視点を変える。

ここまでは、モデルの構造を効率の面から見てきた。次は、そもそも今のモデルがなぜこのような形になり、何をできるようになったのかを見る。構造をどう軽くするかではなく、能力がどう作られるのかへ進む。