Warum RAG wichtiger ist als langer Kontext: Wirtschaft, Sicherheit und hybride Architektur

Im Jahr 2026 sind Kontextfenster von 1–2 Millionen Tokens zur Norm geworden – Claude Sonnet hat bereits 1 Million, Gemini 3 ebenfalls 1 Million, und das neueste Gemini 3.1 Ultra hat bereits 2 Millionen erreicht. Llama 4 Scout beansprucht sogar 10 Millionen. Die logische Schlussfolgerung, zu der viele Teams kommen: Warum einen RAG-Pipeline mit Chunking, Vektordatenbank und Re-Ranker aufbauen, wenn man die gesamte Wissensdatenbank einfach in den Prompt laden kann?

Wenn Sie noch nicht ganz verstanden haben, wie sich RAG von einem gewöhnlichen LLM unterscheidet – beginnen Sie mit dem Artikel LLM vs RAG: Was ist der Unterschied und was soll man wählen, er liefert die Grundlagen, die hier als bekannt gelten. Dieser Artikel ist für diejenigen, die bereits verstehen, was RAG ist, und herausfinden möchten, ob es in Zeiten von Millionen-Token-Kontextfenstern noch benötigt wird.

Das ist eine Falle. Die Kontextgröße ist keine kostenlose Magie. In diesem Artikel erfahren Sie, warum das architektonisch "dumme" Einwerfen von Daten die Projektökonomie ruiniert, warum dies eine Sicherheitsfrage und nicht nur eine Qualitätsfrage ist und wie die Architektur des Jahres 2026 tatsächlich aussieht. Beispiele stammen aus dem realen RAG-Service AskYourDocs.

Der Mythos von "allfressenden" Modellen

Als Anthropic 1 Million Token Kontext für Claude Sonnet ankündigte, machte ich mir einen Tee und stellte mir ernsthaft die Frage: Lohnt es sich überhaupt, die RAG-Pipeline in AskYourDocs weiter zu betreiben? Ich rechnete grob: Ein typischer Unternehmenskunde lädt 200–400 Dokumente hoch – das sind etwa 600–800 Tausend Tokens. Theoretisch passt das alles in ein Fenster. Die Versuchung war nicht abstrakt, sondern sehr konkret: Chunking, Vektordatenbank, Re-Ranker wegwerfen – und alles mit einer einzigen Anfrage hochladen.

Die öffentliche Diskussion zu diesem Thema sah ich gespalten in zwei Extreme, und keines davon entsprach dem, was ich in meinem eigenen Projekt sah. Das erste ist das Marketing der Anbieter, das ich in Modellankündigungen und auf technischen Konferenzen las: "Langer Kontext ersetzt RAG, laden Sie einfach alles in den Prompt, und die Komplexität verschwindet von selbst." Das zweite ist die veraltete Materie von 2024, die ich selbst in meinen ersten Artikeln auf WebsCraft schrieb: Der Wert von RAG wurde ausschließlich als Möglichkeit erklärt, das 4–8K Token-Limit zu umgehen. Aber dieses Limit gibt es schon seit ein oder zwei Jahren nicht mehr, und in meinem eigenen Projekt ist RAG nicht verschwunden und sollte auch nicht verschwinden – nur der Grund für seine Existenz hat sich geändert.

Warum die alte Argumentation nicht mehr funktioniert: Als der Kontext klein war, war RAG die einzige technische Möglichkeit, dem Modell Zugang zu externem Wissen zu verschaffen – ohne ihn hätte das Modell die Dokumente des Kunden einfach nicht gesehen. Jetzt ist der Kontext groß, und die Frage hat sich von "passt das Dokument hinein" zu "sollte es überhaupt hineingeladen werden" verschoben. Ich habe mich davon durch eigene Berechnungen überzeugt: Als ich die tatsächlichen Kosten für das Laden der gesamten Kundendatenbank in jede Anfrage berechnete (dies ist weiter unten im Abschnitt über Ökonomie), wurde klar, dass die Frage nicht mehr technisch, sondern rein ökonomisch, geschwindigkeitsbezogen und – was sich für B2B als am wichtigsten herausstellte – eine Frage der Sicherheit des Datenzugangs verschiedener Kunden ist.

Kurz gesagt: Nur weil ein Modell technisch in der Lage ist, 1 MB Dokument auf einmal zu verdauen, bedeutet das nicht, dass es architektonisch die richtige Entscheidung für ein Produktionssystem mit Tausenden von Anfragen pro Monat ist. Möglichkeit und Zweckmäßigkeit sind zwei verschiedene Dinge, und genau diesen Unterschied habe ich nicht sofort verstanden, bis ich die Zahlen berechnet hatte.

Inferenzökonomie: Die Token-Falle (The Token Trap)

Stellen wir uns eine Unternehmenswissensdatenbank von 5 MB vor – etwa 1 Million Tokens. Vergleichen wir zwei Ansätze anhand der realen Preise von Claude Sonnet 4.6 im Juni 2026: 3 US-Dollar pro Million Eingabe-Tokens.

Warum der Unterschied genau so groß ist: Die Kosten für LLM-Inferenz hängen linear von der Anzahl der Eingabe-Tokens ab. Wenn Sie das gesamte Archiv auf einmal laden, zahlt das Modell für das Lesen des gesamten Arrays bei jeder – selbst der einfachsten – Anfrage. RAG zahlt nur für die 3000 Tokens, die tatsächlich zur Frage gehören. Der Unterschied von 333 Mal ist keine Optimierung, sondern ein anderes Wirtschaftsmodell.

Selbst unter Berücksichtigung von Context Caching-Technologien, die die Kosten für das wiederholte Lesen von Prompts senken, bleiben Sie an einen statischen Daten-Snapshot gebunden. Sobald die Wissensdatenbank aktualisiert wird oder jeder Benutzer seinen eigenen eindeutigen Satz von Dokumenten erhält – wird der Cache ungültig, und die Ökonomie bricht wieder zusammen. Für AskYourDocs ist dies kein theoretischer Fall: Jeder Kunde hat seine eigenen Dokumente, und deshalb kann ein statischer Cache hier nicht helfen.

Dazu kommen die Kosten für den Abruf selbst: Einbettungen über text-embedding-3-small kosten 0,02 US-Dollar pro Million Tokens – das bedeutet, die Suche in der Vektordatenbank ist praktisch kostenlos im Vergleich zur Generierung. Selbst unter Berücksichtigung der Kosten für die Infrastrukturwartung (z. B. RAM für pgvector-Indizes in PostgreSQL) sind diese Kosten fix (Flat Rate) und steigen nicht exponentiell mit jeder neuen Benutzeranfrage – im Gegensatz zu den Tokens, die Sie bei der "Alles in den Kontext laden"-Methode immer wieder für jede Anfrage bezahlen.

Praktisches Fazit: Wenn Ihr Produkt mehr als ein paar hundert Anfragen pro Monat an eine große Wissensdatenbank verarbeitet – das Laden von allem in den Kontext skaliert finanziell nicht, selbst mit Caching. Der Punkt, an dem RAG obligatorisch wird, tritt viel früher ein, als man denkt.

Beispiel von AskYourDocs: In der Produktion verwenden wir openai/text-embedding-3-small (1536 Dimensionen) für Einbettungen und meta-llama/llama-3.3-70b-instruct über OpenRouter für die Antwortgenerierung. Das Einbetten der gesamten Kundendatenbank kostet einmalig ein paar Cent; wir zahlen im Wesentlichen nur für die endgültige Generierung – und genau deshalb macht die RAG-Architektur die Kosten unabhängig von der Größe der Kundendatenbank vorhersagbar.

Warum langer Kontext teurer ist, als es scheint

Die direkten Kosten für Tokens sind nur die halbe Geschichte. Die andere Hälfte ist die Aufmerksamkeitsmechanik (attention) im Transformer, und genau das macht mir am meisten Angst, wenn ich an das Szenario "einfach alles in den Kontext laden" für AskYourDocs denke.

Vereinfacht gesagt: Um eine Antwort zu generieren, muss das Modell jedes Token des Kontexts mit jedem anderen Token vergleichen – das ist Attention. Wenn im Kontext 1000 Tokens sind, sind das ungefähr 1000×1000 = 1 Million Vergleichsoperationen. Wenn sich der Kontext auf 2000 Tokens verdoppelt, sind es nicht doppelt so viele Operationen, sondern 2000×2000 = 4 Millionen. Das nennt man quadratische Skalierung: Der Attention-Mechanismus skaliert quadratisch mit der Kontextlänge – eine Verdoppelung des Kontexts erhöht die Rechenkosten um das Vierfache, nicht um das Doppelte.

Warum dies keine abstrakte Mathematik ist, sondern ein reales Problem für die Benutzererfahrung: Die Zunahme des Kontexts beeinflusst nicht nur die Kosten, sondern auch die Latenz. TTFT (Time to First Token) – die Zeit bis zum Erscheinen des ersten Antwort-Tokens – verschlechtert sich nichtlinear mit der Zunahme des Prompts. Konkrete Zahlen aus einem akademischen Benchmark auf einer Infrastruktur mit 16 Knoten und 128 H100 GPUs: Der Prefill für 128K Kontext-Tokens dauert 3,8 Sekunden, und für 1 Mio. Tokens – bereits 77 Sekunden. Das ist keine lineare Zunahme um das 8-fache, sondern fast das 20-fache – und das auf einer Top-Infrastruktur, die speziell optimiert ist. Auf einem einzigen normalen GPU-Host zeigt dieselbe Studie, dass selbst 128K Kontext bis zu 60 Sekunden dauern kann.

Warum das für ein Produkt entscheidend ist: Stellen Sie sich einen Chatbot oder Sprachassistenten vor, bei dem der Benutzer auf eine Antwort wartet. Meiner Meinung nach ist der Unterschied zwischen 0,2 Sekunden und 7 Sekunden der Unterschied zwischen "die Antwort erschien sofort" und "der Benutzer schloss den Tab, ohne zu warten". Dieselbe Analyse fügt zwei weitere Konsequenzen langer Kontexte hinzu: Langkontext-Modelle sind immer noch durch das Trainingsdatum begrenzt, und die Erhöhung des Kontexts erhöht das Risiko, irrelevante oder verrauschte Texte einzuschleusen – das heißt, ein größerer Kontext ist nicht nur teurer und langsamer, sondern auch statistisch "schmutziger".

Merken Sie sich: Wenn Ihr Produkt empfindlich auf die Antwortgeschwindigkeit reagiert – Chatbot, Sprachassistent, Echtzeit-Agent – macht die quadratische Zunahme der Attention-Kosten den langen Kontext zur schlechtesten Wahl genau dort, wo die Geschwindigkeit am kritischsten ist. RAG hingegen hält den Prefill kurz (3000 Tokens statt einer Million), unabhängig davon, wie groß die Wissensdatenbank des Kunden ist.

RAG vs. Fine-Tuning: Wissen vs. Verhalten

Bevor wir weitermachen, sollten wir einen Begriff erklären, den ich beiläufig verwendet habe: Fine-Tuning (Nachschulung). Dies ist ein Prozess, bei dem ein bereits fertiges, vortrainiertes Modell (z. B. Llama oder GPT) auf einem engen, speziell vorbereiteten Datensatz von Beispielen weiter trainiert wird – und während dieses Trainings werden die Gewichte des Modells physisch verändert. Technisch sieht dies wie eine weitere Trainingsrunde aus, nur viel kürzer und billiger als das Training von Grund auf: Das Modell sieht Tausende von "Anfrage → gewünschte Antwort"-Paaren im gewünschten Format oder Ton, und der Gradientenabstieg passt die Modellparameter schrittweise an dieses Muster an. In leichten Varianten (LoRA, QLoRA) wird nicht das gesamte Modell aktualisiert, sondern nur ein kleiner zusätzlicher "Aufbau" über eingefrorenen Gewichten – das ist billiger und schneller.

Dies ist ein grundlegendes Framework, das man kennen sollte, bevor man weitermacht: Fine-Tuning verändert das Verhalten – Ton, Format, Stil, Syntax. Nach dem Nachschulen spricht das Modell einfach anders und strukturiert die Antwort anders, unabhängig davon, was gefragt wird. RAG verändert das Wissen – operative Fakten, die das Modell während der Antwort verwendet, ohne ein einziges Modellgewicht zu berühren.

Warum die Verwechslung dieser beiden Kategorien teuer ist: Wenn sich Ihre Daten häufiger als einmal pro Woche ändern, wird Fine-Tuning zu einem endlosen Wiederholungstraining – jede Preisaktualisierung, jede neue Unternehmensrichtlinie erfordert einen neuen Trainingsdurchlauf, einen neuen Beispieldatensatz und eine neue Validierung, dass das Modell durch das Nachschulen nicht "kaputtgegangen" ist. Bis dieser Zyklus abgeschlossen ist, ist das Modell bereits veraltet. RAG löst dies grundlegend anders: Das Aktualisieren der Wissensdatenbank bedeutet einfach, einen Vektor in der Datenbank zu überschreiben – Sekunden, ohne jegliches Nachtrainieren der Modellgewichte und ohne das Risiko, dass die Änderung eines Faktors den Antwortstil zu anderen Themen versehentlich verschlechtert.

Aber es gibt einen Nachteil, über den fast niemand schreibt: Das Problem liegt selten in der Wahl zwischen RAG und Fine-Tuning selbst. Laut Gartner scheitern bis zu 80 % der unternehmensweiten RAG-Implementierungen – und der Hauptgrund ist nicht die Architektur, sondern die Qualität der Daten, die in das System indiziert werden. Wir stoßen bei AskYourDocs regelmäßig darauf: Kunden senden Dokumente in unlesbarem Format – gedrehte Scans, PDFs ohne erkennbaren Text, Fotos von Papierformularen anstelle von digitalen Dateien. Und wie man so schön sagt: schlechte Daten rein, schlechte Daten raus (garbage in, garbage out): Das Modell kann keine genaue Antwort auf der Grundlage von Text geben, den es physisch nicht sieht, und beginnt zu halluzinieren, indem es eine "plausible" Antwort hinzufügt, anstatt ehrlich "Ich weiß es nicht" zu sagen. Einen solchen Fall haben wir im Fall Vision OCR für Unternehmen: Wie wir KI beigebracht haben, gedrehte Scans zu lesen detailliert analysiert, wo der Kunde 10.000 Scans geschickt hat, und gerade das unlesbare Format, nicht die RAG-Architektur, war die Ursache für die Halluzinationen.

Warum das so ist: Ein RAG-System ist nur so gut wie die Dokumente in seiner Datenbank. Wenn sich dort Duplikate, veraltete Vertragsvarianten oder unstrukturierte PDFs ohne klare Hierarchie befinden – wird das Modell selbstbewusst auf Basis von Müll antworten, und keine Abrufarchitektur wird das beheben. Das bedeutet, selbst eine perfekt gewählte Architektur wird das Projekt nicht retten, wenn die Dokumente in der Wissensdatenbank unstrukturiert, doppelt vorhanden oder veraltet sind.

Das bedeutet in der Praxis: Bevor Sie sich zwischen RAG und Fine-Tuning entscheiden, überprüfen Sie die Hygiene Ihrer Daten. Eine makellose Architektur auf schmutzigen Daten liefert makellos selbstbewusste falsche Antworten – und das ist schlimmer als gar keine Antwort.

Das Problem "lost in the middle"

Große Modelle können lange Texte technisch lesen, aber ihr Aufmerksamkeitsfokus verteilt sich ungleichmäßig: Informationen am Anfang und Ende des Kontexts werden besser behalten als die in der Mitte. Dies ist kein zufälliger Fehler, sondern ein stabil reproduzierbares Muster, das Forscher als U-förmige Aufmerksamkeitskurve bezeichnen: Wenn man den Graphen "Antwortgenauigkeit" in Abhängigkeit von der Position der benötigten Information im Text erstellt, hat er die Form eines U – hoch an den Rändern, ein Einbruch in der Mitte.

Warum das passiert und warum RAG das löst: RAG mildert den Effekt von "lost in the middle", indem es sicherstellt, dass die Modelle nur den relevantesten Inhalt sehen und nicht den gesamten Stapel auf einmal. Wenn man 497 von 500 Seiten Rauschen entfernt und nur 3 relevante Fragmente übrig lässt, entsteht das Problem der Aufmerksamkeitsunschärfe einfach nicht – es gibt keinen Ort, an dem es sich verstecken könnte. Das Modell selbst erhält physisch keine Möglichkeit, eine Information in der Mitte zu "vergessen", weil es in einem 3000-Token-Prompt kaum eine Mitte gibt.

Warum das besonders wichtig ist, wenn man mit langen Dokumenten arbeitet – Verträge über 80 Seiten, technische Dokumentation, Protokolle von Besprechungen – habe ich die Mechanik des Kontextfensters und warum die Verdoppelung des Kontexts viermal so viel kostet, detaillierter in dem Artikel LLM-Kontextfenster: Warum KI vergisst und was es kostet analysiert. Dort finden Sie auch einen Vergleich, wie Claude, GPT und Gemini die Aufmerksamkeit bei langen Kontexten unterschiedlich halten, was nützlich ist, wenn Sie ein Modell speziell für Aufgaben mit großen Dokumenten auswählen.

In der Praxis bedeutet dies für AskYourDocs eine einfache Sache: Wenn ein Kunde einen 80-seitigen Vertrag hochlädt und nach einem bestimmten Punkt auf Seite 45 fragt, wird RAG genau diesen Ausschnitt abrufen – unabhängig davon, auf welcher Seite er sich physisch befindet. Hätten wir stattdessen den gesamten Vertrag in den Kontext des Modells geladen, wäre die Genauigkeit der Antwort vom Zufall abhängig – davon, wie "nah am Rand" der benötigte Punkt lag.

Das Wichtigste hierbei: Gutes RAG funktioniert wie ein aufmerksamer Sekretär – es entfernt Rauschen, lässt die Essenz übrig. Es ist für das Modell einfacher, Schlussfolgerungen zu ziehen, wenn es klare Fakten vor sich hat und nicht einen wasserreichen Bericht von 500 Seiten, und die Qualität der Antwort hängt nicht mehr davon ab, wo sich die benötigte Information im Dokument versteckt.

Wo langer Kontext wirklich punktet

Ehrlichkeit gebietet, anzuerkennen: Langer Kontext ist nicht immer die schlechtere Wahl. Es gibt Szenarien, in denen er objektiv stärker ist als RAG, und dies zu verschweigen wäre, dieselbe einseitige Marketing-Fehlannahme zu wiederholen, nur in die andere Richtung.

Ich habe dies aus eigener Erfahrung festgestellt, als ich an einem Chatbot-Service arbeitete, bei dem das Modell den gesamten Gesprächsverlauf speichern musste – zuvor erwähnte Fakten über den Benutzer, den Kommunikationsstil, den Kontext früherer Antworten. Der Versuch, dies über RAG (Abruf einzelner "Fakten" aus der Historie) aufrechtzuerhalten, funktionierte schlechter als die einfache Übergabe der letzten N Nachrichten an den Kontext: Das Gespräch verlor an Kohärenz, das Modell "vergaß" den Charakter der Interaktion, der sich aus dem Ton und nicht aus einzelnen Fakten zusammensetzte. Für Dialogsysteme ist der Kontext des Fensters ein natürliches und richtiges Werkzeug, kein Kompromiss.

Empfehlung: Wenn Ihre Aufgabe eine einzige große, kohärente Quelle (Vertrag, Buch, technischer Bericht) ist oder die Aufrechterhaltung eines zusammenhängenden Dialogs – langer Kontext ist schneller und einfacher. Wenn Sie eine dynamische Datenbank mit Zehntausenden von Dokumenten und einen Strom von Anfragen dazu haben – RAG bleibt die wirtschaftlich und architektonisch richtige Wahl.

Ehrliches Fazit: Keiner der beiden Ansätze ist universell besser – und jeder Artikel, der etwas anderes behauptet, verkauft Ihnen Marketing, nicht Architektur.

Multitenancy und Sicherheit

Dies ist ein Argument, über das in Vergleichen von RAG vs. Long Context fast niemand schreibt – und es ist vielleicht das wichtigste für Unternehmen.

Stellen Sie sich die Unternehmenswissensdatenbank eines Unternehmens vor: HR-Dokumente, Finanzberichte von Direktoren, Kundenverträge. Ein Vertriebsmitarbeiter sollte keine Gehaltsabrechnungen der Personalabteilung sehen. Wenn Sie die gesamte Wissensdatenbank in das Kontextfenster eines einzigen Modells laden – wie grenzen Sie den Zugriff auf der Ebene einer einzelnen Anfrage ab?

Warum es durch das Kontextfenster oder Fine-Tuning nicht sicher gemacht werden kann: Beide Ansätze "backen" das Wissen entweder in den Prompt oder in die Modellgewichte ein, ohne zu wissen, wer genau die Frage stellt. Jeder Versuch, den Zugriff zu beschränken, würde bedeuten, eine separate Modellinstanz oder einen separaten Kontext für jeden Benutzer zu unterhalten – was die gesamte Wirtschaftlichkeit zerstört, die wir im Abschnitt über die Token-Falle berechnet haben.

RAG löst dies natürlich auf Architekturebene, nicht als Patch: Der Zugriff wird durch Metadaten in der Vektordatenbank gesteuert – Row-Level Security. Jeder Chunk ist mit Zugriffstags (Abteilung, Rolle, Kunde) gekennzeichnet, und das Modell erhält physisch nicht die Chunks, zu denen der Benutzer keine Rechte hat. Dies ist kein Filter am Ausgang, der durch Prompt-Injection umgangen werden kann – dies ist eine Beschränkung bereits in der Retrieval-Phase, bevor der Text überhaupt in den Kontext des Modells gelangt.

Praktische Schlussfolgerung: Für B2B-SaaS, das gleichzeitig mit Dokumenten mehrerer Kunden arbeitet, ist mandantenfähige Sicherheit keine optionale Funktion, sondern der Grund, warum RAG die einzig praktikable Architektur ist, unabhängig von der Größe des Kontextfensters.

Beispiel von AskYourDocs: Als wir die Architektur entwarfen, standen wir genau vor dieser Wahl – alle Kunden in einer gemeinsamen Datenbank mit Isolierung durch tenant_id zu halten oder für jeden Kunden eine separate Datenbank (und oft eine separate Instanz) bereitzustellen. Dies ist keine theoretische Frage aus einem Lehrbuch, sondern eine Entscheidung, die bestimmt, wie der gesamte Stack aussieht.

Wir haben uns für Single-Tenant entschieden – und entscheidend waren zwei Faktoren, die sich direkt aus unserer Prüfung ergaben. Erstens, DSGVO: Wenn die Daten jedes Kunden physisch in einer separaten Datenbank liegen, ist die Antwort auf die Anfrage "löschen Sie alle unsere Daten" das Löschen einer Datenbank, anstatt den Code zu prüfen, ob alle Anfragen tatsächlich nach tenant_id an jeder der Dutzenden von Stellen in der Codebasis gefiltert wurden. Zweitens verlangt ein Teil unserer Unternehmenskunden Self-Hosting – ihre Dokumente dürfen ihre eigene Infrastruktur nicht verlassen, und die Single-Tenant-Architektur ist dafür natürlich geeignet, ohne zusätzliche Isolationsschichten.

Wenn Sie solche Einschränkungen nicht haben – zum Beispiel, wenn Sie ein Produkt für Hunderte kleiner Kunden ohne strenge Compliance-Anforderungen entwickeln – bleibt Multi-Tenant mit tenant_id und Row-Level Security die wirtschaftlich richtige Wahl: Der Zugriff wird durch Metadaten direkt in der SQL-Abfrage der Vektorsuche gefiltert, bevor das Retrieval überhaupt beginnt, die Ähnlichkeit zu berechnen. Es ist nur wichtig, klar zu verstehen, dass diese Infrastruktureinsparung ein bewusster Kompromiss mit der Sicherheit ist, kein kostenloser Bonus.

Woraus besteht eine gute RAG-Pipeline?

All das oben Genannte macht nur Sinn, wenn RAG selbst richtig gemacht ist. Schlechter RAG – mit primitivem Chunking und reinen Vektoren ohne Schlüsselwörter – diskreditiert den gesamten Ansatz und liefert Argumente für Befürworter von "einfach in den Kontext laden". Drei Komponenten unterscheiden Produktionsqualität von Prototypen.

Chunking-Strategie: nach Struktur schneiden, nicht nach Zeichen

Der häufigste Fehler ist, Text nach einer festen Anzahl von Zeichen zu schneiden, wobei Überschriften, Tabellen und Absatzgrenzen ignoriert werden. Dies "schneidet ins Fleisch": Es reißt den Gedanken mitten im Satz auseinander und zerstört den Kontext eines Chunks. Der richtige Ansatz berücksichtigt die Struktur des Dokuments. Eine detaillierte Analyse von sieben Strategien mit Benchmarks finden Sie im Artikel Chunking in RAG 2026: 7 Strategien für die Produktion.

Hybrid Search: Vektoren ohne Schlüsselwörter sind ein Zeichen für schlechtes RAG

Reine Vektorsuche verpasst exakte Übereinstimmungen – Bestellnummern, Fehlercodes, exakte Begriffe – da semantische Nähe keine lexikalische Übereinstimmung garantiert. Die Kombination von BM25 (Schlüsselwort) und Vektorsuche schließt diese Lücke. Ich habe dies detailliert am Beispiel meines eigenen RAG-Services im Artikel Ich habe BM25 zu meinem RAG-Service hinzugefügt – und die Vektorsuche hat aufgehört, exakte Anfragen zu verlieren erläutert.

Reranking: Zweite Prüfung, bevor sie der LLM angezeigt wird

Die Vektorsuche liefert Kandidaten schnell, aber nicht immer genau. Ein Reranker – ein separates, leichteres Modell (Cross-Encoder) – überprüft die Top-Ergebnisse, bevor sie an die LLM übergeben werden, und sortiert sie nach tatsächlicher Relevanz. In Kombination mit Hybrid Search ergibt dies eine messbare Qualitätssteigerung: eine vollständige Analyse mit Zahlen von +15–40 % – im Artikel Hybrid Search und Reranking für RAG: +15-40 % Qualität.

Kurz gesagt: Das Auslassen einer dieser drei Komponenten verwandelt "RAG" in eine teure und langsame Qualitätsverschlechterung im Vergleich zum gleichen langen Kontext. RAG gewinnt nur, wenn es richtig gemacht wird.

Self-Route: Hybride Weiterleitung

Anstatt sich von vornherein für RAG oder langen Kontext in der Systemdesignphase zu entscheiden, haben Forscher vorgeschlagen, diese Entscheidung dem Modell selbst zu überlassen. Der Ansatz Self-Route wird in der Forschungsarbeit "Retrieval Augmented Generation or Long-Context LLMs?" des Teams von Google DeepMind und der University of Michigan beschrieben. Die Forscher testeten RAG und langen Kontext auf mehreren Datensätzen und stellten ein unerwartetes Ergebnis fest: Wenn die Ressourcen ausreichen, liefert langer Kontext im Durchschnitt eine bessere Genauigkeit als RAG – aber RAG bleibt deutlich günstiger. Das heißt, es gibt keinen klaren Gewinner: Einer gewinnt bei der Qualität, der andere bei den Kosten. Self-Route ist ein Versuch, das Beste aus beiden Welten zu bekommen, anstatt sich einmal und für immer zu entscheiden.

Die Mechanik des Ansatzes besteht aus zwei konkreten Schritten, nicht aus einer abstrakten "das Modell entscheidet selbst". Schritt 1: Die Anfrage und die RAG-Chunks (wie bei normalem RAG) werden an das Modell übergeben, aber mit einem Unterschied – das Modell erhält die ausdrückliche Erlaubnis, die Antwort zu verweigern, wenn es die Informationen in den Chunks für unzureichend hält, anstatt eine plausible Antwort zu erfinden. Schritt 2: Wenn das Modell verweigert – erst dann wird die Anfrage an den vollständigen Kontext des Dokuments weitergeleitet, und das Modell antwortet, wobei der gesamte Text vor Augen liegt. Eine einfache Anfrage durchläuft Schritt 1 und erhält eine schnelle, günstige Antwort. Eine komplexe Anfrage "scheitert" an Schritt 1, das Modell sagt ehrlich "nicht genügend Daten" – und erst dann zahlt das System für den teureren Durchgang durch den vollständigen Kontext.

Warum das in der Praxis funktioniert: Einfache faktische Fragen ("welches Datum hat die Unterzeichnung des Vertrags") durchlaufen fast immer erfolgreich Schritt 1 – RAG wird schneller und günstiger damit fertig, da die benötigte Tatsache normalerweise in einem oder zwei Chunks liegt. Eine komplexe mehrstufige Frage ("wie haben sich die Vertragsbedingungen zwischen drei Versionen geändert") wird mit hoher Wahrscheinlichkeit Schritt 1 nicht bestehen: Die Antwort ist über das gesamte Dokument verstreut, das Retrieval holt nur einen Teil des Bildes, und das Modell – wenn es gut kalibriert ist – erkennt dies. Das Wort "kalibriert" ist hier entscheidend: Der gesamte Ansatz beruht auf der Annahme, dass das Modell seine eigene Unsicherheit ausreichend ehrlich einschätzt und keine Unsicherheit vortäuscht, wo keine ist. Dies ist keine bedingungslose Garantie, sondern ein probabilistischer Mechanismus, der bei leistungsfähigeren Modellen besser funktioniert.

Für ein Produktionssystem bedeutet dies ein konkretes technisches Muster: Der erste Durchgang ist immer günstig (RAG), der zweite Durchgang ist eine teurere Fallback-Option (vollständiger Kontext), die nur für die Minderheit der Anfragen aktiviert wird, bei denen sie wirklich benötigt wird. Der Großteil des Traffics – einfache Fakten – berührt niemals den teuren Weg.

In der Praxis bedeutet dies: Die Architektur von 2026 ist keine Wahl von "RAG oder Kontext" zu Beginn des Projekts, sondern eine Routing-Ebene, die dies für jede Anfrage einzeln entscheidet, und die Kosten für diese Entscheidung sind nur ein zusätzlicher, günstiger Durchgang des Modells durch die RAG-Chunks, bevor es "das reicht nicht" erkennt.

Hybrider Stack 2026: Fazit

Die ideale Architektur von heute ist kein „entweder/oder“. Sie besteht aus drei Schichten: ein kleines, schnelles Modell, das für ein bestimmtes Antwortformat feinabgestimmt wurde (Fine-Tuning für Verhalten); eine hochwertige, polierte RAG-Pipeline mit Hybrid Search und Re-Ranker (Wissensschicht); und eine Self-Route-Ebene, die für jede Anfrage entscheidet, ob Retrieval ausreicht oder ein vollständiger Kontext benötigt wird.

Keine dieser drei Schichten ersetzt die anderen. Fine-Tuning ohne RAG liefert einen konsistenten, aber veralteten Ton. RAG ohne gutes Chunking und Hybrid Search liefert eine schnelle, aber ungenaue Antwort. Langer Kontext ohne RAG liefert Genauigkeit für ein einzelnes Dokument – und eine finanzielle Katastrophe bei Tausenden von Anfragen an eine große Datenbank.

Die wichtigste Schlussfolgerung des Artikels: Die Größe des Kontextfensters Ihres Modells ist eine Marketingzahl auf einer Präsentationsfolie und kein Indikator dafür, wie gut Ihr KI-System ist. Eine Million Token retten kein Projekt, bei dem Retrieval irrelevante Chunks zurückgibt, Dokumente nicht strukturiert oder dupliziert sind und auf fremde Daten durch einen banalen Fehler in einer SQL-Abfrage zugegriffen werden kann. Echte Qualitätsindikatoren sind die Genauigkeit des Retrievals (findet das System wirklich ein relevantes Fragment und nicht nur eines, das vektoriell ähnlich ist), die Datenhygiene (sind die Dokumente strukturiert, aktuell, ohne Duplikate – das, woran 80 % der RAG-Implementierungen scheitern) und die Sicherheitsarchitektur darum herum (ist es physisch unmöglich, dass ein Kunde die Daten eines anderen sieht, unabhängig von Codefehlern).

Das Kontextfenster ist nur eines der Werkzeuge im Werkzeugkasten, nicht das Ziel an sich. Ein Team, das ein Modell mit dem größten Kontext wählt und die Architekturfrage für erledigt hält, wird wahrscheinlich den Weg wiederholen, der zu Beginn dieses Artikels beschrieben wurde: zuerst die Versuchung, „alles einfach in den Prompt zu werfen“, dann die unhaltbare Token-Rechnung, und dann – die schmerzhafte Rückkehr zu Retrieval, Chunking und RLS, nur unter dem Druck eines Produktionsvorfalls und nicht als bewusste architektonische Entscheidung von Anfang an.

Häufig gestellte Fragen

Ist RAG wegen langer Kontextfenster veraltet?

Nein. Kontextfenster haben das Problem des technischen Token-Limits gelöst, aber nicht die Probleme der Kosten, Geschwindigkeit und Sicherheit des Datenzugriffs – und genau diese drei Faktoren bestimmen, ob RAG in der Produktion eingesetzt werden kann.

Was ist günstiger: RAG oder langer Kontext?

RAG ist bei häufigen Abfragen an eine große Wissensdatenbank um Größenordnungen günstiger – in unserer Berechnung betrug der Unterschied das 333-fache. Langer Kontext kann nur für die einmalige Analyse eines Dokuments günstiger sein.

Wann ist es besser, Fine-Tuning anstelle von RAG zu verwenden?

Fine-Tuning eignet sich, wenn das Verhalten des Modells geändert werden muss – Ton, Format, Stil der Antwort. Für operative Fakten, die sich häufiger als einmal pro Woche ändern, ist RAG die einzig praktikable Option.

Was ist „lost in the middle“?

Ein Effekt, bei dem ein Modell Informationen, die sich in der Mitte eines langen Kontexts befinden, schlechter nutzt als Informationen am Anfang oder Ende. RAG mildert dieses Problem, indem es nur relevante Fragmente anstelle des gesamten Textblocks liefert.

Kann RAG und Fine-Tuning kombiniert werden?

Ja, und das ist das häufigste Produktionsmuster von 2026: Fine-Tuning ist für stabiles Verhalten und Format verantwortlich, RAG für aktuelle Fakten zum Zeitpunkt der Anfrage.

Wie löst RAG das Problem des Datenzugriffs im Unternehmen?

Durch Row-Level Security auf der Ebene der Metadaten der Vektordatenbank: Jeder Chunk ist mit Zugriffstags versehen, und der Benutzer erhält physisch keine Informationen, zu denen er keine Rechte hat – die Einschränkung greift noch bevor der Text in den Kontext des Modells gelangt.

Was ist Self-Route in RAG-Systemen?

Ein Ansatz, bei dem das Modell für jede spezifische Anfrage selbst entscheidet, ob Retrieval (RAG) ausreicht oder ein vollständiger Dokumentenkontext benötigt wird – basierend auf der Komplexität der Frage.

Warum scheitern RAG-Implementierungen oft?

Laut Gartner scheitern bis zu 80 % der RAG-Implementierungen in Unternehmen – und der Hauptgrund liegt nicht in der Architektur, sondern in der Qualität der indizierten Daten: Duplikate, veraltete Informationen, fehlende Struktur.

Lesen Sie auch

• Was sind Embeddings: Wie KI den Sinn von Text versteht – die Grundlage dafür, wie Vektorsuche funktioniert
• Vektorsuche für Anfänger – wie RAG die benötigten Informationen findet
• Embedding-Modelle für RAG im Jahr 2026 – Vergleich von Anbietern und Auswahl für die Aufgabe