Konzepte

Wie die Memory Engine Informationen speichert, versteht und wieder abruft.

Vaults

Ein Vault ist ein isolierter Datenraum mit eigenem Verschlüsselungs-Key, eigener Konfiguration und eigenen API-Keys. Daten aus verschiedenen Vaults können sich nie gegenseitig sehen - die Isolation geschieht auf Datenbankebene per Row-Level Security.

Typische Aufteilung: ein Vault pro App, oder ein Vault pro Umgebung (Staging/Production).

Organisationen

Eine Organisation gruppiert User und Vaults. Jeder User gehoert zu mindestens einer Organisation. Org-Owner verwalten Members und setzen Limits (max. Vaults pro Member, max. Vaults pro Org).

Wichtig: Org-Membership und Vault-Zugriff sind getrennte Konzepte. Ein Org-Member hat nicht automatisch Zugriff auf alle Vaults der Org — Vault-Zugriff wird separat ueber Sharing vergeben.

User mit mehreren Organisationen koennen ueber den Org-Picker in der Sidebar zwischen ihren Orgs wechseln. Die aktive Organisation bestimmt welche Vaults angezeigt werden.

Scopes

Innerhalb eines Vaults gibt es drei Isolationsebenen:

Organization: Vault-weit sichtbar. Standard für die meisten Memories.
Area: Thematisch eingegrenzt. Nur sichtbar wenn der Kontext diesen Bereich abfragt. Nützlich für Projekt- oder Thementrennung innerhalb eines Vaults.
Persoenlich: Nur für den erstellenden User sichtbar. Andere User im selben Vault sehen diese Memories nicht.

Vier Gedächtnisebenen

Das Modell orientiert sich an der kognitiven Psychologie (Tulving, Atkinson-Shiffrin). Vier Ebenen mit unterschiedlichen Speicher- und Abruf-Charakteristiken:

Working Memory

Session-Kontext. Die letzten 3-5 Interaktionen, max 8.000 Tokens. Existiert nur waehrend der Session, keine Persistenz.

Episodic Memory

Konkrete Fakten. "Meeting mit Lisa am Donnerstag", "Projekt-Deadline ist der 15. April". Jeder Fakt hat einen Confidence-Score, verliert über die Zeit an Wichtigkeit (Decay) und wird bei jedem Abruf aufgefrischt (Rehearsal).

Semantic Memory

Verdichtetes Wissen. Entsteht wenn mehrere episodische Fakten zu einer Entität konsolidiert werden. "Lisa ist Projektleiterin, bevorzugt asynchrone Kommunikation, hat Q2-Budget-Verantwortung." Profile werden versioniert, nie ueberschrieben.

Prospective Memory

Zukunftsgerichtete Erinnerungen. Zeitbasiert ("Erinnere mich am 15. April") oder eventbasiert ("Wenn jemand X erwähnt, erinnere mich an Y"). Wird bei jedem Ingest geprüft.

Extraction Pipeline

Wenn du memory_store aufrufst, passiert Folgendes:

Der Text wird an ein LLM geschickt, das strukturierte Fakten extrahiert - mit Kategorie, Entitaeten (mehrere pro Fakt moeglich), Confidence und Importance.
Confidence-Routing: Fakten mit hoher Confidence (≥0.85) werden direkt gespeichert. Mittlere (0.4-0.84) landen als Draft zur Prüfung. Niedrige werden verworfen.
Jina AI erzeugt ein 512-dimensionales Embedding für Vektor-Suche.
Conflict Detection prüft ob der neue Fakt einem bestehenden widerspricht.
Alles wird AES-256-GCM verschlüsselt in der Datenbank gespeichert.

Drafts - Human-in-the-Loop

Nicht jeder extrahierte Fakt ist korrekt. Fakten mit mittlerer Confidence (0.4-0.84) werden als Draft gespeichert statt direkt als aktive Memory. Ein Draft wartet auf menschliche Prüfung.

Accept

Der Fakt ist korrekt. Wird als aktive Memory gespeichert und taucht ab sofort im Retrieval auf.

Edit + Accept

Der Fakt ist teilweise korrekt. Du korrigierst den Text, dann wird er als Memory gespeichert.

Reject

Der Fakt ist falsch oder irrelevant. Wird verworfen.

Die Engine lernt aus deinen Entscheidungen. Pro Confidence-Band wird die Akzeptanzrate gemessen. Wenn ein Band konsistent hohe Akzeptanzraten zeigt (≥95% nach 50+ Reviews), werden die Schwellenwerte automatisch angepasst - mehr Fakten werden direkt gespeichert, weniger landen als Draft. Das System kalibriert sich pro Vault.

Ungeprüfte Drafts verfallen nach 14 Tagen automatisch. Tool: memory_draft_review

Retrieval

memory_retrieve nutzt vier parallele Suchpfade:

BM25 Keyword-Suche - exakte Wort-Treffer
Embedding-Suche - semantische Ähnlichkeit per Cosine-Similarity
Pinned/High-Importance - vom User priorisierte Memories
Semantic Profile Matching - Abgleich mit verdichteten Entity-Profilen

Die Ergebnisse werden per Reciprocal Rank Fusion (RRF) zusammengeführt, optional durch einen Cross-Encoder (Jina Reranker) re-ranked, und final nach drei Faktoren sortiert: Aktualität × Wichtigkeit × Relevanz.

Decay und Briefings

Memories verlieren über die Zeit an Wichtigkeit - konfigurierbar per Source-Typ und Kategorie. Jeder Memory hat eine Grace Period (z.B. 30 Tage ohne Decay) und danach einen täglichen Multiplikator (z.B. 0.98 = 2% Verlust pro Tag). Wenn ein Memory abgerufen wird, wird sein Importance-Score aufgefrischt (Rehearsal-Mechanismus).

memory_briefing generiert regelmäßige Zusammenfassungen aus allen aktiven Memories, Drafts und ausgelösten Prospective-Memory-Zielen.

Domain-Config

Jeder Vault hat eine eigene Konfiguration die bestimmt, was und wie die Engine extrahiert:

Categories - Welche Informationstypen erkannt werden (z.B. "termin", "entscheidung", "recherche")
Entity Types - Welche Entitaeten verknuepft werden (z.B. "person", "projekt", "anmelder"). Ein Fakt kann mehrere Entitaeten haben - z.B. wird "Meeting zwischen Lisa und Tom ueber Q3" mit allen drei Entitaeten verknuepft.
Extraction Prompt - Die Anweisung an das LLM, wie Fakten extrahiert werden sollen
Briefing Prompt - Wie Briefings strukturiert werden
Decay Rates - Wie schnell Memories an Wichtigkeit verlieren, pro Source und Kategorie

Beim Vault-Erstellen wählst du eines von 8 Templates (Standard, Developer, Persönlicher Assistent, Customer Support, Research, und weitere). Danach kannst du alles im Config-Editor anpassen.

Connectors

Connectors importieren automatisch Inhalte aus externen Systemen: RSS-Feeds, GitHub-Repositories, Confluence-Spaces, Jira-Projekte. Ein BullMQ-Worker prueft periodisch auf neue Inhalte und schickt sie durch die Extraction-Pipeline. Jeder importierte Fakt behaelt eine source_ref — die URL zum Originaldokument.

Mehr dazu: Connectors

Supervaults und Cross-Tenant Queries

Vaults koennen zu Gruppen gebuendelt werden (max 5 pro Gruppe). Ein Super-Key gibt Zugriff auf alle Vaults der Gruppe. Bei Abfragen werden alle Vaults parallel durchsucht, Scores normalisiert und Ergebnisse zusammengefuehrt. Beim Speichern routet entweder das LLM (via target_tenant) oder der Engine-Side Smart Router den Fakt zum passenden Vault.

Mehr dazu: Vault-Sharing und Gruppen

Forschungsgrundlagen

Die Architektur der Engine basiert auf Modellen aus der kognitiven Psychologie und aktueller KI-Forschung. Jede der folgenden Theorien ist direkt im Code implementiert - keine Marketing-Analogie, sondern echte Umsetzung.

Tulving - Episodisches vs. Semantisches Gedächtnis (1972)

Endel Tulving unterschied zwei Formen des Langzeitgedächtnisses: episodisch (konkrete Erlebnisse mit Kontext) und semantisch (verdichtetes, kontextfreies Wissen). Die Engine bildet das mit zwei getrennten Tabellen ab — memory für Einzelfakten und semantic_memory für konsolidierte Profile. Die Konsolidierung läuft über LLM-gestützte Zusammenfassung.

Complementary Learning Systems - McClelland et al. (1995)

Das Gehirn nutzt zwei komplementäre Systeme: der Hippocampus speichert schnell einzelne Erfahrungen, der Neokortex integriert sie langsam in stabile Repräsentationen. Die Engine macht dasselbe: memory_store speichert sofort (Hippocampus), memory_consolidate verdichtet über Schwellenwerte (Neokortex). Episodische Fakten werden dabei nie gelöscht - Profile werden versioniert.

Ebbinghaus - Vergessenskurve (1885)

Erinnerungen verlieren exponentiell an Stärke. Die Engine implementiert das mit source-abhängigen Decay-Raten: automatisch extrahierte Fakten verfallen schneller (0.98/Tag) als vom User bestätigte (0.995/Tag) oder manuell erstellte (0.998/Tag). Jede Erinnerung hat eine Grace Period ohne Decay. Wird ein Fakt abgerufen, wird der Decay-Timer zurückgesetzt (Rehearsal-Mechanismus nach Atkinson & Shiffrin, 1968).

Einstein & McDaniel - Prospective Memory (1990)

Prospektives Gedächtnis ist die Fähigkeit, sich an zukünftige Absichten zu erinnern. Die Engine unterstützt zeitbasierte Ziele (Deadline) und eventbasierte Trigger. Eventbasierte Trigger nutzen Embedding-Similarity: bei jedem memory_store wird geprüft, ob der neue Inhalt einem gespeicherten Trigger semantisch ähnelt.

Park et al. - Generative Agents (2023)

Das Scoring-Modell aus der Stanford-Studie: Retrieval-Ergebnisse werden nach drei Faktoren gerankt — Aktualität (exponentieller Recency-Score), Wichtigkeit (mit Decay) und Relevanz (aus Hybrid-Retrieval). Die Gewichtung (α, β, γ) ist pro Vault konfigurierbar.

Packer et al. - Inner Monologue (MemGPT, 2023)

Das LLM denkt bei der Extraktion laut nach: Importance-Score mit Begründung, Kontextbezug zu bestehenden Kategorien, Confidence-Einschätzung. Der Inner Monologue wird gespeichert aber nicht dem User gezeigt — er dient der Nachvollziehbarkeit und verbessert die Extraktionsqualität.

Guo et al. - Confidence Calibration (ICML, 2017)

Neuronale Netze sind schlecht kalibriert - ihre Confidence-Scores spiegeln nicht die tatsächliche Korrektheit wider. Die Engine lernt aus Accept/Reject-Entscheidungen: pro Confidence-Band wird die Akzeptanzrate gemessen und die Schwellenwerte pro Vault automatisch nachjustiert.