Der Zyklus wiederholt sich alle paar Monate mit verdächtiger Pünktlichkeit. Ein Labor kündigt ein größeres Kontextfenster an, die Ankündigung wird zum Screenshot, und im nächsten Meeting sagt jemand den Satz: « dann brauchen wir das RAG nicht mehr, wir packen die ganzen Dokumente in den Prompt und fertig ». Das klingt nach Vereinfachung, und genau das will jeder über eine Architektur hören, die Monate gekostet hat. Es ist auch die Art Vereinfachung, die man dreimal bezahlt: in Genauigkeit, in der Rechnung und in der Nacht, in der etwas falsch antwortet und niemand weiß, warum.
Die These in einer Zeile: « großes Kontextfenster oder RAG » ist keine Alternative, weil beide nicht dasselbe Problem lösen. Das Kontextfenster ist ein Kapazitätsmaß — wie viel in einen Aufruf passt. Retrieval ist eine Auswahlentscheidung — was hineinkommt, von allem, was du hast. Das Erste zu vergrößern beantwortet das Zweite nicht. Und wenn du darauf verzichtest zu entscheiden, was hineinkommt, ist das Ergebnis gemessen: die Genauigkeit fällt lange vor dem angekündigten Limit, die Kosten pro Aufruf steigen mit der Preisliste in der Hand, und der Fehler ist nicht mehr debuggbar, weil du nicht mehr weißt, welchen Abschnitt das Modell verwendet hat.
Hier geht es nicht darum, eine Architektur aus Zuneigung zu verteidigen. Es gibt Fälle — sie stehen am Ende, mit Namen —, in denen das große Fenster tatsächlich die richtige Antwort ist und Retrieval zu bauen Overengineering wäre. Es geht darum, aus den echten Gründen zu entscheiden und nicht wegen einer Launch-Schlagzeile.
Großes Kontextfenster oder RAG: nicht zweimal dieselbe Frage
Die Verwechslung hat eine konkrete Wurzel: beide enden an derselben Stelle — Text vor dem Modell im Moment der Antwort — und wirken deshalb austauschbar. Sie sind es nicht. Das Kontextfenster ist der Arbeitsplatz dieses Aufrufs: er füllt sich, wird genutzt, wird geleert. Retrieval ist der Mechanismus, der aus einem Korpus, der nicht hineinpasst und nie hineinpassen wird, die Abschnitte auswählt, die diesen Platz verdienen. Das eine ist die Größe des Tisches; das andere entscheidet, welche Papiere darauf landen.
Die vollständige Taxonomie — Gesprächskontext, abfragbares Wissen und Langzeitgedächtnis, wo jede Schicht lebt und was sie kostet — steht schon im Leitfaden zum Gedächtnis eines KI-Agenten, und sie hier neu zu argumentieren hätte keinen Sinn. Was dieser Leitfaden nicht abdeckt, weil es nicht seine Frage ist, ist diese: was genau passiert, wenn der Markt dir mehr Tisch anbietet und du beschließt, dir damit den zu sparen, der die Papiere auswählt.
Was zuerst bricht, ist nicht das Limit: es ist die Genauigkeit
Das Kontraintuitive daran ist, dass das Problem lange auftritt, bevor das Fenster voll ist. Ein Modell mit angekündigten einer Million Tokens hält seine Qualität nicht bis Token 999.999 und fällt dann von der Klippe: es verschlechtert sich allmählich, und ziemlich früh. Der NoLiMa-Benchmark hat das mit einem Aufbau gemessen, der die Abkürzung der früheren « Nadel im Heuhaufen »-Tests vermeidet — bei NoLiMa teilen Frage und relevanter Abschnitt fast keine Wörter, das Modell kann ihn also nicht über wörtliche Übereinstimmung finden und muss die Assoziation erschließen, genau das, was du im Produktivbetrieb von ihm verlangst.
Die Ergebnisse: GPT-4o startete bei 99,3 % mit kurzem Kontext und fiel auf 69,7 % bei 32K Tokens und auf 56 % bei 128K. Und es war kein Einzelfall: bei 32K fielen 11 der 13 geprüften Modelle auf die Hälfte oder weniger ihrer eigenen Kurzkontext-Basislinie. Quelle: NoLiMa: Long-Context Evaluation Beyond Literal Matching, Modarressi et al., arXiv, Februar 2025.
Dazu kommt ein früher und unabhängig dokumentierter Positionseffekt: die Genauigkeit hängt davon ab, wo die Information im Kontext steht. Die Arbeit, die den Begriff geprägt hat, beschreibt eine U-Kurve — das Modell holt sich einigermaßen gut, was am Anfang und am Ende steht, und scheitert an dem, was in der Mitte bleibt. Quelle: Lost in the Middle: How Language Models Use Long Contexts, Liu et al., Transactions of the ACL, 2024.
Zusammen beschreiben die beiden Effekte den echten Fehlermodus der « einfach alles reinwerfen »-Strategie. Es ist nicht so, dass das Modell die Antwort verweigert: es antwortet souverän mit dem, was es gefunden hat, und das ist nicht zwingend das, was zählte. Die Antwort kommt gut geschrieben, gut strukturiert und schlecht fundiert. Das ist die schlimmste Fehlerart für ein Unternehmenssystem, weil sie sich von einer richtigen Antwort nicht unterscheiden lässt, ohne sie von Hand zu prüfen.
| Was die Ankündigung sagt | Was der Benchmark misst | Was das für dein System bedeutet |
|---|---|---|
| « Fenster mit 1 Mio. Tokens » | Die Verschlechterung beginnt weit unter dieser Zahl | Das angekündigte Limit ist Eingabekapazität, keine Qualitätsgarantie |
| « Deine ganze Doku passt rein » | Bei 32K fallen 11 von 13 Modellen auf ≤50 % ihrer Basis (NoLiMa, 2025) | Hineinpassen ist nicht dasselbe wie genutzt werden |
| « Das Modell findet, was es braucht » | Was in der Kontextmitte steht, wird schlechter gefunden (Liu et al., 2024) | Die Reihenfolge, in der du Dokumente stapelst, wird zur versteckten Variable |
| « Du sparst dir das Retrieval » | Benchmarks messen weder die Rechnung noch die Nachvollziehbarkeit | Gesparte Entwicklung wird zu laufenden Kosten und Intransparenz |
Der Anbieter, der dir die Million Tokens verkauft, berechnet sie doppelt
Hier braucht es kein Argument: es genügt, die Preisliste dessen zu lesen, der das große Fenster verkauft. In der öffentlichen Preisliste der Gemini-API haben zwei Modelle ihren Preis nach Prompt-Länge geteilt, mit dem Schnitt bei genau 200.000 Tokens. Bei Gemini 3.1 Pro Preview, Standardtarif, steigt die Eingabe beim Überschreiten der Schwelle von 2,00 auf 4,00 Dollar pro Million Tokens und die Ausgabe von 12,00 auf 18,00. Bei Gemini 2.5 Pro von 1,25 auf 2,50 in der Eingabe und von 10,00 auf 15,00 in der Ausgabe. Das Kontext-Caching verdoppelt sich ebenfalls. Quelle: Gemini Developer API pricing, Google, abgerufen am 4. Oktober 2026.
Relevant ist nicht der Betrag, der sich ändern wird. Es ist die Form des Tarifs: der Anbieter, der dir das riesige Fenster anbietet, hat entschieden, dir das Doppelte zu berechnen, wenn du es wirklich nutzt. Das ist eine Aussage über die echten Kosten, solche Prompts zu bedienen, geschrieben von dem, der sie trägt. Wer dir « großes Kontextfenster oder RAG » so hinstellt, als wäre die erste Option die kostenlose, ignoriert, dass der Hersteller selbst sie als ein anderes und teureres Produkt bepreist hat.
Und der Zinseszinseffekt bringt Budgets durcheinander. Retrieval bündelt die Ausgabe im Aufbau und in der Pflege eines Index: Kosten, die einmal entstehen und sich über alle Abfragen amortisieren. Alles in den Prompt zu packen verschiebt diese Ausgabe auf die variable Seite, wo sie sich mit jedem Aufruf, jeden Tag, für immer multipliziert. Ein Pilot mit zweihundert Abfragen im Monat merkt es nicht. Dasselbe System, für dreihundert Leute geöffnet, schon. Die Rechnung ist langweilig, und deshalb macht sie niemand vor dem Meeting: multipliziere deine Eingabe-Tokens mit deinem erwarteten Volumen und vergleiche es mit dem, was ein Index kostet. Der Leitfaden dazu, welches Modell in einen Agenten gehört deckt die übrigen Achsen dieser Entscheidung ab, denn die Fenstergröße ist eine Spezifikation unter mehreren und fast nie die entscheidende.
Der Fehler, den du nicht debuggen kannst
Das ist das Argument, das in keinem Benchmark auftaucht und im Betrieb am teuersten ist. Mit Retrieval hast du bei einer falschen Antwort eine Spur: du weißt, welche Abschnitte geholt wurden, mit welcher Abfrage, mit welchem Score. Die Diagnose reduziert sich auf zwei beantwortbare Fragen — war der richtige Abschnitt im Index? hat das Retrieval ihn geliefert? — und jede zeigt auf eine andere Korrektur: die Quelle neu einlesen oder das Retrieval nachstellen.
Ohne Retrieval gibt es keine Spur, weil es keine Auswahl zu protokollieren gab. Du hast zweihunderttausend Tokens übergeben, und das Modell hat benutzt, was es benutzt hat. Du kannst nicht wissen, worauf es sich gestützt hat, du kannst den Weg nicht reproduzieren und du kannst es nicht mit einem umgrenzten Eingriff beheben: dein einziger Hebel ist, Dokumente umzusortieren und es nochmal zu versuchen — Debuggen aus Aberglaube. In einem internen System mit hoher Toleranz ist das lästig. In einem System, das Kunden antwortet oder eine Entscheidung speist, ist es der Unterschied zwischen einem Vorfall, der geschlossen wird, und einem, der offen bleibt.
Wann das große Fenster tatsächlich die richtige Antwort ist
Retrieval über einem Korpus zu bauen, der es nicht braucht, ist die andere Art, sich zu irren, und sie ist häufiger als es klingt. Drei Situationen, in denen das große Fenster klar gewinnt:
- Der Korpus ist klein und stabil. Wenn alles, was das System abfragen muss, bequem unter der Schwelle liegt, an der das Modell abbaut, und sich nicht jede Woche ändert, ist ein Index Infrastruktur, die du pflegst, ohne etwas zu gewinnen.
- Die Evidenz verteilt sich über das ganze Dokument. Wenn die Aufgabe ist, zu synthetisieren, Abschnitte zu vergleichen oder Widersprüche über einen langen Text hinweg zu finden, arbeitet Retrieval gegen dich: Zerstückeln ist genau das, was die Beziehung zwischen den Teilen zerstört. Hier ist langer Kontext kein Luxus, sondern die Anforderung.
- Es ist eine punktuelle Analyse, kein System. Ein Vertrag, ein Bericht, ein Datenexport, der einmal ausgewertet wird. Niemand sollte eine Ingestion-Pipeline für eine Frage bauen, die einmal gestellt wird.
Die ehrliche Lesart der neueren Literatur ist, dass die binäre Zuspitzung von beiden Seiten veraltet ist: langer Kontext liefert besser, wenn die Evidenz verteilt ist, und Retrieval liefert besser, wenn die Evidenz spärlich ist und gefunden werden muss. Die Architektur, die sich durchsetzt, wählt nicht: sie holt, um das Universum auf das Plausible einzuengen, und nutzt dann das lange Fenster, um über diese schon reduzierte Menge zu schließen. Retrieval ist dann kein chirurgischer Präzisionsfilter mehr, sondern ein Rauschfilter — was die Anforderungen an deinen Index deutlich entspannt.
Der Zwei-Minuten-Test, bevor du irgendetwas rauswirfst
Wenn jemand in deinem Team vorschlägt, das Retrieval zu entfernen, weil ein Modell mit mehr Kontext erschienen ist, klären diese vier Fragen das Gespräch ohne Folgetermin:
- Wie viele Tokens hat der komplette Korpus, heute und in zwölf Monaten? Wenn die Zwölf-Monats-Antwort die Schwelle überschreitet, an der das Modell abbaut — und die liegt weit unter dem angekündigten Limit —, ist das Fenster keine Lösung, sondern eine Verlängerung.
- Was würde das echte Abfragevolumen zum Langprompt-Tarif kosten? Mit dem Preisschnitt bei 200K Tokens passt die Rechnung auf ein Blatt. Rechne sie mit dem Volumen, das du anstrebst, nicht mit dem des Piloten.
- Steht die typische Evidenz an einer Stelle oder verteilt? Punktuell und lokalisiert: Retrieval. Über das Dokument verteilt: langer Kontext. Beides je nach Frage: hybrid, und das ist die häufigste Antwort.
- Was antwortest du, wenn ein Kunde fragt, woher dieser Satz kommt? Wenn die Antwort überprüfbar sein muss, brauchst du die Spur dessen, was hineinging. Die gibt nur die Auswahl.
Keine der vier wird von der Fenstergröße beantwortet, und genau das war zu zeigen.
Was das im Betrieb ändert
Es gibt einen weniger technischen Grund, warum der Vorschlag, das RAG wegzuwerfen, so gut ankommt, und man sollte ihn benennen: nicht das große Fenster ist besser, sondern einen Index zu pflegen ist laufende Arbeit, und niemand hat Lust darauf. Wissen altert, Quellen ändern sich, Dokumente werden ersetzt, und wenn niemand neu einliest und Veraltetes invalidiert, antwortet das System irgendwann mit der Version vom letzten Jahr. Das ist der echte Riss, den das Argument des unendlichen Kontexts ausnutzt: es verspricht, eine Betriebsfunktion loszuwerden, nicht eine Software.
Das Problem ist, dass die Funktion nicht verschwindet, sie wird nur unsichtbar. Wenn du die ganzen Dokumente in den Prompt packst, müssen diese Dokumente weiterhin die gültigen sein — nur hast du jetzt weder Index noch Pipeline, wo du es prüfen könntest. Deshalb ist die Aktualität der Wissensbasis eine laufende Funktion, die betrieben wird, und kein Projekt, das abgeschlossen wird: Refresh pro Quelle, Invalidierung des Veralteten und ein Verantwortlicher für jede redaktionelle Entscheidung existieren ohnehin, mit RAG oder ohne.
Und wenn die Debatte, die bei dir wirklich offen ist, nicht diese ist, sondern die andere — ob das Modell auf deinen Daten nachtrainiert werden soll —, ist sie woanders entschieden und mit derselben Logik: Retrieval schlägt Fine-Tuning fast immer, über die Kosten und über die Fähigkeit, ohne Nachtraining zu aktualisieren. Die drei Gespräche — Fenster, Retrieval und Training — vermischen sich in denselben Meetings, und es lohnt sich, sie getrennt zu halten, weil nur eines davon sich ändert, wenn ein neues Modell erscheint.
Das betriebliche Fazit ist kurz. Mehr Kontext ist eine gute Nachricht: er lässt dich mehr relevante Evidenz pro Aufruf übergeben und entspannt die Präzision, die du von deinem Retrieval verlangst. Was er nicht tut, ist zu entscheiden, was relevant ist. Diese Arbeit macht weiterhin jemand — ein Index, eine Abfrage, eine Richtlinie — oder niemand macht sie, und dann hast du keine einfachere Architektur: du hast dieselbe Komplexität, ohne Protokoll und zum doppelten Tarif.