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

Wer sich mit generativer KI im Unternehmen beschäftigt, stößt fast zwangsläufig auf RAG – oft 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, die verstehen wollen, was hinter dem Begriff steckt, bevor sie über den Einsatz entscheiden – ob als Grundlage für einen internen Chatbot, eine Suche über Firmendokumente oder einen Kundenservice-Assistenten. Er ist der Einstiegspunkt in unser Themen-Cluster RAG, Wissensdatenbanken und Daten; Architektur, Datenschutz und einzelne Komponenten wie Vektordatenbanken oder Chunking vertiefen eigene Artikel im Cluster.

Begriffe kurz geklärt

Bevor es um die Funktionsweise geht, vier Begriffe, die häufig durcheinandergeraten:

• LLM (Large Language Model) ist das Sprachmodell, das Text erzeugt – etwa ein Modell wie GPT. Es „weiß” nur, was in seinen Trainingsdaten steckte, und das nur bis zu einem bestimmten Stichtag.
• RAG (Retrieval-Augmented Generation) ist die Methode, ein LLM zur Anfragezeit mit zusätzlichem, gezielt gesuchtem Wissen aus einer eigenen Dokumentenbasis zu versorgen.
• Fine-Tuning / Nachtraining verändert dagegen die Modellparameter selbst, dauerhaft und mit spezifischen Trainingsdaten. RAG und Fine-Tuning lösen unterschiedliche Probleme und lassen sich auch kombinieren – wann welcher Weg sinnvoller ist, behandelt der Cluster-Artikel zu RAG vs. Fine-Tuning.
• Vektordatenbank ist die Komponente, in der die für RAG aufbereiteten Dokumente in durchsuchbarer Form gespeichert werden – mehr dazu im Cluster-Artikel zu Vektordatenbanken.

Was bedeutet RAG?

Die Datenschutzkonferenz beschreibt RAG-Systeme technisch präzise: Die Eingabe der Nutzenden wird durch das RAG-Subsystem um Texte aus Referenzdokumenten ergänzt, bevor sie an ein Sprachmodell gesandt wird – mit dem Ziel, dass die relevanten Informationen tatsächlich in den Fokus der Antwort rücken. Im Idealfall stammt das faktische Wissen einer Antwort vollständig aus den Referenzdokumenten, während das Sprachmodell nur noch für die sprachliche Formulierung zuständig ist.

Der entscheidende Unterschied zu einem „nackten” Sprachmodell: RAG verändert nicht, was das Modell gelernt hat, sondern was es bei einer konkreten Anfrage zusätzlich zu lesen bekommt. Das ist auch der Grund, warum ein RAG-System nach EU-KI-Verordnung selbst als KI-System gilt (Art. 3 Nr. 1 KI-VO) – es trifft eigene Entscheidungen darüber, welche Informationen in die Antwort einfließen.

Ein praktisches Beispiel, wie ich es in Projekten häufig sehe: Ein mittelständisches Unternehmen will eine interne Suche über Produkthandbücher, Montageanleitungen und FAQ-Dokumente anbieten. Ohne RAG müsste entweder ein Sprachmodell auf diesen Dokumenten nachtrainiert werden – aufwändig und bei jeder Dokumentenänderung erneut nötig – oder Mitarbeitende suchen weiter manuell in einer Dateiablage. Mit RAG durchsucht das System bei jeder Frage die aktuelle Dokumentensammlung, findet die relevanten Passagen und lässt das Sprachmodell daraus eine verständliche Antwort formulieren. Ändert sich ein Handbuch, wird nur das Dokument aktualisiert – nicht das Modell.

Welche Komponenten gibt es?

Ein RAG-System besteht laut der Orientierungshilfe der Datenschutzkonferenz im Kern aus vier technischen Bausteinen plus dem Sprachmodell selbst:

Komponente	Aufgabe
Referenzdokumente	Die eigentliche Wissensbasis – Handbücher, Richtlinien, FAQ, Verträge, Produktdaten. Können innerhalb oder außerhalb des RAG-Systems liegen.
Datenaufbereitung / Chunking	Referenzdokumente werden in kürzere Textabschnitte (Chunks) zerlegt – entweder nach fester Zeichenzahl oder inhaltlich-semantisch. Die Qualität dieses Schritts beeinflusst direkt die Qualität späterer Antworten.
Embedding-Modell	Wandelt jeden Chunk – und später die Nutzeranfrage – in einen Vektor um, der die inhaltliche Bedeutung des Texts repräsentiert.
Vektordatenbank	Speichert die Chunks zusammen mit ihren Vektoren, durchsuchbar nach semantischer Nähe.
Retriever	Vergleicht den Anfragevektor mit den gespeicherten Vektoren und liefert die inhaltlich nächstgelegenen Chunks zurück.
Sprachmodell (LLM)	Erhält die ursprüngliche Frage plus die gefundenen Chunks als erweiterten Prompt und formuliert daraus die Antwort.

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

Wichtig für die Praxis: Diese Komponenten müssen nicht alle selbst entwickelt werden. Viele Business-Software-Anbieter und Cloud-Plattformen bieten heute vorkonfigurierte RAG-Bausteine an; die eigentliche Arbeit verschiebt sich damit auf Auswahl, Aufbereitung und Pflege der Referenzdokumente – nicht auf den Bau der technischen Infrastruktur.

Wie läuft eine Anfrage ab?

Der Ablauf lässt sich in vier Schritten beschreiben, die bei jeder einzelnen Anfrage neu durchlaufen werden:

1. Anfrage vektorisieren. Die Nutzereingabe wird mit demselben Embedding-Modell, das auch die Referenzdokumente verarbeitet hat, in einen Vektor umgewandelt.
2. Ähnliche Chunks suchen. Der Retriever vergleicht diesen Anfragevektor mit den in der Vektordatenbank gespeicherten Vektoren und identifiziert die Textabschnitte mit der größten semantischen Nähe – nicht die wortähnlichsten, sondern die inhaltlich passendsten.
3. Prompt erweitern. Die gefundenen Chunks werden zusammen mit der ursprünglichen Eingabe und gegebenenfalls zusätzlichen Anweisungen (etwa „antworte ausschließlich auf Basis der folgenden Quellen”) zu einem erweiterten Prompt zusammengesetzt.
4. Antwort generieren. Das Sprachmodell erzeugt aus diesem erweiterten Prompt die Ausgabe. Je nach System werden zusätzlich die genutzten Quellen angezeigt – ein Punkt, der laut Datenschutzkonferenz auch die Nachvollziehbarkeit der Antwort verbessert.

Das Wichtige an diesem Ablauf: Er passiert bei jeder Anfrage neu. Anders als beim Training oder Nachtraining eines Modells verändert die erweiterte Anfrage das Sprachmodell selbst nicht – die Referenzdaten lassen sich dadurch einfach aktualisieren, korrigieren oder löschen, ohne dass irgendetwas am Modell angepasst werden muss.

Was verbessert RAG – und was nicht?

Der meistgenannte Vorteil ist die Reduktion von Halluzinationen: Sprachmodelle erzeugen laut Datenschutzkonferenz dann besonders unzuverlässige Ausgaben, wenn sie selten vorhandenes oder aktuelles Wissen liefern sollen, das nicht oder 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 Auswirkungen von Halluzinationen, insbesondere weil Nutzenden angezeigt werden kann, auf welchen Textauszügen die Antwort tatsächlich basiert.

Zwei weitere, oft unterschätzte Vorteile:

• Aktualität ohne Neutraining. Ein Sprachmodell kennt nur Daten bis zu seinem Trainingsstichtag. RAG macht aktuelle oder unternehmensspezifische Informationen zugänglich, ohne dass das Modell selbst verändert werden muss.
• Bessere Umsetzbarkeit von Betroffenenrechten. Weil personenbezogene Daten in Referenzdokumenten und Vektordatenbank direkt adressierbar bleiben, lassen sie sich gezielt löschen, korrigieren oder herausgeben – anders als im „antrainierten” Wissen eines Sprachmodells, wo das laut Datenschutzkonferenz weitgehend ungelöst ist. Das erleichtert insbesondere Berichtigungs- und Löschansprüche nach Art. 16 und 17 DSGVO für die im RAG-System hinterlegten Daten.

Was RAG nicht verbessert: die grundsätzliche Funktionsweise des Sprachmodells. Es bleibt ein System, das Wörter auf Basis von Wahrscheinlichkeiten erzeugt – kein echtes Textverständnis im menschlichen Sinn. Und ein Sprachmodell, das mit unrechtmäßig erhobenen Daten trainiert wurde, bleibt laut Datenschutzkonferenz auch innerhalb eines RAG-Systems ein unrechtmäßig trainiertes Modell. RAG ist eine von mehreren möglichen risikomindernden Maßnahmen – kein Reset-Knopf für alle datenschutz- oder qualitätsbezogenen Probleme eines Sprachmodells.

Welche Grenzen bleiben?

Vier Grenzen sind aus meiner Erfahrung in Projekten die wichtigsten – alle auch in der Orientierungshilfe der Datenschutzkonferenz benannt:

• Begrenzte Prompt-Länge. Ein Sprachmodell kann nicht beliebig viel Text auf einmal verarbeiten. Wie viele Chunks in eine Anfrage passen, ist technisch limitiert – bei sehr umfangreichen Dokumentensammlungen entscheidet die Qualität des Retrievers, ob die wirklich relevanten Abschnitte gefunden werden.
• Nur semantisch benachbarte Information wird gefunden. Komplexe Zusammenhänge, die über mehrere, inhaltlich weit auseinanderliegende Textabschnitte verteilt sind, werden vom Retriever leicht übersehen, weil sie keine ausreichende semantische Nähe zueinander aufweisen – selbst wenn sie logisch zusammengehören.
• Kontexttreue ist nicht garantiert. Bei widersprüchlichen Informationen kann ein Sprachmodell dazu tendieren, sein antrainiertes Wissen wiederzugeben und die bereitgestellten Referenzdokumente zu ignorieren. Ein Systemprompt, der das Modell anweist, ausschließlich auf Basis der Quellen zu antworten, kann dem entgegenwirken – eine Garantie ist das nicht.
• Die Qualität steht und fällt mit den Referenzdokumenten. Veraltete, widersprüchliche oder lückenhafte Dokumente führen zu entsprechend unzuverlässigen Antworten. RAG verlagert das Qualitätsproblem, es löst es nicht.

Dazu kommt ein sicherheitsrelevantes Risiko, das das BSI explizit benennt: Knowledge Poisoning. Wer manipulierte Inhalte in die Wissensbasis einschleusen kann, kann das System bei bestimmten Eingaben zu vordefinierten, sachlich falschen Antworten verleiten. Das BSI führt das ausdrücklich als Kehrseite der RAG-Methode an – der Einsatz von RAG als Gegenmaßnahme gegen Halluzinationen bringt gleichzeitig ein neues Risiko mit sich, wenn die Wissensbasis nicht ausreichend gegen Manipulation geschützt ist.

Umsetzung: Wie ein RAG-Projekt in der Praxis startet

Aus meiner Arbeit mit KMU hat sich eine Reihenfolge bewährt, die die genannten Grenzen von Anfang an mitdenkt statt sie später zu reparieren:

1. Wissensbasis abgrenzen, nicht alles auf einmal. Der Fehler, den ich am häufigsten sehe: Unternehmen wollen sofort „das gesamte Firmenwissen” anbinden. Besser ist ein enger, klar abgegrenzter Dokumentenbestand mit hoher Aktualität – etwa nur die aktuellen Produkthandbücher eines Bereichs – statt einer unübersichtlichen Mischung aus aktuellen und veralteten Quellen.

2. Datenaufbereitung ernst nehmen. Wer Dokumente ungeprüft in Chunks zerlegt, riskiert laut Datenschutzkonferenz zerstörte semantische Zusammenhänge und dadurch schlechtere Antworten. Kopf- und Fußzeilen, Seitenzahlen und ähnlicher „Datenmüll” sollten vor dem Chunking entfernt werden.

3. Zugriffsrechte von Anfang an mitdenken. Wenn unterschiedliche Nutzergruppen unterschiedliche Berechtigungen haben sollen – etwa Vertrieb sieht andere Dokumente als Buchhaltung –, muss das Rechte- und Rollenkonzept in der Vektordatenbank selbst umgesetzt werden. Von einer Umsetzung nur über Textanweisungen im Prompt raten sowohl Datenschutzkonferenz als auch BSI ausdrücklich ab, da sie sich zu leicht umgehen lässt.

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

5. Klein pilotieren, messen, erst dann erweitern. Ein enger Anwendungsfall mit einem überschaubaren Dokumentenbestand zeigt innerhalb weniger Wochen, ob Retrieval-Qualität und Antwortgüte für den Praxiseinsatz reichen – deutlich schneller und risikoärmer, als gleich ein unternehmensweites System aufzusetzen.

Wer nicht selbst bauen will: Fertige RAG-Bausteine sind heute Teil vieler Business- und Cloud-Plattformen. Die eigentliche Beratungsarbeit liegt dann meist nicht im technischen Aufbau, sondern in Auswahl der Wissensbasis, Rechtekonzept und Qualitätssicherung – Themen, die wir in der KI-Beratung für Wissenssysteme und RAG-Projekte begleiten.

Risiken: worauf du datenschutz- und sicherheitsseitig achten solltest

Neben Knowledge Poisoning nennt die Datenschutzkonferenz mehrere datenschutzrechtliche Aspekte, die bei RAG-Systemen mit personenbezogenen Daten explizit geprüft werden müssen (Stand Juli 2026, keine Rechtsberatung):

• Rechtsgrundlage. Für die Verarbeitung personenbezogener Daten aus Referenzdokumenten durch das Embedding-Modell und die Speicherung in der Vektordatenbank braucht es eine eigene datenschutzrechtliche Rechtsgrundlage nach Art. 6 DSGVO – unabhängig davon, ob das zugrundeliegende Sprachmodell rechtmäßig trainiert wurde.
• Zweckbindung. Wenn personenbezogene Daten aus der Vektordatenbank an das Sprachmodell übergeben werden, kann es laut Datenschutzkonferenz zu einer Verkettung mit den im Modell selbst enthaltenen personenbezogenen Daten kommen – eine mögliche Zweckbindungsverletzung, die in der Ausgabe des Systems oft nicht erkennbar ist. Deshalb sollte schon bei der Konzeption geprüft werden, welche Daten überhaupt in die Wissensbasis gehören.
• Betroffenenrechte. Auskunfts-, Berichtigungs- und Löschrechte nach Art. 15 ff. DSGVO gelten sowohl für Eingabeprompt und Ausgabe als auch für Referenzdokumente und Vektordatenbank, soweit personenbezogene Daten betroffen sind.
• Angriffe auf das RAG-Subsystem. Neben Knowledge Poisoning nennt das BSI auch Knowledge Base Extraction – den Versuch, über gezielte Anfragen Informationen aus der Wissensbasis abzugreifen, auf die eigentlich kein Zugriff bestehen sollte. Ein sauberes Rechte- und Rollenkonzept in der Vektordatenbank ist hier die wirksamste Gegenmaßnahme, nicht die Hoffnung, dass niemand danach fragt.

Diese Punkte ersetzen keine rechtliche Einzelfallprüfung. Bei personenbezogenen oder sensiblen Daten in der Wissensbasis gehört die konkrete Ausgestaltung in Abstimmung mit Datenschutzbeauftragten oder Rechtsberatung geklärt – insbesondere, sobald es um Daten besonderer Kategorien nach Art. 9 DSGVO geht.

Checkliste: Ist RAG für euren Anwendungsfall geeignet?

Eine RAG-Lösung ist kein Selbstzweck. Die folgende Checkliste hilft, vor dem Start ehrlich einzuschätzen, ob die Voraussetzungen passen:

1. Es gibt eine klar abgegrenzte Wissensbasis (nicht „alles”), die für den geplanten Anwendungsfall relevant ist.
2. Die Dokumente liegen digital vor, sind einigermaßen aktuell und werden gepflegt – nicht seit Jahren unangetastete Ablagen.
3. Unterschiedliche Nutzergruppen brauchen unterschiedliche Zugriffsrechte – und ihr habt ein Konzept dafür, das in der Vektordatenbank selbst umgesetzt wird, nicht nur im Prompt.
4. Antworten sollen mit Quellenangabe erscheinen, 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. Es gibt eine Zuständigkeit dafür, wer die Wissensbasis laufend aktuell hält – 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.

Wenn mehrere Punkte offen sind, ist das kein Grund, das Thema zu verwerfen – aber ein Grund, mit einer kleineren, klarer abgegrenzten Wissensbasis zu starten als ursprünglich geplant.

Die technische Vertiefung – Aufbau einer konkreten RAG-Architektur, Auswahl der Vektordatenbank, Chunking-Strategien und die Abgrenzung zu Enterprise Search oder Fine-Tuning – behandeln die weiteren Artikel im Cluster RAG, Wissensdatenbanken und Daten. Wer die eigene Ausgangslage zuerst einordnen will, bevor es an die Umsetzung geht: Ein kostenloses Erstgespräch klärt in 45 Minuten, ob und wie RAG für euren Anwendungsfall sinnvoll ist.