TrueMem: Aufbau eines modellagnostischen Memory-Layers für KI

Das wöchentliche Ritual

Jeden Freitag tippe ich dasselbe:

"Ich bin Prathamesh. Senior Software Engineer bei TrueFoundry. Ich arbeite am Memory Service. Format: Was ich fertiggestellt habe, was in Arbeit ist, Blocker. Halte es kurz."

Dann bitte ich um mein wöchentliches Update.

Die KI schreibt es perfekt. Aber nächsten Freitag? Dasselbe Ritual. Sie erinnert sich weder an meinen Namen, meine Rolle, mein Projekt noch daran, dass ich drei Wochen hintereinander denselben Blocker erwähnt habe.

Ich habe diesen Assistenten selbst gebaut: einfaches Chat-UI, TrueFoundry AI Gateway im Backend. Er übernimmt Standups, E-Mails, Slack-Nachrichten, Dokumentationsentwürfe. Er ist wirklich nützlich. Aber jede Sitzung beginnt bei null. Ich nutze nicht den Speicher der KI. Ich bin der Speicher der KI.

ChatGPT hat dies mit integriertem Speicher gelöst. Wenn Sie jedoch Ihre eigene LLM-Anwendung bauen, existiert diese Infrastruktur nicht. Sie sind auf sich allein gestellt. Es sei denn, Sie bauen sie selbst.

Also habe ich das getan. TrueMem ist ein persistenter Memory-Layer für KI-Anwendungen. Er verleiht jedem LLM ein Langzeitgedächtnis, das über Sitzungen und sogar über verschiedene Modelle hinweg funktioniert. Kein Wiederholen mehr. Die KI erinnert sich tatsächlich.

Warum bestehende Ansätze nicht funktionieren

Die offensichtlichen Lösungen haben offensichtliche Probleme.

Der integrierte Speicher von ChatGPT ist im Ökosystem von OpenAI gefangen. Sie können nicht programmatisch darauf zugreifen, ihn mit anderen Modellen nutzen oder überprüfen, was gespeichert wird. TrueFoundrys AI Gateway hilft uns, auf mehrere Modelle zuzugreifen und zu überwachen, was gespeichert wird. Für jeden, der eigene Anwendungen baut, ist der integrierte ChatGPT-Speicher keine Option.

Retrieval-Augmented Generation (RAG) löst ein anderes Problem. RAG ruft Informationen aus Dokumenten ab. Es beantwortet "Was steht in diesem PDF?". Der Benutzerspeicher ist grundlegend anders. Er ist persönlich, entwickelt sich weiter und basiert auf Beziehungen. Die Fakten, die ich im Gespräch teile, sind keine zu indexierenden Dokumente; sie sind Kontext, der jede zukünftige Interaktion prägen sollte.

Das Erweitern von Kontextfenstern ist der Holzhammer-Ansatz: den gesamten Gesprächsverlauf einbeziehen. Moderne Modelle unterstützen 128K Tokens oder mehr, warum also nicht? Weil Tokens teuer sind, mehr Kontext eine langsamere Inferenz bedeutet und alles verschwindet, wenn die Sitzung endet. Sie zahlen einen Aufpreis für Amnesie mit zusätzlichen Schritten.

Was wir brauchen, ist ein dedizierter Layer, der destillierte Fakten über Benutzer dauerhaft speichert und nur das abruft, was für die jeweilige Anfrage relevant ist. Das ist die Lücke, die TrueMem schließt.

Lernen aus der Kognitionswissenschaft

Das menschliche Gedächtnis funktioniert nicht, indem es jedes Gespräch wortwörtlich speichert. Wir haben ein Arbeitsgedächtnis für die aktuelle Aufgabe und ein Langzeitgedächtnis für dauerhaftes Wissen. Die beiden Systeme interagieren ständig: Langzeiterinnerungen beeinflussen, wie wir neue Informationen interpretieren, während wichtige neue Erfahrungen im Langzeitspeicher konsolidiert werden.

TrueMem spiegelt diese Architektur mit zwei verschiedenen Komponenten wider: Kurzzeitgedächtnis (Short-Term Memory, STM) für den Gesprächskontext und Langzeitgedächtnis (Long-Term Memory, LTM) für permanente Benutzerfakten.

Die Trennung ist wichtig, weil diese Speichertypen unterschiedlichen Zwecken dienen. STM erfasst, was genau jetzt passiert, den vollständigen Fluss des aktuellen Gesprächs. LTM speichert destillierte Fakten, die über alle Gespräche hinweg bestehen bleiben. STM ist immer im Kontext enthalten; LTM wird basierend auf semantischer Relevanz abgerufen. Der Versuch, beides mit einem Mechanismus zu lösen, erzwingt Kompromisse. Der duale Ansatz vermeidet dies vollständig.

Kurzzeitgedächtnis: Gespräche kohärent halten

Innerhalb einer einzelnen Chat-Sitzung muss sich die KI daran erinnern, was Sie vor fünf Minuten besprochen haben. Das ist die Aufgabe von STM, und es verwaltet zwei Komponenten: eine fortlaufende Zusammenfassung älterer Nachrichten und die letzten zwanzig Nachrichten in voller Genauigkeit.

Mit wachsendem Gespräch verfolgen wir kontinuierlich die Gesamtzahl der Tokens. Wenn sie einen Schwellenwert überschreitet, komprimiert ein Background Worker ältere Nachrichten in die laufende Zusammenfassung, während neuere Nachrichten intakt bleiben.

‍

Die Zusammenfassung erfolgt asynchron, sodass Benutzer nie darauf warten müssen. Wenn der Schwellenwert überschritten wird, ruft ein Hintergrundjob nicht zusammengefasste Nachrichten ab, kombiniert sie mit einer eventuell vorhandenen Zusammenfassung und generiert eine aktualisierte, umfassende Zusammenfassung. Diese Nachrichten werden als "zusammengefasst" markiert und der Zyklus setzt sich fort. Progressive Komprimierung bedeutet, dass selbst stundenlange Gespräche innerhalb angemessener Kontextgrenzen bleiben.

Aber Gesprächskontext allein reicht nicht aus. Was passiert, wenn der Benutzer morgen zurückkehrt? Hier kommt das Langzeitgedächtnis ins Spiel.

Langzeitgedächtnis: Aufbau eines dauerhaften Verständnisses

LTM speichert Fakten über Benutzer, die unbegrenzt bestehen bleiben: ihren Namen, Beruf, Präferenzen, Kommunikationsstil und alles andere, was über Gespräche hinweg erhaltenswert ist. Diese werden nicht als Rohtext gespeichert. Sie werden in Vektor-Embeddings umgewandelt, was eine semantische Ähnlichkeitssuche ermöglicht.

Wenn ein Benutzer fragt "Welche Programmiersprache sollte ich verwenden?", führen wir keinen Keyword-Abgleich mit gespeicherten Erinnerungen durch. Wir betten die Anfrage ein und finden Erinnerungen, die semantisch verwandt sind. Erinnerungen wie "Benutzer bevorzugt Python" und "Arbeitet an ML-Infrastruktur" tauchen auf, weil sie konzeptionell relevant sind, selbst ohne gemeinsame Keywords.

Das System füllt das LTM über zwei Kanäle. Explizite Erinnerungen stammen aus direkten Aufforderungen: "Merke dir, dass ich Stichpunkte bevorzuge" oder "Vergiss nicht, dass ich allergisch gegen Erdnüsse bin." Wir erkennen Trigger-Phrasen, extrahieren den Kernfakt und speichern ihn mit höchster Wichtigkeit. Diese Erinnerungen werden niemals automatisch gelöscht.

Automatische Erinnerungen stammen aus der Gesprächsanalyse. Wenn ein Benutzer erwähnt "Ich habe das ML-Plattform-Team geleitet", ist das ein wertvoller Kontext, selbst ohne explizite Speicheranforderung. Nach jeder Interaktion untersucht ein Background Worker das Gespräch und extrahiert speicherwürdige Fakten, die jeweils mit einem Wichtigkeitswert versehen werden.

Wichtigkeitswerte reichen von eins bis fünf. Eine Fünf bedeutet kritische Informationen, die niemals vergessen werden sollten: explizite Anweisungen des Benutzers, starke Präferenzen, Allergien. Eine Vier steht für wichtige persönliche Fakten wie Beruf oder Wohnort. Dreier sind allgemeiner Kontext wie Hobbys und Interessen. Zweier decken temporäre Informationen wie aktuelle Projekte ab. Einer sind unbedeutende Details. Explizite Erinnerungen erhalten automatisch eine Fünf; automatische Extraktionen erreichen typischerweise Werte zwischen eins und vier, je nachdem, wie bedeutend der Fakt erscheint.

‍

Bei der automatischen Extraktion entsteht eine Herausforderung: Was ist, wenn ein Benutzer in einer Sitzung "Ich mag Python" und in einer anderen "Ich bevorzuge Python gegenüber JavaScript" sagt? Naives Speichern erzeugt Duplikate. TrueMem löst dies mit semantischer Deduplizierung. Vor dem Speichern suchen wir nach bestehenden Erinnerungen mit einer Ähnlichkeit von über 85 %. Wenn ein Beinahe-Duplikat existiert, aktualisieren wir es, anstatt einen neuen Eintrag zu erstellen. Die Datenbank bleibt sauber, wobei jeder Fakt genau einmal in seiner vollständigsten Form erscheint.

Datenschutz wird durch Transparenz gewährleistet. Benutzer können jede gespeicherte Erinnerung anzeigen, bearbeiten und löschen. Alle Erinnerungen sind strikt pro Benutzer isoliert. Für Enterprise-Deployments läuft das gesamte System auf Ihrer Infrastruktur. Nichts verlässt Ihre Umgebung.

Wie steht es um die Extraktionsgenauigkeit? Mehrere Mechanismen adressieren dies: Die Wichtigkeitsbewertung sorgt dafür, dass automatische Extraktionen vor expliziten Erinnerungen bereinigt werden; Benutzer können Fehler überprüfen und korrigieren; und korrekte Informationen, die über Gespräche hinweg verstärkt werden, akkumulieren eine höhere Wichtigkeit, während einmalige Fehlextraktionen durch natürliche Bereinigung verblassen.

Retrieval: Relevante Erinnerungen schnell finden

Das Speichern von Erinnerungen ist nur die halbe Miete. Wenn ein Benutzer eine Nachricht sendet, benötigen wir die richtige Teilmenge: nicht alles, nur das, was relevant ist. Ein Power-User verfügt möglicherweise über 150 gespeicherte Fakten; alle einzubeziehen, würde das Kontextfenster sprengen.

Der Prozess bettet die Nachricht des Benutzers ein, führt eine Cosine-Similarity-Suche durch und liefert die zehn besten Treffer zurück. Dies dauert bei ordnungsgemäßer Indexierung unter 10 Millisekunden.

Eine Ausnahme: neue Benutzer. Wenn jemand weniger als zehn Erinnerungen hat, beziehen wir sie alle ein, unabhängig von der Ähnlichkeit. Zu Beginn einer Beziehung zählt jedes Detail des Kontexts. Sobald die Anzahl zehn übersteigt, wechseln wir zu rein ähnlichkeitsbasiertem Retrieval.

Dieses Retrieval ist Teil eines größeren Kontextvorbereitungsablaufs und muss schnell sein.

Die Performance-Herausforderung

Ein Memory-Layer ist nur dann nützlich, wenn er keine spürbare Latenz verursacht. Benutzer reagieren empfindlich auf Verzögerungen; selbst 200 Millisekunden wirken träge. Unser Ziel lag unter 80 ms für die Kontextvorbereitung.

Der Schlüssel liegt in der Parallelisierung. Die Kontextvorbereitung umfasst mehrere unabhängige Operationen: Generieren eines Embeddings, Abrufen neuerer Nachrichten, Prüfen auf explizite Trigger und Durchsuchen des Langzeitgedächtnisses. Anstatt sie sequentiell auszuführen, starten wir sie parallel.

‍

Die Embedding-Generierung ist mit etwa 30 Millisekunden am langsamsten, läuft aber parallel zu Datenbankabfragen, die in 10 ms abgeschlossen sind. Wir zahlen für die längste Operation, nicht für die Summe. Die Gesamtlatenz liegt bei etwa 45 ms, weit unter dem Zielwert.

Schwere Operationen wie Zusammenfassungen und Speicherextraktionen laufen asynchron ab, nachdem die Antwort gesendet wurde. Der Benutzer wartet nie; die Verarbeitung erfolgt in Background Workern. Diese Trennung zwischen dem schnellen synchronen Pfad und dem langsamen asynchronen Pfad ist für den Produktionseinsatz unerlässlich.

Als das Gedächtnis zuverlässig funktionierte, zeigte sich ein unerwarteter Vorteil: Wir hatten versehentlich etwas Modellagnostisches gebaut.

Der unerwartete Vorteil: Kein Vendor Lock-in mehr

Was wir nicht vorhergesehen hatten: Sobald der Speicher außerhalb des Modells lebt, sind Sie nicht mehr an einen einzelnen Anbieter gebunden.

Von GPT-4 zu Claude wechseln? Ihr Speicher bleibt bestehen. Verschiedene Modelle für unterschiedliche Aufgaben nutzen, wie komplexes Reasoning mit dem einen und kreatives Schreiben mit dem anderen? Alle teilen dasselbe Verständnis über Sie. Ein benutzerdefiniertes Modell fine-tunen? Es erbt vom ersten Tag an bestehende Benutzerbeziehungen.

Der Memory-Layer wird zu Ihrer Konstante; Modelle werden austauschbar.

Die Integration bleibt minimal: Kontext vor dem LLM-Aufruf abrufen, die Interaktion danach protokollieren. Zwei API-Aufrufe verwandeln jedes zustandslose Modell in eines mit persistentem Speicher. Kein SDK-Lock-in, keine komplexe Integration. Nur HTTP-Endpunkte, die in jede Architektur passen.

Natürlich können Erinnerungen nicht ewig wachsen. Ein System ohne Lifecycle Management würde in veralteten Fakten ertrinken.

Memory Lifecycle Management

Jede Erinnerung hat einen Wichtigkeitswert von eins bis fünf. Explizite Anweisungen erhalten eine Fünf. Wichtige persönliche Fakten erhalten eine Vier. Allgemeiner Kontext erhält eine Drei. Temporäre Informationen erhalten eine Zwei. Unbedeutende Details erhalten eine Eins.

Wenn die Anzahl ein Soft Limit überschreitet (standardmäßig 150), setzt die Bereinigung (Pruning) ein. Das System tastet Wichtigkeiten von vier oder höher niemals an. Bei Erinnerungen mit geringerer Wichtigkeit entfernt es zuerst diejenigen mit der niedrigsten Bewertung, wobei das Alter als Entscheidungskriterium dient.

Explizite Anweisungen des Benutzers überstehen diese Bereinigung unbegrenzt. Automatische Extraktionen mit geringem Wert werden recycelt, um Platz für neue Informationen zu schaffen. Der Speicher bleibt ohne manuelle Pflege relevant.

Alles zusammengefügt

Ein Benutzer öffnet einen Chat und tippt: "Hilf mir, mein wöchentliches Update zu erstellen, basierend auf folgenden Punkten …"

‍

Die App ruft TrueMem für den Kontext auf. TrueMem stellt STM und relevantes LTM zusammen, darunter "Name ist Prathamesh", "Senior ML Engineer", "Arbeitet am Memory Service". Dies dauert 45 Millisekunden.

Das LLM generiert eine personalisierte Antwort: "Hier ist dein wöchentliches Update, Prathamesh..." Kein Ritual. Keine erneute Vorstellung. Die KI weiß, wer fragt.

Nach dem Antworten protokolliert die App die Interaktion. Background Worker speichern Nachrichten, extrahieren neue Fakten und aktualisieren Zusammenfassungen nach Bedarf. Die schwere Arbeit geschieht unsichtbar.

Technische Entscheidungen

Wir haben uns aus pragmatischen Gründen für PostgreSQL mit pgvector anstelle dedizierter Vektordatenbanken entschieden. Die meisten Teams nutzen bereits Postgres. Erinnerungen liegen zusammen mit Benutzerdaten und bieten vollständige ACID-Garantien. Für benutzerbezogene Sammlungen von 100-200 Vektoren liefert pgvector Ähnlichkeitssuchen in unter 10 ms. Für benutzerbezogenen Speicher ist es die richtige Wahl.

Background Worker laufen auf Redis-basierten Warteschlangen, da LLM-Aufrufe Sekunden dauern – viel zu lang, um Anfragen zu blockieren. Worker können Fehler erneut versuchen, Operationen zusammenfassen (Batching) und unabhängig skalieren, ohne die für den Benutzer sichtbare Latenz zu beeinträchtigen.

Keine Rituale mehr

Erinnern Sie sich an das Freitagsritual? "Ich bin Prathamesh. Senior Software Engineer. Ich arbeite am Memory Service."

Mit TrueMem passiert das genau einmal. Die KI erinnert sich. Das Update am nächsten Freitag funktioniert einfach. Der E-Mail-Entwurf im nächsten Monat kennt meine Signatur. Der Kontext ist immer da.

Noch besser: Wechseln Sie zu einem anderen Modell, und der Speicher wird übertragen. Der tägliche Assistent wird ohne Zusatzaufwand modellagnostisch.

Das ist das Ziel. KI, die sich an Sie erinnert. Nicht, weil Sie sie ständig daran erinnern, sondern weil sie es tatsächlich tut.

‍