Was ist RAG? Retrieval-Augmented Generation verständlich erklärt

Was ist RAG?

Retrieval-Augmented Generation (RAG) bezeichnet eine Systemarchitektur, bei der ein Sprachmodell vor dem Antworten gezielt Informationen aus einer externen Wissensbasis abruft und diese abgerufenen Inhalte in seine Eingabe aufnimmt. Der Begriff geht auf eine Arbeit von Lewis et al. (2020) zurück, die ein vortrainiertes Sprachmodell mit einem nicht-parametrischen Speicher – einem durchsuchbaren Dokumentindex – kombinierte.

Der Grundgedanke: Ein Sprachmodell trägt sein Wissen in den Modellgewichten (parametrisches Wissen). Dieses Wissen ist zum Trainingszeitpunkt eingefroren, lückenhaft und nicht quellenbelegt. RAG ergänzt es um nicht-parametrisches Wissen – Dokumente, die zur Laufzeit durchsucht und dem Modell mitgegeben werden. So kann eine Anwendung auf firmeneigene, fachspezifische oder aktuelle Inhalte zugreifen, für die das Modell nie trainiert wurde.

Die drei Bausteine: Retrieval, Augmentation, Generation

Der Name benennt die drei Schritte:

Jeder Schritt kann eigenständig gut oder schlecht funktionieren. Ein starkes Sprachmodell rettet keinen schlechten Abruf, und ein perfekter Abruf garantiert keine korrekte Antwort. Diese Trennung ist für Diagnose und Evaluation entscheidend (siehe unten).

Was RAG nicht ist

Rund um RAG kursieren mehrere Verkürzungen. Zur sauberen Einordnung gehört, RAG von benachbarten Begriffen abzugrenzen:

Die zwei Phasen einer RAG-Pipeline

Eine RAG-Anwendung besteht aus zwei zeitlich getrennten Phasen. Die Indexierung läuft vorab und wiederkehrend („offline"): Dokumente werden gelesen, zerlegt, aufbereitet und in einen durchsuchbaren Index geschrieben. Die Anfrage läuft pro Nutzerfrage („online"): Die Frage wird verarbeitet, passende Stellen werden gesucht, optional neu sortiert, dem Modell übergeben und beantwortet.

Aufbereiten: Parsing, Chunking und Metadaten

Die Qualität eines RAG-Systems entscheidet sich oft schon in der Indexierung. Parsing wandelt Quelldateien (PDF, HTML, Office-Dokumente, Tabellen) in bereinigten Text um – fehlerhaftes Parsing von Tabellen, Spalten oder Fußnoten erzeugt unbrauchbare Grundlagen. Chunking zerlegt lange Dokumente in Abschnitte, die einzeln gesucht und übergeben werden können.

Chunking ist ein Optimierungsproblem ohne universelle Lösung: feste Tokenzahl, Absätze, Überschriftenabschnitte, semantische Segmentierung oder überlappende Fenster sind mögliche Strategien. Zu kleine Chunks verlieren Kontext, zu große vermischen Themen und verwässern die relevante Stelle. Es gibt keine allgemeingültige Chunk-Größe und keinen allgemeingültigen Top-k-Wert – beides muss an den eigenen Daten evaluiert werden.

Retrieval: BM25, Dense und Hybrid

Das Retrieval ist der Kern von RAG. Es gibt nicht „die eine" Suche, sondern mehrere Ansätze mit unterschiedlichen Stärken:

BM25 ist ein etabliertes lexikalisches Rankingverfahren (Robertson & Zaragoza) und gerade bei exakten Begriffen oft überraschend stark. Dense Retrieval nutzt Embeddings und findet inhaltlich Verwandtes auch bei anderer Wortwahl – Karpukhin et al. zeigten mit Dense Passage Retrieval (DPR), dass gelernte Vektoren klassische Verfahren bei offenen Fragen deutlich schlagen können. Hybrid Search kombiniert beide Signale und ist häufig robust, aber nicht automatisch immer besser. Welcher Ansatz passt, hängt von Daten, Sprache und Anwendungsfall ab.

Reranking und Late Interaction

Die erste Suchstufe liefert schnell viele Kandidaten, aber grob sortiert. Ein Reranker bewertet danach eine kleinere Kandidatenmenge genauer. Häufig kommt ein Cross-Encoder zum Einsatz, der Frage und Passage gemeinsam liest und so die Relevanz präziser einschätzt als die schnelle Vektorähnlichkeit (Nogueira & Cho demonstrierten Passage-Reranking mit BERT). Cross-Encoder sind genauer, aber rechenintensiver – deshalb bewerten sie nur die Top-Kandidaten, nicht den ganzen Index.

Late Interaction (z. B. ColBERT, Khattab & Zaharia) ist ein Mittelweg: Statt eines einzigen Vektors pro Text werden mehrere Token-Vektoren verglichen. Das erhöht die Genauigkeit gegenüber Single-Vector-Retrieval, benötigt aber mehr Speicher.

Contextual Retrieval

Ein bekanntes Chunking-Problem: Ein isolierter Abschnitt verliert seinen Bezug. „Der Umsatz stieg um 3 %" ist ohne Angabe von Unternehmen und Zeitraum kaum auffindbar und kaum belastbar. Contextual Retrieval (von Anthropic beschrieben) begegnet dem, indem jedem Chunk vor der Indexierung ein kurzer, automatisch erzeugter Kontext vorangestellt wird, der ihn im Gesamtdokument verortet. Laut Anthropics eigener Darstellung sinkt dadurch die Fehlerrate beim Abruf deutlich; solche Zahlen stammen von den jeweiligen Anbietern und sollten als deren Angaben behandelt und am eigenen Datensatz überprüft werden.

Augmentation und Generation

In der Augmentation werden die abgerufenen Stellen in die Modelleingabe eingebaut – meist mit einer Anweisung wie „Beantworte die Frage nur auf Basis der folgenden Quellen und gib die Fundstellen an". Die Art der Übergabe (Reihenfolge, Kennzeichnung der Quellen, Umgang mit widersprüchlichen Passagen) beeinflusst das Ergebnis erheblich.

In der Generation formuliert das Sprachmodell die Antwort. Ob es sich dabei tatsächlich an die Quellen hält (Groundedness) oder frei weiterschreibt, hängt von Modell, Prompt und Kontextqualität ab. Viele Systeme geben Quellenverweise mit aus – das erhöht die Nachvollziehbarkeit, ist aber keine Garantie für Korrektheit.

Retrieval ist kein Beweis

Konstruiertes Beispiel: Auf die Frage „Wie hoch ist der aktuelle Mehrwertsteuersatz?" kann ein älterer Artikel mit einem historischen Satz semantisch perfekt passen – und dennoch die falsche Antwort liefern. Deshalb sind Metadaten (Datum, Version, Quelle) und eine redaktionelle Pflege der Wissensbasis Teil eines belastbaren RAG-Systems, nicht optionales Beiwerk.

RAG und Halluzinationen

RAG wird oft als Mittel gegen Halluzinationen beschrieben. Das stimmt in eine Richtung: Wenn das Modell relevante, korrekte Quellen im Kontext hat, muss es weniger „aus dem Gedächtnis" raten. Aber RAG verhindert Halluzinationen nicht. Neue Fehlerquellen kommen sogar hinzu:

Ein gut gebautes RAG-System begegnet dem u. a. mit der Anweisung, bei fehlender Deckung „Ich weiß es nicht" zu antworten, mit Quellenpflicht und mit einer Prüfung, ob die Antwort tatsächlich durch die Quellen gedeckt ist. Eine menschliche Kontrolle bei wichtigen Aussagen bleibt sinnvoll.

Retrievalfehler vs. Generierungsfehler

Ist eine RAG-Antwort falsch, hilft die Frage: Lag es am Abruf oder an der Erzeugung? Diese Trennung ist die wichtigste Diagnosehilfe.

Für die erste Stelle misst man Retrievalqualität (findet das System die benötigte Passage?), für die zweite die Antwortqualität (nutzt das Modell die Passage korrekt?). Ohne diese Trennung optimiert man oft die falsche Komponente.

RAG vs. Fine-Tuning

RAG und Fine-Tuning lösen unterschiedliche Probleme und schließen sich nicht aus. Fine-Tuning passt die Modellgewichte an – gut für Stil, Format, Ton oder wiederkehrende Aufgabenmuster. RAG liefert Wissen zur Laufzeit – gut für Fakten, die aktuell, nachvollziehbar oder zugriffsgeschützt sein müssen.

Für „unser Modell soll unsere aktuellen Handbücher kennen" ist meist RAG das passende Werkzeug; für „unser Modell soll immer in einem bestimmten Format antworten" eher Fine-Tuning. Beides lässt sich kombinieren.

RAG vs. langes Kontextfenster

Moderne Modelle haben große Kontextfenster. Das wirft die Frage auf: Kann man nicht einfach alle Dokumente in den Prompt kippen und auf RAG verzichten? Beide Ansätze haben Berechtigung, und die Forschung vergleicht sie aktiv (z. B. Li et al., 2024).

Ein sehr großes Kontextfenster ersetzt RAG nicht bei großen, sich ändernden oder zugriffsgeschützten Wissensbeständen – kann aber innerhalb einer RAG-Pipeline mehr abgerufenen Kontext ermöglichen. Die Ansätze ergänzen sich häufiger, als sie konkurrieren.

RAG vs. Websuche, Memory und MCP

Weitere häufige Verwechslungen:

Query-Umformung und Multi-Query

Nutzerfragen sind oft knapp, mehrdeutig oder anders formuliert als die Dokumente. Deshalb setzen viele Systeme vor dem Abruf an: Query Rewriting formuliert die Frage klarer, Multi-Query erzeugt mehrere Varianten und vereint deren Treffer, und Verfahren wie HyDE erzeugen zunächst eine hypothetische Antwort, deren Embedding dann für die Suche genutzt wird. Solche Schritte können Retrieval verbessern, erhöhen aber Latenz und Kosten – der Nutzen ist am eigenen Datensatz zu prüfen.

Agentic Retrieval

Statt eines einzigen Abrufs kann ein agentisches System mehrere Suchschritte planen: eine komplexe Frage in Teilfragen zerlegen, iterativ nachsuchen, Zwischenergebnisse bewerten und erst dann antworten. Anbieter wie Microsoft beschreiben solche agentic retrieval-Ansätze für ihre Suchdienste. Das kann schwierige, mehrteilige Fragen besser beantworten, kostet aber mehr Aufrufe, mehr Zeit und erhöht die Komplexität. Für einfache Fragen ist ein einzelner Abruf oft ausreichend und robuster.

GraphRAG

GraphRAG (von Microsoft Research beschrieben) erweitert klassisches RAG um einen Knowledge Graph: Aus den Dokumenten werden Entitäten und Beziehungen extrahiert und zu einem Graphen verknüpft. Das hilft besonders bei Fragen, die viele Dokumente zusammenführen müssen („Welche Themen ziehen sich durch alle Berichte?"), die reine Passagensuche schlecht beantwortet. GraphRAG ist aufwändiger im Aufbau und nicht für jeden Anwendungsfall nötig – für eng umrissene Faktenfragen genügt oft Standard-RAG.

Multimodales RAG

Retrieval ist nicht auf Text beschränkt. Mit multimodalen Embeddings lassen sich auch Bilder, Tabellen, Folien, Diagramme oder Ausschnitte aus PDFs abrufen und einem multimodalen Modell als Kontext geben. Das ist nützlich für dokumentenlastige Anwendungen (Handbücher, Datenblätter, Präsentationen), stellt aber höhere Anforderungen an Parsing, Indexierung und Auswertung.

Sicherheit: Prompt Injection und Poisoning

Greshake et al. beschrieben, wie sich Sprachmodelle über eingeschleuste Inhalte aus der Ferne kompromittieren lassen; die OWASP-Liste für LLM-Anwendungen führt Prompt Injection als Top-Risiko. Speziell für RAG zeigten Zou et al. mit PoisonedRAG, dass gezielt manipulierte Dokumente in der Wissensbasis („Knowledge Poisoning") Antworten steuern können. Gegenmaßnahmen sind u. a.: nur vertrauenswürdige Quellen indexieren, Inhalte und Anweisungen klar trennen, Berechtigungen durchsetzen, Ausgaben und Werkzeugaufrufe absichern und die Wissensbasis redaktionell pflegen.

Datenschutz und lokales RAG

RAG berührt sensible Daten in zwei Richtungen: Die Wissensbasis kann vertrauliche Dokumente enthalten, und Anfragen können vertrauliche Informationen transportieren. Für datensensible Anwendungen lässt sich RAG vollständig lokal betreiben – mit offenen Embedding-Modellen, einem lokalen Index und einem lokalen Sprachmodell. „Lokal" ist aber nicht automatisch „sicher": Zugriffsrechte, Protokollierung, Aktualität und Modellqualität müssen trotzdem geregelt sein.

Evaluation und Metriken

Ein RAG-System sollte gemessen, nicht nur gefühlt werden. Weil zwei Komponenten beteiligt sind, gehören auch zwei Ebenen evaluiert:

Frameworks wie RAGAS (Es et al.) schlagen Kennzahlen für eine (teils modellgestützte) Bewertung von RAG-Pipelines vor – etwa Faithfulness, Answer Relevancy und Context Precision/Recall. Solche automatischen Bewertungen sind Hilfsmittel, kein Ersatz für Stichproben durch Menschen, besonders bei kritischen Aussagen.

Kosten und Latenz

Jede zusätzliche Stufe – Query-Umformung, mehrfaches Retrieval, Reranking, größerer Kontext – verbessert potenziell die Qualität und erhöht zugleich Latenz und Kosten. Ein sinnvolles System wählt die einfachste Architektur, die die Anforderungen erfüllt, und baut nur dort aus, wo die Evaluation einen echten Mehrwert zeigt. Mehr Bausteine bedeuten nicht automatisch bessere Antworten.

Wann RAG sinnvoll ist – und wann nicht

Sinnvoll, wenn Antworten auf eigenen, aktuellen oder zugriffsgeschützten Dokumenten beruhen sollen, wenn Quellen nachvollziehbar sein müssen oder wenn sich das Wissen häufig ändert. Weniger sinnvoll, wenn eine Aufgabe reines Sprachverständnis ohne externes Faktenwissen ist (z. B. Umformulieren), wenn eine strukturierte Datenbankabfrage die exaktere Antwort liefert (z. B. „Rechnung Nr. 481516"), oder wenn eine kleine, stabile Faktenmenge auch direkt in den Prompt passt.

Häufige Irrtümer über RAG

Praxis-Checkliste: RAG planen

• Welche konkrete Aufgabe soll RAG lösen – und ist RAG dafür das richtige Werkzeug?
• Welche Quellen kommen in die Wissensbasis, und wie werden sie gepflegt?
• Wie werden Dokumente geparst und sinnvoll in Chunks zerlegt?
• Lexikalische, dense oder hybride Suche – und mit welchem Reranking?
• Welche Metadatenfilter und Zugriffsrechte müssen vor dem Abruf greifen?
• Wie verhindere ich Prompt Injection und Poisoning aus abgerufenen Inhalten?
• Soll das System lokal laufen, und welche Datenschutzanforderungen gelten?
• Wie messe ich Retrieval- und Antwortqualität getrennt?
• Was passiert, wenn nichts Passendes gefunden wird?
• Wie versioniere ich Modelle, Index und Chunking bei Änderungen?

Weiterführend: Embeddings, Large Language Models, Tokens & Kontextfenster, Halluzinationen, MCP, KI-Agenten und Prompt Injection.

• Embeddings
• Large Language Models
• Halluzinationen
• MCP
• KI-Agenten
• Lokale KI