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

Das Wichtigste in Kürze:

• RAG kombiniert ein Sprachmodell mit einer durchsuchbaren Wissensbasis aus euren eigenen Dokumenten.
• Bei jeder Anfrage sucht das System passende Textabschnitte und reicht sie dem Modell als Kontext mit.
• Das kann Halluzinationen reduzieren, weil Antworten an konkrete Quellen gebunden werden.
• Eine Garantie ist das nicht: Die Qualität hängt an den Referenzdokumenten.

Wer sich mit generativer KI im Unternehmen beschäftigt, stößt fast zwangsläufig auf RAG. Oft wird die Methode als Wundermittel gegen erfundene Antworten vermarktet: „KI mit RAG halluziniert nicht mehr.“ Das ist zu einfach. RAG ist eine Methode, keine Garantie. Sie kann die Zuverlässigkeit von Sprachmodell-Ausgaben deutlich verbessern, aber nur, wenn die Daten dahinter stimmen und das System sauber gebaut ist. Wer RAG als Blackbox einkauft, die Halluzinationen automatisch abschaltet, wird enttäuscht.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU. Er erklärt, was hinter dem Begriff steckt, bevor ihr über den Einsatz entscheidet. Denkbar ist ein interner Chatbot, eine Suche über Firmendokumente oder ein Kundenservice-Assistent. Er ist der Einstiegspunkt in unser Themen-Cluster RAG, Wissensdatenbanken und Daten, in dem eigene Artikel Architektur, Datenschutz und Komponenten wie Vektordatenbanken oder Chunking vertiefen.

Begriffe kurz geklärt

Diese 4 Begriffe geraten häufig durcheinander.

• LLM (Large Language Model): das Sprachmodell, das Text erzeugt, etwa ein Modell wie GPT, es „weiß“ nur, was bis zu einem Stichtag in seinen Trainingsdaten steckte.
• RAG (Retrieval-Augmented Generation): die Methode, ein LLM zur Anfragezeit mit gezielt gesuchtem Wissen aus einer eigenen Dokumentenbasis zu versorgen.
• Fine-Tuning oder Nachtraining: verändert dagegen die Modellparameter selbst, dauerhaft und mit spezifischen Trainingsdaten.
• Vektordatenbank: der Speicher, in dem die für RAG aufbereiteten Dokumente durchsuchbar abgelegt werden.

RAG und Fine-Tuning lösen verschiedene Probleme. Sie lassen sich auch kombinieren. Wann welcher Weg sinnvoller ist, behandelt der Cluster-Artikel zum Vergleich von RAG und Fine-Tuning. Mehr zu Vektordatenbanken steht ebenfalls in einem eigenen Cluster-Artikel.

Was bedeutet RAG?

Die Datenschutzkonferenz (DSK) beschreibt RAG-Systeme technisch präzise. Das RAG-Subsystem ergänzt die Eingabe der Nutzenden um Texte aus Referenzdokumenten. Erst dann geht die Anfrage an das Sprachmodell. Ziel ist, dass die relevanten Informationen tatsächlich in den Fokus der Antwort rücken, im Idealfall stammt das faktische Wissen der Antwort komplett aus diesen Dokumenten. Das Modell liefert nur noch die sprachliche Form.

Was unterscheidet RAG von einem „nackten“ Sprachmodell? Es verändert nicht, was das Modell gelernt hat. Es verändert, was das Modell bei einer konkreten Anfrage zusätzlich zu lesen bekommt. Auch deshalb gilt ein RAG-System nach EU-KI-Verordnung selbst als KI-System (Artikel 3 Nummer 1 KI-VO), denn es trifft eigene Entscheidungen darüber, welche Informationen in die Antwort einfließen.

Ein Beispiel aus meinen Projekten. Ein mittelständisches Unternehmen will eine interne Suche über Produkthandbücher, Montageanleitungen und FAQ-Dokumente anbieten. Ohne RAG gäbe es zwei unbequeme Wege. Entweder wird ein Sprachmodell auf diesen Dokumenten nachtrainiert, was aufwändig ist und bei jeder Änderung erneut nötig wird. Oder Mitarbeitende suchen weiter manuell in einer Dateiablage.

Mit RAG durchsucht das System bei jeder Frage die aktuelle Dokumentensammlung. Es findet die relevanten Passagen und lässt das Modell daraus eine verständliche Antwort formulieren. Ändert sich ein Handbuch, wird nur das Dokument aktualisiert. Das Modell bleibt unangetastet.

Welche Komponenten gibt es?

Ein RAG-System hat laut der DSK-Orientierungshilfe im Kern 4 technische Bausteine. Dazu kommt das Sprachmodell selbst.

• Referenzdokumente: die Wissensbasis selbst, etwa Handbücher, Richtlinien, FAQ, Verträge oder Produktdaten, innerhalb oder außerhalb des Systems.
• Datenaufbereitung und Chunking: Dokumente werden in kürzere Textabschnitte (Chunks) zerlegt, nach fester Zeichenzahl oder inhaltlich-semantisch.
• Embedding-Modell: wandelt jeden Chunk und später die Nutzeranfrage in einen Vektor um, der die Bedeutung des Texts abbildet.
• Vektordatenbank: speichert die Chunks samt Vektoren, durchsuchbar nach semantischer Nähe.
• Retriever: vergleicht den Anfragevektor mit den gespeicherten Vektoren und liefert die inhaltlich nächsten Chunks zurück.
• Sprachmodell (LLM): erhält die Frage plus gefundene Chunks als erweiterten Prompt und formuliert die Antwort.

Zusammenstellung Philogic Labs auf Basis der Systembeschreibung in der DSK-Orientierungshilfe RAG.

Die Qualität der Aufbereitung prägt direkt die Qualität späterer Antworten. Wichtig für die Praxis: Nichts davon muss komplett selbst entwickelt werden. Viele Business-Software-Anbieter und Cloud-Plattformen bieten vorkonfigurierte RAG-Bausteine an, die eigentliche Arbeit liegt deshalb in Auswahl, Aufbereitung und Pflege der Dokumente, nicht im Bau der Infrastruktur.

Wie läuft eine Anfrage ab?

Der Ablauf hat 4 Schritte. Sie laufen bei jeder einzelnen Anfrage neu durch.

1. Anfrage vektorisieren: Die Eingabe wird mit demselben Embedding-Modell in einen Vektor umgewandelt wie zuvor die Referenzdokumente.

2. Ähnliche Chunks suchen: Der Retriever vergleicht den Anfragevektor mit den gespeicherten Vektoren. Er liefert die inhaltlich passendsten Textabschnitte zurück, nicht die wortähnlichsten.

3. Prompt erweitern: Die gefundenen Chunks werden mit der ursprünglichen Eingabe zu einem erweiterten Prompt zusammengesetzt. Dazu kommen gegebenenfalls Anweisungen wie „antworte ausschließlich auf Basis der folgenden Quellen“.

4. Antwort generieren: Das Sprachmodell erzeugt aus dem erweiterten Prompt die Ausgabe. Je nach System zeigt sie auch die genutzten Quellen, was laut DSK die Nachvollziehbarkeit verbessert.

Wichtig: Der Ablauf passiert bei jeder Anfrage neu. Anders als ein Nachtraining verändert er das Modell nicht, Referenzdaten lassen sich deshalb jederzeit aktualisieren, korrigieren oder löschen, ohne dass am Modell irgendetwas angepasst werden muss.

Was verbessert RAG, und was nicht?

Der meistgenannte Vorteil ist die Reduktion von Halluzinationen. Wann sind Sprachmodelle besonders unzuverlässig? Laut DSK dann, wenn sie seltenes oder aktuelles Wissen liefern sollen, das kaum in den Trainingsdaten steckte. Weil RAG die Antwort an konkret gefundene Textstellen bindet, kann die Methode diese Unrichtigkeiten verringern. Das BSI nennt in seiner Risikoanalyse zu generativen KI-Modellen dieselbe Wirkung: RAG mildere Halluzinationen, insbesondere weil Nutzenden angezeigt werden kann, auf welchen Textauszügen die Antwort tatsächlich basiert.

Zwei weitere Vorteile werden oft unterschätzt.

• Aktualität ohne Neutraining: Ein Sprachmodell kennt nur Daten bis zu seinem Trainingsstichtag. RAG macht aktuelles oder firmenspezifisches Wissen zugänglich, ohne das Modell zu verändern.
• Bessere Umsetzbarkeit von Betroffenenrechten: Personenbezogene Daten bleiben in Dokumenten und Vektordatenbank direkt adressierbar. Sie lassen sich gezielt löschen, korrigieren oder herausgeben, anders als antrainiertes Modellwissen, wo das laut DSK weitgehend ungelöst ist. Das erleichtert Berichtigungs- und Löschansprüche nach Artikel 16 und 17 DSGVO für die im System hinterlegten Daten.

Was RAG nicht verbessert: die grundsätzliche Funktionsweise des Sprachmodells. Es bleibt ein System, das Wörter nach Wahrscheinlichkeiten erzeugt. Echtes Textverständnis entsteht nicht. Und ein unrechtmäßig trainiertes Modell bleibt laut DSK auch im RAG-System ein unrechtmäßig trainiertes Modell. RAG ist eine von mehreren risikomindernden Maßnahmen. Ein Reset-Knopf für alle Datenschutz- oder Qualitätsprobleme ist es nicht.

Welche Grenzen bleiben?

Diese 4 Grenzen sind aus meiner Projekterfahrung die wichtigsten. Alle benennt auch die DSK-Orientierungshilfe.

• Begrenzte Prompt-Länge: Ein Modell kann nicht beliebig viel Text auf einmal verarbeiten, die Zahl der Chunks pro Anfrage ist technisch limitiert.
• Nur semantisch Benachbartes wird gefunden: Zusammenhänge über inhaltlich weit auseinanderliegende Textabschnitte übersieht der Retriever leicht, selbst wenn sie logisch zusammengehören, weil sie keine ausreichende semantische Nähe zueinander aufweisen.
• Kontexttreue ist nicht garantiert: Bei Widersprüchen kann das Modell auf sein Trainingswissen zurückfallen und die Dokumente ignorieren, ein strenger Systemprompt wirkt dem entgegen, garantiert aber nichts.
• Die Qualität hängt an den Dokumenten: Veraltete, widersprüchliche oder lückenhafte Unterlagen führen zu entsprechend unzuverlässigen Antworten.

RAG verlagert das Qualitätsproblem, es löst es nicht. Bei sehr großen Sammlungen entscheidet zudem der Retriever, ob die wirklich relevanten Abschnitte gefunden werden.

Dazu kommt ein Sicherheitsrisiko, das das BSI explizit benennt: Knowledge Poisoning. Wer manipulierte Inhalte in die Wissensbasis einschleust, kann das System zu vordefinierten, sachlich falschen Antworten verleiten. Das BSI führt das ausdrücklich als Kehrseite der RAG-Methode an: Der Schutz gegen Halluzinationen bringt ein neues Risiko mit, wenn die Wissensbasis nicht gegen Manipulation gesichert ist.

Umsetzung: Wie ein RAG-Projekt startet

Aus meiner Arbeit mit KMU hat sich eine Reihenfolge aus 5 Schritten bewährt. Sie denkt die Grenzen von Anfang an mit, statt sie später zu reparieren.

1. Wissensbasis abgrenzen, nicht alles auf einmal. Der häufigste Fehler: Unternehmen wollen sofort „das gesamte Firmenwissen“ anbinden, besser ist ein enger, aktueller Bestand, etwa nur die Produkthandbücher eines Bereichs.

2. Datenaufbereitung ernst nehmen. Wer Dokumente ungeprüft in Chunks zerlegt, riskiert laut DSK zerstörte semantische Zusammenhänge und schlechtere Antworten. Kopf- und Fußzeilen, Seitenzahlen und ähnlicher „Datenmüll“ gehören vorher entfernt.

3. Zugriffsrechte von Anfang an mitdenken. Sollen Nutzergruppen verschiedene Berechtigungen haben, gehört das Rechte- und Rollenkonzept in die Vektordatenbank selbst. Von einer Umsetzung nur über Prompt-Anweisungen raten DSK und BSI ausdrücklich ab, weil sie sich zu leicht umgehen lässt.

4. Quellenangaben in der Antwort sichtbar machen. Sehen Nutzende, auf welchen Textstellen eine Antwort beruht, lässt sich die Aussage prüfen, das ist der wirksamste Hebel gegen unbemerkte Fehlinformation und ein Transparenzgewinn im Sinne der DSGVO.

5. Klein pilotieren, messen, erst dann erweitern. Ein enger Anwendungsfall mit überschaubarem Bestand zeigt in wenigen Wochen, ob Retrieval-Qualität und Antwortgüte reichen, und ist schneller und risikoärmer als ein sofort unternehmensweites System.

Wer nicht selbst bauen will, findet fertige RAG-Bausteine in vielen Business- und Cloud-Plattformen. Die Beratungsarbeit liegt dann meist in Auswahl der Wissensbasis, Rechtekonzept und Qualitätssicherung. Genau diese Themen begleiten wir in der KI-Beratung für Wissenssysteme und RAG-Projekte.

Risiken: worauf du achten solltest

Neben Knowledge Poisoning nennt die DSK weitere Datenschutzpunkte (Stand Juli 2026, keine Rechtsberatung). Sie gehören bei RAG-Systemen mit personenbezogenen Daten explizit geprüft.

• Rechtsgrundlage: Für personenbezogene Daten in Embedding und Vektordatenbank braucht es eine eigene Rechtsgrundlage nach Artikel 6 DSGVO, unabhängig davon, ob das Modell rechtmäßig trainiert wurde.

• Zweckbindung: Gehen personenbezogene Daten aus der Vektordatenbank an das Sprachmodell, kann es laut DSK zur Verkettung mit den im Modell enthaltenen Daten kommen. Deshalb sollte schon die Konzeption klären, welche Daten überhaupt in die Wissensbasis gehören.

• Betroffenenrechte: Auskunft, Berichtigung und Löschung nach Artikel 15, 16 und 17 DSGVO gelten für Eingabe, Ausgabe, Referenzdokumente und Vektordatenbank, soweit personenbezogene Daten betroffen sind.

• Angriffe auf das RAG-Subsystem: Das BSI nennt auch Knowledge Base Extraction, also den Versuch, über gezielte Anfragen geschützte Informationen aus der Wissensbasis abzugreifen. Wirksamste Gegenmaßnahme ist ein sauberes Rechte- und Rollenkonzept in der Vektordatenbank.

Diese Punkte ersetzen keine rechtliche Einzelfallprüfung. Bei personenbezogenen oder sensiblen Daten gehört die Ausgestaltung mit Datenschutzbeauftragten oder Rechtsberatung geklärt, das gilt besonders für Daten besonderer Kategorien nach Artikel 9 DSGVO.

Checkliste: Ist RAG für euch geeignet?

Eine RAG-Lösung ist kein Selbstzweck. Diese 7 Punkte helfen bei einer ehrlichen Einschätzung vor dem Start.

1. Es gibt eine klar abgegrenzte Wissensbasis, die für den Anwendungsfall relevant ist, nicht „alles“.

2. Die Dokumente liegen digital vor, sind aktuell und werden gepflegt, keine seit Jahren unangetasteten Ablagen.

3. Für unterschiedliche Zugriffsrechte der Nutzergruppen gibt es ein Konzept, das in der Vektordatenbank umgesetzt wird, nicht nur im Prompt.

4. Antworten erscheinen mit Quellenangabe, damit Nutzende sie prüfen können.

5. Es ist geklärt, ob und welche personenbezogenen Daten in der Wissensbasis landen, inklusive Rechtsgrundlage und Zweckbindung.

6. Jemand ist dafür zuständig, die Wissensbasis laufend aktuell zu halten, denn ein RAG-System ist nie „fertig eingerichtet“.

7. Der erste Anwendungsfall ist eng geschnitten und lässt sich innerhalb weniger Wochen testen, bevor über eine Ausweitung entschieden wird.

Sind mehrere Punkte offen, ist das kein Grund, das Thema zu verwerfen, aber ein guter Grund, mit einer kleineren Wissensbasis zu starten als ursprünglich geplant.

Die weiteren Artikel im Cluster RAG, Wissensdatenbanken und Daten vertiefen die Technik: RAG-Architektur, Vektordatenbanken, Chunking-Strategien und die Abgrenzung zu Enterprise Search oder Fine-Tuning. Wer die eigene Ausgangslage zuerst einordnen will: Ein kostenloses Erstgespräch klärt in 45 Minuten, ob und wie RAG für euch sinnvoll ist.