Überlegungen zu ChatGPT und Claude's Memory Systems: Was es braucht, um den Abruf von Konversationen auf Abruf zu ermöglichen

Bei hochwertigen KI-Agenten-Systemen ist die Gestaltung des Speichers weitaus komplexer, als es zunächst scheint. Im Kern geht es um die Beantwortung von drei grundlegenden Fragen: Wie soll der Gesprächsverlauf gespeichert werden? Wann soll der vergangene Kontext abgerufen werden? Und was genau soll abgerufen werden?

Diese Entscheidungen wirken sich direkt auf die Reaktionszeit, die Ressourcennutzung und letztlich auf die maximale Leistungsfähigkeit eines Agenten aus.

Modelle wie ChatGPT und Claude werden immer "gedächtnisbewusster", je mehr wir sie einsetzen. Sie merken sich Präferenzen, passen sich an langfristige Ziele an und behalten die Kontinuität über Sitzungen hinweg bei. In diesem Sinne funktionieren sie bereits wie Mini-KI-Agenten. Unter der Oberfläche jedoch basieren ihre Speichersysteme auf sehr unterschiedlichen architektonischen Annahmen.

Jüngste Reverse-Engineering-Analysen der Speichermechanismen von ChatGPTund Claude zeigen einen deutlichen Unterschied. ChatGPT verlässt sich auf vorberechnete Kontextinjektion und Layered Caching, um eine leichtgewichtige, vorhersehbare Kontinuität zu gewährleisten. Claude hingegen verwendet RAG-ähnliche On-Demand-Abrufe mit dynamischen Speicheraktualisierungen, um ein Gleichgewicht zwischen Speichertiefe und Effizienz herzustellen.

Bei diesen beiden Ansätzen handelt es sich nicht nur um Designvorlieben, sondern auch um die Möglichkeiten der Infrastruktur. Milvus 2.6 führt die Kombination aus hybridem Dense-parse Retrieval, effizienter skalarer Filterung und abgestuftem Speicher ein, die für On-Demand-Conversational-Memory erforderlich ist, wodurch das selektive Retrieval schnell und wirtschaftlich genug ist, um in realen Systemen eingesetzt zu werden.

In diesem Beitrag gehen wir darauf ein, wie die Speichersysteme von ChatGPT und Claude tatsächlich funktionieren, warum sie sich architektonisch unterschieden haben und wie die jüngsten Fortschritte in Systemen wie Milvus die Abfrage von Konversationen auf Abruf in großem Maßstab praktisch machen.

ChatGPTs Speichersystem

Anstatt eine Vektordatenbank abzufragen oder vergangene Unterhaltungen dynamisch abzurufen, baut ChatGPT sein "Gedächtnis" auf, indem es einen festen Satz von Kontextkomponenten zusammenstellt und sie direkt in jede Eingabeaufforderung einfügt. Jede Komponente wird im Voraus vorbereitet und nimmt eine bekannte Position im Prompt ein.

Durch dieses Design bleiben die Personalisierung und die Kontinuität der Konversation erhalten, während die Latenzzeit, die Verwendung von Token und das Systemverhalten besser vorhersehbar sind. Mit anderen Worten: Speicher ist nicht etwas, das das Modell spontan sucht, sondern etwas, das das System verpackt und dem Modell jedes Mal zur Verfügung stellt, wenn es eine Antwort erzeugt.

Im Großen und Ganzen besteht eine vollständige ChatGPT-Eingabeaufforderung aus den folgenden Schichten, geordnet von der globalsten zur unmittelbarsten:

[0] Systemanweisungen

[1] Anweisungen für Entwickler

[2] Sitzungs-Metadaten (kurzlebig)

[3] Benutzerspeicher (langfristige Fakten)

[4] Recent Conversations Summary (vergangene Chats, Titel + Ausschnitte)

[5] Aktuelle Sitzungsnachrichten (dieser Chat)

[6] Ihre letzte Nachricht

Die Komponenten [2] bis [5] bilden das effektive Gedächtnis des Systems und erfüllen jeweils eine bestimmte Funktion.

Sitzungs-Metadaten

Sitzungs-Metadaten sind kurzlebige, nicht-persistente Informationen, die einmal zu Beginn einer Konversation eingefügt und nach Beendigung der Sitzung verworfen werden. Ihre Aufgabe ist es, das Modell an den aktuellen Nutzungskontext anzupassen und nicht, das Verhalten langfristig zu personalisieren.

Diese Schicht erfasst Signale über die unmittelbare Umgebung des Benutzers und seine jüngsten Nutzungsmuster. Typische Signale sind:

• Geräteinformationen - z. B. ob der Benutzer ein Mobiltelefon oder einen Desktop benutzt

• Kontoattribute - wie die Abonnementstufe (z. B. ChatGPT Go), das Alter des Kontos und die allgemeine Nutzungshäufigkeit

• Verhaltensmetriken - einschließlich aktiver Tage in den letzten 1, 7 und 30 Tagen, durchschnittliche Gesprächslänge und Modellnutzungsverteilung (z. B. 49 % der Anfragen wurden von GPT-5 bearbeitet)

Benutzerspeicher

Der Benutzerspeicher ist die dauerhafte, bearbeitbare Speicherschicht, die eine Personalisierung über Konversationen hinweg ermöglicht. Sie speichert relativ stabile Informationen - wie den Namen des Benutzers, seine Rolle oder Karriereziele, laufende Projekte, frühere Ergebnisse und Lernpräferenzen - und wird in jede neue Konversation eingefügt, um die Kontinuität über die Zeit zu wahren.

Dieser Speicher kann auf zwei Arten aktualisiert werden:

• Explizite Aktualisierungen erfolgen, wenn die Benutzer den Speicher direkt mit Anweisungen wie "merke dir das" oder "lösche das aus dem Speicher" verwalten.

• Implizite Aktualisierungen erfolgen, wenn das System Informationen identifiziert, die den Speicherkriterien von OpenAI entsprechen - wie z. B. ein bestätigter Name oder eine Berufsbezeichnung - und diese automatisch speichert, vorbehaltlich der standardmäßigen Zustimmung und Speichereinstellungen des Benutzers.

Zusammenfassung der letzten Konversation

Die Zusammenfassung der letzten Konversation ist eine leichtgewichtige, sitzungsübergreifende Kontextebene, die die Kontinuität bewahrt, ohne den gesamten Chatverlauf erneut abzuspielen oder abzurufen. Anstatt sich auf einen dynamischen Abruf zu verlassen, wie es bei traditionellen RAG-basierten Ansätzen der Fall ist, wird diese Zusammenfassung vorberechnet und direkt in jede neue Unterhaltung eingefügt.

Diese Schicht fasst nur Nutzernachrichten zusammen, ohne die Antworten der Assistenten. Ihre Größe ist absichtlich begrenzt - typischerweise etwa 15 Einträge - und sie enthält nur hochrangige Signale über aktuelle Interessen, nicht aber detaillierte Inhalte. Da sie sich nicht auf Einbettungen oder Ähnlichkeitssuche stützt, hält sie sowohl die Latenzzeit als auch den Token-Verbrauch niedrig.

Aktuelle Sitzungsnachrichten

Aktuelle Sitzungsnachrichten enthalten den vollständigen Nachrichtenverlauf der laufenden Konversation und liefern den kurzfristigen Kontext, der für kohärente Turn-by-Turn-Antworten erforderlich ist. Diese Schicht umfasst sowohl Benutzereingaben als auch Antworten des Assistenten, jedoch nur solange die Sitzung aktiv ist.

Da das Modell mit einem festen Token-Limit arbeitet, kann dieser Verlauf nicht unbegrenzt wachsen. Wenn das Limit erreicht ist, lässt das System die ältesten Nachrichten fallen, um Platz für neuere zu schaffen. Diese Kürzung wirkt sich nur auf die aktuelle Sitzung aus: Das Langzeitgedächtnis des Benutzers und die Zusammenfassung der letzten Unterhaltung bleiben intakt.

Das Speichersystem von Claude

Claude verfolgt einen anderen Ansatz bei der Speicherverwaltung. Anstatt ein großes, festes Bündel von Speicherkomponenten in jede Eingabeaufforderung einzubauen - wie es ChatGPT tut -, kombiniert Claude persistenten Benutzerspeicher mit On-Demand-Tools und selektivem Abruf. Historischer Kontext wird nur dann abgerufen, wenn das Modell ihn als relevant erachtet, so dass das System die Tiefe des Kontexts gegen die Rechenkosten abwägen kann.

Der Prompt-Kontext von Claude ist wie folgt strukturiert:

[0] System-Eingabeaufforderung (statische Anweisungen)

[1] Benutzererinnerungen

[2] Konversationsverlauf

[3] Aktuelle Nachricht

Die Hauptunterschiede zwischen Claude und ChatGPT liegen in der Art und Weise, wie der Gesprächsverlauf abgerufen wird und wie der Benutzerspeicher aktualisiert und gepflegt wird.

Benutzererinnerungen

In Claude bilden die Benutzerspeicher eine langfristige Kontextebene, die dem Benutzergedächtnis von ChatGPT ähnelt, aber stärker auf automatische, im Hintergrund ablaufende Aktualisierungen ausgerichtet ist. Diese Erinnerungen werden in einem strukturierten Format (in XML-ähnlichen Tags) gespeichert und sind so konzipiert, dass sie sich im Laufe der Zeit mit minimalem Benutzereingriff weiterentwickeln.

Claude unterstützt zwei Aktualisierungspfade:

• Implizite Aktualisierungen - Das System analysiert regelmäßig den Gesprächsinhalt und aktualisiert den Speicher im Hintergrund. Diese Aktualisierungen werden nicht in Echtzeit durchgeführt, und die mit gelöschten Konversationen verbundenen Speicher werden im Rahmen der laufenden Optimierung nach und nach entfernt.

• Explizite Aktualisierungen - Benutzer können den Speicher direkt über Befehle wie "dies merken" oder "dies löschen" verwalten, die über ein spezielles Tool memory_user_edits ausgeführt werden.

Im Vergleich zu ChatGPT überträgt Claude dem System selbst mehr Verantwortung für die Verfeinerung, Aktualisierung und Bereinigung des Langzeitgedächtnisses. Dies reduziert die Notwendigkeit für die Benutzer, aktiv zu kuratieren, was gespeichert wird.

Konversationsverlauf

Für den Gesprächsverlauf verlässt sich Claude nicht auf eine feste Zusammenfassung, die bei jedem Prompt eingeblendet wird. Stattdessen werden vergangene Kontexte nur dann abgerufen, wenn das Modell dies für notwendig erachtet, wobei drei verschiedene Mechanismen zum Einsatz kommen. Auf diese Weise wird vermieden, dass irrelevante Vorgänge mitgeschleppt werden, und die Verwendung von Token bleibt unter Kontrolle.

Komponente	Zweck	Wie sie verwendet wird
Rolling Window (Aktuelle Konversation)	Speichert den vollständigen Nachrichtenverlauf der aktuellen Konversation (keine Zusammenfassung), ähnlich wie der Sitzungskontext von ChatGPT	Wird automatisch eingespeist. Token-Limit ist ~190K; ältere Nachrichten werden verworfen, sobald das Limit erreicht ist
conversation_search Werkzeug	Durchsucht vergangene Unterhaltungen nach Themen oder Schlüsselwörtern und liefert Links zu Unterhaltungen, Titel und Auszüge von Benutzer-/Assistentennachrichten	Wird ausgelöst, wenn das Modell feststellt, dass historische Details benötigt werden. Zu den Parametern gehören query (Suchbegriffe) und max_results (1-10)
recent_chats Werkzeug	Ruft die jüngsten Unterhaltungen innerhalb eines bestimmten Zeitraums ab (z. B. "letzte 3 Tage"), wobei die Ergebnisse wie folgt formatiert werden conversation_search	Wird ausgelöst, wenn der aktuelle, zeitlich begrenzte Kontext relevant ist. Zu den Parametern gehören n (Anzahl der Ergebnisse), sort_order und der Zeitbereich

Unter diesen Komponenten ist conversation_search besonders erwähnenswert. Sie kann relevante Ergebnisse selbst für lose formulierte oder mehrsprachige Suchanfragen anzeigen, was darauf hindeutet, dass sie auf semantischer Ebene arbeitet und sich nicht auf den einfachen Abgleich von Schlüsselwörtern verlässt. Wahrscheinlich handelt es sich dabei um ein einbettungsbasiertes Retrieval oder um einen hybriden Ansatz, bei dem die Anfrage zunächst in eine kanonische Form übersetzt oder normalisiert wird und dann ein Keyword- oder Hybrid-Retrieval erfolgt.

Insgesamt hat der On-Demand-Abrufansatz von Claude mehrere bemerkenswerte Stärken:

• Der Abruf erfolgt nicht automatisch: Tool-Aufrufe werden durch das eigene Urteil des Modells ausgelöst. Wenn sich ein Benutzer beispielsweise auf "das Projekt, das wir beim letzten Mal besprochen haben" bezieht , kann Claude entscheiden, conversation_search aufzurufen, um den relevanten Kontext abzurufen.

• Umfassenderer Kontext bei Bedarf: Die abgerufenen Ergebnisse können Auszüge aus den Antworten der Assistenten enthalten, während die Zusammenfassungen von ChatGPT nur die Nutzernachrichten erfassen. Dadurch ist Claude besser für Anwendungsfälle geeignet, die einen tieferen oder präziseren Gesprächskontext erfordern.

• Bessere Effizienz durch Voreinstellung: Da historischer Kontext nur bei Bedarf eingespeist wird, vermeidet das System die Übertragung großer Mengen irrelevanter Daten und reduziert so den unnötigen Token-Verbrauch.

Die Nachteile liegen ebenfalls auf der Hand. Die Einführung der On-Demand-Abfrage erhöht die Systemkomplexität: Indizes müssen erstellt und gepflegt, Abfragen ausgeführt, Ergebnisse eingestuft und manchmal neu eingestuft werden. Auch die End-to-End-Latenz wird weniger vorhersehbar als bei einem vorberechneten, stets eingefügten Kontext. Darüber hinaus muss das Modell lernen zu entscheiden, wann ein Abruf notwendig ist. Wenn diese Entscheidung fehlschlägt, wird der relevante Kontext möglicherweise gar nicht abgerufen.

Die Zwänge hinter dem Claude-Style On-Demand Retrieval

Die Einführung eines bedarfsgesteuerten Abrufmodells macht die Vektordatenbank zu einem kritischen Teil der Architektur. Der Abruf von Konversationen stellt ungewöhnlich hohe Anforderungen an die Speicherung und die Ausführung von Abfragen, und das System muss vier Bedingungen gleichzeitig erfüllen.

1. Niedrige Latenzzeittoleranz

In Konversationssystemen muss die P99-Latenz normalerweise unter ~20 ms bleiben. Verzögerungen, die darüber hinausgehen, werden von den Benutzern sofort wahrgenommen. Dies lässt wenig Spielraum für Ineffizienz: Vektorsuche, Metadatenfilterung und Ergebnisranking müssen alle sorgfältig optimiert werden. Ein Engpass an irgendeiner Stelle kann das gesamte Konversationserlebnis beeinträchtigen.

2. Hybride Suchanforderung

Benutzeranfragen erstrecken sich oft über mehrere Dimensionen. Eine Anfrage wie "Diskussionen über RAG der letzten Woche" kombiniert semantische Relevanz mit zeitbasierter Filterung. Wenn eine Datenbank nur die Vektorsuche unterstützt, kann es sein, dass sie 1.000 semantisch ähnliche Ergebnisse liefert, die dann durch die Filterung auf der Anwendungsebene auf eine Handvoll reduziert werden - was einen Großteil der Berechnungen verschlingt. Um praktikabel zu sein, muss die Datenbank von Haus aus kombinierte Vektor- und Skalarabfragen unterstützen.

3. Trennung von Speicherung und Berechnung

Der Gesprächsverlauf weist ein klares Hot-Cold-Zugriffsmuster auf. Aktuelle Konversationen werden häufig abgefragt, während ältere Konversationen nur selten angefasst werden. Müssten alle Vektoren im Speicher verbleiben, würde die Speicherung von mehreren zehn Millionen Konversationen Hunderte von Gigabyte an RAM verbrauchen - ein unpraktischer Kostenfaktor in großem Maßstab. Um praktikabel zu sein, muss das System eine Trennung von Speicher und Rechenleistung unterstützen, indem heiße Daten im Speicher und kalte Daten im Objektspeicher gehalten werden, wobei die Vektoren bei Bedarf geladen werden.

4. Vielfältige Abfragemuster

Die Abfrage von Konversationen folgt nicht einem einzigen Zugriffsmuster. Einige Abfragen sind rein semantisch (z. B. "die Leistungsoptimierung, die wir besprochen haben"), andere sind rein zeitlich ("alle Konversationen der letzten Woche"), und viele kombinieren mehrere Einschränkungen ("Diskussionen über Python, in denen FastAPI in den letzten drei Monaten erwähnt wurde"). Der Datenbank-Abfrageplaner muss die Ausführungsstrategien an die verschiedenen Abfragetypen anpassen, anstatt sich auf eine pauschale Brute-Force-Suche zu verlassen.

Zusammen definieren diese vier Herausforderungen die Kernbedingungen des Conversational Retrieval. Jedes System, das eine On-Demand-Suche im Stile von Claude implementieren will, muss alle diese Herausforderungen auf koordinierte Weise angehen.

Warum Milvus 2.6 für die konversationelle Suche gut funktioniert

Die Design-Entscheidungen in Milvus 2.6 stehen in engem Einklang mit den Kernanforderungen des On-Demand-Conversational Retrieval. Nachfolgend finden Sie eine Aufschlüsselung der Schlüsselfunktionen und deren Zuordnung zu den realen Anforderungen an die Gesprächsabfrage.

Hybrides Retrieval mit dichten und spärlichen Vektoren

Milvus 2.6 unterstützt von Haus aus die Speicherung von dichten und spärlichen Vektoren innerhalb derselben Sammlung und die automatische Zusammenführung ihrer Ergebnisse zur Abfragezeit. Dichte Vektoren (z.B. 768-dimensionale Einbettungen, die von Modellen wie BGE-M3 erzeugt werden) erfassen semantische Ähnlichkeit, während spärliche Vektoren (typischerweise von BM25 erzeugt) exakte Schlüsselwortsignale erhalten.

Für eine Abfrage wie "Diskussionen über RAG von letzter Woche" führt Milvus die semantische Suche und die Suche nach Schlüsselwörtern parallel aus und führt dann die Ergebnisse durch Reranking zusammen. Im Vergleich zur alleinigen Verwendung eines der beiden Ansätze liefert diese hybride Strategie in realen Konversationsszenarien eine deutlich höhere Trefferquote.

Speicher-Rechner-Trennung und Abfrageoptimierung

Milvus 2.6 unterstützt Tiered Storage auf zwei Arten:

• Heiße Daten im Speicher, kalte Daten im Objektspeicher

• Indizes im Arbeitsspeicher, Rohvektordaten im Objektspeicher

Mit diesem Design kann die Speicherung von einer Million Konversationseinträgen mit etwa 2 GB Arbeitsspeicher und 8 GB Objektspeicher erreicht werden. Mit der richtigen Einstellung kann die P99-Latenzzeit unter 20 ms bleiben, selbst wenn die Trennung von Speicher und Rechenleistung aktiviert ist.

JSON-Zerkleinerung und schnelle skalare Filterung

Milvus 2.6 aktiviert standardmäßig JSON Shredding, wodurch verschachtelte JSON-Felder in einem spaltenförmigen Speicher abgeflacht werden. Dies verbessert die Leistung der skalaren Filterung laut offiziellen Benchmarks um das 3-5fache (die tatsächlichen Gewinne variieren je nach Abfragemuster).

Die Abfrage von Konversationen erfordert häufig die Filterung nach Metadaten wie Benutzer-ID, Sitzungs-ID oder Zeitspanne. Mit JSON Shredding können Abfragen wie "alle Unterhaltungen von Benutzer A in der letzten Woche" direkt auf spaltenförmigen Indizes ausgeführt werden, ohne dass wiederholt ganze JSON-Blobs geparst werden müssen.

Open-Source-Kontrolle und betriebliche Flexibilität

Als Open-Source-System bietet Milvus ein Maß an architektonischer und betrieblicher Kontrolle, das geschlossene Black-Box-Lösungen nicht bieten. Teams können Indexparameter einstellen, Daten-Tiering-Strategien anwenden und verteilte Bereitstellungen an ihre Arbeitslasten anpassen.

Diese Flexibilität senkt die Einstiegshürde: Kleine und mittelgroße Teams können Conversational Retrieval-Systeme im Millionen- bis Zig-Millionen-Bereich aufbauen, ohne auf überdimensionierte Infrastrukturbudgets angewiesen zu sein.

Warum ChatGPT und Claude unterschiedliche Wege gegangen sind

Der Unterschied zwischen den Gedächtnissystemen von ChatGPT und Claude besteht im Wesentlichen darin, wie beide Systeme mit dem Vergessen umgehen. ChatGPT bevorzugt proaktives Vergessen: Sobald der Speicher eine festgelegte Grenze überschreitet, wird der ältere Kontext gelöscht. Damit wird Vollständigkeit gegen Einfachheit und vorhersehbares Systemverhalten eingetauscht. Claude bevorzugt das verzögerte Vergessen. Theoretisch kann der Gesprächsverlauf unbegrenzt wachsen, wobei der Abruf an ein Abrufsystem auf Abruf delegiert wird.

Warum also haben die beiden Systeme unterschiedliche Wege gewählt? Die Antwort liegt auf der Hand: Jede Architektur ist nur dann praktikabel, wenn die zugrunde liegende Infrastruktur sie unterstützen kann.

Wäre der Ansatz von Claude im Jahr 2020 versucht worden, wäre er wahrscheinlich unpraktisch gewesen. Damals hatten Vektordatenbanken oft eine Latenzzeit von Hunderten von Millisekunden, hybride Abfragen wurden nur unzureichend unterstützt, und die Ressourcennutzung skalierte bei wachsendem Datenaufkommen ins Unermessliche. Unter diesen Bedingungen wäre der On-Demand-Abruf als überzogene Technik abgetan worden.

Im Jahr 2025 hat sich die Landschaft verändert. Fortschritte in der Infrastruktur - angetrieben durch Systeme wie Milvus 2.6 - habendie Trennung von Speicher und Rechenleistung, die Optimierung von Abfragen, hybride Abfragen mit hoher Dichte und geringer Dichte sowie JSON Shredding in der Produktion möglich gemacht. Diese Fortschritte verringern die Latenzzeit, kontrollieren die Kosten und machen selektive Abrufe in großem Umfang praktikabel. Infolgedessen sind On-Demand-Tools und abrufbasierte Speicher nicht nur machbar, sondern auch zunehmend attraktiv geworden, insbesondere als Grundlage für agentenähnliche Systeme.

Letztlich richtet sich die Wahl der Architektur danach, was die Infrastruktur ermöglicht.

Schlussfolgerung

In realen Systemen ist das Speicherdesign keine binäre Entscheidung zwischen vorberechneten Kontexten und bedarfsgesteuertem Abruf. Die effektivsten Architekturen sind in der Regel hybrid und kombinieren beide Ansätze.

Ein gängiges Muster ist die Einspeisung aktueller Gesprächsverläufe über ein gleitendes Kontextfenster, die Speicherung stabiler Benutzerpräferenzen als Festspeicher und der Abruf älterer Gesprächsverläufe bei Bedarf über eine Vektorsuche. Mit zunehmender Reife eines Produkts kann sich dieses Gleichgewicht allmählich verschieben - von einem primär vorberechneten Kontext zu einem zunehmend abrufgesteuerten -, ohne dass eine störende architektonische Umstellung erforderlich ist.

Selbst wenn man mit einem vorberechneten Ansatz beginnt, ist es wichtig, die Migration im Blick zu haben. Der Speicher sollte mit eindeutigen Bezeichnern, Zeitstempeln, Kategorien und Quellverweisen gespeichert werden. Wenn die Abfrage praktikabel wird, können Einbettungen für den vorhandenen Speicher generiert und zusammen mit denselben Metadaten zu einer Vektordatenbank hinzugefügt werden, sodass die Abfragelogik schrittweise und mit minimaler Unterbrechung eingeführt werden kann.

Haben Sie Fragen oder möchten Sie eine Funktion der neuesten Milvus-Version genauer kennenlernen? Treten Sie unserem Discord-Kanal bei oder stellen Sie Fragen auf GitHub. Sie können auch eine 20-minütige Einzelsitzung buchen, um Einblicke, Anleitungen und Antworten auf Ihre Fragen über die Milvus-Sprechstunde zu erhalten.