Long-Context-Modelle verdrängen RAG aus Enterprise-Anwendungsfällen

Retrieval-augmented generation wurde aus einem einfachen Grund zur Standardarchitektur für Enterprise-KI-Anwendungen: Frühe Context Windows waren zu klein, um die Wissensbasis einer Organisation aufzunehmen, also musste man die relevanten Chunks abrufen und nur diese dem Modell zuführen. Diese Einschränkung hat sich erheblich gelockert. Frontier-Modelle verfügen heute über Context Windows von über einer Million Tokens – genug, um Hunderte vollständiger Dokumente, ganze Codebasen oder Jahre an Kundensupport-Tickets in einem einzigen Prompt zu halten. Engineering-Teams, die interne Tools bauen, stellen zunehmend eine pointierte Frage: Wenn das Modell einfach alles lesen kann, warum dann überhaupt eine Retrieval-Pipeline aufrechterhalten?

Warum Teams RAG aufgeben

Die Argumente gegen RAG drehten sich schon immer um Fehlermodi, die schwer zu debuggen sind. Die Chunking-Strategie entscheidet darüber, ob ein Dokument so aufgeteilt wird, dass die Bedeutung erhalten bleibt oder zerstört wird – eine Tabelle, die über zwei Chunks verteilt wird, ist für das Embedding-Modell und den Retriever gleichermaßen unlesbar. Embedding-Drift bedeutet, dass ein auf einen bestimmten Query-Typ abgestimmtes Retrieval-System stillschweigend an Qualität verliert, wenn sich die zugrunde liegenden Daten oder Query-Muster verschieben – oft ohne offensichtliches Signal, dass dies geschieht. Und Retrieval selbst ist ein probabilistischer Schritt: Die von einer Vektorsuche zurückgegebenen Top-k-Chunks sind nicht garantiert diejenigen, die die tatsächliche Antwort enthalten, was bedeutet, dass RAG-Systeme auf eine Weise versagen, die schwer zu diagnostizieren ist, weil der Fehler vorgelagert zur eigentlichen Antwortgenerierung des Modells auftritt.

Long-Context-Ansätze umgehen all dies. Wenn das gesamte relevante Korpus in den Prompt passt, gibt es keine Chunking-Entscheidung, die man falsch treffen kann, keinen Retrieval-Schritt, der stillschweigend unterperformt, und kein Embedding-Modell, das gewartet oder Fine-tuning benötigt. Für eine mittelgroße Wissensbasis – die Dokumentation eines Produkts, die Vertragsbibliothek einer Rechtsabteilung, das interne Wiki eines Engineering-Teams – ist das Einfügen des gesamten Inhalts in den Context und das Überlassen der Relevanzfindung dem Attention-Mechanismus des Modells inzwischen ernsthaft konkurrenzfähig mit einer gut abgestimmten RAG-Pipeline und aus Engineering-Sicht erheblich günstiger zu bauen und zu warten.

Wo RAG immer noch gewinnt

Der Wandel ist real, aber nicht universell, und die Fälle, in denen RAG die bessere Architektur bleibt, sind konkret statt vage. Erstens, Skalierung: Ein Korpus mit Zehntausenden von Dokumenten oder mehr übersteigt selbst die größten Context Windows, und kein noch so großes Context-Window-Wachstum ändert diese Rechnung für wirklich große Wissensbasen. Zweitens, Kosten bei Volumen: Die Verarbeitung von einer Million Tokens bei jeder einzelnen Query kostet – selbst mit Prompt-Caching – deutlich mehr als das Abrufen einiger tausend relevanter Tokens, und dieser Unterschied summiert sich schnell über Millionen von Queries in einer Produktionsanwendung. Drittens, Aktualität: RAG-Systeme mit einer Vektordatenbank können neu indexierte Inhalte innerhalb von Sekunden integrieren, während Long-Context-Ansätze erfordern, aktualisierte Dokumente in jeden nachfolgenden Prompt erneut aufzunehmen, was bei häufig wechselndem Korpus unhandlich wird. Viertens, Multi-Tenancy: Anwendungen, die vielen Kunden mit strengen Datenisolationsanforderungen dienen, benötigen oft Retrieval-Systeme, die Zugriffsgrenzen auf Chunk-Ebene durchsetzen können – etwas, das schwerer sauber zu garantieren ist, wenn ein gesamter Dokumentensatz in einem gemeinsamen Context liegt.

Das aufkommende Hybrid-Muster

Die Architektur, die in Produktionssystemen an Bedeutung gewinnt, ist keine binäre Entscheidung, sondern ein abgestufter Ansatz. Teams verwenden Long-Context-Stuffing für den „heißen" Teil ihrer Wissensbasis – häufig abgerufene, relativ stabile Dokumente – während sie eine Retrieval-Schicht für den Long Tail seltener abgerufener oder sich schnell ändernder Inhalte beibehalten. Einige Systeme nutzen Retrieval nun als groben ersten Durchgang, um auszuwählen, welche vollständigen Dokumente in den Context aufgenommen werden sollen, statt kleine Chunks abzurufen – effektiv nutzen sie RAGs Auswahlmechanismus auf Dokumentebene, während sie die Fragmentierung auf Chunk-Ebene vollständig vermeiden. Dieses Hybrid-Muster erfasst einen Großteil des Zuverlässigkeitsvorteils von Long-Context, während es die Kosten- und Skalierungseigenschaften beibehält, die RAG ursprünglich notwendig gemacht haben.

Wie man tatsächlich entscheidet

Beginnen Sie damit, Ihr Korpus gegen das effektive Context Window Ihres Modells zu bemessen – und berücksichtigen Sie dabei, dass die Modellleistung bei Needle-in-a-Haystack-Retrieval-Aufgaben abnimmt, je näher Sie an das angegebene Context-Limit kommen: Ein Modell, das für zwei Millionen Tokens ausgelegt ist, nutzt nicht zuverlässig alle zwei Millionen Tokens gleich gut. Wenn Ihr Korpus bequem in dieses effektive Fenster passt und sich selten ändert, ist Long-Context-Stuffing wahrscheinlich einfacher und zuverlässiger zu bauen. Wenn Ihr Korpus groß ist, sich häufig ändert oder eine granulare Zugriffskontrolle pro Benutzer erfordert, ist eine Retrieval-Schicht weiterhin die richtige Wahl, und die Engineering-Investition in hochwertiges Chunking und Retrieval bleibt lohnenswert. Die Teams, die hier die besten Entscheidungen treffen, sind diejenigen, die aufgehört haben, RAG als Standard zu behandeln, und es als eine Option unter mehreren betrachten – ausgewählt auf Basis der tatsächlichen Korpusgröße, Aktualisierungshäufigkeit und Kostenbeschränkungen statt aus architektonischer Gewohnheit.