Braucht man RAG noch, wenn eine Million Token passt?

/01Begriff und Abgrenzung: RAG gegen Kontextfenster

RAG ist eine Architektur, kein Behelf: Vor der Antwort eines Sprachmodells durchsucht ein Retrieval-Schritt eine Dokumentensammlung, wandelt Text in Embeddings um, vergleicht sie in einer Vektordatenbank und legt nur die vermutlich passenden Ausschnitte in den Prompt. Das Modell sieht nie die ganze Sammlung, sondern eine Handvoll Textstellen, die ein Suchsystem vorher ausgewählt hat.

Long-Context-Modelle verfolgen den entgegengesetzten Ansatz: Statt vorzusortieren, bekommt das Modell möglichst viel auf einmal — bis zu einer Million Token bei Claude Sonnet 5, gegenüber 200.000 Token bei den Vorgängermodellen der Sonnet-Reihe. Die naheliegende Frage, die diesem Artikel den Titel gibt: Wenn ein einzelner Prompt mehrere tausend Seiten fasst, warum dann noch ein separates Suchsystem betreiben?

Die kurze Antwort: Kontextfenster und Retrieval lösen unterschiedliche Probleme. Ein großes Kontextfenster verschiebt, wie viel Text hineinpasst — nicht, wie zuverlässig das Modell mit vergrabenem Inhalt darin umgeht, was es kostet, das bei jeder Anfrage zu wiederholen, und ob sich die Antwort auf eine konkrete Fundstelle zurückführen lässt. Die folgenden Abschnitte gehen diese Fragen einzeln durch, bevor der Artikel zu dem kommt, was 2026 in der Praxis funktioniert.

/02Die Kostenrechnung: RAG gegen volles Kontextfenster

Bei Claude Sonnet 5 kostet eine Million Eingabe-Token 2 US-Dollar, unabhängig davon, ob der Prompt 9.000 oder 900.000 Token lang ist — laut Anthropic-Preisliste wird ein 900.000-Token-Kontext zum selben Satz pro Token abgerechnet wie ein kurzer. Das klingt nach einem Argument gegen RAG: kein Reranking-Modell, keine Vektordatenbank, einfach alles hineinkopieren. Die Rechnung geht trotzdem selten auf, sobald mehr als eine Handvoll Anfragen zusammenkommt.

Der Grund liegt nicht im Token-Preis, sondern in der Menge: Wer bei jeder Anfrage die komplette Dokumentensammlung erneut in den Prompt legt, zahlt die Verarbeitung dieser Sammlung bei jeder einzelnen Anfrage neu — Prompt-Caching senkt die Kosten für wiederholte Präfixe, ändert aber nichts daran, dass ein Sprachmodell für jedes verarbeitete Token Rechenzeit und Arbeitsspeicher braucht. Der KV-Cache wächst mit der Kontextlänge nahezu linear mit, und genau er bestimmt, wie viel Grafikspeicher eine Anfrage belegt und wie lange die erste Antwortsilbe auf sich warten lässt. Bei wenigen tausend Dokumenten mit häufig wechselnden Anfragen ist das ein Betriebsproblem, kein Rechenexempel auf dem Papier.

RAG verschiebt diesen Aufwand: Die teure Arbeit — Dokumente in Embeddings umwandeln, in einer Vektordatenbank indizieren — passiert einmal beim Einspielen, nicht bei jeder Anfrage. Was pro Anfrage übrig bleibt, ist eine Suche über den Index und ein kurzer Prompt aus den besten Treffern. Bei einer Kanzlei mit wenigen tausend Dokumenten und mehreren hundert Anfragen am Tag ist der Unterschied real messbar; bei einem Archiv, das dreimal im Monat durchsucht wird, lohnt sich der Aufbau eines Suchsystems dagegen kaum — dort ist ein großes Kontextfenster tatsächlich die einfachere und oft die günstigere Wahl.

/03Trefferqualität: was „Lost in the Middle" zeigt

Ein großes Kontextfenster garantiert nicht, dass das Modell alles darin gleich gut nutzt. Die vielzitierte Untersuchung „Lost in the Middle" von Liu et al. (2023) hat das an mehreren Sprachmodellen mit einer Aufgabe geprüft, die genau das misst: Ein Dokument mit der Antwort steckt zwischen mehreren Ablenkungsdokumenten, und die Position des richtigen Dokuments im Kontext wandert von Anfang bis Ende. Das Ergebnis ist eine U-Kurve: Modelle finden die Antwort am zuverlässigsten, wenn sie am Anfang oder Ende des Kontexts steht, und am unzuverlässigsten, wenn sie in der Mitte vergraben ist.

Im Experiment mit 20 Dokumenten fiel die Trefferquote von GPT-3.5-Turbo von 75,8 % bei einem Treffer am Anfang auf Werte im mittleren 50er-Prozentbereich, wenn der Treffer in der Mitte lag, und erholte sich zum Ende hin nur teilweise auf rund 63,2 %. Die Autoren beobachteten diesen Effekt ausdrücklich auch bei Modellen mit explizit langem Kontextfenster — ein größeres Fenster verschiebt also nicht automatisch, wie gleichmäßig ein Modell den Inhalt darin gewichtet.

Für die Praxis heißt das: Je mehr irrelevante oder nur am Rande passende Dokumente im Prompt landen, desto größer das Risiko, dass die eine relevante Stelle in der Mitte untergeht — genau das Szenario, das entsteht, wenn ganze Aktenordner statt vorsortierter Auszüge in den Kontext wandern. Ein Retrieval-Schritt, der vorher zehn statt zweihundert Kandidaten auswählt, verkleinert nicht nur den Prompt, er verschiebt die verbleibenden Treffer auch näher an die Ränder, wo Modelle sie zuverlässiger nutzen.

/04Aktualität und Nachvollziehbarkeit der Quelle

Ein Kontextfenster speichert nichts zwischen zwei Anfragen — jedes Mal, wenn sich ein Dokument ändert, muss die neue Fassung erneut in den Prompt. Bei einer Vertragsvorlage, die einmal im Quartal überarbeitet wird, ist das kein Problem. Bei einem Datenraum, in dem täglich neue Schriftsätze eingehen, oder einer Fertigungsdokumentation, die bei jeder Änderung an der Anlage nachgezogen wird, wird das Nachziehen zur Daueraufgabe — und zu der Stelle, an der vergessen wird, die alte Fassung aus dem Prompt zu entfernen. Ein Suchindex kennt dagegen nur den aktuellen Stand: Ein neu indiziertes Dokument ersetzt das alte, ohne dass jemand am Prompt selbst etwas ändern muss.

Der zweite Unterschied betrifft die Nachvollziehbarkeit. Wirft man zweihundert Seiten in ein Kontextfenster und lässt das Modell frei formulieren, lässt sich im Nachhinein kaum sagen, welcher Satz aus welcher Quelle stammt. Ein Retrieval-Schritt liefert dagegen einzelne, abgegrenzte Textausschnitte mit Herkunftsangabe — Dokumentname, Abschnitt, im Idealfall Seitenzahl. Für eine Kanzlei, die eine Aussage im Zweifel an der Originalstelle im Aktenordner belegen muss, oder einen Industriebetrieb, der eine Wartungsempfehlung auf ein bestimmtes Datenblatt zurückführen will, ist diese Rückverfolgbarkeit kein Komfortmerkmal, sondern die Voraussetzung dafür, die Antwort überhaupt zu verwenden.

/05Datenschutz: was on-premise laufen muss

Sobald Dokumente personenbezogene Daten enthalten — Mandantenkorrespondenz, Personalakten, Kundendatensätze in der Fertigungsdokumentation —, greift die DSGVO bei jedem Schritt, der diese Daten verarbeitet, nicht nur bei der finalen Antwort. Das betrifft auch das Embedding-Modell: Es liest den vollständigen Dokumenteninhalt, um daraus einen Vektor zu berechnen, und wenn dieser Schritt über eine externe API läuft, verlassen die Rohdaten damit das eigene Haus — unabhängig davon, ob am Ende nur ein kurzer Ausschnitt beim Sprachmodell landet.

Die ehrliche Aufteilung: Embedding-Modell, Vektordatenbank und Reranking-Modell gehören in den eigenen Betrieb — On-Premise heißt hier, dass diese drei Bausteine, die den vollständigen Text sehen, das Haus nicht verlassen. Das Sprachmodell für die finale Antwort kann dagegen über eine API laufen, wenn ausschließlich die wenigen bereits ausgewählten und geprüften Textausschnitte hinausgehen, nicht die gesamte Sammlung. Wo genau diese Grenze gezogen wird, ist eine Entscheidung, die zum Auftragsverarbeitungsvertrag und zur Risikobewertung passen muss — HostSpezial betreibt den eigenen Bestand seit 2010 aus dem Rechenzentrum Coburg mit Ausweichstandort Neustadt und ist nach ISO/IEC 27001:2024 zertifiziert (Zertifikat 202787), was diese Entscheidung erleichtert, aber nicht ersetzt.

Ein zweiter, oft übersehener Punkt: Ein Retrieval-System, das Dokumente unautorisiert einliest oder dessen Suchindex nicht dieselben Zugriffsrechte durchsetzt wie das Quellsystem, liefert einem Nutzer im Zweifel Inhalte, auf die er gar keinen Zugriff haben sollte — eine Prompt-Injection-Lücke entsteht zusätzlich dort, wo ein Dokument selbst Anweisungen enthält, die ein nachgeschaltetes Modell unbeabsichtigt befolgt. Beides gehört in dieselbe Prüfung wie die Frage, wo die Modelle laufen.

Eine ausführliche Einordnung von DSGVO-Anforderungen an KI-Systeme insgesamt — Auftragsverarbeitung, Löschfristen, Betroffenenrechte — liefert der Artikel KI On-Premise: DSGVO-konforme KI-Lösungen; dieser Abschnitt beschränkt sich auf die Besonderheiten von Retrieval-Architekturen.

/06Hybrid-Suche: Stichwort- und Vektortreffer kombinieren

Reine Vektorsuche hat eine bekannte Schwäche: Sie findet Bedeutungsähnlichkeit gut, versagt aber bei exakten Begriffen — einer Aktenzeichennummer, einer Normbezeichnung, einem Produktcode. Ein Embedding-Modell bildet solche Zeichenketten selten trennscharf ab, weil es auf Bedeutung trainiert ist, nicht auf exakte Übereinstimmung. Stichwortsuche nach dem klassischen BM25-Verfahren kann genau das umgekehrt: Sie findet die exakte Zeichenkette zuverlässig, versteht aber keine Umschreibung oder Synonyme. Hybrid-Suche führt beide Wege parallel aus und kombiniert die Ergebnislisten.

Qdrant löst die Kombination über seine Query API: Eine Anfrage kann mehrere prefetch-Suchen — eine über dichte, eine über spärliche Vektoren — parallel ausführen und die Ergebnislisten anschließend fusionieren. Der Standardweg dafür ist Reciprocal Rank Fusion: Jedes Dokument bekommt für jede Ergebnisliste, in der es auftaucht, einen Punktwert nach der Formel 1 ÷ (k + Rang), addiert über alle Listen; die Konstante k liegt in Qdrants Voreinstellung bei 2. Entscheidend an diesem Verfahren ist, dass es nur die Platzierung zählt, nicht die absolute Punktzahl der beiden sehr unterschiedlichen Suchverfahren — ein Vektor-Ähnlichkeitswert und ein BM25-Score sind schlicht nicht auf derselben Skala vergleichbar.

POST /collections/kb/points/query
{
  "prefetch": [
    { "query": [0.02, -0.31, "..."], "using": "dense",  "limit": 20 },
    { "query": { "indices": [12, 88, 401], "values": [0.4, 0.9, 0.2] },
      "using": "sparse", "limit": 20 }
  ],
  "query": { "fusion": "rrf" },
  "limit": 10
}

Weaviate geht einen ähnlichen Weg mit eigenem Vokabular: Der Parameter alpha gewichtet zwischen reiner Stichwortsuche (0) und reiner Vektorsuche (1), und seit Version 1.24 fusioniert die Engine standardmäßig über die tatsächlichen Ähnlichkeitswerte beider Suchen (Relative Score Fusion) statt nur über Ränge. Für den laufenden Betrieb heißt das: Die Wahl des Fusionsverfahrens ist kein Implementierungsdetail, das sich später unauffällig nachziehen lässt, sondern beeinflusst direkt, welche Dokumente vorne landen — sie gehört in die Testphase, nicht in die Nacharbeit.

/07Reranking und saubere Dokumentenzerlegung

Hybrid-Suche liefert typischerweise zwanzig bis fünfzig Kandidaten — mehr, als in den Prompt passen sollten, und in einer Reihenfolge, die aus zwei technisch unterschiedlichen Bewertungen zusammengerechnet ist. Ein Reranking-Modell bewertet diese Kandidaten anschließend neu, aber anders als die erste Suche: Es liest Anfrage und Dokument gemeinsam statt getrennt und gibt einen einzelnen Relevanzwert aus, keine Vektordarstellung. Das ist rechenintensiver pro Dokument, aber weil nur die Kandidaten aus dem ersten Schritt neu bewertet werden — nicht die gesamte Sammlung —, bleibt der Mehraufwand begrenzt.

Zwei Modelle stehen für den Eigenbetrieb zur Verfügung: BGE Reranker v2-m3 von BAAI kommt mit 0,6 Milliarden Parametern aus, ist mehrsprachig trainiert und lässt sich auf einer einzelnen GPU betreiben, laut Modellkarte auch mit Quantisierung auf kleinerer Hardware. Jina Reranker verfolgt einen ähnlichen Ansatz mit eigenem Trainingskorpus. Wer keinen eigenen Betrieb will, bekommt mit Cohere Rerank (aktuell Version 4.0) einen Dienst über API — dort zählt eine Anfrage mit bis zu 100 zu bewertenden Dokumenten als eine Abrechnungseinheit, längere Dokumente werden ab 500 Token in mehrere Teile gesplittet.

Der Punkt, den die Redaktion nach eigener Erfahrung am häufigsten unterschätzt sieht, liegt vor dem Reranking-Modell, nicht darin: die Dokumentenzerlegung. Ein Vertrag, der an einer Absatzgrenze mitten im Satz zerschnitten wird, ein Datenblatt, dessen Tabellenüberschrift im vorherigen Abschnitt hängen bleibt, eine Klausel ohne den Paragrafentitel darüber — jeder dieser Fehler produziert einen Textausschnitt, der weder das Retrieval noch das Reranking-Modell richtig einordnen kann, weil ihm der Kontext fehlt, der eigentlich dazugehört. In der Praxis bringt eine Woche Arbeit an der Zerlegung — Chunks an Absatz- statt Zeichengrenzen schneiden, Überschriften und Paragrafenbezug in jeden Chunk hinein wiederholen, Tabellen als Ganzes belassen — häufiger einen Qualitätssprung als der Wechsel des Reranking-Modells. Ob das tatsächlich stimmt, prüft sich nicht am Bauchgefühl: Eine kleine Eval-Harness aus zwanzig bis fünfzig echten Fragen mit bekannter richtiger Fundstelle zeigt in Recall@5 oder Recall@10 schnell, ob eine Änderung an Zerlegung, Suche oder Reranking tatsächlich etwas bringt.

/08Graph-RAG: wann sich der Zusatzaufwand lohnt

Hybrid-Suche und Reranking finden gute Antworten auf Fragen, die sich an einem oder wenigen Dokumenten festmachen lassen. Sie stoßen an eine Grenze, sobald die Antwort erst aus der Beziehung zwischen mehreren Dokumenten entsteht — „Welche Lieferanten hängen an der Anlage, die im Vorfall vom März betroffen war?" lässt sich nicht durch Ähnlichkeit zu einem Textausschnitt beantworten, sondern nur durch das Nachverfolgen einer Kette von Bezügen. Graph-RAG begegnet dem, indem es zusätzlich zum Suchindex einen Wissensgraphen aus Entitäten und Beziehungen aufbaut — Anlage, Lieferant, Vorfall, Vertrag — und die Suche darüber ergänzt, statt sie zu ersetzen.

Der Preis dafür ist real: Ein Graph muss aus den Dokumenten extrahiert werden, üblicherweise mit demselben Sprachmodell, das später auch antwortet, und diese Extraktion braucht Pflege, wenn sich Dokumente ändern oder falsch erkannte Beziehungen auffallen. Für eine Kanzlei mit klar abgegrenzten Mandaten oder einen Industriebetrieb, dessen Fragen sich meist auf ein Datenblatt oder eine Anleitung beziehen, ist dieser Zusatzaufwand selten gerechtfertigt — Hybrid-Suche mit Reranking deckt den überwiegenden Teil der Fragen ab. Graph-RAG lohnt sich dort, wo Beziehungen zwischen vielen Entitäten regelmäßig die eigentliche Frage sind: Lieferketten, Zulassungsketten, Organisationsstrukturen mit häufigem Wechsel.

Ehrlich: Der häufigste Fehler ist an dieser Stelle nicht die falsche Entscheidung zwischen RAG und langem Kontextfenster, sondern eine schlecht vorbereitete Dokumentensammlung, die beide Ansätze gleichermaßen ausbremst. Bevor ein Graph aufgebaut, ein zweites Modell für Reranking beschafft oder ein Kontextfenster mit einer Million Token gebucht wird, lohnt sich die Frage, ob die vorhandenen Dokumente überhaupt sauber genug zerlegt sind, um von irgendeinem der drei Ansätze profitieren zu können.

/09Referenzaufbau für Kanzlei und Industriebetrieb

Für einen typischen Mittelstandskunden mit wenigen tausend Dokumenten — eine Kanzlei mit Aktenbestand, ein Industriebetrieb mit Datenblättern, Wartungsprotokollen und Konstruktionsunterlagen — sieht ein tragfähiger Aufbau in der Praxis so aus: eine Vektordatenbank mit Hybrid-Suche als Fundament, ein Reranking-Modell zur Rangkorrektur der obersten Kandidaten, ein sauber gepflegter Zerlegungsprozess, der Dokumentenstruktur statt fester Zeichenzahl als Schnittgrenze nutzt, und ein Sprachmodell, das aus den zehn bis zwanzig besten Treffern die eigentliche Antwort formuliert. Graph-RAG kommt nur dazu, wenn die Fragen tatsächlich beziehungsgetrieben sind.

Die Aufteilung zwischen eigenem Haus und externer API folgt der Regel aus Abschnitt fünf: Embedding-Modell, Vektordatenbank und Reranking-Modell laufen im eigenen Haus, sobald die Dokumente selbst das Haus nicht verlassen dürfen. Für den Eigenbetrieb dieser drei Bausteine hat sich vLLM als Serving-Engine für Open-Weight Modelle etabliert — sie hält mehrere Anfragen parallel im Speicher und lässt sich, wie beim Reranking-Modell in Abschnitt sieben beschrieben, mit Quantisierung auf eine einzelne GPU begrenzen, statt einen ganzen Rechnerverbund zu binden. Wie sich ein solcher Aufbau mit aktuellen offenen Modellen konkret bestückt, beschreibt der Artikel Qwen3.8 ist Open Weight im Detail.

Wird die Suche später als Werkzeug in einen Agenten eingebunden — etwa über MCP, damit ein Assistent selbstständig entscheidet, wann er nachschlägt —, gilt dieselbe Zugriffskontrolle wie für die Suche selbst: Ein Werkzeug, das mehr Dokumente zurückgeben kann, als der anfragende Nutzer einsehen dürfte, ist ein Datenschutzproblem, unabhängig davon, wie gut das Reranking dahinter funktioniert.

/10Häufige Fragen