Aktualisiert am 3. November 2026 (Fassung 9). Fassung 9 des Papers (Zenodo, DOI 10.5281/zenodo.23832288) zählt die Eingabe-Tokens über den ganzen Antwort-Prompt, Vorlage und Frage eingeschlossen: 963,2 gegen 105.669,0 je Frage, ein Verhältnis von 1/109,7 (nur über den Historienblock gezählt, waren es 109,6). Das Vergleichsergebnis steht jetzt so, wie Fassung 9 es sagt: Gegen Letta und Mem0 zeigen die sechs Vergleiche keinen signifikanten Unterschied. Text, Tabelle und Rechnung tragen diese Formen; die Vermerke darunter behalten ihr Datum.
Berichtigt am 18. Oktober 2026. Den Vergleichsarm nannten wir bisher „Long-Context-Oracle“ und das Verhältnis „Token-Budget“. Beides war ungenau. In LongMemEval heißt „oracle“ die Bedingung, in der das Modell nur die Evidenz-Sitzungen sieht; unser Vergleichsarm liest die ganze Historie. Und gezählt sind nur die Eingabe-Tokens im Antwortschritt, nicht der Aufbau des Gedächtnisses. Text, Tabelle und Rechnung tragen jetzt diese Formen.
Nachgemessen am 15. September 2026. Die gedruckten Vergleichszahlen gegen Letta und Mem0 stammen aus einem Lauf mit zwei Fehlern auf unserer Seite, in den Adaptern dieser Systeme: Der Letta-Adapter ließ 59 der 500 Aufgaben unbedient, und bei Mem0 griff die Trennung je Frage nicht. Mit reparierten Adaptern und versionsgleichen Judges gilt: drei der neun Vergleiche halten, alle gegen A-Mem und signifikant; die sechs gegen Letta und Mem0 sind Gleichstände am Kriterium des Papiers, verloren ist keiner. Das Token-Verhältnis lautet 109,6-fach, nicht die gedruckten 106 — die alte Zahl kam aus einer Tausender-Konstante im Zeichenskript, nicht aus einer Messung. Beide Korrekturen sind unten eingearbeitet. Belege: Korrektur-Notiz, DOI 10.5281/zenodo.22831087.
Berichtigt am 11. Oktober 2026. Tabelle, Vergleichsabschnitt und Reproduzierbarkeit trugen die Korrekturen entgegen dem Satz oben noch nicht; jetzt tragen sie sie. Laut derselben Notiz ist der gemessene Arm ein Python-Nachbau, nicht ein Import der npm-Pakete. Die Angabe zur TripleCopy-Stärke nach 30 Tagen ist gestrichen; sie rechnete aus den gedruckten Formeln nicht nach.
Ergänzt am 9. Oktober 2026. Die Mechanismen-Zahlen weiter unten stammen aus der Simulation des Papers. Laut derselben Notiz erreichen unter Stress 10 von 15 Komponenten das gedruckte Kriterium (neun mit Verlust, PriorityMap mit Gewinn), und der einzige Lauf der Schlafschleife auf echten Daten zeigte einen Verlust an Abrufpräzision. Beides ist unten eingearbeitet.
Es gibt einen Satz zum ZenBrain-Paper, den ich auswendig kann, in seiner berichtigten Fassung:
Der gemessene ZenBrain-Arm erreicht 91,3 % der Genauigkeit eines Full-Context-Vergleichsarms (dessen Antwortmodell die ganze Historie liest) mit 1/109,7 von dessen Eingabe-Tokens im Antwortschritt.
Das ist der Satz, der entscheidet, ob es sich überhaupt lohnt, eine Memory-Architektur zu bauen — oder ob wir einfach jedes Mal das volle Konversationsarchiv ins Context-Window kippen sollten und hoffen, dass das LLM das Richtige tut.
Spoiler: Im Antwortschritt lohnt es sich deutlich.
Was der Full-Context-Vergleichsarm ist
LongMemEval-S Full-500 ist ein Memory-Benchmark mit 500 Fragen, und jede Frage ist ihrem eigenen Konversations-Kontext zugeordnet — etwa 494 Gesprächs-Turns pro Frage, im Schnitt 105 577 Tokens (Median 105 744, Maximum 107 740). Es geht über sechs Kategorien: multi-session, temporal-reasoning, knowledge-update, plus drei single-session-Varianten.
Der Full-Context-Vergleichsarm funktioniert so: Wir nehmen das gesamte Konversationsarchiv der jeweiligen Frage — alle 105 600 Tokens — und stopfen sie in das Context-Window von gpt-4o-mini. Kein Memory-System dazwischen, keine Retrieval-Filterung, kein Forgetting, keine Konsolidierung. Das Modell liest jedes Mal die volle Geschichte und beantwortet die Frage daraus.
Eine theoretische Obergrenze ist das nicht: Die Information ist vollständig da, aber zwischen viel, was mit der Frage nichts zu tun hat. In LongMemEval heißt die Bedingung, in der das Modell nur die Sitzungen mit der Evidenz sieht, „oracle“; dieser Arm ist etwas anderes.
Was ZenBrain stattdessen tut
Im Modell des Papers bekommt ZenBrain die gleichen 494 Turns einmal beim Ingest, sortiert sie durch die 7-Layer-Architektur (Working, Short-Term, Episodic, Semantic, Procedural, Core, Cross-Context), schreibt einen Knowledge Graph mit Two-Factor-Synapsen, konsolidiert im Leerlauf und vergisst auf Ebbinghaus-Kurve. Gemessen wurde laut Korrektur-Notiz ein Python-Nachbau, dessen Trefferlisten der reinen Kosinus-Suche gleichen. Die offene Bibliothek @zensation/core führt keinen Knowledge Graph und kein Schlaf-Replay aus; in ihrem Langzeitgedächtnis verfällt nichts von selbst. Bei der Abfrage retournieren wir die 5 relevantesten Memories (k = 5) — etwa 963 Tokens je Frage, gemessen an den tatsächlich gesendeten Prompts.
Das sind 1/109,7 der Eingabe-Tokens, die der Vergleichsarm im Antwortschritt bekommt.
Das Resultat (nach Paper und Korrektur-Notiz)
| System | Accuracy | Eingabe-Tokens im Antwortschritt |
|---|---|---|
| Full-Context-Vergleichsarm (gpt-4o-mini, ganze Historie) | 52,2 % | ~105 600 |
ZenBrain (k = 5) | 47,7 % | ~963 |
A-Mem (k = 5) | 35,4 % | nicht ausgewiesen |
Die gedruckten Werte für Letta und Mem0 und das Intervall für ZenBrain sind zurückgezogen (Korrektur-Notiz, Abschnitte 1 und 3); mit reparierten Adaptern liegen beide gleichauf mit ZenBrain.
Der gemessene Arm erreicht 47,7 / 52,2 = 91,3 % der Genauigkeit des Vergleichsarms. Der Vergleichsarm liegt 4,5 Prozentpunkte vorn. Sein Antwortmodell liest dafür 109,7-fach mehr Eingabe-Tokens je Frage.
Unter den k = 5-Memory-Systemen hält ZenBrain einen Vorsprung nur gegen A-Mem. Beim abgerufenen Kontext halten drei von neun Paarvergleichen, alle gegen A-Mem, unter allen drei LLM-Judges (Sonnet 4.5, Opus 4.6, GPT-4o) und Bonferroni-korrigiert. Gegen Letta und Mem0 zeigen die sechs übrigen Vergleiche keinen signifikanten Unterschied.
Was das praktisch heißt
Die Diskussion "Brauche ich überhaupt ein Memory-System, oder kann ich einfach das ganze Archiv ins Context-Window kippen?" hat eine quantitative Antwort.
Wer im Antwortschritt 109,7-mal mehr Eingabe-Tokens bezahlt, gewinnt 4,5 Prozentpunkte Genauigkeit. Bei einer Million Anfragen, einem typischen Preis von ~0,15 €/1M Input-Tokens für gpt-4o-mini und einer Historie von 105 600 Tokens je Anfrage:
- Vergleichsarm, Eingabe im Antwortschritt:
1 000 000 × 105 600 × 0,15 / 10⁶ = 15 840 € - ZenBrain, Eingabe im Antwortschritt (
k = 5, ~963 Tokens):1 000 000 × 963 × 0,15 / 10⁶ ≈ 144 €
15 696 € Differenz für 4,5 Prozentpunkte, je 1 Mio. Anfragen. Die Rechnung zählt nur den Antwortschritt: Der Aufbau des Gedächtnisses beim Ingest ist darin nicht enthalten.
Umgekehrt lässt sie die Latenz außen vor (ein 105 K-Token-Prompt braucht spürbar länger bis zum ersten Token als ein 1 K-Token-Prompt), und die Tatsache, dass der Vergleichsarm kein Memory-Konzept hat: Es kann nicht über Sessions hinweg lernen, und einzelne Erinnerungen lassen sich nicht gezielt löschen (in ZenBrain mit forget()).
Der Vergleichsarm ist ein Brute-Force-Werkzeug. ZenBrain ist eine Architektur.
Wo das Verhältnis herkommt
Das Paper führt die 91,3-%-Marke auf vier Mechanismen zurück. Die Korrektur-Notiz schränkt das ein: Gemessen wurde ein Python-Nachbau, dessen Trefferlisten ohne die zwei hashbasierten Mechanismen der reinen Kosinus-Suche gleichen. Ob die beschriebene Architektur sich so verhält, soll die registrierte Folgemessung klären. Die vier Mechanismen, wie das Paper sie beschreibt:
- Layer-Routing. Eine Frage mit zeitlichem Bezug wird vom Episodic-Layer-Boost (
w = 2,0) priorisiert; eine Verfahrensfrage geht an den Procedural-Layer; eine Identitäts-Frage trifft auf Core Memory direkt. Auf LoCoMo zeigt das Paper für das Layer-Routing +181 % auf temporal queries gegenüber Flat-Dense-Storage; laut Korrektur-Notiz stützt sich das auf einen von fünf Anfrage-Pools, zwei zeigen keinen Vorsprung. - Two-Factor Synaptic Consolidation. Edges im Knowledge Graph haben nicht nur ein Gewicht
w_ij, sondern auch eine Konsolidierungsvarianzσ²_ij. Reife Edges (σ² → 0) widerstehen sowohl Decay als auch katastrophalem Überschreiben — eine EWC-artige Strafe (Elastic Weight Consolidation), mit1/σ²als Ersatz für die Fisher-Information. Die WichtigkeitI_ij = 1/σ²_ijwird gleichzeitig als Retrieval-Boost genutzt. - Sleep-Consolidation. Im Leerlauf läuft die Simulation-Selection-Loop: Sie generiert Replay-Kandidaten aus echten Episoden + Counterfactuals, scored sie mit
TAG = 0,34·|δ_TD| + 0,30·R + 0,21·N + 0,15·E(E = emotionales Gewicht), stärkt Top-Kandidaten via LTP, prunt schwache via LTD. Resultat in der Simulation: +37 % Stabilität, −47,4 % Storage; auf echten Daten sank die Abrufpräzision. - Predictive Memory Architecture (PMA). Die Reconsolidation öffnet ein 10-Minuten-Fenster nach Retrieval, in dem Erinnerungen je nach Prediction-Error in einen von vier Modi übergehen (confirmed / selective_edit / integration / new_episode). TripleCopyMemory speichert jedes Ereignis dreifach mit divergenten Decay-Konstanten; mit dem Alter einer Erinnerung übernimmt die tiefe Kopie die Führung.
Im 15-Mechanismen-Ablation-Test des Papers, einer Simulation, gilt: Unter moderaten Bedingungen sind die meisten Algorithmen kooperativ-redundant — Sleep ist die einzige einzelne Komponente, die das gedruckte Kriterium erreicht. Unter Stress (60 Tage, decay = 0,25/Tag) erreichen 10 von 15 Komponenten das gedruckte Kriterium, neun mit einem Verlust (ΔQ bis −93,7 %) und PriorityMap mit einem Gewinn. Das ist kein Bug, sondern das Design: die Algorithmen bilden ein Cooperative Survival Network.
Die ehrliche Einordnung
Wir behaupten nicht, dass 91,3 % universell genug ist. Für sicherheitskritische Anwendungen (Diagnostik, Recht, Finanztransaktionen) sind die fehlenden 4,5 pp möglicherweise zu teuer — dann ist Long-Context die richtige Antwort, und der 109,7-fache Eingabe-Aufwand im Antwortschritt ist akzeptabel.
Für die übergroße Mehrheit der Knowledge-Work-Anwendungen — Personal Assistants, CRM, Forschungs-Agenten, Coding-Copiloten, Lernsysteme — ist k = 5 die wirtschaftlich richtige Wahl. Das ist exact die Regimezone, für die Memory-basierte Systeme erfunden wurden.
Und unter den Memory-Systemen hält ZenBrain auf LongMemEval-500 drei von neun Paarvergleichen, alle gegen A-Mem; die sechs gegen Letta und Mem0 zeigen keinen signifikanten Unterschied.
Mehr Memory ist nicht die Antwort. Bessere Memory ist.
Reproduzierbarkeit
Die Werte je Frage und ein Skript zum Nachrechnen liegen der Korrektur-Notiz bei. Die Genauigkeit von 47,7 % (gegenüber 52,2 % beim Full-Context-Vergleichsarm) rechnet sich aus drei echten End-to-End-Läufen exakt nach. Die frühere Angabe, die Ergebnisse lägen im Repo und die Pipeline sei deterministisch, ist zurückgezogen.
- Paper: Zenodo DOI 10.5281/zenodo.19353663
- Code: github.com/zensation-ai/zenbrain
- Offene Bibliothek (npm):
npm install @zensation/algorithms @zensation/core. Sie reproduziert die Benchmark-Zahlen nicht; gemessen wurde ein Python-Nachbau.