Es gibt einen einzigen Satz aus dem ZenBrain-Paper, den ich auswendig kann:
ZenBrain reaches 91,3 % of long-context-oracle accuracy at 1/106ᵗʰ the per-query token budget.
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: es lohnt sich.
Was eine "Long-Context Oracle"-Baseline überhaupt 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.
Eine "Long-Context Oracle"-Baseline 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.
Das ist die theoretische Obergrenze. Mehr Information geht nicht — alles ist im Context.
Was ZenBrain stattdessen tut
ZenBrain bekommt 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, lässt nachts die Sleep-Consolidation laufen und vergisst auf Ebbinghaus-Kurve. Bei der Abfrage retournieren wir die 5 relevantesten Memories (k = 5) — etwa 1 000 Tokens inklusive Antwort-Prompt-Overhead.
Das sind 1/106 dessen, was das Oracle bekommt.
Das Resultat (Tabelle 8 im Paper)
| System | Accuracy (95 % CI) | Token-Budget pro Anfrage |
|---|---|---|
| Long-Context Oracle (gpt-4o-mini, voller Haystack) | 52,2 % | ~105 600 |
| ZenBrain (k = 5, 7-Layer Memory) | 47,7 % (47,4 – 47,8) | ~1 000 |
| Letta (k = 5) | 42,8 % | ~1 000 |
| A-Mem (k = 5) | 35,4 % | ~1 000 |
| Mem0 (k = 5) | 31,8 % | ~1 000 |
ZenBrain erreicht 47,7 / 52,2 = 91,3 % der Oracle-Accuracy. Das Oracle gewinnt um 4,5 Prozentpunkte. Es verbraucht dafür 106-fach mehr Tokens pro Frage.
Unter den k = 5-Memory-Systemen, die alle dasselbe Token-Budget haben, dominiert ZenBrain:
- +4,9 pp gegenüber Letta
- +12,3 pp gegenüber A-Mem
- +15,9 pp gegenüber Mem0
Diese drei Lücken sind statistisch belastbar (Bonferroni-korrigiert p ≤ 6,2 × 10⁻³¹ über drei unabhängige LLM-Judges: Sonnet 4.5, Opus 4.7, GPT-4o; Effektgrößen d ∈ [0,18; 0,52]). Es ist nicht eine Frage des Glücks oder der Seed-Wahl: ZenBrain gewinnt 12 von 12 Head-to-Head-Vergleichen über alle Judges hinweg.
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.
Wenn du bereit bist, 106-mal mehr Tokens pro Anfrage zu zahlen, gewinnst du 4,5 Prozentpunkte Genauigkeit. Bei einer Million Anfragen, einem typischen Pro-Token-Preis von ~0,15 €/1M Input-Tokens für gpt-4o-mini, und einem Haystack von 105 600 Tokens pro Anfrage:
- Long-Context-Oracle-Kosten:
1 000 000 × 105 600 × 0,15 / 10⁶ = 15 840 € - ZenBrain-Kosten (
k = 5, ~1 000 Tokens):1 000 000 × 1 000 × 0,15 / 10⁶ = 150 €
105 690 € Differenz für 4,5 Prozentpunkte. Pro 1 Mio. Anfragen.
Und das ignoriert die Latenz-Kosten (ein 105 K-Token-Prompt braucht in der Praxis 5–15 Sekunden Time-to-First-Token, ein 1 K-Token-Prompt unter 500 ms), die Storage-Kosten beim Caching (ZenBrain konsolidiert auf ~48 % weniger Tokens nach Sleep-Cycle als der naive Speicher), und die Tatsache, dass das Oracle kein Memory-Konzept hat — es kann nicht über Sessions hinweg lernen, hat keine kalibrierte Konfidenz, kein Forgetting, kein DSGVO-konformes Vergessen, keine Reconsolidation.
Das Oracle ist ein Brute-Force-Werkzeug. ZenBrain ist eine Architektur.
Wo die Pareto-Position herkommt
Vier Mechanismen tragen die 91,3-%-Marke gemeinsam:
- 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 bringt allein das Layer-Routing +181 % auf temporal queries gegenüber Flat-Dense-Storage. - 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 — mathematisch äquivalent zu Elastic Weight Consolidation. Die WichtigkeitI_ij = 1/σ²_ijwird gleichzeitig als Retrieval-Boost genutzt. - Sleep-Consolidation. Nachts läuft die Simulation-Selection-Loop: das System generiert Replay-Kandidaten aus echten Episoden + Counterfactuals, scored sie mit
TAG = 0,4·|δ_TD| + 0,35·R + 0,25·N, stärkt Top-Kandidaten via LTP, prunt schwache via LTD. Resultat: +37 % Stabilität, −47,4 % Storage. - 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 — die Deep-Copy mit logarithmischem Wachstum übernimmt nach 7+ Tagen die Dominanz, retainiert 91,2 % Strength bei 30 Tagen vs. praktisch null bei reinem Ebbinghaus.
Keiner dieser Mechanismen allein erzeugt die Pareto-Position. Im 15-Algorithmen-Ablation-Test des Papers zeigt sich, warum: Unter moderaten Bedingungen sind die meisten Algorithmen kooperativ-redundant — Sleep ist der einzige individuell signifikante Beitrag. Unter Stress (60 Tage, decay = 0,25/Tag) werden 9 von 15 Algorithmen individuell kritisch (ΔQ bis −93,7 %). 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 106-fache Token-Aufwand ist akzeptabel.
Für die übergroße Mehrheit der Knowledge-Work-Anwendungen — Personal Assistants, CRM, Forschungs-Agenten, Coding-Copiloten, Lernsysteme — ist die Pareto-Position bei k = 5 die wirtschaftlich richtige Wahl. Das ist exact die Regimezone, für die Memory-basierte Systeme erfunden wurden.
Und unter den Memory-Systemen ist ZenBrain auf LongMemEval-500 nicht knapp besser. Es führt um 4,9 / 12,3 / 15,9 Prozentpunkte gegen die nächsten drei Konkurrenten — bei demselben Token-Budget.
Mehr Memory ist nicht die Antwort. Bessere Memory ist.
Reproduzierbarkeit
Alle Resultate kommen aus docs/papers/results/g5-full500-nomic/ im Repo. Die Pipeline ist deterministisch — drei Retrieval-Seeds (42, 123, 456) für ZenBrain produzieren bit-identische Aggregate. Der Reproduktionsbefehl steht in Appendix F.4 des Papers.
- Paper: Zenodo DOI 10.5281/zenodo.19353663
- Code: github.com/zensation-ai/zenbrain
- npm:
npm install @zensation/algorithms @zensation/core