Google の SLEEP フレームワークとエージェントの記憶ファイル: 重みはコンテキスト税をなくすが、アドレスも消す

Google Research は 10 月 27 日、sleep と呼ぶフレームワークについての記事を公開しました (動詞と区別するため、ここでは SLEEP と書きます)。見出しの主張はすぐに広まりました。デプロイ後も学習を続け、1,000 万トークンまでの長文脈ベンチマークでほぼ満点を取り、見た情報を自分の重みに移すことでそれを実現するモデルです。ただ、背後にある論文はこのニュースより古いものです。6 月から arXiv に掲載されており、コメント欄によればある版は 2025 年 9 月から OpenReview で公開されています。新しいのはブログ記事のほうです。今週のブレイクスルーとして扱う前に知っておくべき事実ですが、切り捨てる理由にはなりません。エージェントの記憶を作っている人に向けて、これはよい問いを投げかけています。

モデルがコンテキストをパラメータに変えられるなら、なぜメモを残すのでしょうか。今月はじめ、エージェントの記憶を Markdown ファイルに移すと読める記憶が手に入るものの、読めることは最新であること、参照されること、合意されていることとは別物だと論じました。重みの記憶は逆の方向に進みます。読めること自体を手放す代わりに、ファイルでは解決できない問題を二つ解決します。私の見立てでは、このトレードオフはエージェントが知っていることの一部には正しく、残りには誤りです。そして両者の境界は、サイズや速度とは関係ありません。一つのものを指し示して取り除く必要が今後あるかどうかで決まります。

Google の SLEEP フレームワークが重みに対して行うこと

仕組みは、神経科学の用語から想像するより具体的です。著者自身もそう書いています。

our framework operates entirely within a fixed model architecture and human-defined training rules.

モデルが起きている間、新しい情報は高速な部品に置かれます。コンテキストに対する attention と、すばやく更新される高頻度の MLP ブロックです。睡眠はモデルが何かに気づいて始まるわけではありません。一定ステップごとに、スケジュールで実行されます。実行されると、モデルは自分を教師としてデータセットをサンプリングし、次の遅いブロックに新しい低ランクエキスパートを追加し、生徒が教師の出力を再現できるまでそのエキスパートを蒸留で学習させます。ブログはこれを knowledge seeding と呼んでいます。その後、速いブロック自身のベース重みが更新され、過去の睡眠で蓄積したエキスパートがリセットされ、一段上の新しいエキスパートが有効になります。

第二段階の「夢」が自己改善を担います。各ルーターはドメインを混ぜるためにランダムなエキスパートも追加で発火させ、モデルは合成の練習サンプルを生成し、サンプルは勾配ベースの重要度スコアで選別されます。上位のものが残り、多様性のためにランダムなものもいくつか加わります。残した夢ごとにモデルの独立したコピーをファインチューニングし、そのコピーが下流タスクで改善した場合にだけ夢に報酬が与えられます。論文の知識取り込みのアブレーションでは、ベースモデルが 31.9、手法全体が 48.9、夢なしの手法が 35.7 でした。少なくともこの実験では、差の大部分を夢が生んでいます。

数字はすべて著者自身のものです。満州語とカラマン語から英語への継続翻訳では、SLEEP は段階をまたいでもほとんど低下しないのに対し、in-context learning や単純なファインチューニングは大きく忘れます。BABILong では 1,000 万トークンまでほぼ満点ですが、そのグラフの小型モデル (SLEEP と Titans) はベンチマークでファインチューニングされており、GPT-4 はゼロショットで評価されています。事実の取り込みでは二つの設定でそれぞれ 48.9% と 46.2% を記録し、一つ目では SEAL を約 2 ポイント上回ります。Qwen3-8B で AIME 24、AIME 25、HMMT 25 がそれぞれ 79.2%、69.0%、46.1% です。ベースモデルは 1B から 8B パラメータです。コードへのリンクはなく、SLEEP 自体の限界を論じる節もなく、睡眠 1 サイクルの絶対的なコストも示されていません。効率に関する付録によれば、同じステップ数では単純なファインチューニングのほうが 4 倍効率がよく、単純なファインチューニングが三つの推論ベンチマークで SLEEP に追いつくには 3.6〜4.8 倍の実時間が必要です。結果は十分に成り立つかもしれません。ただ、現時点の情報源には独立した再現がなく、公開から数か月の論文の多くはその段階にあります。

重みの記憶が解決し、エージェントの記憶ファイルでは解決できないこと

二つあり、どちらも軽く扱うべきではありません。

一つ目はコンテキスト税です。テキストとして持つ記憶は、使うたびにコンテキストウィンドウへ読み込み直す必要があります。セッションごとに、そのセッションがその大半を必要としたかどうかに関係なく、コストが発生します。Claude Code は起動時に記憶インデックスの先頭 200 行または 25KB だけを読み込みます。メモを読み込むハーネスはどれも、保持する量とコンテキストで消費する量の間で同じトレードオフをしています。これは呼ばないツールに払うトークン税と同じもので、スキーマの代わりに事実に払っているだけです。重みに入った事実は、呼び出しごとのコンテキストトークンを消費しません。コストはパラメータと学習に移りますが、エージェントが覚えている量に比例して増えることはなくなります。

二つ目は、誰も開かなかったファイルです。ファイルの記憶では、エージェントは 1 行の説明をタスクと照らし合わせて、どの文書を読むかを決めます。その判断が外れるとファイルは閉じたままで、それはどこにも記録されません。重みはこのループからエージェントの判断を取り除きます。失敗そのものが完全になくなるわけではありません。正しいエキスパートを発火させないルーターや、事実を持っているのに使わないモデルは、一段下にある閉じたファイルです。それでも、エージェントが見に行くことを思いついたかどうかに依存する手順はなくなります。

エージェントの記憶にはアドレスが必要で、重みにはそれがない

オペレーターが記憶に対して行うことは、すべて目的語を持つ動詞です。このエントリを読む。先週と差分を取る。その変更を戻す。この人が忘れてほしいと頼んだものを削除する。このメモは Web ページから来て指示のように読めるので、保存される前に拒否する。どれも指し示す対象が必要です。ファイルの記憶にはいたるところにアドレスがあり、私が「読める」と言ったことの大半はこの点でした。

統合された事実にはアドレスがありません。SLEEP では、ファイルが何かを保存するという意味でどこかに保存されているわけではありません。低ランク更新の中の一つの方向であり、たまたまそれを含んでいたサンプルを生徒が模倣することで学習され、そのサンプルが含んでいた他のすべてと混ざっています。モデルに尋ねて、何が返ってくるかを見ることはできます。一覧にすることはできず、答えにそれが含まれなくなったとしても、消えた証明にはなりません。以前のエッセイで最も紙幅を割いた問題である古くなった記憶も、同じ理由でここではさらに悪化します。ファイルは少なくとも最後に書かれた時点を記録しますが、重み行列の中の方向には、別途記録しておかない限り、そのためのフィールドがありません。

SLEEP のロールバック単位は一晩ではなくチェックポイント

このアーキテクチャには操作できる単位が一つ残っていると読みたくなります。新しい知識は新たに追加された低ランクエキスパートに入り、ブログによれば古いパラメータを乱さずにそこへ保存されます。それなら昨夜の統合は一つのブロックであり、悪い夜はアダプタを外すように捨てられるはずです。

論文自身の更新順序は、そうではないことを示しています。睡眠の 1 ステップは三つのことを同時に行います。知識を渡す側の速いブロックのベース重みを更新し、そのブロックが過去の睡眠で蓄積した低ランクエキスパートをリセットし、一段上の新しいエキスパートを有効にします。新しいエキスパートを捨てれば統合された内容は消えますが、速いブロックは重みが変わったまま、以前持っていたエキスパートも失った状態で残ります。そのうえで夢がすべての上に学習を重ねます。一晩を取り消すために取り出せる部分は、モデルのどこにもありません。論文はロールバックを論じていないので、これは更新ルールについての私の読みですが、成り立つと考えています。

戻れる先はチェックポイント、つまり以前の状態全体を保存したコピーです。そして階層構造のせいで、チェックポイントが唯一残る境界になります。遅いレベルへの統合はそのたびに、過去の複数の睡眠が速いレベルに入れたものをまとめ、個別の断片としては消してしまいます。稼働中のモデルでは、二つの過去の睡眠の間の境界は、両方が一段上に移った時点で消えています。月曜のチェックポイントにはまだ残っています。Git に履歴を持つファイルの記憶なら、古い変更はどれも識別でき、確認でき、戻すこともできます。一つを戻すには、その後の編集を順にたどる必要があるとしてもです。

そして、単位が一つの事実になることは決してありません。月曜に戻ることはできます。ユーザーが忘れてほしいと頼んだ一文だけを取り除き、それ以降のすべてを残すことはできません。machine unlearning は実在する研究分野で、model editing は特定の関連付けをその場で変えられますが、どちらもこうしたモデルについて特定の事実が消えたことを証明はしませんし、SLEEP はそのどちらも提供していません。

SLEEP が何を重みに統合するかを誰が決めるのか

以前のエッセイでは、文書としての記憶の弱点は書き込みにあると論じました。読み込みはハーネスが強制しますが、保存はエージェントへの指示にすぎず、プロンプトは不変条件ではありません。

SLEEP は判断そのものをなくすことで、この穴を塞ぎます。睡眠はステップ数で実行され、統合用のデータセットはモデルが今持っているものからサンプリングされ、パイプライン内の唯一の選別は夢の中にあって、そこではサンプルが性能にどれだけ役立つかで残されます。それが真実か、誰のものか、どこから来たかを問う部分はどこにもありません。良識をもって使うようエージェントに求める記憶ツールより正直ではあります。判断しているふりすらしないからです。同時に、実際の入力で運用する人にとっては、これが設計の最も弱い点です。

保存されるべきではなかったメモを考えてみてください。ファイルの記憶では、保存されたメモに入り込んだインジェクションは、少なくとも 1 行です。数週間後にエージェント自身の言葉としての権限を帯びて戻ってくるのは悪いことですが、grep して削除できます。重みの記憶では、覚醒中にコンテキストにあったテキストが速い重みを形づくり、統合用のデータセットはその重みが形づくったモデルからサンプリングされます。あるインジェクションが遅いブロックまで生き残るかどうかは実験で確かめるべき問いで、論文は検証していません。生き残るなら、grep できる行はありません。モデルに質問して、正しい質問に当たることを祈るしかありません。

エージェントの記憶の設計: 記録からコンパイルするキャッシュとしての重み

前回の私の答えは、履歴を保つ記録とその上の読めるビューでした。重みも同じ分け方に収まります。同じ記録に対する二つ目のビューとしてです。そしてこの分け方が、重みの記憶をそもそも安全に運用できるかどうかを決めます。

まず記録を残します。覚醒中にコンテキストに入ったものすべてを、アドレスと日付つきで、統合された後も保管します。この記録は、拒否すべきメモを拒否できる唯一の場所でもあります。フィルタリングは、テキストが、学習が行われるセッションに届く前に行う必要があります。届いた後では、モデルの重みはすでに変わっているからです。次に、重みを記録とチェックポイントからコンパイルしたキャッシュとして扱います。1 行を削除するには、記録からその行を取り除き、その行が入る前に保存したチェックポイントから覚醒、睡眠、夢を再実行します。結果は「元のモデルから事実を一つ引いたもの」にはなりません。サンプリングもランダムなエキスパートも実行のたびに異なるからです。保証されるのはもっと狭く、もっと役に立つことです。その行は一度も入らなかった、ということです。

この再実行のコストを決めるのは、チェックポイントの頻度ではなく、その行の古さです。昨日のことを忘れるには 1 日分を再実行します。去年の春のことを忘れるには、去年の春以降のすべてを再実行します。記憶が古いほど取り除くコストは高くなり、古い行も新しい行と同じ安さで削除できるファイルとは正反対です。蒸留が済んだ時点で入力を捨てた統合には再実行の手段がなく、その誤りはせいぜい修正できるだけで、取り除くことはできません。

境界を決めるのはこのコスト曲線です。一つずつ取り除く必要のないものは重みに入れます。社内の文体、ある分野での慣れ、ゆっくりとしか変わらないコードベースの形です。持ち主から削除を求められうるもの、あるいは期限切れになりうる真実は記録として残します。人についての事実、決定とそれを下した人、外部から未確認のまま入ってきたものすべてです。

SLEEP は現実の問題に対する真剣な試みであり、数字が著者の研究室の外でも成り立てば、エージェントの記憶にかかるコストを変えるでしょう。オペレーターが記憶に求めるものは変わりません。働きながら学ぶモデルは、学ぶべきでないことをいずれ学びます。それが何かを突き止める手段が記録です。