Retrieval-Augmented Generation (RAG)

Was ist Retrieval-Augmented Generation (RAG)?

Retrieval-Augmented Generation (RAG) ist eine Architektur, die zur Anfragezeit eine Wissensquelle nach für die Anfrage relevanten Dokumenten durchsucht und diese in den Prompt des Modells einfügt, sodass die Antwort auf abgerufenen Belegen beruht statt nur auf dem, was das Modell während des Trainings memoriert hat. Sie verschafft Modellen Zugriff auf private, aktuelle und überprüfbare Informationen. Der Name geht auf ein NeurIPS-Paper von Lewis et al. bei Meta AI aus dem Jahr 2020 zurück, das bei drei Open-Domain-Frage-Antwort-Aufgaben den Stand der Technik setzte und Sprache erzeugte, die die Autoren als spezifischer, vielfältiger und faktentreuer maßen als eine rein parametrische Baseline [1].

Die wichtigsten Punkte

• RAG trennt Wissen vom Modell. Der Korpus lässt sich aktualisieren, auditieren und mit Berechtigungen versehen, ohne das Modell anzufassen – etwas, das im Training verankertes Wissen nie erlaubt.
• Die Antwortqualität wird durch die Retrieval-Qualität begrenzt. Erreicht die richtige Textstelle den Prompt nie, kann keine noch so große Modellfähigkeit das ausgleichen.
• Die Verankerung von Antworten in abgerufenem Text reduziert Halluzinationen und ermöglicht Zitate, beseitigt Fehler aber nicht vollständig: Modelle können ihre Quellen weiterhin falsch lesen oder über sie hinausgehen.
• Das Muster der 2026er-Ära ist zunehmend agentisches RAG, bei dem das Modell die Suche iterativ mit Tools selbst steuert, statt eine einzige feste Charge von Chunks zu erhalten.

So funktioniert es

Ein RAG-System hat eine Offline- und eine Online-Hälfte. Offline werden Dokumente in Chunks zerlegt, jeder Chunk wird in ein Vektor-Embedding umgewandelt, das seine Bedeutung kodiert, und die Vektoren wandern zusammen mit dem Text in eine Vektordatenbank. Online wird eine eingehende Anfrage auf die gleiche Weise eingebettet, die Datenbank liefert die Chunks zurück, deren Vektoren der Anfrage am nächsten liegen, und diese Chunks werden zusammen mit der Anweisung, aus dem bereitgestellten Material zu antworten, in den Prompt gepackt. Hier übernimmt semantische Suche das Abrufen und das Sprachmodell das Lesen und Schreiben.

Produktivsysteme legen Verfeinerungen über dieses Grundgerüst. Hybrides Retrieval kombiniert Vektor-Ähnlichkeit mit klassischer Keyword-Bewertung, da exakte Bezeichner und seltene Begriffe reine Embeddings ins Straucheln bringen. Ein Reranker bewertet die besten Kandidaten mit einem teureren Modell neu, bevor die finale Auswahl getroffen wird. Query Rewriting erweitert knappe Fragen, Metadaten-Filter setzen Dokumentberechtigungen pro Nutzer durch, und die Chunking-Strategie – Größen, Überlappungen und die Berücksichtigung der Dokumentstruktur – bestimmt still einen Großteil der erreichbaren Obergrenze. Antworten zitieren üblicherweise, aus welchen Chunks sie stammen, was Nutzern eine Möglichkeit zur Verifikation gibt – die KI-Grounding-Eigenschaft, die RAG für alles Kundenorientierte attraktiv macht. Diese Attraktivität zeigt sich in Adoptionsdaten: Eine Umfrage von Menlo Ventures aus dem Jahr 2024 unter 600 US-amerikanischen Enterprise-IT-Entscheidern fand RAG in 51 % der Enterprise-LLM-Architekturen vor, gegenüber 31 % im Jahr zuvor [2].

Die sich verschiebende Grenze verläuft entlang der Frage, wer das Retrieval kontrolliert. Klassisches RAG ruft einmal ab, vor der Generierung, mit festen Parametern. Agentisches RAG gibt dem Modell ein Such-Tool an die Hand und lässt es wiederholt abfragen, umformulieren, Referenzen verfolgen und selbst entscheiden, wann genug Belege vorliegen. Lange Kontextfenster haben keines von beidem überflüssig gemacht: Korpora im Gigabyte-Bereich lassen sich weiterhin nicht komplett einbetten, und Retrieval bleibt der Kosten- und Relevanzfilter, der entscheidet, was diese Kontext-Token verdient.

Beispiel

Ein B2B-Softwareunternehmen baut einen Support-Assistenten auf Basis von 4.000 Help-Center-Artikeln, Release Notes und internen Runbooks. Die Pipeline zerlegt Dokumente abschnittsweise in Chunks, bettet sie ein und speichert sie mit Produktversions-Metadaten. Fragt ein Kunde "warum funktioniert SSO nach dem März-Update nicht mehr", bettet das System die Frage ein, filtert nach der Produktversion des Kunden, ruft die acht besten Chunks ab, rerankt sie auf drei und weist das Modell an, nur aus diesen Passagen mit verlinkten Zitaten zu antworten. Das Modell liefert eine Breaking Change aus den Release Notes sowie die Migrationsschritte aus einem Runbook. Wenn das Team Fixes ausliefert, indiziert es die geänderten Artikel noch in derselben Nacht neu, und der Assistent ist am nächsten Morgen aktuell – ganz ohne Modelländerungen.

Häufige Missverständnisse

Der hartnäckige Fehler besteht darin, RAG als Versicherung gegen Halluzination zu behandeln. Retrieval schränkt den Raum für Erfindungen ein, aber das Modell kann abgerufene Fakten weiterhin falsch kombinieren, über das hinausgehen, was die Quellen hergeben, oder sich auf parametrisches Wissen verlassen, wenn das Retrieval mager ausfällt. Schlimmer noch: Schwaches Retrieval erzeugt selbstbewusst zitierten Unsinn, da die Zitate auf Chunks verweisen, die die Behauptung nie enthielten. Vertrauenswürdiges RAG braucht Evals für beide Hälften: Retrieval-Metriken dafür, ob die richtigen Belege ankamen, und Groundedness-Prüfungen dafür, ob die Antwort tatsächlich innerhalb dieser Belege geblieben ist.

FAQ

Was bedeutet RAG im Kontext eines LLM? Ein "RAG-LLM"-Aufbau ist schlicht ein Sprachmodell, das mit einem Retrieval-Schritt verdrahtet ist: Zuerst läuft die Suche, die Ergebnisse wandern in den Prompt, und das Modell antwortet auf dieser Basis. Das Modell selbst bleibt unverändert; RAG beschreibt die umgebende Architektur, nicht eine besondere Art von Modell.

Ist RAG besser als Fine-Tuning? Sie lösen unterschiedliche Probleme. Retrieval-Augmented Generation ist das richtige Werkzeug, um Fakten einzuspeisen, insbesondere solche, die sich ändern, pro Kunde unterschiedlich sind oder Zitate benötigen. Fine-Tuning ist das richtige Werkzeug, um Verhalten, Stil oder Aufgabenformate beizubringen. Ausgereifte Systeme nutzen oft beides: ein fein abgestimmtes Modell, das abgerufenen Kontext liest.

Machen lange Kontextfenster RAG überflüssig? Nein. Selbst Fenster mit Millionen von Token können keinen ernsthaften Korpus fassen, Attention verschlechtert sich bei sehr langen Eingaben, und einen vollständigen Korpus bei jeder Anfrage zu bezahlen, ist wirtschaftlich absurd. Lange Kontexte haben das Retrieval-Budget verändert und erlauben es Systemen, größere und dafür weniger Chunks zu übergeben – die Notwendigkeit des Retrievals heben sie nicht auf.

Quellen

1. Lewis et al., Meta AI. "Ergebnisse des ursprünglichen RAG-Papers zu Open-Domain-Frage-Antwort-Aufgaben." https://arxiv.org/abs/2005.11401. Abgerufen im August 2026.
2. Menlo Ventures. "RAG-Adoption in Enterprise-LLM-Architekturen, 2024 gegenüber 2023." https://menlovc.com/2024-the-state-of-generative-ai-in-the-enterprise/. Abgerufen im August 2026.