Kontext als Budget

Mehr Kontext ist nicht mehr Verständnis

Wenn ein Modell eine Frage falsch beantwortet, obwohl die Antwort im mitgegebenen Material steht, ist der Reflex, mehr Material mitzugeben. Das ist der Fehler, den dieses Modul behandelt. Ein Kontextfenster ist keine Festplatte, auf der Information einfach liegt — es ist knappe, ungleich wirksame Fläche mit einem Preis pro Aufruf.

Drei Eigenschaften machen den Unterschied zur Festplatte, und alle drei sind gemessen statt behauptet: Information wirkt positionsabhängig, die effektiv nutzbare Länge liegt unter der beworbenen, und zusätzliches irrelevantes Material verdünnt das relevante. Wer diese drei kennt, budgetiert Kontext, statt ihn zu füllen.

Der Positionseffekt ist gemessen

Liu und Kollegen haben 2023 in TACL untersucht, wie Modelle lange Eingaben tatsächlich nutzen — über Mehrdokument-Fragen und Schlüssel-Wert-Abruf. Der Befund ist eine U-Kurve: Die Leistung ist am höchsten, wenn die relevante Information am Anfang oder am Ende des Kontexts steht, und fällt deutlich ab, wenn dieselbe Information in der Mitte liegt.

Der Titel der Arbeit — Lost in the Middle — ist wörtlich zu nehmen: Es geht nicht um Aufmerksamkeit im übertragenen Sinn, sondern um eine messbare Leistungseinbuße für Material an einer bestimmten Stelle. Und der Effekt betrifft ausdrücklich auch Modelle, die für lange Kontexte gebaut wurden.

Position im Kontext

Praktische Konsequenz

Anfang

Gut verwertet — hier gehören Instruktion und die wichtigsten Constraints hin.

Mitte

Schwächste Stelle — hier landet bei langen Kandidatenlisten genau das, was zählt.

Ende

Gut verwertet — hier gehören die aktuelle Frage und der wichtigste Beleg hin.

Beanspruchte und effektive Länge

Effektives Kontextfenster — Die Eingabelänge, bis zu der ein Modell eine Aufgabe noch verlässlich löst — im Unterschied zur technisch akzeptierten Länge. Die erste Zahl steht im Datenblatt, die zweite muss man messen.

Hsieh und Kollegen haben mit dem RULER-Benchmark genau diese Lücke vermessen, mit Aufgaben jenseits des simplen Nadel-im-Heuhaufen-Tests — darunter Mehrschritt-Verfolgung und Aggregation. Ergebnis: Fast alle untersuchten Modelle zeigen große Leistungsabfälle, wenn die Kontextlänge steigt. Und obwohl alle eine Kontextgröße von 32K Tokens oder mehr beanspruchen, hielt nur die Hälfte bei 32K noch eine befriedigende Leistung.

Das ist die nüchterne Version einer Zahl, die im Marketing als Fähigkeit erscheint. Ein beworbenes Fenster ist eine Obergrenze der Annahme, keine Zusage über die Verwertung. Für dich heißt das: Die nutzbare Länge ist eine Eigenschaft deiner Aufgabe und muss an deinen Fällen gemessen werden — sie steht in keinem Datenblatt.

Die eigene effektive Länge zu bestimmen ist unspektakuläre Arbeit: Nimm deine Aufgabe, baue Eingaben in aufsteigenden Längen — etwa 4K, 8K, 16K, 32K Tokens, gezählt mit dem count_tokens-Endpunkt statt geschätzt — und miss die Trefferquote je Stufe an derselben Fallmenge. Der Punkt, an dem die Kurve kippt, ist deine Grenze. Sie liegt bei Aufgaben mit Aggregation oder Mehrschritt-Verfolgung typischerweise deutlich früher als beim reinen Nachschlagen einer Angabe.

Verdünnung: das Signal-Rausch-Verhältnis

Aus Positionseffekt und effektiver Länge folgt gemeinsam ein Effekt, der in Reviews regelmäßig unterschätzt wird: Zusätzliches irrelevantes Material macht das relevante nicht bloß schwerer zu finden — es verdrängt es an schlechtere Positionen und senkt seinen Anteil am Ganzen.

Ein Beispiel mit Zahlen: Ein Prompt bekommt 3 relevante Absätze. Jemand ergänzt vorsorglich 30 weitere, weil sie thematisch verwandt sind. Der Anteil des Relevanten fällt von 100 % auf 9 %, die drei Absätze rutschen mit hoher Wahrscheinlichkeit in die Mitte, und die Eingabe ist elfmal so teuer. Die Antwortqualität sinkt — nicht, obwohl mehr Kontext da ist, sondern deswegen.

Der Effekt ist deshalb so hartnäckig, weil er sich im Einzelfall nicht zeigt. Wer die 30 Absätze ergänzt und eine Handvoll Anfragen ausprobiert, sieht plausible Antworten — die Verschlechterung ist eine Verschiebung in der Trefferquote über viele Fälle, kein sichtbarer Ausfall. Sie ist nur an einer festen Fallmenge messbar, und genau deshalb wächst der Kontext in Systemen ohne Eval-Set monoton: Jede Ergänzung wirkt harmlos, und niemand hat ein Instrument, das Gegenteil zu zeigen.

Relevanz vor Menge

Die praktische Regel ist damit unspektakulär: Relevanz für die aktuelle Anfrage entscheidet, nicht thematische Verwandtschaft und nicht Verfügbarkeit. Der Unterschied ist entscheidend, weil Verfügbarkeit die bequemste Auswahl ist — die Kundenhistorie liegt vor, also wird sie mitgegeben — und weil sie systematisch zu viel liefert.

• Was braucht die Antwort zwingend? Ohne dieses Material ist die Aufgabe unlösbar. Das kommt hinein.
• Was verbessert die Antwort messbar? Am Eval prüfen, nicht annehmen. Hinein, wenn es sich zeigt.
• Was ist thematisch verwandt? Das ist kein Kriterium. Verwandtschaft ist der häufigste Grund für Verdünnung.
• Was liegt ohnehin vor? Erst recht kein Kriterium — Verfügbarkeit ist eine Eigenschaft deines Systems, nicht der Anfrage.

Der Kontext ist ein Posten pro Aufruf

Neben der Qualität hat Kontext eine zweite, sehr direkte Eigenschaft: Er wird bei jedem einzelnen Aufruf bezahlt. Das klingt banal und wird trotzdem übersehen, weil ein Prompt-Block einmal geschrieben und danach millionenfach ausgeliefert wird. Ein fester Anhang wächst einmal um 2.000 Tokens und kostet ab dann in jedem Aufruf 2.000 Tokens.

Die Rechnung lohnt sich explizit. Bei 200.000 Aufrufen pro Tag sind 2.000 zusätzliche Eingabe-Tokens 400 Millionen Tokens täglich — für einen Block, den jemand ergänzt hat, weil er nützlich schien. Diese Zahl ist das Argument, das in Diskussionen über Prompt-Länge fehlt, und sie ist in fünf Minuten ausgerechnet.

• Feste Blöcke — Instruktion, Beispiele, Schema. Kosten pro Aufruf, dafür stabil und cache-fähig.
• Variable Blöcke — Dokumente, Verlauf, Nutzerfrage. Kosten pro Aufruf und schwanken mit dem Fall.
• Ausgabe — meist teurer je Token als Eingabe. Ausgabelänge ist ein eigener Posten, kein Nebeneffekt.

Zwei Größen sind dabei getrennt zu führen. Die Eingabelänge steuerst du über die Auswahl des Kontexts; die Ausgabelänge über die Aufgabe und die Obergrenze max_tokens. Ausgabe-Tokens sind je Token typischerweise deutlich teurer als Eingabe-Tokens — eine Anweisung, die zu ausführlicheren Antworten führt, ist also die teuerste Prompt-Änderung überhaupt, obwohl sie im Prompt kürzer ausfällt als ein zusätzlicher Beispielblock.

Präfix-Stabilität: die Reihenfolge ist eine Kostenentscheidung

Hier wird die Anordnung im Prompt zur Geldfrage. Prompt-Caching arbeitet über einen Präfix-Abgleich: Wiederverwendet wird nur ein Anfangsstück, das byteweise identisch ist. Ändert sich irgendein Byte im Präfix, ist alles dahinter entwertet — nicht nur die geänderte Stelle.

Anthropic dokumentiert dazu die Reihenfolge, in der eine Anfrage zusammengesetzt wird: erst die Werkzeugdefinitionen, dann der System-Prompt, dann die Nachrichten. Daraus folgt die Bauregel: Stabiles nach vorn, Veränderliches nach hinten. Ein Zeitstempel im System-Prompt, eine wechselnde Anfrage-ID oder eine nicht deterministisch sortierte Werkzeugliste entwerten den Cache bei jedem Aufruf — lautlos.

Bauentscheidung

Wirkung auf den Präfix

Instruktion und Schema an den Anfang

Bleiben identisch — der teure Teil wird wiederverwendet.

datetime.now() im System-Prompt

Entwertet den Cache bei jedem Aufruf, ohne Fehlermeldung.

Werkzeugliste in wechselnder Reihenfolge

Dasselbe: der Präfix ändert sich, obwohl inhaltlich nichts anders ist.

Nutzerfrage und Dokument nach hinten

Verändern nur das Ende — der Präfix bleibt gültig.

Ein zweiter Punkt gehört dazu, weil er still fehlschlägt: Ein Präfix wird erst ab einer Mindestlänge überhaupt zwischengespeichert, und diese Grenze hängt vom Modell ab. Ein kurzer System-Prompt kann also korrekt aufgebaut sein und trotzdem nie aus dem Cache gelesen werden — ohne Fehler, ohne Hinweis. Deshalb gehört die Markierung (cache_control) mit einer Messung zusammen und nicht mit einer Annahme.

Trunkierung ist eine Entscheidung

Irgendwann passt es nicht mehr. Der Standardfall in Produktionssystemen ist, dass dann irgendetwas wegfällt — meist das Ende der Liste, weil die Schleife dort abbricht. Das ist eine Entscheidung, die niemand getroffen hat und die niemand nachlesen kann.

Eine bewusste Trunkierung hat drei Bestandteile: reservierte Pflichtteile, die nie wegfallen (Instruktion, Schema, aktuelle Frage), eine dokumentierte Priorität für den Rest, und eine Spur darüber, dass gekürzt wurde und wie viel. Der dritte Punkt ist der, der in Vorfällen fehlt: Ohne Spur ist eine Antwort auf gekürztem Material von einer auf vollständigem nicht unterscheidbar.

Kompression und ihr Preis

Wenn Kürzen nicht reicht, liegt Verdichten nahe: einen langen Verlauf oder viele Dokumente von einem Modell zusammenfassen lassen und die Zusammenfassung mitgeben. Das funktioniert und hat einen scharfen, vorhersagbaren Preis — Kompression verliert zuerst das, was am wenigsten nach Prosa aussieht: Identifikatoren, Zahlen, Datumsangaben, Eigennamen.

Genau diese Dinge braucht die nachgelagerte Aufgabe aber häufig. Deshalb die Reihenfolge: zuerst verlustfrei aufräumen — Duplikate, Signaturen, Boilerplate, Navigationstexte, wiederholte Zitate —, und erst danach verlustbehaftet verdichten. Und wenn verdichtet wird, mit ausdrücklicher Anweisung, welche Elemente wörtlich zu erhalten sind.

Ein Budget, das man einhalten kann

Zum Schluss die Bauform, die aus den Befunden folgt: eine explizite Aufteilung des Fensters, bevor der erste Aufruf läuft. Nicht als Dokument für die Ablage, sondern als Zahlen im Code, gegen die geprüft wird.

Posten

Eigenschaft

Instruktion und Schema

Reserviert, fällt nie weg, stabil am Anfang für den Cache.

Beispiele

Reserviert, feste Zahl — nicht so viele, wie gerade hineinpassen.

Abgerufenes Material

Variabel mit Obergrenze und dokumentierter Priorität.

Verlauf

Variabel, verdichtet, mit reserviertem Anteil für die letzten Turns.

Aktuelle Frage

Reserviert, am Ende — die stärkste Position.

Reserve für die Ausgabe

Reserviert. Wer sie vergisst, bekommt abgeschnittene Antworten.

Was dieses Modul nicht behandelt

Zwei Nachbarthemen sind ausdrücklich nicht hier zu Hause, damit die Grenze klar ist. Erstens: Wie man Caching, Latenzbudgets und Zeitüberschreitungen im laufenden Betrieb auslegt, überwacht und ausrollt, gehört zum Track LLM Production Ops — hier ging es nur um die Prompt-Struktur, die Cache-Fähigkeit überhaupt ermöglicht.

Zweitens: Wie man einen Gesprächsverlauf über viele Turns verwaltet — Drift, Verdichtung, Neustart, Zustandsbesitz — behandelt das Modul Mehrturn-Verläufe und Zustand. Die Budget-Regeln von hier gelten dort weiter; die Frage ist dann aber, wer den Zustand besitzt, nicht wie viel hineinpasst.

Zusammenfassung — gleich im Check

Du kennst jetzt die Größen: den gemessenen Positionseffekt mit seiner U-Kurve, den Unterschied zwischen beanspruchter und effektiver Länge, die Verdünnung durch thematisch verwandtes Material, den Kontext als Posten pro Aufruf, die Präfix-Stabilität als Bauregel, Trunkierung mit Reserve, Priorität und Spur, sowie Kompression hinter verlustfreiem Aufräumen und mit benannten Pflicht-Elementen.