Die Strukturierung des Speichers nach Typ reduziert die abgerufenen Token um etwa 40 %.

Warum ein flacher Speicher versagt

Die meisten Tutorials für Anfänger bringen einem LLM-Agenten bei, sich zu „erinnern“, indem sie jede neue Information an eine einzige Liste anhängen und diese Liste in jeder Runde an das Modell zurückgeben. Der Code umfasst buchstäblich nur drei Zeilen und liefert eine funktionierende Demo. In der Praxis wächst die Liste jedoch unkontrolliert an. Dabei treten zwei Symptome auf:

  • Der Agent behandelt veraltete Daten als weiterhin wahr – zum Beispiel liefert er eine ETA, die bereits vor Stunden abgelaufen ist.
  • Das Kontextfenster füllt sich mit Belanglosigkeiten, die die Antwort nie beeinflussen, was die API-Kosten in die Höhe treibt und die Antwortzeiten verlängert.

Ein einfacher Vektorspeicher oder ein simpler Key-Value-Cache kann die Berufsbezeichnung eines Nutzers nicht von einem temporären Projektstatus unterscheiden. Wenn der Agent eine semantische Suche durchführt, schlägt der Ähnlichkeitsalgorithmus möglicherweise eine alte ETA vor, nur weil die Suchanfrage dieselben Wörter enthält, obwohl der Datenpunkt nicht mehr relevant ist.

Strukturierter Speicher: vier Kategorien, ein Ziel

Die Lösung besteht darin, den Speicher nicht länger als Monolith zu behandeln, sondern jeden Eintrag in eine von vier Kategorien zu klassifizieren:

  • Nutzerfakten (User facts) – stabile Attribute wie die Rolle eines Nutzers, die bevorzugte Sprache oder die Sicherheitsfreigabe. Diese ändern sich selten und können für die gesamte Sitzung zwischengespeichert werden.
  • Feedback – explizite Regeln, die der Agent befolgen muss, z. B. „niemals Datenbankpasswörter preisgeben“ oder „Humor bei Compliance-Anfragen vermeiden“. Da sie das Verhalten steuern, gehören sie in den System Prompt statt in den durchsuchbaren Pool.
  • Projektstatus (Project state) – schnelllebige Daten wie aktuelle ETAs, der Fortschritt von Aufgaben oder temporäre Token. Dieser Bereich benötigt eine Ablaufprüfung; sobald ein Zeitstempel außerhalb eines definierten Fensters liegt, sollte der Eintrag gelöscht werden.
  • Referenzen (References) – Verweise auf externe Dienste, Dokumenten-IDs oder API-Endpunkte. Sie sind kein anzuzeigender Inhalt, sondern Routen, um bei Bedarf frische Daten abzurufen.

Mem0 ermöglicht es Entwicklern, jedem Speicherdatensatz beliebige Metadaten anzuhängen. Durch das Indexieren des kind-Feldes kann eine Abfrage zuerst nach dem relevanten Bucket filtern, bevor das LLM entscheidet, wie das Ergebnis verwendet wird.

Zweistufiger Abruf mit Mem0

  1. Speicher nach Typ abrufen – Eine kurze Filterabfrage fragt Mem0 nach „allem Feedback“ oder „Projektstatus-Einträgen, die neuer als ein kurzes Intervall sind“. Der Ergebnissatz ist bereits auf die entsprechende Kategorie zugeschnitten.
  2. Das LLM entscheiden lassen – Die gefilterten Textfragmente werden zusammen mit der aktuellen Frage des Nutzers in den Prompt eingefügt. Das Modell kann nun darüber schlussfolgern, ohne irrelevante Fakten durchforsten zu müssen.

Ein konkretes Beispiel: Anstatt darauf zu warten, dass ein semantischer Treffer die Regel „die Datenbank nicht verspotten“ hervorhebt, injiziert der Entwickler diese Regel direkt zu Beginn der Sitzung in den System Prompt und speichert sie für die gesamte Interaktion zwischen. Selbst wenn die Anfrage des Nutzers keinen expliziten Bezug zu Datenbanken enthält, kennt das Modell die Einschränkung bereits.

Praktische Tricks zur Kostensenkung

  • Feedback-Regeln zwischenspeichern – Speichern Sie den Regelsatz einmal pro Sitzung und verwenden Sie ihn wieder, anstatt in jeder Runde neu zu suchen. Dies reduziert den Token-Verbrauch in jeder Runde.
  • Projektstatus-Suchen überspringen, wenn irrelevant – Wenn der Nutzer eine rein konzeptionelle Frage stellt („Was ist der Unterschied zwischen überwachtem und bestärkendem Lernen?“), besteht keine Notwendigkeit, ETA- oder Aufgabenfortschrittsdaten abzurufen.

Durch die Anwendung dieser zwei Gewohnheiten kann der Token-Verbrauch im Vergleich zu einem naiven flachen Speicheransatz um etwa 40 % reduziert werden. Die Einsparungen schlagen sich direkt in niedrigeren API-Rechnungen und schnelleren Antwortzeiten nieder, insbesondere bei Agenten, die über viele Interaktionen hinweg aktiv bleiben.

Wer profitiert, wer hat Bedenken?

Gewinner – Teams, die Kundensupport-Bots, interne Workflow-Assistenten oder irgendwelche Multi-Turn-LLM-Schnittstellen entwickeln. Sie erhalten zuverlässigere Antworten, vermeiden peinliche Fehler durch veraltete Daten und können ihr Budget effizienter nutzen.

Fazit

Wenn Sie einen LLM-Agenten wollen, der auch in langen Sitzungen präzise bleibt, hören Sie auf, jeden Fakt in ein einziges Kontextfenster zu stopfen. Kennzeichnen Sie jeden Speicher als Nutzerfakt, Feedback, Projektstatus oder Referenz, erzwingen Sie bei Bedarf Ablaufdaten und lassen Sie ein Tool wie Mem0 die schwere Arbeit erledigen. Das Ergebnis sind aktuellere Antworten, weniger unnötige Token und eine spürbare Senkung der Betriebskosten.