LCM: Lossless Context Management

Dieses Papier stellt Lossless Context Management (LCM) vor, eine deterministische Architektur, die das Gedächtnis von LLMs durch rekursive Kontextkomprimierung und Aufgabenpartitionierung verbessert, wodurch der Volt-Agent bei langen Kontext-Coding-Aufgaben bis zu 1 Million Token Claude Code übertrifft und gleichzeitig eine verlustfreie Zustandsabrufung sowie Terminierung garantiert.

Das Wesentliche

Stellen Sie sich vor, Sie versuchen, ein riesiges, mehrere Tage andauerndes Rätsel zu lösen. Sie haben einen brillanten Detektiv (die KI), aber dieser hat ein sehr kurzes Kurzzeitgedächtnis. Wenn Sie ihm einen Stapel mit 1.000 Hinweisen geben, wird er die ersten paar vergessen, bis er beim letzten angekommen ist.

Lange Zeit bestand die Lösung darin, dem Detektiv einfach ein größeres Notizbuch (ein größeres „Kontextfenster") zu geben. Doch irgendwann werden selbst die größten Notizbücher zu schwer zu tragen, und der Detektiv beginnt, sich durch die schiere Menge an Papier zu verwirren.

Dieses Papier stellt eine neue Methode vor, um dem Detektiv zu helfen: Lossless Context Management (LCM) (Verlustfreie Kontextverwaltung). Stellen Sie sich dies vor, als würden Sie dem Detektiv einen superintelligenten, automatisierten Bibliothekar geben, der die Notizen für ihn verwaltet, anstatt den Detektiv zu bitten, sein eigenes Ablagesystem zu schreiben.

So funktioniert es, unter Verwendung einfacher Analogien:

1. Das Problem: Die Debatte „GOTO" vs. „Strukturiert"

Das Papier vergleicht zwei Arten, mit dem Gedächtnis umzugehen:

• Der alte Weg (RLM): Stellen Sie sich vor, Sie bitten den Detektiv, sein eigenes Ablagesystem in Code zu schreiben. Er muss entscheiden, wie er die Notizen organisiert, wann er Dinge verwirft und wie er sie später findet. Dies ist vergleichbar damit, einem Programmierer unbegrenzte Freiheit zu geben, GOTO-Anweisungen zu verwenden (das Springen an beliebige Stellen im Code). Es ist mächtig, aber wenn der Detektiv einen Fehler in seinem Ablageskript macht, stürzt das gesamte System ab oder wird unübersichtlich.
• Der neue Weg (LCM): Anstatt den Detektiv das Ablagesystem schreiben zu lassen, stellt die Engine (der Computer, auf dem der Detektiv läuft) einen vorgefertigten, perfekten Aktenschrank bereit. Der Detektiv sagt nur: „Hier ist ein neuer Hinweis", und die Engine entscheidet automatisch, wann alte Hinweise zusammengefasst und wo sie gespeichert werden sollen. Dies ist vergleichbar mit der Verwendung von strukturierter Programmierung (Schleifen und Wenn-Dann-Anweisungen): Es ist weniger flexibel, aber es stürzt niemals aufgrund schlechter Logik ab.

2. Die zwei magischen Werkzeuge von LCM

Das Papier besagt, dass LCM zwei Haupttricks einsetzt, um den Detektiv fokussiert zu halten:

A. Der „verlustfreie" Aktenschrank (Hierarchischer DAG)

• Funktionsweise: Die Engine bewahrt eine „Hauptkopie" jedes einzelnen Notizs, Wort für Wort, in einem sicheren Tresor (dem Immutable Store) auf.
• Die Zusammenfassung: Um Platz im aktiven Arbeitsbereich des Detektivs zu sparen, erstellt die Engine eine „Zusammenfassungskarte" für alte Notizen. Sie legt die Zusammenfassungskarte in den Arbeitsbereich und versteckt die vollständige Notiz im Tresor.
• Die Magie: Wenn der Detektiv später die ursprüngliche Notiz sehen muss, kann er danach fragen, und die Engine tauscht die Zusammenfassungskarte sofort gegen die vollständige Notiz aus. Nichts geht jemals wirklich verloren; es wird nur komprimiert, bis es benötigt wird.
• Analogie: Stellen Sie sich vor, Sie lesen ein 500-seitiges Buch. Anstatt das ganze Buch zu tragen, tragen Sie ein Lesezeichen mit einer einzeiligen Zusammenfassung jedes Kapitels. Wenn Sie eine Einzelheit nachprüfen müssen, blättern Sie zurück zur spezifischen Seite im Buch. Sie verlieren niemals den Originaltext.

B. Das „parallele" Team (LLM-Map)

• Das Problem: Wenn der Detektiv 1.000 Dateien nacheinander lesen muss, wird er müde und vergisst die erste Datei, bis er die letzte erreicht.
• Die Lösung: Anstatt dass der Detektiv die Dateien selbst liest, agiert die Engine wie ein Chef, der 16 Assistenten einstellt. Der Detektiv gibt dem Chef eine einzige Anweisung: „Lesen Sie diese 1.000 Dateien und sagen Sie mir den Hauptpunkt jeder einzelnen." Die Engine sendet alle 1.000 Dateien gleichzeitig an die Assistenten.
• Das Ergebnis: Die Assistenten leisten die Schwerstarbeit parallel. Der Detektiv sieht nur die endgültige, organisierte Ergebnisliste. Der Detektiv muss niemals 1.000 Dateien gleichzeitig in seinem Kopf halten.

3. Das „Zero-Cost"-Versprechen

Eine der größten Behauptungen des Papiers ist, dass dieses System kleine Aufgaben nicht verlangsamt.

• Analogie: Wenn Sie nur 5 Notizen zu archivieren haben, macht sich die Engine keine Mühe, ein komplexes Ablagesystem zu erstellen. Sie lässt den Detektiv sie einfach direkt lesen. Der „Aktenschrank" greift erst, wenn der Stapel zu groß wird. Das bedeutet, dass für normale, kurze Gespräche das System genauso schnell wirkt wie eine Standard-KI.

4. Die Ergebnisse: Die Konkurrenz schlagen

Die Autoren testeten ihr System (genannt Volt) gegen Claude Code, das derzeit einer der besten KI-Coding-Assistenten der Welt ist.

• Der Test: Sie gaben beiden Systemen ein riesiges „Rätsel" mit bis zu 1 Million Wörtern an Hinweisen (Tokens).
• Das Ergebnis:
  • Bei kleinen Hinweisen (unter 32.000 Wörtern) schnitten beide Systeme etwa gleich gut ab.
  • Bei riesigen Hinweisen (32.000 bis 1 Million Wörter) gewann Volt jedes Mal.
  • Das Papier behauptet, Volt war bei der Suche nach der richtigen Antwort in massiven Datensätzen deutlich besser, weil es sich nicht durch das Textvolumen „verwirren" ließ, wohingegen Claude Code zu kämpfen begann, sobald der Text länger wurde.

5. Warum dies wichtig ist (laut dem Papier)

Das Papier argumentiert, dass es riskant ist, einer KI zu verlangen, ihr eigenes Gedächtnis zu verwalten (wie beim „alten Weg"), da KI Fehler in ihrem eigenen Code machen kann. Indem die Gedächtnisverwaltung an die Computer-Engine verlagert wird (der „neue Weg"), wird das System:

1. Zuverlässiger: Es stürzt nicht ab, weil die KI ein schlechtes Skript geschrieben hat.
2. Effizienter: Es bewältigt enorme Datenmengen, ohne dass die KI überfordert wird.
3. Verlustfrei: Es garantiert, dass keine Information jemals wirklich gelöscht, sondern nur zusammengefasst wird.

Kurz gesagt schlägt das Papier vor, dass für sehr lange, komplexe Aufgaben es besser ist, der KI einen strukturierten, automatisierten Assistenten zu geben, der die Gedächtnisverwaltung übernimmt, anstatt die KI selbst versuchen zu lassen, die Bibliothekarin zu sein.

Technische Zusammenfassung

Technischer Zusammenfassung: Verlustfreie Kontextverwaltung (LCM)

Problemstellung

Der primäre Engpass für komplexe, langfristige agentische Aufgaben bleibt das effektive Kontextfenster von Large Language Models (LLMs). Selbst Modelle mit nominellen Fenstern von über 1 Million Token haben Schwierigkeiten mit mehrtägigen Sitzungen, bei denen das Volumen an Tool-Aufrufen, Dateiinhalten und Zwischenschritten der Schlussfolgerung die Kapazität überschreitet. Dies wird durch „Kontextverrottung" verschärft, bei der die Leistung erheblich abnimmt, bevor das harte Token-Limit erreicht ist.

Vorherige Arbeiten, insbesondere Recursive Language Models (RLMs), schlugen vor, dass Modelle ihren eigenen Kontext durch symbolische Rekursion aktiv verwalten sollten (z. B. durch das Schreiben von Skripten, um ihre eigenen Prompts zu chunken und zu verarbeiten). Obwohl RLMs die Machbarkeit einer aktiven Kontextverwaltung demonstrierten, erben sie die Stochastik des Modells: Eine Speicherstrategie, die in einem Durchlauf funktioniert, kann im nächsten versagen. Darüber hinaus führt das Hüllen jeder Interaktion in ein rekursives Gerüst bei Aufgaben, die in Standardfenster passen, zu Latenz und Kosten („Kurzkontext-Strafe"). Es besteht eine Spannung zwischen der Ausdruckskraft modellgenerierter Kontrollflüsse und der Zuverlässigkeit, die für Produktionssysteme erforderlich ist.

Methodik: Verlustfreie Kontextverwaltung (LCM)

LCM schlägt eine deterministische, architekturzentrierte Alternative zum modellzentrierten Ansatz von RLM vor. Anstatt das Modell zu bitten, Speicherstrategien zu erfinden, verlagert LCM die Last der Speicherarchitektur auf die Engine und bietet eine deterministische, datenbankgestützte Infrastruktur. Das System basiert auf zwei Kernsäulen: Rekursive Kontextkomprimierung und Rekursive Aufgabenpartitionierung.

1. Dual-State-Speicherarchitektur

LCM gewährleistet verlustfreie Abrufbarkeit durch ein Dual-State-Design:

• Der unveränderliche Speicher: Ein persistenter, transaktionaler Speicher (z. B. PostgreSQL), in dem jede Benutzernachricht, jede Assistentenantwort und jedes Tool-Ergebnis wortwörtlich gespeichert und niemals verändert wird. Dies ist die Quelle der Wahrheit.
• Der aktive Kontext: Das Fenster, das bei jedem Durchgang an das LLM gesendet wird, zusammengesetzt aus aktuellen Rohnachrichten und vorab berechneten Zusammenfassungs-Knoten.

Zusammenfassungsknoten fungieren als materialisierte Ansichten, die aus älteren Nachrichten durch LLM-Zusammenfassung abgeleitet werden. Entscheidend ist, dass das System „verlustfreie Zeiger" auf die Originaldaten behält. Wenn eine Zusammenfassung unzureichend ist, ermöglicht das Tool lcm_expand dem Agenten, den Originalinhalt wortwörtlich abzurufen. Um eine Kontextflutung zu verhindern, ist lcm_expand auf Teilaufgaben beschränkt, während die Hauptschleife der Interaktion nur Zusammenfassungen beobachtet.

2. Hierarchischer DAG und Kontrollschleife

Die zentrale Datenstruktur ist ein gerichteter azyklischer Graph (DAG) von Zusammenfassungen. Wenn sich der aktive Kontext füllt, werden ältere Nachrichten zu Zusammenfassungsknoten komprimiert, während die Originale erhalten bleiben.

• Deterministische Kontrollschleife: Die Engine verwaltet die Komprimierung unter Verwendung weicher ($\tau_{soft}$) und harter ($\tau_{hard}$) Token-Schwellenwerte.
• Kostenlose Kontinuität: Unterhalb von $\tau_{soft}$ findet keine Zusammenfassung statt; das System fungiert als passiver Logger und verursacht keinen Overhead. Die Komprimierung wird asynchron ausgelöst, wenn die Schwellenwerte überschritten werden, wobei Zusammenfassungen zwischen den LLM-Durchgängen in den Kontext ausgetauscht werden.
• Drei-Stufen-Eskalation: Um Konvergenz zu garantieren und „Komprimierungsfehler" (bei denen eine Zusammenfassung länger ist als die Eingabe) zu verhindern, wendet LCM ein striktes Eskalationsprotokoll an:
  1. Normal: LLM-Zusammenfassung unter Beibehaltung von Details.
  2. Aggressiv: LLM-Zusammenfassung in Stichpunkten mit reduzierten Token-Zielen.
  3. Deterministischer Fallback: Eine nicht-LLM-basierte Kürzung auf ein festes Token-Limit (z. B. 512 Token).

3. Verarbeitung großer Dateien

Für Dateien, die die Kontextgrenzen überschreiten (z. B. große Protokolle oder Datensätze), lädt LCM nicht den vollständigen Inhalt. Stattdessen speichert es einen Verweis (Pfad, ID) und eine vorab berechnete Explorationszusammenfassung. Diese Zusammenfassung wird von einem typenbewussten Dispatcher generiert (Schema-Extraktion für strukturierte Daten, strukturelle Analyse für Code, LLM-Zusammenfassung für Text), was es dem Modell ermöglicht, über die Datei zu reasoning, ohne sie zu laden. Datei-IDs werden durch den Zusammenfassungs-DAG propagiert, wodurch das Modell auch nach mehreren Komprimierungsrunden awareness über die begegneten Dateien behält.

4. Rekursion auf Operator-Ebene

LCM ersetzt vom Modell geschriebene Schleifen durch engine-verwaltete Primitive:

• LLM-Map: Verarbeitet eine Liste von Elementen parallel über zustandslose LLM-Aufrufe (z. B. Klassifizierung, Extraktion).
• Agentic-Map: Startet vollständige Unter-Agenten-Sitzungen für jedes Element, geeignet für mehrstufiges Reasoning oder Tool-Nutzung.
• Garantien: Die Engine übernimmt Iteration, Parallelität, Wiederholungsversuche und Schema-Validierung. Ausgaben werden in externen JSONL-Dateien gespeichert, um Kontextverschmutzung zu verhindern.
• Invariante der Bereichsreduktion: Um unendliche Delegierungsschleifen zu verhindern, muss ein Unter-Agent deklarieren, welche Arbeit er behält und welche er delegiert. Wenn ein Agent versucht, seine gesamte Verantwortung zu delegieren, lehnt die Engine den Aufruf ab. Diese strukturelle Garantie stellt das Ende ohne willkürliche Tiefenbegrenzung sicher.

Hauptbeiträge

1. Architektonischer Wandel: LCM verlagert die Kontextverwaltung von einem stochastischen, modellgenerierten Prozess (RLM) auf einen deterministischen, engine-verwalteten Prozess. Dies spiegelt den historischen Wandel von unbeschränkten GOTO-Anweisungen zu strukturierten Kontrollflüssen in Programmiersprachen wider.
2. Verlustfreie Abrufbarkeit: Im Gegensatz zu RAG oder gleitenden Fenstern garantiert LCM, dass jeder vorherige Zustand wortwörtlich über den unveränderlichen Speicher wiederhergestellt werden kann, unabhängig davon, wie oft der Kontext komprimiert wurde.
3. Kostenlose Kontinuität: Die Architektur verursacht keine Latenz- oder Kostenüberlastung für kurze Aufgaben, die in das native Kontextfenster passen, und adressiert damit eine wesentliche Ineffizienz in rekursiven Gerüsten.
4. Deterministische Konvergenz: Das Drei-Stufen-Eskalationsprotokoll und die Invariante der Bereichsreduktion bieten mathematische Garantien gegen Komprimierungsfehler bzw. unendliche Rekursion.

Ergebnisse

Die Autoren bewerteten LCM (implementiert im Volt-Agenten) gegen Claude Code (v2.1.4) und rohes Opus 4.6 auf dem OOLONG-Benchmark (speziell die trec_coarse-Aufteilung) und testeten Kontextlängen von 8K bis 1M Token.

• Leistung: Volt (LCM) erzielte einen durchschnittlichen absoluten Score von 74,8 und übertraf Claude Code mit 70,3 um 4,5 Punkte.
• Sensitivität gegenüber Kontextlänge:
  • < 32K Token: Volt und Claude Code schnitten vergleichbar ab, wobei Claude Code bei kürzeren Längen einen leichten Vorsprung hatte.
  • > 32K Token: Volt übertraf Claude Code konsistent. Der Abstand vergrößerte sich im ultra-langfristigen Regime erheblich:
    • Bei 256K Token: Volt führte um 10,0 Punkte.
    • Bei 512K Token: Volt führte um 12,6 Punkte.
    • Bei 1M Token: Volt führte um 4,3 Punkte.
• Baseline-Degradation: Rohes Opus 4.6 ohne Gerüst zeigte jenseits von 65K Token einen steilen Leistungsabfall und fiel bei den größten Längen unter einen Score von 20.
• Mechanismus: Der Leistungsüberschuss wird der Verwendung von LLM-Map durch LCM für parallele Aggregation zugeschrieben, was eine Kontextsättigung vermeidet. Im Gegensatz dazu verlässt sich Claude Code darauf, dass das Modell Chunking-Strategien entwickelt, was bei wachsendem Kontext zu Fehlervarianz und kognitiver Belastung führt.

Bedeutung und Behauptungen

Die Arbeit behauptet, dass LCM eine Rechtfertigung und Erweiterung des von RLMs vorangetriebenen rekursiven Paradigmas darstellt. Sie zeigt, dass rekursive Kontextmanipulation nicht nur konventionelle LLMs, sondern auch fortschrittliche Codierungsagenten mit nativem Dateisystemzugriff (wie Claude Code) übertreffen kann.

Die Autoren argumentieren, dass LCM einen überlegenen Kompromiss für Produktionsumgebungen bietet:

• Zuverlässigkeit vor Flexibilität: Durch den Verzicht auf die maximale Flexibilität von vom Modell geschriebenen Schleifen gewinnt LCM Konvergenzgarantien, kostenlose Kontinuität und verlustfreie Zustandsabrufbarkeit.
• Produktionsfähigkeit: Die deterministischen Primitive ermöglichen die sofortige Bereitstellung von Architekturen mit unendlichem Kontext, ohne darauf warten zu müssen, dass Modelle die Metakompetenz des Managements ihres eigenen Speichers beherrschen.
• Komplementarität: Die Autoren schlagen vor, dass LCM und RLM sich nicht gegenseitig ausschließen; ein zukünftiges System könnte für Standardfälle standardmäßig auf LCMs strukturierte Operatoren zurückgreifen, während es RLM-artige symbolische Rekursion für außergewöhnliche Aufgaben beibehält, die maximale Flexibilität erfordern.

Die Arbeit schließt, dass die „architekturzentrierte" Sichtweise (Bereitstellung strukturierter Primitive) Zuverlässigkeits- und Kostenvorteile für Produktionsaggregationsworkloads bietet, insbesondere wenn Kontextlängen über die Fähigkeiten aktueller roher Modellfenster hinaus skalieren.