RAG-Qualität testen: Metriken und Methoden

Was dieser Artikel über RAG-Qualitätstests behandelt

• Du lernst, warum Qualitätstests für RAG-Systeme unverzichtbar sind und was passiert, wenn Du sie weglässt
• Du verstehst die wichtigsten Metriken wie Recall, Precision, Faithfulness und Answer Relevance anhand konkreter Beispiele
• Du erfährst, wie das RAGAS Framework funktioniert und wie Du es für die Evaluation Deines Systems nutzt
• Du bekommst eine Schritt-für-Schritt-Anleitung, um ein eigenes Test-Set zu erstellen und auszuwerten
• Du lernst typische Stolpersteine kennen und wie Du sie vermeidest

Einleitung: RAG-Qualität testen verständlich erklärt

Du hast ein RAG-System aufgebaut, vielleicht mit Ollama und einer lokalen Vektordatenbank. Auf den ersten Blick funktioniert alles. Du stellst eine Frage, bekommst eine Antwort, die plausibel klingt. Aber wie gut ist das System wirklich? Wie oft gibt es falsche Antworten? Und woran liegen die Fehler, an der Suche nach den richtigen Textstellen oder an der Generierung der Antwort?

Genau hier kommen Qualitätstests ins Spiel. In diesem Artikel erkläre ich Dir, wie Du die Qualität Deines RAG-Systems systematisch misst und verbesserst. Dabei schauen wir uns sowohl die Metriken als auch die praktische Umsetzung an. Wenn Du noch nicht genau weißt, was RAG überhaupt ist, lohnt sich zuerst der Artikel zu den RAG Grundlagen.

Warum brauche ich Qualitätstests?

Stell Dir vor, Du betreibst ein RAG-System für den internen Support Deines Unternehmens. Mitarbeiter stellen Fragen zu Urlaubsanträgen, Spesenrichtlinien und IT-Problemen. Das System beantwortet 80 Prozent der Fragen korrekt. Bei 20 Prozent gibt es falsche oder unvollständige Antworten.

Ohne systematische Tests weißt Du nicht, welche 20 Prozent das sind. Ein Mitarbeiter fragt nach der Frist für Urlaubsanträge und bekommt die Antwort “drei Wochen vor Beginn”. Das klingt plausibel, aber die richtige Antwort lautet “vier Wochen”. Niemand beschwert sich, weil die Antwort überzeugend formuliert ist. Der Fehler fällt erst auf, wenn jemand zu spät beantragt und der Antrag abgelehnt wird.

Qualitätstests lösen dieses Problem. Sie zeigen Dir, wo Dein System Schwächen hat, bevor es im produktiven Einsatz zu Problemen kommt. Du erkennst Muster in den Fehlern und kannst gezielte Verbesserungen ableiten, etwa den Wissensbestand in einem Bereich zu erweitern oder das Reranking zu optimieren.

RAG-Qualität testen kurz erklärt

Stell Dir einen Studenten vor, der sich auf eine Prüfung vorbereitet. Er könnte einfach behaupten, er sei bereit. Oder er übt mit alten Klausuren und zählt, wie viele Fragen er richtig beantwortet. Nur so weiß er, ob er wirklich fit ist.

Genso funktioniert ein Qualitätstest für RAG. Du nimmst eine Sammlung von Fragen, bei denen Du die richtige Antwort kennst, legst sie Deinem System vor und vergleichst die Ausgabe mit der erwarteten Antwort. Aus dem Vergleich berechnest Du Metriken, die Dir sagen, wie gut das System funktioniert. Eine einzelne Zahl reicht nicht, weil RAG aus mehreren Schritten besteht. Die Suche kann gut sein, die Generierung schlecht, oder umgekehrt. Deshalb misst Du beide Schritte getrennt.

Für wen sind Qualitätstests gedacht?

Qualitätstests richten sich an mehrere Gruppen:

• Entwickler, die ein RAG-System bauen und wissen wollen, ob ihre Konfiguration gut funktioniert
• Betreiber kleiner und mittlerer Systeme, die keine teuren Evaluations-Teams bezahlen können, aber trotzdem sichergehen wollen, dass ihr System zuverlässig arbeitet
• Teams, die von einer API-basierten Lösung auf eine lokale KI umsteigen und die Qualität vergleichen wollen
• Anfänger, die zum ersten Mal ein RAG-System bauen und verstehen wollen, woran sie Qualität erkennen

Du brauchst keinen Doktortitel in Statistik. Die Grundideen sind einfach, und die Werkzeuge wie RAGAS nehmen Dir viel Arbeit ab.

Wichtige Begriffe rund um RAG-Qualität

Begriff	Bedeutung
Recall	Anteil der relevanten Textstellen, die das System gefunden hat. Hoher Recall bedeutet, es findet fast alles Wichtige.
Precision	Anteil der gefundenen Textstellen, die tatsächlich relevant sind. Hohe Precision bedeutet, wenig unnötiger Ballast.
F1	Kombination aus Recall und Precision zu einem Wert. Hilft, wenn Du eine Zahl zum Vergleichen brauchst.
Faithfulness	Misst, ob die Antwort nur Aussagen enthält, die durch die gefundenen Quellen gedeckt sind. Keine Halluzinationen.
Answer Relevance	Misst, ob die Antwort tatsächlich die gestellte Frage beantwortet, nicht nur irgendetwas Relevantes sagt.
Context Precision	Bewertet, ob die gefundenen Textstellen für die Antwort nützlich sind.
Context Recall	Bewertet, ob alle nötigen Informationen aus den Quellen gefunden wurden.
RAGAS	Ein Framework zur automatischen Evaluation von RAG-Systemen, das mehrere Metriken berechnet.
Ground Truth	Die als korrekt festgelegte Referenzantwort, gegen die Du das System testest.
Evaluation Set	Eine Sammlung von Testfragen mit zugehörigen Referenzantworten und erwarteten Quellen.

Warum RAG-Qualität schwer zu messen ist

RAG besteht aus zwei Hauptschritten: Retrieval und Generierung. Jeder Schritt kann gut oder schlecht sein, und die Kombination macht die Bewertung komplex. Ein System kann die perfekten Textstellen finden und trotzdem eine falsche Antwort generieren. Oder es findet mittelmäßige Quellen, formuliert daraus aber eine brauchbare Antwort.

Hinzu kommt, dass Qualität subjektiv ist. Was als “gute Antwort” gilt, hängt vom Kontext ab. Eine knappe Antwort kann für eine schnelle Nachfrage ideal sein, für eine komplexe Frage reicht sie nicht. Metriken können diese Subjektivität nur teilweise abbilden.

Ein weiteres Problem ist die Unterscheidung zwischen Halluzination und falschem Retrieval. Wenn die Antwort falsch ist, liegt das daran, dass das Modell etwas erfindet, oder daran, dass die falschen Textstellen gefunden wurden? Ohne getrennte Messung beider Schritte bleibst Du im Dunkeln. Deshalb nutzt man mehrere Metriken gleichzeitig, die jeweils unterschiedliche Aspekte beleuchten.

Retrieval-Metriken

Die Retrieval-Phase ist der erste Schritt: Das System sucht in der Vektordatenbank nach Textstellen, die zur Frage passen. Zwei Metriken stehen hier im Zentrum.

Recall: Haben wir die richtigen Textstellen gefunden?

Recall misst, wie viele der relevanten Textstellen das System gefunden hat. Angenommen, in Deiner Datenbank gibt es fünf Textstellen, die für eine Frage wichtig sind. Das System findet drei davon. Der Recall liegt bei 60 Prozent.

Hoher Recall ist wichtig, weil die Generierung nur auf dem aufbauen kann, was gefunden wurde. Wenn eine kritische Textstelle fehlt, kann das Modell sie nicht verwenden, und die Antwort wird unvollständig oder falsch.

Precision: Sind die gefundenen Textstellen relevant?

Precision misst, wie viele der gefundenen Textstellen tatsächlich relevant sind. Das System findet zehn Textstellen, aber nur vier davon sind für die Frage wichtig. Die Precision liegt bei 40 Prozent.

Niedrige Precision bedeutet, dass das Modell mit vielen irrelevanten Textstellen arbeiten muss. Das kann die Antwort verschlechtern, weil das Modell sich verwirren lässt oder den Fokus verliert. Es kostet auch Rechenleistung und Zeit, weil unnötig viele Textstellen verarbeitet werden.

Methoden wie Hybrid Search und Reranking helfen, die Precision zu verbessern, ohne den Recall zu senken. Hybrid Search kombiniert semantische und keyword-basierte Suche, während Reranking die gefundenen Textstellen nach Relevanz neu sortiert.

Generierungs-Metriken

Nach dem Retrieval generiert das Sprachmodell die Antwort aus den gefundenen Textstellen. Auch hier gibt es zwei zentrale Metriken.

Faithfulness: Stimmt die Antwort mit den Quellen überein?

Faithfulness misst, ob alle Aussagen in der Antwort durch die gefundenen Quellen gedeckt sind. Wenn die Antwort behauptet, die Frist für Urlaubsanträge liege bei drei Wochen, aber in den Quellen steht vier Wochen, ist die Antwort nicht faithful. Das Modell hat entweder falsch gelesen oder etwas hinzugefügt.

Niedrige Faithfulness ist ein Warnsignal für Halluzinationen. Das Modell erfindet Fakten, die nicht in den Quellen stehen. Das ist besonders gefährlich, weil die Antworten oft überzeugend klingen. Quellenangaben in der Ausgabe helfen, dieses Problem für Nutzer transparenter zu machen, lösen es aber nicht.

Answer Relevance: Beantwortet die Antwort die Frage?

Answer Relevance misst, ob die Antwort tatsächlich auf die gestellte Frage eingeht. Eine Antwort kann vollständig faithful sein und trotzdem die Frage verfehlen. Wenn jemand fragt “Wie lange dauert die Kündigungsfrist?” und die Antwort erklärt ausführlich den Ablauf einer Kündigung, aber nennt keine Frist, dann ist die Antwort nicht relevant.

Answer Relevance ist schwieriger zu messen als Faithfulness, weil “Relevanz” subjektiver ist. RAGAS nutzt einen Ansatz, bei dem aus der Antwort neue Fragen generiert werden und dann gemessen wird, wie ähnlich diese generierten Fragen der Originalfrage sind. Eine gute Antwort sollte es ermöglichen, die Originalfrage rekonstruieren zu können.

RAGAS Framework

RAGAS (Retrieval Augmented Generation Assessment) ist ein Open-Source-Framework, das die Evaluation von RAG-Systemen automatisiert. Es berechnet die vier wichtigsten Metriken in einem Durchlauf:

• Faithfulness: Sind alle Aussagen in der Antwort durch den Kontext gedeckt?
• Answer Relevance: Beantwortet die Antwort die Frage?
• Context Precision: Sind die gefundenen Textstellen nützlich für die Antwort?
• Context Recall: Wurden alle nötigen Informationen gefunden?

Wie RAGAS funktioniert

RAGAS nutzt ein Sprachmodell als Bewerter. Du gibst ihm die Frage, die gefundenen Textstellen, die generierte Antwort und optional die Referenzantwort. Das Bewertungsmodell analysiert diese Eingaben und produziert Scores für jede Metrik, typischerweise zwischen 0 und 1. RAGAS selbst benötigt also ein Sprachmodell. Bei einer lokalen KI kannst Du ein lokales Modell als Bewerter verwenden, etwa über Ollama. Das kostet Rechenleistung, hält aber alle Daten auf Deinem System.

RAGAS einsetzen

Die typische Nutzung sieht so aus: Du erstellst ein Evaluation Set, also eine Liste von Fragen mit Referenzantworten. Für jede Frage lässt Du Dein RAG-System laufen und speicherst die gefundenen Textstellen und die generierte Antwort. Diese Daten gibst Du an RAGAS, das die Metriken berechnet. Am Ende erhältst Du einen Bericht mit Durchschnittswerten und Einzelwerten pro Frage.

RAGAS ist in Python verfügbar und lässt sich in bestehende Pipelines integrieren. Für kleinere Systeme reicht es, die Evaluation manuell anzustoßen. Für größere Systeme automatisierst Du den Prozess und lässt ihn regelmäßig laufen, zum Beispiel nach jeder Aktualisierung des Wissensbestands.

Ein Test-Set erstellen

Ein gutes Test-Set ist die Grundlage jeder Evaluation. Ohne sinnvolle Testfragen messen Du nichts Nützliches. Hier sind die Schritte zum Erstellen eines Test-Sets.

Schritt 1: Fragen sammeln

Sammle 20 bis 50 Fragen, die typisch für die Nutzung Deines Systems sind. Nutze verschiedene Quellen: echte Fragen von Nutzern, falls Du Protokolle hast, eigene Testfragen, Fragen aus verschiedenen Themenbereichen und einen Mix aus einfachen und komplexen Fragen. Achte darauf, dass die Fragen die Bandbreite abdecken, nicht nur die einfachen Fälle.

Schritt 2: Referenzantworten erstellen

Für jede Frage schreibst Du die beste Antwort auf, basierend auf Deinem Wissen der Quellen. Diese Referenzantwort muss nicht wortwörtlich so im Wissensbestand stehen, aber sie muss korrekt und vollständig sein. Diese Referenz ist Dein Ground Truth.

Schritt 3: Erwartete Quellen notieren

Für jede Frage notierst Du, welche Textstellen aus dem Wissensbestand relevant sein sollten. Das hilft später bei der Bewertung des Retrievals. Wenn das System andere Textstellen findet, kannst Du erkennen, ob die Suche verbessert werden muss.

Schritt 4: Randfälle einbauen

Baue bewusst schwierige Fragen ein: Fragen, bei denen die Antwort aus mehreren Textstellen kombiniert werden muss, Fragen mit mehrdeutigen Begriffen, Fragen, für die es keine Antwort im Wissensbestand gibt. Gerade die Fälle ohne Antwort sind wichtig, weil das System dort idealerweise sagt “Ich habe dazu keine Informationen” statt etwas zu erfinden.

Beispiel: RAG-System evaluieren

Hier ist ein konkreter Ablauf für die Evaluation mit RAGAS.

Vorbereitung

Du hast Dein RAG-System mit Lokalem RAG aufgebaut. Dein Test-Set enthält 30 Fragen mit Referenzantworten und erwarteten Quellen. RAGAS ist installiert, und Du hast ein lokales Bewertungsmodell über Ollama eingerichtet.

Durchführung

Für jede Frage im Test-Set stellst Du die Frage an Dein RAG-System, speicherst die gefundenen Textstellen (Context) und die generierte Antwort (Answer) und notierst die Referenzantwort (Ground Truth). Diese Daten sammelst Du in einer Tabelle oder JSON-Datei.

Auswertung mit RAGAS

Du übergibst die gesammelten Daten an RAGAS. Das Framework berechnet für jede Frage die vier Metriken und gibt Dir Durchschnittswerte. Ein typisches Ergebnis könnte so aussehen:

• Faithfulness: 0,82
• Answer Relevance: 0,75
• Context Precision: 0,68
• Context Recall: 0,71

Interpretation

Die Zahlen zeigen, dass das Retrieval Schwächen hat. Context Precision und Context Recall sind relativ niedrig. Das System findet nicht immer die besten Textstellen. Faithfulness ist höher, was bedeutet, dass das Modell die gefundenen Textstellen meist korrekt wiedergibt. Answer Relevance liegt dazwischen, was darauf hindeutet, dass einige Antworten die Frage nicht optimal beantworten, möglicherweise weil die Quellen nicht ideal waren.

Die Schlussfolgerung: Du solltest zuerst am Retrieval arbeiten, etwa durch Reranking oder Hybrid Search, bevor Du an der Generierung feilen.

Manuelle Tests

Nicht jeder braucht sofort ein Framework wie RAGAS. Manuelle Tests sind ein guter Einstieg und oft aufschlussreicher als erwartet.

Ablauf

1. Nimm 20 Fragen aus Deinem Test-Set
2. Stelle jede Frage an Dein RAG-System
3. Vergleiche die Antwort mit Deiner Referenzantwort
4. Notiere: korrekt, teilweise korrekt oder falsch
5. Bei falschen Antworten: notiere die Ursache (falsche Quellen, falsche Generierung, Frage nicht verstanden)

Auswertung

Nach 20 Fragen hast Du eine einfache Statistik. Vielleicht 14 korrekt, 4 teilweise korrekt, 2 falsch. Wichtiger als die Quote ist die Fehleranalyse. Schau Dir die falschen und teilweise korrekten Antworten an. Gibt es Muster? Vielleicht scheitern alle falschen Antworten an Fragen zu einem bestimmten Thema, was auf eine Lücke im Wissensbestand hindeutet. Oder die gefundenen Textstellen waren richtig, aber die Antwort war falsch formuliert, was auf ein Problem in der Generierung hindeutet.

Manuelle Tests kosten Zeit, geben Dir aber ein Gefühl für das System, das keine Metrik ersetzen kann. Für eine erste Einschätzung reichen sie völlig aus.

Typische Stolpersteine bei Qualitätstests

Bei Qualitätstests gibt es mehrere Fallstricke, die Deine Ergebnisse verfälschen können.

Zu kleine Test-Sets: Mit fünf Fragen bekommst Du keine aussagekräftigen Werte. Ein einzelner Ausreißer verändert das Ergebnis dramatisch. Nutze mindestens 20, besser 50 Fragen.

Unrealistische Fragen: Wenn Deine Testfragen alle einfach sind, sieht das System besser aus als es ist. Baue schwierige und mehrdeutige Fragen ein, die das System wirklich fordern.

Fehlende Randfälle: Fragen ohne Antwort im Wissensbestand werden oft vergessen. Das System sollte erkennen, wenn es keine Informationen hat, statt zu halluzinieren. Teste das explizit.

Veraltete Referenzantworten: Wenn sich Dein Wissensbestand ändert, können Referenzantworten falsch werden. Aktualisiere das Test-Set regelmäßig, besonders nach größeren Updates.

Bewertungsmodell ist zu schwach: Wenn Du RAGAS mit einem kleinen lokalen Modell als Bewerter nutzt, können die Scores unzuverlässig sein. Teste mit unterschiedlichen Bewertungsmodellen und vergleiche.

Überanpassung an Metriken: Wenn Du nur auf die Zahlen schaust und das System so optimierst, dass die Metriken besser werden, kann die tatsächliche Qualität leiden. Metriken sind Hilfsmittel, nicht das Endziel. Nutze immer auch manuelle Stichproben.

Einmalige Tests: Ein Test nach dem Aufbau reicht nicht. Jede Änderung am System, am Wissensbestand oder an den Parametern kann die Qualität beeinflussen. Führe Tests regelmäßig durch, am besten nach jeder relevanten Änderung.

Hardware, Kosten und Sicherheit bei Qualitätstests

Qualitätstests verbrauchen Ressourcen, besonders wenn Du RAGAS mit einem lokalen Bewertungsmodell nutzt. Jede Frage im Test-Set erfordert mehrere Aufrufe des Bewertungsmodells, weil RAGAS für jede Metrik separate Analysen durchführt. Bei 50 Fragen und vier Metriken kommst Du auf 200 Modellaufrufe pro Evaluation.

Für die Hardware bedeutet das: Du brauchst genug RAM und VRAM, um das Bewertungsmodell flüssig laufen zu lassen. Ein Modell mit 7 bis 8 Milliarden Parametern, etwa Llama 3 8B, ist ein guter Kompromiss zwischen Qualität und Ressourcenbedarf. Auf einem System mit 16 GB RAM läuft es, wenn auch nicht besonders schnell. Für komfortable Geschwindigkeit sind 32 GB RAM und eine dedizierte GPU empfehlenswert.

Die Kosten halten sich bei lokaler Ausführung in Grenzen, weil keine API-Gebühren anfallen. Du zahlst nur für Strom und Hardware. Bei Cloud-APIs können die Kosten bei regelmäßigen Tests und größeren Test-Sets schnell addieren.

Sicherheitstechnisch ist die lokale Ausführung ein Vorteil. Deine Testfragen, Referenzantworten und gefundenen Textstellen bleiben auf Deinem System. Das ist wichtig, wenn der Wissensbestand sensible Unternehmensdaten enthält.

Weiterführende Links und Infos zu Qualitätstests

• Die offizielle RAGAS-Dokumentation bietet detaillierte Erklärungen aller Metriken und Beispiele zur Integration
• Im Artikel zu Reranking erfährst Du, wie Du die Precision Deines Retrievals verbesserst
• Hybrid Search kombiniert zwei Suchmethoden für bessere Ergebnisse
• Wenn Du den Wissensbestand aktualisierst, hilft der Artikel zum Wissensbestand aktualisieren
• Grundlagen zu lokaler KI findest Du im Artikel Was ist lokale KI?

FAQ: RAG-Qualität testen - Typische Fragen

Wie viele Fragen sollte mein Test-Set enthalten? Für eine erste Einschätzung reichen 20 Fragen. Für aussagekräftige Metriken sind 50 oder mehr empfehlenswert. Je mehr, desto zuverlässiger die Werte, aber desto höher auch der Aufwand.

Brauche ich RAGAS oder reichen manuelle Tests? Für den Einstieg reichen manuelle Tests völlig. Sie geben Dir ein Gefühl für das System. RAGAS lohnt sich, wenn Du systematisch vergleichen willst, etwa vor und nach einer Änderung, oder wenn Du größere Systeme betreust.

Welches Modell soll ich als RAGAS-Bewerter nutzen? Ein Modell mit 7 bis 8 Milliarden Parametern ist ein guter Start. Kleinere Modelle können unzuverlässig bewerten. Wenn Dir Qualität wichtiger als Geschwindigkeit ist, nutze ein größeres Modell.

Wie oft sollte ich Tests durchführen? Mindestens nach jeder relevanten Änderung, also nach Updates des Wissensbestands, nach Parameteränderungen oder nach dem Wechsel des Sprachmodells. Bei aktiver Entwicklung lohnt sich ein Test nach jedem Sprint.

Was tun, wenn die Metriken gut sind, aber die Antworten schlecht wirken? Das ist ein Hinweis auf Überanpassung. Die Metriken messen bestimmte Aspekte, aber nicht alles. Nutze manuelle Stichproben und schau Dir Antworten direkt an. Vertraue nicht blind auf die Zahlen.

Kann ich RAGAS ohne Referenzantworten nutzen? RAGAS kann einige Metriken ohne Referenzantwort berechnen, etwa Faithfulness und Answer Relevance. Für Context Recall brauchst Du Referenzantworten. Ohne sie ist die Aussagekraft eingeschränkt.

Wie unterscheide ich Retrieval-Fehler von Generierungs-Fehlern? Schau Dir die gefundenen Textstellen an. Wenn die richtigen Quellen gefunden wurden, die Antwort aber falsch ist, liegt das Problem in der Generierung. Wenn die falschen Quellen gefunden wurden, liegt es am Retrieval. RAGAS trennt das durch Context Precision und Context Recall von Faithfulness.

Was ist ein guter Faithfulness-Wert? Werte über 0,8 sind solide, über 0,9 sehr gut. Unter 0,7 solltest Du dringend nachbessern, weil das Modell zu oft erfindet. Beachte, dass der Wert vom Bewertungsmodell abhängt und zwischen Durchläufen leicht schwanken kann.

Helfen Quellenangaben bei der Qualität? Quellenangaben machen die Antworten für Nutzer nachvollziehbarer und helfen bei der manuellen Prüfung. Sie verbessern die Metriken nicht direkt, aber sie machen Fehler sichtbarer.

Was kostet ein Qualitätstest mit RAGAS auf lokaler Hardware? Nur Strom und Zeit. Bei 50 Fragen mit einem 8B-Modell auf einer durchschnittlichen GPU dauert ein Durchlauf etwa 15 bis 30 Minuten. Ohne GPU kann es deutlich länger dauern.

Kann ich Tests automatisieren? Ja, RAGAS lässt sich in Python-Skripte einbinden. Du kannst die Evaluation nach jedem Update des Wissensbestands automatisch ausführen und die Ergebnisse protokollieren. So erkennst Du Trends über die Zeit.

Quellen und weiterführende Literatur

• RAGAS Dokumentation und GitHub-Repository
• Es, S., James, J., Espinosa-Anke, L., Schockaert, S. (2023): “RAGAS: Automated Evaluation of Retrieval Augmented Generation”
• Lewis, P. et al. (2020): “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”
• Weitere Artikel auf BotServ.de zum Thema Lokales RAG