Ein Agent, der sich erinnert, indem er seine gesamte Historie in den nächsten Prompt einfügt, hat kein Gedächtnis. Er hat eine wachsende Rechnung, eine harte Token-Obergrenze und eine Latenzkurve, die mit jedem Turn schlechter wird. Echtes Gedächtnis ist eine Speicherentscheidung: was man persistiert, wo man es ablegt und wie man zur Inferenzzeit nur die relevante Teilmenge zurückholt. Das ist ein Datenbankproblem, und es als Prompt-Problem zu behandeln ist der Grund, warum Agenten, die in der Demo glänzen, in Woche zwei zusammenbrechen.

Das Verführerische am Context Stuffing ist, dass es zuerst funktioniert. Am Anfang einer Session ist die Historie kurz, alles passt, und der Agent wirkt, als würde er sich erinnern. Dann wächst das Gespräch, der Prompt wächst mit ihm, und drei Dinge passieren gleichzeitig: Die Kosten steigen, weil man jedes Mal alles erneut sendet, die Latenz steigt, weil das Modell jedes Mal mehr liest, und irgendwann trifft man das Context Window und ältere Fakten fallen still vorne heraus. Der Ausfall ist kein Bug, den man patchen kann. Er ist die Architektur.

Zwei Arten von Gedächtnis, zwei Arten von Speicher

"Gedächtnis" ist eigentlich zwei verschiedene Bedürfnisse, und sie zu vermischen ist, wo Designs schiefgehen.

Session- und Arbeitsgedächtnis: ein Key-Value-Store

Die letzten Turns, der aktuelle Task-Zustand, die kurzfristigen Präferenzen des Nutzers, all das wird über einen bekannten Key nachgeschlagen: eine Session-ID, eine User-ID, eine Thread-ID. Man will schnelle Reads und Writes auf diesem Key und eine Time-to-Live, damit veraltete Sessions von selbst verfallen. Das ist eine DynamoDB-Tabelle, keine Vektorsuche. Man partitioniert nach Session oder Nutzer, hält den laufenden Zustand als Item, setzt eine TTL und liest ihn zu Beginn jedes Turns zurück. Keine Embeddings, keine Ähnlichkeit, nur ein schneller Keyed-Lookup von "wo waren wir stehengeblieben".

Langzeit-semantisches Gedächtnis: ein Vektorspeicher

Die Fakten, an die sich ein Agent über Sessions hinweg erinnern soll, frühere Entscheidungen, gelernte Präferenzen, relevante vergangene Austausche, werden nicht über einen Key nachgeschlagen. Sie werden über Bedeutung nachgeschlagen: "Was weiß ich, das für diese neue Nachricht relevant ist." Das ist semantische Suche über Embeddings, und genau dafür ist ein Vektorspeicher da. Auf AWS ist die pragmatische Wahl Aurora Serverless v2 mit pgvector: Die Embeddings liegen direkt neben den relationalen Daten, man fragt sie mit SQL ab, und man muss keine separate spezialisierte Datenbank dafür aufsetzen.

Das Muster: abrufen, nicht anhäufen

Sobald Gedächtnis eine Datenbank ist, hört jeder Turn auf anzuhängen und fängt an abzufragen. Die Schleife wird zu:

on each turn:
  1. read session state by key      (DynamoDB: where were we)
  2. embed the new user message
  3. semantic search long-term store (pgvector: what is relevant)
  4. assemble a bounded prompt:
       system + tools
       + top-k retrieved memories
       + recent turns from session state
       + new message
  5. call the model
  6. write new facts back to the stores

Der Prompt ist jetzt begrenzt, egal wie lange die Beziehung zum Nutzer schon läuft. Ein Gespräch beim tausendsten Turn sendet einen Prompt derselben Größe wie beim zehnten, weil man die relevante Handvoll Erinnerungen abholt statt sie alle mitzuschleppen. Kosten und Latenz werden flach statt zu steigen. Das ist dieselbe Retrieval-Disziplin, die RAG funktionieren lässt, angewandt auf die eigene Historie des Agenten statt auf einen Dokumentenkorpus.

Was man entscheiden muss, was ein Prompt verbirgt

Gedächtnis in eine Datenbank zu verlagern erzwingt Entscheidungen, die Context Stuffing einen ignorieren lässt, und diese Entscheidungen sind das eigentliche Engineering:

  • Was es wert ist, gemerkt zu werden. Nicht jeder Turn ist eine Erinnerung. Man schreibt dauerhafte Fakten und Entscheidungen, nicht Smalltalk, sonst füllt sich der Speicher mit Rauschen, den das Retrieval dann wieder hochspült.
  • Wann man vergisst. TTLs auf dem Session-Zustand und eine Policy zum Altern oder Ersetzen von Langzeitfakten, damit eine alte Präferenz nicht eine korrigierte übertrumpft.
  • Wie viel man abruft. Top-k ist ein Regler. Zu wenig, und der Agent vergisst; zu viel, und man ist wieder bei einem aufgeblähten Prompt, bei dem der Retrieval-Schritt keinen Wert hinzufügt.
  • Konsistenz zwischen den beiden Speichern. Session- und semantisches Gedächtnis können sich widersprechen. Man entscheidet, wer im Zweifel gewinnt.

Das Fazit

Context Stuffing ist kein Gedächtnis, es ist das Verschieben einer Speicherentscheidung, bis die Token-Rechnung und die Context-Grenze sie für einen treffen. Man teilt das Problem: schneller keyed Session-Zustand in DynamoDB, semantisches Langzeit-Recall in pgvector auf Aurora, und ein Retrieval-Schritt pro Turn, der aus beiden einen begrenzten Prompt zusammensetzt. In dem Moment, in dem Gedächtnis zu einer Datenbank mit Retrieval-Schritt wird statt zu einem immer weiter wachsenden Prompt, hören Kosten und Latenz auf, mit der Gesprächslänge zu skalieren, und man entscheidet, was der Agent sich merkt, statt das Window entscheiden zu lassen, was es vergisst.

Weiterlesen

Für die Datenbank- und Infrastrukturseite, Aurora und DynamoDB im großen Maßstab zu betreiben, gibt es die Cloud-Notizen auf ercan.cloud, und der Hub ist unter ercanermis.com.