Analyse: Lange Kontextfenster haben Retrieval nicht überflüssig gemacht – sie haben seine Aufgabe verändert
Kontextfenster mit einer Million Token machen es technisch möglich, einfach alles in den Prompt zu packen. Genauigkeit, Latenz und Kosten sprechen dagegen. Eine praktikable Entscheidungsregel dafür, wann man auf Retrieval setzt, wann man alles hineinstopft – und wann man beides kombiniert.
Kurze Antwort
Machen große Kontextfenster RAG überflüssig?
Nein, aber sie verändern dessen Aufgabe. Ein sehr großes Fenster vollständig zu befüllen, verschlechtert die Genauigkeit bei Informationen, die in der Mitte vergraben sind, vervielfacht Latenz und Kosten bei jeder Anfrage und erschwert es, die Quelle einer Antwort nachzuvollziehen. Retrieval bleibt die richtige Standardlösung für große oder sich ändernde Datenbestände, für alles, was Zitierfähigkeit oder Zugriffskontrolle erfordert, sowie für kostensensible Anwendungen mit hohem Volumen. Lange Kontextfenster eignen sich heute vor allem für das Verständnis ganzer Dokumente, als Arbeitsgedächtnis von Agenten innerhalb einer Aufgabe und als zweite Stufe, nachdem Retrieval die Auswahl bereits eingegrenzt hat.
Das Wichtigste
- Kontextkapazität ist nicht dasselbe wie Kontextnutzung. Modelle rufen Informationen vom Anfang und Ende eines langen Fensters zuverlässig ab, aus der Mitte hingegen deutlich weniger zuverlässig.
- Kosten und Latenz skalieren mit dem, was tatsächlich gesendet wird, nicht mit dem, was das Fenster erlauben würde. Ein Retrieval-Schritt, der 200.000 Token auf 4.000 reduziert, rechnet sich bei jeder einzelnen Anfrage.
- Retrieval bleibt relevant wegen dreier Eigenschaften, die ein langer Kontext nicht bieten kann: Zitierfähigkeit, Aktualität und nutzerspezifische Zugriffskontrolle.
- Die derzeit stärkste Architektur ist kein Entweder-oder. Erst durch Retrieval eingrenzen, dann dem Modell großzügigen Kontext über die eingegrenzte Auswahl geben.
- Wenn Antworten falsch sind, weil das richtige Dokument gar nicht erst abgerufen wurde, misst man mit einer Modellbewertung die falsche Komponente.
Jedes Mal, wenn ein Kontextfenster um eine Größenordnung wächst, macht dieselbe Behauptung die Runde: Retrieval sei nur ein Behelf für kleine Fenster gewesen; jetzt seien die Fenster groß, also habe sich Retrieval erledigt. Man solle die Dokumente einfach in den Prompt packen und das Modell den Rest erledigen lassen.
Die Behauptung ist nicht abwegig. Inzwischen ist es tatsächlich möglich, eine komplette Codebasis, die E-Mails eines ganzen Jahres oder einen Stapel Verträge in einer einzigen Anfrage unterzubringen. Dass die meisten Produktivsysteme weiterhin Retrieval einsetzen, liegt nicht an Trägheit. Der Grund ist, dass Kapazität und Nutzung zwei verschiedene Dinge sind und drei Eigenschaften von Retrieval überhaupt nichts mit der Größe des Kontextfensters zu tun haben.
Kapazität ist nicht gleich Nutzung
Ein Modell, das eine Million Token akzeptiert, nimmt auch eine Million Token entgegen. Ob es sie jedoch gleichmäßig nutzt, ist eine andere empirische Frage. Seit das Phänomen erstmals beschrieben wurde, fällt die Antwort stets gleich aus: Am Anfang und Ende einer langen Eingabe ist der Abruf am zuverlässigsten, in der Mitte am schwächsten.
Die praktische Folge ist unangenehm. An welcher Stelle ein Dokument im Prompt landet, beeinflusst, ob das Modell es berücksichtigt, unabhängig davon, wie relevant dieses Dokument ist. Ein System, das fünfzig Dokumente in beliebiger Reihenfolge aneinanderhängt, führt damit eine Qualitätsvariable ein, die niemand überwacht und die sich verschiebt, sobald sich die Reihenfolge der Verkettung ändert.
Als übliche Beruhigungspille dienen Ergebnisse aus sogenannten Needle-in-a-Haystack-Tests: Ein markanter Satz wird in einem großen Kontextfenster versteckt und zuverlässig wiedergefunden. Dieser Test ist wesentlich einfacher, als er aussieht. Eine einzelne ungewöhnliche Zeichenfolge zu finden, ist eine Aufgabe des lexikalischen Abgleichs. Reale Fragen erfordern dagegen, Informationen aus mehreren Passagen zusammenzuführen, Widersprüche zwischen zwei Stellen zu erkennen oder festzustellen, dass die Antwort fehlt. Benchmarks, die diese anspruchsvollere Aufgabenform prüfen, zeigen durchweg, dass der effektiv nutzbare Arbeitskontext weit unter der beworbenen Kapazität liegt.
Die Rechnung, die niemand aufmachen will
Kosten und Latenz richten sich danach, was Sie senden, nicht danach, was Sie senden dürfen.
Nehmen wir einen Support-Assistenten, der täglich zehntausend Fragen auf Grundlage einer Wissensdatenbank mit 200.000 Token bearbeitet. Wird die gesamte Datenbank in jede Anfrage gepackt, entstehen pro Tag zwei Milliarden Eingabe-Token. Bei jedem derzeitigen Preis für Spitzenmodelle ist das ein Budgetposten, der auffällt. Werden pro Frage viertausend relevante Token abgerufen, sind es vierzig Millionen – ein Unterschied um den Faktor fünfzig, bei jeder einzelnen Anfrage und auf Dauer.
Die Latenz folgt derselben Kurve. Die Zeit bis zum ersten Token steigt mit der Eingabelänge. Ein Support-Widget, bei dem die Antwort nach 900 Millisekunden erscheint, ist ein anderes Produkt als eines, das acht Sekunden braucht – unabhängig von der Qualität der Antwort.
Prompt-Caching verkompliziert die Rechnung auf eine Weise, die präzise benannt werden sollte, denn es ist das stärkste Argument für das vollständige Einspeisen. Ist ein großer Präfix bei vielen Anfragen identisch, kann Caching seine Kosten um ein Vielfaches senken und die Latenz deutlich verkürzen. Wenn Ihr Korpus tatsächlich gemeinsam genutzt wird und stabil bleibt – etwa ein unveränderliches Produkthandbuch oder ein fester Gesetzestext –, verändert das die Kalkulation und wird bislang zu selten genutzt. Caching bringt jedoch nichts, wenn sich die umfangreichen Inhalte je nach Nutzer oder Anfrage unterscheiden. Genau das ist bei den meisten Unternehmenseinsätzen der Fall, deren wesentlicher Zweck darin besteht, dass jeder Nutzer andere Dokumente sehen darf.
Die drei Eigenschaften von Retrieval, die Kontext nicht bietet
Dieser Teil des Arguments bleibt unverändert, wenn die Fenster größer werden.
Quellenzuordnung. Eine abgerufene Passage besitzt bereits eine Identität, bevor das Modell sie überhaupt sieht: eine Dokument-ID, eine URL, eine Seite, einen Revisionsstand. Zitiert das Modell die Passage, lässt sich der Beleg technisch überprüfen. Text, der lediglich in ein Kontextfenster eingefügt wird, besitzt keine solche Identität. Fordert man ein Modell auf, aus einer undifferenzierten Textmasse zu zitieren, entstehen Quellenangaben, die schwer zu überprüfen und leicht zu erfinden sind. Bei jeder Anwendung, in der eine falsche Antwort auf eine nachvollziehbare Quelle zurückgeführt werden muss – ob im Rechtswesen, in der Medizin, im Finanzbereich oder bei Compliance-Fragen –, entscheidet allein dieser Punkt über die Architektur.
Aktualität. Korpora verändern sich. Ein Retrieval-Index wird durch neue Einträge aktualisiert; ein vollständig bestückter Prompt muss dagegen neu aufgebaut und als gesamte Nutzlast erneut gesendet werden. Wenn sich Ihre Wissensdatenbank stündlich ändert, ist das eine Verfahren ein Hintergrundprozess, das andere eine Zusatzbelastung bei jeder Anfrage.
Zugriffskontrolle. Dieser Punkt entscheidet im Stillen über die meisten Unternehmensarchitekturen. Verschiedene Nutzer dürfen unterschiedliche Dokumente sehen. In einem Retrieval-System werden Berechtigungen zum Zeitpunkt der Abfrage als Filter angewandt, bevor irgendein Text das Modell erreicht – eine gewöhnliche, überprüfbare Autorisierungsgrenze. In einem System, das alles in den Prompt packt, muss die Berechtigungsentscheidung beim Zusammenstellen der Nutzlast fallen. Jeder Fehler führt dazu, dass sich das vertrauliche Dokument eines Nutzers im Prompt eines anderen befindet. Sobald es im Kontextfenster steht, kann keine nachgelagerte Kontrolle es wieder ungesehen machen.
Worin lange Kontexte tatsächlich besser sind
Der spiegelbildliche Irrtum besteht darin, daraus zu schließen, dass Retrieval immer gewinnt. Bei einer bestimmten und wachsenden Gruppe von Aufgaben sind große Kontextfenster eindeutig überlegen.
Analyse vollständiger Artefakte. Einen ganzen Vertrag zusammenfassen, einen Fehler durch eine gesamte Codebasis verfolgen oder zwei lange Dokumente Klausel für Klausel vergleichen: Die Aufteilung in Chunks zerstört aktiv die Struktur, auf die solche Aufgaben angewiesen sind. Geht es bei der Frage um die Gesamtgestalt eines Artefakts, liefert Retrieval nur Fragmente eines Gedankengangs, der unversehrt benötigt wird.
Arbeitsgedächtnis von Agenten. Ein Agent, der bereits vierzig Schritte einer Aufgabe durchlaufen hat, führt seine eigene Historie mit sich – Werkzeugausgaben, Zwischenschlüsse und gelesene Dateien. Dieser Kontext ist innerhalb der Sitzung entstanden und in keinem Retrieval-Index enthalten. Größere Fenster verlängern unmittelbar den Zeitraum, über den ein Agent arbeiten kann, bevor seine früheren Entscheidungen komprimiert werden müssen.
Seltene Lesevorgänge mit hoher Tragweite. Wenn eine Aufgabe nur einige Dutzend Mal am Tag ausgeführt wird und die Korrektheit wichtiger ist als die Kosten pro Aufruf, lohnt es sich, für die Einfachheit eines vollständig bestückten Prompts zu bezahlen. Nicht jedes System benötigt einen Index.
Die Architektur, die tatsächlich gewinnt
Als Entweder-oder-Frage formuliert, ist dies ein falscher Gegensatz. Das derzeit stärkste Muster nutzt beides nacheinander.
Breit abrufen, dann großzügig lesen. Nutzen Sie Retrieval, um einen großen Korpus auf eine Gruppe von Kandidaten einzugrenzen. Doch während ein älteres System vielleicht drei Chunks mit je 500 Token weitergereicht hätte, geben Sie nun zwanzig vollständige Dokumente weiter. Retrieval übernimmt die Aufgabe, für die es geeignet ist: die Auswahl unter Wahrung der Zugriffskontrolle und der Quellenzuordnung. Der lange Kontext übernimmt, was er besonders gut kann: Schlussfolgerungen aus Material zu ziehen, ohne es künstlich zu zerstückeln.
Damit wird eine Annahme umgekehrt, die in viel älterem RAG-Code fest verankert ist: Chunks müssten klein sein, weil Platz im Kontextfenster knapp sei. Dieser Platz ist nicht mehr knapp. Bilden Sie Chunks für die Qualität des Retrievals, nicht für das Budget des Kontextfensters – rufen Sie Inhalte in der Granularität ab, die einen präzisen Abgleich ermöglicht, und erweitern Sie anschließend jeden Treffer auf seinen vollständigen Abschnitt oder sein vollständiges Dokument, bevor er in den Prompt gelangt.
Zwei kleinere Praktiken sind wichtiger geworden. Ordnen Sie bewusst an: Angesichts des Positionseffekts sollten die am höchsten bewerteten Passagen an den Rändern des zusammengestellten Kontexts stehen und nicht in seiner Mitte. Und kennzeichnen Sie jede Passage im Prompt mit ihrer Quellen-ID, damit die Belegführung technisch überprüfbar bleibt und nicht vom guten Willen des Modells abhängt.
Die richtige Komponente bewerten
Eine diagnostische Gewohnheit verhindert hier den größten Teil der vergeudeten Arbeit: Wenn eine Antwort falsch ist, prüfen Sie, ob sich das erforderliche Dokument überhaupt im Kontext befand.
War es nicht enthalten, ist die Retrieval-Stufe gescheitert, und ein Modellwechsel wird daran nichts ändern. War es vorhanden und das Modell lag trotzdem falsch, handelt es sich um ein Generierungsproblem – erst dann werden die Größe des Kontextfensters, die Reihenfolge und die Struktur des Prompts relevant. Systeme, die ausschließlich die Gesamtqualität vom Anfang bis zum Ende messen, können diese Fälle nicht unterscheiden. Die verantwortlichen Teams verbringen daher oft Monate damit, Modelle auszutauschen, obwohl der Index defekt ist.
Kurz gesagt: Lange Kontexte haben die Beschränkung beseitigt, die Retrieval zwingend erforderlich machte, und alle anderen Gründe für Retrieval unverändert bestehen lassen. Die meisten Produktivsysteme werden weiterhin beides einsetzen. Die interessante Gestaltungsfrage lautet inzwischen nicht mehr, ob Inhalte abgerufen werden sollen, sondern wie viel davon dem Modell anschließend übergeben wird.
Häufige Fragen
- Was bedeutet „Lost in the Middle“?
- Das beobachtete Muster, dass Modelle Informationen am Anfang oder Ende einer langen Eingabe zuverlässiger abrufen als Informationen in der Mitte. Das heißt, die Position eines Dokuments im Prompt beeinflusst, ob das Modell es nutzt – unabhängig von dessen Relevanz.
- Reicht ein Needle-in-a-Haystack-Test aus, um einem langen Kontextfenster zu vertrauen?
- Nein. Einen einzelnen, unverwechselbar platzierten Satz zu finden, ist eine wesentlich leichtere Aufgabe als das Zusammenführen, Vergleichen oder logische Verknüpfen zahlreicher Passagen, die über dasselbe Fenster verstreut sind – genau das aber verlangen reale Fragen.
- Wann ist es richtig, das gesamte Dokument in den Kontext zu packen?
- Wenn der Bestand klein und stabil ist, wenn die Frage tatsächlich das gesamte Dokument erfordert und wenn das Volumen so gering ist, dass die Kosten pro Anfrage keine Rolle spielen. Vertragsprüfungen, die Analyse einer einzelnen Codebasis und einmalige Tiefenlektüren erfüllen diese Kriterien.
- Entkräftet Prompt-Caching das Kostenargument?
- Es senkt die Kosten erheblich, wenn ein stabiler Prefix über viele Anfragen hinweg wiederverwendet wird – eine reale und bislang zu wenig genutzte Optimierung. Es hilft jedoch nicht, wenn der große Inhaltsblock sich von Nutzer zu Nutzer oder von Anfrage zu Anfrage unterscheidet, und es löst weder das Genauigkeits- noch das Attributionsproblem.
- Wie funktionieren Zitate ohne Retrieval?
- Deutlich schlechter. Bittet man ein Modell, aus einer Masse unmarkierten Texts in seinem Kontextfenster zu zitieren, entstehen Verweise, die sich kaum maschinell überprüfen lassen. Retrieval gibt jeder Textpassage eine Identität, bevor das Modell sie überhaupt sieht – erst das macht ein Zitat nachprüfbar.