Wie unterscheidet sich dies vom Langzeitgedächtnis?

Das Langzeitgedächtnis speichert Fakten außerhalb des Prompts und ruft sie bei Bedarf ab; die Kontextkomprimierung verkleinert den bei jedem Aufruf gesendeten Live-Kontext. Sie ergänzen sich: Das Gedächtnis entscheidet, was zurückgeholt wird, die Komprimierung entscheidet, wie kompakt es im Fenster platziert wird.

Zusammenfassen, bereinigen oder komprimieren – was sollte ich verwenden?

Zuerst bereinigen (kostenlos, verlustfrei beim Entfernen echter Redundanz), den älteren Verlauf zusammenfassen, wenn er unbegrenzt wächst, und eine Prompt-Komprimierung erst dann hinzufügen, wenn Sie immer noch mehr Spielraum benötigen und die Qualitätskosten validieren können. Die meisten Systeme kombinieren alle drei Ansätze.

Woran erkenne ich, dass die Komprimierung der Qualität schadet?

Führen Sie ein Evaluierungsset mit ein- und ausgeschalteter Komprimierung aus und vergleichen Sie die Aufgabenergebnisse, nicht nur die Token-Zahlen. Achten Sie auf selbstbewusst falsche Antworten und verworfene Einschränkungen – das sind die typischen Anzeichen einer verlustbehafteten Komprimierung, die zu weit gegangen ist.

Kosten & LeistungAktualisiert 2026-06-24 · Version 1.1

Kontextkomprimierung

Die Kontextkomprimierung reduziert die Token, die einem Modell bei jedem Aufruf übergeben werden, während die Informationen, die es tatsächlich zum Handeln benötigt, erhalten bleiben. Nutzen Sie sie bei langlebigen Agenten und langen Konversationen, um Kosten und Latenzzeiten zu senken und innerhalb des Kontextfensters zu bleiben. Die drei Hebel sind das Zusammenfassen des Verlaufs, das Bereinigen irrelevanter Kontexte und das Komprimieren von Prompts. Das zentrale Risiko ist der Informationsverlust (Lossiness): das Weglassen des einen Details, auf das es ankam. Messen Sie die erhaltenen Informationen, nicht nur die eingesparten Token.

Evidenz: ProduktionKonfidenz: NiedrigQuelle: ProduktionssystemQuelle: Persönliche ErfahrungQuelle: Branchenbeobachtung

Maschinenlesbar: JSON

Problem

Langlebige Agenten und Multi-Turn-Konversationen akkumulieren Kontext: Jedes Tool-Ergebnis, jede vorherige Nachricht und jedes abgerufene Dokument wird beim nächsten Aufruf erneut abgespielt. Die Token-Anzahl wächst annähernd linear mit der Interaktion, sodass die Kosten pro Aufruf und die Latenz steigen. Schließlich läuft das Kontextfenster über und die ältesten (manchmal wichtigsten) Inhalte werden stillschweigend abgeschnitten. Naive Lösungen – größere Fenster, aggressiveres Abschneiden – erhöhen entweder die Kosten oder zerstören die Informationen, die das Modell benötigt, um kohärent zu bleiben.

Wann zu verwenden

Trifft zu, wenn der Kontext im Verhältnis zu dem, was ein einzelner Schritt benötigt, unbegrenzt wächst: Konversationsassistenten mit langen Verläufen, autonome Agenten, die viele Tool-Aufrufe in Schleifen durchlaufen, RAG-Pipelines, die zu viele Daten abrufen (Over-Retrieval), und Batch-Jobs, bei denen die Prompt-Größe die Kosten dominiert. Es eignet sich, wenn ein Großteil des akkumulierten Kontexts redundant oder veraltet ist, wenn Sie die Prompt-Zusammenstellung kontrollieren und wenn Sie gewisse Rekonstruktionsfehler tolerieren können. Es ist ungeeignet, wenn jedes Token tragend ist (Rechts-, Audit- oder Exact-Recall-Aufgaben) oder wenn Interaktionen so kurz sind, dass das Kontextfenster nie an seine Grenzen stößt.

Lösung

Betrachten Sie den Live-Kontext als ein Budget, das Sie aktiv verwalten, und nicht als ein Log, an das nur angehängt wird. Es gibt drei komplementäre Hebel. Die Zusammenfassung (Summarization) ersetzt einen Teil des Verlaufs durch eine kürzere Synopse – typischerweise eine fortlaufende Zusammenfassung älterer Turns, die regelmäßig aktualisiert wird, während neuere Turns wortwörtlich erhalten bleiben. Das Pruning (Bereinigen) entfernt Kontext, der für den aktuellen Schritt irrelevant ist: Duplikate entfernen, veraltete Tool-Ausgaben verwerfen und nur diejenigen abgerufenen Chunks auswählen, deren Score über einem Relevanzschwellenwert liegt. Die Prompt-Komprimierung (z. B. LLMLingua) nutzt ein kleineres Modell, um informationsarme Token vor dem Senden des Prompts zu löschen oder umzuformulieren, was einen geringen Genauigkeitsverlust gegen eine erhebliche Token-Reduzierung eintauscht. Fügen Sie diese Komponenten zu einer Pipeline mit expliziten Grenzen zusammen: Behalten Sie ein wortwörtliches aktuelles Fenster, eine fortlaufende Zusammenfassung des älteren Verlaufs und einen bei Bedarf gefüllten Retrieval-Slot bei. Schützen Sie einen „angepinnten“ Bereich für Fakten, die niemals komprimiert werden dürfen – Identifikatoren, Einschränkungen, das aktuelle Ziel. Instrumentieren Sie das Ergebnis unbedingt: Führen Sie ein Evaluierungsset aus, das Antworten mit und ohne Komprimierung vergleicht, damit Sie sehen, wann die Qualität nachlässt, und passen Sie die Aggressivität pro Workload statt global an. Komprimierung ist ein Regler zwischen Qualität und Kosten, kein kostenloser Gewinn.

Komponenten

Fortlaufender SummarizerRelevanz-PrunerPrompt-KompressorAngepinnter BereichKontext-Budget-ControllerRetention-Evaluator

Vorteile

Das Senden von weniger Token reduziert direkt die Input-Kosten bei jedem Aufruf, was sich über lange Agenten-Schleifen und hohes Traffic-Volumen summiert.
Kleinere Prompts bedeuten weniger Kodierungsaufwand und eine kürzere Time-to-First-Token, was die Reaktionsfähigkeit in interaktiven und agentischen Abläufen verbessert.
Die Begrenzung des Live-Kontexts ermöglicht es, lange Konversationen und mehrschrittige Agenten fortzuführen, ohne dass das Fenster überläuft oder Inhalte stillschweigend abgeschnitten werden.
Das Entfernen von redundantem und veraltetem Kontext kann die Qualität verbessern, indem Ablenkungen reduziert werden, sodass sich das Modell auf das konzentrieren kann, was aktuell wichtig ist.

Risiken

Zusammenfassungen und Pruning können genau das eine Detail verwerfen, das sich später als entscheidend herausstellt, was zu selbstbewusst falschen Antworten führt.
Fortlaufende Zusammenfassungen fassen vorherige Zusammenfassungen zusammen; kleine Auslassungen summieren sich über viele Zyklen, bis der rote Faden unbemerkt verloren geht.
Der Betrieb eines Summarizers oder Kompressors verursacht eigene Latenz, Kosten und Fehlerquellen, was die Einsparungen bei kurzen Interaktionen wieder aufheben kann.
Aggressives Verwerfen kann stillschweigend Einschränkungen oder Anweisungen entfernen, von denen das Modell weiterhin abhängt, ohne dass ein offensichtliches Fehlersignal ausgegeben wird.

Wann nicht zu verwenden

Wenn jedes Token tragend ist – bei rechtlichen Fragen, Audits, Compliance oder präziser Datenextraktion –, ist eine verlustbehaftete Komprimierung inakzeptabel.
Wenn Konversationen das Fenster selten an seine Grenzen bringen, kostet der Komprimierungs-Overhead mehr, als er einspart, und sorgt für unnötige Komplexität.
Führen Sie ohne ein Retention-Evaluierungs-Harness kein Deployment durch: Sie können sonst nicht feststellen, ob die Komprimierung die Antworten stillschweigend verschlechtert.

Technologien

SummarizationContext pruningRAGPrompt compression (LLMLingua)

Beispiele

Ein Agent, der eine große Codebasis iteriert, behält ein wortwörtliches aktuelles Fenster sowie eine fortlaufende Zusammenfassung früherer Schritte bei und pinnt die Aufgabenspezifikation sowie Dateipfade an, um das Ziel nicht aus den Augen zu verlieren.
Ein Multi-Session-Support-Bot fasst vorherige Turns in einer kompakten Fallzusammenfassung zusammen, bereinigt gelöste Teilprobleme und pinnt gleichzeitig die Account-Einschränkungen des Kunden an.
Eine Retrieval-Pipeline, die viele Chunks abruft, wendet Relevanz-Pruning und Prompt-Komprimierung an, um nur Passagen mit starkem Signal zu senden, wodurch Token eingespart werden, ohne die Antwort zu verlieren.

Praxisbelege

Kontext: Single-Operator, Local-First OpenClaw-Deployment, beobachtet über 57 Tage (161 Sessions / 2.776 Turns), aggregiert aus den eigenen Trajektorien-Traces des Agenten.
Szenario: Lange autonome Transkripte werden präventiv verdichtet und Tool-Ergebnisse abgeschnitten, um innerhalb des Prompt-Budgets zu bleiben.
Technologie: Präventive Verdichtung mit Sicherheitsmarge, Abschneiden von Tool-Ergebnissen, ein Context-Pruning-Hook und eine Vorabprüfung auf Überlauf mitten im Turn.
Last: 2.810 kontextkompilierte Ereignisse über 2.776 Turns hinweg in 57 Tagen.
Ergebnisse: Die Verdichtung lief inline über das gesamte Fenster hinweg und hielt mehrschrittige autonome Turns im Budget (p95 87,6 s pro Turn), ohne dass Fehler durch Kontextüberlauf auftraten. Single-Operator, Local-First-Deployment.

KPIs

Token pro Aufruf (Input): Der primäre Kostentreiber. Verfolgen Sie die Verteilung vor und nach der Komprimierung; ein gesundes Ergebnis ist eine deutliche Reduzierung ohne Anstieg nachgelagerter Fehler.
Informationserhalt / Aufgabenqualität: Vergleichen Sie Antworten mit und ohne Komprimierung in einem Evaluierungsset. Ein gutes Ergebnis zeigt sich darin, dass die Qualität bei sinkender Token-Zahl innerhalb Ihrer Toleranz stabil bleibt.
End-to-End-Latenz: Netto nach Komprimierungs-Overhead. Ein gutes Ergebnis ist eine geringere Gesamtlatenz; achten Sie darauf, dass Aufrufe des Summarizers oder Kompressors die Einsparungen nicht wieder zunichtemachen.
Kontextüberlauf- / Abschneiderate: Wie oft Interaktionen an das Limit des Fensters stoßen. Ein gutes Ergebnis ist es, diesen Wert gegen Null zu senken, ohne auf das Verwerfen angepinnter Inhalte zurückgreifen zu müssen.

Beobachtete Fehlermuster

Eine Zusammenfassung lässt eine früh erwähnte Einschränkung aus; viele Turns später verletzt der Agent diese, weil dieser Fakt schlichtweg aus dem Kontext verschwunden ist.
Wiederholtes erneutes Zusammenfassen verstärkt Paraphrasierungsfehler und Auslassungen, bis die fortlaufende Zusammenfassung nicht mehr widerspiegelt, was tatsächlich passiert ist.
Ein falsch konfiguriertes Budget komprimiert Identifikatoren oder Anweisungen, die eigentlich geschützt sein sollten, was die Korrektheit stillschweigend beeinträchtigt.
Ein aggressiver Relevanzschwellenwert filtert Kontext heraus, der für einen Edge Case wichtig war, sodass die Qualität in Tests gut aussieht, in der Praxis jedoch versagt.

Lessons Learned

Die Token-Reduzierung lässt sich trivial maximieren, ist allein jedoch bedeutungslos; die eigentliche Metrik ist, ob das Modell immer noch korrekt antwortet.
Schützen Sie Identifikatoren, Einschränkungen und das aktuelle Ziel explizit, damit keine Komprimierungsstufe sie verwerfen kann.
Komprimieren Sie den alten Verlauf, nicht den aktiven Kontext; die jüngsten Interaktionen enthalten das am stärksten entscheidungsrelevante Signal.
Passen Sie die Aggressivität pro Workload anhand eines Evaluierungssets an; was für Smalltalk sicher ist, ist für eine Audit-Aufgabe leichtsinnig.

FAQs

Wie unterscheidet sich dies vom Langzeitgedächtnis?: Das Langzeitgedächtnis speichert Fakten außerhalb des Prompts und ruft sie bei Bedarf ab; die Kontextkomprimierung verkleinert den bei jedem Aufruf gesendeten Live-Kontext. Sie ergänzen sich: Das Gedächtnis entscheidet, was zurückgeholt wird, die Komprimierung entscheidet, wie kompakt es im Fenster platziert wird.
Zusammenfassen, bereinigen oder komprimieren – was sollte ich verwenden?: Zuerst bereinigen (kostenlos, verlustfrei beim Entfernen echter Redundanz), den älteren Verlauf zusammenfassen, wenn er unbegrenzt wächst, und eine Prompt-Komprimierung erst dann hinzufügen, wenn Sie immer noch mehr Spielraum benötigen und die Qualitätskosten validieren können. Die meisten Systeme kombinieren alle drei Ansätze.
Woran erkenne ich, dass die Komprimierung der Qualität schadet?: Führen Sie ein Evaluierungsset mit ein- und ausgeschalteter Komprimierung aus und vergleichen Sie die Aufgabenergebnisse, nicht nur die Token-Zahlen. Achten Sie auf selbstbewusst falsche Antworten und verworfene Einschränkungen – das sind die typischen Anzeichen einer verlustbehafteten Komprimierung, die zu weit gegangen ist.