RAG-Systeme evaluieren: Retrieval, Antwortqualität und Quellenbezug

Das Wichtigste in Kürze:

• RAG Evaluation prüft 3 Ebenen: Retrieval, Antwortqualität und Quellenbezug.
• Ein Golden Question Set macht Tests wiederholbar statt zufällig.
• Quellenbezug heißt: Jede Aussage muss durch die gefundenen Quellen gedeckt sein.
• Menschliche Stichproben bleiben Pflicht, vor dem Start und im Betrieb.

Eine Demo mit 5 gut vorbereiteten Fragen sagt wenig darüber aus, ob ein RAG-System im Alltag hält, was es verspricht. Wer eine interne Wissensdatenbank mit Retrieval Augmented Generation aufbaut, steht früher oder später vor einer Frage. Funktioniert das System auch bei den 100 Fragen, die niemand vorher getestet hat? Genau hier setzt RAG Evaluation an.

Du lässt ein RAG-System auf 3 Ebenen prüfen. Die Retrieval-Ebene fragt: Findet das System die passenden Textabschnitte zur Anfrage? Die Antwortebene fragt: Ist die Antwort korrekt, vollständig und ohne Widerspruch zu den gefundenen Quellen? Die Quellenebene fragt: Stimmen die angezeigten Belege wirklich mit der Antwort überein? Erst alle 3 zusammen ergeben ein belastbares Bild. Eine gut klingende Antwort auf falscher oder erfundener Quelle bleibt ein Fehler, den eine reine Demo fast nie zeigt.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU. Gemeint sind Teams, die ein RAG-System nicht nur einführen, sondern verantwortlich betreiben wollen, etwa als internes Wissenssystem oder als Assistent im Kundensupport. Er beantwortet 5 Fragen: Welche Ebenen werden evaluiert? Was ist ein Golden Question Set? Wie misst man Retrieval, wie prüft man Quellenbezug, und welche Rolle spielt menschliche Bewertung? Ziel ist ein nachvollziehbares Vorgehen statt Bauchgefühl.

Begriffe kurz geklärt

Vorab eine kurze Abgrenzung der wichtigsten Begriffe. Wir nutzen sie so, wie sie auch die Datenschutzkonferenz in ihrer Orientierungshilfe zu RAG-Systemen verwendet.

• Retrieval ist der Suchschritt: Aus der Nutzeranfrage wird ein Anfragevektor gebildet, mit dem eine Vektordatenbank nach inhaltlich ähnlichen Textabschnitten (Chunks) durchsucht wird.

• Referenzdokumente sind die Quellen, aus denen die Chunks stammen. Bei einer internen Wissensdatenbank sind das typischerweise Handbücher, Richtlinien, FAQ-Sammlungen oder Vertragsvorlagen.

• Generierte Antwort ist der Text, den das Sprachmodell aus Nutzeranfrage und gefundenen Chunks erzeugt.

• Halluzination bezeichnet laut Datenschutzkonferenz den Fall, dass ein KI-Modell plausibel klingende Informationen erzeugt, die nicht durch die zugrunde liegenden Daten gedeckt sind. Bei einem RAG-System heißt das: Die Information steht nicht in den gefundenen Referenzdokumenten.

• Faithfulness oder Groundedness ist die Eigenschaft einer Antwort, sich nur auf die wirklich gefundenen Quellen zu stützen statt auf das Trainingswissen des Sprachmodells.

Wichtig ist die Abgrenzung nach unten. Ein System, das 3 zufällig gestellte Testfragen richtig beantwortet, ist nicht evaluiert, sondern nur einmal ausprobiert. Evaluation bedeutet Wiederholbarkeit: dieselben Tests, nachvollziehbar dokumentiert, regelmäßig erneut durchgeführt.

Welche Ebenen werden evaluiert?

Ein RAG-System besteht laut der Orientierungshilfe der Datenschutzkonferenz im Kern aus 4 Komponenten: Embedding-Modell, Vektordatenbank, Retriever und generativem Sprachmodell. Für die Evaluation ergeben sich daraus 3 praktisch trennbare Prüfebenen. Eine vierte, übergreifende kommt in der Praxis meist dazu:

• Retrieval. Leitfrage: Werden die inhaltlich relevanten Textabschnitte überhaupt gefunden? Typischer Fehler: Die richtige Information liegt in der Wissensdatenbank, wird aber nicht gefunden.

• Antwortqualität. Leitfrage: Ist die generierte Antwort korrekt, vollständig und verständlich? Typischer Fehler: Die richtigen Chunks sind da, aber die Antwort fasst sie falsch zusammen.

• Quellenbezug (Faithfulness). Leitfrage: Stützt sich die Antwort wirklich auf die angezeigten Quellen? Typischer Fehler: Die Antwort klingt plausibel, stammt aber teils aus dem Trainingswissen des Modells statt aus der Quelle.

• Systemverhalten im Alltag. Leitfrage: Wie reagiert das System auf Randfälle wie fehlende Informationen, widersprüchliche Quellen oder mehrdeutige Fragen? Typischer Fehler: Das System erfindet eine Antwort, statt zu sagen, dass es die Information nicht hat.

Der Grund für die Trennung ist einfach. Die Fehlerursachen sind unterschiedlich, und die Gegenmaßnahmen auch. Ein Retrieval-Fehler wird durch besseres Chunking oder ein passenderes Embedding-Modell behoben, ein Faithfulness-Fehler eher durch einen strikteren Systemprompt oder ein anderes Sprachmodell. Wer nur auf die Endantwort schaut, vermischt beide Ursachen und behebt am Ende oft das falsche Problem.

Das BSI ergänzt in seiner Publikation zu generativen KI-Modellen einen wichtigen Punkt. Tests sollten nicht nur das Sprachmodell selbst betreffen, sondern das gesamte System mit allen Schnittstellen, bei RAG also inklusive Retriever, Vektordatenbank und Anbindung an die Referenzdokumente.

Was ist ein Golden Question Set?

Ein Golden Question Set ist eine feste, wiederverwendbare Sammlung von Testfragen mit vorab festgelegter erwarteter Quelle und erwarteter Antwort. “Golden” bedeutet: von Menschen mit Fachwissen kuratiert und als Referenz akzeptiert. Es ist kein automatisch erzeugter Datensatz, den niemand geprüft hat.

Die Datenschutzkonferenz beschreibt die Funktion von Testdaten in ihrer Orientierungshilfe zu KI-Systemen. Testdaten werden demnach „für eine unabhängige Bewertung (Evaluation) eines KI-Modells oder Systems verwendet, um die erwartete Leistung vor dessen Betriebsaufnahme zu bestätigen“. Genau diese Funktion übernimmt das Golden Question Set für ein RAG-System.

In der Praxis baue ich ein Golden Question Set aus 3 Quellen auf:

• Echte Fragen. Anonymisierte Fragen aus dem bisherigen Support- oder Wissensmanagement-Alltag.
• Konstruierte Randfälle. Mehrdeutige Fragen, Fragen ohne Antwort in der Wissensbasis, Fragen mit veralteten oder widersprüchlichen Quellen.
• Risikoreiche Themen. Fragen, bei denen eine falsche Antwort teuer wäre, etwa zu vertraglichen oder rechtlichen Details.

Das eigentliche Eval-Template, mit dem jede Frage dokumentiert wird, hat bei mir 7 Spalten. Sie heißen: Test-ID, Frage oder Prompt, erwartete Quelle (Dokument und Abschnitt), erwarteter Kern der Antwort, tatsächliche Quelle, Fehlerklasse bei Abweichung und Bewertung.

3 Beispiele zeigen das Prinzip:

• RQ-001: Kündigungsfrist für Vertragstyp X. Erwartete Quelle: Vertragsvorlage X, Abschnitt 4.2. Erwarteter Kern: konkrete Fristangabe laut Vorlage. Bewertung: bestanden oder nicht bestanden.

• RQ-002: Frage ohne Antwort in der Wissensbasis, Fehlanzeige erwartet. Erwarteter Kern: Das System soll die fehlende Information benennen, nicht erfinden. Mögliche Fehlerklassen: Halluzination, Retrieval-Fehler oder Antwortfehler.

• RQ-003: Frage mit zwei widersprüchlichen Quellenversionen, etwa einer älteren und einer neueren Fassung eines Dokuments. Erwarteter Kern: Das System soll auf den Widerspruch hinweisen oder die aktuelle Fassung nennen.

Eigenes Eval-Template Philogic Labs. Die Spalte „Fehlerklasse“ ist der wichtigste Teil. Sie trennt Retrieval-Fehler (falsche oder fehlende Quelle gefunden), Antwortfehler (richtige Quelle, falsch zusammengefasst) und Halluzination (Antwort ohne Deckung durch eine Quelle). Nur so lässt sich gezielt nachbessern, statt pauschal „das System spinnt“ zu sagen.

Die sinnvolle Größe eines Golden Question Sets hängt stark vom Anwendungsfall und der Breite der Wissensbasis ab. Eine allgemeingültige Zahl gibt es nicht. Es gilt nur die Faustregel: Ein Set, das nur die einfachsten Fragen abdeckt, sagt kaum mehr aus als eine Demo. Entscheidend ist die bewusste Streuung über Kategorien (einfache Fragen, Randfälle, risikoreiche Themen), nicht eine bestimmte Gesamtmenge.

Wie misst man Retrieval?

Retrieval lässt sich messen, sobald im Golden Question Set die erwartete Quelle pro Frage hinterlegt ist. In der Praxis sind 2 Kennzahlen am gebräuchlichsten:

• Trefferquote (Recall). Wird die als relevant markierte Quelle unter den gelieferten Ergebnissen überhaupt gefunden, unabhängig von der Position?
• Position der relevanten Treffer. Landet die richtige Quelle unter den ersten Ergebnissen, die ans Sprachmodell gehen? Oder erst weit hinten, wo die begrenzte Kontextlänge des Modells sie womöglich gar nicht mehr berücksichtigt?

Beide Kennzahlen lassen sich automatisch berechnen, sobald das Golden Question Set steht. Das macht Retrieval zur am einfachsten messbaren Ebene.

Die Orientierungshilfe der Datenschutzkonferenz zu RAG-Systemen benennt zudem die Faktoren, die die Retrieval-Qualität in der Praxis am stärksten prägen. Das sind die Qualität, Aktualität und Vollständigkeit der Referenzdokumente, die Qualität der Datenaufbereitung und die Passung des Embedding-Modells zur Sprache. Mit Datenaufbereitung ist gemeint, wie sinnvoll Dokumente in Chunks aufgeteilt werden, ohne Sinnabschnitte zu zerreißen. Ein Embedding-Modell, das nicht mit deutschsprachigen Texten trainiert wurde, ordnet deutschen Referenzdokumenten laut der Orientierungshilfe tendenziell weniger relevante Chunks zu.

Für KMU heißt das praktisch: Prüfe zuerst die Chunking-Strategie und die Sprachpassung des Embedding-Modells, bevor du komplexere Retrieval-Metriken einführst. Dort liegen aus Erfahrung die häufigsten und am einfachsten behebbaren Ursachen für schwaches Retrieval.

Wie prüft man Quellenbezug?

Quellenbezug, auch Faithfulness oder Groundedness genannt, prüft eine andere Frage als Retrieval. Nicht: Wurde die richtige Quelle gefunden? Sondern: Stützt sich die generierte Antwort wirklich auf das, was in der Quelle steht? Beides kann unabhängig voneinander schiefgehen.

Ein System kann die perfekte Quelle finden und trotzdem eine Antwort erzeugen, die davon abweicht. Das Sprachmodell neigt bei widersprüchlichen Inhalten laut Datenschutzkonferenz dazu, „das Wissen aus den Trainingsdaten wiederzugeben und die Inhalte aus den Referenzdokumenten zu verwerfen“.

Praktisch prüfst du Quellenbezug, indem du jede Sachaussage der Antwort mit dem angezeigten Quellentext abgleichst. Steht die Aussage dort wörtlich oder sinngemäß? Oder wurde etwas ergänzt, das nicht in der Quelle steht? Diese Prüfung läuft manuell an Stichproben aus dem Golden Question Set. Bei größerem Umfang helfen automatisierte Verfahren bei der Vorauswahl auffälliger Fälle; die menschliche Prüfung im risikoreichen Bereich ersetzen sie nicht.

2 Maßnahmen erhöhen den Quellenbezug systematisch, unabhängig vom konkreten Werkzeug:

1. Systemprompt mit klarer Anweisung. Die Datenschutzkonferenz nennt als technische Maßnahme gegen das Verwerfen von Referenzinhalten „vor allem einen Systemprompt, der das RAG-System anweist, ausschließlich mithilfe der referenzierten Quellen zu antworten“.
2. Quellenanzeige in der Ausgabe. Sehen Nutzende, auf welchen Textauszügen eine Antwort basiert, lassen sich laut BSI die Auswirkungen von Halluzinationen mildern. Nicht weil sie seltener auftreten, sondern weil sie erkennbar und prüfbar werden.

Wichtig für die Erwartungshaltung: Quellenbezug reduziert das Risiko, er garantiert nichts. Beide hier genannten Quellen sind sich einig, dass RAG Halluzinationen mindert, aber nicht ausschließt.

Welche Rolle hat menschliche Bewertung?

Automatisierte Metriken sind unverzichtbar, um ein Golden Question Set wiederholt und ohne großen Aufwand durchzurechnen. Alle relevanten Fragen beantworten sie aber nicht. Ob eine Antwort im konkreten Geschäftskontext brauchbar, vollständig und angemessen formuliert ist, entscheiden am Ende Menschen mit Fachwissen. Ein Beispiel: Eine Antwort kann formal quellentreu sein und trotzdem den Kern der Frage verfehlen, weil Kontext fehlt, den nur jemand mit Fachkenntnis vermisst.

Menschliche Bewertung gehört an 3 Punkte:

• Vor dem Start. Beim Aufbau und der Pflege des Golden Question Sets selbst. Das kann keine Maschine übernehmen, weil hier festgelegt wird, was überhaupt als richtig gilt.

• Bei Auffälligkeiten. Wenn automatische Prüfungen einen Fall markieren, etwa wegen fehlender Quelle oder geringer Übereinstimmung mit dem Referenztext.

• Regelmäßig im Betrieb. Als Stichprobe laufender Anfragen, nicht nur einmalig vor dem Go-live. Die Datenschutzkonferenz verlangt ausdrücklich die „fortwährende Validierung des KI-Systems“ im Betrieb statt einer einmaligen Prüfung vor der Einführung.

Wer diese dritte Stichprobe streicht, weil der erste Testlauf gut aussah, übersieht das Kernproblem. Referenzdokumente ändern sich, neue Fragetypen tauchen auf. Die Qualität eines RAG-Systems ist keine feste Eigenschaft; sie verschiebt sich mit jeder Änderung an Wissensbasis oder Modell.

Umsetzung: So setzt du die Evaluation auf

Dieses Vorgehen ist für KMU gedacht und setzt kein eigenes Data-Science-Team voraus.

Schritt 1: Golden Question Set aufbauen. Sammle 20 bis 50 echte oder realistische Fragen aus dem Anwendungsfall, ergänzt um bewusst konstruierte Randfälle wie fehlende Information oder widersprüchliche Quellen. Lege für jede Frage die erwartete Quelle und den erwarteten Antwortkern fest, am besten mit der Person im Fachbereich, die die Inhalte am besten kennt.

Schritt 2: Baseline messen. Führe das Set einmal vollständig durch das System und dokumentiere jedes Ergebnis im Eval-Template. Wurde die richtige Quelle gefunden? Stimmt die Antwort mit der Quelle überein? Welche Fehlerklasse liegt bei Abweichungen vor?

Schritt 3: Fehlerklassen priorisieren. Retrieval-Fehler, Antwortfehler und Halluzinationen haben unterschiedliche Ursachen und Gegenmaßnahmen (siehe oben). Bearbeite zuerst die Fehlerklasse mit den meisten Vorkommen oder dem höchsten Risiko, nicht zwingend beides zusammen.

Schritt 4: Systemprompt und Quellenanzeige prüfen. Bevor du an Embedding-Modell oder Chunking schraubst, lohnt der Blick auf die einfacheren Hebel. Das sind eine klare Anweisung im Systemprompt und eine sichtbare Quellenanzeige in der Antwort.

Schritt 5: Regelmäßige Wiederholung verankern. Lege fest, wer das Set in welchem Rhythmus erneut durchführt, wer Stichproben aus dem Betrieb prüft und wer neue Testfälle ergänzt. Ohne benannte Zuständigkeit verfällt jede Evaluation nach dem ersten Durchlauf.

Fehlt intern die Kapazität für diesen Aufbau, lässt sich ein Erstcheck für ein bestehendes oder geplantes RAG-System auch extern erledigen. Dazu mehr im Abschnitt zum weiteren Vorgehen.

Risiken & Grenzen

Ein paar Grenzen gehören zur ehrlichen Einordnung:

• Ein Golden Question Set bildet nie alle möglichen Fragen ab. Es ist eine Stichprobe, keine Vollabdeckung. Ein System kann alle 30 Testfragen bestehen und trotzdem bei Frage 31 versagen.

• Automatisierte Faithfulness-Prüfung ist selbst eine KI-gestützte Einschätzung. Sie ist damit nicht fehlerfrei und ersetzt die menschliche Stichprobe im risikoreichen Bereich nicht.

• Evaluation prüft das System, nicht die Referenzdokumente selbst. Enthält die Wissensbasis veraltete oder falsche Informationen, gibt ein RAG-System diese Fehler quellentreu und trotzdem inhaltlich falsch wieder. Die Datenschutzkonferenz weist ausdrücklich darauf hin, dass verantwortliche Stellen „regelmäßig überprüfen“ müssen, ob die Referenzdokumente den Anforderungen an Qualität, Aktualität und Vollständigkeit entsprechen. Das ist eine eigene Aufgabe, keine Nebenwirkung der technischen Evaluation.

• Datenschutz ist kein Nebenschauplatz. Sobald personenbezogene Daten in Referenzdokumenten oder Testfragen stecken, gelten die üblichen Anforderungen an Rechtsgrundlage, Zugriffsbeschränkung und Betroffenenrechte. Dieser Artikel ersetzt keine Rechtsberatung. Stand ist Juli 2026; verbindliche Einordnungen gehören zu Datenschutzbeauftragten oder Rechtsberatung.

• Es gibt keine garantierte Fehlerquote. Weder RAG allgemein noch ein bestimmtes Evaluationsverfahren schließen Halluzinationen vollständig aus. Alle hier zitierten Quellen sprechen von Reduktion, nicht von Beseitigung.

Checkliste: RAG-System evaluieren

1. Golden Question Set mit erwarteter Quelle und erwartetem Antwortkern pro Frage vorhanden, kuratiert von Menschen mit Fachwissen.

2. Das Set deckt einfache Fragen, Randfälle (fehlende oder widersprüchliche Information) und risikoreiche Themen ab.

3. Retrieval, Antwortqualität und Quellenbezug werden getrennt geprüft, mit dokumentierten Fehlerklassen statt nur “funktioniert” oder “funktioniert nicht”.

4. Der Systemprompt weist das Modell explizit an, sich auf die referenzierten Quellen zu stützen.

5. Die Antwort zeigt Nutzenden sichtbar, auf welchen Quellen sie basiert.

6. Regelmäßige Stichproben laufen im Betrieb, nicht nur einmalig vor dem Start.

7. Es gibt eine benannte Zuständigkeit für die Pflege des Golden Question Sets und der Referenzdokumente.

8. Datenschutzanforderungen an Testfragen und Referenzdokumente mit personenbezogenen Daten sind geklärt.

9. Intern ist kommuniziert, dass Evaluation Risiken reduziert, aber keine Fehlerfreiheit garantiert.

Du planst ein RAG-System oder willst ein bestehendes evaluieren, ohne dafür ein eigenes Team aufzubauen? In einem kostenlosen Erstgespräch klären wir, ob ein strukturierter Evaluationsaufbau für euren Anwendungsfall sinnvoll ist. Mehr zum Beratungsangebot rund um interne Wissenssysteme findest du auf der Startseite. Wer die eigenen Teams im Umgang mit KI-Ausgaben und deren Grenzen fit machen will, findet passende Formate bei den Schulungen. Weitere Grundlagen bündelt die Übersichtsseite RAG und Wissensdatenbanken.