RAG-Qualität messen bevor der Assistent falsch antwortet.

Ein RAG-Assistent — also ein Sprachmodell, das Antworten aus Ihren eigenen Dokumenten zieht — fühlt sich in der Demo fast immer großartig an. Man stellt drei, vier Fragen, bekommt flüssige, plausible Antworten, alle sind begeistert. Das Problem zeigt sich erst später und unter Last: wenn das System vor echten Kunden oder Mitarbeitern eine Frage knapp danebenbeantwortet, eine Quelle erfindet oder zu einem heiklen Thema selbstbewusst Unsinn ausgibt. Genau deshalb ist die Frage „Funktioniert unser RAG gut genug?“ keine Bauchentscheidung, sondern eine Messaufgabe. Ohne systematische Evaluation tappen Sie im Dunkeln: Sie wissen nicht, ob eine Änderung am System es besser oder schlechter gemacht hat, und Sie merken Qualitätsprobleme erst, wenn sich jemand beschwert. Dieser Beitrag zeigt, wie Sie RAG-Qualität belastbar messen — von der Trennung zwischen Retrieval- und Antwortqualität über die wichtigsten Metriken wie Recall, Precision und Faithfulness bis zum Aufbau eines Test-Sets und dem ehrlichen Umgang mit den Grenzen automatischer Bewertung, etwa beim LLM-as-Judge.

Warum sich RAG ohne Messung gefährlich gut anfühlt.

Sprachmodelle sind Meister des überzeugenden Tons. Eine Antwort kann grammatisch perfekt, flüssig und selbstsicher klingen — und trotzdem inhaltlich falsch sein. Dieses Auseinanderfallen von Form und Wahrheit ist der Kern der Gefahr bei RAG-Systemen: Die Oberfläche täuscht Qualität vor, die der Inhalt nicht hält.

In der Demo prüft niemand die Antworten gegen die Quelle. Man fragt nach Dingen, die man ohnehin kennt, und der erste Eindruck entscheidet. Im Produktivbetrieb fragen echte Nutzer nach Dingen, die sie nicht kennen — und genau dann ist eine falsche, aber überzeugende Antwort am schädlichsten, weil niemand sie hinterfragt.

Hinzu kommt: Jede Verbesserung kann verschlechtern. Sie tauschen das Embedding-Modell, ändern die Chunk-Größe, passen den Prompt an — und ohne Messung wissen Sie nicht, ob das System besser oder heimlich schlechter geworden ist. Evaluation verwandelt RAG-Entwicklung von Raten in Ingenieursarbeit: Man ändert etwas, misst, vergleicht. Ohne diese Schleife optimiert man im Blindflug.

Zwei Fragen trennen: gefunden und beantwortet.

Der wichtigste konzeptionelle Schritt ist, RAG-Qualität in zwei unabhängige Teile zu zerlegen. Ein RAG-System hat zwei Stufen, und beide können getrennt versagen:

• Retrieval: Findet das System die richtigen Dokumentstellen zu einer Frage? Wenn schon die abgerufenen Passagen die Antwort gar nicht enthalten, kann das beste Sprachmodell danach nur raten.
• Generation: Macht das Modell aus den gefundenen Passagen eine korrekte, vollständige und treue Antwort — oder fügt es Dinge hinzu, die in den Quellen nicht stehen?

Diese Trennung ist entscheidend für die Fehlersuche. Eine schlechte Antwort kann zwei völlig verschiedene Ursachen haben: Entweder wurden die falschen Passagen gefunden (Retrieval-Problem), oder die richtigen Passagen wurden falsch verarbeitet (Generation-Problem). Die Gegenmaßnahmen sind komplett unterschiedlich — bessere Chunking-/Embedding-Strategie versus besserer Prompt oder besseres Modell.

Wer beide Stufen in einen Topf wirft und nur die Endantwort bewertet, repariert oft an der falschen Stelle. Getrennte Messung sagt Ihnen, wo das System tatsächlich klemmt.

Die Metriken, die wirklich zählen.

Für beide Stufen gibt es etablierte Kennzahlen. Man muss nicht alle nutzen, sollte aber je Stufe mindestens eine im Blick haben.

Die wichtigste Metrik gegen Halluzinationen ist Faithfulness (Treue): Sie misst, ob jede Aussage der Antwort durch die abgerufenen Quellen gedeckt ist. Eine hohe Faithfulness bedeutet, dass das Modell nichts erfindet — auch wenn die Antwort dann vielleicht unvollständig bleibt. Faithfulness und Correctness sind nicht dasselbe: Eine Antwort kann treu zur (falschen) Quelle und damit faktisch falsch sein. Deshalb braucht es beide Blickwinkel — die Treue gegen die Quelle und die Korrektheit gegen die Wahrheit.

Das Test-Set: das Herzstück jeder Evaluation.

Keine Metrik ist etwas wert ohne ein gutes Test-Set — eine Sammlung von Fragen mit bekannten, korrekten Referenzantworten und idealerweise den Quellstellen, aus denen sie stammen sollten. Dieses Test-Set ist die Investition, die über alles entscheidet.

Bewährt hat sich, das Set aus echten Nutzerfragen zu speisen, nicht aus erfundenen Wohlfühlfragen. Realistische Sets enthalten bewusst auch schwierige Fälle: mehrdeutige Fragen, Fragen, deren Antwort über mehrere Dokumente verstreut ist, und — besonders wichtig — Fragen, die das System gar nicht beantworten kann. Denn ein gutes RAG-System muss auch erkennen, wann es nichts Belastbares findet, und das ehrlich sagen, statt zu fabulieren.

Für einen ersten aussagekräftigen Durchlauf reichen oft schon einige Dutzend bis etwa hundert sorgfältig kuratierte Frage-Antwort-Paare. Qualität schlägt hier Quantität deutlich. Das Set wird von Fachleuten geprüft, nicht maschinell zusammengewürfelt, und es wächst über die Zeit: Jeder reale Fehler, der im Betrieb auffällt, wandert als neuer Testfall hinein. So entsteht eine Regressionssicherung, die verhindert, dass alte Fehler nach einer Änderung zurückkehren.

LLM-as-Judge: nützlich, aber mit Vorsicht.

Antworten von Hand zu bewerten ist gründlich, aber langsam und teuer. Deshalb hat sich das Verfahren „LLM-as-Judge“ etabliert: Ein zweites Sprachmodell beurteilt die Antworten des RAG-Systems nach vorgegebenen Kriterien — etwa, ob die Antwort durch die Quellen gedeckt ist. Das skaliert und macht häufige, automatisierte Evaluationsläufe überhaupt erst praktikabel.

Der Ansatz funktioniert erstaunlich gut, hat aber klare Schwächen, die man kennen muss. Der Judge ist selbst ein Sprachmodell und kann irren — er kann eine plausibel klingende, falsche Antwort durchwinken. Es gibt Verzerrungen: Manche Judges bevorzugen längere Antworten oder den eigenen Stil. Und ein Judge, der gegen eine vom selben Modelltyp erzeugte Referenz urteilt, kann blinde Flecken teilen.

Praktisch heißt das: LLM-as-Judge ist ein hervorragendes Werkzeug für den laufenden, automatisierten Vergleich, aber kein Ersatz für menschliche Kalibrierung. Bewährt hat sich, den Judge an einer von Menschen bewerteten Stichprobe zu eichen — stimmen Judge und Mensch hinreichend überein, kann man dem Judge für die Masse vertrauen und nur Zweifelsfälle und Stichproben menschlich nachprüfen.

Was gute Werte realistisch bedeuten.

Eine häufige Frage lautet: Welche Zahlen sind gut genug? Die ehrliche Antwort: Das hängt stark vom Einsatzzweck ab, und absolute Schwellen sind mit Vorsicht zu genießen.

Für einen internen Assistenten, dessen Fehler ein Mensch leicht erkennt und korrigiert, darf die Messlatte niedriger liegen als für ein System, das direkt vor Kunden antwortet. Wichtiger als ein bestimmter Prozentwert ist die relative Aussage: Hat die letzte Änderung die Faithfulness verbessert oder verschlechtert? Diese Vergleichsmessung ist robust, während absolute Zielwerte schnell zur Scheinpräzision werden.

Eine sinnvolle Praxis ist, Mindestschwellen je Metrik zu definieren, unterhalb derer das System nicht in Produktion geht — besonders bei Faithfulness, weil dort die Halluzinationsgefahr sitzt. Eine kleine Quote nicht beantwortbarer Fragen, die das System korrekt mit „dazu finde ich nichts Belastbares“ beantwortet, ist dabei ein Qualitätsmerkmal, kein Mangel. Ein System, das nie passt, sondern auf alles antwortet, ist verdächtiger als eines, das seine Grenzen kennt. Bewerten Sie deshalb ausdrücklich auch, wie gut das System schweigt, wenn es schweigen sollte.

Evaluation als Dauerbetrieb verankern.

Eine einmalige Bewertung vor dem Go-Live ist nützlich, aber unzureichend. RAG-Qualität verändert sich laufend: Dokumente kommen hinzu, das zugrunde liegende Modell wird aktualisiert, Nutzer stellen neue Arten von Fragen. Ohne fortlaufende Messung altert die Bewertung und gibt falsche Sicherheit.

Drei Praktiken machen Evaluation nachhaltig. Erstens ein automatisierter Testlauf: Bei jeder Änderung am System läuft das Test-Set automatisch durch, und die Metriken werden verglichen — eine Verschlechterung blockiert die Auslieferung. Zweitens Produktions-Monitoring: Reale Anfragen und Antworten werden stichprobenartig bewertet, um Drift zu erkennen, die im Test-Set nicht auftaucht. Drittens eine Feedback-Schleife: Nutzer können Antworten als falsch oder unbrauchbar markieren, und diese Fälle fließen in das Test-Set zurück.

Der Aufwand dafür ist im Mittelstand überschaubar, sobald das erste Test-Set steht und die Bewertung automatisiert läuft. Der eigentliche Wert liegt in der Ruhe, die das schafft: Sie können Ihr RAG-System weiterentwickeln, Modelle tauschen und Dokumente ergänzen, ohne jedes Mal zu zittern, ob Sie damit unbemerkt die Qualität ruiniert haben. Evaluation ist nicht der Bremsklotz der RAG-Entwicklung, sondern ihre Voraussetzung für Vertrauen.

Sie haben einen RAG-Assistenten im Einsatz oder in Planung und wollen seine Qualität messbar machen, bevor er vor Kunden danebenliegt? Unverbindlich anfragen — wir bauen ein belastbares Test-Set auf, richten Retrieval- und Faithfulness-Metriken ein und verankern die Evaluation als laufende Sicherung.