Contextual Memory Virtualisation: DAG-Based State Management and Structurally Lossless Trimming for LLM Agents

1. Problemstellung

Große Sprachmodelle (LLMs), insbesondere Coding-Agenten, akkumulieren während ausgedehnter Arbeitssitzungen einen erheblichen „Zustand" (State) im Kontextfenster. Dazu gehören Architektur-Abbildungen, Abwägungen von Kompromissen, Codebase-Konventionen und technische Entscheidungen. Dieser Zustand wird mit hohem Rechenaufwand (Zeit und Token-Kosten) aufgebaut.

Das Hauptproblem liegt in der Behandlung dieses Zustands, wenn das Kontextfenster seine Grenzen erreicht:

• Verlustbehaftete Komprimierung: Native Funktionen (wie /compact in Claude Code) fassen den gesamten akkumulierten Zustand (z. B. 132.000 Token) oft auf wenige Sätze zusammen (z. B. 2.300 Token). Dabei geht das nuancierte Verständnis, das über eine ganze Sitzung hinweg aufgebaut wurde, zu 98 % verloren.
• Ineffizienz: Jede neue Sitzung beginnt quasi bei Null, was zu wiederholten Kosten für den Kontextaufbau führt.
• Limitationen bestehender Ansätze:
  • RAG (Retrieval-Augmented Generation): Fügt Dokumente hinzu, bewahrt aber keinen konversationellen Zustand.
  • MemGPT: Nutzt Paging, ist aber auf eine einzelne Sitzung beschränkt und verlässt sich auf das Modell für das Speichermanagement.
  • Memory-Plugins: Speichern nur Fakten, verlieren aber die konversationelle Nuance.
  • Native Tools: Bieten nur Undo oder einfaches Forken ohne Versionskontrolle oder Linienverfolgung.

2. Methodik: Contextual Memory Virtualisation (CMV)

Das Paper schlägt Contextual Memory Virtualisation (CMV) vor, ein System, das den akkumulierten LLM-Verständnisstand als versionierten Zustand behandelt. Es lehnt sich an das Konzept des virtuellen Speichers in Betriebssystemen an, um die physischen Token-Grenzen des Kontextfensters zu abstrahieren.

A. DAG-basiertes Zustandsmodell (Directed Acyclic Graph)

Der Sitzungsverlauf wird nicht als lineare Kette, sondern als gerichteter azyklischer Graph (DAG) modelliert:

• Knoten (Snapshots): Jeder Knoten ist eine unveränderliche Kopie des JSONL-Protokolls einer Sitzung zu einem bestimmten Zeitpunkt, annotiert mit Metadaten (Name, Zeitstempel, Token-Schätzung).
• Kanten (Branches): Eine Kante repräsentiert einen Fork (Verzweigung). Aus einem Snapshot kann eine neue, unabhängige Arbeitssitzung gestartet werden.
• Vorteil: Dies ermöglicht ein Git-ähnliches Workflow-Modell für LLM-Kontexte. Ein Nutzer kann einen stabilen „Root Commit" (z. B. nach 40 Minuten Architektur-Design) erstellen und davon aus parallel unabhängige Zweige für verschiedene Aufgaben (Authentifizierung, Refactoring, Performance) ableiten, ohne den Kontextaufbau wiederholen zu müssen.

B. Dreipass-Algorithmus für strukturell verlustfreies Trimmen

Um Token-Kosten zu senken, ohne das semantische Verständnis zu verlieren, wird ein dreistufiger Algorithmus eingeführt, der mechanischen Ballast entfernt, aber alle Benutzer- und Assistant-Nachrichten wortwörtlich erhält.

1. Pass 1 (Erkennung von Komprimierungsgrenzen): Scannt das Protokoll nach Markierungen, die native Komprimierung anzeigen, um den Punkt zu finden, an dem der ursprüngliche Text bereits zusammengefasst wurde.
2. Pass 2 (Sammlung von Tool-IDs): Identifiziert alle Tool-Aufrufe (tool use), die vor der Komprimierungsgrenze stattfanden. Dies dient der Erkennung von „verwaisten" Ergebnissen.
3. Pass 3 (Streaming und Trimmen): Wendet Regeln an, um den Inhalt zu reduzieren:
   • Vor-Komprimierung überspringen: Alles vor der letzten Komprimierungsgrenze wird verworfen (da bereits zusammengefasst).
   • Metadaten entfernen: Datei-Historie und Warteschlangen-Operationen werden gelöscht.
   • Bilder entfernen: Base64-kodierte Bilder werden komplett entfernt.
   • Tool-Ergebnisse stubben: Inhalte von Tool-Ergebnissen, die einen Schwellenwert (z. B. 500 Zeichen) überschreiten, werden durch einen Platzhalter ([Trimmed: ~N chars]) ersetzt. Metadaten (Dateipfade, Befehle) bleiben erhalten.
   • Verwaiste Ergebnisse entfernen: Tool-Ergebnisse, deren Aufruf vor der Komprimierungsgrenze gelöscht wurde, werden ebenfalls entfernt, um API-Validierungsfehler zu vermeiden.
   • Denk-Blöcke entfernen: Nicht portable kryptografische Signaturen werden entfernt.

3. Wichtige Beiträge

1. DAG-Zustandsmodell: Formalisierung von Sitzungsverläufen als versionierbare Graphen, die Branching, Chaining und Team-Sharing ermöglichen.
2. Strukturell verlustfreies Trimmen: Ein Algorithmus, der Token-Kosten um durchschnittlich 20 % (bis zu 86 % bei starkem Ballast) senkt, ohne die API-Korrektheit oder die konversationelle Integrität zu gefährden.
3. Ökonomische Analyse: Eine empirische Bewertung über 76 reale Coding-Sitzungen, die zeigt, dass die Trim-Methode auch unter Prompt-Caching-Bedingungen wirtschaftlich tragfähig ist.

4. Ergebnisse

Die Evaluation basierte auf Daten eines einzelnen Nutzers (Claude Opus 4.6) über drei Monate (76 qualifizierte Sitzungen).

• Token-Reduktion:
  • Durchschnittliche Reduktion: 20 %.
  • Median: 12 %.
  • Maximal: 86 % (bei Sitzungen mit hohem Overhead durch Tool-Ausgaben und Metadaten).
  • Sitzungen mit gemischtem Tool-Einsatz (≥15 % Overhead) zeigten eine durchschnittliche Reduktion von 39 %.
• Ökonomische Tragfähigkeit (Break-Even-Analyse):
  • Das Trimmen invalidiert den Prompt-Cache (einmalige Strafe für das „Cold Cache"-Laden).
  • Durch die geringeren Kosten pro Token in nachfolgenden Runden gleicht sich dies jedoch schnell aus.
  • Break-Even-Punkt: Im Durchschnitt wird die Cache-Strafe nach 35 Runden (Turns) ausgeglichen. Bei Sitzungen mit hohem Overhead (>30 % Reduktion) liegt der Break-Even bereits bei 10–15 Runden.
  • Bei Sitzungen mit minimalem Overhead ist das Trimmen oft nicht notwendig (Break-Even > 60 Turns).
• Kostenvermeidung durch Branching: Der größte wirtschaftliche Vorteil liegt nicht im Trimmen selbst, sondern im Vermeiden des kompletten Kontext-Wiederaufbaus. Das Branching von einem Snapshot spart die Kosten und Zeit (10–20 Runden), die nötig wären, um ein Codebase-Verständnis neu zu erarbeiten.

5. Bedeutung und Schlussfolgerung

Das Paper zeigt, dass die Lösung für die Flüchtigkeit von LLM-Kontexten nicht zwingend in größeren Kontextfenstern oder Modell-Updates liegt, sondern auf der Tooling-Ebene implementiert werden kann.

• Paradigmenwechsel: CMV wandelt LLM-Sitzungen von ephemeren (vergänglichen) Datenströmen in persistente, versionierte Ressourcen um.
• Effizienz: Es ermöglicht die Wiederverwendung von teurem Kontextaufbau über mehrere parallele Arbeitsströme hinweg.
• Architektonische Lücke: Die Notwendigkeit, CMV als „Userland"-Lösung zu implementieren, deutet auf eine fehlende Abstraktion in aktuellen Systemen hin. Das Paper plädiert dafür, persistentes, versioniertes Konversationsmanagement als First-Class-Bürger in zukünftigen „AI Operating Systems" (wie AIOS) zu integrieren.

Zusammenfassend bietet CMV einen praktischen, sofort einsatzbereiten Rahmen, um die Effizienz von LLM-Agenten in komplexen, mehrtägigen Aufgaben drastisch zu steigern, indem es den Kontextverlust durch Fensterbegrenzungen und ineffizientes Komprimieren eliminiert.