Millionen Tokens vergeudet? Claude's Offizielle Lösung: 5 Tipps gegen Kontextverschlechterung

Hat Anthropic selbst den Mythos der Millionenzeichen-Kontextlänge durchbrochen?

https://claude.com/blog/using-claude-code-session-management-and-1m-context

In einem kürzlich erschienenen Blogbeitrag von Anthropic über die „Verwaltung von Millionenzeichen-Kontext“ wird erneut das Problem des „Kontextverfalls“ (context rot) erwähnt. Einfach ausgedrückt:

Je länger der Kontext, desto dümmer wird das Modell.

Anthropic erklärt, dass der Kontextfensterbereich alle Inhalte umfasst, die das Modell beim Generieren der nächsten Antwort „sehen“ kann. Dies beinhaltet Ihre Systemhinweise, die bisherigen Gesprächsinhalt, jeden Toolaufruf und dessen Ausgabe sowie alle gelesenen Dateien.

Derzeit beträgt das Kontextfenster von Claude Code eine Million Token.

Ein langer Kontext ist jedoch nicht unbedingt besser. Die Aufmerksamkeit des Modells wird auf mehr Token verteilt, und frühere, bereits irrelevante Inhalte beginnen, die aktuelle Aufgabe zu stören, was zu einer Verschlechterung der Leistung führt. Dies ist der „Kontextverfall“.

Dies ist kein von der Community erfundener Begriff, sondern stammt aus einem offiziellen Blogbeitrag von Anthropic.

Bereits bei der Veröffentlichung von Sonnet 4.6 im Februar dieses Jahres wurde in der Ankündigung festgehalten, dass Sonnet 4.6 ein Beta-Fenster mit einer Million Token-Kontextlänge bietet.

Aber eine Million Token sind nicht gleich einer Million effektiven Token.

Jede Nachricht, die Sie in das Gespräch einfügen, jeder Dateilesevorgang und jeder Toolaufruf verdünnen die Aufmerksamkeit des Modells.

Frühere, bereits irrelevante Inhalte verschwinden nicht automatisch. Sie stören wie Rauschen die aktuelle Aufgabe weiterhin.

Nachdem das Problem aufgeworfen wurde, gibt Anthropic in diesem Blogbeitrag eine umfassende Verwaltungsstrategie an.

Zuerst wird Ihnen gesagt, dass „Ihr Gespräch im Verfall begriffen ist“, und dann wird Ihnen gezeigt, wie Sie es beheben können.

Je länger der Kontext, desto dümmer wird die KI

Schauen wir uns zunächst den Mechanismus des „Kontextverfalls“ genauer an.

Eine Million Token klingt wie eine Menge.

Eine mittelgroße Codebasis, einschließlich Dokumentation und Quellcode, umfasst möglicherweise nur einige hunderttausend Token. Theoretisch können Sie das gesamte Projekt hineinstopfen und dann beliebig fragen.

Aber die Aufmerksamkeit des Modells ist eine begrenzte Ressource.

Die Konfigurationsdatei, die Sie vor zwei Stunden gelesen haben, das Protokoll einer fehlgeschlagenen Fehlersuche vor einer Stunde und ein Sackgasse, die Sie vor einer halben Stunde erkundet haben, befinden sich alle noch im Fenster und konkurrieren um die Aufmerksamkeit des Modells.

Dies ist der Mechanismus des Kontextverfalls: Das Modell muss gleichzeitig zu viele irrelevante Dinge „merken“ und kann sich nicht auf die aktuelle Aufgabe konzentrieren.

Vielleicht denken Sie, dass dies genauso ist wie beim Menschen, wenn ein Meeting zu lange dauert und man ablenkt.

Das stimmt tatsächlich.

Informationsüberlastung führt zu einer Verdünnung der Aufmerksamkeit. Dies hat nichts mit der Fähigkeit zu tun, sondern ist ein Bandbreitenproblem.

Was noch schlimmer ist: Wenn der Kontext fast die Obergrenze von einer Million Token erreicht, löst das System automatisch eine „Kompression“ (compaction) aus:

D.h., dass das gesamte Gespräch zu einer kürzeren Zusammenfassung zusammengefasst wird, und dann wird in einem neuen Fenster weitergearbeitet.

Das klingt intelligent, aber genau in dem Moment, in dem die automatische Kompression erfolgt, ist der Kontext am längsten und die Leistung des Modells am schlechtesten.

Es ist schwierig, etwas zuverlässig zu machen, wenn man in dem dümmlichsten Zustand die wichtigste Zusammenfassung erstellt.

Jede Gesprächsrunde ist eine Weggabelung

Anthropic definiert in seinem Blogbeitrag jedes Gesprächsinteraktionsereignis als einen Entscheidungsknoten.

Nach jeder Interaktionsrunde stehen Sie an einer Weggabelung. Es gibt nicht nur die Möglichkeit, „weiterzuschreiben“.

Erste Option: Continue. Senden Sie eine weitere Nachricht in derselben Sitzung und gehen Sie einfach weiter. Der Kontext ist noch relevant, also ist es nicht nötig, sich zu bemühen. Dies ist die natürlichste Wahl und in den meisten Fällen auch ausreichend.

Zweite Option: /rewind. Drücken Sie zweimal Esc, um zu einer früheren Nachricht zurückzukehren und von dort neu zu beginnen.

Im offiziellen Blogbeitrag gibt es eine sehr treffende Einschätzung: Es ist besser, zurückzukehren, als zu korrigieren.

Das Zurückkehren (Rewind) ist in der Regel die bessere Korrekturmethode.

Angenommen, Claude hat fünf Dateien gelesen und eine Methode versucht, die nicht funktioniert hat. Ihre natürliche Reaktion wäre, zu sagen: „Das geht nicht, probieren Sie eine andere Methode.“

Aber das Problem dabei ist, dass die gesamten Zwischenschritte dieser fehlgeschlagenen Versuche noch im Kontext bleiben und die nachfolgenden Entscheidungen weiterhin beeinträchtigen.

Eine klüglichere Methode wäre, zum Zeitpunkt zurückzukehren, als die Dateien gelesen wurden, und eine präzisere Anweisung mit neuen Informationen zu senden: Verwenden Sie nicht Plan A, das foo-Modul hat diesen Schnittstellen nicht verfügbar gemacht, gehen Sie direkt zu Plan B.

Die nützlichen Dateilesevorgänge bleiben erhalten, die fehlgeschlagenen Versuche werden verworfen. Der Kontext ist sauber.

Sie können auch Claude bitten, die von ihm gelernten Inhalte zusammenzufassen und eine Übergabemeldung zu erstellen. Dies ist etwas wie eine Nachricht, die die zukünftige Version von Claude an die vergangene Version von sich selbst hinterlässt: Dieser Weg habe ich ausprobiert, er führt nicht zum Ziel.

Dritte Option: /clear. Starten Sie eine neue Sitzung und fügen Sie eine kurze Erklärung hinzu: Was Sie zuvor getan haben, was Sie jetzt tun möchten und welche Dateien relevant sind.

Der Vorteil ist, dass es keinen Kontextverfall gibt und Sie den Kontext vollständig kontrollieren können. Der Nachteil ist, dass es aufwändig ist, da Sie alle Hintergrundinformationen selbst schreiben müssen.

Vierte Option: /compact. Lassen Sie das Modell das aktuelle Gespräch zusammenfassen und ersetzen Sie die ursprüngliche Gesprächsgeschichte durch die Zusammenfassung.

Es ist bequem, aber es gibt Verluste.

Sie können eine Leitanweisung anhängen: /compact focus on the auth refactor, drop the test debugging (Konzentrieren Sie sich auf die Authentifizierungsumgestaltung, entfernen Sie die Testfehlersuche).

Lassen Sie es wissen, was beibehalten und was verworfen werden soll, anstatt es raten zu lassen.

/clear und /compact scheinen ähnlich, aber ihre Verhaltensweisen sind völlig unterschiedlich:

/compact lässt das Modell entscheiden, was wichtig ist. Sie haben es bequem, aber es kann wichtigste Informationen verloren gehen. Bei /clear müssen Sie die wichtigen Inhalte selbst schreiben. Es ist aufwändig, aber präzise.

Fünfte Option, Subagents.

Übertragen Sie einen Teil der Arbeit an einen Subagenten mit eigenem Kontext und lassen Sie ihn nur das Endergebnis zurückbringen.

Wenn Sie wissen, dass die nächste Aufgabe eine große Menge an Zwischenausgaben erzeugen wird, aber Sie nur das Endergebnis benötigen, ist der Subagent die sauberste Lösung.

Er erhält ein neues, unabhängiges Kontextfenster, in dem er alle aufwändigen Arbeiten erledigt. Alle Zwischenschritte bleiben im Subfenster, und am Ende wird nur eine Zusammenfassung in die Hauptsitzung zurückgesendet.

Subagents: Ihr einmaliger Ermittler

Von den fünf Aktionen wird der Subagent am häufigsten missverstanden.

Viele Menschen assoziieren beim Wort „Subagent“ mit „Multi-Agenten-Kooperation“: Teamarbeit, parallele Verarbeitung, Meetings von KI-Mitarbeitern.

Aber der Kernwert der Subagenten, wie in diesem Blogbeitrag von Anthropic beschrieben, besteht nur in einer Sache: Kontextisolierung.

In der offiziellen Dokumentation steht ausdrücklich: Jeder Subagent läuft in seinem eigenen Kontextfenster.

Er kann eine große Anzahl von Dateien lesen, umfangreiche Recherchen durchführen und den gesamten Ermittlungsprozess durchlaufen. Am Ende werden jedoch nur die Zusammenfassung und ein kurzes Metadatenstück an die Hauptsitzung zurückgesendet.

Alle diese massiven Zwischenschritte bleiben im einmaligen Kontext des Subagents. Ihre Hauptsitzung wird nicht von diesem Rauschen beeinträchtigt.

Das Kriterium, das Anthropic intern verwendet, ist auch sehr einfach:

Brauche ich später die Ausgabe dieser Tools selbst oder nur das Endergebnis?

Wenn die Antwort auf letzteres lautet, übergeben Sie es an den Subagenten.

Im Blogbeitrag werden drei typische Szenarien genannt:

Lassen Sie den Subagenten das Arbeitsergebnis anhand der Spezifikationsdatei überprüfen; lassen Sie den Subagenten eine andere Codebasis lesen und ihren Authentifizierungsprozess zusammenfassen, und dann implementieren Sie es selbst; lassen Sie den Subagenten anhand Ihrer Git-Änderungen Dokumentation schreiben.

Bei diesen drei Szenarien gibt es einen gemeinsamen Punkt: Der Prozess ist aufwändig, das Ergebnis ist einfach.

Deshalb ist der Subagent im Wesentlichen nicht Ihr Kollege, der mit Ihnen zusammenarbeitet, sondern eher Ihr „einmaliger Ermittler“.

Sein Arbeitsblatt kann nach Abschluss der Aufgabe weggeworfen werden, und Sie müssen nur den letzten Bericht nehmen.

Obwohl Claude Code automatisch Subagenten aufruft, können Sie ihm auch genauere Ausführungsanweisungen geben, z. B.:

Starten Sie einen Subagenten, um das Ergebnis dieser Arbeit anhand der folgenden Spezifikationsdatei zu überprüfen;

Erzeugen Sie einen Subagenten, um eine andere Codebasis zu lesen und die Implementierung ihres Authentifizierungsprozesses zusammenzufassen, und dann implementieren Sie es selbst auf die gleiche Weise;

Erzeugen Sie einen Subagenten, um anhand meiner Git-Änderungen Dokumentation für diese Funktion zu schreiben.

Achten Sie auf die Stürze bei der automatischen Kompression

Anthropic gibt in seinem Blogbeitrag einen Fehler zu, den viele Entwickler bereits gemacht haben: Der Sturz bei der automatischen Kompression (compaction).

Wann passiert der Sturz? Wenn das Modell nicht vorhersagen kann, was Sie als Nächstes tun werden.

Im Blogbeitrag wird ein Beispiel gegeben:

Sie haben eine lange Debugging-Sitzung durchgeführt, die automatische Kompression wurde ausgelöst, und das Modell hat den gesamten Debugging-Prozess zusammengefasst. Dann sagen Sie plötzlich: „Beheben Sie jetzt die Warnung in bar.ts.“

Aber da die gesamte Sitzung hauptsächlich um das Debugging herum revolvierte, war diese Warnung nur ein Nebeneffekt, der während des Prozesses gesehen wurde und bei der Kompression bereits entfernt wurde.

Wo liegt das Problem? Genau in dem Moment, in dem die automatische Kompression ausgelöst wird, ist der Kontext am längsten und die Leistung des Modells am schlechtesten.

Sie lassen ein bereits „abgelenktes“ Modell entscheiden, welche Informationen wichtig sind und welche verworfen werden können.

Glücklicherweise gibt das Millionenzeichen-Fenster einen Puffer.

Sie müssen nicht warten, bis die automatische Kompression ausgelöst wird. Sie können stattdessen frühzeitig die /compact-Funktion nutzen und eine Erklärung anhängen: Was Sie als Nächstes tun werden und welche Informationen beibehalten werden müssen.