Vertrauenswürdige RAG-Antworten: Zitate, Belege und der Weg zur Ablehnung

Retrieval-Augmented Generation (RAG) gibt einem Sprachmodell ausgewählten Quellenkontext, bevor es eine Antwort erzeugt. Im Vergleich zu Antworten, die nur auf allgemeinen Trainingsdaten beruhen, kann dieser Ansatz aktueller und stärker auf eine bestimmte Domäne bezogen sein. Es gibt jedoch einen wichtigen Unterschied: Ein Quellenfragment neben einer Antwort bedeutet nicht, dass die Quelle diese Antwort tatsächlich stützt.

Für Nutzer eines Produkts ist der Unterschied groß. „Das Modell hat ein Dokument gefunden“ und „Dieser Satz wird durch diesen Abschnitt des Dokuments gestützt“ sind nicht dasselbe Vertrauensniveau. In Bereichen, in denen Fehler teuer sind—etwa Recht, Bildung, Finanzen, Gesundheit oder internes Unternehmenswissen—sollte eine RAG-Funktion nicht nur antworten, sondern für jede wichtige Aussage prüfbare Belege liefern.

Retrieval ist kein Beweis

Die Retrieval-Schicht liefert Textfragmente, die Kandidaten für eine Anfrage sind. Diese Kandidaten können richtig sein, aber auch veraltet, unvollständig, aus dem Zusammenhang gerissen oder nur oberflächlich mit der Frage verbunden. Ein Ähnlichkeitswert zeigt sprachliche Nähe zur Anfrage; er beweist nicht, dass der Text die Antwort stützt.

Das erste Designprinzip ist deshalb einfach: Jedes gefundene Fragment ist ein Beweiskandidat. Beim Formulieren der Antwort darf das Modell keine Schlussfolgerung als sicher darstellen, wenn der Text sie nicht ausdrücklich sagt. Fehlt eine ausreichende Grundlage, ist die Fähigkeit des Systems zu sagen „Ich habe keine Quelle gefunden, die das bestätigt“ wertvoller als eine längere Antwort ohne Nachweis.

Quelldaten als Produktvertrag behandeln

Eine überprüfbare Antwort beginnt vor dem Modellaufruf. Jedes Dokumentfragment sollte nicht nur seinen Text, sondern auch den Kontext bewahren, mit dem es wiedergefunden werden kann. Mindestens diese Felder sind hilfreich:

• Dokument-ID, Titel, Version und Gültigkeitsdatum,
• eine für Menschen verständliche Position wie Abschnitt, Seite oder Klausel,
• der genaue Textbereich oder Anfang und Ende eines Zitats,
• Quellentyp und Zugriffsberechtigung,
• Indexierungszeit und Beziehung zu einer vorherigen Version.

Diese Metadaten dienen nicht nur zur Anzeige einer Quellenkarte, sondern auch der Sicherheit. Ein Dokument, das ein Nutzer nicht lesen darf, darf nicht in einer Antwort oder Zitatliste erscheinen, nur weil es im Retrieval auftaucht. Die RAG-Schicht darf keine Hintertür um das bestehende Identitäts- und Berechtigungsmodell der Anwendung werden.

Zitate an Aussagen binden, nicht nur an Antworten

Fünf Links am Ende einer Antwort sagen Lesern nicht, welche Aussage auf welchem Text beruht. Besser ist es, jede wichtige überprüfbare Aussage oder jeden Aufzählungspunkt mit einer Quellen-ID zu verbinden.

Wenn ein System zum Beispiel drei Schlussfolgerungen zu einer Richtlinie liefert, sollte jede Schlussfolgerung den passenden Dokumentabschnitt öffnen. Diese Verbindung besteht aus zwei Teilen: der vom Modell gelieferten Aussage und dem Originaltextfragment, das als Beleg akzeptiert wird. Beim Öffnen eines Zitats sollten Nutzer mehr als einen Dokumentnamen sehen—idealerweise den genauen Absatz und die Position.

Ein Prompt kann dieses Verhalten fördern. Dem Modell kann vorgegeben werden, nur Informationen aus dem bereitgestellten Kontext zu verwenden, fehlende Details nicht zu erraten und unbelegte Fragen abzulehnen. Ein Prompt ist jedoch allein kein Sicherheitsmechanismus. Auch die Ausgabestruktur sollte das Muster erzwingen: Für jede Aussage können Felder wie sourceId, Textbereich und Belegstatus definiert werden.

Einen zweiten Prüfschritt hinzufügen

Auch ein vom Modell erzeugtes Zitat kann falsch sein. Bei Anwendungen mit höherem Risiko sollte nach der Generierung ein unabhängiger Prüfschritt folgen. Der Prüfer betrachtet die Aussage, den zitierten Text und bei Bedarf einen größeren Dokumentkontext.

Ziel ist nicht, literarische Ähnlichkeit zu berechnen. Die praktische Frage lautet: Stützt diese Quelle diese Aussage wirklich? Wenn nicht, kann das System die Aussage entfernen, vorsichtiger formulieren oder mitteilen, dass kein ausreichender Beleg gefunden wurde.

Dadurch werden Kennzahlen wie Zitatabdeckung und Zitatkorrektheit möglich. Die erste misst, wie viele wichtige Aussagen mit einer Quelle verbunden sind; die zweite, ob diese Quellen tatsächlich passend sind. Nur die Zufriedenheit mit einer Antwort zu messen, kann solche Fehler unsichtbar lassen.

Ablehnung und Unsicherheit sind Produktfähigkeiten

RAG-Systeme verbergen ein leeres oder schwaches Retrieval-Ergebnis oft hinter einem überzeugenden Absatz. Ein Produktablauf sollte Situationen stattdessen klar unterscheiden:

• Ohne relevante Quelle sollte das System nicht antworten.
• Bei teilweisen Quellen sollte es Unterstütztes und Unbekanntes trennen.
• Wenn Dokumente widersprüchlich sind, sollte der Widerspruch sichtbar werden und Unterschiede bei Version, Datum oder Umfang gezeigt werden.
• Ist eine Quelle alt, sollte die Antwort ihre Aktualitätsgrenze nennen.

Kurzfristig scheint das weniger selbstsichere Antworten zu erzeugen. Langfristig lernen Nutzer dadurch die Grenze des Systems kennen, und Vertrauen basiert auf etwas Stabilerem als zufälliger Selbstsicherheit.

Belege in der Nutzererfahrung sichtbar machen

Quellen sollten nicht hinter einem getrennten technischen Bildschirm versteckt werden. Markierungen im Text, aufklappbare Zitate, Abschnittslinks und Angaben zur Dokumentversion laden Nutzer zur Prüfung ein. Die Oberfläche sollte aber nicht zu einem Linkstapel werden: Zitate nur an Aussagen anzuhängen, die eine Entscheidung beeinflussen, erhält die Lesbarkeit.

Für das Team sollte jede Antwort über Retrieval-Anfrage, ausgewählte Fragmente, Modellversion, Prompt-Version und Prüfergebnis nachvollziehbar bleiben. Fragt ein Nutzer „Warum habe ich dieses Ergebnis bekommen?“, sollte nicht nur der Endtext, sondern auch die Kette dorthin sichtbar sein.

Klein beginnen und messen

Statt eine gesamte Wissensbasis auf einmal an RAG anzuschließen, ist ein enger, klar definierter Anwendungsfall sicherer. Ein Evaluationsset mit zwanzig Beispielfragen sollte Fälle mit richtiger Quelle, falscher Quelle, teilweiser Quelle und ohne Quelle enthalten. Wird dasselbe Set bei jeder Version ausgeführt, zeigt sich, wie Änderungen an Retrieval oder Prompt die Qualität beeinflussen.

Vertrauenswürdiges RAG bedeutet nicht, längere Antworten zu erzeugen. Es bedeutet, die Distanz zwischen dem, was die Quelle sagt, und dem, was das Modell sagt, zu verringern. Produkte, die Belege im Datenmodell, im Ausgabeschema, im Prüfschritt und in der Oberfläche verankern, geben Nutzern mehr als eine Antwort: Sie geben ihnen eine Begründung, die sie selbst prüfen können.