KI-Gedächtnis: Konversationsverlauf und Tokens

Wichtige Erkenntnisse: Eine konversationelle KI mit Gedächtnis auszustatten, basiert auf drei Mechanismen: einem Sliding Window mit Prioritäten (System-Prompt + letzte Austausche immer enthalten), einem kontrollierten Token-Budget zur Kostenkontrolle (ein Gespräch mit 10 Austauschen kostet 5x mehr) und einem Fallback-System zwischen LLM-Modellen, um die Verfügbarkeit zu gewährleisten. Das ist der Unterschied zwischen einem Werkzeug und einem echten Assistenten.

Die erste Version der KI in TAMSIV war amnesisch. "Füge Brot zu meiner Einkaufsliste hinzu" funktionierte perfekt. Aber die Fortsetzung mit "Setze es für morgen" scheiterte kläglich – die KI wusste nicht, von welcher Aufgabe die Rede war. Jeder Austausch begann von vorne.

Dieses Problem ist grundlegend in jeder konversationellen KI-Anwendung. LLMs haben kein natives Gedächtnis. Bei jeder Anfrage muss der gesamte Kontext erneut gesendet werden. Und das ändert alles – in Bezug auf UX, Kosten und Architektur.

Hier ist, wie ich der TAMSIV-KI Gedächtnis verliehen habe.

Warum haben LLMs kein Gedächtnis?

Es ist kontraintuitiv, wenn man ChatGPT oder Claude benutzt, aber diese Modelle haben keine Persistenz zwischen den Anfragen. Jeder API-Aufruf ist unabhängig. Das "Gedächtnis", das du in einer ChatGPT-Konversation wahrnimmst, ist die Anwendung, die bei jeder Nachricht den vollständigen Verlauf zurücksendet.

Konkret, wenn du deine 5. Nachricht in einem Gespräch sendest, empfängt die API:

1. Den System-Prompt (die Verhaltensanweisungen)
2. Nachricht 1 + Antwort 1
3. Nachricht 2 + Antwort 2
4. Nachricht 3 + Antwort 3
5. Nachricht 4 + Antwort 4
6. Deine Nachricht 5

Mit jedem weiteren Austausch wächst die Payload. Und damit zwei Probleme: das Kontextfenster (technische Grenze des Modells) und die Kosten in Tokens (jeder Token wird abgerechnet).

Das ist es, was die Dokumentation von OpenAI als Verwaltung des Konversationszustands bezeichnet.

Wie funktioniert das Sliding Window von TAMSIV?

Die klassische Lösung ist das Sliding Window: Es werden nur die letzten N Austausche beibehalten. Aber ein rohes Sliding Window ist zu simpel für eine App wie TAMSIV, wo die KI Referenzen auf vergangene Aktionen verstehen muss.

Ich habe ein Sliding Window mit Prioritäten implementiert:

• Maximale Priorität: der System-Prompt (immer enthalten, nie gekürzt)
• Hohe Priorität: die letzten 2 Austausche (der unmittelbare Kontext)
• Hohe Priorität: die Funktionsaufrufe und ihre Ergebnisse (die ausgeführten Aktionen – Aufgabenerstellung, Memo-Änderung usw.)
• Mittlere Priorität: die vorherigen Austausche (3 bis N-2)
• Niedrige Priorität: alte Austausche, zusammengefasst oder gelöscht je nach Token-Budget

Warum haben Funktionsaufrufe Priorität? Weil in TAMSIV, wenn der Benutzer sagt "Ändere die Priorität der gerade erstellten Aufgabe", die KI wissen muss, welche Aufgabe erstellt wurde. Diese Information befindet sich im function_result eines früheren Austauschs. Ohne sie kann die KI das Pronomen "sie" nicht auflösen.

Wie verwaltet man das Token-Budget, ohne die Kosten zu sprengen?

Das ist der Kern des Problems. Ein Gespräch mit 10 Austauschen kann 5-mal mehr kosten als ein isolierter Austausch, weil die kumulative Payload jedes Mal zurückgesendet wird.

Konkretes Beispiel mit einem Modell zu 0,001 $ / 1000 Tokens:

• Austausch 1: ~500 Tokens (System-Prompt + Nachricht) = 0,0005 $
• Austausch 5: ~2500 Tokens (Verlauf 1-4 + Nachricht 5) = 0,0025 $
• Austausch 10: ~5000 Tokens (Verlauf 1-9 + Nachricht 10) = 0,005 $
• Gesamtgespräch 10 Austausche: ~25.000 kumulierte Tokens = 0,025 $

Für eine App mit Tausenden von Benutzern summieren sich diese Cents schnell. Ich habe drei Schutzmaßnahmen implementiert:

1. Limit von 20 Austauschen pro Gespräch: Darüber hinaus wird empfohlen, ein neues Gespräch zu beginnen. Das vermeidet Monster-Gespräche mit 100 Austauschen.
2. Geschätzter Token-Zähler: Vor jedem Aufruf schätzt das Backend die Anzahl der Tokens der vollständigen Payload. Wenn das Budget überschritten wird, werden die ältesten Austausche gekürzt.
3. Modellwahl je nach Komplexität: Eine einfache Nachricht ("Füge Brot hinzu") verwendet ein leichtes Modell. Eine komplexe Anfrage ("Organisiere meine Wochenaufgaben nach Priorität neu") verwendet ein leistungsfähigeres Modell.

Wie funktioniert der Fallback zwischen LLM-Modellen?

In der Produktion ist Zuverlässigkeit nicht verhandelbar. Wenn das Hauptmodell (konfiguriert über OPENROUTER_MODEL) einen Fehler 429 (Rate Limit) oder 503 (Service Unavailable) zurückgibt, sollte der Benutzer nichts bemerken.

Das TAMSIV-Backend implementiert einen automatischen Fallback:

1. Aufruf des Hauptmodells über OpenRouter
2. Bei Fehler 429/503 → Wiederholung mit OPENROUTER_FALLBACK_MODEL
3. Der AlertService sendet eine E-Mail an den Admin, um den Fallback zu melden
4. Der Benutzer erhält seine Antwort normal – keine wahrnehmbare Verschlechterung

In der Produktion führt TAMSIV 2 bis 3 Fallbacks pro Woche durch. Das ist minimal, aber es passiert. Ohne diesen Mechanismus würde der Benutzer eine generische Fehlermeldung sehen – und wahrscheinlich die App verlassen.

Die Wahl von OpenRouter als LLM-Proxy (anstatt die OpenAI- oder Anthropic-API direkt aufzurufen) ist strategisch: Es ermöglicht, Modelle zu wechseln, ohne den Code zu ändern. Wenn ein neues Modell herauskommt, muss nur eine Umgebungsvariable geändert werden. Die komplette Sprach-Pipeline bleibt identisch.

Welche Auswirkungen hat das Gedächtnis auf die Benutzererfahrung?

Der Unterschied ist spektakulär. Vor dem Gesprächsverlauf war jeder Austausch unabhängig. Danach wird die KI zu einem echten Assistenten:

• "Ändere die Priorität der gerade erstellten Aufgabe" → die KI weiß, welche Aufgabe, und ändert sie
• "Setze das doch auf Freitag" → die KI versteht, dass "das" sich auf das letzte erstellte Ereignis bezieht
• "Füge auch ein Memo dazu hinzu" → die KI greift das Thema des Gesprächs auf, um das Memo zu erstellen
• "Nein, ich sagte morgen, nicht übermorgen" → die KI korrigiert, indem sie die zeitliche Referenz versteht

Das ist der Unterschied zwischen einem Sprachformular (alles jedes Mal wiederholen) und einem Assistenten, der zuhört und sich erinnert. Das macht das Diktiergerät von TAMSIV im Alltag nutzbar.

Wie beeinflusst der System-Prompt die Qualität der Antworten?

Der System-Prompt ist das wichtigste Dokument der Anwendung. Er definiert das Verhalten der KI: Ton, Antwortformat, verfügbare Funktionswerkzeuge, Einschränkungen.

Der System-Prompt von TAMSIV enthält:

• Die Persona: "Du bist der Sprachassistent von TAMSIV, einer Aufgaben- und Memo-Management-Anwendung."
• Die Funktionswerkzeuge: die 7 Funktionen, die die KI aufrufen kann (create_task, update_task, create_memo, update_memo, create_calendar_event, ask_clarification, end_conversation)
• Die Einschränkungen: kurze Antworten (der Benutzer hört über TTS), kein Markdown, keine langen Listen
• Der Benutzerkontext: die bevorzugte Sprache, die Zeitzone, der Plan (Free/Pro/Team)

Ein gut durchdachter System-Prompt reduziert drastisch Halluzinationen und themenfremde Antworten. Das ist eine Investition, die sich in jedem Gespräch auszahlt.

Wie verwaltet man multimodale Gespräche (Sprache + Text)?

In TAMSIV spricht der Benutzer, aber die KI antwortet sowohl sprachlich (über OpenAI TTS) als auch textlich (auf dem Bildschirm angezeigt). Der Verlauf speichert beide Formen:

• Benutzerseite: der vom STT transkribierte Text (nicht das rohe Audio – zu schwer an Tokens)
• KI-Seite: der Text der Antwort (an TTS gesendet und angezeigt)

Die vollständige Pipeline ist: Audio → STT → Text → LLM (mit Verlauf) → Text → TTS → Audio. Der Verlauf existiert nur in der Textebene, was die Architektur enorm vereinfacht.

Welche Alternativen zum Sliding Window gibt es?

Das Sliding Window ist nicht der einzige Ansatz. Es gibt andere Strategien:

• Zusammenfassung: Zusammenfassen alter Austausche in einem kondensierten Absatz. Vorteil: maximale Kompression. Nachteil: Detailverlust und ein zusätzlicher LLM-Aufruf für die Zusammenfassung.
• RAG (Retrieval Augmented Generation): Speichern des Verlaufs in einer Vektordatenbank und Abrufen nur der relevanten Austausche durch semantische Ähnlichkeit. Leistungsstark, aber aufwendig in der Implementierung.
• Explizites Gedächtnis: Speichern von aus Gesprächen extrahierten "Fakten" (Benutzereinstellungen, wiederkehrende Aufgaben) in einer strukturierten Datenbank. Das ist es, was ChatGPT mit seiner "Memory"-Funktion macht.

Für TAMSIV ist das Sliding Window mit Prioritäten der beste Kompromiss: einfach zu implementieren, effizient in Tokens und ausreichend für Gespräche von 5 bis 15 Austauschen. Wenn die Gespräche viel länger würden, würde ich RAG in Betracht ziehen.

Wie implementiert man einen Gesprächsverlauf in deinem eigenen Projekt?

Wenn du eine App mit einem LLM erstellst, sind hier die Schritte:

1. Speichere den Verlauf serverseitig: Vertraue niemals dem Client, den Konversationszustand zu verwalten. Das Backend ist die Quelle der Wahrheit.
2. Implementiere ein Sliding Window: Beginne einfach (behalte die letzten N Austausche), füge dann bei Bedarf Prioritäten hinzu.
3. Budgetiere die Tokens: Zähle die Tokens vor jedem Aufruf. Kürze intelligent, wenn das Budget überschritten wird.
4. Füge einen Fallback hinzu: Mindestens ein Backup-Modell im Falle eines Fehlers des Hauptmodells.
5. Messe die Kosten: Protokolliere jeden Aufruf mit der Anzahl der verwendeten Tokens. Das ermöglicht es, das System langfristig zu optimieren.

Das Admin-Dashboard von TAMSIV zeigt die Konversationsmetriken in Echtzeit an: durchschnittliche Anzahl der Austausche, durchschnittliche Kosten pro Konversation, Fallback-Rate. Diese Daten sind entscheidend, um Kosten in der Produktion zu optimieren.

FAQ

Wie viele Austausche macht ein durchschnittlicher Benutzer pro Gespräch?

In TAMSIV liegt der Durchschnitt bei 3 bis 5 Austauschen. Der typische Benutzer sagt "Füge eine Aufgabe für morgen hinzu: Zahnarzt anrufen", bestätigt die Vorschau und fährt mit einer Änderung fort ("Setze sie auf hohe Priorität"). Lange Gespräche (10+ Austausche) machen weniger als 10 % des Volumens aus.

Sind die Kosten für den Gesprächsverlauf signifikant?

Ja, das ist der Hauptausgabenposten der KI-Pipeline. Jeder zusätzliche Austausch erhöht die kumulierten Kosten. Für TAMSIV liegen die durchschnittlichen Kosten pro Gespräch bei etwa 0,01 bis 0,03 EUR mit dem Hauptmodell. Das Fallback-Modell ist in der Regel günstiger, was die Mehrkosten teilweise ausgleicht.

Sollte der Verlauf in der Datenbank gespeichert werden?

Für TAMSIV existiert der Verlauf im Speicher (Backend-seitig) während der WebSocket-Sitzung. Er wird nicht in der Datenbank gespeichert – wenn die Verbindung geschlossen wird, geht der Verlauf verloren. Das ist eine bewusste Entscheidung: Die Gespräche sind kurz und transient. Wenn du Gespräche später wieder aufnehmen musst, musst du sie in der Datenbank speichern.

OpenRouter vs. direkte Aufrufe der LLM-Anbieter-APIs?

OpenRouter fungiert als Proxy, der den Zugriff auf Dutzende von Modellen (OpenAI, Anthropic, Google usw.) über eine einzige API vereinheitlicht. Der Vorteil: Modellwechsel ohne Codeänderung. Der Nachteil: eine zusätzliche Schicht (marginale Latenz). Für eine App wie TAMSIV, die Flexibilität und Fallback benötigt, ist das eine offensichtliche Wahl.

Funktioniert das Konversationsgedächtnis mit dem Echtzeitmodus?

TAMSIV hat drei WebSocket-Modi. Im LiveWebSocket-Modus (der Standardmodus) wird der Verlauf manuell verwaltet, wie in diesem Artikel beschrieben. Im Echtzeitmodus (OpenAI Realtime API) wird der Verlauf nativ von der API verwaltet – es ist ein bidirektionales Protokoll mit Zustand. Der Legacy-Modus funktioniert im Batch ohne Persistenz.