Table of Contents

Context Language Models (CLMs) geben einem KI-Agenten direkte Kontrolle über die Informationen für seinen nächsten Modellaufruf. Der Ansatz verbessert die Kontextverwaltung in mehreren veröffentlichten Bewertungen, belegt aber kein Ende der Halluzinationen. Ein Agent braucht weiterhin Belege für seine Aussagen und unabhängige Prüfungen seiner Arbeit.

Die technische Frage lautet, ob selektive Bearbeitung die richtigen Fakten zu vertretbaren Kosten erhält. Eine kürzere Unterhaltung hilft nur, wenn der Agent seine Anforderungen behält, Beobachtungen von Annahmen trennt und bei Bedarf Belege abruft.

Die wichtigsten Punkte

  • Bearbeitbarer Kontext: CLM beschreibt eine Ausführungsmethode für vorhandene Modelle, mit optionalem Training zur besseren Nutzung.
  • Bedingte Gewinne: Modellgröße, Kontextbudget, Aufgabe und Serving-Backend beeinflussen die Ergebnisse.
  • Rechenbilanz: Prefix-Reuse-FLOPs enthalten Neuberechnungen nach Bearbeitungen, messen aber weder verstrichene Zeit noch Abrechnung direkt.
  • Gedächtnisintegrität: Eigene Notizen eines Agenten bleiben fehleranfällig und potenziell unsichere Eingaben.
  • Praktische Bewertung: Miss akzeptierte Ergebnisse, verlorene Fakten, unbelegte Aussagen und Wiederherstellungskosten gemeinsam.

Gedächtnis und Belege trennen

Ein Kontextfenster enthält die Eingabe, die dem Modell während eines Aufrufs zur Verfügung steht. Anweisungen, Toolantworten, Arbeitsnotizen und frühere Nachrichten teilen sich den Platz. Die Komprimierung ersetzt einen Teil dieses Materials durch eine kürzere Darstellung.

Betrachte eine beispielhafte Aufgabe zur Abhängigkeitsaktualisierung. Ein Testläufer meldet zwei Fehler. Der Agent komprimiert seine Historie in eine Notiz, die besagt, dass die Aktualisierung erfolgreich war. Die nächste Arbeit beginnt mit einer falschen Annahme, obwohl die ursprüngliche Testausgabe auf der Festplatte liegt.

Eine Änderung der Komprimierungsmethode beeinflusst, wie diese falsche Notiz in das Arbeitsgedächtnis gelangt. Sie ersetzt aber nicht den Testläufer als Beleg. Vor der Annahme der Aktualisierung braucht der Ablauf weiterhin ein neues Testergebnis oder einen prüfbaren Datensatz des relevanten Laufs.

FehlerGeeignete Prüfung
Verlorene AnforderungAktuellen Zustand mit den ursprünglichen Abnahmekriterien vergleichen
Erfundene BeobachtungAussage mit einem Toolergebnis oder Quelldatensatz abgleichen
Falsche BegründungSchlussfolgerung gegen das erwartete Verhalten der Aufgabe prüfen
Nicht autorisierte AnweisungBerechtigungen außerhalb der vom Modell geschriebenen Notizen erzwingen

Diese Unterscheidung zählt bei jeder Gedächtnistechnik. Erhaltung und Korrektheit sind getrennte Eigenschaften. Ein System, das eine falsche Aussage perfekt erhält, bleibt falsch.

Was CLMs ändern

Rulin Shao und Mitautoren, darunter Forschende von Meta Superintelligence Labs und der University of Washington, stellten CLMs in einem Preprint vom 29. September 2026 vor. Ihre Implementierung stellt den laufenden Kontext als bearbeitbare Datei bereit. Der Agent ändert sie mit Shellbefehlen oder Code, und die Laufzeit lädt den überarbeiteten Inhalt beim nächsten Aufruf. Siehe Context Language Models .

Ordinary continuation:
existing context + new response + new tool output

Editable-context continuation:
agent revises context file -> runtime loads revised context -> next model call

Die Modellarchitektur muss für den Zero-Shot-Ansatz nicht ersetzt werden. Die Laufzeit ergänzt eine Fähigkeit um ein vorhandenes Modell. Die Arbeit untersucht außerdem Anweisungen, erlernte Kontextverwaltung und Reinforcement Learning.

Eine Notizdatei ist etwas anderes. Das Lesen einer gespeicherten Notiz fügt ihren Inhalt einer Unterhaltung hinzu. Späteres Bearbeiten der Datei entfernt den alten Text nicht automatisch aus dem laufenden Kontext. CLM braucht Laufzeitunterstützung, um Änderungen mit späteren Anfragen zu synchronisieren. Die offizielle Implementierung enthält den Agentencode und eine getrennte Serving-Erweiterung.

Externer Speicher bleibt nützlich. Halte ausführliche Protokolle und Quelldokumente für den Abruf verfügbar und bewahre knappe Verweise im Arbeitsgedächtnis. Der Speicherort eines Dokuments und die von ihm gestützte Aussage zählen oft mehr, als jede Zeile in der nächsten Eingabe zu behalten.

Ergebnisse sorgfältig lesen

Benchmarkverbesserungen sind bestimmte Vergleiche. Die folgenden Ergebnisse stammen aus den Bewertungen der Autoren und nicht aus Tests für diesen Artikel. Die Forschung ist weiterhin ein Preprint. Ein ausgewählter Benchmark belegt keine Zuverlässigkeit in beliebigen Abläufen.

BewertungGemeldetes ErgebnisInterpretation
BrowseComp-Plus, Zero-Shot11,4 % relativer Genauigkeitsgewinn und 21,5 % weniger Prefix-Reuse-FLOPs gegenüber der stärksten BaselineGenauigkeit und Rechenaufwand verbessern sich in diesem Aufbau
TerminalBench 2.1Gleiche Genauigkeit wie die stärkste Baseline bei 29,5 % weniger FLOPsDer Vorteil ist Effizienz bei vergleichbarer Genauigkeit
EdgeBench, 12-Stunden-Läufe5 % höherer Wert bei 59 % weniger FLOPsSoftwareoptimierungswert, keine Halluzinationsrate
Trainiertes Qwen3.5-9BCLM 42,5 % gegenüber 42,1 % für trainierte ZusammenfassungKleine Genauigkeitslücke bei größerem Rechenunterschied

Der trainierte 9B-Vergleich nutzt 1,34 gegenüber 2,19 PFLOPs pro Frage, also etwa 38,8 % weniger Rechenaufwand für CLM. Die Verbesserung von 28,8 % vor dem Training auf 42,5 % danach ist ein anderer Vergleich als die Lücke von 0,4 Punkten gegenüber trainierter Zusammenfassung. Halte die Baseline eindeutig. Siehe Ergebnisse und Trainingstabelle der Arbeit .

Relative Prozente brauchen ebenfalls einen Nenner. Ein Anstieg von etwa 53,3 % auf 59,4 % entspricht ungefähr 6,1 Prozentpunkten oder 11,4 % relativ. Keine der beiden Angaben bedeutet, dass das System jede Frage richtig beantwortet.

Kontextbudget verändert Ergebnisse

Ein Kontextbudget von 32K erscheint in den wichtigsten Bewertungen. Es begrenzt Aufbewahrung und Bearbeitung spürbar. Ergebnisse bei diesem Budget dürfen nicht auf jede Bereitstellung mit größerem Fenster übertragen werden.

Bei 128K auf EdgeBench-10 berichtet Anhang F die folgenden Ergebnisse über zehn Aufgaben und drei Seeds:

MethodeEndwertMittlere Prefix-Reuse-PFLOPs pro Versuch
Zusammenfassung47,8222
CLM47,3142
CLM mit Subagenten50,2219

Die Genauigkeit eines einzelnen Agenten liegt nahe beieinander, während CLM in diesem Vergleich etwa 36 % weniger Rechenaufwand nutzt. Die Subagent-Konfiguration verändert das Ergebnis erneut. Kontextkapazität, Agentenkonfiguration und Rechenbudget gehören neben dem Methodennamen in den Vergleich.

Modellfähigkeit bleibt wichtig

Kleinere Modelle verwalten Gedächtnis nicht automatisch gut. Im Trainingsvergleich startet das untrainierte 9B-CLM unter der Zusammenfassungsbaseline. Eine separate ergänzende Bewertung meldet 39,9 % gegenüber 37,7 % auf BrowseComp-Plus. Dies sind verschiedene Versuchsaufbauten und keine austauschbaren Messungen.

Die ergänzende TerminalBench-Analyse meldet außerdem keine Kontextbearbeitungen in der Hälfte der 9B-Aufgaben. Eine Bearbeitungsschnittstelle garantiert nicht, dass ein Modell sie wirksam nutzt. Bewerte das ausgewählte Modell und seine Einstellungen, statt CLM als universelle Aufwertung zu behandeln.

Neuberechnung berücksichtigen

Der KV-Cache speichert Zwischenberechnungen der Aufmerksamkeit. Beim normalen Prefix-Caching verwendet unveränderter Text am Anfang der nächsten Anfrage frühere Berechnungen wieder. Eine Änderung nahe am Anfang verkürzt den wiederverwendbaren Prefix und zwingt zur erneuten Verarbeitung des folgenden Textes.

Previous request: A + B + C
Revised request:  A + replacement for B + C

Standard prefix reuse:
reuse A, recompute replacement for B and C

Das Prefix-Reuse-FLOPs-Maß der Arbeit zählt Generierung und Promptverarbeitung nach der ersten Abweichung. Ein PFLOP entspricht 10¹⁵ Gleitkommaoperationen. Dies ist eine geschätzte Rechensumme, kein Qualitätswert, Durchsatzmaß oder Rechnungsbetrag.

Das 7,7×-Beispiel in Anhang C nutzt einen beispielhaften Prompt mit 20.000 Tokens und eine Antwort mit 500 Tokens. Eine Änderung am Anfang kostet das 7,7-Fache des modellierten Append-only-Durchlaufs mit einem wiederverwendbaren Prefix von 18.000 Tokens. Dies ist eine Neuberechnungsstrafe bei vorgegebenen Längen und keine gemessene 7,7-fache Verringerung von Halluzinationen.

Die lokale Latenz hängt vom Promptdurchsatz ab. Als Rechenbeispiel dauert das erneute Lesen von 24.000 Tokens bei angenommenen 800 Tokens pro Sekunde 30 Sekunden, bevor weiterer Aufwand anfällt. Dies ist kein Benchmark für einen bestimmten Mac oder eine bestimmte GPU. Miss Backend, Quantisierung und die tatsächlichen Promptgrößen für deinen Einsatz.

Die llama.cpp-Diskussion zur Hybridmodell-Neuverarbeitung zeigt, warum Prefixänderungen und rekurrente Zustandsprüfpunkte wichtig sind. Sie belegt kein identisches Verhalten über alle Releases oder Anwendungen mit llama.cpp. Protokolliere die Laufzeitversion und prüfe ihre Cacheprotokolle.

Cacheeinsparungen haben Grenzen

Suffix Cache Reuse (SCR) hält Cachezustände für Text vor, der nach einer Änderung bestehen bleibt. Die veröffentlichte Erweiterung zielt auf SGLang. Ihre README nennt Version 0.5.16. Sie ist eine getrennte Serving-Optimierung und keine Voraussetzung für die grundlegende Methode mit bearbeitbarem Kontext.

Wiederverwendung ist näherungsweise. Erhaltene Tokens behalten Zustände, die unter dem vorherigen Kontext berechnet wurden. Gleiche Benchmarkleistung belegt daher keine numerische Gleichheit mit einer vollständigen Neuberechnung des neuen Prompts.

Die Autoren melden 35 % weniger serverseitige Berechnung in ihrem BrowseComp-Plus-Vergleich. Von den zusätzlich wiederverwendeten 7,8 Prozentpunkten der Prompt-Tokens stammen 5,3 aus entfernten Reasoning-Blöcken und 2,5 aus anderen Änderungen. Ein großer Teil des Vorteils gilt daher auch außerhalb expliziter CLM-Bearbeitung. Siehe SCR-Implementierungsnotizen .

Bei API-Abrechnung trennst du normale Eingaben, Cache-Schreibvorgänge und Cache-Lesevorgänge. Anthropic listet Sonnet 4.6 mit 3, 3,75 und 0,30 US-Dollar pro Million Tokens für normale Eingaben, fünfminütige Cache-Schreibvorgänge und Cache-Treffer. Das Umschreiben von 20.000 Tokens als Cache-Schreibvorgang kostet 0,075 US-Dollar gegenüber 0,006 US-Dollar für einen Treffer. Die Differenz von 0,069 US-Dollar schließt Ausgabe und andere Abrechnungsfaktoren aus. Dokumentation zum Prompt-Caching , geprüft am 10. Oktober 2026.

Die Gesamtkosten der Aufgabe bestimmen den Kompromiss. Gelegentliche teure Bearbeitungen sparen weiterhin Kosten, wenn sie spätere Eingaben stark verkleinern. Häufige Änderungen mit nur wenigen verbleibenden Durchläufen bieten weniger Gelegenheit, ihre Kosten auszugleichen.

Prüfe das Cacheverhalten im eingesetzten Serving-Pfad. Die Wiederverwendungsmessungen der Arbeit beweisen nicht, dass eine API, ein SGLang-Release oder eine lokale Laufzeit dieselben Cache-Steuerungen bereitstellt. Protokolliere Cache-Treffer, Prompt-Tokens, Neuberechnung und Resetverhalten während des Piloten. Fehlende Telemetrie ist eine Einschränkung der Bewertung.

Notizen unter Anweisungen halten

Vom Modell geschriebene Erinnerung ist nicht vertrauenswürdige Aufgabennutzung. Sie enthält Beobachtungen, Deutungen und manchmal Fehler. Jede Notiz als Anweisung zu behandeln, gibt diesen Fehlern Autorität über spätere Aktionen.

OpenAI dokumentierte 27 Jailbreak-ähnliche Komprimierungszusammenfassungen in einem getrennten Trainingslauf eines unveröffentlichten Modells der Astra-Familie. Einige injizierte Anweisungen wurden ignoriert, während aufgabenspezifische Einschränkungen eine gemeldete Fortsetzung beeinflussten. Der Bericht beschreibt seltenes Verhalten und sagt, dass eine erneute Generierung es im finalen Astra-Modell oder den für den Verkehr verwendeten Checkpoints nicht reproduzierte. Dies belegt einen Fehlermodus, nicht seine Häufigkeit in eingesetzten CLMs. Siehe OpenAIs Bericht zu Komprimierungszusammenfassungen .

Eine defensive Implementierung sollte diese Zuständigkeiten trennen:

KomponenteBehandlung
Nutzeranforderungen und BerechtigungenAußerhalb der bearbeitbaren Notizebene bewahren
ArbeitsnotizenBearbeitung erlauben, Herkunft erhalten und Unsicherheit markieren
OriginalbelegeUnabhängig von Zusammenfassungen abrufbare Datensätze behalten
Aktionen und ÄnderungenÄnderungen protokollieren und Zugriffskontrollen im Code erzwingen

Löschen ist nicht zwingend Auslöschen. SCR bewahrt Zustände, die vom früheren Kontext beeinflusst wurden. Als technische Schlussfolgerung sollte das Entfernen von Text aus einer bearbeitbaren Datei nicht als Beweis gelten, jeden Einfluss aus dem Cachezustand entfernt zu haben. Teste explizites Zurücksetzen, wenn der Ablauf einen sauberen Neustart braucht.

Einen begrenzten Piloten testen

Beginne mit Anforderungen an die Aufbewahrung, nicht mit einer beworbenen Kontextlänge. Wähle eine wiederholte Aufgabe mit bekannten Antworten, unveränderlichen Eingabedaten und einer klaren Abschlussprüfung. Nutze für den ersten Vergleich eine Sandbox mit synthetischen Daten.

  1. Exakte Fakten erstellen: IDs, geänderte Anforderungen, fehlgeschlagene Versuche und einen korrigierten Wert aufnehmen.
  2. Vergleichbare Konfigurationen ausführen: feste Zusammenfassung, bearbeitbarer Kontext und Notizablauf in einer neuen Sitzung.
  3. Eingaben konstant halten: dasselbe Modell, Aufgabenset, Werkzeuge, Generierungslimits und Kontextbudget verwenden.
  4. Nach Gedächtnisänderungen prüfen: exaktes Erinnern, Quellenabruf und die Kennzeichnung überholter Fakten als veraltet testen.
  5. Den gesamten Lauf messen: Erfolgsrate, unbelegte Aussagen, verstrichene Zeit, Änderungen, Überlaufwiederherstellung und manuelle Korrekturen erfassen.

Tokenabrechnung gehört in die Laufzeit. Anhang G findet bei den getesteten Modellen ein begrenztes Bewusstsein für die Kontextlänge. Umwelthinweise verbessern die Schätzungen. Der Versuchsaufbau enthält außerdem Überlaufwiederherstellung. Liefere gemessene Tokenzahlen und reserviere Antwortplatz, statt die Kapazität vom Modell schätzen zu lassen.

Ein notizbasierter Rückfall hilft, wenn die Bearbeitung des Livekontexts fehlt. Halte die Übergabe kurz und mit Belegen verknüpft. Der folgende Eintrag ist beispielhaft und kein CLM-API-Format:

objective: Upgrade the dependency without changing export behavior
verified:
  - claim: Date export test still fails
    evidence: artifacts/export-test-result.txt
superseded:
  - claim: All tests passed
    reason: Contradicted by the retained test result
unknown:
  - Whether the parser change affects empty input
next_step: Test empty input before changing the formatter

Auch eine neue Sitzung muss diese Notiz lesen, und eine schlechte Notiz überträgt weiterhin schlechte Informationen. Öffne für wichtige Aussagen die Belege erneut und halte die ursprüngliche Aufgabenspezifikation verfügbar. Dies ist eine Kompatibilitätsoption und kein Beweis für CLM-gleiche Gewinne.

Nach akzeptierten Ergebnissen entscheiden

Teste CLMs, wenn lang laufende Aufgaben wiederholt nützlichen Zustand verlieren oder viel Rechenaufwand für veralteten Kontext verbrauchen. Eine kurze Interaktion mit wenig Historie bietet weniger Gelegenheit für diese spezielle Optimierung.

Das offizielle Repository steht unter CC BY-NC 4.0. Prüfe die Lizenz , bevor du die Implementierung in einem kommerziellen Projekt übernimmst. Öffentlicher Quellcode allein gewährt keine uneingeschränkte kommerzielle Wiederverwendung.

Zuverlässige Fertigstellung bleibt das Ziel. Behalte die Methode nur, wenn sie akzeptierte Ergebnisse verbessert oder Kosten senkt, ohne Belegprüfungen zu schwächen. Für verwandte Bereitstellungsentscheidungen lies den Vergleich lokaler KI und gehosteter Modelle und den Leitfaden zur GPU- und Kontextplanung .

Quellen