26.02.2024 AI Engineering 5 Minuten Lesezeit

Gemini 1.5 Pro: Macht eine Million Token Kontext RAG überflüssig?

Googles Gemini 1.5 Pro verarbeitet bis zu einer Million Token Kontext. Macht das Retrieval-Augmented Generation überflüssig? Wir rechnen nach: Kosten pro Anfrage, Latenz, Multi-Needle-Recall, Aktualität und Zugriffskontrolle. Das Fazit vom Februar 2024: Langer Kontext verändert den Bau von Retrieval-Pipelines — er ersetzt sie nicht.

Eine Million Token verändern die Frage

Im Februar 2024 hat Google Gemini 1.5 Pro vorgestellt. Die zentrale Zahl ist das Kontextfenster: bis zu 1 Million Token in einer Private Preview — genug für rund 700.000 Wörter, eine Stunde Video oder mehr als 30.000 Zeilen Code. Das größte bisher verfügbare Fenster bot Claude 2.1 mit 200.000 Token. Die Reaktion in vielen Engineering-Diskussionen kam prompt: Wenn das Modell den gesamten Korpus lesen kann, wozu dann noch eine Retrieval-Pipeline?

Diese Frage verdient Arithmetik, keine Stimmung. Wir bei Blue IT Systems bauen Retrieval-Augmented-Systeme für den Produktionsbetrieb. Unsere Antwort mit Stand Februar 2024: Langer Kontext verändert, wie wir retrieven. Er beseitigt nicht die Gründe, warum wir retrieven. Dieser Artikel benennt diese Gründe mit Zahlen.

Eine Anfrage kommt an — der Router stuft die Schwierigkeit ein. 1/4

Was Gemini 1.5 Pro tatsächlich liefert

Gemini 1.5 Pro ist ein mittelgroßes Mixture-of-Experts-Modell. Google gibt an, dass es die Qualität von Gemini 1.0 Ultra mit weniger Trainingsrechenleistung erreicht. Das Standard-Kontextfenster beträgt 128.000 Token. Das Fenster mit 1 Million Token ist ein experimentelles Feature, verfügbar in einer Private Preview über AI Studio und Vertex AI. In interner Forschung berichtet Google von erfolgreichen Tests bis 10 Millionen Token.

Zwei Vorbehalte stehen in der Ankündigung selbst. Erstens der Preis: Preisstufen vom Standardfenster mit 128.000 Token bis hinauf zu 1 Million Token sind angekündigt, aber nicht beziffert. Zweitens die Latenz: Google weist frühe Tester ausdrücklich auf längere Antwortzeiten hin und nennt das volle Fenster rechenintensiv. Beide Vorbehalte entscheiden die RAG-Frage — wir nehmen sie deshalb ernst.

Needle-Tests sind keine Produktionslasten

Der Technical Report zeigt nahezu perfekten Single-Needle-Recall: 100 % bis 530.000 Token, über 99,7 % bei 1 Million, 99,2 % bei 10 Millionen. Das ist ein echtes Ergebnis. Der Lost-in-the-Middle-Effekt, den Liu et al. im Juli 2023 dokumentierten — sinkende Genauigkeit, wenn relevanter Text in der Mitte des Kontexts steht —, tritt in diesem Test nicht auf.

Ein Needle-Test fragt aber nach einem einzelnen platzierten Fakt. Derselbe Report platziert auch 100 Needles in einem Kontext: Der Recall fällt auf rund 70 % bei 128.000 Token und über 60 % bei 1 Million. GPT-4 Turbo erreicht an seiner 128.000-Token-Grenze im Mittel etwa 50 %. Reale Anfragen — "listen Sie jede Haftungsklausel in diesen Verträgen auf" — sind Multi-Needle-Aggregation, kein Einzelfakt-Lookup. Ein System mit 60 % Recall liefern Sie nicht unbeaufsichtigt aus.

Die Kostenrechnung spricht für Retrieval

Für Gemini 1.5 Pro existiert kein veröffentlichter Preis. Wir rechnen deshalb mit der nächstliegenden bepreisten Referenz: GPT-4 Turbo, angekündigt am 6. November 2023, zu 0,01 $ pro 1.000 Input-Token — 10 $ pro Million. Angenommen wird eine Wissensbasis von 700.000 Wörtern, rund 1 Million Token, mit 1.000 Fragen pro Tag.

Das Token-Volumen unterscheidet sich um den Faktor 200. Keine plausible Preisdifferenz zwischen Modellen schließt diese Lücke. Kosteten Long-Context-Token fünfmal weniger, läge der Full-Context-Ansatz immer noch bei 2.000 $ pro Tag gegenüber 50 $ mit Retrieval. Wer den gesamten Korpus mit jeder Anfrage sendet, bezahlt dieselbe Lektüre immer wieder. Retrieval bezahlt einmal pro Index-Aktualisierung.

Ansatz	Input-Token pro Anfrage	Kosten pro Anfrage	Kosten pro Tag (1.000 Anfragen)
Gesamter Korpus im Kontext	ca. 1.000.000	ca. 10,00 $	ca. 10.000 $
Retrieval (Top-k-Chunks)	ca. 5.000	ca. 0,05 $	ca. 50 $

Latenz ist eine Produktgrenze

Die Rechenkosten der Attention wachsen mit der Eingabelänge, und Google sagt das offen: Frühe Tester des 1-Million-Token-Fensters müssen mit längeren Antwortzeiten rechnen; Optimierungen laufen. Interaktive Produkte haben Latenzbudgets von wenigen Sekunden. Ein Assistent, der vor jeder Antwort das komplette Handbuch neu liest, kann korrekt und trotzdem unbenutzbar sein.

Latenz summiert sich außerdem. Agentenartige Systeme setzen mehrere Modellaufrufe pro Nutzeraufgabe ab. Fünf Long-Context-Aufrufe in Folge machen aus Sekunden Minuten. Retrieval hält jeden Aufruf klein, jeden Schritt schnell und das Gesamtbudget planbar. Für Batch-Workloads — ein Vertrag, eine Codebasis, ein Video — sind Dutzende Sekunden akzeptabel. Genau dort passt das 1-Million-Token-Fenster heute hin.

Was Retrieval kann und Kontext nicht

Vier Eigenschaften von Retrieval liegen außerhalb jedes Kontextfensters. Aktualität: Ein Index wird inkrementell aktualisiert und spiegelt eine Dokumentänderung binnen Minuten wider; ein befüllter Prompt ist ein Schnappschuss, der pro Anfrage neu gebaut werden muss. Zugriffskontrolle: Unterschiedliche Nutzer dürfen unterschiedliche Dokumente sehen; ein Retrieval-Filter setzt Berechtigungen pro Anfrage durch, ein geteilter Mega-Prompt kann das nicht.

Nachvollziehbarkeit: Abgerufene Chunks tragen Dokumentidentität und Position — das ermöglicht Zitate und Audits; eine Antwort, destilliert aus einer Million undifferenzierter Token, tut das nicht. Größe: 1 Million Token sind rund 1.500 Seiten. Korpora, die wir in der Praxis sehen, sind Gigabytes — tausendfach größer als das Fenster. Dort ist Retrieval keine Optimierung, sondern der einzige Zugang.

Langer Kontext und Retrieval kombiniert

Langer Kontext ersetzt Retrieval nicht. Er lockert dessen engste Beschränkungen. Mit 100.000 oder mehr Token Spielraum wird Chunking grob: ganze Abschnitte oder ganze Dokumente statt 300-Token-Fragmente. Ranking-Fehler kosten weniger, weil mehr Kandidaten hineinpassen. Die Empfindlichkeit gegenüber Chunk-Grenzen und der Position eines Fakts im Prompt sinkt — die Needle-Ergebnisse stützen das.

Die Architektur, die sich aus unserer Sicht durchsetzen wird: Retrieval als grober Filter, der den relevanten Bruchteil eines Korpus auswählt; das Long-Context-Modell als gründlicher Leser dieses Bruchteils. Günstig, wo das Volumen liegt, sorgfältig, wo das Schlussfolgern liegt. Das ist ein einfacheres und besseres RAG — nicht das Ende von RAG.

Ausblick aus dem Februar 2024

Unsere Prognosen vom Februar 2024, so formuliert, dass Sie sie später prüfen können. Kontextfenster wachsen weiter; das 10-Millionen-Token-Forschungsergebnis erreicht innerhalb von zwei Jahren die Produktion. Token-Preise fallen, aber Anfragevolumina steigen mit der Verbreitung — die Kostenasymmetrie zwischen Full Context und Retrieval bleibt. Anbieter werden einen Mechanismus liefern, der wiederholten Kontext amortisiert — eine Form von Prefix- oder Prompt-Caching —, weil die Ökonomie ihn erzwingt.

RAG stirbt 2024 nicht. Es wird einfacher: weniger Chunking-Heuristiken, weniger aggressives Reranking, mehr Vertrauen darauf, dass das Modell liest, was Retrieval ihm reicht. Die Engineering-Frage verschiebt sich von "Wie pressen wir einen Korpus in 4.000 Token?" zu "Welche 100.000 Token verdienen die Aufmerksamkeit des Modells?". Das halten wir für Fortschritt.