Retrieval Augmented Generation (RAG)
Ein Sprachmodell erzeugt Text aus dem, was es beim Training gelernt hat. Wenn die Antwort aber aus einem konkreten Dokument stammen soll, braucht das Modell Zugriff auf dieses Dokument. Retrieval Augmented Generation (RAG) ist das Architekturmuster, das diesen Zugriff herstellt: Vor der Antwortgenerierung werden relevante Textpassagen aus einer externen Quelle abgerufen und dem Modell als Kontext mitgegeben.
Grundprinzip: Abrufen vor dem Generieren
RAG trennt zwei Aufgaben, die in einem reinen Sprachmodell verschmolzen sind: das Speichern von Wissen und das Formulieren von Antworten. Das Modell formuliert weiterhin. Das Wissen kommt aus einer separaten Datenquelle.
Der Ablauf folgt einem festen Schema. Eine Nutzeranfrage geht ein. Ein Retrieval-Modul sucht in einer Dokumentensammlung nach passenden Passagen. Die gefundenen Passagen werden zusammen mit der Anfrage an das Sprachmodell übergeben. Das Modell generiert eine Antwort auf Basis dieses erweiterten Kontexts.
Beispiel: Eine Versicherung betreibt einen internen Chatbot. Ein Sachbearbeiter fragt: "Welche Frist gilt für die Rückabwicklung bei Vertragstyp 7b?" Das Sprachmodell kennt die internen Vertragsrichtlinien nicht. Das RAG-System durchsucht die Wissensdatenbank der Versicherung, findet Abschnitt 4.3 der Richtlinie und übergibt diesen Text an das Modell. Die Antwort enthält die korrekte Frist mit Quellenangabe.
Beispiel: Ein juristischer Recherche-Assistent erhält die Frage "Welche Urteile zum Thema Arbeitszeiterfassung gibt es seit 2022?" Das Retrieval-Modul durchsucht eine Urteilsdatenbank, liefert drei relevante Entscheidungen mit Aktenzeichen, und das Modell fasst die Kernaussagen zusammen.
Fachliche Einordnung: RAG ist kein eigenständiges Modell, sondern ein Systementwurfsmuster. Es kombiniert ein Information-Retrieval-System mit einem generativen Sprachmodell. Die Erstveröffentlichung stammt von Lewis et al. (2020, Facebook AI Research). Seitdem hat sich RAG als Standardarchitektur für wissensgestützte KI-Systeme etabliert.Der Retrieval-Schritt im Detail
Der Retrieval-Schritt entscheidet, welche Textpassagen das Modell sieht. Die Qualität der Antwort hängt direkt von der Qualität dieser Auswahl ab.
Im Kern funktioniert der Abruf so: Die Nutzeranfrage wird in einen Vektor umgewandelt. Dieser Embedding-Vektor repräsentiert die Bedeutung der Anfrage als Zahlenfolge. In einer Vektordatenbank liegen die Dokumente ebenfalls als Vektoren vor. Das System berechnet die Cosine Similarity zwischen Anfrage-Vektor und Dokument-Vektoren und gibt die ähnlichsten Treffer zurück.
Beispiel: Die Anfrage "Wie funktioniert die Kündigung bei Mietverträgen?" erzeugt einen Vektor. In der Dokumentensammlung liegen Mietrechts-Texte, AGB-Vorlagen und FAQ-Einträge. Das System findet die drei Passagen mit der höchsten Ähnlichkeit: einen Gesetzesauszug zu § 573 BGB, einen FAQ-Eintrag zu Kündigungsfristen und eine interne Richtlinie zu Sonderkündigungen.
Beispiel: Ein technisches Support-System erhält die Anfrage "Drucker druckt nur leere Seiten". Der Retrieval-Schritt liefert drei Knowledge-Base-Artikel: Treiber-Neuinstallation, Patronen-Reset und Firmware-Update. Alle drei Passagen gehen als Kontext an das Modell.
Dokumente vorbereiten: Chunking und Indexierung
Bevor ein RAG-System Dokumente durchsuchen kann, müssen diese aufbereitet werden. Große Texte werden in kleinere Abschnitte zerlegt. Diesen Vorgang nennt man Chunking. Jeder Abschnitt wird einzeln in einen Vektor umgewandelt und in der Vektordatenbank gespeichert.
Die Wahl der Chunk-Größe beeinflusst die Ergebnisqualität. Zu kleine Chunks verlieren den Zusammenhang. Zu große Chunks verwässern die Relevanz, weil sie neben der gesuchten Information auch irrelevanten Text enthalten.
Beispiel: Ein Unternehmen indexiert sein 200-seitiges Qualitätshandbuch. Bei einer Chunk-Größe von 500 Token entstehen rund 800 Abschnitte. Eine Anfrage zu "Prüfintervall für Messgeräte" liefert genau den Absatz aus Kapitel 7.6, der die Intervalle definiert. Wäre das gesamte Kapitel ein einziger Chunk, käme eine dreiseitige Passage zurück, aus der das Modell den relevanten Satz erst extrahieren müsste.
Beispiel: Eine Kanzlei indexiert Mandantenakten. Jede Akte enthält Schriftverkehr, Verträge und Notizen. Das Chunking trennt nach Dokumenttyp und Absatz. Bei der Suche nach "Widerspruchsfrist Bescheid vom 12.03." liefert das System den konkreten Absatz aus dem Bescheid, nicht die gesamte Akte.
Neben der Größe spielt die Chunking-Strategie eine Rolle. Einfache Ansätze teilen nach fester Zeichenzahl. Fortgeschrittene Methoden berücksichtigen Absatzgrenzen, Überschriften oder semantische Zusammengehörigkeit. Eine weitere Technik ist das Überlappen (Overlap): Aufeinanderfolgende Chunks teilen sich einen Teil ihres Textes, damit Zusammenhänge an Chunk-Grenzen nicht verloren gehen.
Prompt-Konstruktion: Kontext und Anfrage zusammenführen
Nachdem das Retrieval-Modul die relevanten Passagen geliefert hat, werden diese in einen Prompt eingebaut. Das Sprachmodell erhält also nicht nur die ursprüngliche Frage, sondern auch den abgerufenen Kontext.
Die Struktur eines typischen RAG-Prompts sieht so aus: Zuerst eine Systemanweisung ("Beantworte die Frage ausschließlich auf Basis der folgenden Dokumente"). Dann die abgerufenen Passagen. Dann die Nutzerfrage. Diese Reihenfolge gibt dem Modell eine klare Aufgabe und begrenzt den Antwortrahmen auf die gelieferten Quellen.
Beispiel: Ein RAG-System für eine Produktdatenbank erhält die Frage "Ist das Modell X wassergeschützt?" Die Systemanweisung lautet: "Beantworte die Frage nur aus den gegebenen Datenblättern. Wenn die Information fehlt, sage das." Die abgerufene Passage enthält das Datenblatt mit IP-Schutzklasse. Das Modell antwortet mit der konkreten Schutzklasse und verweist auf das Datenblatt.
Die Begrenzung auf den gelieferten Kontext ist ein zentraler Mechanismus gegen Halluzinationen. Ohne diese Anweisung könnte das Modell fehlende Informationen aus seinen Trainingsdaten ergänzen, was zu sachlich falschen Antworten führt.
Architekturvarianten
Die beschriebene Grundarchitektur wird als Naive RAG bezeichnet. Sie besteht aus einem Retrieval-Schritt und einem Generierungsschritt. In der Praxis existieren Erweiterungen, die spezifische Schwächen adressieren.
Advanced RAG ergänzt Vor- und Nachverarbeitungsschritte. Vor dem Retrieval wird die Anfrage umformuliert (Query Rewriting), um bessere Treffer zu erzielen. Nach dem Retrieval werden die Ergebnisse neu sortiert (Reranking), um die relevantesten Passagen nach oben zu bringen.
Beispiel: Ein Nutzer fragt "Wie geht das mit den Steuern bei Krypto?" Query Rewriting reformuliert zu "Besteuerung von Kryptowährungen in Deutschland". Diese präzisere Anfrage liefert Treffer aus dem Steuerrecht statt aus allgemeinen Krypto-Artikeln.
Modular RAG behandelt die einzelnen Komponenten als austauschbare Module. Das Retrieval kann wahlweise über eine Vektordatenbank, eine klassische Volltextsuche oder eine Kombination aus beidem (Hybrid Search) laufen. Der Generator kann durch verschiedene Sprachmodelle ersetzt werden.
Beispiel: Ein E-Commerce-System kombiniert Vektor-Suche (für semantische Ähnlichkeit) mit Keyword-Suche (für exakte Artikelnummern). Die Anfrage "Adapter für USB-C Laptop" liefert über die Vektor-Suche thematisch passende Produkte. Die parallele Keyword-Suche findet Produkte, deren Beschreibung exakt "USB-C" enthält. Beide Ergebnislisten werden zusammengeführt.
Qualitätsmessung
Die Qualität eines RAG-Systems wird auf zwei Ebenen gemessen: Retrieval-Qualität und Antwort-Qualität.
Die Retrieval-Qualität misst, ob die richtigen Passagen gefunden werden. Precision gibt an, welcher Anteil der abgerufenen Passagen tatsächlich relevant ist. Recall gibt an, welcher Anteil der insgesamt relevanten Passagen gefunden wurde. Beide Metriken zusammen zeigen, ob das System präzise genug filtert und gleichzeitig nichts Wichtiges übersieht.
Beispiel: Ein RAG-System ruft fünf Passagen ab. Drei davon sind relevant. Precision: 3/5 = 60%. In der Dokumentensammlung gäbe es insgesamt vier relevante Passagen. Recall: 3/4 = 75%. Das System filtert akzeptabel, übersieht aber eine relevante Passage.
Die Antwort-Qualität misst, ob die generierte Antwort korrekt und vollständig ist. Faithfulness prüft, ob die Antwort nur Informationen aus den abgerufenen Passagen verwendet. Answer Relevancy prüft, ob die Antwort die gestellte Frage tatsächlich beantwortet. Frameworks wie RAGAS (Retrieval Augmented Generation Assessment) automatisieren diese Bewertung.
Einsatzbereiche in der Praxis
RAG-Systeme finden dort Anwendung, wo Sprachmodelle auf spezifisches, aktuelles oder vertrauliches Wissen zugreifen sollen.
Internes Wissensmanagement: Unternehmen machen Handbücher, Prozessbeschreibungen und interne Richtlinien über einen Chatbot durchsuchbar. Mitarbeitende stellen Fragen in natürlicher Sprache und erhalten Antworten mit Quellenverweisen.
Beispiel: Ein Onboarding-Chatbot beantwortet neuen Mitarbeitenden Fragen wie "Wie beantrage ich Urlaub?" oder "Wo finde ich die Reisekostenrichtlinie?" Das System durchsucht das Intranet und liefert die passende Richtlinie mit Link zum Originaldokument.
Technische Dokumentation: Softwarefirmen indexieren ihre API-Dokumentation, Changelogs und Troubleshooting-Guides. Entwickler fragen in natürlicher Sprache statt manuell durch Hunderte Seiten zu blättern.
Regulatorik und Compliance: In regulierten Branchen (Finanzwesen, Pharma, Medizintechnik) durchsuchen RAG-Systeme Gesetzestexte, Normen und Prüfberichte. Die Quellenangabe in der Antwort ist hier besonders relevant, da sie eine Nachprüfung ermöglicht.
Beispiel: Ein Pharma-Unternehmen setzt ein RAG-System ein, das FDA-Richtlinien und EU-Verordnungen durchsucht. Bei der Frage "Welche Dokumentationspflichten gelten für Klasse-IIb-Medizinprodukte?" liefert das System die relevanten Passagen aus der MDR (Medical Device Regulation) mit Artikel- und Absatznummer.
Grenzen und typische Fehlerquellen
RAG reduziert Halluzinationen, beseitigt sie aber nicht. Wenn das Retrieval-Modul irrelevante Passagen liefert, generiert das Modell eine Antwort auf falscher Grundlage. Wenn keine passende Passage gefunden wird, kann das Modell auf seine Trainingsdaten zurückfallen, sofern die Systemanweisung das nicht explizit unterbindet.
Retrieval-Fehler: Das häufigste Problem ist, dass die abgerufenen Passagen nicht zur Frage passen. Ursachen: ungeeignete Chunk-Größe, schlechte Embedding-Qualität oder mehrdeutige Anfragen.
Beispiel: Die Frage "Was kostet die Lösung?" in einem IT-Kontext kann sich auf eine Softwarelizenz oder auf eine chemische Lösung beziehen. Je nach Dokumentenbasis liefert das Retrieval Passagen aus dem falschen Fachgebiet.
Kontextfenster-Limits: Jedes Sprachmodell hat ein begrenztes Kontextfenster. Wenn zu viele Passagen abgerufen werden, passen nicht alle in den Prompt. Das System muss dann eine Auswahl treffen, wobei relevante Informationen verloren gehen können.
Aktualität: Die Qualität eines RAG-Systems steht und fällt mit der Aktualität der indexierten Dokumente. Veraltete Dokumente in der Vektordatenbank führen zu veralteten Antworten. Ein regelmäßiger Re-Indexierungsprozess ist daher notwendig.
Beispiel: Ein Unternehmen indexiert seine Preisliste im Januar. Im März ändern sich die Preise. Das RAG-System liefert bis zur nächsten Indexierung die alten Preise. Ohne automatische Re-Indexierung oder Versionskontrolle bleibt dieser Fehler unbemerkt.
Grenzen der Retrieval-Qualität: Vektorbasierte Suche arbeitet mit Ähnlichkeit, nicht mit logischem Verstehen. Fragen, die Schlussfolgerungen über mehrere Dokumente hinweg erfordern (Multi-Hop Reasoning), werden von einfachen RAG-Systemen nicht zuverlässig beantwortet. Hier sind Erweiterungen wie iteratives Retrieval oder Agent-basierte Architekturen nötig.
RAG ist ein pragmatischer Kompromiss: Es macht Sprachmodelle nützlicher für konkrete Aufgaben, ohne dass das Modell selbst verändert werden muss. Im Vergleich zu Fine-Tuning, bei dem das Modell mit zusätzlichen Daten nachtrainiert wird, ist RAG schneller einsetzbar und die Datenquellen bleiben transparent. Die Architektur verlagert das Problem der Wissensspeicherung vom Modell in eine externe, aktualisierbare Datenbank.
Fachliche Einordnung: RAG adressiert eine fundamentale Einschränkung generativer Sprachmodelle: Ihr Wissen ist auf den Trainings-Zeitpunkt begrenzt (Knowledge Cutoff). RAG durchbricht diese Grenze, indem es das Modell mit aktuellen, domänenspezifischen Daten versorgt. Die Architektur wird als "non-parametric" bezeichnet, weil das zusätzliche Wissen nicht in den Modellparametern gespeichert wird, sondern extern verbleibt. Aktuelle Forschung untersucht, wie RAG mit Fine-Tuning kombiniert werden kann (RAFT: Retrieval Augmented Fine-Tuning), um sowohl allgemeines als auch domänenspezifisches Wissen zu verbessern.