Kontextkomprimierung

Strategien zur Kontextkomprimierung

Wenn Agentensitzungen Millionen von Token an Konversationsverlauf generieren, wird eine Komprimierung zwingend erforderlich. Der naive Ansatz ist eine aggressive Komprimierung, um die Token pro Anfrage zu minimieren. Das korrekte Optimierungsziel sind jedoch Token pro Aufgabe: die Gesamtzahl der Token, die zum Abschließen einer Aufgabe verbraucht werden, einschließlich der Kosten für erneutes Abrufen, wenn durch die Komprimierung kritische Informationen verloren gehen.

Wann diese Fähigkeit zu aktivieren ist

Aktiviere diese Fähigkeit, wenn:

• Agentensitzungen die Grenzen des Kontextfensters überschreiten
• Codebasen die Kontextfenster überschreiten (Systeme mit 5M+ Token)
• Strategien zur Zusammenfassung von Gesprächen entworfen werden
• Fälle debuggt werden, in denen Agenten "vergessen", welche Dateien sie geändert haben
• Evaluationsframeworks für die Komprimierungsqualität erstellt werden
• Dauerhafte Übergabezusammenfassungen erstellt werden, die Entscheidungen, Dateien, Risiken und nächste Aktionen bewahren

Aktiviere diese Fähigkeit nicht für verwandte Arbeiten, die von anderen Fähigkeiten abgedeckt werden:

• Allgemeine Token-Effizienz-Taktiken wie Maskierung, Prefix-Caching oder Partitionierung: context-optimization.
• Diagnose, warum ein langer Kontext fehlschlägt, bevor eine Abhilfe gewählt wird: context-degradation.
• Schreiben von Rohausgaben, Logs oder Plänen in Dateien, ohne sie zusammenzufassen: filesystem-context.
• Entwerfen von langfristigem semantischen Gedächtnis über Sitzungen hinweg: memory-systems.
• Das Modell entscheidet, wann und wo es seinen eigenen Kontext umschreibt: self-managed-context. Diese Fähigkeit legt dennoch fest, was der Ersatztext bewahren muss.

Kernkonzepte

Die Kontextkomprimierung tauscht Tokeneinsparungen gegen Informationsverlust. Wähle basierend auf den Sitzungseigenschaften aus drei produktionsreifen Ansätzen:

1. Ankerbasierte Iterative Zusammenfassung: Implementiere dies für langlebige Sitzungen, bei denen die Dateiverfolgung wichtig ist. Pflege strukturierte, dauerhafte Zusammenfassungen mit expliziten Abschnitten für Sitzungsabsicht, Dateiänderungen, Entscheidungen und nächste Schritte. Wenn die Komprimierung ausgelöst wird, fasse nur den neu abgeschnittenen Bereich zusammen und füge ihn in die bestehende Zusammenfassung ein, anstatt sie von Grund auf neu zu generieren. Dies verhindert eine Drift, die sich ansammelt, wenn Zusammenfassungen vollständig neu generiert werden – jede Regeneration riskiert, Details zu verlieren, die das Modell als niedrigpriorisiert betrachtet, die die Aufgabe jedoch benötigt. Die Struktur erzwingt die Erhaltung, da dedizierte Abschnitte als Checklisten fungieren, die der Zusammenfasser ausfüllen muss, und so stillen Informationsverlust abfangen.

2. Opaque Compression: Hebe dies für kurze Sitzungen auf, bei denen die Kosten für erneutes Abrufen niedrig sind und maximale Tokeneinsparungen erforderlich sind. Es erzeugt komprimierte Darstellungen, die auf Rekonstruktionstreue optimiert sind, und erreicht Kompressionsraten von 99%+, opfert aber die Interpretierbarkeit vollständig. Der Kompromiss ist wichtig: Es gibt keine Möglichkeit zu überprüfen, was erhalten wurde, ohne eine sondenbasierte Evaluation durchzuführen. Verwende dies daher niemals, wenn Debugging oder Artefaktverfolgung kritisch ist.

3. Regenerative Full Summary: Verwende dies, wenn die Lesbarkeit der Zusammenfassung entscheidend ist und Sitzungen klare Phasengrenzen aufweisen. Es generiert bei jedem Komprimierungsauslöser detaillierte, strukturierte Zusammenfassungen. Die Schwäche ist der kumulative Detailverlust über mehrere Zyklen hinweg – jede vollständige Regeneration ist ein neuer Durchlauf, der Details aus früheren Zusammenfassungen möglicherweise herabstuft.

Detaillierte Themen

Optimiere auf Token pro Aufgabe, nicht auf Token pro Anfrage

Messe die gesamten Token, die vom Start bis zum Abschluss einer Aufgabe verbraucht werden, nicht die Token pro einzelner Anfrage. Wenn die Komprimierung Dateipfade, Fehlermeldungen oder Entscheidungsbegründungen fallen lässt, muss der Agent erneut erkunden, Dateien erneut lesen und Schlussfolgerungen erneut ableiten – und verschwendet dabei weit mehr Token, als die Komprimierung eingespart hat. Eine Strategie, die 0,5% mehr Token pro Anfrage spart, aber 20% mehr erneutes Abrufen verursacht, kostet insgesamt mehr. Verfolge die Häufigkeit des erneuten Abrufens als primäres Qualitätssignal: Wenn der Agent wiederholt darum bittet, bereits verarbeitete Dateien erneut zu lesen, ist die Komprimierung zu aggressiv.

Löse zuerst das Problem der Artefaktspur

Die Integrität der Artefaktspur ist oft die schwächste Dimension bei Komprimierungsevaluationen (claim-context-compression-factory-benchmark). Gehe dies proaktiv an, da die allgemeine Zusammenfassung sie nicht zuverlässig aufrechterhalten kann.

Erhalte diese Kategorien in jedem Komprimierungszyklus explizit:

• Welche Dateien erstellt wurden (vollständige Pfade)
• Welche Dateien geändert wurden und was sich geändert hat (inklusive Funktionsnamen, nicht nur Dateinamen)
• Welche Dateien gelesen, aber nicht geändert wurden
• Spezifische Bezeichner: Funktionsnamen, Variablennamen, Fehlermeldungen, Fehlercodes

Implementiere einen separaten Artefaktindex oder eine explizite Dateizustandsverfolgung im Agentengerüst, anstatt dich darauf zu verlassen, dass der Zusammenfasser diese Details erfasst. Selbst strukturierte Zusammenfassungen mit dedizierten Dateiabschnitten haben bei langen Sitzungen Schwierigkeiten mit der Vollständigkeit.

Strukturiere Zusammenfassungen mit obligatorischen Abschnitten

Erstelle strukturierte Zusammenfassungen mit expliziten Abschnitten, die stillen Informationsverlust verhindern. Jeder Abschnitt fungiert als Checkliste, die der Zusammenfasser ausfüllen muss, wodurch Auslassungen sichtbar werden und nicht stillschweigend erfolgen.

## Sitzungsabsicht
[Was der Benutzer erreichen möchte]

## Geänderte Dateien
- auth.controller.ts: JWT-Token-Generierung korrigiert
- config/redis.ts: Connection-Pooling aktualisiert
- tests/auth.test.ts: Mock-Setup für neue Konfiguration hinzugefügt

## Getroffene Entscheidungen
- Verwendung von Redis-Verbindungspools anstelle von verbindungsbasierten Anfragen
- Wiederholungslogik mit exponentiellem Backoff bei vorübergehenden Ausfällen

## Aktueller Stand
- 14 Tests bestanden, 2 fehlgeschlagen
- Verbleibend: Mock-Setup für Session-Service-Tests

## Nächste Schritte
1. Verbleibende Testfehler beheben
2. Vollständige Testsuite ausführen
3. Dokumentation aktualisieren

Passe die Abschnitte an die Domäne des Agenten an. Ein Debugging-Agent benötigt "Grundursache" und "Fehlermeldungen"; ein Migrationsagent benötigt "Quellschema" und "Zielschema". Die Struktur ist wichtiger als die spezifischen Abschnitte – jedes explizite Schema übertrifft eine freie Zusammenfassung.

Wähle Komprimierungsauslöser strategisch

Wann die Komprimierung ausgelöst wird, ist genauso wichtig wie die Art der Komprimierung. Wähle eine Auslöserstrategie basierend auf der Vorhersagbarkeit der Sitzung:

Strategie	Auslösepunkt	Kompromiss
Feste Schwelle	70-80% Kontextauslastung	Einfach, kann aber zu früh komprimieren
Gleitendes Fenster	Letzte N Runden + Zusammenfassung behalten	Vorhersagbare Kontextgröße
Bedeutungsbasiert	Weniger relevante Abschnitte zuerst komprimieren	Komplex, bewahrt aber Signal
Aufgabenbegrenzung	Bei logischen Aufgabenabschlüssen komprimieren	Saubere Zusammenfassungen, aber unvorhersehbare Zeitpunkte

Standardmäßig sollte für Codierungsagenten das gleitende Fenster mit strukturierten Zusammenfassungen verwendet werden – es bietet die beste Balance zwischen Vorhersagbarkeit und Qualität. Verwende aufgabenbegrenzte Auslöser, wenn Sitzungen klare Phasenübergänge haben (z. B. Recherche, dann Implementierung, dann Tests).

Bewerte Komprimierung mit Sonden, nicht mit Metriken

Traditionelle Metriken wie ROUGE oder Embedding-Ähnlichkeit erfassen die funktionale Komprimierungsqualität nicht. Eine Zusammenfassung kann bei lexikalischer Überlappung gut abschneiden, aber den einen Dateipfad vermissen lassen, den der Agent zur Fortsetzung benötigt.

Verwende eine sondenbasierte Evaluation: Stelle nach der Komprimierung Fragen, die testen, ob kritische Informationen überlebt haben. Wenn der Agent richtig antwortet, hat die Komprimierung die richtigen Informationen bewahrt. Wenn nicht, rät er oder halluziniert.

Sondentyp	Was wird getestet	Beispielfrage
Erinnerung	Faktische Bewahrung	"Was war die ursprüngliche Fehlermeldung?"
Artefakt	Dateiverfolgung	"Welche Dateien haben wir geändert?"
Fortsetzung	Aufgabenplanung	"Was sollen wir als nächstes tun?"
Entscheidung	Argumentationskette	"Was haben wir bezüglich des Redis-Problems entschieden?"

Bewerte Komprimierung in sechs Dimensionen

Bewerte die Komprimierungsqualität für Codierungsagenten in diesen Dimensionen. Genauigkeit und die Erhaltung der Artefaktspur trennen Methoden tendenziell deutlicher als lexikalische Ähnlichkeit (claim-context-compression-factory-benchmark), daher benötigt die Komprimierung eine spezielle Handhabung, die über die allgemeine Zusammenfassung hinausgeht.

1. Genauigkeit: Sind technische Details korrekt – Dateipfade, Funktionsnamen, Fehlercodes?
2. Kontextbewusstsein: Spiegelt die Antwort den aktuellen Gesprächszustand wider?
3. Artefaktspur: Weiß der Agent, welche Dateien gelesen oder geändert wurden?
4. Vollständigkeit: Behandelt die Antwort alle Teile der Frage?
5. Kontinuität: Kann die Arbeit ohne erneutes Abrufen von Informationen fortgesetzt werden?
6. Anweisungsbefolgung: Respektiert die Antwort die genannten Einschränkungen?

Praktische Anleitung

Wende den Drei-Phasen-Komprimierungsworkflow für große Codebasen an

Komprimiere für Codebasen oder Agentensysteme, die die Kontextfenster überschreiten, in drei aufeinanderfolgenden Phasen. Jede Phase verengt den Kontext, sodass die nächste Phase innerhalb des Budgets arbeiten kann.

1. Recherchephase: Erkunde Architekturdiagramme, Dokumentation und wichtige Schnittstellen. Komprimiere die Erkundung in eine strukturierte Analyse von Komponenten, Abhängigkeiten und Grenzen. Ausgabe: ein einzelnes Recherchedokument, das die rohe Erkundung ersetzt.

2. Planungsphase: Konvertiere das Recherchedokument in eine Implementierungsspezifikation mit Funktionssignaturen, Typdefinitionen und Datenfluss. Eine Codebasis mit 5 Millionen Token komprimiert sich in dieser Phase auf etwa 2.000 Wörter Spezifikation.

3. Implementierungsphase: Führe die Spezifikation aus. Der Kontext bleibt auf die Spezifikation plus aktive Arbeitsdateien fokussiert, nicht auf die rohe Codebasis-Erkundung. Diese Phase benötigt selten weitere Komprimierung, da die Spezifikation bereits kompakt ist.

Verwende Beispielartefakte als Komprimierungsseeds

Wenn ein manuelles Migrationsbeispiel oder ein Referenz-PR bereitgestellt wird, verwende es als Vorlage, um das Zielmuster zu verstehen, anstatt die Codebasis von Grund auf zu erkunden. Das Beispiel offenbart Einschränkungen, die eine statische Analyse nicht aufdecken kann: welche Invarianten gelten müssen, welche Dienste bei Änderungen brechen und wie eine saubere Implementierung aussieht.

Dies ist am wichtigsten, wenn der Agent nicht zwischen wesentlicher Komplexität (Geschäftsanforderungen) und zufälliger Komplexität (Legacy-Workarounds) unterscheiden kann. Das Beispielartefakt kodiert diese Unterscheidung implizit und spart Token, die sonst für Trial-and-Error-Erkundung aufgewendet würden.

Implementiere die ankerbasierte iterative Zusammenfassung Schritt für Schritt

1. Definiere explizite Zusammenfassungsabschnitte, die zur Domäne des Agenten passen (Debugging, Migration, Feature-Entwicklung)
2. Fasse beim ersten Komprimierungsauslöser den abgeschnittenen Verlauf in diesen Abschnitten zusammen
3. Fasse bei nachfolgenden Komprimierungen nur den neu abgeschnittenen Inhalt zusammen – fasse die bestehende Zusammenfassung nicht erneut zusammen
4. Füge neue Informationen in bestehende Abschnitte ein, anstatt sie neu zu generieren, und dedupliziere nach Dateipfad und Entscheidungsidentität
5. Markiere, welche Informationen aus welchem Komprimierungszyklus stammen – dies ermöglicht das Debuggen, wenn Zusammenfassungen abweichen

Wähle den richtigen Ansatz für das Sitzungsprofil

Verwende die ankerbasierte iterative Zusammenfassung, wenn:

• Sitzungen langlebig sind (100+ Nachrichten)
• Dateiverfolgung wichtig ist (Codierung, Debugging)
• Eine Überprüfung der bewahrten Informationen erforderlich ist

Verwende Opaque Compression, wenn:

• Maximale Tokeneinsparungen erforderlich sind
• Sitzungen relativ kurz sind
• Die Kosten für erneutes Abrufen niedrig sind (z. B. kein Dateisystemzugriff erforderlich)

Verwende regenerative Zusammenfassungen, wenn:

• Die Interpretierbarkeit der Zusammenfassung für die menschliche Überprüfung entscheidend ist
• Sitzungen klare Phasengrenzen haben
• Eine vollständige Kontextüberprüfung bei jedem Komprimierungsauslöser akzeptabel ist

Kalibriere Komprimierungsverhältnisse nach Methode

Methode	Komprimierungsrate	Qualitätsbewertung	Kompromiss
Ankerbasierte Iterative	98,6%	3,70	Beste Qualität, etwas weniger Komprimierung
Regenerative	98,7%	3,44	Gute Qualität, moderate Komprimierung
Opaque	99,3%	3,35	Beste Komprimierung, Qualitätsverlust

Verwende diese als quellspezifische Benchmark-Werte, nicht als universelle Konstanten (claim-context-compression-factory-benchmark). Für jede Aufgabe, bei der Kosten für erneutes Abrufen anfallen, begünstigt dieser Kompromiss im Allgemeinen strukturierte Ansätze.

Beispiele

Beispiel 1: Debugging Sitzungskomprimierung

Ursprünglicher Kontext (89.000 Token, 178 Nachrichten):

• 401-Fehler am Endpunkt /api/auth/login
• Rückverfolgung durch Auth-Controller, Middleware, Session-Store
• Veraltete Redis-Verbindung gefunden
• Connection-Pooling korrigiert, Wiederholungslogik hinzugefügt
• 14 Tests bestanden, 2 fehlgeschlagen

Strukturierte Zusammenfassung nach Komprimierung:

## Sitzungsabsicht
Debuggen des 401 Unauthorized-Fehlers am Endpunkt /api/auth/login trotz gültiger Anmeldeinformationen.

## Grundursache
Veraltete Redis-Verbindung im Session-Store. JWT wurde korrekt generiert, aber die Sitzung konnte nicht gespeichert werden.

## Geänderte Dateien
- auth.controller.ts: Keine Änderungen (nur gelesen)
- middleware/cors.ts: Keine Änderungen (untersucht)
- config/redis.ts: Connection-Pooling-Konfiguration korrigiert
- services/session.service.ts: Wiederholungslogik für vorübergehende Ausfälle hinzugefügt
- tests/auth.test.ts: Mock-Setup aktualisiert

## Teststatus
14 bestanden, 2 fehlgeschlagen (Probleme mit Mock-Setup)

## Nächste Schritte
1. Verbleibende Testfehler beheben (Session-Service mocken)
2. Vollständige Testsuite ausführen
3. Auf Staging bereitstellen

Beispiel 2: Sondenantwortqualität

Nach der Komprimierung die Frage stellen: "Was war der ursprüngliche Fehler?"

Gute Antwort (strukturierte Zusammenfassung):

"Der ursprüngliche Fehler war eine 401 Unauthorized-Antwort vom Endpunkt /api/auth/login. Benutzer erhielten diesen Fehler mit gültigen Anmeldeinformationen. Die Grundursache war eine veraltete Redis-Verbindung im Session-Store."

Schlechte Antwort (aggressive Komprimierung):

"Wir haben ein Authentifizierungsproblem debuggt. Der Login ist fehlgeschlagen. Wir haben einige Konfigurationsprobleme behoben."

Die strukturierte Antwort bewahrt Endpunkt, Fehlercode und Grundursache. Die aggressive Antwort verliert alle technischen Details.

Richtlinien

1. Optimiere auf Token pro Aufgabe, nicht auf Token pro Anfrage
2. Verwende strukturierte Zusammenfassungen mit expliziten Abschnitten für die Dateiverfolgung
3. Löse die Komprimierung bei 70-80% Kontextauslastung aus
4. Implementiere inkrementelles Zusammenführen anstelle einer vollständigen Neugenerierung
5. Teste die Komprimierungsqualität mit sondenbasierter Evaluation
6. Verfolge die Artefaktspur separat, wenn die Dateiverfolgung kritisch ist
7. Akzeptiere etwas niedrigere Komprimierungsverhältnisse für eine bessere Qualitätserhaltung
8. Überwache die Häufigkeit des erneuten Abrufens als Signal für die Komprimierungsqualität

Fallstricke

1. Komprimiere niemals Tool-Definitionen oder Schemata: Das Komprimieren von Funktionsaufrufschemata, API-Spezifikationen oder Tool-Definitionen zerstört die Agentenfunktionalität vollständig. Der Agent kann keine Werkzeuge mehr aufrufen, keine strukturierten Antworten parsen und keine API-Aufrufe ausführen. Behandle diese als unveränderlichen Kontext, der niemals komprimiert werden darf, unabhängig von der Kontextgröße.

2. Verliere keine Entscheidungsbegründungen: Wenn die Komprimierung die Begründung hinter einer Entscheidung verwirft, riskiert der Agent, sie in nachfolgenden Iterationen rückgängig zu machen. Bewahre die Entscheidungsbegründung als Teil jedes Entscheidungsprotokolls auf.

3. Ignoriere keine Domänengrenzen: Ein für die Zusammenfassung von Chat-Gesprächen optimiertes Modell schneidet bei der Zusammenfassung von Codierungs-Debugging-Sitzungen schlecht ab. Verwende domänenspezifische Zusammenfassungsstrategien oder stimme das Zusammenfassungsmodell auf Codierungsaufgaben ab.

4. Überspringe keine Tests: Nach der erstmaligen Komprimierung wirst du eine geringere Fehlerwahrscheinlichkeit feststellen, aber isoliert betrachtet sind die Raten für bestimmte Aufgabentypen (Dateiverfolgung) immer noch hoch genug, um evaluiert zu werden. Teste jede Komprimierungsmethode mit domänenspezifischen Sonden, bevor du sie in der Produktion einsetzt.

5. Optiere nicht auf Rohmetriken: ROUGE-Scores und Embedding-Ähnlichkeit können eine Zusammenfassung als hochwertig einstufen, während sie kritische Codierungsdetails vermissen lässt. Verwende sondenbasierte Metriken, die auf die Artefaktverfolgung und die Entscheidungserhaltung zugeschnitten sind, nicht allgemeine Textähnlichkeitsmetriken.