Googles SLEEP-Framework vs. Speicherdateien für Agenten: Gewichte streichen die Kontextsteuer und mit ihr die Adresse

Google Research hat am 27. Oktober einen Beitrag über ein Framework veröffentlicht, das es sleep nennt (ich schreibe es SLEEP, damit es sich vom Verb abhebt), und die zentralen Zahlen haben sich schnell verbreitet: ein Modell, das nach dem Deployment weiterlernt, auf einem Long-Context-Benchmark bis 10 Millionen Tokens fast perfekt abschneidet und das schafft, indem es das Gesehene in die eigenen Gewichte verschiebt. Das Paper dahinter ist älter als die Nachricht. Es liegt seit Juni auf arXiv, und laut seiner Kommentarzeile ist eine Fassung seit September 2025 auf OpenReview öffentlich. Neu ist der Blogpost. Das sollte man wissen, bevor man es als Durchbruch dieser Woche behandelt, und es ist kein Grund, es abzutun. Die Frage, die es allen stellt, die Speicher für Agenten bauen, ist berechtigt.

Wenn ein Modell Kontext in Parameter verwandeln kann, wozu dann überhaupt Notizen? Anfang des Monats habe ich argumentiert, dass Agentenspeicher in Markdown-Dateien einen Speicher bringt, den man lesen kann, und dass lesbar nicht dasselbe ist wie aktuell, konsultiert oder abgestimmt. Gewichtsspeicher geht den umgekehrten Weg. Er gibt Lesbarkeit komplett auf und löst dafür zwei Probleme, die Dateien nicht lösen können. Meine Lesart: Der Tausch ist für einen Teil dessen, was ein Agent weiß, richtig und für den Rest falsch, und die Grenze zwischen beiden hat nichts mit Größe oder Geschwindigkeit zu tun. Es geht darum, ob du jemals auf eine einzelne Sache zeigen und sie entfernen musst.

Was Googles SLEEP-Framework mit den Gewichten macht

Der Mechanismus ist konkreter, als das Vokabular aus der Neurowissenschaft vermuten lässt, und die Autoren sagen das selbst:

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

Solange das Modell wach ist, liegt neue Information in seinen schnellen Komponenten: Attention über den Kontext plus hochfrequente MLP-Blöcke, die sich schnell aktualisieren. Schlaf wird durch nichts ausgelöst, was das Modell bemerkt. Er läuft nach Plan, alle so und so viele Schritte. Wenn er läuft, sampelt das Modell einen Datensatz aus sich selbst als Lehrer, fügt dem nächsten, langsameren Block einen neuen Low-Rank-Experten hinzu und trainiert diesen Experten per Destillation, bis der Schüler reproduziert, was der Lehrer gesagt hätte. Der Blog nennt das Knowledge Seeding. Danach werden die Basisgewichte des schnelleren Blocks aktualisiert, die Experten, die er aus früheren Schlafphasen angesammelt hatte, zurückgesetzt, und der neue Experte eine Ebene höher wird eingeschaltet.

Die zweite Stufe, das Träumen, ist der Ort der Selbstverbesserung. Jeder Router aktiviert zusätzlich einen zufälligen Experten, um Domänen zu mischen, das Modell erzeugt synthetische Übungsbeispiele, und die Beispiele werden nach einem gradientenbasierten Wichtigkeitswert gefiltert: Die besten bleiben, dazu ein paar zufällige für Vielfalt. Mit jedem behaltenen Traum wird eine isolierte Kopie des Modells feingetunt, und belohnt wird der Traum nur, wenn diese Kopie danach besser abschneidet. In der Ablation zur Wissensaufnahme kommt das Basismodell auf 31,9, die volle Methode auf 48,9, die Methode ohne Träumen auf 35,7. Zumindest in diesem Experiment trägt das Träumen den Großteil des Vorsprungs.

Die Zahlen stammen von den Autoren selbst. Kaum Leistungsverlust von Stufe zu Stufe bei kontinuierlicher Übersetzung aus dem Mandschurischen und dem Kalamang ins Englische, wo In-Context-Learning und schlichtes Fine-Tuning stark vergessen. Fast perfekte BABILong-Werte bis 10M Tokens, wobei die kleinen Modelle in diesem Diagramm, nämlich SLEEP und Titans, auf den Benchmark feingetunt wurden, GPT-4 dagegen zero-shot bewertet wurde. 48,9 % und 46,2 % in zwei Settings zur Aufnahme von Fakten, im ersten etwa zwei Punkte vor SEAL. 79,2 %, 69,0 % und 46,1 % auf AIME 24, AIME 25 und HMMT 25 mit Qwen3-8B. Die Basismodelle reichen von 1B bis 8B Parametern. Es gibt keinen Code-Link, keinen Abschnitt zu den Grenzen von SLEEP selbst und keine absoluten Kosten für einen Schlafzyklus. Der Effizienz-Anhang berichtet, dass schlichtes Fine-Tuning bei gleicher Schrittzahl viermal effizienter ist und das 3,6- bis 4,8-Fache der Laufzeit braucht, um SLEEP auf den drei Reasoning-Benchmarks einzuholen. Die Ergebnisse mögen durchaus Bestand haben. Die Quellen bieten nur noch keine unabhängige Replikation, und da stehen die meisten Paper in ihren ersten Monaten.

Was Gewichtsspeicher löst und Speicherdateien für Agenten nicht

Zwei Dinge, und keines davon würde ich abtun.

Das erste ist die Kontextsteuer. Ein Speicher, der als Text vorliegt, muss zur Nutzung in das Fenster zurückgelesen werden, in jeder Sitzung, und die Rechnung fällt an, unabhängig davon, ob die Sitzung das meiste davon brauchte oder nicht. Claude Code lädt beim Start nur die ersten 200 Zeilen oder 25 KB seines Speicherindex, und jede Harness, die Notizen lädt, macht denselben Tausch zwischen dem, was sie mitführt, und dem, was sie ausgibt. Es ist die Token-Steuer auf Tools, die du nie aufrufst, bezahlt für Fakten statt für Schemas. Ein Fakt in den Gewichten kostet pro Aufruf keine Kontext-Tokens. Die Kosten wandern in Parameter und Training, aber sie wachsen nicht mehr mit der Menge dessen, was der Agent sich merkt.

Das zweite ist die Datei, die niemand geöffnet hat. Bei einem Dateispeicher entscheidet der Agent, welches Dokument er liest, indem er eine einzeilige Beschreibung mit der Aufgabe abgleicht, und wenn dieses Urteil danebenliegt, bleibt die Datei zu und nichts hält das fest. Gewichte nehmen die Entscheidung des Agenten aus dieser Schleife. Den Fehler selbst nehmen sie nicht ganz heraus: Ein Router, der den richtigen Experten nicht aktiviert, oder ein Modell, das einen Fakt hat und ihn nicht nutzt, ist die geschlossene Datei eine Ebene tiefer. Aber kein Schritt hängt mehr davon ab, dass der Agent daran gedacht hat, nachzusehen.

Agentenspeicher braucht eine Adresse, und Gewichte haben keine

Alles, was ein Operator mit einem Speicher macht, ist ein Verb mit einem Objekt. Lies diesen Eintrag. Vergleiche ihn mit dem Stand von letzter Woche. Mach diese Änderung rückgängig. Lösche, was diese Person gelöscht haben möchte. Lehne diese Notiz ab, bevor sie gespeichert wird, weil sie von einer Webseite kam und sich wie eine Anweisung liest. Jedes davon braucht etwas, auf das man zeigen kann. Ein Dateispeicher hat überall Adressen, und das war der größte Teil dessen, was ich mit lesbar meinte.

Ein konsolidierter Fakt hat keine Adresse. In SLEEP ist er nicht irgendwo gespeichert in dem Sinn, in dem eine Datei etwas speichert. Er ist eine Richtung in einem Low-Rank-Update, gelernt, indem der Schüler Beispiele imitiert, die ihn zufällig enthielten, und vermischt mit allem anderen, was diese Beispiele enthielten. Du kannst das Modell danach fragen und sehen, was zurückkommt. Auflisten kannst du ihn nicht, und eine Antwort, die ihn nicht mehr enthält, beweist nicht, dass er weg ist. Veraltete Einträge, das Problem, dem ich im früheren Essay den meisten Platz gegeben habe, werden hier aus demselben Grund schlimmer: Eine Datei hält wenigstens fest, wann sie zuletzt geschrieben wurde, und eine Richtung in einer Gewichtsmatrix hat dafür kein Feld, außer du führst eines daneben.

Die Rollback-Einheit in SLEEP ist ein Checkpoint, keine Nacht

Es liegt nahe, die Architektur so zu lesen, als bliebe ein Ansatzpunkt übrig. Neues Wissen landet in einem neu hinzugefügten Low-Rank-Experten, und laut Blog wird es dort gespeichert, ohne ältere Parameter zu stören. Dann wäre die Konsolidierung der letzten Nacht doch ein Block, und eine schlechte Nacht ließe sich verwerfen, so wie man einen Adapter entlädt.

Die Update-Reihenfolge im Paper selbst sagt etwas anderes. Ein Schlafschritt macht drei Dinge zusammen: Er aktualisiert die Basisgewichte des schnelleren Blocks, der Wissen weitergibt, er setzt die Low-Rank-Experten zurück, die dieser Block aus früheren Schlafphasen angesammelt hatte, und er aktiviert den neuen Experten eine Ebene höher. Wirfst du den neuen Experten weg, entfernst du, was konsolidiert wurde, und lässt den schnelleren Block mit veränderten Gewichten und ohne die Experten zurück, die er vorher hatte. Das Träumen trainiert dann auf all dem weiter. Es gibt kein Stück des Modells, das du herausnehmen kannst, um eine Nacht ungeschehen zu machen. Das Paper behandelt Rollback nicht, also ist das meine Lesart seiner Update-Regel, und ich glaube, sie hält.

Zurückrollen kannst du auf einen Checkpoint, eine gespeicherte Kopie des gesamten Zustands von vorher. Und die Hierarchie macht Checkpoints zur einzigen Grenze, die übrig bleibt. Jede Konsolidierung in eine langsamere Ebene führt zusammen, was mehrere frühere Schlafphasen in die schnellere gelegt haben, und danach gibt es sie nicht mehr als einzelne Stücke. Im laufenden Modell ist die Linie zwischen zwei früheren Schlafphasen verschwunden, sobald beide eine Ebene höher gewandert sind. Ein Checkpoint vom Montag hat sie noch. Ein Dateispeicher mit Historie in Git hält jede alte Änderung identifizierbar und einsehbar, auch wenn ihr Rückgängigmachen heißt, sich durch die Änderungen danach zu arbeiten.

Und keine Einheit ist je ein Fakt. Du kannst zum Montag zurück. Du kannst nicht einen einzelnen Satz entfernen, den ein Nutzer gelöscht haben wollte, und alles danach behalten. Machine Unlearning ist ein echtes Forschungsfeld, und Model Editing kann eine bestimmte Assoziation an Ort und Stelle ändern, aber keines von beiden beweist für ein Modell wie dieses, dass ein bestimmter Fakt weg ist, und SLEEP bietet keines von beiden.

Wer entscheidet, was SLEEP in die Gewichte konsolidiert

In meinem früheren Essay war die Schwachstelle eines Dokumentenspeichers das Schreiben. Das Laden erzwingt die Harness, aber das Speichern ist eine Anweisung an den Agenten, und ein Prompt ist keine Invariante.

SLEEP schließt diese Lücke, indem es die Entscheidung abschafft. Schlaf läuft nach Schrittzahl, der Konsolidierungsdatensatz wird aus dem gesampelt, was das Modell gerade enthält, und die einzige Auswahl in der Pipeline steckt im Träumen, wo Beispiele danach behalten werden, wie sehr sie der Leistung helfen. Nichts darin fragt, ob etwas wahr ist, wem es gehört oder woher es kam. Das ist ehrlicher als ein Speicher-Tool, das der Agent mit gutem Urteilsvermögen benutzen soll, denn es gibt gar nicht erst vor, zu urteilen. Es ist aber auch die schwächste Stelle des Designs für alle, die es mit echten Eingaben betreiben.

Denk an die Notiz, die nie hätte gespeichert werden dürfen. In einem Dateispeicher ist eine Injection, die in einer gespeicherten Notiz landet, wenigstens eine Zeile. Sie kommt Wochen später mit dem Rang der eigenen Worte des Agenten zurück, was schlimm ist, aber du kannst danach greppen und sie löschen. In einem Gewichtsspeicher formt Text, der während der Wachphase im Kontext lag, die schnellen Gewichte, und der Konsolidierungsdatensatz wird aus einem Modell gesampelt, das von diesen Gewichten geprägt ist. Ob eine bestimmte Injection bis in die langsameren Blöcke überlebt, ist eine empirische Frage, die das Paper nicht testet. Wenn ja, gibt es keine Zeile zum Greppen. Du kannst dem Modell nur Fragen stellen und hoffen, dass du die richtige erwischst.

Agentenspeicher-Design: Gewichte als Cache, kompiliert aus einem Protokoll

Meine Antwort beim letzten Mal war ein Protokoll, das seine Historie behält, mit einer lesbaren Sicht obendrauf. Gewichte passen in dieselbe Aufteilung, als zweite Sicht auf dasselbe Protokoll, und die Aufteilung entscheidet, ob sich ein Gewichtsspeicher überhaupt sicher betreiben lässt.

Zuerst das Protokoll: alles, was während der Wachphase in den Kontext kam, mit Adresse und Datum, auch nach der Konsolidierung aufbewahrt. Dieses Protokoll ist auch der einzige Ort, an dem die abzulehnende Notiz abgelehnt werden kann. Gefiltert werden muss, bevor Text eine Sitzung erreicht, die lernt, denn danach hat sich das Modell schon bewegt. Dann behandelst du die Gewichte als Cache, kompiliert aus dem Protokoll und einem Checkpoint. Um eine Zeile zu löschen, nimmst du sie aus dem Protokoll und spielst Wachphase, Schlaf und Träumen von einem Checkpoint aus neu ab, der gespeichert wurde, bevor die Zeile hineinkam. Das Ergebnis ist nicht dasselbe Modell minus ein Fakt, denn Sampling und zufällige Experten unterscheiden sich bei jedem Lauf. Was es garantiert, ist enger und nützlicher: Diese Zeile ist nie hineingekommen.

Die Kosten dieses Neuabspielens bestimmt das Alter der Zeile, nicht die Häufigkeit deiner Checkpoints. Gestern zu vergessen heißt, einen Tag neu abzuspielen. Etwas vom letzten Frühjahr zu vergessen heißt, alles seit dem letzten Frühjahr neu abzuspielen. Je älter eine Erinnerung, desto teurer ist es, sie zu entfernen, und das ist das Gegenteil einer Datei, in der eine alte Zeile so billig zu löschen ist wie eine neue. Eine Konsolidierung, deren Eingaben weggeworfen wurden, sobald sie destilliert waren, lässt sich gar nicht neu abspielen, und ihre Fehler lassen sich bestenfalls flicken, nie entfernen.

Diese Kostenkurve zieht die Grenze. In die Gewichte gehört, was du nicht Stück für Stück entfernen musst: ein Hausstil, Routine in einer Domäne, die Form einer Codebasis, die sich langsam ändert. Als Protokoll behältst du alles, was einen Besitzer hat, der es zurückfordern kann, oder nur auf Zeit stimmt: Fakten über Menschen, Entscheidungen und wer sie getroffen hat, und alles, was ungeprüft von außen kam.

SLEEP ist ein ernsthafter Versuch, ein echtes Problem zu lösen, und wenn sich die Zahlen außerhalb des Labors der Autoren bestätigen, wird es verändern, was Agentenspeicher kostet. Was ein Operator von einem Speicher braucht, bleibt gleich. Ein Modell, das beim Arbeiten lernt, wird etwas lernen, was es nicht soll, und das Protokoll ist der Weg, herauszufinden, was.