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

Eine Demo mit fünf 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 der Frage: Funktioniert das System auch bei den hundert Fragen, die niemand vorher getestet hat? Genau hier setzt RAG Evaluation an.

RAG-Systeme lässt du auf drei Ebenen prüfen: der Retrieval-Ebene (findet das System die passenden Textabschnitte zur Anfrage?), der Antwortebene (ist die generierte Antwort korrekt, vollständig und widerspruchsfrei zu den gefundenen Quellen?) und der Quellenebene (stimmen die angezeigten Belege tatsächlich mit der Antwort überein?). Erst alle drei zusammen ergeben ein belastbares Bild – eine gut klingende Antwort auf falscher oder erfundener Quelle bleibt ein Fehler, den eine reine Demo-Vorführung fast nie zeigt.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die ein RAG-System – etwa als internes Wissenssystem oder Kundensupport-Assistent – nicht nur einführen, sondern auch verantwortlich betreiben wollen. Er beantwortet: 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 eines subjektiven Bauchgefühls.

Begriffe kurz geklärt

Bevor es um das Vorgehen geht, eine kurze Abgrenzung der wichtigsten Begriffe, wie sie auch die Datenschutzkonferenz in ihrer Orientierungshilfe zu RAG-Systemen verwendet:

• Retrieval ist der Suchschritt: Aus einer 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 typischerweise Handbücher, Richtlinien, FAQ-Sammlungen oder Vertragsvorlagen.
• Generierte Antwort ist der vom Sprachmodell erzeugte Text, der auf Basis der Nutzeranfrage und der gefundenen Chunks entsteht.
• Halluzination bezeichnet laut Datenschutzkonferenz den Fall, dass ein KI-Modell Informationen erzeugt, die zwar plausibel klingen, aber nicht durch die zugrunde liegenden Daten gestützt sind – bei einem RAG-System also nicht in den gefundenen Referenzdokumenten stehen.
• Faithfulness beziehungsweise Groundedness ist die Eigenschaft einer Antwort, sich ausschließlich auf die tatsächlich gefundenen Quellen zu stützen, statt auf das allgemeine Trainingswissen des Sprachmodells zurückzugreifen.

Wichtig ist die Abgrenzung nach unten: Ein System, das in drei zufällig gestellten Testfragen richtig antwortet, ist nicht evaluiert – es wurde 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 vier Komponenten: Embedding-Modell, Vektordatenbank, Retriever und generativem Sprachmodell. Für die Evaluation lassen sich daraus drei praktisch trennbare Prüfebenen ableiten – eine vierte, übergreifende kommt in der Praxis meist dazu:

Ebene	Leitfrage	Typischer Fehler, wenn es schiefgeht
Retrieval	Werden die inhaltlich relevanten Textabschnitte überhaupt gefunden?	Die richtige Information liegt in der Wissensdatenbank, wird aber nicht gefunden
Antwortqualität	Ist die generierte Antwort korrekt, vollständig und verständlich?	Die richtigen Chunks werden gefunden, aber die Antwort fasst sie falsch zusammen
Quellenbezug (Faithfulness)	Stützt sich die Antwort tatsächlich auf die angezeigten Quellen?	Die Antwort klingt plausibel, stammt aber teilweise aus dem Trainingswissen des Modells statt aus der Quelle
Systemverhalten im Alltag	Wie reagiert das System auf Randfälle – fehlende Informationen, widersprüchliche Quellen, mehrdeutige Fragen?	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 weist in seiner Publikation zu generativen KI-Modellen zusätzlich darauf hin, dass Tests nicht nur das Sprachmodell selbst betreffen sollten, sondern das gesamte System mit allen Schnittstellen – bei einem RAG-System also inklusive Retriever, Vektordatenbank und der 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 – kein automatisch generierter Datensatz, den niemand geprüft hat. Die Datenschutzkonferenz betont in ihrer Orientierungshilfe zu KI-Systemen allgemein, dass Testdaten „für eine unabhängige Bewertung (Evaluation) eines KI-Modells oder Systems verwendet werden, um die erwartete Leistung vor dessen Betriebsaufnahme zu bestätigen” – und genau diese Funktion übernimmt das Golden Question Set für ein RAG-System.

In der Praxis baue ich ein Golden Question Set aus drei Quellen auf: erstens echten, anonymisierten Fragen aus dem bisherigen Support- oder Wissensmanagement-Alltag, zweitens gezielt konstruierten Randfällen (mehrdeutige Fragen, Fragen ohne Antwort in der Wissensbasis, Fragen mit veralteten oder widersprüchlichen Quellen), drittens Fragen zu besonders risikoreichen Themen, bei denen eine falsche Antwort teuer wäre – etwa vertragliche oder rechtliche Details.

Das eigentliche Eval-Template, mit dem jede Frage dokumentiert wird, sieht bei mir so aus:

Test-ID	Frage/Prompt	Erwartete Quelle (Dokument/Abschnitt)	Erwarteter Kern der Antwort	Tatsächliche Quelle	Fehlerklasse (falls abweichend)	Bewertung
RQ-001	Beispiel: Kündigungsfrist für Vertragstyp X	Vertragsvorlage X, Abschnitt 4.2	Konkrete Fristangabe laut Vorlage	—	—	bestanden/nicht bestanden
RQ-002	Beispiel: Frage ohne Antwort in der Wissensbasis	keine – Fehlanzeige erwartet	System soll fehlende Information benennen, nicht erfinden	—	Halluzination / Retrieval-Fehler / Antwortfehler	bestanden/nicht bestanden
RQ-003	Beispiel: Frage mit zwei widersprüchlichen Quellenversionen	ältere und neuere Fassung eines Dokuments	System soll auf Widerspruch hinweisen oder die aktuelle Fassung nennen	—	—	bestanden/nicht bestanden

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 Größe eines sinnvollen Golden Question Sets hängt stark vom Anwendungsfall und der Breite der Wissensbasis ab – es gibt dafür keine allgemeingültige Zahl, nur die Faustregel, dass ein Set, das nur die einfachsten Fragen abdeckt, kaum mehr aussagt als eine Demo. Entscheidend ist eher die bewusste Streuung über Kategorien (einfache Fragen, Randfälle, risikoreiche Themen) als eine bestimmte Gesamtmenge.

Wie misst man Retrieval?

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

• Trefferquote (Recall): Wird die als relevant markierte Quelle unter den vom Retriever gelieferten Ergebnissen überhaupt gefunden – unabhängig von der Position?
• Position der relevanten Treffer: Landet die richtige Quelle unter den ersten Ergebnissen, die tatsächlich an das Sprachmodell weitergegeben werden, oder erst weit hinten, wo sie aufgrund der begrenzten Kontextlänge des Modells möglicherweise gar nicht mehr berücksichtigt wird?

Beide Kennzahlen lassen sich automatisiert berechnen, sobald das Golden Question Set steht – das macht Retrieval zur am einfachsten zu messenden Ebene. Die Orientierungshilfe der Datenschutzkonferenz zu RAG-Systemen benennt zusätzlich die Faktoren, die die Retrieval-Qualität in der Praxis am stärksten beeinflussen: die Qualität, Aktualität und Vollständigkeit der Referenzdokumente, die Qualität der Datenaufbereitung – also wie sinnvoll Dokumente in Chunks aufgeteilt werden, ohne Sinnabschnitte zu zerreißen – und die Passung des Embedding-Modells zur verwendeten Sprache. Ein Embedding-Modell, das nicht mit deutschsprachigen Texten trainiert wurde, ordnet deutschsprachigen Referenzdokumenten laut der Orientierungshilfe tendenziell weniger relevante Chunks zu.

Für KMU praktisch heißt das: Bevor du komplexere Retrieval-Metriken einführst, lohnt sich der Blick auf die Chunking-Strategie und die Sprachpassung des Embedding-Modells – dort liegen erfahrungsgemäß die häufigsten, am einfachsten behebbaren Ursachen für schwaches Retrieval.

Wie prüft man Quellenbezug?

Quellenbezug – Faithfulness oder Groundedness – prüft eine andere Frage als Retrieval: Nicht „wurde die richtige Quelle gefunden”, sondern „stützt sich die generierte Antwort tatsächlich auf das, was in der Quelle steht”. Beides kann unabhängig voneinander schiefgehen: Ein System kann die perfekte Quelle finden und trotzdem eine Antwort generieren, die davon abweicht – etwa weil das Sprachmodell bei widersprüchlichen Inhalten dazu neigt, laut Datenschutzkonferenz „das Wissen aus den Trainingsdaten wiederzugeben und die Inhalte aus den Referenzdokumenten zu verwerfen”.

Praktisch prüfst du Quellenbezug, indem du jede einzelne Sachaussage der generierten Antwort mit dem angezeigten Quellentext abgleichst: Steht die Aussage dort wörtlich oder sinngemäß, oder wurde etwas hinzugefügt, das nicht in der Quelle steht? Diese Prüfung lässt sich manuell an Stichproben aus dem Golden Question Set durchführen; bei größerem Umfang unterstützen automatisierte Verfahren die Vorauswahl auffälliger Fälle, ersetzen die menschliche Prüfung im risikoreichen Bereich aber nicht vollständig.

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

1. Systemprompt mit expliziter 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. Wenn Nutzenden angezeigt wird, auf welchen konkreten Textauszügen eine Antwort basiert, lassen sich laut BSI Auswirkungen von Halluzinationen mildern – nicht, weil sie seltener auftreten, sondern weil sie für Nutzende erkennbar und prüfbar werden.

Wichtig für die Erwartungshaltung: Quellenbezug ist eine Reduktion des Risikos, keine Garantie. Beide hier genannten Quellen sind sich einig, dass Halluzinationen durch RAG gemindert, aber nicht ausgeschlossen werden können.

Welche Rolle hat menschliche Bewertung?

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

Menschliche Bewertung sollte an drei Punkten stattfinden:

• Vor dem Start: beim Aufbau und der Kuratierung des Golden Question Sets selbst – das kann keine Maschine übernehmen, weil hier festgelegt wird, was überhaupt als „richtig” gilt.
• Bei Auffälligkeiten: wenn automatisierte Prüfungen einen Fall als potenziell problematisch markieren (fehlende Quelle, geringe Übereinstimmung mit dem Referenztext).
• Regelmäßig im Betrieb: als Stichprobenprüfung laufender Anfragen, nicht nur einmalig vor dem Go-live. Die Datenschutzkonferenz verlangt in ihrer Orientierungshilfe zu KI-Systemen ausdrücklich die „fortwährende Validierung des KI-Systems” im Betrieb, nicht nur eine einmalige Prüfung vor der Einführung.

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

Umsetzung: wie du eine RAG-Evaluation aufsetzt

Ein pragmatisches Vorgehen für KMU, das kein eigenes Data-Science-Team voraussetzt:

Schritt 1 – Golden Question Set aufbauen. Sammle 20 bis 50 echte oder realistische Fragen aus dem Anwendungsfall, ergänzt um bewusst konstruierte Randfälle (fehlende Information, widersprüchliche Quellen). Lege für jede Frage die erwartete Quelle und den erwarteten Antwortkern fest – am besten gemeinsam 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 Anzeige der Quellen prüfen. Bevor an Embedding-Modell oder Chunking-Strategie geschraubt wird, lohnt sich der Blick auf einfachere Stellhebel: eine klare Anweisung im Systemprompt und eine sichtbare Quellenanzeige in der Antwort.

Schritt 5 – Regelmäßige Wiederholung etablieren. Lege fest, wer das Golden Question Set in welchem Rhythmus erneut durchführt, wer Stichproben aus dem laufenden Betrieb prüft und wer neue Testfälle ergänzt, wenn neue Fragetypen oder Fehlerfälle auftauchen. Ohne benannte Zuständigkeit verfällt jede Evaluation nach dem ersten Durchlauf.

Wenn intern die Kapazität für diesen Aufbau fehlt, lässt sich ein Erstcheck für ein bestehendes oder geplantes RAG-System auch extern durchführen lassen – dazu mehr im Abschnitt zum weiteren Vorgehen.

Risiken & Grenzen

Ein paar Grenzen dieses Vorgehens 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 bei allen 30 Testfragen bestehen und trotzdem bei Frage 31 versagen.
• Automatisierte Faithfulness-Prüfung ist selbst eine KI-gestützte Einschätzung und damit nicht fehlerfrei. Sie ersetzt die menschliche Stichprobe im risikoreichen Bereich nicht.
• Evaluation prüft das System, nicht die Referenzdokumente selbst. Wenn die Wissensbasis veraltete oder falsche Informationen enthält, kann ein RAG-System diese Fehler quellentreu und trotzdem inhaltlich falsch wiedergeben. Die Datenschutzkonferenz weist ausdrücklich darauf hin, dass verantwortliche Stellen „regelmäßig überprüfen” müssen, ob die verwendeten Referenzdokumente den Anforderungen an Qualität, Aktualität und Vollständigkeit entsprechen – das ist eine eigene Aufgabe, keine Nebenwirkung der technischen Evaluation.
• Datenschutzrechtliche Aspekte sind kein Nebenschauplatz. Sobald personenbezogene Daten in Referenzdokumenten oder Testfragen enthalten sind, 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 können versprechen, Halluzinationen vollständig auszuschließen – alle hier zitierten Quellen sprechen von Reduktion, nicht von Beseitigung.

Checkliste: RAG-System evaluieren

1. Wir haben ein Golden Question Set mit erwarteter Quelle und erwartetem Antwortkern pro Frage – kuratiert von Menschen mit Fachwissen, nicht automatisch generiert.
2. Das Set deckt einfache Fragen, Randfälle (fehlende oder widersprüchliche Information) und risikoreiche Themen ab.
3. Wir prüfen Retrieval, Antwortqualität und Quellenbezug getrennt und dokumentieren Fehlerklassen statt nur „funktioniert”/„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. Wir führen regelmäßige Stichprobenprüfungen im laufenden Betrieb durch – nicht nur einmalig vor dem Start.
7. Es gibt eine benannte Zuständigkeit für die fortlaufende Pflege des Golden Question Sets und der Referenzdokumente.
8. Datenschutzrechtliche Anforderungen an Testfragen und Referenzdokumente mit personenbezogenen Daten sind geklärt.
9. Wir kommunizieren intern, dass Evaluation Risiken reduziert, aber keine Fehlerfreiheit garantiert.

Wenn du ein RAG-System planst oder ein bestehendes System evaluieren willst, 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 zum Thema RAG bündelt die Übersichtsseite RAG und Wissensdatenbanken.