Kontextfenster und Memory: Wie sich LLM-Anwendungen Dinge merken

Ein Sprachmodell hat kein Gedächtnis. Was sich für Nutzer wie eine fortlaufende Unterhaltung anfühlt, ist technisch eine Serie unabhängiger Anfragen, bei denen die Anwendung jedes Mal neu entscheidet, was das Modell zu sehen bekommt. Das Kontextfenster ist der einzige Kanal dafür, und es ist endlich. Alles, was eine LLM-Anwendung über frühere Nachrichten, Nutzerpräferenzen oder den Stand einer Aufgabe weiß, muss bei jeder Anfrage aktiv hineingelegt werden.

In der Praxis zeigt sich das Problem schleichend. Die ersten zwanzig Nachrichten einer Sitzung funktionieren tadellos. Danach beginnt das System, frühere Absprachen zu vergessen, sich zu widersprechen oder auf Details zu beharren, die längst überholt sind. Gleichzeitig steigen Kosten und Latenz mit jeder Nachricht, weil die gesamte Historie immer wieder mitgeschickt wird. Wer hier keine bewusste Strategie hat, bekommt beides: schlechtere Qualität und höhere Rechnung.

Das Kontextfenster ist ein Budget, kein Speicher

Der erste Denkfehler ist, das Kontextfenster als Speicher zu betrachten, den man einfach füllt. Große Fenster verleiten dazu, alles hineinzukippen: die komplette Historie, sämtliche Dokumente, jede Werkzeugbeschreibung. Das funktioniert schlechter, als die reine Kapazität vermuten lässt. Modelle gewichten Inhalte in sehr langen Kontexten ungleichmäßig, relevante Details in der Mitte gehen leichter unter, und irrelevanter Ballast lenkt die Erzeugung ab. Dazu kommt der wirtschaftliche Aspekt: Jedes Token im Kontext kostet bei jeder Anfrage erneut Geld und Zeit.

Sinnvoller ist es, das Fenster als Budget zu behandeln, das pro Anfrage bewusst verteilt wird. Die Frage lautet nicht, was alles hineinpasst, sondern was die aktuelle Anfrage tatsächlich braucht. Damit wird Kontextverwaltung zu einer Entwurfsentscheidung der Anwendung, nicht zu einem Nebeneffekt der Gesprächslänge.

Sliding Window und laufende Zusammenfassung

Die einfachste Strategie ist das Sliding Window: Es werden nur die letzten N Nachrichten mitgeschickt, ältere fallen heraus. Das ist trivial zu implementieren, hält Kosten stabil und reicht für viele Anwendungsfälle, bei denen ältere Nachrichten tatsächlich irrelevant werden, etwa bei kurzen Support-Dialogen. Der Preis ist hartes Vergessen: Was aus dem Fenster fällt, ist weg, auch wenn es die wichtigste Information der Sitzung war.

Die zweite Strategie ist die laufende Zusammenfassung. Sobald die Historie eine Schwelle überschreitet, verdichtet ein eigener Modellaufruf die älteren Nachrichten zu einem kompakten Text, der an den Anfang des Kontexts wandert. Die jüngsten Nachrichten bleiben wörtlich erhalten, die älteren nur als Substrat. Das bewahrt den roten Faden über lange Sitzungen, hat aber eigene Tücken: Zusammenfassungen verlieren Details, und ein Fehler in der Zusammenfassung pflanzt sich in alle folgenden Anfragen fort. Bewährt hat sich, der Zusammenfassung eine feste Struktur zu geben, etwa getrennte Abschnitte für getroffene Entscheidungen, offene Punkte und Nutzerangaben, statt sie frei formulieren zu lassen.

Beide Ansätze lassen sich kombinieren: ein Fenster für den Wortlaut der letzten Nachrichten, eine strukturierte Zusammenfassung für alles davor. Für die meisten Chat-artigen Anwendungen ist diese Kombination der pragmatische Standard.

Externes Memory in Datenbank oder Notizdateien

Manche Informationen gehören gar nicht in die Gesprächshistorie, sondern in ein externes Memory, das die Sitzung überdauert. Zwei Formen haben sich etabliert. Die erste ist die Datenbank: Die Anwendung extrahiert gezielt Fakten, etwa Präferenzen, Stammdaten oder den Bearbeitungsstand eines Vorgangs, und legt sie strukturiert ab. Bei jeder Anfrage wird der passende Ausschnitt geladen und in den Kontext gestellt. Das ist präzise und abfragbar, verlangt aber, dass man vorher definiert, welche Arten von Information gemerkt werden sollen.

Die zweite Form ist die Notizdatei: ein freier Textbereich, den das Modell selbst über Werkzeugaufrufe liest und fortschreibt, ähnlich einem Arbeitsjournal. Das ist flexibler, weil keine Struktur vorgegeben ist, aber auch fehleranfälliger, weil das Modell entscheidet, was notiert wird. In agentischen Anwendungen, die über Stunden an einer Aufgabe arbeiten, ist dieses Muster inzwischen verbreitet, für klassische Endnutzer-Chats ist die Datenbankvariante meist die verlässlichere Wahl.

Wichtig ist in beiden Fällen ein oft übersehener Punkt: Externes Memory braucht Pflege. Veraltete Einträge müssen überschrieben oder verworfen werden können, sonst schleppt die Anwendung Widersprüche mit, und der Nutzer wundert sich, warum das System auf einer längst geänderten Angabe beharrt.

Kontext-Budgetierung pro Anfrage

Wer mehrere Quellen kombiniert, braucht eine explizite Aufteilung des Fensters. Ein praktikables Muster ist, jeder Kategorie einen festen Anteil zuzuweisen: ein Block für Systemanweisungen und Werkzeugbeschreibungen, ein Block für externes Memory, ein Block für abgerufene Dokumente, ein Block für die jüngste Historie, und eine Reserve für die Antwort. Überschreitet eine Kategorie ihr Budget, wird innerhalb der Kategorie priorisiert, statt das Gesamtbudget zu sprengen.

Dieses Vorgehen hat einen unterschätzten Nebeneffekt: Es macht Probleme diagnostizierbar. Wenn die Qualität einbricht, lässt sich prüfen, welche Kategorie zu viel oder zu wenig Raum bekommt. Ohne Budgetierung ist der Kontext eine Blackbox, in der sich Fehlerursachen kaum lokalisieren lassen.

Welcher Ansatz passt wann

Für typische Projekte im Mittelstand lässt sich die Wahl grob an drei Fragen festmachen. Erstens: Wie lang sind die Sitzungen wirklich? Kurze, abgeschlossene Dialoge brauchen selten mehr als ein Sliding Window. Zweitens: Muss Wissen die Sitzung überleben? Wenn ja, führt an externem Memory kein Weg vorbei, und die Datenbankvariante ist der wartbarere Einstieg. Drittens: Wie hoch ist das Volumen? Bei vielen Anfragen pro Tag rechnet sich der Aufwand für Zusammenfassung und Budgetierung schnell über die eingesparten Tokens, bei einem internen Werkzeug mit einer Handvoll Nutzern eher nicht.

Der häufigste Fehler ist, mit der komplexesten Lösung zu starten. Ein sauber begrenztes Fenster plus eine strukturierte Zusammenfassung deckt einen großen Teil der Fälle ab und lässt sich später um externes Memory erweitern, wenn der Bedarf nachweislich da ist.

Fazit

LLM-Anwendungen merken sich nichts von selbst. Gedächtnis ist eine Architekturentscheidung, die aus vier Bausteinen zusammengesetzt wird: einem begrenzten Fenster für den jüngsten Wortlaut, einer laufenden Zusammenfassung für den roten Faden, externem Memory für sitzungsübergreifendes Wissen und einer expliziten Budgetierung, die alles zusammenhält. Wer diese Bausteine bewusst wählt, statt die Historie einfach wachsen zu lassen, bekommt stabile Qualität über lange Sitzungen und behält zugleich Kosten und Latenz unter Kontrolle.