91 % der Genauigkeit bei 1 % der Tokens — die Pareto-Position für AI-Memory

Es gibt einen einzigen Satz aus dem v6 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.6, 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:

1. Layer-Routing. Eine Frage mit zeitlichem Bezug wird vom Episodic-Layer-Boost (w = 2,0) priorisiert; eine Verfahrens­frage 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.
2. Two-Factor Synaptic Consolidation. Edges im Knowledge Graph haben nicht nur ein Gewicht w_ij, sondern auch eine Konsolidierungs­varianz σ²_ij. Reife Edges (σ² → 0) widerstehen sowohl Decay als auch katastrophalem Überschreiben — mathematisch äquivalent zu Elastic Weight Consolidation. Die Wichtigkeit I_ij = 1/σ²_ij wird gleichzeitig als Retrieval-Boost genutzt.
3. 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.
4. 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