[RAG (Retrieval-augmented Generation)](https://en.wikipedia.org/wiki/Retrieval-augmented_generation) erweitert ein LLM, indem es relevante Passagen aus einem externen Korpus abruft, häufig über Einbettungen und Ähnlichkeitssuche, und sie dann als Kontext einspeist, damit das Modell anhand aktueller oder domänenspezifischer Daten antworten kann.

Es eignet sich gut für die Dokumentensuche. Beim Agentengedächtnis fällt es auseinander.

Ein neues Papier vom King's College London und dem Alan Turing Institute mit dem Titel „Beyond RAG for Agent Memory: Retrieval by Decoupling and Aggregation“ (Hu et al., Februar 2026; [siehe Papier](https://arxiv.org/abs/2602.02007)) erklärt den Grund dafür und weist auf einen besseren Ansatz hin.

## Warum RAG beim Agentenspeicher nicht ausreicht

Standard-RAG geht von einem großen, gemischten Korpus aus: Text einbetten, [top-k](https://en.wikipedia.org/wiki/Nearest_neighbor_search) nach Ähnlichkeit abrufen, als Kontext verketten.

Das Agentengedächtnis ist das Gegenteil: ein begrenzter, kohärenter Strom, in dem dieselbe Tatsache in vielen Formulierungen auftritt. Die Anwendung von RAG hier führt zu drei Problemen:

1. **Überflüssiges Top-K.** Sie fragen: „Wann war ich zuletzt beim Zahnarzt?“ In einem Dokumentenkorpus gibt top-k möglicherweise einige relevante Absätze aus verschiedenen Quellen zurück. Im Agentengedächtnis sagen viele Brocken fast das Gleiche („Zahnarzttermin am 15. März vereinbart“, „Zahnarzttermin am 15. März“, „Zahnarzttermin für den 15. März gebucht“). Top-k füllt sich mit Wiederholungen. Das Papier nennt dies „Zusammenbruch in eine einzige dichte Region“. Ähnlichkeit trennt nicht das, was *notwendig* ist, von dem, was lediglich *ähnlich* ist.
2. **Durch die Bereinigung werden Beweisketten unterbrochen.** Sie fragen: „Haben wir den Rechnungsstreit beigelegt?“ Die Antwort hängt von einer Kette ab: „Rechnung Nr. 123 wurde angefochten“, dann „Wir haben einer teilweisen Rückerstattung zugestimmt“, dann „Den vereinbarten Betrag bezahlt“. Beim Post-hoc-Beschneiden bleibt möglicherweise „Bezahlte Rechnung Nr. 123“ erhalten und die früheren Runden werden gelöscht. Das Model antwortet dann mit „Ja, gelöst“, ohne zu wissen, dass es einen Streit gibt. Das Beschneiden von Fragmenten zeitlich verknüpfter Beweise führt zu falschen Antworten.
3. **Ähnlichkeit ignoriert Struktur.** Sie fragen: „Wie ist der Status der Barcelona-Reise?“ Sie benötigen das Projekt, die Aufgabe (z. B. Flüge buchen) und das Ergebnis. Ähnlichkeit gibt Teile zurück, in denen „Barcelona“ oder „Reise“ erwähnt wird: vielleicht eine zufällige Erwähnung, eine vergangene Reise, eine Aufgabe aus einem anderen Projekt. Sie brauchten einen strukturellen Weg (dieses Projekt, diese Aufgaben, diese Ergebnisse). Ähnlichkeit kodiert das nicht. Struktur schon.

## Struktur statt Ähnlichkeit

Ein besserer Ansatz besteht darin, die Struktur zu verwenden, um zu steuern, was geladen wird, und nicht die Ähnlichkeit. Geben Sie Entitäten (Aufgaben, Kontakte, Transaktionen, Ereignisse) ein und rufen Sie sie nach Schema, Entitäts-IDs, Beziehungen und Zeitleisten ab. Behalten Sie Beobachtungen und abgeleitete Ergebnisse als ganze Einheiten bei; Schneiden Sie nicht innerhalb von Beweisblöcken ab. Dieselbe Eingabe und dasselbe Schema führen zu derselben Ausgabe. Kein LLM im kritischen Pfad.

## Was das Papier zeigt

Das System des Papiers (xMemory) erstellt eine vierstufige Hierarchie (Nachrichten zu Episoden, Semantik und Themen) mit Einbettungen und LLM-Zusammenfassungen. Es schlägt fünf andere Systeme (Naive RAG[^1], A-Mem[^2], MemoryOS[^3], LightMem[^4], Nemori[^5]) auf LoCoMo und PerLTQA, den Benchmark-Datensätzen für Langzeitgedächtnis bei Gesprächen und persönliche Langzeitbeantwortung von Fragen. Das Papier erfordert keine Einbettungen oder LLMs; es erfordert Struktur. Sie können mit einer erlernten Hierarchie (xMemory) oder mit einem deterministischen Schema-First-Design dorthin gelangen. Das Papier dokumentiert auch die Fragilität der LLM-generierten Struktur (A-Mem, MemoryOS): Formatierungsabweichungen, fehlgeschlagene Updates. Eine deterministische, schemaorientierte Struktur ist eine zuverlässigere Basis.

## xMemory vs Neotoma

Neotoma ist die [strukturierte Speicherschicht](/posts/truth-layer-agent-memory), die ich aufbaue: Schema-First, deterministisch, für Herkunft und Wiedergabe gebaut. Beide Systeme gehen über RAG hinaus; Sie unterscheiden sich darin, wie sie ihre Struktur aufbauen.

**xMemory** erstellt eine vierstufige Hierarchie (Nachrichten zu Episoden, Semantik und Themen) mit Einbettungen und LLM-Zusammenfassungen. Episoden sind zusammenhängende Blöcke; Semantik sind wiederverwendbare Fakten; Themengruppensemantik für Zugriff auf hoher Ebene. Ein Sparsity-Semantik-Ziel gleicht die Themengröße aus. Zu groß führt zu redundantem Abruf; Zu kleine Fragmente beweisen. Der Abruf erfolgt von oben nach unten: Wählen Sie einen kompakten Satz von Themen und Semantiken aus und erweitern Sie ihn dann nur dann auf intakte Episoden (und optional Nachrichten), wenn dies die Unsicherheit des Lesermodells verringert. Kein Beschneiden innerhalb der Einheiten. Bei diesen Benchmarks übertrifft es die fünf Basislinien in Bezug auf Qualität und Token-Nutzung. Das Papier stellt fest, dass die von LLM generierte Struktur (z. B. in A-Mem, MemoryOS) brüchig ist: Formatierungsabweichungen, fehlgeschlagene Aktualisierungen. Da xMemory seine Hierarchie mit LLM-Zusammenfassungen aufbaut, weist es die gleiche Sprödigkeit auf.

**Neotoma** baut eine Struktur ohne LLMs im kritischen Pfad auf. Entitäten werden typisiert; Beziehungen und Zeitpläne sind explizit; Beim Abruf werden Schema, Entitäts-IDs, Beziehungen und Zeitbereiche verwendet. Dieselbe Eingabe und dasselbe Schema führen zu derselben Ausgabe. Schemata entwickeln sich immer noch weiter. Unbekannte Felder landen in einer Schutzschicht. Eine deterministische Pipeline kann Felder mit hoher Zuverlässigkeit in das Schema hochstufen. Ein LLM kann neue Felder oder Typen als ausstehende Empfehlungen vorschlagen, die nur über Tools oder menschliche Genehmigung angewendet werden. Die Schlussfolgerung bleibt beratend: Schemaänderungen erfolgen durch Tools oder menschliche Genehmigung; Extraktion und Reduktion bleiben deterministisch; Das Schema bleibt die Quelle der Wahrheit. Die Kritik des Papiers gilt, wenn das Modell die Struktur *antreibt*, nicht wenn es vorschlägt und Menschen oder Werkzeuge anwenden. „Ingest-to-Retrieve“ bleibt deterministisch.

### Vergleich

| | xSpeicher | Neotom |
|--|--------|--------|
| Strukturquelle | Einbettungen + LLM-Zusammenfassungen (Episoden, Semantik, Themen) | Schema-First, deterministische Extraktion und Reduzierer |
| Hierarchie | Vier Ebenen (Nachrichten, Episoden, Semantik, Themen), geleitet von der Sparsity-Semantik-Zielsetzung | Typisierte Entitäten, Beziehungen, Zeitleisten (keine festen „Ebenen“) |
| Abruf | Von oben nach unten: repräsentative Auswahl im Diagramm, dann durch Unsicherheit begrenzte Erweiterung auf intakte Episoden/Nachrichten | Nach Schema, Entitäts-IDs, Beziehungen, Zeitleisten |
| Redundanzkontrolle | Repräsentative Auswahl + nur erweitern, wenn die Unsicherheit sinkt | Strukturelle Abfragen geben das zurück, wonach Sie fragen. keine Ähnlichkeit zusammenbrechen |
| Intakte Einheiten | Ja (kein Beschneiden innerhalb von Episoden/Nachrichten) | Ja (Beobachtungen und Entitäten bleiben vollständig erhalten) |
| Determinismus | Nein (LLM-generierte Struktur variiert) | Ja (gleiche Eingabe, gleiches Schema, gleiche Ausgabe) |
| Sprödigkeit | Papier zitiert LLM-Formatierungsabweichungen und fehlgeschlagene Aktualisierungen in ähnlichen Systemen | Schema und Code sind explizit; kein LLM im kritischen Pfad |

### Relative Vorteile

**xMemory** zeichnet sich aus, wenn es sich bei der Eingabe um einen Konversationsstrom handelt und Sie eine Struktur ohne die Definition von Schemata wünschen. Beispiel: Langfristiger Chat mit einem Assistenten, in dem Sie fragen: „Was haben wir bezüglich der Reise beschlossen?“ oder „Wann habe ich das letzte Mal das Budget erwähnt?“ xMemory erstellt Episoden, Semantik und Themen; Der Abruf ist tokeneffizient. Es eignet sich auch für schnelle Prototypen (Supporttickets, Besprechungsnotizen), bei denen Sie noch keine Schemata erstellen möchten. Sie akzeptieren Hierarchiedrift und benötigen keine Überprüfbarkeit oder erstklassige Abfrage nach Entität.

**Neotoma** eignet sich hervorragend, wenn Sie Rückverfolgbarkeit benötigen oder Ihre Daten bereits strukturiert sind. Beispiel: Überprüfbare Entscheidungen (Zahlungen, Vereinbarungen, Aufgabenergebnisse), bei denen dieselben Eingaben und dasselbe Schema denselben Schnappschuss ergeben müssen. Schemaänderungen werden versioniert und deterministisch angewendet; kein LLM im Pfad. Es eignet sich auch für typisierte Entitäten (Aufgaben, Kontakte, Transaktionen, Ereignisse) mit Beziehungen und Zeitleisten. Abfrage nach Entitätstyp, ID, Beziehung oder Zeitbereich. Neotoma behandelt diese als einheimisch; xMemory würde eine Serialisierung in Text erfordern und verliert den erstklassigen Zugriff.

## Iterative Strukturierung im Gespräch

Im Dialog entsteht oft eine Struktur: „Fügen Sie dafür eine Aufgabe hinzu“, „zeichnen Sie auf, dass wir uns bereit erklärt haben, 500 zu zahlen“, und der Agent handelt. Das handhaben die beiden Systeme unterschiedlich.

**xMemory:** Das Gespräch ist das primäre Objekt. Was der Agent tut (z. B. „Ich habe eine Aufgabe für den Zahnarzt erstellt“), bleibt im Nachrichtenstrom und fließt in Episoden, Semantik und Themen ein. Sie erhalten eine besser erlernte Hierarchie, aber keinen separaten, abfragbaren Entitätsgraphen. Struktur lebt innerhalb der Hierarchie.

**Neotoma:** Das Gespräch ist eine Quelle für Beobachtungen. Wenn der Agent eine Aufgabe, einen Kontakt oder eine Transaktion erstellt oder aktualisiert, erzeugen diese Vorgänge Beobachtungen und Entitäts-Snapshots. Neue Felder aus dem Dialog können in einer Erhaltungsebene landen und bei hoher Konfidenz in das Schema hochgestuft werden. Der Dialog und das strukturierte Diagramm bleiben synchron, da beide in denselben Speicher schreiben.

**Abweichender Abruf.** xMemory unterstützt den semantischen Abruf über die Hierarchie. Fragen in natürlicher Sprache („Was haben wir beim Zahnarzt entschieden?“) geben Themen, Semantik oder intakte Episoden zurück. Es unterstützt keinen strukturellen Abruf (keine Entitätstypen mit IDs und Beziehungen). Dies führt in drei Fällen zu erwarteten Ausfällen:

- **Beweise über mehrere Runden verteilt.** „Haben wir den Rechnungsstreit beigelegt?“ Der Streit, die Verhandlung und die Zahlung können in unterschiedlichen Episoden oder Themen stattfinden; Beim Abrufen kann es sein, dass ein oder zwei davon auftauchen und der Rest übersehen wird, sodass das Modell falsch oder unvollständig antwortet.
- **Abfragen festlegen.** „Welche Aufgaben sind vor Freitag fällig?“ oder „Alle Zahlungen anzeigen, um X zu kontaktieren.“ Es gibt keine zu filternden Aufgaben- oder Transaktionsentitäten. Sie erhalten semantische Übereinstimmungen (Nachrichten, in denen „Aufgabe“ und „Freitag“ oder „Kontakt X“ erwähnt werden), keine endgültige Liste, sodass die Ergebnisse unvollständig oder verrauscht sind.
- **Beziehungsdurchquerung.** „Welche Aufgaben in Projekt Y stehen noch aus?“ Ohne ein Projekt-Aufgaben-Diagramm werden beim Abrufen Gesprächsausschnitte zurückgegeben, in denen möglicherweise einige Aufgaben oder Projekte weggelassen werden. Sie können die Beziehung nicht zuverlässig aufzählen.

Neotoma unterstützt beides. Sie können Fragen im semantischen Stil stellen, wenn die Daten im Speicher gespeichert sind. Sie erhalten auch eine Strukturabfrage nach Entitätstyp, ID, Beziehung und Zeitfenster, sodass Set-Abfragen und Beziehungsdurchläufe vollständige, erstklassige Ergebnisse liefern. Der Nachteil besteht darin, dass Sie Schemata und einen Speicher benötigen, der diese Beobachtungen akzeptiert.

## Struktur vor Ähnlichkeit, Schemavorrang vor Sprödigkeit

Für den Agentenspeicher schlägt die Ähnlichkeit mit Rohtext fehl. Der Abruf muss durch die Struktur gesteuert werden: wie Sie den Stream zerlegen und organisieren, nicht wie viele Blöcke einer Abfrage entsprechen. Das Papier zeigt, dass eine erlernte Hierarchie (xMemory) naive RAG übertrifft und dass die von LLM generierte Struktur brüchig ist.

Ein deterministischer, schemaorientierter Pfad bietet Ihnen jedoch denselben strukturellen Vorteil ohne diese Sprödigkeit. Ich baue [Neotoma](https://github.com/markmhendrickson/neotoma) auf Letzterem auf, damit Aufnahme und Abruf reproduzierbar bleiben und das Schema die Quelle der Wahrheit bleibt.

[^1]: **Naive RAG:** Erinnerungen einbetten, festes Top-K nach Ähnlichkeit abrufen, keine Hierarchie. Kein separates Projekt; Grundlinie definiert im [Papier](https://arxiv.org/abs/2602.02007).
[^2]: **A-Mem:** Agentenspeicher für LLM-Agenten; Links im Zettelkasten-Stil und agentengesteuerte Aktualisierungen eines Speichernetzwerks. [Projekt](https://github.com/agiresearch/A-mem).
[^3]: **MemoryOS:** hierarchischer Kurz-/Mittel-/Langzeitspeicher mit Aktualisierungs-, Abruf- und Generierungsmodulen für personalisierte Agenten. [Projekt](https://github.com/BAI-LAB/MemoryOS).
[^4]: **LightMem:** Leichter Speicher, inspiriert von Atkinson-Shiffrin-Stufen; themenbezogene Konsolidierung und Offline-Langzeitaktualisierungen. [Projekt](https://github.com/zjunlp/LightMem).
[^5]: **Nemori:** selbstorganisierendes episodisches Gedächtnis mit Ereignissegmentierung und Vorhersagekalibrierung für adaptives Wissen. [Projekt](https://github.com/nemori-ai/nemori).