Quellenangaben in RAG-Systemen: Nachvollziehbare Antworten bauen

„Unsere KI zeigt bei jeder Antwort die Quellen an” – dieser Satz fällt in fast jedem Verkaufsgespräch über RAG-Systeme (Retrieval-Augmented Generation). Er stimmt auch fast immer. Nur beantwortet er nicht die eigentliche Frage: Belegt die angezeigte Quelle tatsächlich die konkrete Aussage in der Antwort, oder ist sie nur ein Verweis auf ein Dokument, das irgendwo in der Nähe des Themas lag? Zwischen einer Quellenliste und einer nachprüfbaren Antwort liegt technischer Aufwand, den viele Projekte überspringen.

Dieser Artikel gehört zum Themen-Cluster RAG und Wissensdatenbanken. Er beantwortet konkret: Wie werden Quellen referenziert, wie verknüpft man eine Aussage mit ihrer Textstelle, wie prüft man Zitatstreue, welche Metadaten braucht es dafür – und was eine Quellenangabe eben nicht zeigt.

Problem und Zielgruppe: Wenn die Quellenliste nichts beweist

Der Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die ein RAG-System einführen, betreiben oder von einem Anbieter angeboten bekommen – also an alle, die am Ende verantworten müssen, ob eine KI-gestützte Antwort im Kundenservice, im internen Support oder in der Angebotserstellung stimmt.

Das typische Muster: Ein RAG-Chatbot gibt eine Antwort und darunter eine Liste von drei Dokumenten. Das wirkt vertrauenswürdig – ist es aber nur, wenn zwei Dinge stimmen. Erstens: Die Antwort stammt tatsächlich aus diesen Dokumenten und nicht (auch) aus dem allgemeinen Trainingswissen des Sprachmodells. Zweitens: Jede einzelne Aussage in der Antwort lässt sich einer konkreten Stelle in einem dieser Dokumente zuordnen, nicht nur das Dokument als Ganzes dem Thema. Viele RAG-Implementierungen erfüllen keines von beidem zuverlässig – sie zeigen Dokumente an, die beim Retrieval gefunden wurden, unabhängig davon, ob das Sprachmodell sie für die konkrete Aussage tatsächlich genutzt hat.

Das Problem ist keine Nebensache. Sobald eine RAG-Antwort in eine Entscheidung einfließt – eine Kundenauskunft, eine interne Richtlinienauslegung, eine Aussage gegenüber einer Behörde – wird die Frage „woher stammt das?” zur Haftungsfrage. Eine Quellenliste, die diese Frage nicht ehrlich beantwortet, ist schlimmer als keine: Sie erzeugt Vertrauen, das nicht gedeckt ist.

Begriffe kurz geklärt: Referenzierung, Grounding, Zitatstreue

Für den Rest des Artikels drei Begriffe klar getrennt:

• Referenzierung ist die technische Verknüpfung zwischen einer Textstelle (Chunk) in der Vektordatenbank und ihrem Ursprungsdokument. Sie entsteht bei der Datenaufbereitung, nicht erst bei der Antwortgenerierung.
• Grounding (Verankerung) beschreibt, ob eine generierte Aussage tatsächlich auf den gefundenen Textstellen beruht – im Unterschied zu Inhalten, die das Sprachmodell aus seinem Training ergänzt, kombiniert oder frei erzeugt.
• Zitatstreue ist die Eigenschaft, mit der ein System eine referenzierte Textstelle inhaltlich korrekt wiedergibt, statt sie zu verkürzen, umzudeuten oder mit anderem Wissen zu vermischen.

Diese drei Ebenen sind unabhängig voneinander erfüllbar oder nicht erfüllbar. Ein System kann technisch sauber referenzieren (jeder Chunk hat eine ID und einen Dokumentverweis) und trotzdem schlecht grounden (das Sprachmodell ignoriert die Chunks bei Widersprüchen zu seinem Trainingswissen). Genau diese Lücke beschreibt die Datenschutzkonferenz in ihrer Orientierungshilfe zu RAG-Systemen: Die Kontexttreue eines Sprachmodells hängt davon ab, wie das System konzipiert ist, und Modelle können „insbesondere bei widersprüchlichen Inhalten das Wissen aus den Trainingsdaten wiedergeben und die Inhalte aus den Referenzdokumenten verwerfen”.

Wie werden Quellen referenziert?

Referenzierung beginnt nicht bei der Antwort, sondern bei der Datenaufbereitung. Referenzdokumente werden in Textabschnitte (Chunks) zerlegt, jeder Chunk wird per Embedding-Modell in einen Vektor überführt und zusammen mit einer eindeutigen Kennung in der Vektordatenbank gespeichert. Diese Kennung – nicht der Chunk-Inhalt selbst – ist die eigentliche Referenz: Sie verweist auf Dokumenttitel, Abschnitt und im Idealfall die genaue Position im Ursprungsdokument.

Bei der Anfrage durchsucht der Retriever die Vektordatenbank nach semantisch passenden Chunks und gibt sie inklusive ihrer Kennung an das Sprachmodell weiter. Damit eine Antwort tatsächlich referenziert wird, muss diese Kennung zwei Stationen überstehen:

1. Im Prompt an das Sprachmodell. Die übergebenen Chunks müssen mit ihrer ID markiert sein, und der Systemprompt muss das Modell explizit anweisen, jede Aussage mit der ID des stützenden Chunks zu kennzeichnen. Ohne diese Anweisung generiert das Modell einen flüssigen Text ohne innere Zuordnung – die angezeigte Quellenliste wird dann nachträglich aus den insgesamt abgerufenen Chunks zusammengestellt, unabhängig davon, welche davon die Antwort tatsächlich gestützt haben.
2. In der Anzeige für Nutzende. Die Kennung wird in eine für Menschen nachvollziehbare Form übersetzt: Dokumentname, Abschnitt, Datum, im besten Fall ein anklickbarer Link zur genauen Stelle statt nur zum Dokumentanfang.

Der entscheidende Unterschied für die Praxis: Referenzierung auf Dokumentebene („diese Antwort stammt aus drei Dokumenten”) ist technisch einfach und in praktisch jedem RAG-System vorhanden. Referenzierung auf Aussage-Ebene („dieser Satz stammt aus Chunk 14 von Dokument X”) erfordert einen Systemprompt, der das explizit verlangt, und eine Anzeigelogik, die das im Frontend auch abbildet. Viele Standardlösungen bleiben bei der ersten, einfacheren Stufe – und genau diese Lücke ist der unique angle dieses Artikels: Eine Quellenliste ist nutzlos, wenn sie die konkrete Aussage nicht stützt.

Wie verknüpft man Antwort und Textstelle?

Praktisch läuft die Verknüpfung über drei Bausteine, die zusammen funktionieren müssen:

Chunk-IDs im Prompt-Format. Jeder an das Sprachmodell übergebene Textabschnitt wird mit einer maschinenlesbaren Markierung versehen, etwa [Quelle: Dok-47, Abschnitt 3.2]. Das Sprachmodell wird angewiesen, diese Markierung direkt hinter jeder gestützten Aussage zu wiederholen.

Ein restriktiver Systemprompt. Die Datenschutzkonferenz nennt als technische Gegenmaßnahme gegen das Verwerfen von Referenzinhalten explizit einen Systemprompt, der das RAG-System anweist, „ausschließlich mithilfe der referenzierten Quellen zu antworten”. Das reduziert das Risiko, dass Trainingswissen unmarkiert in die Antwort einfließt, schließt es aber nicht vollständig aus.

Nachgelagerte Prüfung statt blindem Vertrauen. Selbst mit guter Prompt-Gestaltung bleibt die Verknüpfung eine Anweisung an ein probabilistisches System – keine Garantie. In meiner Arbeit sehe ich am häufigsten den Fehler, dass Teams die Chunk-Referenzen im Prompt für ausreichend halten und keine Stichprobenprüfung einbauen. Ein einfacher, aber wirksamer Kontrollmechanismus: Bei jeder n-ten Antwort wird automatisiert oder manuell geprüft, ob die zitierten Chunk-IDs die jeweilige Aussage tatsächlich stützen.

Bei der Chunk-Bildung selbst entscheidet sich vorab, wie präzise diese Verknüpfung überhaupt sein kann. Kleine, thematisch abgeschlossene Chunks lassen sich exakter referenzieren als große Textblöcke, in denen mehrere Aussagen stecken – dafür verlieren zu kleine Chunks oft den Kontext, den sie brauchen, um überhaupt gefunden zu werden. Diesen Zielkonflikt zwischen Präzision und Kontext löst kein Standardwert; er wird pro Anwendungsfall austariert.

Wie prüft man Zitatstreue?

Zitatstreue prüfst du nicht am System insgesamt, sondern an konkreten Antworten – idealerweise mit einer festen Prüflogik, die sich wiederholen lässt. Die folgende Matrix ist unser eigenes Werkzeug dafür, das sich in Kundenprojekten bewährt hat:

Prüfschritt	Leitfrage	Ergebnis „stützt”	Ergebnis „stützt nicht”
1. Aussage isolieren	Welche einzelne Behauptung in der Antwort wird geprüft?	Eine klar abgrenzbare Aussage, kein ganzer Absatz	–
2. Referenzierte Textstelle öffnen	Steht dort der Inhalt, auf den sich die Aussage stützt?	Inhalt ist wörtlich oder sinngemäß enthalten	Inhalt fehlt, ist gegenteilig oder nur thematisch verwandt
3. Vollständigkeit prüfen	Fehlt eine wichtige Einschränkung, die im Original stand?	Einschränkungen wurden übernommen	Bedingungen, Ausnahmen oder Zeitbezüge wurden weggelassen
4. Fremdwissen erkennen	Enthält die Aussage Zahlen, Namen oder Details, die in der Textstelle nicht vorkommen?	Nein, alles ist im Chunk belegt	Ja – das Modell hat ergänzt oder kombiniert
5. Aktualität abgleichen	Ist die Textstelle noch der aktuelle Stand, oder wurde das Referenzdokument seither geändert?	Stand aktuell	Referenzdokument veraltet

Eigene Prüfmatrix Philogic Labs für die stichprobenhafte Kontrolle von RAG-Antworten.

Diese fünf Schritte lassen sich in unter zwei Minuten pro Aussage durchführen – der Aufwand entsteht nicht durch die Prüfung selbst, sondern dadurch, dass sie regelmäßig und nicht nur einmalig beim Rollout gemacht werden muss. Modelle, Chunking-Konfiguration und Referenzdokumente ändern sich; eine Zitatstreue-Prüfung, die vor sechs Monaten gut aussah, sagt wenig über den heutigen Zustand.

Für risikoarme, interne Use Cases reicht eine monatliche Stichprobe von zehn bis zwanzig Antworten. Bei Antworten mit rechtlicher oder finanzieller Relevanz – etwa gegenüber Kund:innen oder Behörden – gehört eine Zitatstreue-Prüfung als fester Schritt in den Freigabeprozess, nicht nur ins Monitoring.

Welche Metadaten sind nötig?

Metadaten sind die Grundlage, ohne die weder Referenzierung noch Zitatstreue-Prüfung möglich sind. Die folgende Übersicht zeigt, was mindestens vorhanden sein muss und was situativ dazukommt:

Metadatenfeld	Zweck	Pflicht oder situativ
Chunk-ID	Eindeutige technische Referenz zwischen Antwort und Textstelle	Pflicht
Dokumenttitel und Quelle	Menschlich lesbare Zuordnung, Anzeige in der Antwort	Pflicht
Abschnitt oder Seitenangabe	Ermöglicht das Auffinden der exakten Stelle, nicht nur des Dokuments	Pflicht für belastbare Nachprüfbarkeit
Stand- oder Versionsdatum	Zeigt, ob die referenzierte Information noch aktuell ist	Pflicht
Freigabestatus	Verhindert, dass Entwürfe oder interne Notizen als belastbare Quelle erscheinen	Situativ, aber wichtig bei gemischten Dokumentbeständen
Zugriffsberechtigung	Steuert, wem eine Quelle überhaupt angezeigt werden darf	Situativ, zwingend bei personenbezogenen oder vertraulichen Daten
Sprache des Ursprungsdokuments	Relevant für die Passung des Embedding-Modells und Fehlerdiagnose	Situativ

Eigene Zusammenstellung Philogic Labs, orientiert an Anforderungen aus Datenaufbereitung und Datenschutzpraxis in RAG-Projekten.

Zwei Punkte daraus verdienen Betonung. Erstens: Die Zugriffsberechtigung ist kein Nice-to-have. Wenn dein RAG-System Dokumente aus unterschiedlichen Abteilungen bündelt, kann die Anzeige einer Quelle selbst schon eine unerwünschte Offenlegung sein – etwa wenn ein Chatbot einer Person Einblick in ein Dokument gewährt, auf das sie regulär keinen Zugriff hätte. Zweitens: Ohne Stand- oder Versionsdatum kann eine noch so sauber referenzierte Antwort trotzdem falsch sein, weil sich das Ursprungsdokument seither geändert hat, die Vektordatenbank aber nicht nachgezogen wurde.

Was zeigt eine Quelle nicht?

Das ist die unbequemste, aber wichtigste Frage – und der Grund, warum eine Quellenliste allein niemandem etwas beweist.

Eine Quelle zeigt nicht, dass das Modell sie korrekt verstanden hat. Referenzierung belegt, dass ein Chunk beim Retrieval gefunden und an das Modell übergeben wurde. Sie belegt nicht, dass das Modell ihn richtig gelesen, nicht verkürzt und nicht mit eigenem Trainingswissen vermischt hat. Genau hier liegt eines der größten praktischen Risiken generativer Sprachmodelle: Laut BSI stellen Halluzinationen im Kontext von Sprachmodellen ein großes Problem dar, „da die generierten Ausgaben zumeist glaubhaft erscheinen, insbesondere, wenn auf wissenschaftliche Publikationen oder andere Referenzen verwiesen wird, welche selbst frei erfunden sein können”. Eine angezeigte Quelle kann also existieren – und die Aussage daneben trotzdem falsch oder erfunden sein, ohne dass das auf den ersten Blick auffällt.

Eine Quelle zeigt nichts über die Qualität des Ursprungsdokuments. Ein RAG-System referenziert ein Dokument unabhängig davon, ob es veraltet, fehlerhaft oder aus zweifelhafter Quelle stammt. Die Datenschutzkonferenz weist entsprechend darauf hin, dass die Zuverlässigkeit von RAG-Systemen stark von Qualität, Aktualität und Vollständigkeit der verwendeten Referenzdokumente abhängt und Dokumente aus unbekannten oder nicht vertrauenswürdigen Quellen von vornherein nicht verwendet werden sollten. Referenzierung ersetzt keine Qualitätssicherung der Datenbasis.

Eine Quelle zeigt nichts über das, was nicht gefunden wurde. Der Retriever sucht nach semantischer Nähe, nicht nach logischer Vollständigkeit. Textstellen, die inhaltlich relevant wären, aber in einem anderen Vektorraum-Bereich liegen oder über mehrere Chunks verteilt sind, tauchen in der Trefferliste womöglich gar nicht auf – die Antwort wirkt trotzdem vollständig belegt, weil sie nur zeigt, was gefunden wurde, nicht, was fehlt.

Eine Quelle zeigt nicht die Funktionsweise des zugrundeliegenden Sprachmodells. Die Datenschutzkonferenz macht diese Grenze explizit: Transparenz in einem RAG-System beschränkt sich auf Aussagen über die erweiterte Anfrage an das Sprachmodell. Wie das Modell intern zu seiner konkreten Formulierung kommt und warum bestimmte Embeddings bestimmten Chunks zugeordnet werden, bleibt intransparent – Referenzierung schafft Nachvollziehbarkeit auf der Ebene des Inputs, nicht der internen Verarbeitung.

Diese vier Grenzen bedeuten nicht, dass Quellenangaben nutzlos sind – im Gegenteil, sie sind der einzige praktikable Hebel, um eine RAG-Antwort überhaupt überprüfbar zu machen. Sie bedeuten, dass eine angezeigte Quelle der Startpunkt einer Prüfung ist, nicht ihr Ergebnis.

Umsetzung: Vom Chunk zur nachvollziehbaren Antwort

In der Praxis lässt sich nachvollziehbare Referenzierung in vier Schritten aufbauen, die aufeinander aufbauen:

Schritt 1 – Datenaufbereitung mit Referenzierung von Anfang an. Chunk-IDs, Dokumenttitel, Abschnitt und Stand werden bereits bei der Aufteilung der Referenzdokumente vergeben, nicht nachträglich ergänzt. Störende Elemente wie Kopf- und Fußzeilen werden vorab bereinigt, damit sie nicht als vermeintlicher Inhalt referenziert werden. Chunks sollten möglichst abgeschlossene Sinnabschnitte enthalten – das erleichtert später sowohl das Retrieval als auch die Zitatstreue-Prüfung.

Schritt 2 – Prompt-Gestaltung mit Zitierpflicht. Der Systemprompt verlangt explizit, jede Aussage mit der zugehörigen Chunk-Referenz zu kennzeichnen, und weist das Modell an, ausschließlich mit den referenzierten Inhalten zu antworten. Fehlt eine Textstelle für eine Frage, soll das Modell das benennen, statt aus Trainingswissen zu ergänzen.

Schritt 3 – Anzeige, die tatsächlich nachprüfbar macht. Referenzen werden nicht nur als Liste unter der Antwort angezeigt, sondern pro Aussage – etwa als Fußnoten oder anklickbare Marker, die zur konkreten Textstelle springen. Wo das technisch nicht möglich ist, sollte zumindest die Zuordnung „diese Antwort stützt sich auf diese Abschnitte” erkennbar bleiben, nicht nur „diese Dokumente wurden durchsucht”.

Schritt 4 – Laufende Stichprobenprüfung mit der Prüfmatrix. Regelmäßig, nicht nur beim Go-Live, werden Antworten mit der oben beschriebenen Fünf-Schritte-Matrix geprüft. Auffälligkeiten – Chunks, die häufig falsch zugeordnet werden, oder Themen, bei denen das Modell trotz Anweisung auf Trainingswissen zurückgreift – fließen zurück in Chunking, Prompt oder Modellauswahl.

Wie lange dieser Aufbau dauert, hängt stark von Datenbasis und Systemlandschaft ab – seriös beziffern lässt sich das erst nach einer kurzen Bestandsaufnahme der vorhandenen Dokumente und Systeme. Für die Größenordnung: Ein fokussierter Pilot mit klar abgegrenztem Dokumentbestand (zum Beispiel eine Produktdokumentation oder ein interner Richtlinien-Ordner) lässt sich in Wochen aufsetzen; die Integration in ein gewachsenes, verteiltes Dokumentenmanagement mit unterschiedlichen Zugriffsrechten braucht spürbar länger. Wer diesen Aufbau nicht selbst leisten will oder kann, für den ist ein Erstgespräch zur KI-Beratung der schnellste Weg, den Aufwand für den eigenen Fall einzuschätzen.

Risiken und Grenzen

Ein paar Grenzen gehören ehrlich in diesen Artikel, statt sie zu verschweigen:

• Referenzierung ist kein Wahrheitsbeweis. Selbst ein technisch sauber referenziertes System kann Aussagen liefern, die die Textstelle falsch interpretieren. Referenzierung reduziert das Risiko und macht es prüfbar – sie eliminiert es nicht.
• Mehr Metadaten bedeuten mehr Pflegeaufwand. Jede zusätzliche Metadatenebene – Freigabestatus, Zugriffsrechte, Versionierung – muss gepflegt werden, wenn sich Dokumente ändern. Veraltete Metadaten sind gefährlicher als keine, weil sie falsche Sicherheit erzeugen.
• Zugriffsrechte über die Vektordatenbank hinweg sind technisch anspruchsvoll. Wenn unterschiedliche Nutzendengruppen unterschiedliche Zugriffsrechte auf die Ursprungsdokumente haben, muss diese Trennung im gesamten RAG-Subsystem konsistent durchgesetzt werden – nicht nur im Dokumentenarchiv, sondern auch in der Vektordatenbank und in der Antwortanzeige.
• Externe oder unbekannte Quellen untergraben jede Referenzierungslogik. Bindet ein System zusätzlich externe Datenquellen ein, etwa per Websuche, lässt sich deren Rechtmäßigkeit, Eignung und Richtigkeit oft nicht im gleichen Maß prüfen wie bei kuratierten internen Referenzdokumenten. Das kann Antworten aktueller wirken lassen, ohne dass sich das positiv auf ihre Richtigkeit auswirkt.
• Rechtlicher Rahmen (Stand Juli 2026, keine Rechtsberatung): Werden personenbezogene Daten über RAG referenziert oder angezeigt, gelten die üblichen DSGVO-Anforderungen – Rechtsgrundlage, Zweckbindung, Betroffenenrechte. Eine sauber referenzierte Quelle macht die Verarbeitung nicht automatisch datenschutzkonform; sie ist eine technische Voraussetzung für Transparenz, keine rechtliche Absicherung. Im Zweifel gehört diese Bewertung zu Datenschutzbeauftragten oder Rechtsberatung.

Checkliste: Quellenangaben in RAG-Systemen prüfen

1. Jeder Chunk in der Vektordatenbank trägt eine eindeutige ID mit Verweis auf Dokument, Abschnitt und Stand.
2. Der Systemprompt verlangt explizit eine Kennzeichnung jeder Aussage mit der stützenden Chunk-Referenz.
3. Der Systemprompt weist das Modell an, ausschließlich mit den referenzierten Inhalten zu antworten und fehlende Belege zu benennen.
4. Referenzen werden pro Aussage angezeigt, nicht nur als allgemeine Dokumentenliste unter der Antwort.
5. Metadaten umfassen mindestens Chunk-ID, Dokumenttitel, Abschnitt und Stand-/Versionsdatum.
6. Bei personenbezogenen oder vertraulichen Daten sind Freigabestatus und Zugriffsberechtigung als Metadaten hinterlegt und werden bei der Anzeige durchgesetzt.
7. Eine feste Prüflogik (zum Beispiel die Fünf-Schritte-Matrix) wird regelmäßig auf Stichproben angewendet, nicht nur beim Rollout.
8. Auffälligkeiten aus der Prüfung fließen zurück in Chunking, Prompt-Gestaltung oder Modellauswahl.
9. Externe oder unbekannte Datenquellen werden getrennt von kuratierten internen Referenzdokumenten behandelt und geprüft.
10. Bei Antworten mit rechtlicher oder finanzieller Relevanz ist die Zitatstreue-Prüfung Teil des Freigabeprozesses, nicht nur des Monitorings.

Wer diesen Aufbau lieber mit Unterstützung angeht als komplett selbst zu entwickeln: Ein kostenloses Erstgespräch klärt in kurzer Zeit, wo dein RAG-Vorhaben bezüglich Referenzierung und Zitatstreue steht und was ein sinnvoller nächster Schritt wäre. Team-Schulungen zum sicheren Umgang mit RAG-Antworten bieten wir separat über unsere Schulungen an.