Verhindert RAG Halluzinationen? Was es verbessert und was nicht

Ein RAG-System soll genau das Problem lösen, für das generative KI-Modelle berüchtigt sind: Antworten, die überzeugend klingen, aber erfunden sind. Die Grundidee ist einfach – gib dem Sprachmodell die richtigen Dokumente mit auf den Weg, bevor es antwortet, dann muss es nicht raten. In der Praxis ist die Frage „Verhindert RAG Halluzinationen?” trotzdem eine Fehlstellung. Die kurze und ehrliche Antwort: RAG senkt das Risiko messbar, beseitigt es aber nicht. Wer RAG als Garantie verkauft oder einkauft, baut auf einer falschen Annahme auf.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU, die ein RAG-System planen, pilotieren oder bereits im Einsatz haben und wissen wollen, wo die Grenzen liegen. Er ordnet ein, warum RAG-Systeme trotzdem halluzinieren, welche Rolle die Referenzdokumente dabei spielen, was bei widersprüchlichen Quellen passiert, welche Prompts helfen und wann ein System besser gar nicht antworten sollte. Er gehört zu unserem Themen-Cluster RAG und Wissensdatenbanken.

Vorab zur Einordnung: Dieser Artikel ist eine allgemeine Information, Stand Juli 2026, und keine Rechtsberatung. Bei Datenschutz- oder Haftungsfragen rund um KI-Ausgaben gehören Datenschutzbeauftragte oder spezialisierte Kanzleien an den Tisch – die offiziellen Orientierungshilfen der Datenschutzkonferenz und des BSI, auf die sich dieser Artikel stützt, sind der richtige Ausgangspunkt dafür.

Begriffe kurz geklärt

Damit die folgenden Abschnitte trennscharf sind:

• Halluzination. Die Datenschutzkonferenz definiert es so: Man spricht von KI-Halluzinationen, wenn KI-Modelle Informationen erzeugen, die zwar plausibel klingen, aber nicht durch ihre Trainingsdaten – beziehungsweise im RAG-Fall nicht durch die bereitgestellten Referenzdokumente – gestützt sind.
• RAG (Retrieval-Augmented Generation). Ein Verfahren, das eine Anfrage an ein Sprachmodell um passende Informationen aus einer Wissensbasis anreichert, bevor die Anfrage beantwortet wird. Das BSI beschreibt es so: Generative Modelle erhalten dadurch Zugriff auf zusätzliche Informationen, ohne dass diese zuvor als Trainingsmaterial verwendet wurden.
• Referenzdokumente sind die Quelldokumente der Wissensbasis, aus denen der Retriever die passenden Textausschnitte holt.
• Chunks sind die Textabschnitte, in die diese Dokumente zerlegt werden, bevor sie eingebettet werden.
• Retriever ist die Komponente, die zu einer Anfrage die relevantesten Chunks aus der Vektordatenbank sucht.
• Kontexttreue beschreibt, wie zuverlässig ein Sprachmodell tatsächlich die bereitgestellten Referenzinformationen nutzt, statt auf sein antrainiertes Wissen zurückzugreifen.

Wichtig für die Einordnung: Ein RAG-System ändert laut Datenschutzkonferenz nichts an den Eigenschaften seiner LLM-Komponente. Es beeinflusst und ergänzt sie lediglich durch zusätzlichen Kontext im Eingabeprompt. Das antrainierte Wissen des Sprachmodells bleibt unverändert vorhanden – und kann jederzeit wieder durchschlagen.

Warum halluziniert ein RAG-System?

Weil das Sprachmodell hinter jedem RAG-System im Kern weiterhin ein Sprachmodell ist. Das BSI beschreibt die Ursache technisch nüchtern: Generative KI-Modelle bieten aus unterschiedlichen Gründen keine oder unzureichende Garantien hinsichtlich der Qualität ihrer Ausgaben. Fehlerhafte Inhalte können aus den Trainingsdaten stammen – sie können aber auch trotz korrektem, hochqualitativem Trainingsmaterial entstehen, schlicht aufgrund des probabilistischen Charakters der Modelle. Ein Sprachmodell sagt das statistisch wahrscheinlichste nächste Wort voraus, nicht die geprüfte Wahrheit. Hat es zudem keinen Zugriff auf aktuelle Daten, erfindet es bei Bedarf Inhalte, die weder Teil der Eingabe noch des Trainingsdatensatzes waren – das ist Halluzinieren im technischen Sinn.

RAG setzt genau hier an: Die Datenschutzkonferenz stellt fest, dass die vom RAG-System generierten Antworten idealerweise auf den Informationen aus den Referenzdokumenten basieren. Deshalb können mit der RAG-Methode Halluzinationen reduziert und die Ausgabe unrichtiger Informationen verringert werden. Das ist der eigentliche Nutzen von RAG – nicht ein neues, verlässlicheres Modell, sondern ein Modell, dem die richtigen Fakten näher an die Anfrage herangetragen werden.

Nur bleibt das eben eine Wahrscheinlichkeitsverbesserung, keine Garantie. Die Datenschutzkonferenz benennt vier Herausforderungen, die trotz RAG bestehen bleiben: die Qualität der Referenzdokumente selbst, die Qualität der Datenaufbereitung (wie sauber Dokumente in Chunks zerlegt werden), die Qualität des verwendeten Embedding-Modells und die Kontexttreue des Sprachmodells – also ob es die bereitgestellten Informationen tatsächlich nutzt oder ignoriert. Fällt eine dieser vier Voraussetzungen aus, sinkt der Effekt von RAG entsprechend. Besonders tückisch: Das BSI weist darauf hin, dass Halluzinationen bei Sprachmodellen ein großes Problem darstellen, gerade weil die generierten Ausgaben zumeist glaubhaft erscheinen – vor allem, wenn dabei auf wissenschaftliche Publikationen oder andere Referenzen verwiesen wird, die selbst frei erfunden sein können. Ein RAG-System mit Quellenangaben schützt davor nur, wenn die Quellenangabe tatsächlich zum verwendeten Chunk gehört und nicht selbst ein Fantasieprodukt des Modells ist.

Welche Rolle spielen Referenzdokumente?

Die Referenzdokumente sind der eigentliche Hebel – und gleichzeitig der unterschätzte Wartungsaufwand. Die Datenschutzkonferenz ist hier eindeutig: Die Zuverlässigkeit von RAG-Systemen hängt stark von der Qualität, Aktualität und Vollständigkeit der verwendeten Referenzdokumente ab. Unvollständige oder veraltete Daten führen zu unrichtigen Ausgaben – nicht als Randrisiko, sondern als direkte Konsequenz. Verantwortliche müssen deshalb regelmäßig überprüfen, ob die Referenzdokumente diesen Anforderungen noch entsprechen. Ein RAG-System, das einmal aufgesetzt und dann nicht mehr gepflegt wird, verliert seine Schutzwirkung schleichend, ohne dass das nach außen sichtbar wird.

Drei weitere Qualitätsdimensionen kommen laut Datenschutzkonferenz dazu, bevor ein Dokument überhaupt hilfreich sein kann:

• Datenaufbereitung. Vor der Umwandlung eines Dokuments in Chunks sollten störende Elemente wie Kopf- und Fußzeilen oder Seitennummern bereinigt werden. Größe und Überlappung der Textabschnitte beeinflussen die Qualität direkt – Chunks sollten möglichst abgeschlossene Sinnabschnitte enthalten, sonst reißt der Kontext mitten im Gedanken ab.
• Embedding-Qualität. Das Embedding-Modell muss zur Sprache der Referenzdokumente passen. Ist ein Embedding-Modell nicht auf deutschsprachige Texte trainiert, werden einer deutschen Anfrage im Zweifel die falschen oder weniger relevanten Chunks zugeordnet.
• Externe Datenquellen. Wird ein RAG-System zusätzlich mit externen Quellen betrieben, etwa einer Websuche, muss die Rechtmäßigkeit, Eignung und Richtigkeit dieser Daten geprüft werden. Die Datenschutzkonferenz hält fest, dass diese Anforderungen bei einer eingebundenen Websuche regelmäßig nicht erfüllt werden – externe Daten lassen Antworten zwar aktuell wirken, können sich aber negativ auf die Richtigkeit auswirken.

Das BSI ergänzt einen konkreten technischen Hebel gegen Halluzinationen: Wird den Nutzenden in der Ausgabe angezeigt, auf welchen konkreten Textauszügen die Antwort tatsächlich basiert, lassen sich die Auswirkungen von Halluzinationen mildern. Sichtbare Quellenangaben sind also nicht nur ein Transparenz-Feature, sondern eine funktionale Gegenmaßnahme – Nutzende können eine Antwort gegen die zitierte Quelle prüfen, statt sie blind zu übernehmen.

Was passiert bei Widersprüchen?

Hier liegt eine der am wenigsten beachteten Schwachstellen von RAG-Systemen. Die Datenschutzkonferenz beschreibt das Phänomen unter dem Begriff Kontexttreue: Abhängig vom Design des RAG-Systems und vom Training des Sprachmodells können die Berechnungen im Modell dazu tendieren, insbesondere bei widersprüchlichen Inhalten das Wissen aus den Trainingsdaten wiederzugeben und die Inhalte aus den Referenzdokumenten zu verwerfen. Mit anderen Worten: Genau in dem Moment, in dem die Referenzdokumente am wichtigsten wären – weil sie etwas Aktuelleres oder Firmenspezifisches sagen als das allgemeine Trainingswissen des Modells –, kann das Modell sie ignorieren.

Als Gegenmaßnahme kommt laut Datenschutzkonferenz vor allem ein Systemprompt in Betracht, der das RAG-System anweist, ausschließlich mithilfe der referenzierten Quellen zu antworten. Das reduziert das Risiko, löst den eigentlichen Konflikt aber nicht auf – wenn zwei Referenzdokumente sich widersprechen, weiß auch ein streng instruiertes Modell nicht, welches davon gilt. Diese Priorisierung muss vorher geklärt sein, etwa durch Versionierung, Gültigkeitsdaten oder eine klare Vorrangregel zwischen Dokumentenquellen.

Ein zweiter, strukturell bedingter Grund für unvollständige oder scheinbar widersprüchliche Antworten liegt in den Grenzen der RAG-Methode selbst. Die Anreicherung des Eingabeprompts findet nur im semantisch benachbarten Einbettungsraum statt: Komplexe Wenn-Dann-Zusammenhänge über lange Textpassagen hinweg liegen unter Umständen nicht mehr semantisch benachbart und landen nicht im selben Chunk. Daraus ergeben sich laut Datenschutzkonferenz systembedingte Schwächen bei der Erkennung von Informationen, die zwar logisch zusammengehören, aber keine ausreichende semantische Nähe aufweisen. Ein RAG-System kann also unvollständige Antworten liefern, ohne dass die Referenzdokumente selbst widersprüchlich wären – die Lücke entsteht erst beim Zerschneiden und Wiederzusammensetzen der Information.

Schließlich benennt das BSI einen Angriffsvektor, der Widersprüche gezielt erzeugt: die Vergiftung hinterlegter Wissensdaten (Knowledge Poisoning). Angreifende können manipulierte Inhalte in die Wissensbasis einschleusen, die das Modell bei bestimmten Eingaben zu vordefinierten, falschen Ausgaben verleiten. Das BSI weist ausdrücklich darauf hin, dass der Einsatz von RAG damit auch ein neues Risiko mit sich bringt, das ohne RAG so nicht existieren würde – ein Grund mehr, nur vertrauenswürdige Dokumentquellen in die Wissensbasis zu lassen.

Welche Prompts helfen?

Prompts sind die letzte Verteidigungslinie, nicht die erste – aber eine wirksame, wenn Referenzdokumente und Chunking bereits stimmen. Der von der Datenschutzkonferenz explizit empfohlene Hebel ist ein Systemprompt, der das Modell anweist, ausschließlich mithilfe der referenzierten Quellen zu antworten. In der Praxis übersetze ich das in vier konkrete Bausteine, die ich in RAG-Piloten regelmäßig einsetze:

1. Explizite Verweigerungsanweisung. Der Systemprompt muss dem Modell erlauben und aktiv abverlangen, „ich finde dazu keine ausreichende Information in den bereitgestellten Dokumenten” zu antworten, statt eine plausible Lücke zu füllen. Ohne diese Anweisung optimiert das Modell standardmäßig auf eine hilfreich klingende Antwort – auch wenn keine trägt.
2. Quellenpflicht pro Aussage. Jede sachliche Aussage soll auf einen konkreten Chunk oder ein Dokument zurückführbar sein, nicht nur die Antwort als Ganzes. Das erleichtert Nutzenden die Prüfung und macht sichtbar, wenn eine Antwort mehrere Quellen unzulässig vermischt.
3. Kein Rückgriff auf Modellwissen. Die Anweisung, ausschließlich mit den referenzierten Quellen zu antworten, sollte explizit ausschließen, dass das Modell allgemeines Trainingswissen ergänzt, selbst wenn es „naheliegend” erscheint. Genau dieses stille Ergänzen ist der Kern des Kontexttreue-Problems aus dem vorigen Abschnitt.
4. Unsicherheit benennen statt glätten. Bei mehreren, sich widersprechenden Fundstellen soll das Modell den Widerspruch benennen, statt sich für eine Version zu entscheiden. Das ist unbequemer für die Nutzererfahrung, aber der einzige ehrliche Umgang mit einer echten Dateninkonsistenz.

Wichtig für die Erwartungshaltung: Ein Prompt ist eine Verhaltensanweisung, kein Filter. Er kann die Tendenz des Modells verschieben, garantiert aber nicht, dass jede Ausgabe der Anweisung folgt – gerade bei langen, mehrdeutigen oder in sich widersprüchlichen Kontexten. Prompt-Engineering ersetzt keine saubere Wissensbasis, es setzt auf ihr auf.

Wann darf es nicht antworten?

Die wichtigste Designentscheidung für ein RAG-System ist oft nicht, wie es antwortet, sondern wann es das lassen sollte. Aus den bisherigen Abschnitten lassen sich vier Situationen ableiten, in denen ein RAG-System keine inhaltliche Antwort geben sollte, sondern das Fehlen von belastbarem Kontext offenlegen muss:

• Kein ausreichend relevanter Treffer. Wenn der Retriever keine Chunks findet, deren semantische Nähe zur Anfrage über einer sinnvollen Schwelle liegt, sollte das System das offen sagen, statt mit schwach passenden Fundstellen eine Antwort zu konstruieren.
• Ungelöster Widerspruch zwischen Quellen. Wenn zwei oder mehr Referenzdokumente sich widersprechen und keine Priorisierungsregel (Aktualität, Dokumenttyp, Freigabestatus) vorliegt, ist eine einzelne, glatt klingende Antwort irreführender als ein Hinweis auf den Widerspruch.
• Sensible personenbezogene oder rechtlich heikle Fragen. Bei Fragen mit Personenbezug oder rechtlicher, medizinischer oder personalbezogener Tragweite sollte ein RAG-System auf menschliche Prüfung verweisen, statt eine automatisierte Einzelfallentscheidung zu produzieren. Das BSI empfiehlt allgemein, bei sensiblen Daten grundsätzlich davon auszugehen, dass alles, worauf ein Modell Zugriff hat, potenziell abgegriffen werden kann – ein zusätzlicher Grund für Zurückhaltung bei automatisierten Ausgaben in diesem Bereich.
• Fragen außerhalb des geprüften Dokumentenbestands. Fragen zu Themen, die erkennbar außerhalb der aktuell eingebundenen Wissensbasis liegen (etwa aktuelle Ereignisse ohne entsprechendes Referenzdokument), sollten nicht mit dem allgemeinen Trainingswissen des Modells beantwortet werden, wenn der Anspruch des Systems „nur geprüfte interne Informationen” lautet.

Diese vier Regeln lassen sich technisch über Schwellenwerte im Retrieval, Systemprompt-Instruktionen und – bei kritischen Anwendungsfällen – eine Freigabeschleife durch Menschen umsetzen. Kein RAG-System sollte in einem produktiven Setting ohne mindestens die ersten beiden Regeln live gehen.

Umsetzung: Grounding in fünf Schritten reduzieren

So gehe ich vor, wenn ein RAG-Vorhaben von Anfang an auf möglichst geringe Halluzinationsrate ausgelegt werden soll:

1. Wissensbasis kuratieren, nicht nur befüllen. Nur vertrauenswürdige, aktuelle Dokumente aufnehmen; für jedes Dokument einen Verantwortlichen und ein Aktualisierungsintervall festlegen. Das ist die mit Abstand wirksamste Einzelmaßnahme, weil sie an der von der Datenschutzkonferenz benannten Hauptursache ansetzt.
2. Chunking und Embedding testen, nicht raten. Chunk-Größe und Überlappung an typische Fragen anpassen, Embedding-Modell auf Sprachpassung prüfen. Ein falsch gewähltes Embedding-Modell für deutschsprachige Dokumente kostet Trefferqualität, die keine Prompt-Anweisung mehr ausgleicht.
3. Systemprompt restriktiv formulieren. Die vier Bausteine aus dem Prompt-Abschnitt oben – Verweigerungsanweisung, Quellenpflicht, kein Rückgriff auf Modellwissen, Unsicherheit benennen – als festen Bestandteil des Systemprompts verankern und bei jeder Modelländerung erneut testen.
4. Quellenangaben sichtbar machen. Jede Antwort mit den zugrunde liegenden Textauszügen oder zumindest den Quelldokumenten ausliefern. Das ist laut BSI eine wirksame Gegenmaßnahme gegen Halluzinationseffekte und macht Prüfung durch Nutzende überhaupt erst möglich.
5. Retrieval-Schwellenwerte und Rückzugsverhalten definieren. Festlegen, ab welcher Ähnlichkeit ein Treffer als „ausreichend relevant” gilt, und ein sauberes Antwortverhalten für den Fall darunter programmieren – inklusive der vier Situationen aus dem vorigen Abschnitt.

Wenn du dabei Unterstützung willst: Im Rahmen der KI-Beratung prüfe ich RAG-Vorhaben genau entlang dieser fünf Schritte, und in den Schulungen lernt dein Team, Systemprompts und Wissensbasis danach selbst zu pflegen. Für eine erste Einschätzung deines RAG-Piloten reicht ein kurzes Erstgespräch.

Risikomatrix: Halluzinationsquellen und Gegenmaßnahmen

Die folgende Matrix ist mein Arbeitswerkzeug, um Halluzinationsrisiken in RAG-Projekten zu priorisieren. Sie ersetzt keine technische Einzelfallprüfung, sortiert aber die Diskussion mit Entwicklung und Fachbereich:

Risikoquelle	Wo sie entsteht	Warnsignal in der Praxis	Wichtigste Gegenmaßnahme
Veraltete Referenzdokumente	Wissensbasis-Pflege	Antworten widersprechen aktuellen internen Regeln	Aktualisierungsintervall je Dokument, klarer Owner
Unvollständige Dokumentenbasis	Wissensbasis-Aufbau	System antwortet zu Themen, für die keine Quelle existiert	Abdeckungsprüfung vor Go-Live, Verweigerungsanweisung
Schlechtes Chunking	Datenaufbereitung	Antworten wirken abgeschnitten oder aus dem Zusammenhang gerissen	Chunk-Größe/Überlappung testen, Kopf-/Fußzeilen bereinigen
Embedding-Sprachmismatch	Modellwahl	Relevante Dokumente werden bei korrekten Fragen nicht gefunden	Embedding-Modell für Zielsprache validieren
Geringe Kontexttreue bei Widersprüchen	LLM-Komponente	Antwort folgt sichtbar dem allgemeinen Modellwissen statt der Quelle	Restriktiver Systemprompt, Priorisierungsregel zwischen Quellen
Komplexe Zusammenhänge über mehrere Chunks	RAG-Architektur	Antwort ist logisch unvollständig, obwohl Information vorhanden war	Chunk-Überlappung erhöhen, iteratives Retrieval prüfen
Fehlende Quellenangaben	Ausgabegestaltung	Nutzende können Antworten nicht prüfen, Vertrauen sinkt	Textauszüge/Dokumentreferenz in jeder Antwort anzeigen
Erfundene Zitate oder Referenzen	LLM-Komponente	Antwort verweist auf Quellen, die es in der Wissensbasis nicht gibt	Zitatprüfung gegen tatsächlich abgerufene Chunks
Manipulierte Wissensbasis (Knowledge Poisoning)	Dokumenteneinspeisung	Plausible, aber falsche Antworten zu einzelnen, gezielten Fragen	Nur vertrauenswürdige Quellen, kontrollierter Einspeiseprozess
Externe Datenquellen ohne Prüfung	Retrieval-Erweiterung	Antworten wirken aktuell, aber Herkunft ist nicht nachvollziehbar	Rechtmäßigkeit und Richtigkeit externer Quellen vorab prüfen

Die ersten vier Zeilen entscheiden in den meisten KMU-Projekten darüber, wie hoch die Halluzinationsrate im Alltag tatsächlich ausfällt – sie gehören an den Anfang jeder Fehleranalyse.

Risiken und Grenzen

Zur ehrlichen Einordnung gehören auch die Punkte, die weder RAG noch dieser Artikel lösen:

• Keine vollständige Ausschließbarkeit. Die Datenschutzkonferenz stellt klar fest, dass trotz RAG nicht vollständig ausgeschlossen werden kann, dass ein Sprachmodell weiterhin unrichtige Informationen ausgibt. RAG ist eine Risikominderung, kein Beweis der Richtigkeit.
• Intransparenz auf Modellebene. Wie ein Sprachmodell aus einer erweiterten Anfrage konkret eine Ausgabe erzeugt, bleibt laut Datenschutzkonferenz sehr schwer nachvollziehbar. Auch für die in der Vektordatenbank gespeicherten Embeddings gilt: Es lässt sich nicht erklären, warum ein Chunk welchen Vektor erhält. Die Transparenz eines RAG-Systems beschränkt sich darauf, zu zeigen, welche Quellen in die Anfrage eingeflossen sind – nicht, wie das Modell daraus die Antwort formt.
• Das Trainings-Erbe bleibt. Ein RAG-System ändert nichts an den Eigenschaften der zugrunde liegenden LLM-Komponente. Risiken, die aus dem Training des Modells stammen, bestehen unabhängig vom RAG-Aufbau fort.
• Neue Angriffsfläche durch die Wissensbasis. Mit RAG kommt laut BSI zugleich ein neues Risiko dazu: die gezielte Manipulation der hinterlegten Wissensdaten. Wer eine Wissensbasis aufbaut, muss sie auch gegen Missbrauch absichern, nicht nur gegen Veralterung.
• Bewegliche Faktenlage. Beide zugrunde liegenden Orientierungshilfen sind Stand 2025 und werden fortgeschrieben. Technische Gegenmaßnahmen wie iteratives Retrieval über KI-Agenten-Systeme, die Widersprüche über mehrere Anfragen hinweg auflösen sollen, befinden sich noch in der praktischen Erprobung. Plane für dieses Thema eine regelmäßige Überprüfung deiner Bewertung ein – der nächste Review-Termin für diesen Artikel steht nach drei Monaten im Kalender.

Checkliste: Halluzinationsrisiko in RAG-Systemen senken

Zum Abhaken vor dem Aufbau, während des Betriebs und bei jeder größeren Änderung:

Vor dem Aufbau

• Dokumentenbestand auf Aktualität und Vollständigkeit geprüft, Owner je Dokument benannt
• Priorisierungsregel zwischen widersprüchlichen oder sich überschneidenden Quellen festgelegt
• Embedding-Modell auf Sprachpassung zum Dokumentenbestand geprüft
• Nur vertrauenswürdige Dokumentquellen für die Einspeisung zugelassen

Beim Aufbau

• Chunk-Größe und Überlappung anhand typischer Nutzerfragen getestet
• Kopf-/Fußzeilen und Formatierungsrauschen vor dem Embedding bereinigt
• Systemprompt mit Verweigerungsanweisung, Quellenpflicht und Ausschluss von Modellwissen formuliert
• Retrieval-Schwellenwert für „ausreichend relevant” definiert und getestet

Beim Betrieb

• Quellenangaben/Textauszüge in jeder Antwort sichtbar
• Rückzugsverhalten für die vier Nicht-Antworten-Situationen implementiert und geprüft
• Regelmäßiger Aktualisierungszyklus für die Referenzdokumente eingerichtet
• Stichprobenprüfung von Antworten gegen zitierte Quellen etabliert
• Review-Termin für diese Bewertung eingeplant

Wenn du deinen RAG-Piloten vor dem Start einmal strukturiert auf Halluzinationsrisiken prüfen lassen willst – genau dafür ist der Erstcheck da.