Ist RAG noch relevant? Retrieval im Zeitalter langer Kontextfenster

Ihr KI-Anbieter sagt, Sie brauchen kein RAG mehr. Ihr KI-Entwickler sagt, ohne RAG geht nichts. Beide haben halb recht, und das macht die Entscheidung so schwer.

Retrieval Augmented Generation, kurz RAG, war 2023 und 2024 eine der am stärksten gehypten Technologien im Bereich KI. Wer ein ernstzunehmendes KI-Projekt umsetzte, baute eine Vektor-Datenbank, berechnete Embeddings und kombinierte beides mit einem Sprachmodell. 2026 ist die Begeisterung abgeklungen. Moderne Modelle wie Gemini 2.5 Pro oder Claude verarbeiten bis zu einer Million Token in einem einzigen Prompt. Das entspricht der kompletten Herr-der-Ringe-Trilogie mit Platz für den Hobbit. Viele Unternehmen fragen sich jetzt: Ist die ganze RAG-Infrastruktur überhaupt noch nötig?

Die ehrliche Antwort ist nicht schwarz oder weiß. Sie ist nicht "RAG ist tot" und nicht "RAG löst alles". Sie ist: Es kommt auf den Anwendungsfall an. Dieser Artikel zeigt, was RAG wirklich ist, warum lange Kontextfenster das Spielfeld verändert haben und welche Architektur für welches Szenario die richtige ist. Er basiert auf meiner Erfahrung aus verschiedenen KI-Projekten im Mittelstand und der aktuellen Marktlage im Frühjahr 2026.

Was RAG wirklich ist

Die häufigste Verwechslung in Gesprächen über RAG ist diese: RAG wird mit Embeddings gleichgesetzt. Das ist der Ursprung vieler falscher Architekturentscheidungen. Retrieval Augmented Generation ist kein konkretes Verfahren, sondern ein Prinzip. Es bedeutet: Relevante Informationen aus einer externen Quelle in den Kontext eines Sprachmodells laden, bevor das Modell antwortet.

Der Kern dieses Prinzips ist die Trennung zwischen Wissensspeicher und Sprachmodell. Das Modell selbst muss nichts Konkretes über Ihr Unternehmen wissen. Es muss nur gut mit dem arbeiten können, was ihm geliefert wird. Und genau dafür muss eine Retrieval-Schicht sorgen.

RAG ist nicht Embeddings

Embeddings sind eine mathematische Repräsentation von Text. Textabschnitte werden in Vektoren umgerechnet, also in lange Zahlenreihen, die sich miteinander vergleichen lassen. Wenn zwei Texte thematisch ähnlich sind, liegen ihre Vektoren nah beieinander. Das ist die Grundlage der semantischen Suche, und sie war bis 2024 der Standard für Retrieval in KI-Systemen.

Aber Embeddings sind nur ein Mechanismus, nicht der einzige. Und sie haben klare Schwächen. Sie müssen für jeden Text berechnet werden, was Rechenzeit kostet. Sie müssen synchron zum Quelldatenbestand gehalten werden, was organisatorischen Aufwand erzeugt. Und sie liefern nicht immer bessere Ergebnisse als eine einfache Schlagwort-Suche.

Andere Retrieval-Methoden

In produktiven Systemen ist Retrieval fast nie reine semantische Suche. Es ist eine Kombination aus mehreren Ansätzen. Die klassische Schlagwort-Suche ist in vielen Fällen überlegen, gerade bei Fachbegriffen, Produktnummern oder Eigennamen. Strukturierte SQL-Abfragen sind für bestimmte Fragen deutlich effizienter als jede KI-Lösung. API-Aufrufe an bestehende Systeme liefern live und aktuell, was in einer Vektor-Datenbank längst veraltet wäre. Hybride Suche kombiniert Schlagwort und Semantik und liefert in der Praxis meistens die besten Ergebnisse.

Wer RAG denkt, sollte also nicht "Vektor-Datenbank" denken, sondern "wie kommen die richtigen Informationen zur richtigen Zeit ins Kontextfenster". Die Antwort ist selten ein einzelnes Werkzeug.

Warum die Frage RAG oder Long Context überhaupt gestellt wird

Vor zwei Jahren waren Kontextfenster von 8.000 Token Standard. Das reicht für ein paar Seiten Text, nicht für ein Firmen-Handbuch. Wer ein KI-System auf einer umfangreichen Wissensbasis aufbauen wollte, brauchte Retrieval. Es gab keine Alternative.

Heute haben sich die Verhältnisse verschoben. Modelle mit einer Million Token oder mehr sind verfügbar. Der Traum dahinter ist verständlich: Alle Dokumente in den Prompt kippen, das Modell macht den Rest. Keine Embedding-Pipeline, keine Vektor-Datenbank, keine Chunking-Strategie. Weniger Infrastruktur, weniger Fehlerquellen, schnellere Entwicklung.

Die unangenehme Wahrheit: Mehr Kontext bedeutet nicht automatisch bessere Antworten. Im Gegenteil. Je mehr Tokens ein Modell verarbeitet, desto schlechter wird die Fokussierung. Forschungsarbeiten zeigen, dass Informationen in der Mitte langer Kontexte schlechter gefunden werden als am Anfang oder Ende. Und die Kosten skalieren linear mit der Eingabegröße. Jede Anfrage bei einer Million Token kostet bares Geld, immer wieder.

Die drei Argumente für Long Context

Trotzdem gibt es gute Gründe, warum Long Context in manchen Szenarien die bessere Wahl ist. Drei davon sind ernst zu nehmen.

Einfachere Infrastruktur

Ein produktives RAG-System ist kein kleines Projekt. Sie brauchen eine Chunking-Strategie, also eine Logik, wie Dokumente in verarbeitbare Stücke zerlegt werden. Sie brauchen ein Embedding-Modell, das die Chunks in Vektoren umwandelt. Sie brauchen eine Vektor-Datenbank zur Speicherung. Sie brauchen einen Reranker, um die besten Treffer zu sortieren. Sie brauchen eine Synchronisation zwischen Quelldaten und Vektoren. Und all das muss überwacht, gewartet und aktualisiert werden.

In der Praxis hat ein professionelles RAG-System leicht zehn bis fünfzehn Komponenten. Jede dieser Komponenten kann kaputtgehen. Long Context umgeht diese Komplexität komplett. Sie laden Ihre Daten in den Kontext und fragen. Fertig.

Für Teams mit wenig KI-Erfahrung ist das ein realer Vorteil. Weniger Infrastruktur bedeutet weniger Angriffsfläche, weniger Betriebskosten und eine steilere Lernkurve bis zum produktiven Einsatz.

Kein Retrieval-Roulette

Der gefährlichste Fehlermodus in RAG-Systemen heißt Silent Failure. Die relevante Information existiert in Ihrem Datenbestand, aber das Retrieval findet sie nicht. Das Modell bekommt die falschen oder unvollständigen Chunks und generiert trotzdem eine Antwort. Die Antwort wirkt souverän und überzeugend, ist aber falsch.

Dieser Fehler ist schwer zu entdecken, weil er nicht als Fehler erscheint. Das System sagt nicht "Ich habe nichts gefunden". Es halluziniert eine plausible Antwort auf Basis unvollständiger Daten. Für viele Unternehmensanwendungen ist das hochproblematisch, besonders wenn Entscheidungen auf den Antworten basieren.

Long Context löst dieses Problem, weil es keinen Retrieval-Schritt gibt. Das Modell sieht alles. Was gefunden werden kann, kann auch berücksichtigt werden.

Das Ganze-Buch-Problem

RAG ist darauf ausgelegt, relevante Ausschnitte zu finden. Das funktioniert gut, wenn die Antwort in einem konkreten Textabschnitt steht. Es funktioniert schlecht, wenn die Antwort in dem liegt, was nicht da ist.

Ein Beispiel: Sie haben ein Anforderungsdokument und ein Release-Dokument. Die Frage lautet: Welche Sicherheitsanforderungen wurden im finalen Release nicht umgesetzt? Die Antwort steckt nicht in einem einzelnen Chunk. Sie ergibt sich aus dem Vergleich beider Dokumente, aus dem, was im einen steht und im anderen fehlt.

RAG findet die Anforderungen und findet die Release-Notizen. Aber die Lücke zwischen beiden ist kein abrufbarer Ausschnitt. Das Modell sieht nie das vollständige Bild und kann die Lücke nicht erkennen. Long Context zeigt beide Dokumente komplett und ermöglicht den Vergleich.

Warum RAG trotzdem relevant bleibt

Die Gegenargumente sind mindestens ebenso gewichtig. Drei davon sollten jeder Architekturentscheidung zugrunde liegen.

Die Rechenkosten-Falle

Kontextfenster klingen in der Werbung kostenlos. In der Rechnung sind sie es nicht. Ein 500-Seiten-Handbuch entspricht rund 250.000 Token. Wenn Sie dieses Handbuch bei jeder Anfrage in den Prompt laden, zahlen Sie bei jeder Anfrage für die Verarbeitung aller 250.000 Token. Bei einem Unternehmen mit 10.000 Anfragen pro Monat ergibt das 2,5 Milliarden verarbeitete Token nur aus diesem einen Dokument.

RAG dreht diese Rechnung um. Die Daten werden einmal beim Indexieren verarbeitet. Bei jeder Anfrage werden nur die relevanten Chunks geladen, oft weniger als 10.000 Token. Die Verarbeitungskosten pro Anfrage sind damit eine Größenordnung kleiner.

Prompt Caching kann diesen Unterschied für statische Daten teilweise ausgleichen. Bei dynamischen Datenbeständen, die sich ändern, greift diese Optimierung aber nicht. Und genau dynamische Daten sind im Unternehmenskontext der Regelfall: Wikis, Tickets, Mails, Verträge, Berichte. Sie ändern sich ständig.

Die Nadel im Heuhaufen

Die Annahme, dass ein Modell alles nutzt, was im Kontextfenster steht, ist naiv. Die Realität sieht anders aus. Je länger der Kontext, desto diffuser die Aufmerksamkeit des Modells. Eine Information, die in der Mitte eines 500-Seiten-Dokuments steht, wird häufig nicht gefunden. Oder das Modell halluziniert Details aus dem umgebenden Text statt die exakte Stelle zu zitieren.

RAG reduziert den Heuhaufen, bevor das Modell ihn durchsuchen muss. Indem nur die relevanten fünf bis zehn Chunks geliefert werden, wird der Kontext fokussiert. Das Modell arbeitet mit Signal statt Rauschen. Die Antwortqualität profitiert direkt davon.

Dieses Prinzip gilt universell in der KI: Weniger Tokens, wenn sie die richtigen sind, führen zu besseren Ergebnissen als mehr Tokens. Die Illusion, dass "mehr Kontext immer besser" ist, hält sich hartnäckig, ist aber falsch.

Der unendliche Datenbestand

Eine Million Token sind beeindruckend. Im Unternehmenskontext sind sie verschwindend klein. Ein durchschnittliches Unternehmen hat Datenbestände im Terabyte-Bereich. Größere Organisationen bewegen sich im Petabyte-Bereich. Selbst das größte Kontextfenster eines Modells ist davon Lichtjahre entfernt.

Für alles, was nicht ein einzelnes, bounded Dataset ist, brauchen Sie zwingend eine Retrieval-Schicht. Ohne sie kommen Sie nicht einmal in die Nähe des Kontextfensters. Die Frage ist nicht, ob Retrieval gebraucht wird, sondern wie es aussehen soll.

Der echte Entscheidungsrahmen

Die Wahl zwischen Long Context und RAG ist keine Glaubensfrage. Sie folgt klaren Mustern.

Wann Long Context die richtige Wahl ist

Long Context gewinnt bei abgegrenzten Datenbeständen und bei globalem Reasoning. Wenn die relevanten Daten ein einzelnes Dokument oder eine kleine Dokumentengruppe sind, zum Beispiel ein Vertrag, ein Buch, ein technisches Handbuch. Wenn die Analyse das gesamte Dokument betrachten muss, zum Beispiel für Vergleiche, Lückenanalysen oder übergreifende Zusammenfassungen. Und wenn die Anfragefrequenz gering ist, sodass die höheren Kosten pro Anfrage tragbar bleiben.

Typische Anwendungsfälle: Juristische Vertragsanalyse, wissenschaftliche Literaturauswertung einzelner Studien, Code-Review über ein komplettes Repository, Qualitätsanalysen einzelner technischer Spezifikationen.

Wann RAG die richtige Wahl ist

RAG gewinnt überall dort, wo der Datenbestand groß, wachsend oder dynamisch ist, wo fokussierte Antworten gefragt sind und wo die Anfragefrequenz hoch ist. Ein Unternehmen mit tausenden Dokumenten, Tickets und Wiki-Einträgen kann diese nicht in jeden Prompt laden. Ein Kundensupport-System mit hunderten Anfragen pro Tag kann sich die Kostenstruktur von Long Context nicht leisten. Ein Helpdesk, der präzise auf konkrete Probleme antwortet, profitiert von fokussiertem Kontext statt Dokumenten-Fluten.

Typische Anwendungsfälle: Internes Wissensmanagement, Kundensupport-Automatisierung, Entwickler-Assistenten über firmeninternen Code, Recherche in wachsenden Dokumentensammlungen.

Wann Hybrid die richtige Wahl ist

In der Praxis ist Hybrid die häufigste Antwort. Ein Retrieval-Schritt grenzt den relevanten Bereich grob ein. Der gefundene Ausschnitt kann dann in einem größeren Kontextfenster tief verarbeitet werden. Tool-Use und das Model Context Protocol erweitern beides um strukturierte Abfragen an Live-Systeme. Die Architektur wird komplexer, aber sie spiegelt die Realität der meisten Unternehmen.

Kriterium	Long Context	RAG	Hybrid
Datenmenge	Klein, abgegrenzt	Groß, wachsend	Gemischt
Anfragefrequenz	Niedrig	Hoch	Mittel bis hoch
Antwort-Tiefe	Global, vergleichend	Fokussiert	Beides
Kosten pro Anfrage	Hoch	Niedrig	Mittel
Infrastruktur-Aufwand	Niedrig	Hoch	Hoch
Datenaktualität	Statisch	Dynamisch	Dynamisch

Der Mittelstand und die Retrieval-Frage

Die theoretische Debatte RAG gegen Long Context übersieht das eigentliche Problem vieler Unternehmen. Das liegt nicht in der Wahl der Retrieval-Technologie, sondern in der Qualität der Daten.

Das ungeliebte Thema Datenformate

Im Mittelstand liegen Dokumente meistens als PDF vor. Verträge, technische Beschreibungen, Produktkataloge, Präsentationen. PDF ist ein schlechtes Format für KI-Systeme. Die Text-Extraktion ist unzuverlässig, besonders bei mehrspaltigen Layouts, Tabellen oder gescannten Dokumenten. Bilder müssen separat beschrieben werden, was zusätzliche Verarbeitung kostet. Und die Struktur eines Dokuments, also Überschriften, Listen, Querverweise, geht bei der Extraktion oft verloren.

Der Effekt ist direkt spürbar. Ein RAG-System, das auf PDFs aufgesetzt wird, liefert schlechtere Ergebnisse als eines, das mit strukturierten Markdown- oder HTML-Dokumenten arbeitet. Die Chunks sind unsauber, die Embeddings unpräzise, die Retrieval-Qualität sinkt.

Wer KI produktiv einsetzen will, muss früh über Datenformate nachdenken. Nicht nach dem Motto "Wir digitalisieren alles später". Sondern nach dem Prinzip: Welches Format ist die beste Grundlage für spätere Nutzung, inklusive KI? Strukturierte Daten, Markdown, ordentliche Datenbanken schlagen Scan-PDFs um Größenordnungen.

Die realistische Architektur

Ein pragmatisches KI-System im Mittelstand kombiniert mehrere Retrieval-Quellen. Strukturierte Daten werden per SQL abgefragt. Textuelle Dokumente werden über hybride Suche erschlossen, also Schlagwort und Semantik kombiniert. Live-Daten aus Systemen wie CRM oder ERP kommen über API-Aufrufe in den Kontext. Das Sprachmodell selbst entscheidet, welches Werkzeug es für welche Frage nutzt.

Das Model Context Protocol hat in diesem Bereich 2025 viel bewegt. Es standardisiert, wie Sprachmodelle mit externen Werkzeugen kommunizieren. Für Unternehmen bedeutet das: Einmal angebundene Systeme sind für jedes kompatible Modell nutzbar, ohne für jeden Anbieter eine eigene Integration zu bauen.

Was oft schiefgeht

In meiner Erfahrung aus KI-Projekten im Mittelstand sehe ich immer wieder dieselben Fehler. Unternehmen investieren in Vektor-Datenbanken, bevor sie verstehen, was sie eigentlich brauchen. Embeddings werden auf Dokumente berechnet, die sich monatlich ändern, ohne einen Plan für die Re-Indexierung. Die Qualität des Retrievals wird nie gemessen, aber an der Antwortqualität müsste sie gemessen werden. Wenn das Retrieval schlecht ist, kann auch das beste Sprachmodell keine guten Antworten geben.

Ohne technische Führung, die diese Zusammenhänge überblickt, werden KI-Projekte oft nach dem Lautesten im Raum gebaut. Wer den Vektor-Datenbank-Anbieter zuerst empfohlen hat, gewinnt. Die Architekturentscheidung wird delegiert, statt getroffen. Am Ende steht ein System, das technisch funktioniert, aber die Erwartungen nicht erfüllt.

Was sich 2026 verändert hat

Die Debatte RAG gegen Long Context ist in gewisser Weise schon wieder überholt. Die wichtigste Entwicklung der letzten achtzehn Monate ist nicht die Größe der Kontextfenster, sondern die Qualität des Tool-Use.

Moderne Sprachmodelle rufen selbstständig Suchmaschinen auf, fragen Datenbanken ab und integrieren Live-Informationen. Das ist kein starres RAG-System mit vordefinierten Retrieval-Schritten. Es ist eine dynamische Informationsbeschaffung, bei der das Modell selbst entscheidet, welche Daten es braucht. Dieser Ansatz wird oft Agentic Search genannt und ist in vielen Szenarien der klassischen RAG-Pipeline überlegen.

Reine RAG-Systeme oder reine Long-Context-Lösungen werden selten. Die meisten produktiven Systeme, die ich 2026 sehe, nutzen beides und erweitern es um Tool-Use. Die grundlegende Logik bleibt aber gleich: Relevante Informationen finden und dem Modell zur Verfügung stellen. Der Name ändert sich, das Problem bleibt.

Fünf Fragen vor der Architekturentscheidung

Wer vor einer KI-Architekturentscheidung steht, sollte diese fünf Fragen beantworten, bevor irgendeine Technologie ausgewählt wird.

Wie groß ist der relevante Datenbestand? Einzelne Dokumente, hundert Dokumente oder ein kompletter Firmen-Wissensspeicher? Die Größenordnung bestimmt, ob Long Context überhaupt möglich ist.
Wie oft ändern sich die Daten? Statisch, monatlich, täglich oder live? Bei häufig wechselnden Daten ist Prompt Caching nutzlos, und die Long-Context-Kosten bleiben voll bestehen.
Wie viele Anfragen erwarten Sie pro Monat? 100, 10.000 oder 1 Million? Bei hoher Frequenz entscheidet die Kostenstruktur pro Anfrage über die Wirtschaftlichkeit.
Welche Art von Antworten brauchen Sie? Fokussierte Auszüge oder übergreifende Analysen? Fokussierte Antworten profitieren von RAG, globales Reasoning von Long Context.
In welchem Format liegen Ihre Daten heute? Strukturiert oder als Scan-PDF? Das Datenformat ist oft der limitierende Faktor, nicht die Retrieval-Technologie.

Die Antworten auf diese Fragen bestimmen die Architektur. Nicht der Hype, nicht der Vertriebsmitarbeiter und nicht das Buzzword der Woche.

Fazit

RAG ist nicht tot. Aber die Frage ist selten "RAG oder nicht". Lange Kontextfenster haben das Spielfeld erweitert, nicht vereinfacht. In den meisten produktiven KI-Systemen von 2026 arbeiten Retrieval, Long Context und Tool-Use zusammen. Welche Kombination die richtige ist, hängt vom Anwendungsfall ab, nicht von der Technologiewahl.

Der häufigste Fehler im Mittelstand ist nicht die falsche Retrieval-Strategie. Er ist, gar keine bewusste Entscheidung zu treffen. Systeme werden gebaut, weil jemand einen Vektor-Datenbank-Vortrag gesehen hat oder weil der KI-Anbieter diesen Ansatz mitliefert. Die eigentliche Frage, was der Anwendungsfall wirklich braucht, wird übersprungen.

Wer KI produktiv einsetzen will, braucht jemanden, der diese Entscheidungen verantworten kann. Jemanden, der die technischen Unterschiede versteht, aber auch die wirtschaftlichen und organisatorischen Konsequenzen einschätzen kann. Warum das eine klassische CTO-Aufgabe ist, habe ich in einem früheren Artikel beschrieben. Für viele Mittelständler ist ein Fractional CTO oder externer Berater der richtige Weg. Wie lokale KI-Modelle diese Entscheidung zusätzlich beeinflussen, habe ich zuletzt behandelt.

Checkliste: Ihre nächste KI-Architekturentscheidung

Sie haben die Größe und Änderungshäufigkeit Ihres Datenbestands konkret eingeschätzt.
Sie kennen die erwartete Anfragefrequenz und haben die Kostenstruktur von RAG und Long Context verglichen.
Sie haben bewertet, ob Ihre Daten in einem Format vorliegen, das für KI-Verarbeitung geeignet ist.
Sie haben geprüft, ob ein einzelner Retrieval-Ansatz reicht oder eine hybride Architektur nötig ist.
Sie haben berücksichtigt, wie sich Ihr Datenbestand in den nächsten zwei bis drei Jahren entwickelt.
Sie haben eine neutrale technische Bewertung eingeholt, nicht nur den Vorschlag eines Anbieters übernommen.
Sie wissen, wie Sie die Qualität des Retrievals messen werden, nicht nur die Antwortqualität.

Wenn Sie bei drei oder mehr Punkten unsicher sind, fehlt die Grundlage für eine fundierte Architekturentscheidung. Ein KI-Strategie-Workshop bringt in zwei bis drei Tagen Klarheit: Analyse Ihrer Anwendungsfälle, Bewertung der Datenlage, konkrete Empfehlung für die passende Architektur.

Sie planen ein KI-Projekt und stehen vor der Frage, welche Architektur wirklich passt? Kontaktieren Sie mich für einen KI-Strategie-Workshop.