Context Rot, RAG und Long Context: Wie man LLM-Systeme im Jahr 2026 architektoniert

Das Jahr, in dem 2M-Token-Fenster aufhörten, eine Rolle zu spielen

Etwa sechs Monate lang, gegen Ende 2024 und Anfang 2025, machte ein vertrautes Argument die Runde in Engineering-Slack-Kanälen: RAG sei nun obsolet. Einfach alles hineinkopieren.

Die Argumentation klang sauber. Anthropic lieferte Claude Sonnet mit einem 1M-Token-Kontextfenster aus. Google brachte Gemini 2.5 und 2.5 Pro auf 2M Tokens. Meta kündigte Llama 4 Scout mit einer theoretischen Grenze von 10M Tokens an. Wenn Ihre Wissensbasis in einen einzigen Prompt passt, warum sich mit Vektorspeichern, Embedding-Pipelines und Chunking-Strategien herumschlagen?

Dann veröffentlichte Chroma Research im Juli 2025 "Context Rot: How Increasing Input Tokens Impacts LLM Performance" von Kelly Hong, Anton Troynikov und Jeff Huber. Das Paper führte sorgfältige Experimente über 18 Frontier-Modelle hinweg durch und zeigte etwas, das die Marketing-Seiten nicht offenbarten: Lange Kontextfenster degradieren auf nicht offensichtliche Weise lange bevor sie ihre Grenze erreichen. Ein 200K-Token-Fenster kann bei 50K Tokens Input bereits ernsthafte Genauigkeitseinbußen zeigen. Ein 1M-Token-Fenster ist nicht zuverlässig in der Lage, über 1M Tokens zu schlussfolgern.

Dieses Ergebnis hat die Architekturdiskussion neu gerahmt. RAG ist nicht obsolet. Long Context ist kein Gratisessen. Die interessante Frage lautet nicht mehr „welches gewinnt", sondern „welches Muster passt zu dieser Datenform, diesem Latenzbudget und dieser Aktualitätsanforderung".

Dieser Beitrag ist die architekturnahe Antwort: Wann sollte Ihr System abrufen, wann sollte es alles hineinkippen, und wann sollte es beides tun.

---

Was das Chroma-Paper tatsächlich gezeigt hat

Es lohnt sich, das Chroma-Paper sorgfältig zu lesen, denn die Schlagzeile („Context Rot existiert") wird dem, was tatsächlich darin steht, nicht gerecht. Das Team führte erweiterte Versionen von Needle-in-a-Haystack-Benchmarks (NIAH) über GPT-4.1, die Claude-4-Familie einschließlich Opus 4 und Sonnet 4, Gemini 2.5 und Qwen3 hinweg durch. Ihr offenes Replikations-Kit auf GitHub ermöglicht es Ihnen, die Läufe zu reproduzieren.

Drei Erkenntnisse stechen hervor.

Erkenntnis 1: Die Leistung degradiert ungleichmäßig mit zunehmender Eingabelänge. Das ist das Kernergebnis. Modelle werden nicht langsam und vorhersehbar in linearer Rate schlechter, wenn der Input länger wird. Sie stoßen auf Klippen. Manche Modelle schaffen 32K problemlos und brechen bei 64K zusammen. Andere halten zusammen, bis sie es plötzlich nicht mehr tun. Die Größe des dokumentierten Kontextfensters korreliert nur schwach damit, wie gut das Modell diesen Kontext tatsächlich nutzt.

Erkenntnis 2: Semantische Ähnlichkeit treibt den Verfall stärker als die Länge. Wenn die „Nadel" semantisch deutlich vom umgebenden „Heuhaufen" verschieden ist, finden Modelle sie problemlos. Wenn Ablenkungstexte semantisch ähnlich zur Antwort sind, sinkt die Genauigkeit stark, und der Einbruch wächst mit der Länge weiter. Mit anderen Worten: Je schwerer es ist, die Antwort vom Rauschen zu unterscheiden, desto schneller bricht der lange Kontext zusammen. Das passt zu einem separaten Ergebnis von Liu et al. (2024), "Lost in the Middle: How Language Models Use Long Contexts" in TACL, das eine U-förmige Leistungskurve zeigte, bei der die Mitte langer Kontexte systematisch unterbewertet wird.

Erkenntnis 3 (die überraschende): Strukturierter, kohärenter Text degradiert die Aufmerksamkeit STÄRKER als gemischter Text. Das ist das Ergebnis, das die Denkweise von Engineers verändern sollte. Die Intuition war, dass ein sauberes, gut organisiertes 100K-Token-Dokument für ein Modell leichter zu verarbeiten ist als ein chaotischer 100K-Token-Klumpen. Die Daten sagen das Gegenteil, oder zumindest nicht immer. Kohärenter Text scheint die Aufmerksamkeit diffuser über eine lange Sequenz zu verteilen, während gemischter Text deutlichere lokale Signale erzeugt, an denen sich das Modell festhalten kann. Die Implikation: Einem Modell ein aufgeräumtes, gut formatiertes PDF zu füttern, ist nicht automatisch sicherer, als ihm ein chaotisches Retrieval-Set zu füttern.

Der Sequential-NIAH Benchmark (arXiv 2504.04713) erweitert dies weiter, indem er testet, ob Modelle mehrere Retrievals aus verschiedenen Teilen eines langen Kontexts verketten können. Der Leistungsabfall ist beim mehrstufigen Reasoning über Distanz sogar noch steiler.

Hamel Husain fasste die praktische Implikation in seinen Notizen zu Context Rot gut zusammen: Die Engineering-Haltung sollte nicht „alles hineinpacken" sein, sondern „dem Modell den kleinstmöglichen, relevantesten Kontext geben, der die Frage beantwortet".

---

Warum Long Context scheitert: Der Mechanismus

Der Mechanismus ist wichtig, denn er prognostiziert, welche Workloads scheitern werden.

Die Standard-Transformer-Attention verwendet einen Softmax über alle Tokenpaare. Wenn die Sequenzlänge N wächst, verteilen sich die Attention-Gewichte über mehr Positionen. Selbst mit relativen Positionscodierungen wie RoPE (Rotary Position Embeddings) oder ALiBi wächst der Softmax-Nenner und das Gewicht pro Position auf einen einzelnen Token schrumpft. Bei 1M Tokens muss der „richtige" Token mit 999.999 anderen um ein endliches Aufmerksamkeitsbudget konkurrieren.

Positionscodierungen helfen, aber sie sind keine Zauberei. RoPE hat eine bekannte Verfallskurve, wenn man weit über die Trainingslänge hinaus extrapoliert. Modelle, die auf Sequenzen bis zu 32K Tokens trainiert wurden und bei 1M Tokens eingesetzt werden, betreiben Extrapolation, die die zugrunde liegende Mathematik nicht vollständig unterstützt. Tricks wie YaRN, Position Interpolation und NTK-aware Scaling erweitern den nutzbaren Bereich, aber keiner davon erzeugt ein Modell, das 1M Tokens so effektiv nutzt wie 32K.

Es gibt auch ein Problem mit den Trainingsdaten. Selbst wenn ein Modell auf langen Sequenzen trainiert, sind Beispiele, die kontextübergreifendes Schlussfolgern über 800K Tokens erfordern, selten. Modelle lernen, die Teile des Kontexts zu nutzen, die ihnen die Trainingsdaten beigebracht haben.

Context Rot ist kein Bug, den das nächste Release beheben wird. Es ist eine Eigenschaft der Architektur und der Trainingsverteilung. Zukünftige Modelle werden die Grenzen weiter verschieben, aber das Grundmuster wird eine Weile bestehen bleiben.

---

Wo RAG immer noch gewinnt

Angesichts von Context Rot ist Retrieval-Augmented Generation keine Legacy-Infrastruktur. Hier ist, wo es 2026 weiterhin gewinnt.

Multi-Dokument-Korpora im großen Maßstab. Wenn Ihre Wissensbasis aus 50.000 Dokumenten mit insgesamt 500M Tokens besteht, passt sie in kein Kontextfenster. Retrieval ist die einzige tragfähige Architektur.

Aktualität und Frische. Vektorspeicher aktualisieren sich inkrementell. Ein Long-Context-Prompt erfordert den Neuaufbau des Prompts bei jeder Inhaltsänderung. Für Dokumente, die stündlich aktualisiert werden (News, Kataloge, Support-Tickets, Code-Repos), bewältigt Retrieval Änderungen kostengünstig.

Kosten. Die Inferenzkosten skalieren ungefähr linear mit den Input-Tokens. 200K Tokens zu senden, kostet das 200-fache von 1K Tokens. Wenn 95 Prozent Ihrer Anfragen aus 5K relevanten Tokens beantwortet werden können, verschafft Ihnen Retrieval eine 40-fache Kostenreduktion ohne Genauigkeitsverlust.

Zitation und Provenienz. Retrieval liefert Ihnen eine strukturierte Liste von Quelldokumenten, die Sie anzeigen, verlinken und ranken können. Long-Context-Ausgaben lassen sich ohne zusätzliche Zitationsextraktions-Infrastruktur schwerer auf konkrete Quellen zurückführen.

Zugriffskontrolle und Mandantenfähigkeit. Wenn Ihr Korpus eine Sichtbarkeit pro Nutzer, pro Mandant oder pro Rolle hat, können Sie nicht einfach alles hineinkippen. Retrieval filtert nach Zugriffsrichtlinie, bevor das Modell die Daten sieht. Nicht verhandelbar für B2B-Produkte.

Reasoning über mehrere Korpora hinweg. Wenn die Antwort eine Slack-Nachricht, eine Notion-Seite, ein Linear-Issue und einen GitHub-PR kombiniert, ist Retrieval die Brücke.

Wenn Ihr Produkt eines dieser Kriterien erfüllt, ist RAG nicht optional. Die Frage wird, wie man Retrieval gut macht, nicht ob man es tun soll.

---

Wo Long Context gewinnt

Long Context hat Workloads, in denen es die richtige Antwort ist.

Tiefes Reasoning über ein einzelnes Dokument. Einen 100-seitigen Rechtsvertrag lesen und Fragen über Klauseln hinweg beantworten. Ein Forschungspapier analysieren. Ein Earnings Call zusammenfassen. Wenn die richtige Antwort zwei Absätze verbindet, die 80 Seiten voneinander entfernt sind, zerbricht Retrieval oft diese Verbindung. Long Context bewahrt sie.

Code-Verständnis innerhalb eines Repositorys. Viele Code-Reasoning-Aufgaben benötigen Imports, Typen, Definitionen und Aufrufstellen gleichzeitig. Chunking nach Dateien verliert die Beziehungen zwischen Dateien. Das gesamte Repository in den Kontext zu packen (wenn es passt), bewahrt die Struktur.

Konversationelle Kontinuität. Langlaufende Agent-Sitzungen profitieren von der vollständigen Historie im Kontext. Retrieval über die Konversationshistorie ist brüchig: Sie brauchen oft die letzten 50 Turns, nicht die semantisch ähnlichsten 50 Turns.

Exploratives Reasoning, bei dem Sie die Anfrage nicht kennen. Wenn Sie nicht sicher sind, was Sie ein Dokument fragen sollen, bis Sie angefangen haben, darüber nachzudenken, ist Retrieval schwer einzusetzen. Sie können die Anfrage nicht im Voraus schreiben. Long Context lässt das Modell das Material durchforsten.

Querverweise innerhalb einer kohärenten Einheit. Ein Lehrbuchkapitel, ein Forschungspapier, ein Rechtsgutachten: Diese sind logisch geschlossen. Chunking und Wiederzusammensetzen verliert oft die Argumentationsstruktur.

Grobe Heuristik: Wenn Ihre Daten ein einzelnes logisches Dokument sind und es passt, ist Long Context die sauberere Architektur.

---

Das hybride Muster, das tatsächlich funktioniert

Der Standard 2026 für ernsthafte LLM-Systeme ist weder reines RAG noch reiner Long Context. Es ist ein Hybrid: Rufen Sie eine umfangreiche, aber begrenzte Menge von Tokens ab, und schlussfolgern Sie dann mit Long Context darüber.

Hier ist der kanonische Ablauf:

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

Warum das funktioniert: Jede Stufe behandelt den Fehlermodus der anderen. Retrieval verengt einen Korpus, der für jedes Kontextfenster zu groß ist, auf eine handhabbare Menge. Long-Context-Reasoning über das Retrieval-Set stellt das Multi-Dokument-, Multi-Chunk-Reasoning wieder her, das reines RAG oft bricht, wenn es nur die Top-5-Chunks sendet.

Die entscheidende Engineering-Entscheidung ist die Größe des Retrieval-Sets. Senden Sie zu wenige Tokens, verlieren Sie den Long-Context-Vorteil (Sie könnten gleich klassisches Top-5-RAG machen). Senden Sie zu viele, lösen Sie Context Rot aus. Die Chroma-Daten legen nahe, dass die sichere Obergrenze deutlich unter dem dokumentierten Limit des Modells liegt, oft um das 4- bis 10-fache. Ein Modell mit 200K-Fenster ist meist solide bis zu 40K bis 80K. Ein Modell mit 1M-Fenster bewältigt oft 150K bis 300K mit minimalem Verfall.

Das ist das Architekturmuster, auf das die meisten Teams, die LLM-Features im großen Maßstab ausliefern, bis Ende 2025 konvergierten. Es ist nicht glamourös, aber es funktioniert.

---

Den Hybriden tunen: Zahlen und Heuristiken

Lassen Sie mich Zahlen an die Stellschrauben bringen. Das sind keine universellen Wahrheiten; es sind Startpunkte, die für viele Teams in der Produktion funktionieren.

Chunk-Größe. 500 bis 1.500 Tokens pro Chunk für die meiste Prosa. 200 bis 500 für Code (pro Funktion oder pro logischem Block). 1.500 bis 3.000 für juristischen oder akademischen Text, bei dem der Kontext innerhalb eines Chunks zählt. Überlappen Sie Chunks um 10 bis 20 Prozent.

Top-k-Retrieval. Holen Sie mehr, als Sie senden werden. Rufen Sie die Top 50 bis 200 ab, dann reranken. Der Reranker (ein Cross-Encoder, oft ein kleines spezialisiertes Modell wie Cohere Rerank oder ein feinjustierter BGE-Reranker) kostet pro Paar mehr als das Embedding-Modell, ist aber bei feinkörniger Relevanz drastisch genauer.

Verhältnis von Rerank zu Kontext. Nach dem Reranken behalten Sie die Top 20 bis 100 Chunks für die Long-Context-Stufe. Die genaue Zahl hängt von der Chunk-Größe und Ihrem sicheren Kontextbudget ab.

Hybrides Retrieval. Kombinieren Sie dichtes (Vektor) und sparsames (BM25, SPLADE) Retrieval mit Reciprocal Rank Fusion. Reines dichtes Retrieval verfehlt Exakt-Match-Anfragen (SKUs, Fehlercodes, Eigennamen). Reines sparsames Retrieval verfehlt Paraphrasen. Hybrid fängt beides ab.

Sicheres Kontextbudget. Testen Sie Ihr Modell. Bauen Sie ein kleines Eval-Set mit Fragen, deren Antwort Reasoning über mehrere Chunks bei unterschiedlichen Kontextlängen erfordert. Messen Sie die Genauigkeit bei 16K, 32K, 64K, 128K, 256K Tokens vollgestopftem Kontext. Wählen Sie die größte Größe, bei der die Genauigkeit noch akzeptabel ist. Das ist Ihr sicheres Budget. Bleiben Sie in der Produktion 20 Prozent darunter, um Spielraum zu lassen.

Retrieval komplett umgehen. „Fasse das Dokument zusammen, das ich gerade hochgeladen habe" ist eine Single-Document-Aufgabe. Erkennen Sie solche Anfragen mit einem kleinen Klassifikator und überspringen Sie Retrieval; das spart Latenz und vermeidet das Aufkommen unzusammenhängender Störgeräusche.

Zusammenfassungs-Schicht. Bei sehr langer Historie (monatelange Konversationen, große Codebasen) schalten Sie einen Zusammenfassungsschritt dazwischen, der älteres Material vor der Zusammenstellung komprimiert. Zusammenfassungen kosten ebenfalls Tokens, also testen Sie, ob sie helfen.

Hier ist eine Vergleichstabelle, die die Trade-offs erfasst:

---

Anti-Patterns, die Engineers weiterhin ausliefern

Einige Fallen treten häufig genug auf, um sie hervorzuheben.

„Einfach alles in den Kontext kippen." Verlockend nach jedem Release, das das Fenster verdoppelt. Die Chroma-Daten besagen, dass es lautlos degradiert. Sie werden Stichproben bestehen und in der Produktion bei Anfragen scheitern, die kontextübergreifendes Reasoning erfordern. Führen Sie immer eine Evaluation bei Ihrer Ziel-Kontextgröße durch, bevor Sie ausliefern.

„Immer RAG verwenden." Reflexartiges RAG für jeden Workload verfehlt Single-Document-Fälle. Ein 50-seitiges PDF in einen Vektorindex zu legen und dann Top-5-Chunks abzurufen, liefert in der Regel eine schlechtere Antwort, als dem Modell das gesamte PDF zu füttern. Heuristik: Wenn ein einzelnes Dokument in Ihr sicheres Kontextbudget passt und die Anfrage dieses Dokument betrifft, überspringen Sie Retrieval.

„Den Token-Count des Retrieval-Sets ignorieren." Teams setzen Top-k auf „wie viele auch immer hineinpassen" und entdecken drei Monate später, dass ihr durchschnittlicher Prompt 350K Tokens hat und die Genauigkeit stillschweigend degradiert ist. Erfassen Sie die zusammengestellte Kontextgröße als erstklassige Kennzahl. Warnen Sie darauf.

„Dem dokumentierten Fenster vertrauen." Ein 1M-Token-Fenster bedeutet nicht, dass das Modell 1M Tokens gleich gut nutzt. Die dokumentierte Grenze ist das, was Sie technisch senden können. Die nutzbare Grenze ist dort, wo das Modell noch auf Ihrem Qualitätsniveau performt. Das sind unterschiedliche Zahlen, oft um eine Größenordnung.

„Evals überspringen, weil das Modell jetzt gut ist." Upgrades bei Frontier-Modellen verändern die optimale Architekturentscheidung. Ein Workload, der auf GPT-4-32K RAG benötigte, kommt mit Long Context auf Gemini 2.5 Pro vielleicht zurecht. Werten Sie neu aus, wenn sich Modelle ändern.

---

Was sich an der Hardware 2026 ändert

Größere Fenster verschieben einige Entscheidungen. Es ist wichtig, genau zu sein, welche.

Llama 4 Scout mit 10M Tokens. Wenn der nutzbare Kontext auch nur die Hälfte des dokumentierten Limits beträgt, passen ganze mittelgroße Korpora in einen einzigen Prompt. Single-Tenant-Assistenten über eine interne Wissensbasis von 1M Tokens können Retrieval überspringen. Die Ökonomie zählt jedoch: 5M Tokens Input auf einem Frontier-Modell sind pro Anfrage teuer.

Gemini 2.5 / 3 Pro mit 2M Tokens. Ein 2M-Fenster mit Prompt-Caching verschiebt das Kalkül für Workflows, die wiederholt dasselbe große Dokumentenset abfragen. Cachen Sie 1,5M Tokens Hintergrundkontext, zahlen Sie nur für die marginale Anfrage, und die Kosten pro Anfrage beginnen, mit Retrieval zu konkurrieren.

Claude Sonnet 1M. Nützlich für agentische Workloads, bei denen der Session-State groß wird. Konversationsagenten, die ihre eigene Historie zusammenfassen oder per RAG abrufen mussten, können nun mehr Rohhistorie im Kontext halten.

Prompt-Caching über Anbieter hinweg. Anthropic, Google und OpenAI unterstützen alle Input-Caching. Long-Context-Architekturen werden für wiederholte Anfragen gegen stabile Inhalte deutlich günstiger. Der Kostenvorteil von RAG schrumpft, wenn Caching greift, verschwindet aber nicht.

Was sich nicht geändert hat: Context Rot. Keines dieser Releases enthält Benchmark-Daten, die zeigen, dass größere Fenster das Rot-Problem lösen. Größere Fenster heben die Decke an, aber dieselbe Form der Degradation bleibt bestehen. Sie müssen weiterhin Ihr sicheres Budget messen. Sie brauchen weiterhin Retrieval für aktuelle, mandantenfähige, mehrquellige Workloads. Hybrid bleibt der richtige Standard.

---

Ein Entscheidungsrahmen, den Sie tatsächlich anwenden können

Hier ist ein Ablauf, den Sie auf jedes neue LLM-Feature anwenden können. Gehen Sie ihn von oben nach unten durch.

Schritt 1: Wie groß ist Ihr Korpus?

• Unter 100K Tokens insgesamt: Überspringen Sie Retrieval, verwenden Sie direkt Long Context.
• 100K bis 1M Tokens: Hängt von der Aktualität ab (gehen Sie zu Schritt 2).
• Über 1M Tokens: Retrieval ist erforderlich.

Schritt 2: Wie aktuell müssen die Daten sein?

• Updates pro Stunde oder schneller: Retrieval. Long-Context-Prompts sind zu teuer, um sie neu aufzubauen.
• Updates pro Tag bis Woche: Beide Muster funktionieren.
• Statisch oder selten aktualisiert: Long Context mit Prompt-Caching ist günstig und sauber.

Schritt 3: Wie sieht die Anfrageform aus?

• Tiefes Reasoning über ein einzelnes Dokument: Tendieren Sie zu Long Context.
• Multi-Dokument-Synthese: Tendieren Sie zum Hybrid.
• Nachschlagen oder Faktenabruf: Tendieren Sie zu klassischem RAG (Top-k, kleiner Kontext).
• Explorativ oder offen: Tendieren Sie zu Long Context, wenn das Dokumentenset begrenzt ist; sonst Hybrid.

Schritt 4: Brauchen Sie Zitation oder Zugriffskontrolle?

• Ja zu einem von beiden: Retrieval ist erforderlich (entweder klassisches RAG oder Hybrid). Reine Long-Context-Architekturen lassen sich sehr schwer nachträglich mit Zitationen und Filtern pro Nutzer ausstatten.

Schritt 5: Wie sieht Ihr Latenzbudget aus?

• Unter 1 Sekunde: Klassisches RAG (kleiner Kontext, schnell).
• 1 bis 5 Sekunden: Hybrid ist machbar.
• Über 5 Sekunden: Jedes Muster funktioniert.

Schritt 6: Wie sieht Ihre Genauigkeits-Mindestschwelle bei langen Anfragen aus?

• Hohe Genauigkeit bei mehrstufigem Reasoning über mehr als 50K Tokens: Hybrid mit Reranker.
• Best Effort: Klassisches RAG ist meist in Ordnung.

Gehen Sie diese sechs Schritte durch, und Sie landen bei einer von drei Architekturen: klassisches Top-k-RAG, reiner Long Context oder Hybrid. Die meisten Produktionssysteme für ernsthafte Workloads landen beim Hybrid. Nicht weil Hybrid universell besser ist, sondern weil reale Workloads in der Regel mindestens eine Bedingung haben (mandantenfähige Daten, Aktualität, Kosten, Zitation), die reinen Long Context bricht, und mindestens eine (Single-Doc-Reasoning, kontextübergreifende Anfragen, Exploration), die reines Top-k-RAG bricht.

Das Chroma-Paper hat den Diskurs verändert. Es ließ das Argument Long Context versus RAG im Nachhinein etwas peinlich erscheinen. Sie sind keine Konkurrenten; sie sind zwei der drei Komponenten eines funktionierenden LLM-Stacks, und die dritte (Reranking) ist das, was den Hybrid stabil macht.

---

Häufig gestellte Fragen

Hat Geminis 2M-Kontextfenster RAG getötet?

Nein. Das 2M-Token-Fenster ist real, aber das Chroma-Paper "Context Rot" hat gezeigt, dass die Leistung lange vor dem Erreichen der Fenstergrenze nachlässt. Praktische sichere Kontextbudgets für Modelle mit 2M-Fenster landen bei hochgenauen Workloads tendenziell bei 150K bis 400K Tokens, also weit weniger als das vermarktete Limit. RAG (oder das hybride Retrieve-then-Reason-Muster) bleibt die richtige Architektur für große, mehrdokumentige, frische oder mandantenfähige Korpora.

Was ist Context Rot in einfachen Worten?

Context Rot ist die Beobachtung, dass LLMs langen Kontext schlechter nutzen, als die Marketingmaterialien suggerieren. Wenn Sie mehr Tokens hineinfüttern, degradiert die Genauigkeit bei Retrieval- und Reasoning-Aufgaben nicht-linear. Sie wird schneller schlechter, wenn Ablenkungstexte semantisch ähnlich zur Antwort sind, und selbst kohärenter, gut strukturierter Input kann die Aufmerksamkeit stärker schaden als gemischter Input. Das Ergebnis: Ein 1M-Token-Fenster zu füllen, liefert Ihnen keine Antwort in 1M-Token-Qualität.

Wie groß sollte mein Retrieval-Set sein, bevor Context Rot einsetzt?

Testen Sie Ihr spezifisches Modell. Ein grober Ausgangspunkt: Bleiben Sie bei hochgenauen Workloads bei 20 bis 40 Prozent des dokumentierten Kontextfensters. Bei einem Modell mit 200K-Fenster sind das 40K bis 80K Tokens Retrieval. Bei einem Modell mit 1M-Fenster 200K bis 400K. Bauen Sie ein kleines Eval-Set mit Multi-Hop-Reasoning-Fragen und messen Sie die Genauigkeit über Kontextgrößen hinweg. Wählen Sie die größte Größe, bei der die Genauigkeit noch in Ihrem Qualitätsbereich liegt.

Verändert Prompt-Caching das Kalkül?

Ja, deutlich. Prompt-Caching (verfügbar bei Anthropic, Google und OpenAI) macht die marginalen Kosten von Long-Context-Anfragen gegen stabile Inhalte deutlich günstiger. Wenn Sie ein großes Set an Hintergrunddokumenten cachen können und nur für das Delta pro Anfrage zahlen, wird Long Context für eher statische Korpora ökonomisch konkurrenzfähig mit Retrieval. Caching behebt jedoch nicht Context Rot: Gecachter Long Context ist immer noch Long Context, mit derselben Genauigkeitsdegradation.

Sollte ich einen Reranker verwenden, bevor ich an Long Context sende?

Für die meisten produktiven Hybrid-Systeme: ja. Ein Reranker (Cross-Encoder-Modell, das Anfrage-Dokument-Paare bewertet) über Ihre 50 bis 200 abgerufenen Top-Chunks verbessert drastisch die Relevanz dessen, was Sie an die Long-Context-Stufe weitergeben. Das Auslassen des Rerankings führt oft dazu, dass man mehr Tokens vollstopft, um die geringere Präzision zu kompensieren, was Sie in die Rot-Zone drückt. Reranking gehört zu den hebelstärksten Verbesserungen, die Sie an einer hybriden Pipeline vornehmen können.

---

Schlussgedanken

Das Verführerische an jedem neuen Modell-Release mit größerem Fenster ist das implizite Versprechen: „Hör auf zu engineerieren, schmeiß es einfach rein." Das Chroma-Paper hat harte Zahlen darauf gesetzt, warum dieses Versprechen nicht eingelöst wurde, und die zugrunde liegende Mathematik (Softmax-Verdünnung, Extrapolation der Positionscodierung, Trainingsverteilung) lässt vermuten, dass es nicht sauber eingelöst werden wird, selbst wenn Kontextfenster auf 100M Tokens anwachsen.

Was uns bleibt, ist die langweilige, produktive Antwort. Bauen Sie Retrieval. Tunen Sie es. Fügen Sie einen Reranker hinzu. Wählen Sie ein sicheres Kontextbudget durch Messen, nicht durch Vertrauen in das Datenblatt. Senden Sie dem Modell die kleinstmögliche, relevanteste Menge an Tokens, die die Antwort tatsächlich enthält. Lassen Sie es darüber schlussfolgern. Zitieren Sie die Quellen.

Das ist weniger aufregend als „die AGI ist da, kopier einfach deine Codebasis rein", aber es liefert Features aus, die in der Produktion funktionieren. Die Teams, die im Jahr 2026 still und leise gute LLM-Produkte bauen, sind diejenigen, die das Long-Context-Narrativ mit Skepsis behandelt haben und das RAG-Narrativ mit derselben Skepsis, und am Ende mit hybriden Pipelines dastehen, die die Workloads bewältigen, die sie tatsächlich haben.

Architekturentscheidungen überdauern Modell-Releases. Treffen Sie die richtigen, und das nächste Modell-Upgrade ist eine kostenlose Verbesserung statt eines erzwungenen Rewrites.