Wie misst man die Qualität eines RAG-Systems objektiv?
Direkte Antwort
RAG-Qualität lässt sich in zwei Ebenen messen: Retrieval-Metriken wie Recall@k und Precision@k prüfen, ob die richtigen Dokumente überhaupt gefunden wurden, und generative Metriken wie Faithfulness und Answer Relevance prüfen, ob die Antwort tatsächlich auf den gefundenen Dokumenten beruht und die Frage beantwortet.
"Ein RAG-System kann beim Retrieval perfekt und bei der Generierung trotzdem falsch sein — deshalb müssen beide Ebenen getrennt gemessen werden.
Ohne eine strukturierte Evaluation bleibt die Einschätzung eines RAG-Systems bei "fühlt sich gut an" — und das reicht nicht, sobald das System produktiv Entscheidungen beeinflusst.
Retrieval-Metriken — wurden die richtigen Dokumente gefunden
Recall@k misst, wie oft ein relevantes Dokument unter den Top-k-Treffern war, Precision@k misst, wie viele der Top-k-Treffer tatsächlich relevant waren. Beide setzen ein Test-Set mit Frage-zu-relevanten-Dokumenten-Zuordnungen voraus.
Ohne ein solches Test-Set, typischerweise 50 bis 200 kuratierte Frage-Antwort-Paare aus echten Nutzeranfragen, lässt sich Retrieval-Qualität nicht systematisch verbessern, sondern nur raten.
Generative Metriken — beruht die Antwort auf dem Kontext
Faithfulness (auch Groundedness genannt) prüft, ob jede Aussage in der Antwort durch den abgerufenen Kontext gedeckt ist, meist automatisiert durch ein zweites LLM als Prüfer (LLM-as-Judge). Answer Relevance prüft, ob die Antwort die gestellte Frage überhaupt trifft.
Frameworks wie RAGAS oder TruLens automatisieren diese Prüfungen, ersetzen aber keine stichprobenartige menschliche Kontrolle, weil LLM-as-Judge selbst Fehler macht, besonders bei subtilen Halluzinationen.
Ein praktikables Evaluations-Setup aufbauen
Der pragmatische Einstieg ist ein Golden-Set aus realen, im Betrieb aufgetretenen Fragen, gegen das bei jeder Änderung an Chunking, Embedding-Modell oder Prompt automatisiert getestet wird.
Ohne Regressionstests bei jeder Pipeline-Änderung bleibt unklar, ob eine Optimierung an einer Stelle die Qualität an anderer Stelle verschlechtert hat — ein häufiger, aber vermeidbarer Fehler in produktiven RAG-Projekten.
Wann passt es — wann nicht?
Passt gut
- ✓Es existiert bereits ein Korpus echter Nutzerfragen aus einem Piloten oder Support-Kanal
- ✓Das System soll iterativ weiterentwickelt werden
Passt nicht
- ✗Das System befindet sich noch in einer sehr frühen Prototyp-Phase ohne echte Nutzerfragen
Quellen
RAGAS Framework Dokumentation, https://docs.ragas.io