Ein größeres Kontextfenster wird Ihr Agentenproblem nicht lösen: Aufmerksamkeitsbudget und Caching

Ein Anbieter kann ein Kontextfenster mit einer Million Token bewerben, und das Modell wird dennoch zuverlässig weitaus weniger davon nutzen. Der RULER-Benchmark von NVIDIA prüft, bei welcher Länge ein Modell weiterhin gute Leistungen erbringt. Bei zwei der siebzehn getesteten Modelle, Yi-34B und GPT-4 (1106 Preview), lag die zuverlässige Länge bei etwa 32 K Token bei angegebenen 200 K Token sowie bei 64 K Token bei angegebenen 128 K Token. Die schwächsten Modelle versagten bereits bei einem winzigen Bruchteil dessen, was in der Beschreibung versprochen wurde. Ab diesem Punkt ist die beworbene Größe lediglich eine Angabe in der Preisliste und keine tatsächliche Produktionsfähigkeit.

Man beobachtet denselben zugrundeliegenden Fehler an mehreren Stellen. Ein Agent vergisst eine architektonische Entscheidung aus der ersten Runde. Ein RAG-System holt das richtige Dokument ab, antwortet aber dennoch falsch. Eine automatische Sitzungszusammenfassung lässt genau die Konfigurationszeile aus, die man benötigt hat. Der übliche Reflex ist es, ein größeres Arbeitsfenster zu kaufen – doch bei Agenten führt das nicht zum Erfolg, denn Kapazität war nie das Problem. Das eigentliche Problem ist, wie das Modell seine Aufmerksamkeit auf alles verteilt, was bereits in diese Kapazität passt.

Kurzfassung

Das Kontextfenster ist kein einheitliches Speichermedium. Es handelt sich um eine Ressource mit einem Aufmerksamkeitsbudget, das bereits weit vor dem Tokenlimit erschöpft ist. Material am Anfang oder Ende des Kontexts wird besser genutzt als Material in der Mitte – bis zu dem Punkt, dass ein Modell, dem ein Dokument mitten im Prompt übergeben wird, schlechter antworten kann als eines, dem nichts gegeben wird. Ein konkretes Beispiel: Ein Agent, der in einem einzigen Prompt einen langen Tool-Log, eine Menge abgerufener Fragmente sowie seine Anweisungen erhält, neigt dazu, das am Rande Liegende zu berücksichtigen und den Rest bewusst zu vernachlässigen.

Drei Tools verwalten dieses Budget, wobei jedes etwas anderes opfert:

• Prompt-Kompression entfernt Token mit geringer Informationsdichte. Sie erweist sich auf Referenzbenchmarks gut, doch unabhängige Wiederholungen zeigen Schwächen bei strukturiertem Inhalt wie Nummerierungen, exakten Zeichenketten und Codefragmenten.

Schiebepuffer und Kompression steuern die Länge der Sitzung. Der Schiebepuffer verwirft die ältesten Einträge, während die Kompression diese durch eine Zusammenfassung ersetzt – ihre Verluste unterscheiden sich dabei.

Prompt-Caching kann die Eingabekosten um etwa 90 Prozent senken, ohne Informationen zu verlieren, vorausgesetzt der Präfix ist bei den Aufrufen bytegenau identisch.

Hier liegt die Falle: Sowohl Kompression als auch Komprimierung zerstören den Cache, und die Einsparungen durch Caching übersteigen oft die durch Kompression. Die Verwendung des falschen Tools für das falsche Problem führt zu stillen Produktionsfehlern, die später nur schwer diagnostizierbar sind.

Kontext ist ein Budget, keine Speicherlösung

Zunächst zwei Begriffe. Ein Token ist die Texteinheit, mit der das Modell arbeitet – etwa vier Zeichen oder drei Viertel eines englischen Wortes. Das Kontextfenster gibt die maximale Anzahl der in einem Aufruf verarbeiteten Tokens an; es bezieht sich weniger auf die tägliche Speicherkapazität als vielmehr auf die maximale Größe der Aufmerksamkeitsmatrix bei einer einzigen Durchlaufphase.

Andrej Karpathy beschreibt das Kontextengineering als die Kunst, das „Fenster“ genau mit dem zu füllen, was der nächste Schritt benötigt – wobei das Modell als Prozessor und das Fenster als seine Arbeitsmemorie fungiert. Diese Analogie ist nützlich, deckt aber nur die Hälfte ab. Die andere Hälfte betrifft das Aufmerksamkeitsbudget. Anthropics Leitfaden zum Kontextengineering für Agenten betrachtet den Kontext als begrenzte Ressource mit abnehmender Effektivität, wobei jeder hinzugefügte Token von einem begrenzten Pool an Aufmerksamkeit genutzt wird. Das ist Rechenkunst, keine Poesie: Die Anzahl der Aufmerksamkeitspaare wächst quadratisch, sodass tausend Token etwa eine Million Beziehungen bedeuten und hunderttausend zehn Milliarden.

Daher ist das Hinzufügen von Kontext nur zur Vorsicht niemals kostenlos. Drei zusätzliche Beispiele für Few-Shot-Lösungen, eine vollständige Konversationshistorie oder zwanzig Tool-Definitionen anstelle von fünf beziehen sich alle aus demselben Pool wie die wichtigen Fakten. Die erste Frage bei einer Architekturüberprüfung sollte nicht lauten, wie viele Token verfügbar sind, sondern welche Teil des Budgets tatsächlich zum gewünschten Ergebnis beiträgt.

Die U-förmige Kurve

Liu und seine Kollegen (Stanford und Berkeley, 2023) maßen die Genauigkeit bei der Mehrdokumenten-Fragebeantwortung und stellten eine U-förmige Kurve fest. Die Antworten waren am zuverlässigsten, wenn der relevante Abschnitt zuerst oder zuletzt stand, und am unzuverlässigsten, wenn er in der Mitte lag. Der Begriff „Verloren in der Mitte“ setzte sich schnell durch, lange bevor eine einheitliche Erklärung gefunden wurde.

Was wirklich beunruhigend ist, ist ein Nebeneffekt. Wenn die Eingabe zwanzig oder dreißig Dokumente enthielt, erzielte eine richtige Antwort, die mitten im Kontext platziert wurde, eine geringere Bewertung als der Baseline-Test ohne Dokumente, bei dem das Modell überhaupt keine Dokumente sah. Die richtigen Beweise an der falschen Stelle bereitzustellen, kann das System in einer schlechteren Lage lassen als wenn es gar nichts erhält.

Warum das passiert: noch unklar

Jahre später gibt es keine Einigkeit über die Ursache. Mehrere Erklärungen stehen im Wettbewerb:

• ein Artefakt der Trainingsdaten, da Autoren dazu neigen, Schlüsselpunkte in Anfängen und Enden zu platzieren,
• die Funktionsweise der Positionsalphabete und kausalen Maskierungen,
• die grundlegende Geometrie des Dekoders, die bereits vor dem Training durch die Initialisierung entsteht,
• eine Anpassung, die während des Vortrainings entsteht, wenn das Modell konkurrierende Speicheranforderungen ausgleicht.

Jeder Grund erfordert ein anderes Gegenmittel: andere Trainingsdaten, eine andere Aufmerksamkeitsmaske, die Kalibrierung der Aufmerksamkeit oder einfach nur eine umgeordnete Anfrage. Sie in einer einzigen, klaren Erklärung zusammenzufassen wäre irreführend.

Was ist gelöst und was nicht

Die Frage, ob das Problem bereits gelöst ist, stellt es falsch dar. Die einfache Abrufung von Fakten ist größtenteils gelöst: Aktuelle Spitzendmodelle können einen wörtlich genannten „Nadel“ in einem sehr langen Heuhaufen überall dort finden, wo er sich befindet. Mehrschrittiges Reasoning hingegen ist noch nicht gelöst. Die Synthese mehrerer Dokumente oder das Bearbeiten von Code in einem großen Repository ist eine andere Aufgabe als die Suche nach einem einzelnen Fakt – und veröffentlichte Bewertungen zur Langkontext-Codeverarbeitung zeigen, dass die Erfolgsraten bei gleichem Modell und Aufgabentyp mit zunehmender Eingabelänge stark abnehmen.

Auch gibt es Hinweise dagegen, dass diese Kurve universell gilt. Chromas Context Rot-Studie prüfte achtzehn Grenzmodellreihen und stellte fest, dass ein durcheinandergewürfelter, logisch incoher Datensatz in allen Fällen einem kohärenten überlegen war, und seine Experimente ergaben ebenfalls keinen konstanten positionellen Vorteil. Die vernünftige Schlussfolgerung ist, dass es mehr als einen Degradationsmechanismus gibt, und „Lost in the Middle“ ist nur einer davon.

Eine einzige Formulierung, die die Bewertung von 27 % auf 98 % steigerte

Anthropic berichtete von einem aufschlussreichen Fall mit Claude 2.1 in einem „Nadel im Heuhaufen“-Test. Die Genauigkeit lag bei 27 Prozent, bis am Anfang der Antwort des Modells eine einzige Zeile hinzugefügt wurde, die es anwies, den relevantesten Satz aus dem Kontext auszuwählen. Danach stieg die Trefferquote auf 98 Prozent. Es wurden keine neuen Fähigkeiten hinzugefügt; lediglich eine Anweisung wechselte ihren Platz. Es handelte sich um eine einzige Bewertung, eine Modellversion und eine Art Aufgabe – daher sollte dies als Beispiel und nicht als allgemeine Regel für alle Anfragen angesehen werden.

Der Mechanismus: Aufmerksamkeits-Schlammgruben

Frühe Token in einer Sequenz ziehen unverhältnismäßig viel Aufmerksamkeit auf sich, egal ob sie relevant sind oder nicht. Der Grund liegt in der Mathematik: Softmax sorgt dafür, dass die Aufmerksamkeitsgewichte insgesamt eins ergeben, wodurch das Modell seine gesamte Aufmerksamkeit irgendwohin richten muss – selbst wenn nichts Vorhandenes dies verdient. Zurückhaltung ist keine Option, weshalb die ersten Positionen zu einer Art Ablagerungsstätte werden. Diese werden als Aufmerksamkeits-Schlammgruben bezeichnet.

Ein Team am MIT (Xiao und Kollegen) verwandelte diese Besonderheit in ein Werkzeug. Ihre Erkenntnis war, dass ein einfaches Schiebefenster genau in dem Moment zusammenbricht, in dem das erste Token aus dem Cache entfernt wird. Durch das Festhalten nur an den ersten wenigen Tokens als feste „Sinks“ bleibt die Generierung auch bei Strömen von Millionen von Token stabil – und das bis zu 22,2 Mal schneller als durch die erneute Berechnung jedes Fensters. Populäre Zusammenfassungen überspringen oft eine Einschränkung: Sie fügen keinerlei Tokens zum tatsächlichen Speicher hinzu. Die Ausgabe bleibt flüssig, während alte Tokens verschwinden, und jedes Token, das außerhalb des Fensters liegt, geht endgültig verloren. Stabilität und Speicherbedarf sind unterschiedliche Dinge.

Der praktische Rat lautet daher, die Schlüsselanweisung dort zu platzieren, wo die Aufmerksamkeit am stärksten ist – in der Regel am Ende – und dies anhand eigener Setup-Bedingungen zu überprüfen. Das gilt nicht universell: Einige Studien zeigen, dass „Sinks“, die mitten in einer Sequenz auftauchen, besser unterdrückt als geschützt werden sollten, und das Verhalten variiert je nach Modell.

Kompression, Fenster und Kompaktheit

Stellen Sie sich einen Koffer vor, der nicht alles aufnehmen kann. Sie können weniger wichtige Gegenstände weglassen, nur die neuesten einpacken oder eine Notiz darüber schreiben, was zu Hause geblieben ist. Jede Entscheidung bedeutet den Verlust von etwas anderem.

Schnelle Kompression

Die LLMLingua-Familie bewertet die Überraschungswertigkeit jedes Tokens mit einem kleinen Hilfsmodell und entfernt diejenigen mit geringen Informationen. Die Ergebnisse sind beeindruckend: Bei LLMLingua eine Kompression von bis zu 20 Mal, und bei dem auf Anfragen eingestellten LongLLMLingua eine Verbesserung von bis zu 21,4 Prozent bei NaturalQuestions – und das mit nur einem Viertel der Tokens. Es handelt sich dabei um zwei Varianten und nicht um ein einziges Ergebnis.

Unabhängige Nachahmungen erschweren das Bild. In einer Klage gegen das Referenzrepositorium wurde berichtet, dass der vollständig unkomprimierte Prompt deutlich bessere Leistungen zeigte als der komprimierte, was dem Inhalt des Papers widerspricht. Eine weitere Studie zum Komprimieren in diesem Bereich ergab, dass die Genauigkeit bei der Zählung von Fragmenten zurückging, da die Kompression die Nummerierung sowie genauen Zeichenketten zerstört. Die Schlussfolgerung ist nicht, dass die Kompression versagt – ihre Zuverlässigkeit ist umstritten und hängt vom Datentyp ab. Erzähltexte vertragen sie gut, während nummerierte Abschnitte, Identifikatoren, Code und Zahlen das nicht tun.

Drei Möglichkeiten zur Verwaltung einer Sitzung

• Schiebefenster-Verfahren. Einfaches First-In-First-Out: Man behält die letzten k Nachrichten oder N Token bei und wirft den Rest weg. Dies kostet computergestützt nichts, führt aber zu erheblichen Verlusten – eine Entscheidung aus Turn eins ist bereits im fünften Turn verschwunden, und das Modell kann etwas vorschlagen, das dieser Entscheidung widerspricht.

Kompaktion. Ersetzen Sie das ältere Gespräch durch eine Zusammenfassung. Das Risiko besteht darin, dass die Zusammenfassung so stark vereinfacht wird, dass wichtige Details verloren gehen, deren Bedeutung später erkennbar wird. Die Schwellenwerte variieren stark zwischen den Tools, doch eine gängige Empfehlung ist, die Kompaktion bei etwa 70 bis 75 Prozent der Kapazität auszulösen und nicht bei 95, da ein Modell ohne Pufferraum eine schlechtere Zusammenfassung erstellt.

Außermemorie. Im MemGPT-Stil befinden sich die Daten außerhalb des Fensters, und das Modell holt sie bei Bedarf über eine Funktionsaufruf ab. Nichts geht endgültig verloren, doch jeder Abruf verursacht Verzögerungen und einen zusätzlichen Funktionsaufruf. Zudem muss das Modell zunächst wissen, ob ein bestimmter Fakt überhaupt abgerufen werden sollte – was wiederum Anlass für Fehler bietet. Nutzen Sie diese Methode für Fakten, die auf Abruf verfügbar sein müssen, wie z. B. Benutzerpräferenzen oder frühere Entscheidungen, und nicht für alles.

Das Problem: Die Kompression zerstört den Cache-Rabatt

Durch schnellen Caching merkt sich der Anbieter den unveränderten Inhalt Ihrer Anfrage und berechnet spätere Lesevorgänge zu einem Bruchteil der üblichen Gebühr. Der darunterliegende KV-Cache speichert den berechneten Zustand früherer Token, sodass das Modell diese Arbeit nicht erneut durchführen muss.

Der Preis für diesen Rabatt ist die Starrheit: Der Präfix muss bei allen Aufrufen bytegenau identisch sein. Das schließt eine variable Zeitstempelangabe am Anfang, eine zufällige Session-ID vor den Anweisungen sowie umsortierte Schlüssel in einem JSON-Objekt aus. Alles Variable gehört in den volatilen Teil. Teams, die leistungsstarke Produktionsagenten einsetzen, bezeichnen die Cache-Hit-Rate als ihre wichtigste Systemmetrik – der Kostendifferenz zwischen Hit und Miss liegt dabei bei etwa zehn Mal.

Hier schließt sich die Falle. Die Kompression schreibt den Prompt bei jedem Aufruf neu, da die verwendeten Token von der jeweiligen Frage abhängen, wodurch jede Anfrage zu einem Cache-Miss wird. Eine Ersparnis von etwa sechzig Prozent bei den Tokenen geht einher mit dem Verlust eines Neunzig-Prozent-Rabatts, und dieses Nachteil wird häufiger eingefahren, als Teams annehmen.

In Marketingmaterialien kursiert eine Anekdote über eine Monatsrechnung, die nach der Einführung der Kompression von etwa 42.000 US-Dollar auf 2.100 US-Dollar sank, wobei kein Unternehmen, keine Datumangabe und keine Methode genannt werden. Es ist unmöglich zu erkennen, ob bei diesem Vergleich der verlorene Cache berücksichtigt wurde – schließlich ist genau diese Variable entscheidend dafür, ob ein solches Ergebnis sich wiederholt.

Ein Plan für Montag

Diese Liste ersetzt nicht die Tests mit Ihren eigenen Daten. Sie verhindert den häufigsten Fehler, nämlich sofort auf Kompression oder größere Zeitfenster zurückzugreifen, anstatt erst günstigere und sicherere Optionen zu prüfen.

1. Klassifizieren Sie die Aufgabe. Handelt es sich um den Abruf einfacher Fakten oder um mehrstufiges Denken in einem langen Kontext? Das bestimmt, wie ernst die Positionsschwäche tatsächlich ist.
2. Prüfen Sie, wo sich die wichtigste Anweisung befindet. Wenn sie mitten im Prompt versteckt ist, verschieben Sie sie an das Ende und messen Sie erneut. Es handelt sich dabei um eine Änderung in einem Satz – das ist die einzige verfügbare Möglichkeit hier.
3. Überprüfen Sie die Stabilität des Präfixes. Wenn sich der Systemprompt bei verschiedenen Aufrufen bereits um einen Byte unterscheidet, nützt das Caching nichts; daher muss dies zuerst behoben werden. In Bewertungen wird dieses Thema seltener erwähnt als die Wahl des Modells, kann aber dennoch einen größeren Einfluss haben.

Nennen Sie das Problem, bevor Sie ein Werkzeug wählen. Kostenintensive Probleme erfordern die Überprüfung des Caches vor der Kompression. Eine Qualität, die im Laufe einer langen Sitzung nachlässt, deutet auf eine Komprimierung bei einem Schwellenwert von 70 bis 75 Prozent hin. Vergessene spezifische Fakten deuten je nachdem, ob diese auf Anfrage zurückgegeben werden müssen, entweder auf ein Schiebefenster oder externe Speicher.

Falls Sie weiterhin Kompression verwenden, testen Sie diese an Ihren eigenen Daten, insbesondere an Daten mit genauen Zahlen, Identifikatoren und Code, bei denen veröffentlichte Ergebnisse am häufigsten nicht nachgeahmt werden können.

Was man daraus lernen kann

Ein größeres Fenster behebt kein Problem, da es lediglich die Kapazität einer Ressource erhöht, deren Problem niemals an der Kapazität lag.

• Das Fenster ist ein Aufmerksamkeitsbudget und keine Speicherkapazität, und jeder zusätzlich hinzugefügte Token entzieht Ressourcen aus dem Pool, der den wichtigen Daten dient.

Die Debatte um „The Lost in the Middle“ wird falsch dargestellt: Die Extraktion von Fakten wird größtenteils durch State-of-the-Art-Modelle erledigt, während mehrstufiges Reasoning in langen Kontexten weiterhin deutlich nachlässt.

Die Positionierung ist das günstigste Mittel, das man zur Verfügung hat – prüfen Sie sie daher, bevor Sie in teurere Lösungen investieren.

Bei der Kompression wurden in unabhängigen Tests bekannte Schwächen festgestellt, insbesondere bei Inhalten, die wortwörtlich erhalten bleiben müssen.

Caching und Kompression heben sich in wirtschaftlicher Hinsicht gegenseitig auf – berechnen Sie daher zunächst beide Einsparungen.

Der eigentliche Wandel in der täglichen Arbeit liegt in der Reihenfolge der Fragen bei einer Design-Überprüfung. Fragen Sie zunächst, was im Kontext enthalten ist und wo jeder Punkt steht, und erst danach, wie groß er ist. Wenn Sie die Reihenfolge umkehren, zahlen Sie den Preis dafür, dass wichtige Fakten in einem größeren Rahmen untergehen. Eine kurze Faustregel: Prüfen Sie zunächst die Position, dann die Stabilität, anschließend das Volumen und wenden Sie schließlich die Kompression an.