# Kontext als Budget > Das Kontextfenster ist knappe, ungleich wirksame Fläche mit einem Preis pro Aufruf: Positionseffekt, effektive gegen beanspruchte Länge, Verdünnung, Präfix-Stabilität, bewusste Trunkierung und die Kosten der Kompression. Track: [Prompt Engineering](https://physar.tech/learn/prompt-engineering) Kanonische Fassung: https://physar.tech/learn/prompt-engineering/context-window-budget Stand: 2026-09-04 Interaktiver Teil: 9 Checks (nur im Browser) ## 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. _[Abbildung: Jedes Token im Kontext kostet bei jedem Aufruf, konkurriert mit jedem anderen um Aufmerksamkeit und wirkt je nach Position unterschiedlich stark.]_ 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. > **Merksatz:** Kontext ist ein Budget, kein Speicher. Die Frage ist nie, ob etwas noch hineinpasst, sondern ob dieses Token seinen Platz und seinen Preis bei jedem Aufruf verdient. ### 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. | > **Was daraus folgt:** Bei einer Liste aus 40 abgerufenen Kandidaten liegt der Treffer statistisch meistens in der Mitte. Die Gegenmaßnahme ist nicht Umsortieren allein, sondern **weniger und besser** — die Kandidatenzahl senken und die stärksten an die Ränder legen. ### 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. > **Merksatz:** Ein Modell nimmt an, was hineinpasst, und verwertet, was es verwerten kann. Die beiden Zahlen sind verschieden, und nur die zweite entscheidet über die Antwortqualität. ### 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. > **Merksatz:** Etwas vorsorglich mitzugeben ist keine Sicherheitsmaßnahme, sondern eine Verdünnung. Jeder irrelevante Absatz verschlechtert die Position und den Anteil der relevanten. ### 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. > **Merksatz:** Der Kontext beantwortet **diese** Anfrage, nicht alle möglichen. Wer für den Fall vorsorgt, dass später etwas gefragt werden könnte, bezahlt bei jedem Aufruf für einen Fall, der meistens nicht eintritt. ### 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. > **Merksatz:** Jedes Token im Prompt ist eine wiederkehrende Ausgabe, kein Einmalaufwand. Ein Block, dessen Nutzen niemand messen kann, ist ein Abonnement ohne Gegenleistung. ### 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. > **Prüfbar machen:** Ob der Cache greift, ist keine Glaubensfrage: Die Antwort enthält mit `cache_read_input_tokens` die Zahl der aus dem Cache gelesenen Eingabe-Tokens. Bleibt sie über wiederholte Aufrufe mit gleichem Präfix bei null, gibt es einen stillen Entwerter — und den findet man, nicht vermutet man. ### 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. > **Merksatz:** Stille Trunkierung erzeugt Antworten, die vollständig aussehen und es nicht sind. Wenn gekürzt wird, muss es im Ergebnis oder mindestens im Protokoll stehen — sonst hat man eine unsichtbare Fehlerquelle eingebaut. ### 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 Verlauf, der nicht mehr passt Ein Support-Assistent bekommt den vollständigen Ticketverlauf. Bei Altkunden sind das bis zu 400 Nachrichten; das Fenster reicht nicht. Der Vorschlag: den Verlauf vom Modell auf 500 Wörter zusammenfassen lassen. Der Assistent muss in seiner Antwort auf konkrete Vorgangsnummern und Beträge Bezug nehmen können. **Anforderungen** - In welcher Reihenfolge gehst du vor? - Was verlierst du auch bei sauberem Vorgehen? **Schritte** - Verlustfrei aufräumen: Signaturen, Zitat-Blöcke voriger Mails, automatische Eingangsbestätigungen und Duplikate entfernen. Das kostet keine Information und schneidet solche Verläufe oft um die Hälfte. - Relevanz statt Vollständigkeit: nicht der ganze Verlauf, sondern die offenen Vorgänge plus die letzten Nachrichten. Ein abgeschlossener Vorgang von 2019 trägt zur aktuellen Frage nichts. - Erst danach verdichten — mit der ausdrücklichen Anweisung, Vorgangsnummern, Beträge und Datumsangaben wörtlich zu erhalten und Unsicherheit zu benennen statt zu glätten. - Die Pflichtteile reservieren und die Kürzung protokollieren: Wie viele Nachrichten sind eingegangen, wie viele in den Kontext gekommen? Ohne diese Zahl ist der nächste Vorfall nicht analysierbar. **Merksatz:** Kompression ist ein verlustbehafteter Schritt und gehört hinter jedes verlustfreie Aufräumen — und was wörtlich erhalten bleiben muss, muss man benennen, weil Verdichtung genau diese Elemente zuerst opfert. **+** Der Verlauf passt, die zitierfähigen Angaben bleiben, und die Kürzung ist nachvollziehbar. **−** Du hast eine zusätzliche Modellstufe im Pfad: mehr Latenz, mehr Kosten, und eine Fehlerquelle mehr — eine falsche Zusammenfassung ist im Ergebnis nicht mehr von einer falschen Antwort unterscheidbar. ### 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. | **Kurzcheck:** Euer Retrieval liefert 40 Kandidaten in den Kontext; der Treffer ist meistens dabei, wird aber oft nicht verwendet. Die Kandidaten sind nach Relevanz sortiert. Was ist die wirksamste Änderung? - [x] Die Kandidatenzahl deutlich senken und die stärksten an Anfang und Ende legen - [ ] Die Kandidatenzahl erhöhen, damit der Treffer sicher enthalten ist - [ ] Im Prompt betonen, dass alle Kandidaten gleich gründlich zu prüfen sind - [ ] Die Kandidaten unsortiert übergeben, damit keine Position bevorzugt wird > Genau. Beides adressiert den gemessenen Positionseffekt: Bei 40 Kandidaten liegt der Treffer meistens in der schwächsten Zone, und weniger Kandidaten heben zusätzlich den Anteil des Relevanten. ### 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. > **Haltung:** Ein größeres Fenster löst keine dieser Fragen, es verschiebt sie nur. Positionseffekt, Verdünnung und Kosten pro Aufruf gelten bei 1M Tokens genauso wie bei 8K — nur werden die Rechnungen größer. ### 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. > **Gleich im Check:** In den nächsten Aufgaben budgetierst du selbst. Achte auf den wiederkehrenden Reflex: Die naheliegende Antwort ist fast immer, mehr mitzugeben, und sie ist fast immer die falsche. ## Quellen - Liu et al., Lost in the Middle: How Language Models Use Long Contexts, TACL 2024 — https://arxiv.org/abs/2307.03172 - Hsieh et al., RULER: What's the Real Context Size of Your Long-Context Language Models?, 2024 — https://arxiv.org/abs/2404.06654 - Anthropic — Prompt caching (Präfix-Abgleich, Reihenfolge tools, system, messages, Cache-Kennzahlen) — https://platform.claude.com/docs/en/build-with-claude/prompt-caching - Anthropic — Prompting best practices: Structure prompts with XML tags — https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices - Maynez et al., On Faithfulness and Factuality in Abstractive Summarization, ACL 2020 — https://arxiv.org/abs/2005.00661