Memory OS: Reasoning-Paradoxon und SGR im Agentenspeicher

Memory OS Architektur: Von Reasoning-Paradoxen zu hierarchischen Speichergrafen

Leistungsstarke Modelle wie o4-mini mit hohem reasoning_effort brechen die Schema-Strenge bei der strukturierten Objektextraktion. Statt sich an Pydantic-Schemata zu halten, beginnt das Modell, die Struktur zu "verbessern": Objekte werden zusammengeführt, JSON-Felder angepasst und Konzepttypen verschwimmen. Tests mit über 300 Prompts zeigten eine umgekehrte Beziehung: Mehr Reasoning führt zu weniger Determinismus.

SGR (Schema-Guided Reasoning) mit response_format und striktem StrictBase (extra='forbid', keine Optional/default) löst das Problem teilweise, doch das Modell kämpft weiter gegen die Einschränkungen. Die Einführung eines Semantic Mapper reduzierte reasoning_effort, indem Disziplin auf Datenverträge, Validierung und Nachbearbeitung verlagert wurde.

Ergebnisse:

• Token-Kosten sanken um 48 %;
• Extraktionsqualität stieg von 5,2 auf 7,11;
• Volle Nachverfolgbarkeit über message_id.

Der Validator prüft das JSON-Schema rekursiv: additionalProperties: false, alle Felder in required. Dies dient als Kernsignal für Agentenspeicher: LLM-Intelligenz bei der Extraktion ist für Schema-Ausführung gedacht, nicht für Kreativität.

Warum Flat RAG bei großen Datensätzen scheitert und der Wechsel zu verwaltetem Speicher

Flat RAG glänzt in Demos, bricht aber bei großen Korpora wie Jocker (3.253 Gespräche, 24.639 Nachrichten) zusammen: Keine Herkunft, zeitliche Semantik oder Update-Regeln. Retrieval holt ähnliche Chunks ohne Quellenverknüpfung, was zu Graph Sludge führt – Tausende Knoten ohne Granularität (über 26.000 in Jocker vor Refactoring).

Schichtentrennung ist essenziell:

• Retrieval: Top-k ähnliche Chunks;
• Speicher: Wissensobjekte, Verknüpfungen, zeitliche Änderungen, Revisionen, Abbau.

Ohne das artet das System zu einem Chunk-Index mit Halluzinationen bei komplexen Abfragen aus.

Kernontologie: ConceptHypothesis als Bürger erster Klasse

Wir starten mit einer Kernontologie mit typisierten Objekten und Relationen. Weg mit lockeren Entitäten/Zusammenfassungen, hin zu ConceptHypothesis:

from pydantic import BaseModel, ConfigDict, Field
from typing import List, Literal, Optional
from datetime import datetime

class StrictBase(BaseModel):
    model_config = ConfigDict(extra="forbid")

class EvidenceSpan(StrictBase):
    source_id: str
    message_id: str
    text: str
    confidence: float

class ConceptRelation(StrictBase):
    target_id: str
    relation: Literal["causes", "conflicts_with", "supports", "instance_of", "enables"]
    confidence: float

class ConceptHypothesis(StrictBase):
    concept_id: str
    title: str
    type: Literal["behavioral_pattern", "project", "event", "tension", "goal", "belief", "entity"]
    description: str
    state: Literal["active", "weak", "merged", "split", "archived"]
    confidence: float
    aliases: List[str]
    evidence_spans: List[EvidenceSpan]
    relations: List[ConceptRelation]
    revision_count: int
    first_seen: Optional[datetime]
    last_seen: Optional[datetime]

Dieses Objekt trägt Evidence-Spans, Relationen, Confidence und revision_count. Temporales Reasoning (Ereignisse, Widersprüche) ist erstklassig, kein Chunk-Nebenprodukt.

Datenverträge und Staging: SQLite als einzige Wahrheit

Datenverträge fixieren die Struktur an Pipeline-Grenzen. SQLite ist die Wahrheit für Nachrichten (UUID, Text, Rolle, parent_id, Timestamp, conversation_id). Neo4j-Graph: Knoten wie Conversation/Message/Segment/Concept/Topic, Kanten wie HAS_MESSAGE/NEXT/CONTAINS_MESSAGE/EVIDENCE_FOR/BELONGS_TO.

Der Schlüssel ist EVIDENCE_FOR: Konzepte verknüpfen direkt mit Nachrichten-Evidenz. Chronologisches NEXT/PREVIOUS-Gerüst beschleunigt Inferenz ohne Datenbank-Sortierung.

Staging-Datenbank (separates SQLite) speichert Pipeline-Zwischenzustände für volle Auditierbarkeit.

Concept Memory Loop und Topic-Clustering

Concept Memory Loop: Erstellen/Anhängen/Verfeinern/Verwerfen – der Hypothesen-Management-Zyklus. Topic-Clustering via UMAP + HDBSCAN + Optuna für gewichtete Verknüpfungen verhindert Überkompression und Konzept-Explosion.

LongMemEval und zuständige Multi-Agent-Inferenz

LongMemEval (über 100 Mio. Tokens): 4 Debug-Phasen, Exploration vs. Execution. Zuständige Multi-Agenten: Planner/Scout/Synthesizer für hierarchisches Retrieval.

Agentischer Gärtner, Invalidierung und MCP

Agentischer Gärtner – dedizierte Graph-Wartungspipeline. Invalidierung/Reparatur für bi-temporale Fakten. MCP – souveräne Speicher-Schnittstelle.

Maßstab: 106,7 Mio. Tokens, 632.868 semantische Einheiten, 2,4 Mio. Kanten.

Wichtige Erkenntnisse:

• Hohes Reasoning bricht SGR; Semantic Mapper und niedriges Effort nutzen;
• Flat RAG → Graph Sludge; Evidence-Spans und temporale Ontologie fordern;
• ConceptHypothesis mit Pydantic StrictBase – Basis für verwaltete Kompression;
• SQLite als Wahrheit + Neo4j für Herkunft und Chronologie;
• Multi-Agent + Gärtner für 100-Mio.-Token-Skala.

— Editorial Team