Was Context Rot in LLMs bedeutet
Context Rot ist die gemessene Tendenz eines großen Sprachmodells, Informationen mit zunehmender Eingabelänge schlechter zu nutzen, und zwar lange bevor das Kontextfenster voll ist. Chroma Research hat das im Juli 2025 an 18 Frontier-Modellen mit Zahlen belegt, und die Folgearbeiten bis 2026 haben den Befund eher geschärft als abgeschwächt. Ein Modell, das mit 1M Tokens beworben wird, schlussfolgert über 1M Tokens nicht in der Qualität, die es bei 30K zeigt.
Die praktische Fassung für alle, die entscheiden müssen, was sie bauen: Das dokumentierte Kontextfenster gibt an, wie viel gesendet werden darf. Das nutzbare Fenster reicht so weit, wie das Modell die geforderte Qualitätsschwelle noch erreicht. Das sind zwei verschiedene Zahlen, und die zweite ist meist ein Bruchteil der ersten.
Genau diese Lücke ist der Grund, warum das Argument, das Ende 2024 und Anfang 2025 durch die Engineering-Kanäle lief („RAG ist jetzt überflüssig, einfach alles hineinkopieren"), schlecht gealtert ist. Die Fenster sind tatsächlich gekommen. Anthropic liefert 1M Tokens bei Claude Opus 5 und Claude Sonnet 5. Die GPT-5.6-Familie von OpenAI bringt rund 1.05M. Googles Gemini 3.1 Pro bringt 1M. Metas Llama 4 Scout dokumentiert 10M. Nicht gekommen ist ein Modell, das all das auch gut nutzt.
Die interessante Frage lautet deshalb nicht mehr „welches Verfahren gewinnt", sondern „welches Muster passt zu dieser Datenform, diesem Latenzbudget, dieser Aktualitätsanforderung und dieser Rechnung". Genau das beantwortet der Rest dieses Textes.
Was Chromas Context-Rot-Forschung gezeigt hat
Die Schlagzeile („Context Rot existiert") wird der Arbeit nicht gerecht. In Context Rot: How Increasing Input Tokens Impacts LLM Performance, veröffentlicht am 14. Juli 2025, führten Kelly Hong, Anton Troynikov und Jeff Huber kontrollierte Experimente über 18 Modelle hinweg durch: die Claude-4-Familie plus Claude 3.7 und 3.5, o3, die GPT-4.1-Familie, GPT-4o, GPT-4 Turbo, Gemini 2.5 Pro und Flash sowie drei Größen von Qwen3. Mit ihrem Replikations-Kit auf GitHub lässt sich alles nachstellen.
Vier Befunde sind für die Architektur relevant.
Die Leistung degradiert ungleichmäßig, wenn die Eingabe wächst. Wer wegen der Context-Rot-Kurve hier gelandet ist: Die Form ist der eigentliche Punkt. Es ist kein sanfter linearer Abfall. Die Genauigkeit hält sich, dann stürzt sie über eine Klippe, und diese Klippe liegt bei jedem Modell woanders. Aufgetragen ergibt sich ein zackiger Abstieg, keine Rampe, und genau deshalb sagt eine Stichprobe bei einer Kontextgröße fast nichts über das Verhalten bei einer anderen aus.
Der Einbruch ist groß. Auf LongMemEval, einem Benchmark für dialogbasiertes Question-Answering, filterte das Team auf 306 Prompts herunter und verglich von jedem zwei Fassungen. Die fokussierte Fassung enthält nur das relevante Material und umfasst im Schnitt rund 300 Tokens. Die vollständige Fassung vergräbt dieselbe Antwort im umgebenden Gespräch und umfasst im Schnitt rund 113k Tokens. Mit den fokussierten Prompts kamen die Modelle gut zurecht, bei den vollständigen degradierten sie durchgängig. Der Abstand schwankt stark von Modell zu Modell, und Chroma merkte an, dass er bei den Claude-Modellen am ausgeprägtesten ausfiel. Gleiche Frage, gleiches Modell, gleiche Antwort in der Eingabe. Verändert wurde nur, wie viel irrelevanter Text mitkam.
Semantische Ähnlichkeit treibt den Verfall stärker als die Länge. Wenn sich die „Nadel" leicht vom „Heuhaufen" unterscheiden lässt, finden die Modelle sie. Sehen die Ablenker der Antwort semantisch ähnlich, fällt die Genauigkeit steil ab, und der Abfall wird mit der Länge größer. Schon ein einziger Ablenker verschlechtert die Leistung gegenüber der Baseline mit nur einer Nadel, vier verstärken den Effekt. Das passt zu Liu et al. (2024), "Lost in the Middle," in TACL: Dort zeigte sich eine U-förmige Kurve, bei der die Mitte eines langen Kontexts systematisch untergewichtet wird.
Strukturierter, kohärenter Text schadet der Aufmerksamkeit mehr als durchmischter Text. Das ist das Ergebnis, das die Denkweise von Engineers verändern sollte. Die Intuition sagt, über ein sauberes Dokument mit 100K Tokens lasse sich leichter schlussfolgern als über ein durcheinandergewürfeltes. Chroma fand das Gegenteil, und zwar durchgängig über alle 18 Modelle: Den Heuhaufen zu mischen und seinen logischen Fluss zu zerstören verbesserte die Leistung. Warum das so ist, bleibt offen; Chroma geht nur so weit zu sagen, dass die Struktur einer Eingabe beeinflussen könnte, wie Aufmerksamkeit verteilt wird. Der handlungsrelevante Teil braucht keinen Mechanismus: Ein ordentliches, sauber formatiertes PDF ist nicht automatisch die sichere Option.
Noch ein Detail für den Produktivbetrieb: Fehlermodi sind modellspezifisch. Unter Ablenkern zeigten die Claude-Modelle die niedrigsten Halluzinationsraten und enthielten sich bei Unsicherheit eher, während die GPT-Modelle die höchsten zeigten und eher selbstbewusst falsch antworteten. Wer zwischen beiden wählt, wählt zum Teil auch, welchen Fehler er lieber debuggt.
| Was verändert wird | Was mit der Genauigkeit passiert | Was das für Ihre Pipeline bedeutet |
|---|---|---|
| Eingabe wächst von ~300 auf ~113k Tokens | Durchgängige Degradation auf LongMemEval | Irrelevanter Kontext ist keine kostenlose Polsterung |
| Nadel sieht aus wie der Heuhaufen | Steiler Abfall, verschärft sich mit der Länge | Auf Präzision reranken statt nur Tokens ergänzen |
| Ein Ablenker hinzugefügt | Messbarer Abfall gegenüber der Baseline | Knappe Fehltreffer vor dem Zusammenbau entfernen |
| Heuhaufen durchmischt vs. kohärent | Durchmischt schnitt bei allen 18 Modellen besser ab | Saubere Formatierung ist kein Sicherheitspuffer |
| Modell unter Ablenkern getauscht | Claude enthält sich, GPT halluziniert | Den Fehlermodus wählen, der sich erkennen lässt |
Der Sequential-NIAH-Benchmark (arXiv 2504.04713) setzt aus einem anderen Blickwinkel an derselben Schwachstelle an und prüft, ob Modelle Nadeln extrahieren können, die in der richtigen Reihenfolge zurückkommen müssen. Über sechs LLMs hinweg und bei Kontexten von 8K bis 128K schaffte das beste Modell 63,5 Prozent. Mehrstufiges Retrieval über Distanz ist schwerer, als es die Demos mit einer einzelnen Nadel vermuten lassen.
Als sanfterer Einstieg: Hamel Husain hat Kelly Hong eingeladen, die Forschung durchzugehen, und eine kommentierte Mitschrift dieses Vortrags veröffentlicht. Die Schlussfolgerungen decken sich mit dem Report: Die Leistung ist über Kontextlängen hinweg nicht einheitlich, die Art der Präsentation von Informationen zählt, und bewusstes Context Engineering ist der Hebel.
Warum Long Context versagt: der Mechanismus
Der Mechanismus ist wichtig, weil er vorhersagt, welche Workloads brechen.
Transformer-Attention rechnet ein Softmax über Token-Paare. Wächst die Sequenzlänge, verteilt sich die Aufmerksamkeit auf mehr Positionen. Selbst mit relativen Positionskodierungen wie RoPE oder ALiBi wächst der Nenner des Softmax, und das Gewicht, das für ein einzelnes Token übrig bleibt, schrumpft. Bei 1M Tokens konkurriert das richtige Token mit 999.999 anderen um ein endliches Budget.
Positionskodierungen dehnen den Bereich, beseitigen das Problem aber nicht. RoPE degradiert, wenn weit über die Trainingslänge hinaus extrapoliert wird; ein Modell, das auf 32K-Sequenzen trainiert und bei 1M eingesetzt wird, betreibt also eine Extrapolation, die die zugrunde liegende Mathematik nicht vollständig trägt. YaRN, Positionsinterpolation und NTK-aware Scaling helfen alle, und keines davon erzeugt ein Modell, das 1M Tokens so gut nutzt wie 32K.
Hinzu kommt ein Problem mit den Trainingsdaten. Selbst wenn ein Modell auf langen Sequenzen trainiert, sind Beispiele, die echtes Schlussfolgern über 800K Tokens verlangen, selten. Modelle lernen, jene Teile des Kontexts zu nutzen, die ihre Trainingsdaten ihnen beigebracht haben.
Context Rot ist damit eine Eigenschaft der Architektur und der Trainingsverteilung und kein Bug, den das nächste Release wegpatcht. Künftige Modelle werden die Grenze weiter verschieben, und die Form der Degradation wird bleiben.
Premature Termination: was die Forschung 2026 ergänzt hat
Das nützlichste neue Ergebnis seit der Erstveröffentlichung dieses Artikels stammt aus der Arbeit an Long-Horizon-Agenten, nicht aus der Benchmark-Forschung.
In Diagnosing and Mitigating Context Rot in Long-horizon Search (Juni 2026) untersuchten Shijie Xia, Yikun Wang, Zhen Huang und Pengfei Liu vier Flaggschiff-Modelle über drei Benchmarks hinweg und benannten einen Fehlermodus, den die frühere Literatur übersprungen hatte: premature termination, den vorzeitigen Abbruch. Bei großem Kontext geben Modelle auf oder liefern eine unsichere, falsche Antwort zurück, lange bevor sie das Fenster ausgeschöpft haben. Kontrolliert man für die Schwierigkeit der Anfrage, steigt die Rate vorzeitiger Abbrüche mit der Kontextlänge.
Das rahmt das Problem neu. Context Rot umfasst zwei verschiedene Fehler, und sie verlangen gegensätzliche Korrekturen. Findet das Modell die Nadel nicht mehr, muss die Präzision steigen. Hört das Modell auf zu suchen, braucht es Raum und Anlass, weiterzusuchen. Bei einem Agenten mit mehrstufiger Suche kostet es Wochen, beides zu vermengen.
Der zweite Befund ist der, den man übernehmen sollte. Die Autoren analysierten sieben Methoden des Kontextmanagements in drei Kategorien und kamen zu dem Schluss, dass diese Methoden vor allem als Test-Time-Scaling-Strategien wirken: Indem sie die Rate vorzeitiger Abbrüche senken, verschaffen sie dem Modell mehr Exploration. Compaction und Pruning rechtfertigen sich damit als Genauigkeitsfeatures und nicht nur als Kostenkontrolle. Zusätzlich bauten die Autoren eine verhaltensbewusste Filterstrategie für paralleles Sampling und maßen über drei Aggregationsmethoden hinweg einen Zugewinn von 2,6 bis 4,9 Prozent.
Wer Agenten über lange Sessions laufen lässt, sollte messen, wie oft sie früh aufgeben. Das ist eine billige Metrik, und fast niemand instrumentiert sie.
Wo RAG weiterhin gewinnt
Vor diesem Hintergrund behauptet Retrieval-Augmented Generation weiterhin seinen Platz. Hier gewinnt es nach wie vor.
Große Korpora aus vielen Dokumenten. Umfasst die Wissensbasis 50.000 Dokumente mit insgesamt 500M Tokens, passt sie in kein Fenster. Retrieval ist dann die einzig tragfähige Architektur.
Aktualität und Frische. Vektorspeicher aktualisieren inkrementell. Ein Long-Context-Prompt muss neu gebaut werden, sobald sich Inhalte ändern. Bei allem, was stündlich aktualisiert wird (News, Kataloge, Support-Tickets, Code), verarbeitet Retrieval Änderungen günstig.
Kosten. Die Input-Kosten skalieren mit den Input-Tokens, und oberhalb bestimmter Schwellen skalieren sie schlechter als linear. Wenn sich 95 Prozent der Anfragen aus 5K relevanten Tokens beantworten lassen, ist Retrieval um ein Vielfaches günstiger, ohne Genauigkeit einzubüßen.
Zitate und Provenienz. Retrieval liefert eine strukturierte Liste von Quellen, die sich anzeigen, verlinken und ranken lässt, während es zusätzlichen Aufwand braucht, um eine Long-Context-Antwort in konkreten Quellen zu verankern. Aus demselben Grund schlägt ein Lesewerkzeug, das die Passage samt Quelle behält, eines, das nur eine Zusammenfassung behält: Wenn Sie in Glasp Fragen über alles stellen, was Sie gespeichert haben, kann jede Antwort auf das Highlight zurückzeigen, aus dem sie stammt.
Zugriffskontrolle und Mandantenfähigkeit. Wenn ein Korpus Sichtbarkeiten pro Nutzer, pro Mandant oder pro Rolle kennt, lässt es sich nicht komplett hineinkippen. Retrieval filtert nach Richtlinie, bevor das Modell überhaupt etwas sieht. Im B2B ist das nicht verhandelbar.
Reasoning über mehrere Korpora. Wenn die Antwort einen Slack-Thread, eine Notion-Seite, ein Linear-Issue und einen GitHub-PR umspannt, ist Retrieval die Brücke.
Trifft auch nur einer dieser Punkte zu, ist RAG nicht optional. Die Frage lautet dann, wie man Retrieval gut macht, nicht ob man es einsetzt.
Wo Long Context gewinnt
Für manche Workloads ist Long Context schlicht die richtige Antwort.
Tiefes Reasoning über ein einzelnes Dokument. Einen 100-seitigen Vertrag lesen und klauselübergreifend antworten. Ein Paper analysieren. Einen Earnings Call durcharbeiten. Wenn die Antwort zwei Absätze verbindet, die 80 Seiten auseinanderliegen, zerschneidet Chunking diese Verbindung oft.
Code-Verständnis innerhalb eines Repositories. Viele Code-Aufgaben brauchen Imports, Typen, Definitionen und Aufrufstellen gleichzeitig. Chunking pro Datei verliert die Beziehungen zwischen den Dateien.
Gesprächskontinuität. Lange Agenten-Sessions profitieren von echter Historie. Retrieval über den Gesprächsverlauf ist brüchig, weil meist die letzten 50 Züge gebraucht werden und nicht die 50 semantisch ähnlichsten.
Exploratives Reasoning, wenn die Anfrage noch nicht feststeht. Wer die Anfrage nicht vorab formulieren kann, kann Retrieval kaum zielen. Long Context lässt das Modell stöbern.
Querverweise innerhalb einer zusammenhängenden Einheit. Ein Lehrbuchkapitel, ein Paper, ein juristischer Schriftsatz. Diese zu zerteilen und wieder zusammenzusetzen kostet meist die Argumentation.
Grobe Heuristik: Bilden die Daten ein logisches Dokument und passen sie in das gemessene sichere Budget, ist Long Context die sauberere Architektur.
Das Hybrid-Muster, bei dem die meisten Teams landen
Der Standard für ernsthafte Systeme im Jahr 2026 ist weder reines RAG noch reiner Long Context. Man ruft eine substanzielle, aber begrenzte Menge an Tokens ab und schlussfolgert dann darüber.
User query
|
v
[Retrieval Stage]
- Vector search (top 100 chunks)
- Optional keyword/BM25 search merged in (hybrid retrieval)
- Optional reranker (cross-encoder over top 100, keep top 30)
|
v
[Assembly Stage]
- Concatenate retrieved chunks
- Add metadata, source headers, structural hints
- Target total: 50K to 200K tokens
|
v
[Long-Context Reasoning Stage]
- Send to frontier model with reasoning prompt
- Model uses the full retrieval set as its context
|
v
Answer + citations
Jede Stufe deckt den Fehlermodus der anderen ab. Retrieval verengt ein Korpus, das für jedes Fenster zu groß ist, auf etwas Handhabbares. Das Reasoning über die gesamte abgerufene Menge stellt jenes chunk-übergreifende Schlussfolgern wieder her, das klassisches Top-5-RAG wegwirft.
Die tragende Entscheidung ist die Größe der Retrieval-Menge. Zu wenige Tokens, und man hat nur Top-5-RAG nachgebaut. Zu viele, und man steckt in der Context-Rot-Zone und zahlt mehr für eine schlechtere Antwort. Eine brauchbare Faustregel, die der nächste Abschnitt in eine Messung überführt: Planen Sie ein sicheres Budget von etwa 20 bis 40 Prozent des dokumentierten Fensters und prüfen Sie es an den eigenen Daten nach. Bei einem Modell mit 200K-Fenster sind das 40K bis 80K. Bei einem Modell mit 1M-Fenster sind es 200K bis 400K, was zufällig ziemlich genau dort liegt, wo sich die Abrechnung ändert.
Den Hybrid tunen: Zahlen und Heuristiken
Das sind keine universellen Wahrheiten, sondern Startpunkte, die sich im Produktivbetrieb bewähren.
Chunk-Größe. 500 bis 1.500 Tokens für Fließtext. 200 bis 500 für Code, pro Funktion oder logischem Block. 1.500 bis 3.000 für juristische oder akademische Texte, in denen der Kontext innerhalb eines Chunks Bedeutung trägt. 10 bis 20 Prozent Überlappung.
Top-k-Retrieval. Mehr abrufen als am Ende gesendet wird. Top 50 bis 200 abrufen, dann reranken. Ein Cross-Encoder kostet pro Paar mehr als ein Embedding-Modell und ist bei feingranularer Relevanz dramatisch besser.
Verhältnis von Rerank zu Kontext. Nach dem Reranking die besten 20 bis 100 Chunks behalten. Die genaue Zahl ergibt sich aus der Chunk-Größe und dem sicheren Budget.
Hybrides Retrieval. Dichte und spärliche Verfahren (BM25, SPLADE) per Reciprocal Rank Fusion kombinieren. Rein dicht verpasst exakte Treffer wie SKUs, Fehlercodes und Eigennamen. Rein spärlich verpasst Umschreibungen.
Zwei dieser Stellschrauben verdienen mehr als einen Aufzählungspunkt, denn an ihnen verlieren Teams unbemerkt Genauigkeit.
Die erste ist das sichere Kontextbudget, und der einzig ehrliche Weg, es festzulegen, ist Messen. Bauen Sie ein kleines Eval-Set aus Fragen, die chunk-übergreifendes Schlussfolgern verlangen, und bewerten Sie die Genauigkeit bei 16K, 32K, 64K, 128K und 256K vollgestopftem Kontext. Nehmen Sie die größte Größe, die Ihre Schwelle noch überschreitet, und arbeiten Sie 20 Prozent darunter, um Luft zu behalten. Dieser gemessene Wert sollte ungefähr bei der obigen Regel von 20 bis 40 Prozent landen; tut er es nicht, gilt das Eval und nicht die Heuristik.
Die zweite ist das, was beim Modellwechsel passiert, und genau das hat Teams 2026 erwischt. Mit Claude Opus 4.7 hat sich Anthropics Tokenizer geändert: Derselbe Text ergibt nun je nach Inhalt ungefähr das 1,0- bis 1,35-Fache an Tokens, was Anthropic mit rund 30 Prozent mehr zusammenfasst. Die Dokumente sind nicht gewachsen. Das Budget ist geschrumpft. Wer vor einem Jahr eine Token-Obergrenze festgezurrt und darunter das Modell getauscht hat, hat heute eine Obergrenze mit anderer Bedeutung, und kein Logeintrag wird das ankündigen.
Retrieval ganz überspringen, wenn die Anfrage es nahelegt. „Das gerade hochgeladene Dokument zusammenfassen" ist eine Einzeldokument-Aufgabe. Erkennen Sie solche Fälle mit einem kleinen Klassifikator, überspringen Sie das Retrieval, sparen Sie Latenz und vermeiden Sie es, unverwandtes Rauschen einzuspielen.
Schichten für Zusammenfassung und Pruning. Bei sehr langen Historien älteres Material vor dem Zusammenbau komprimieren. Auch Zusammenfassungen kosten Tokens, also messen, ob sie tatsächlich helfen.
| Achse | Reines RAG (Top-5-Chunks) | Reiner Long Context | Hybrid (50K-200K abrufen, dann schlussfolgern) |
|---|---|---|---|
| Datenform | Viele Dokumente, breites Korpus | Ein Dokument oder kleine Menge | Viele Dokumente, tiefes Reasoning |
| Typische Eingabegröße | 2K-10K Tokens | 100K-1M Tokens | 50K-200K Tokens |
| Latenz | Schnell | Langsam | Mittel |
| Kosten pro Anfrage | Niedrig | Hoch, jenseits der Preisklippe noch höher | Mittel |
| Genauigkeit im großen Maßstab | Gut, wenn top-k stimmt | Degradiert durch Context Rot | Am besten für komplexe Anfragen |
| Aktualität | Einfach (Index aktualisieren) | Schwer (Prompt neu bauen) | Einfach (Index aktualisieren) |
| Zitate | Nativ | Erfordert Zusatzaufwand | Nativ (über die abgerufene Menge) |
| Zugriffskontrolle | Nativ (Filter beim Retrieval) | Schwer | Nativ |
| Reasoning über ein Dokument | Bricht oft | Stark | Stark |
| Dokumentübergreifendes Reasoning | Begrenzt (nur top-k) | Nicht zutreffend, außer bei einem Dokument | Stark |
Anti-Patterns, die Engineers immer wieder ausliefern
Einige Fallen wiederholen sich oft genug, um sie zu benennen.
„Einfach alles in den Kontext kippen." Nach jedem Release, das das Fenster verdoppelt, ist das verlockend. Es degradiert stillschweigend, also bestehen Sie die Stichproben und scheitern im Produktivbetrieb genau an den Anfragen, die kontextübergreifendes Schlussfolgern gebraucht hätten. Führen Sie vor dem Ausliefern ein Eval bei Ihrer Zielgröße durch.
„Immer RAG verwenden." Reflexhaftes Retrieval verfehlt die Einzeldokument-Fälle. Ein 50-seitiges PDF zu indexieren und die Top-5-Chunks zu ziehen ist meist besser als nichts, verliert aber gegen das schlichte Senden des PDF.
„Die zusammengebaute Token-Zahl ignorieren." Teams setzen top-k auf „was gerade passt" und stellen drei Monate später fest, dass ihr durchschnittlicher Prompt 350K Tokens umfasst, die Genauigkeit still gesunken ist und sich die Rechnung an einer Schwelle verdoppelt hat, die niemand gelesen hatte. Behandeln Sie die Größe des zusammengebauten Kontexts als erstklassige Metrik und alarmieren Sie darauf.
„Dem dokumentierten Fenster vertrauen." Die dokumentierte Grenze sagt, was gesendet werden darf. Die nutzbare Grenze liegt dort, wo die Qualität hält. Das sind zwei verschiedene Zahlen, und nur eine davon steht im Datenblatt.
„Evals weglassen, weil das Modell jetzt gut ist." Modell-Upgrades verändern die richtige Architektur und manchmal auch die Token-Buchhaltung im Untergrund. Bewerten Sie neu, wenn sich Modelle ändern.
„Ein stiller Fehler ist ein sicherer Fehler." Unter Ablenkern halluzinieren manche Modelle und andere enthalten sich, und bei Aufgaben mit langem Horizont hören manche einfach früh auf. Wissen Sie, welches Verhalten Ihr System zeigt, und instrumentieren Sie dafür.
Was sich 2026 geändert hat: Fenster, Preise und Compaction
Seit der ersten Fassung dieses Artikels haben sich zwei Dinge verschoben, und beide weisen in dieselbe Richtung.
Long Context hat inzwischen eine veröffentlichte Preisklippe, und zwar bei zwei Anbietern. OpenAI rechnet die GPT-5.6-Familie über zwei Tarife ab. Unterhalb der Schwelle kostet GPT-5.6 Sol $4 pro Million Input-Tokens und $20 pro Million Output-Tokens. Oberhalb kostet dasselbe Modell $8 und $30. Terra geht von $2/$12 auf $4/$18, Luna von $0.20/$1.20 auf $0.40/$1.80. Die Schwelle liegt bei 272K Input-Tokens, und ihr Überschreiten bepreist die gesamte Anfrage neu, nicht nur den Überhang. Ein Prompt mit 272.001 Tokens wird für jedes einzelne dieser Tokens zum höheren Tarif abgerechnet. Gemessen an einem beworbenen Fenster von 1.05M Tokens ist damit nur etwa ein Viertel davon zum beworbenen Preis zu haben.
Google macht dasselbe bei einer niedrigeren Schwelle. Gemini 3.1 Pro kostet $2 pro Million Input- und $12 pro Million Output-Tokens für Prompts bis 200K Tokens, darüber $4 und $18. Dieselbe Struktur aus 2x Input und 1,5x Output, nur 72K Tokens früher. Wer seine Pipeline an OpenAIs Klippe bemessen und dann den Anbieter gewechselt hat, überschreitet Googles Schwelle unbemerkt, ohne eine einzige Zeile Code zu ändern.
Dass zwei unabhängige Anbieter Long Context als Aufpreis bepreisen, ist stärkere Evidenz als jeder von beiden allein. Damit wird aus einem Qualitätsargument ein Budgetargument: Unter dem sicheren Kontextbudget zu bleiben war ohnehin schon der Schritt, der Genauigkeit erhält, und jetzt entscheidet er zusätzlich über eine oder zwei Rechnungen.
Anbieter liefern Kontextmanagement als Produktfeature aus. Anthropics Compaction fasst früheren Kontext serverseitig zusammen, während ein Gespräch wächst. Sie ist nicht standardmäßig aktiv, sondern muss eingeschaltet werden; ist sie aktiv, liegt die Auslöseschwelle bei Modellen mit 1M-Fenster standardmäßig bei 150K Tokens. Noch einmal in Ruhe gelesen: Der Anbieter mit dem Fenster von einer Million Tokens setzt seinen eigenen Standardwert auf 15 Prozent davon. Anthropic liefert außerdem Context Editing, das alte Tool-Ergebnisse oder Thinking-Blöcke entfernt, statt sie zusammenzufassen. Zwei verschiedene Mechanismen, dasselbe zugrunde liegende Eingeständnis.
Prompt Caching ist der echte Kostenhebel, und er wirkt: Gecachte Input-Lesevorgänge kosten bei beiden großen APIs etwa ein Zehntel des normalen Input-Preises. Caching macht wiederholte Anfragen gegen stabile Inhalte deutlich günstiger. Es behebt Context Rot nicht, und bei OpenAI befreit es auch nicht vom Long-Context-Tarif.
| Modell | Dokumentiertes Fenster | Praktischer Vorbehalt |
|---|---|---|
| Claude Opus 5 / Sonnet 5 | 1M Tokens | Compaction liegt nach dem Aktivieren standardmäßig bei 150K |
| Claude Haiku 4.5 | 200K Tokens | Sicheres Budget liegt bei etwa 40K-80K |
| GPT-5.6 (Sol / Terra / Luna) | ~1.05M Tokens | Gesamte Anfrage wird oberhalb von 272K Input neu bepreist |
| Gemini 3.1 Pro | 1M Tokens | Gesamte Anfrage wird oberhalb von 200K neu bepreist |
| Llama 4 Scout | 10M Tokens (iRoPE) | Dokumentiert, in dieser Tiefe aber nicht nachgewiesen |
Unverändert bleibt das zugrunde liegende Ergebnis. Keines dieser Releases lieferte Belege dafür, dass ein größeres Fenster Context Rot behebt. Größere Fenster heben die Decke an, die Form der Degradation bleibt, und für aktuelle, mandantenfähige Workloads aus vielen Quellen wird weiterhin Retrieval gebraucht.
Das ist dieselbe Disziplin, die sich generell beim Context Engineering zeigt: Was aus dem Prompt herausgelassen wird, zählt genauso viel wie das, was hineinkommt. Und es ist auch der Grund, warum die Retrieval-Schicht dieselbe Prüfung verdient wie jeder andere Eingabepfad, denn indirekte Prompt Injection kommt über abgerufene Dokumente herein und nicht über Ihre Nutzer.
Ein Entscheidungsrahmen für den sofortigen Einsatz
Gehen Sie das bei jedem neuen LLM-Feature von oben nach unten durch.
Schritt 1: Wie groß ist Ihr Korpus?
- Insgesamt unter 100K Tokens: Retrieval überspringen, Long Context verwenden.
- 100K bis 1M Tokens: hängt von der Aktualität ab, weiter zu Schritt 2.
- Über 1M Tokens: Retrieval ist Pflicht.
Schritt 2: Wie aktuell müssen die Daten sein?
- Stündlich oder schneller: Retrieval. Lange Prompts neu zu bauen ist zu teuer.
- Täglich bis wöchentlich: Beide Muster funktionieren.
- Statisch: Long Context mit Prompt Caching ist günstig und sauber.
Schritt 3: Welche Form hat die Anfrage?
- Tiefes Reasoning über ein einzelnes Dokument: eher Long Context.
- Synthese über mehrere Dokumente: eher hybrid.
- Nachschlagen oder Faktenabruf: eher klassisches RAG.
- Explorativ: Long Context, wenn die Dokumentmenge begrenzt ist, sonst hybrid.
Schritt 4: Brauchen Sie Zitate oder Zugriffskontrolle?
- Ja bei einem von beiden: Retrieval ist Pflicht. Zitate und nutzerbezogene Filter nachträglich in ein reines Long-Context-Design einzubauen ist schmerzhaft.
Schritt 5: Wie hoch ist Ihr Latenzbudget?
- Unter 1 Sekunde: klassisches RAG.
- 1 bis 5 Sekunden: hybrid ist machbar.
- Über 5 Sekunden: jedes Muster funktioniert.
Schritt 6: Wo liegt Ihre Genauigkeitsuntergrenze bei langen Anfragen?
- Hohe Genauigkeit bei mehrstufigem Reasoning jenseits von 50K Tokens: hybrid mit Reranker.
- Bestmöglicher Aufwand: klassisches RAG genügt meist.
Schritt 7: Wo landet Ihr zusammengebauter Prompt relativ zur Preisklippe?
- Unter 272K bei OpenAI, unter 200K bei Google oder unter dem andernorts gemessenen sicheren Budget: unproblematisch.
- Knapp an einer der beiden Schwellen: Reranker ergänzen und die Retrieval-Menge kürzen. Meist ergibt das gleichzeitig eine bessere Antwort und eine kleinere Rechnung.
Die meisten Produktivsysteme landen bei hybrid, weil reale Workloads mindestens eine Einschränkung mitbringen, die reinen Long Context bricht (Mandantenfähigkeit, Aktualität, Kosten, Zitate), und mindestens eine, die reines Top-k-RAG bricht (Reasoning über ein Dokument, kontextübergreifende Anfragen, Exploration).
Es gibt eine menschliche Version derselben Fähigkeit. Aufmerksame Leser haben immer schon von Hand entschieden, welches Material es verdient, vor einen Denkprozess zu gelangen, und Highlighting ist genau diese Entscheidung, explizit gemacht. Glasps Web-Highlighter behält die Passagen, die Sie für behaltenswert hielten, statt der ganzen Seite, und das ist Retrieval mit menschlichem Reranker. Wer eigene Werkzeuge auf diese Menge richten möchte: Glasps MCP-Connector stellt Ihre Highlights einem LLM direkt zur Verfügung. Mehr zu diesem Setup steht in Notizen in einen MCP-Server verwandeln.
Häufig gestellte Fragen
Was ist Context Rot in LLMs?
Context Rot ist die Beobachtung, dass LLMs langen Kontext schlechter nutzen, als das Marketing nahelegt. Je mehr Tokens hineingehen, desto nichtlinearer degradiert die Genauigkeit bei Retrieval und Reasoning: Es gibt Klippen statt einer sanft abfallenden Rampe. Der Effekt verstärkt sich schneller, wenn Ablenkertexte der Antwort ähneln, und Chroma fand über alle 18 getesteten Modelle hinweg, dass sogar kohärente, gut strukturierte Eingaben der Aufmerksamkeit mehr schadeten als durchmischte. Ein Fenster von 1M Tokens zu füllen erkauft keine Antwort in 1M-Token-Qualität.
Ist RAG 2026 veraltet?
Nein, und die Evidenz weist in die andere Richtung. Retrieval bleibt erforderlich für Korpora, die jedes Fenster übersteigen, für Daten, die sich stündlich ändern, für mandantenbezogene Zugriffskontrolle und für Zitate. Veraltet ist das klassische Top-5-RAG als einziges Muster. Der aktuelle Standard ist hybrid: eine begrenzte Menge abrufen und dann über alles davon schlussfolgern. Größere Kontextfenster haben verändert, wie viel abgerufen wird, nicht ob abgerufen wird.
Ersetzt Long Context RAG?
Im allgemeinen Fall nicht. Chromas Context-Rot-Report zeigte, dass die Leistung lange vor dem Füllen des Fensters degradiert, und die Anbieter haben dem inzwischen in ihren eigenen Produkten zugestimmt: Anthropics optionale Compaction fasst bei einem 1M-Token-Modell standardmäßig ab 150K zusammen, OpenAI bepreist Anfragen oberhalb von 272K Input-Tokens neu und Google oberhalb von 200K. Long Context ersetzt RAG dort, wo es um ein einzelnes, begrenztes Dokument geht, das in das gemessene sichere Budget passt.
Wie groß darf meine Retrieval-Menge sein, bevor Context Rot einsetzt?
Testen Sie Ihr konkretes Modell, aber ein vernünftiger Startpunkt sind 20 bis 40 Prozent des dokumentierten Fensters. Das sind 40K bis 80K bei einem 200K-Modell und 200K bis 400K bei einem 1M-Modell, wobei Sie bei OpenAI aus Abrechnungsgründen unter 272K und bei Google unter 200K bleiben sollten. Bauen Sie ein kleines Eval aus mehrstufigen Fragen, messen Sie die Genauigkeit über Kontextgrößen hinweg und nehmen Sie die größte Größe, die Ihre Schwelle noch überschreitet.
Behebt Prompt Caching Context Rot?
Nein. Caching behebt Kosten, nicht Genauigkeit. Gecachte Input-Lesevorgänge kosten etwa ein Zehntel des normalen Input-Preises, sodass Long-Context-Anfragen gegen stabile Inhalte deutlich günstiger werden und der Kostenvorteil von RAG schrumpft. Das Modell liest weiterhin denselben langen Kontext und degradiert auf dieselbe Weise, es wird also weniger für dieselbe schwächere Antwort gezahlt. Bei OpenAI befreit Caching zudem nicht vom Preistarif für Long Context.
Sollte ich vor dem Senden an Long Context einen Reranker einsetzen?
Für die meisten hybriden Produktivsysteme: ja. Ein Cross-Encoder, der die abgerufenen Top-50 bis Top-200-Chunks bewertet, verbessert deutlich, was die Reasoning-Stufe erreicht. Auf das Reranking zu verzichten bedeutet meist, mehr Tokens hineinzustopfen, um die schwächere Präzision auszugleichen, und das schiebt Sie sowohl Richtung Context-Rot-Zone als auch Richtung Preisklippe. Es ist eine der wirkungsvollsten Änderungen, die sich an einer hybriden Pipeline vornehmen lassen.
Mein Agent bricht bei langen Aufgaben früh ab. Ist das Context Rot?
Wahrscheinlich, und es hat inzwischen einen Namen. Das Paper von 2026, Diagnosing and Mitigating Context Rot in Long-horizon Search, nennt es premature termination: Unter schwerem Kontext geben Modelle auf oder antworten mit unverdienter Zuversicht, bevor sie das Fenster ausgeschöpft haben, und zwar mit einer Rate, die mit der Kontextlänge steigt. Kontextmanagement hilft vor allem, indem es diese Rate senkt, sodass der Agent weiter exploriert. Erfassen Sie frühe Abbrüche als eigene Metrik.
Abschließende Gedanken
Jedes Release mit einem größeren Fenster trägt dasselbe implizite Versprechen: Schluss mit dem Engineering, einfach alles hineinkippen. Chroma hat mit harten Zahlen belegt, warum dieses Versprechen nicht eingelöst wurde, die Arbeiten von 2026 haben einen zweiten Fehlermodus ergänzt, nach dem niemand gesucht hatte, und die zugrunde liegende Mathematik (Softmax-Verdünnung, Positions-Extrapolation, Trainingsverteilung) sagt, dass es auch bei 100M Tokens nicht sauber eingelöst wird.
Übrig bleibt die langweilige, produktive Antwort. Bauen Sie Retrieval. Tunen Sie es. Ergänzen Sie einen Reranker. Wählen Sie ein sicheres Kontextbudget durch Messen statt durch Vertrauen in ein Datenblatt, und messen Sie neu, wenn sich das Modell oder sein Tokenizer ändert. Senden Sie die kleinste, relevanteste Token-Menge, die die Antwort enthält. Lassen Sie das Modell darüber schlussfolgern. Nennen Sie die Quellen.
Die Wendung von 2026 ist, dass die Anbieter inzwischen so bepreisen und bauen, als stimmten sie dieser Sicht zu. Klippen bei 272K und 200K sowie eine Compaction-Voreinstellung bei 150K sind allesamt Eingeständnisse, dass das nutzbare Fenster nur ein Bruchteil des beworbenen ist. Das ist nützlich, denn es bedeutet, dass die disziplinierte Architektur zugleich die günstige ist, und diese beiden zeigen selten in dieselbe Richtung.
Wer eine breitere Karte dazu sucht, welches Modell auf welche Aufgabe gehört, findet sie in der Matrix aus KI-Aufgaben und Modellen. Architekturentscheidungen überdauern Modell-Releases. Trifft man sie richtig, ist das nächste Upgrade eine kostenlose Verbesserung statt einer erzwungenen Neuentwicklung.
