Zum Inhalt

Automatische Übersetzung

Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Speicher für KI-Agenten: Schema-gesteuertes, typisiertes Zustandsmanagement für langlaufende Systeme

Agenten versagen selten deshalb, weil sie alles vergessen haben. Vielmehr versagen sie, weil sie sich an eine alte Information erinnern und diese als aktuellen Zustand betrachten.

Stellen Sie sich einen langlaufenden Assistenten vor, der einer Nutzerin namens Mira zur Seite steht. In einem Gesprächszweig teilt Mira mit, dass die Frist für ihren Reisepass der 15. Juli sei. Später korrigiert sie dies auf den 30. Juni. Ein Vektorabgleich kann zwar die alte Notiz finden, doch er kann allein nicht erkennen, welche Frist aktuell gilt. Das ist der Unterschied zwischen Abruffähigkeit und echtem Gedächtnis.

Zusammenfassung: Behandeln Sie das dauerhafte Agentenmemory als typisierten Anwendungsstate. Extrahieren Sie mögliche Memory-Einträge über eine Grenze mit strukturiertem Ausgabeformat, speichern Sie die Einträge mit Tenant-Bereich, Gültigkeitsfenstern, Überlagerungsmechanismen, Herkunftsinformationen sowie Schema-Versionierung – und holen Sie beim Lesen den aktuellsten relevanten Teil ab. Die Vektorsuche kann im System verbleiben; sie sollte jedoch nicht als Quelle für veränderliche Fakten dienen.

Die Falle des Kontextfensters

Das Kontextfenster stellt lediglich einen Arbeitsbereich dar. Es handelt sich weder um dauerhaftes Memory noch um eine Datenbank.

Langlaufende Agenten müssen Präferenzen, Task-Zustände, Kundendaten, Entscheidungen bezüglich Tools, Compliance-Hinweise sowie frühere Fehler speichern. Eine einfache Lösung besteht darin, Zusammenfassungen anzufügen oder alte Notizen in einen Vektorstore zu übertragen. Das funktioniert solange, bis sich einer der gespeicherten Fakten ändert.

Dann hat der Agent beispielsweise zwei Fristen für Passbescheinigungen, zwei bevorzugte Formate oder zwei Projektentscheidungen. Die semantische Suche kann beide Ergebnisse liefern. Eine Zusammenfassung könnte eines davon überschreiben. Ein langer Kontext könnte das veraltete Element neben dem aktuellen enthalten. Keines dieser Verhaltensweisen bietet jedoch einen klaren Memory-Vertrag.

Der Vertrag muss konkrete Fragen beantworten:

  • Was gilt derzeit?
  • Was galt am 2. Juni?
  • Wer hat das gesagt?
  • Welchem Mieter gehört es?
  • Welchen älteren Fakt hat dieser Fakt ersetzt?
  • Kann ich ihn löschen oder verfallen lassen?

Genau hier setzt Schema-Guided Agent Memory (SGAM) ein.

Was SGAM bedeutet

Der Name muss zunächst vereinfacht werden, damit die Architektur verständlich wird.

Schema-Guided Dialogue (SGD) ist das 2019 von Google veröffentlichte datengetriebene Datensatz für zielorientierte Dialoge. Sein Schema beschreibt Service-APIs, Absichten sowie Slots, sodass ein Dialogmodell den Zustand von Diensten verfolgen kann, die es zuvor nicht gesehen hat. Ein nützliches Vorbild – allerdings aus einer anderen Ebene.

Schema-Guided Memory (SGM) ist der Forschungsbegriff, den Mei et al. in According to Me: Long-Term Personalized Referential Memory QA verwenden. In dieser Arbeit werden freitextbasierte Descriptive Memory (DM)-Strukturen mit Schlüssel-Wert-Speicherelementen mit festem Schema verglichen. Die Quelleninformation bleibt dieselbe; nur die Darstellung ändert sich.

Schema-Guided Agent Memory (SGAM) ist das Engineering-Muster, das in diesem Artikel benannt wird: Es geht darum, Schemata zur Steuerung von Schreibvorgängen, Aktualisierungen, Abfragen und Löschungen dauerhafter Agentenmerkmale zu nutzen. Das Schema ist dabei nicht einfach nur eine ansprechendere Notizform – es stellt vielmehr den Vertrag für den Zustand dar.

ATM-Bench macht diese Motivation konkret. Es nutzt etwa vier Jahre an persönlichen Memodaten aus E-Mails, Bildern und Videos und stellt anschließend Fragen, die auf persönliche Referenzen, Standortkenntnisse, mehrere Belegelemente sowie zeitliche Aktualisierungen angewiesen sind. Aktuelle Memosysteme schneiden bei dieser anspruchsvollen Aufgabe schlecht ab, während SGM im Vergleich zu DM verbesserte Ergebnisse liefert – denn Felder wie Zeit, Quelle, Standort, Entitäten und Tags stehen dem Abruf- und Antwortsystem als strukturierte Daten zur Verfügung statt als freier Text.

Deshalb betrifft der nächste Vergleich SGAM versus SGR. Schema-gesteuertes Reasoning ist kein willkürlicher Umweg, sondern vielmehr das notwendige „Schreibtor“, das SGAM in der Regel benötigt.

SGR ist das Schreibtor

Schema-gesteuertes Reasoning (SGR) sowie Schema-gesteuertes Agenten-Memory (SGAM) lösen unterschiedliche Aspekte desselben Produktionsproblems.

Ich habe SGR in diesem Blog als wiederkehrendes Bauelement verwendet. Die ursprüngliche vLLM und XGrammar – Artikel der Mechanismus wurde erläutert. Spätere Beiträge wendeten ihn an. strukturierte Bewertungskriterien, Planer und Router, und reproduzierbare RAG-Bewertungskriterien. In all diesen Fällen hat SGR den Aufruf eingeschränkt, sodass die Rückgabe ausreichend valid war, um von Code verarbeitet zu werden.

SGAM übernimmt diese Vorgehensweise, ändert jedoch die Lebensdauer der Ergebnisse. Die Ausgabe ist nicht länger lediglich ein Urteil, eine Route oder ein Plan für die aktuelle Anfrage. Stattdessen handelt es sich dabei um einen möglichen Speicherwrite, der zukünftige Sitzungen sowie Tool-Aufrufe beeinflussen kann. Deshalb sind die Ähnlichkeiten und Unterschiede von großer Bedeutung.

SGR beschränkt einen einzelnen Modellaufruf. Er zwingt das Modell dazu, für den aktuellen Inferenzschritt ein gültiges Objekt zu erzeugen – meist über Pydantic, JSON Schema, strukturierte Ausgaben, die vom jeweiligen Anbieter bereitgestellt werden, oder einen gesteuerten Dekodierungsmechanismus wie XGrammar.

SGAM entscheidet darüber, was nach dem Bestehen dieses Objekts geschieht. Soll es gespeichert werden? Überlagert es eine ältere Eintragung? Welcher Mieter kann es einsehen? Handelt es sich um aktuelle oder historische Daten? Welches Quellenereignis dient als Grundlage dafür?

Dimension SGR SGAM
Bereich Ein Inferenzschritt oder eine Toolaufruf Langlebiger Lebenszyklus der Speicherung
Formatierung Pydantic oder JSON Schema für den Aufruf Typisierte Datensätze, Schemata und Beziehungen
Durchsetzung Strukturierte Ausgabe oder Einschränkungen bei der Dekodierzeit Validierung, Datenbankbeschränkungen, Konfliktregeln
Lebensdauer Wird in der Regel nach der Antwort verworfen. bleibt zwischen den Sitzungen bestehen und läuft weiter
Fehlermodus Ungültige oder semantisch schwache Extraktion Veralteter, verschmutzter, nicht abgegrenzter oder nicht überprüfbarer Zustand

Das Muster lautet:

structured extraction on write -> typed memory at rest -> scoped retrieval on read

SGR sorgt dafür, dass die Extraktion zuverlässig genug ist, um in den Speicher aufgenommen zu werden. SGAM stellt sicher, dass der Speicher sicher genug ist, um später erneut verwendet zu werden.

from datetime import datetime
from pydantic import BaseModel, Field


class MemoryDelta(BaseModel):
    tenant_id: str = Field(description="Isolation boundary, e.g. acme")
    subject: str = Field(description="Normalized entity ID, e.g. mira")
    attribute: str = Field(description="Property being updated")
    value: str = Field(description="New value")
    valid_from: datetime
    source_episode_id: str

Dieses Objekt ist nicht das Speichersystem. Es stellt die Grenze zwischen unstrukturierten Gesprächen und dem Speicherprotokoll dar.

Die beiden Flüsse

Der Workflow umfasst zwei getrennte Ströme. Wenn diese miteinander vermischt werden, entstehen aus den Diagrammen unübersichtliche Strukturen.

Der Eingabestrom stellt den Schreibweg dar:

  1. Erfassen Sie eine rohe Episode aus Nachrichten, Tool-Ergebnissen oder Geschäftsereignissen.
  2. Extrahieren Sie durch strukturierte Ausgaben die relevanten Datensätze.
  3. Überprüfen Sie das Schema und lehnen Sie fehlerhafte Eingaben ab.
  4. Klären Sie Konflikte, schließen Sie veraltete Datensätze und bewahren Sie die Herkunftsnachweise auf.
  5. Speichern Sie den Eintrag im SGAM-Speicher.

Der Anfragenstrom ist der Leseweg:

  1. Beginnen Sie mit der Anfrage des Benutzers.
  2. Entscheiden Sie, ob für die Anfrage der aktuelle Zustand oder ein Zustand zu einem bestimmten Zeitpunkt benötigt wird.
  3. Filtern Sie nach Tenant, Speichertyp, Thema, Attribut sowie Gültigkeitsfenster.
  4. Fügen Sie nur dann Vektor- oder Graphenerweiterungen hinzu, wenn eine präzise Zustandsabfrage nicht ausreicht.
  5. Erstellen Sie für das Modell den kleinstmöglichen zusammengefassten Kontext.

Architektur der schema-gestützten Agenten-Memory

Lesen Sie dieses Diagramm von links nach rechts in zwei Kanälen. Der obere Kanal schreibt in den Speicher. Der untere Kanal liest aus dem Speicher. Der Speicher wird gemeinsam genutzt, doch die Verantwortlichkeiten nicht.

Was gehört in ein Speicherschema

Ein minimales SGAM-Eintrag benötigt mehr als text.

tenant_id
memory_id
subject
attribute
value
memory_type
schema_version
valid_from
valid_to
supersedes_memory_id
source_episode_id
confidence
retention_policy

Diese Struktur macht gewöhnliche Operationen explizit. Ein neuer Fristtermin für ein Pass kann den vorherigen Fristtermin außer Kraft setzen, ohne die Historie zu löschen. Eine Abfrage kann nach dem aktuellen Zustand oder einem Zustand zu einem bestimmten Zeitpunkt fragen. Eine Antwort kann auf das jeweilige Queldokument verweisen. Eine Migration kann erkennen, welche Schema-Version eine Datenspur erzeugt hat. Ein Löschvorgang kann feststellen, welche Indizes gereinigt werden müssen.

Genau hier unterscheiden sich SGAM und RAG voneinander: RAG holt Dokumente ab, während SGAM den Zustand verwaltet.

SGAM ist nicht anti-Vektor. Vektoren sind nützlich für das verschwommene Abrufen, das Clustering sowie die Erweiterung. Allerdings liegt der aktuelle Wert bei mira.passport_deadline Es muss aus einem begrenzten Speicherrecord stammen und nicht einfach aus dem ersten verfügbaren Chunk.

Ein Beispiel für einen veralteten Zustand

Die kleinste nützliche SGAM-Demo ist ein Buchhaltungsregister für das oben genannte Mira-Beispiel mit zwei Episoden.

e1: Mira prefers concise answers. Her passport deadline is 2026-07-15.
e2: Mira corrected the deadline. It is now 2026-06-30.

Ein Text-Memory-Suchvorgang kann Ergebnisse zurückgeben. e1 weil es die richtigen Wörter enthält. Ein eingegebener Store sollte zurückgeben e2 für den aktuellen Zustand und beibehalten e1 für eine historische Abfrage.

Das Verhalten auf der Schreibseite ist unbedeutend:

def close_previous_fact(db: sqlite3.Connection, fact: MemoryFact) -> int | None:
    row = db.execute(
        """
        select fact_id
        from memory_facts
        where tenant_id = ?
          and subject = ?
          and attribute = ?
          and valid_to is null
        order by valid_from desc
        limit 1
        """,
        (fact.tenant_id, fact.subject, fact.attribute),
    ).fetchone()
    if not row:
        return None

    db.execute(
        "update memory_facts set valid_to = ? where fact_id = ?",
        (fact.valid_from, row["fact_id"]),
    )
    return int(row["fact_id"])

Das erwartete Verhalten ist das eigentliche Ziel:

Naive text memory:
  returned episode: e1 -> passport deadline is 2026-07-15

SGAM current state:
  mira.passport_deadline = 2026-06-30
  valid_from=2026-06-03T10:00:00Z, source=e2

SGAM point-in-time state:
  on 2026-06-02, mira.passport_deadline = 2026-07-15

In der Produktion sollte diese Transaktion mit einer strukturierten Extraktion auf dem Schreibweg kombiniert werden. Dadurch wird ein veralteter Zustand im Datenbankkern entfernt. Das Modell muss nicht mehr selbst erraten, welche alten Informationen weiterhin gültig sind.

Tool oder Framework Hauptspeicherschicht Zeitliche Verarbeitung Schema-Mechanismus Praktische Nische
Zep / Graphiti Neo4j, FalkorDB, Neptune sowie Unterstützung für veraltete Kuzu-Systeme Hoch Pydantic-Entitäten und Kantenarten, zeitbasierte Kanten, Provenienz Zeitgraphen-Speicher
LangGraph / LangMem LangGraph-Speicher, Speicher mit Postgres-Unterstützung Mittel JSON speichert Profile sowie die Extraktion von Sammlungen mittels Pydantic Agenten-Apps, die bereits auf LangGraph basieren
Mem0 Gemanagter Stack mit Valkey-/Redis-/Vector-Backends in OSS-Umgebungen Mittel Arten von Speicher, benutzerdefinierte Kategorien, Extraktionsanweisungen User-, Agent- und Sitzungsspeicher als Service
Letta / MemGPT Datenbankgestützter Agentenzustand und Speicherblokke Niedrig Bearbeitbare, beschriftete Speicherblöcke Zustandsbasierte Agenten mit kontextbezogener Verwaltung im Stil von Betriebssystemen
Cognee Graph-, Vektor- und relationale Backend-Systeme Mittel Ontologieorientierte Extraktion und Validierung Enterprise-Wissensgraphen-Speicher
LlamaIndex-Property-Graph Property Graph-Speicher sowie Vektor-Speicher Niedrig bis mittel SchemaLLMPathExtractor mit zulässigen Entitäten und Beziehungen Graphextraktion aus Dokumenten und Spuren

Graphiti stellt die klarste Open-Source-Referenz dar, wenn das Speichermanagement relationell und zeitbasiert erfolgen soll. Es verfolgt die Änderungen von Fakten, bewahrt die Herkunft der jeweiligen Datenquellen auf und unterstützt hybride Suchmechanismen. LangGraph eignet sich gut als Anwendungs层, da es Thread-Checkpointe von den gespeicherten Daten zwischen den Threads trennt. Mem0 ist nützlich, wenn man verwaltete Speicheroperationen statt selbstständiger Steuerung aller Speichersysteme bevorzugt. Letta kommt den editierbaren Kontextblöcken näher als den SGAM-Lösungen auf Feldebene, doch das konzeptionelle Framework mit Zustandsagenten bleibt weiterhin relevant.

Beginnen Sie nicht mit der aufwendigsten Graphenstruktur, es sei denn, die Anwendung benötigt sie tatsächlich. Für viele Teams reicht bereits in der ersten Version eine relationale Tabelle mit JSON-Dateninhalten, Validitätsspalten, Tenant-Indizes sowie einem Vector-Sidecar aus.

Implementierungsleitfaden

Die erste Entscheidung bei der Implementierung betrifft nicht die Frage „Graphen- oder Vektor-Speicher?“, sondern vielmehr, was das Produkt überhaupt speichern darf.

Ein Support-Agent kann sich den Account-Status, offene Fälle sowie dauerhafte Kontaktoptionen merken. Er sollte jedoch nicht jeden frustrierten Nutzer automatisch in einen Profilzustand versetzen. Ein Coding-Agent kann sich Repository-Konventionen sowie ungelöste Aufgaben merken. Er sollte keine privaten Notizen ewig speichern, nur weil diese einmal abgerufen wurden.

Beginnen Sie mit dem Schreibweg und betrachten Sie das Gedächtnis als eine kleine Zustandsänderung:

  1. Benennen Sie den Typ des Gedächtnisses, das Thema, den Tenant-Bereich sowie die Aufbewahrungsklasse.
  2. Extrahieren Sie die Kandidatendaten mit einer strukturierten Ausgabe.
  3. Überprüfen Sie die Daten mit Pydantic oder der Schema-Schicht, die bereits in Ihrem Stack verwendet wird.
  4. Klären Sie Konflikte vor dem Einfügen – insbesondere ob die neue Datenspur die alte ersetzt.
  5. Bewahren Sie einen Quellenzeiger zum ursprünglichen Ereignis, Tool-Ergebnis, Datei, Ticket oder Benutzerbestätigung auf, aus denen die Datenspur entstanden ist.
  6. Speichern Sie die Schema-Version zusammen mit der Datenspur – nicht nur im Anwendungscode.

Für viele Teams kann der erste SGAM-Speicher eine relationale Tabelle mit einer JSON-Spalte sowie einigen Indizes sein. Es ist nicht notwendig, direkt mit einem temporären Wissensgraphen zu beginnen. Der Graph wird nützlich, wenn Beziehungen von Bedeutung sind: Kunde zu Account, Account zu Richtlinie, Aufgabe zu Artefakt, Benutzer zu Präferenz, Projekt zu Entscheidung.

Schnellweg-Einschreibungen und Hintergrund-Einschreibungen

Eine sofortige Extraktion lohnt sich, wenn die nächste Aktion von den neuen Daten abhängt. Wenn der Nutzer sagt „Merken Sie sich, dass ich kurze Antworten bevorzuge“, sollte das System nicht auf einen täglichen Job warten, um anders zu handeln.

Die meisten Anfragen verlaufen nicht so. Der günstigere Standardweg besteht darin, die Rohdaten der Anfrage schnell zu erfassen, Metadaten zum Tenant/Session/Tool hinzuzufügen und einen Hintergrundprozess damit zu beauftragen, später potenzielle Erinnerungen auszuwerten. Die auf Wiederholungen basierende Konsolidierung ist eine Variante dieser Strategie: Anfragen mit schwachem Signal werden vorerst zurückgehalten, und ein Fakt wird nur dann berücksichtigt, wenn ähnliche Belege wieder auftauchen oder der Benutzer dies explizit bestätigt. Der Kompromiss dabei ist eine Verzögerung in Bezug auf Aktualität. Dies ist akzeptabel bei Szenarien wie „Der Benutzer bittet häufig um CSV-Exporte“, weniger jedoch bei Situationen wie „Der Kunde hat die Lieferadresse geändert“.

Der Leseweg sollte weniger komplex sein als der Schreibweg. Zuerst sollte die Frage „In welchem Zustand darf ich arbeiten?“ beantwortet werden, anschließend geprüft werden, ob eine ungenaue Suche nützlichen Kontext liefern kann.

  1. Filtern nach Tenant, Erinnerungstyp und Gültigkeitszeitraum.
  2. Zuerst den exakten, strukturierten Zustand abrufen, bevor semantische Äquivalente betrachtet werden.
  3. Für unterstützende Belege, verwandte Entitäten und Beispiele Vektor- oder Graphenerweiterungen nutzen – diese dienen jedoch nicht als Quelle für aktuelle Fakten.
  4. Den kleinstmöglichen, zitierten Kontext zusammenstellen, der die Frage beantworten kann.

Schema-Migrationen sollten als Produktarbeit betrachtet werden. Wenn sich eine Erinnerungsdatei ändert, ändert sich auch das Verhalten des Agents: Was er sich merken kann, was er zitieren darf, was er löschen kann sowie welche alten Fakten weiterhin als aktuell gelten. Migrationsskripte, Rückfüllvorgänge, doppelte Lesefenster sowie Löschverhalten müssen im selben Release-Plan wie die Produktänderung behandelt werden.

Wo SGAM seine Nützlichkeit zeigt

SGAM eignet sich besonders gut, wenn Erinnerungen zustandsbehaftet sind und im Laufe der Zeit changieren:

  • Benutzerpräferenzen, die aktualisiert oder widerrufen werden können;
  • Kundendaten oder Kontoinformationen mit Prüfanforderungen;
  • Zustand von Aufgaben für langlaufende Assistenten;
  • Projektgedächtnis von Code-Agenten;
  • Gemeinsamer Zustand mehrerer Agenten;
  • Konformitätshinweise, bei denen die Herkunft entscheidend ist;
  • Zeitbezogene Fragen wie „Was glaubten wir vor der Migration?“

Es ist übertrieben, wenn das Gedächtnis nur kurzlebig ist, exploratorisch genutzt wird oder kostengünstig neu berechnet werden kann. Wenn ein Agent nur wenige Kontinuitätsschritte benötigt, reichen ein Checkpoint sowie eine gekürzte Nachrichtenhistorie aus. Bei statischer Dokumentqualitätsprüfung kann RAG ausreichen. Falls Ihr Schema täglich ändert, weil das Anwendungsfeld noch unklar ist, wird SGAM Ihre Arbeit verlangsamen.

Bewertungskontrollliste

Bewerten Sie das Gedächtnissystem nicht allein anhand der Endantwort. Ein solches System kann höflich antworten, obwohl es falsche Informationen bereitgestellt hat, veraltete Daten abgerufen hat oder unterwegs eine Grenze zwischen verschiedenen Nutzern überschritten hat.

Die Struktur ähnelt der Bewertungseinheit in meinem Artikel zur Bewertung von RAG-Systemen: Messen Sie die Pipeline-Phase, in der der Fehler auftreten kann, und nicht nur den am Ende erzeugten Text. Dies überschneidet sich zudem mit den Anforderungen der Trace-Methodik. der Artikel zur Bewertung von Agenten: Ein Speicherfehler ist oft bereits im Laufverlauf sichtbar, noch bevor er sich im Ergebnis zeigt.

Für SGAM ist der sauberste Test die Wiederholung. Gibt man eine feste Abfolge von Episoden in den Speicherschreiber ein, prüft man das Protokoll nach jedem bedeutenden Zug und stellt anschließend Fragen zum aktuellen Zustand sowie zu einem bestimmten Zeitpunkt anhand des entstandenen Speichers.

Schicht Der Fehler, nach dem Sie suchen Messgrößen
Erstellung der Extraktion Der Agent hat eine Tatsache übersehen, eine erfunden oder eine ungültige Form erzeugt. Schema-konforme Schreibrate, Extraktionsgenauigkeit/Rückrufrate, Abdeckung der Quelldatenepisoden
Konfliktbehandlung Ein veralteter Wert blieb weiterhin gültig oder ein korrekter alter Wert wurde überschrieben. Korrektheit bei Überlagerung, Duplikatrate, Korrektheit bei Invalidation von veralteten Fakten
Isolierung und Richtlinien Gedächtnisleck, das sich über verschiedene Benutzer ausbreitet oder über den vorgesehenen Zeitrahmen hinaus bestehen bleibt. Fehler bei der Isolierung von Tenant-Daten, Korrektheit der Löschvorgänge, Einhaltung von Aufbewahrungsrichtlinien
Datenabruf Das richtige Datensatz existiert, doch der Leser hat ihn nicht abgerufen. Genauigkeit im aktuellen Zustand, Genauigkeit zu einem bestimmten Zeitpunkt, Recall@k für Speicherdatensätze
Antwortverankerung Die Antwort nutzte Speicher ohne entsprechende Unterstützung oder bezog sich auf die falsche Quelle. Stellen Sie einen Support-Antrag bezüglich der Quelldatenepisoden, der Genauigkeit der Zitierungen sowie der Richtigkeit der Konfliktlösung.
Operationen Der Speicherpfad ist zu langsam, zu veraltet oder zu aufwendig im Umgang. p95-Schreibverzögerung, Verzögerung durch Datenveraltetheit, Leseverzögerung, Kosten pro Abfrage

Benchmarks wie zum Beispiel LoCoMo, LongMemEval, und ATM-Bench-Testumgebung Stellen Sie nützliche externe Signale bereit. Sie ersetzen jedoch nicht ein eigenes Testumfeld für das jeweilige Domänenkontext. Der Speicherverbrauch hängt von der Arbeitslast ab: Ein Code-Assistent, ein Kundenservice-Bot sowie ein Compliance-Copilot erfordern unterschiedliche Schemata, Filter, Retentionsregeln und Fehlerprüfungen.

Einschränkungen

SGAM ist meine Bezeichnung für ein Muster und nicht für ein Standard. Die Branche verwendet bereits überschneidende Namen für Elemente im selben Designraum: LangGraph-Memory und LangMem Erörtern Sie kurzfristige und langfristige Speicherstrukturen, Profile, Sammlungen, Schreibvorgänge auf Hot-Paths sowie Hintergrund-Geräte für die Speichermanagement. Zep Graphiti er bezeichnet die grafenförmige Variante als temporären Kontextgraphen. Letta er stellt das System als Zustandsagenten dar, die persistente Speicherblokke besitzen. Mem0 bezeichnet sich selbst als eine verwaltete Speicherschicht. Microsoft Graph RAGLlamaIndex Property Graphs sowie Cognee nutzen die Sprache von Knowledge Graphs für Aufgaben im Bereich der assoziativen Suche und Ontologieverarbeitung.

Diese Namen sind nicht austauschbar. Einige Systeme verwalten Benutzerprofile, andere Episoden. Wieder andere erstellen einen grafischen Kontext über Dokumente hinweg. Weitere Systeme stellen dem Agenten Werkzeuge zur Verfügung, um sein eigenes Gedächtnis zu bearbeiten. SGAM stellt eine strengere Version dieser Ansicht dar: Wenn dauerhaftes Gedächtnis den aktuellen Anwendungsstatus repräsentiert, sind Schema, Gültigkeit, Herkunftsnachweis, Konfliktbewältigung, Aufbewahrungsfristen sowie Migration erforderlich.

Getyptes Gedächtnis kann dennoch fehlerhaft sein. Ein Schema erleichtert zwar die Überprüfung fehlerhafter Eingaben, macht sie aber nicht zuverlässiger. Es bleibt weiterhin ein Vertrauen in die Quelle sowie die Bestätigung durch den Benutzer für sensible Fakten erforderlich, genauso wie Konfliktrichtlinien, Löschfunktionen und Überwachungsmechanismen.

Schema-Migration ist arbeitsintensiv. Sobald das Gedächtnis zum Status des Systems wird, muss man sich mit Versionsverwaltung, Rückfüllvorgängen, alten Datensätzen sowie dem Löschverhalten auseinandersetzen. Das ist der Preis dafür, einen zuverlässigen aktuellen Zustand statt nur einer Ansammlung plausibler Notizen zu erhalten.

Wesentliche Erkenntnisse

  1. Der Kontext stellt ein Arbeitsset dar. Eine dauerhafte Agentenmemorie erfordert einen separaten Zustandsvertrag.
  2. SGR und SGAM ergänzen sich gegenseitig: Zunächst muss die Schreiboperation validiert werden, anschließend muss das typisierte Lebenszyklusmanagement der Memorie im Ruhezustand gewährleistet sein.
  3. Vektorbasiertes Abrufen ist nützlich, doch aktuelle Fakten benötigen Angaben zu Reichweite, Gültigkeit, Überlagerung sowie Herkunft.
  4. Beginnen Sie mit einem einfachen relationellen oder JSON-basierten Memorielogbuch, bevor Sie auf Graphstrukturen ausweichen.
  5. Beurteilen Sie die Memorie anhand der Korrektheit von Schreibvorgängen, der zeitlichen Abruffähigkeit, der Verankerung in der Realität, der Isolierung der Benutzer sowie des Löschverhaltens.

Referenzen