Was ist RAG? Retrieval-Augmented Generation erklärt

Retrieval-Augmented Generation (RAG) ist ein Verfahren, bei dem ein System einen externen Dokumentenindex nach relevanten Passagen durchsucht und diese an ein Sprachmodell übergibt, bevor es eine Antwort erzeugt. Statt sich allein auf die beim Training festgelegten Gewichte zu verlassen, kann das Modell anhand privater, interner oder kürzlich aktualisierter Informationen antworten.

Ein gewöhnliches Sprachmodell kennt nur die Daten, mit denen es bis zu seinem Stichtag trainiert wurde. Fragt ein Nutzer nach der internen Erstattungsrichtlinie Ihres Unternehmens, einer neu veröffentlichten API-Spezifikation oder einem vor fünf Minuten aktualisierten Kontodatensatz, kann das Basismodell die Antwort nicht allein aus seinem Gedächtnis kennen. RAG schließt diese Lücke, indem es einen Suchschritt mit der Generierung verbindet: Erst werden die relevanten Fakten abgerufen, dann wird eine auf dem abgerufenen Text beruhende Antwort erzeugt.

Was bedeutet Retrieval-Augmented Generation?

Retrieval-Augmented Generation bezeichnet die Verbindung eines Informationssuchsystems mit einem Textgenerierungsmodell, sodass abgerufene externe Dokumente zum Zeitpunkt der Anfrage in die Ausgabe einfließen. Statt zu erwarten, dass ein neuronales Netz jeden Fakt in seinen Parametern speichert, behandelt RAG einen externen Textindex wie ein offenes Buch, in dem das Modell vor seiner Antwort nachschlagen kann.

Grundsätzlich umfasst jeder RAG-Ablauf zwei Kernphasen:

1. Abrufen: Wenn ein Nutzer einen Prompt eingibt, wandelt das System die Anfrage in eine Suche in einem externen Datenspeicher um – etwa in einer Vektordatenbank, einem Stichwortsuchindex oder einer Kombination aus beiden – und ruft die relevantesten Textpassagen ab.
2. Generieren: Das System fügt die abgerufenen Passagen zusammen mit der ursprünglichen Frage des Nutzers in den Kontext des Modells ein. Das Sprachmodell erzeugt anhand dieser Passagen eine Antwort.

Da der Referenztext für jede Anfrage dynamisch abgerufen wird, lässt sich das Wissen des Systems durch Aktualisieren des Dokumentenindex ändern, ohne das zugrunde liegende Modell erneut zu trainieren. Deshalb ist RAG ein gängiges Verfahren für Support-Assistenten, die Suche in interner Dokumentation und fachspezifische Frage-Antwort-Tools. Daneben gibt es kreative Anwendungen, bei denen Teams spezielle Workflow-Tools wie AI Studio Video für die Medienproduktion und Text-APIs für den Wissensabruf nutzen.

Wie unterschied sich die RAG-Publikation von 2020 vom heutigen RAG-Verfahren?

Der Begriff „Retrieval-Augmented Generation“ stammt aus einer Veröffentlichung von Patrick Lewis und Kollegen aus dem Jahr 2020 (arXiv:2005.11401). Darin wurde ein vortrainiertes Sequence-to-Sequence-Modell mit einem dichten Vektorindex von Wikipedia kombiniert. Heute bezeichnen Entwickler damit meist eine einfachere Pipeline zur Erstellung von Prompts. Wer beide Ansätze versteht, erkennt, warum „RAG“ in Forschungsarbeiten und technischen Dokumentationen etwas unterschiedlich beschrieben wird.

Die Architektur von Lewis et al. aus dem Jahr 2020

In der ursprünglichen Veröffentlichung von 2020 und dem begleitenden Forschungsbeitrag von Meta AI beschrieben die Autoren Sprachmodelle als Systeme mit zwei Arten von Gedächtnis:

• Parametrisches Gedächtnis: Wissen in den Gewichten des neuronalen Netzes, konkret eines vortrainierten BART-Sequence-to-Sequence-Modells.
• Nichtparametrisches Gedächtnis: Wissen in einem externen dichten Vektorindex von Wikipedia-Artikeln, der mit einem neuronalen Retriever namens Dense Passage Retrieval (DPR) abgefragt wird.

In diesem Forschungsaufbau wurden Retriever und Generator gemeinsam Ende zu Ende trainiert. Die Veröffentlichung stellte zwei Varianten vor, wie abgerufene Passagen die Generierung beeinflussen:

• RAG-Sequence: Das Modell verwendet dieselben abgerufenen Passagen, um die gesamte Ausgabesequenz zu erzeugen.
• RAG-Token: Das Modell kann für jedes erzeugte Token auf unterschiedliche abgerufene Passagen zurückgreifen.

Bei den in den Tabellen der Veröffentlichung angegebenen Benchmarks für offene Fragebeantwortung (arXiv:2005.11401) erreichte RAG-Sequence im Natural Questions-Benchmark einen Wert von 44.5 Exact Match. Damit übertraf es sowohl die rein parametrischen Seq2seq-Vergleichsmodelle als auch die im Rahmen der Studie getesteten Architekturen zum Abrufen und Extrahieren.

Das heutige technische Verfahren

In der modernen Anwendungsentwicklung trainieren Teams Retriever und Generator nur selten gemeinsam. Stattdessen bezeichnet „RAG“ fast immer eine Pipeline zur Inferenz, die auf sofort einsetzbaren Embedding-Modellen und universellen LLM-APIs aufbaut:

1. Dokumente in kleinere Passagen (Chunks) aufteilen.
2. Diese Chunks in Vektor-Embeddings umwandeln und in einem Index speichern.
3. Bei einer Anfrage die am besten passenden Chunks abrufen.
4. Die Ergebnisse optional für eine höhere Relevanz neu ordnen.
5. Die abgerufenen Text-Chunks direkt in den Prompt einfügen und das LLM um eine Antwort bitten.

Sowohl die neuronale Ende-zu-Ende-Architektur von 2020 als auch die heutige Pipeline, die Text in Prompts einfügt, heißen RAG. Im technischen Alltag ist damit das moderne Pipeline-Verfahren gemeint, sofern nicht ausdrücklich das Training eines Retrievers mit einem Seq2seq-Modell erwähnt wird.

Wie funktioniert eine moderne RAG-Pipeline Schritt für Schritt?

Ein produktives RAG-System teilt seine Arbeit in zwei getrennte Abläufe: eine offline ausgeführte Ingestion-Pipeline, die Dokumente vorbereitet und indexiert, und eine online ausgeführte Abfrage-Pipeline, die bei jeder Nutzerfrage läuft. Architekturleitfäden wie die RAG-Anleitung von AWS und der RAG-Leitfaden des AWS Generative AI Innovation Center zerlegen diese Phasen in einzelne Komponenten, die sich unabhängig voneinander optimieren lassen.

1. Die Ingestion-Pipeline (Daten indexieren)

Bevor ein Nutzer einen Prompt sendet, muss das System die Quelldokumente durchsuchbar machen:

• Dokumente laden und bereinigen: Klartext und Metadaten (Titel, URLs, Zeitstempel, Zugriffsrechte) aus PDFs, Wikis, Datenbanken oder Markdown-Dateien extrahieren und fehlerhafte Formatierung oder wiederkehrende Seitenelemente entfernen.
• Chunking: Lange Dokumente in kleinere Abschnitte zerlegen, damit nur relevante Passagen statt ganzer Handbücher abgerufen werden. Sind Chunks zu klein, verlieren sie den umgebenden Kontext und brechen Gedanken ab; sind sie zu groß, bringen sie irrelevantes Rauschen mit und erhöhen den Tokenverbrauch. Teams lassen benachbarte Chunks häufig leicht überlappen, damit Sätze an den Grenzen ihre Bedeutung behalten.
• Embedding: Jeden Chunk durch ein Embedding-Modell verarbeiten, das seinen Text in einen dichten numerischen Vektor umwandelt, der seine semantische Bedeutung darstellt.
• Indexierung: Diese Vektoren zusammen mit Rohtext und Metadatenfiltern in einer Vektordatenbank oder einer hybriden Suchmaschine speichern, die Vektorähnlichkeit mit Stichwortsuche kombiniert (etwa BM25).

2. Die Abfrage-Pipeline (Fragen beantworten)

Wenn ein Nutzer zur Laufzeit eine Frage stellt, stellt die Abfrage-Pipeline den Prompt zusammen:

• Abfrageverarbeitung und Embedding: Die Nutzereingabe übernehmen, optional zur besseren Verständlichkeit umformulieren oder erweitern und mit genau demselben Embedding-Modell wie bei der Ingestion in einen Vektor umwandeln.
• Abruf: Im Index nach Chunks suchen, deren Vektoren dem Abfragevektor am nächsten liegen. Häufig werden semantische Suche, Stichwortsuche und Metadatenfilter kombiniert, etwa um Ergebnisse auf Dokumente zu beschränken, die der aktuelle Nutzer lesen darf.
• Optionale Neuordnung: Die zunächst gefundenen Chunks durch ein Cross-Encoder-Reranker-Modell verarbeiten lassen. Es bewertet, wie direkt jede Passage die konkrete Frage beantwortet, und reduziert die Liste auf die besten Treffer.
• Prompt-Zusammenstellung und Generierung: Die höchstplatzierten Passagen zusammen mit der Nutzerfrage in eine strukturierte Prompt-Vorlage einfügen, die gesamte Eingabe an das LLM senden und die erzeugte Antwort zurückgeben, häufig mit Quellenangaben aus den Metadaten.

Wie schneidet RAG im Vergleich zu langen Kontextfenstern und Fine-Tuning ab?

RAG, lange Kontextfenster und Fine-Tuning lösen unterschiedliche Teile der Modellanpassung. Produktive Systeme kombinieren sie häufig, statt sie als einander ausschließende Optionen zu betrachten. Die richtige Wahl hängt davon ab, ob dynamische Fakten, das Verständnis großer Textmengen in einer Sitzung oder Änderungen am Modellverhalten benötigt werden.

Dimension	Retrieval-Augmented Generation (RAG)	Langes Kontextfenster	Fine-Tuning
Hauptziel	Für jede Anfrage relevante Fakten aus einem großen oder sich ändernden Korpus liefern	Das Modell bei einer Anfrage eine große Textmenge lesen lassen	Stil, Ton, Formatierung oder Verhalten bei spezialisierten Aufgaben ändern
Wissensaktualisierung	Dokumente im externen Index aktualisieren oder austauschen	Die in den Prompt eingefügten Rohdokumente austauschen	Neue Trainingsbeispiele sammeln und einen weiteren Trainingslauf durchführen
Tokenauswirkung pro Anfrage	Niedrig bis mittel (nur abgerufene Chunks werden gesendet)	Hoch (jedes Dokument bleibt in der Prompt-Eingabe)	Niedrig (Wissen oder Verhalten ist in den Modellgewichten verankert)
Quellenangabe	Bestimmte abgerufene Chunks lassen sich einfach zitieren	Möglich, bei sehr großen Eingaben aber schwerer genau zuzuordnen	Schwierig; Gewichte enthalten keine ausdrücklichen Dokumentverweise
Zugriffskontrolle	Pro Anfrage über Metadatenfilter im Index durchgesetzt	Muss vor dem Zusammenstellen des Prompts gefiltert werden	Schwer abzugrenzen; alles in den Gewichten kann jedem Nutzer offengelegt werden

RAG vs. lange Kontextfenster

Da moderne Modelle große Kontextfenster unterstützen, ist es verlockend, auf den Abruf zu verzichten und die gesamte Wissensbasis in jeden Prompt einzufügen. Für einige wenige kurze Dokumente funktioniert das gut – besonders zusammen mit Prompt-Caching und einem bereits gefüllten KV cache, damit wiederkehrende Präfixe nicht jedes Mal neu verarbeitet werden müssen.

Wächst der Korpus jedoch auf Tausende Dateien, stößt das Einfügen aller Inhalte in den Prompt an zwei Grenzen:

1. Kosten und Latenz: Riesige Prompts bei jeder Interaktion erhöhen API-Kosten und die Zeit bis zum ersten Token. Deshalb bleibt selektiver Abruf eine zentrale Strategie, wenn es darum geht, KI-API-Kosten zu senken.
2. Nachlassende Aufmerksamkeit: Modelle beachten nicht jeden Teil eines riesigen Prompts gleichermaßen gut. Mit zunehmendem irrelevantem Text im Fenster sinkt oft die Genauigkeit – ein Phänomen namens Context Rot. RAG hält den Prompt fokussiert, indem nur die für die aktuelle Frage wichtigen Passagen abgerufen werden.

RAG vs. Fine-Tuning

Fine-Tuning aktualisiert die Gewichte eines Modells anhand ausgewählter Beispiele. Es ist wirksam, wenn ein Modell einem strengen Ausgabeschema folgen, eine bestimmte Markenstimme annehmen oder fachspezifische Syntax erlernen soll. Schnell wechselnde Fakten lassen sich damit schlecht vermitteln.

Die Veröffentlichung von Lewis et al. aus dem Jahr 2020 (arXiv:2005.11401) zeigte mit einem Experiment zum Austausch des Index, warum nichtparametrisches Gedächtnis für sich ändernde Fakten wichtig ist. Die Autoren testeten ihr Modell mit einem Wikipedia-Dump vom Dezember 2016 und einem vom Dezember 2018 anhand von Fragen zu Staats- und Regierungschefs, die zwischen diesen Zeitpunkten gewechselt hatten:

• Stimmte das Jahr der Frage mit dem Indexjahr überein, beantwortete das Modell mit dem Index von 2016 70% der Fragen zu Staats- und Regierungschefs von 2016 richtig und mit dem Index von 2018 68% der Fragen zu denen von 2018.
• Passte der Index nicht zu den Fragen, fiel die Genauigkeit auf 12% (Index von 2018 für Staats- und Regierungschefs von 2016) beziehungsweise 4% (Index von 2016 für diejenigen von 2018).

Allein der Austausch des externen Index aktualisierte das Faktenwissen des Systems über die Welt, ohne ein einziges Modellgewicht erneut zu trainieren.

Wo versagt RAG?

Der zusätzliche Abruf reduziert das Raten eines Sprachmodells bei privaten oder aktuellen Themen, beseitigt aber weder KI-Halluzinationen noch garantiert er korrekte Antworten. Da ein RAG-System mehrere Komponenten hat, können Fehler sowohl bei der Suche als auch bei der Generierung auftreten:

• Übersehene Treffer: Formuliert ein Nutzer eine Frage mit anderen Begriffen als im Quelldokument oder wurde beim Chunking eine Tabelle von ihrer Überschrift getrennt, findet der Retriever möglicherweise die Passage mit der Antwort nicht. Gelangt der richtige Chunk nie in den Prompt, fehlt dem Modell die Grundlage.
• Störende oder veraltete Dokumente: Ein Index ist nur so gut wie seine Dateien. Enthält die Wissensbasis die Versionen 2023 und 2026 einer Einarbeitungsanleitung ohne klare Filterung veralteter Versionen, gibt der Retriever dem Modell unter Umständen überholte Anweisungen.
• Zu viele Treffer: 25 Chunks „für alle Fälle“ abzurufen, ist oft kontraproduktiv. Viele nur am Rande relevante Passagen verwässern die eigentliche Antwort, erhöhen die Latenz und können Context Rot auslösen, bei dem das Modell von beinahe passenden Details abgelenkt wird.
• Indirekte Prompt Injection über abgerufenen Text: Nimmt der Index nicht vertrauenswürdige externe Inhalte auf, etwa eingehende E-Mails, öffentliche Webseiten oder von Nutzern eingereichte Tickets, können Angreifer schädliche Anweisungen in einem Dokument platzieren. Wird dieses Dokument abgerufen und in den Prompt eingefügt, kann es einen Prompt-Injection-Angriff auslösen, der das Modellverhalten kapert.
• Ignorierter oder falsch gelesener Kontext: Selbst wenn genau die richtige Passage im Prompt steht, kann der Generator eine Verneinung falsch verstehen, zwei getrennte Chunks fehlerhaft vermischen oder sein Vorwissen aus dem Training über den bereitgestellten Text stellen, wenn die abgerufene Passage allgemeinem Wissen widerspricht.

Checkliste für ein zuverlässiges RAG-System

Beim Übergang eines RAG-Prototyps in die Produktion verhindern einige disziplinierte technische Vorgehensweisen die häufigsten Fehler:

• Index aktuell und frei von Duplikaten halten: Automatisierte Pipelines erstellen, die gelöschte Dokumente entfernen, ersetzte Versionen archivieren und jedem indexierten Chunk eindeutige Zeitstempel und Quell-URLs zuweisen.
• Weniger, aber bessere Treffer abrufen: Statt Dutzende schwacher Treffer in den Prompt einzufügen, hybride Suche (Vektor + Stichwort) mit Metadatenfiltern und einem Reranker kombinieren, sodass nur wenige aussagekräftige Passagen an den Generator gelangen.
• Nicht vertrauenswürdigen abgerufenen Text klar von Systemanweisungen trennen: Abgerufene Chunks mit ausdrücklichen strukturellen Trennzeichen umgeben, etwa XML-Tags oder gekennzeichneten Dokumentblöcken, und im System-Prompt festlegen, dass diese Blöcke ausschließlich passive Referenzdaten und niemals ausführbare Befehle sind.
• Das Modell bei fehlendem Kontext zum Verzicht anweisen: Das Modell soll klar sagen, wenn die bereitgestellten Passagen nicht genug Informationen für eine Antwort enthalten. Eine Prompt-Anweisung garantiert nicht, dass das Modell immer folgt, bietet ihm aber eine klarere Alternative zum stillen Raten, wenn der Abruf keine Treffer liefert.

Häufig gestellte Fragen

Braucht man für RAG immer eine Vektordatenbank?

Nein. Retrieval-Augmented Generation benötigt lediglich eine Möglichkeit, vor dem Modellaufruf relevante Texte abzurufen. Vektordatenbanken sind zwar für die semantische Ähnlichkeitssuche beliebt, doch viele produktive RAG-Systeme verwenden herkömmliche Stichwortsuchmaschinen (wie BM25 in Elasticsearch oder die Volltextsuche von PostgreSQL) oder eine hybride Suche, die Stichwort- und Vektorsuche kombiniert.

Kann RAG Halluzinationen eines LLM vollständig verhindern?

Nein. RAG reduziert Halluzinationen durch fehlende oder veraltete Trainingsdaten, weil es dem Modell den Referenztext direkt im Prompt liefert. Dennoch kann das Modell eine Passage falsch lesen, Fakten aus zwei nicht zusammengehörigen Chunks falsch kombinieren oder eine Antwort erraten, wenn der Retriever irrelevante Dokumente liefert.

Sollte ich für interne Unternehmensdokumente RAG oder Fine-Tuning verwenden?

Beginnen Sie mit RAG, wenn ein Modell Fragen zu internen Dokumenten beantworten soll, die sich mit der Zeit ändern. Mit RAG können Sie Dateien im Index sofort hinzufügen, bearbeiten oder löschen und bei jeder Anfrage individuelle Zugriffsrechte durchsetzen. Fine-Tuning eignet sich dagegen besser, um einheitliche Formatierung, Tonalität oder Aufgabenabläufe zu vermitteln.

Quellen

• Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — arXiv:2005.11401
• Meta AI Research Blog — Retrieval-Augmented Generation: Streamlining the creation of intelligent natural language processing models
• AWS Prescriptive Guidance — Understanding LLMs and RAG
• AWS Machine Learning Blog — From RAG to fabric: Lessons learned from building real-world RAGs at GenAIIC – Part 1