RAG-Qualität messen: RAGAS, MLflow, Precision at K

Constantin Budin, Principal Data & AI bei Pexon Consulting | 10 Min. Lesezeit | 04.08.2026

TL;DR

RAG-Qualität messen Sie nicht per Bauchgefühl, sondern mit Metriken: RAGAS liefert Faithfulness, Answer Relevancy, Context Precision und Context Recall, Precision at K bewertet den Retriever. MLflow trackt die Werte über Versionen hinweg. Diese Anleitung zeigt Testset, RAGAS-Setup, MLflow-Tracking und wie Sie die Zahlen richtig interpretieren.

Warum RAG-Qualität messen, nicht raten

Der typische Ablauf bei RAG-Projekten: Der Chatbot antwortet in der Demo überzeugend, geht in Produktion, und drei Wochen später beschwert sich die Fachabteilung über falsche Antworten. Ohne Messung ist jede Verbesserung ein Blindflug, Sie ändern das Chunking oder das Prompt und wissen nicht, ob es besser oder schlechter wurde.

RAG-Evaluation macht Qualität zur Zahl. Und, viel wichtiger, sie trennt zwei völlig verschiedene Fehlerquellen: Liegt das Problem am Retriever, der die falschen Dokumente holt, oder am Generator, der aus richtigen Dokumenten eine falsche Antwort baut? Ohne diese Trennung optimieren Sie oft die falsche Komponente.

Deutschsprachige Anleitungen dazu sind rar, obwohl die Werkzeuge frei verfügbar sind. Dieser Beitrag schließt die Lücke, mit RAGAS und MLflow.

Was Sie für dieses Tutorial brauchen

• Ein laufendes RAG-System, das zu einer Frage die abgerufenen Kontexte und die generierte Antwort liefert.
• Python 3.10+ mit RAGAS (v0.2 oder neuer, die Version deckt inzwischen auch agentische Abläufe ab) und MLflow.
• Einen LLM-Zugang für die Bewertung selbst, denn RAGAS nutzt ein Modell als Judge.
• Ein kleines Testset: Fragen, idealerweise mit Referenzantworten. Zwanzig bis fünfzig gute Beispiele reichen für den Anfang mehr als hundert schlechte.

Die Metriken, die Sie kennen müssen

RAGAS bündelt vier Kernmetriken. Zwei bewerten den Retriever, zwei den Generator, und genau diese Zuordnung ist der eigentliche Nutzen.

Dazu kommt Precision at K, die klassische Retrieval-Metrik: Wie viele der Top-K abgerufenen Dokumente sind relevant? Sie ist schnell, deterministisch und braucht kein LLM, deshalb ein guter erster Sanity-Check für den Retriever.

Die Faustregel für die Interpretation: Sind Context Precision und Recall niedrig, liegt das Problem beim Retriever, dann helfen besseres Chunking, andere Embeddings oder Re-Ranking. Ist der Kontext gut, aber Faithfulness niedrig, halluziniert der Generator, dann helfen Prompt-Anpassungen oder ein anderes Modell. Warum Standard-RAG bei manchen Dokumenttypen grundsätzlich an Grenzen stößt, behandelt unser Beitrag zu den Grenzen von Standard-RAG.

Schritt 1: Ein Testset bauen

Ohne Testset keine Messung. Sammeln Sie echte Fragen, wie Ihre Nutzer sie stellen, und für die Recall-Messung je eine Referenzantwort. Die Struktur pro Eintrag: Frage, die vom System abgerufenen Kontexte, die generierte Antwort und die Referenzantwort.

Widerstehen Sie der Versuchung, das Testset vom LLM erzeugen zu lassen und es dann vom LLM bewerten zu lassen, das misst nur die Konsistenz des Modells mit sich selbst. Die wertvollsten Testfälle sind echte Fragen, an denen Ihr System in der Praxis gescheitert ist.

Schritt 2: RAGAS einrichten und Metriken berechnen

Mit dem Testset berechnen Sie die vier Metriken in wenigen Zeilen. Die genaue API kann sich je RAGAS-Version unterscheiden, gleichen Sie im Zweifel mit der offiziellen Dokumentation ab.

from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_precision,
    context_recall,
)

# dataset enthaelt: question, contexts, answer, ground_truth
result = evaluate(
    dataset,
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
)
print(result)   # z. B. faithfulness 0.91, context_precision 0.68 ...

Für Precision at K brauchen Sie kein Framework, das rechnen Sie direkt:

def precision_at_k(retrieved_ids, relevant_ids, k):
    """Anteil relevanter Dokumente unter den Top-K Treffern."""
    top_k = retrieved_ids[:k]
    treffer = sum(1 for doc_id in top_k if doc_id in relevant_ids)
    return treffer / k

# Beispiel: 3 von 5 Top-Treffern sind relevant -> 0.6
print(precision_at_k(["d1", "d2", "d3", "d4", "d5"], {"d1", "d3", "d9"}, k=5))

Schritt 3: Ergebnisse in MLflow tracken

Ein einzelner Messwert sagt wenig. Interessant wird es im Vergleich: Hat die neue Chunking-Strategie die Context Precision verbessert? Genau dafür ist MLflow da, es hält jede Auswertung als Run fest, mit Parametern und Metriken.

import mlflow

with mlflow.start_run(run_name="rag-eval-chunking-v2"):
    mlflow.log_param("chunk_size", 512)
    mlflow.log_param("embedding_model", "text-embedding-3-large")
    mlflow.log_metrics({
        "faithfulness": result["faithfulness"],
        "answer_relevancy": result["answer_relevancy"],
        "context_precision": result["context_precision"],
        "context_recall": result["context_recall"],
    })

Jetzt sehen Sie über alle Experimente hinweg, welche Konfiguration welche Werte erzeugt hat. Das macht aus subjektivem „fühlt sich besser an“ eine belegbare Verbesserung.

Schritt 4: interpretieren und iterieren

Die Zahlen sind Mittel zum Zweck. Der Wert entsteht durch die richtige Reaktion auf sie.

Niedrige Context Precision bei ordentlicher Recall bedeutet: Der Retriever holt zu viel Irrelevantes mit. Reduzieren Sie die Chunk-Größe oder ergänzen Sie ein Re-Ranking. Niedrige Context Recall bedeutet: Wichtige Information fehlt im Kontext. Erhöhen Sie K oder überarbeiten Sie die Indexierung. Niedrige Faithfulness bei gutem Kontext bedeutet: Der Generator erfindet. Schärfen Sie den Prompt in Richtung „antworte nur aus dem Kontext“ oder wechseln Sie das Modell.

Wichtig: Ändern Sie immer nur eine Variable pro Durchlauf und messen Sie erneut. Sonst wissen Sie am Ende nicht, welche Änderung gewirkt hat, und genau das verhindert MLflow, indem es jeden Lauf sauber dokumentiert.

Häufige Fallstricke

• Zu kleines oder unrealistisches Testset: Fünf Fragen sagen nichts. Nutzen Sie echte Nutzerfragen, besonders die gescheiterten.
• Kein Referenz-Ground-Truth: Ohne Referenzantwort lässt sich Context Recall nicht berechnen. Planen Sie den Aufwand ein.
• Judge-Modell zu schwach: RAGAS bewertet mit einem LLM. Ein zu kleines Judge-Modell liefert unzuverlässige Scores.
• Einzelmessung statt Verlauf: Ein Wert ohne Vergleich ist wertlos. Tracken Sie über Versionen, sonst optimieren Sie im Nebel.

Häufig gestellte Fragen

Was ist RAGAS und wofür nutze ich es?

RAGAS ist ein Open-Source-Framework zur Bewertung von RAG-Systemen. Es misst mit einem LLM als Judge, wie gut Retriever und Generator arbeiten, über die Metriken Faithfulness, Answer Relevancy, Context Precision und Context Recall. Neuere Versionen decken auch agentische Abläufe ab, nicht nur klassisches RAG.

Was ist der Unterschied zwischen Context Precision und Precision at K?

Precision at K ist eine klassische, deterministische Retrieval-Metrik: Anteil relevanter Dokumente unter den Top-K, ohne LLM berechenbar. Context Precision in RAGAS bewertet zusätzlich mit einem Modell, wie relevant die abgerufenen Chunks für die konkrete Frage sind. Precision at K ist der schnelle Sanity-Check, Context Precision die feinere Bewertung.

Wofür brauche ich MLflow bei der RAG-Evaluation?

MLflow speichert jede Auswertung als Run mit Parametern und Metriken. So vergleichen Sie systematisch, ob eine Änderung an Chunking, Embeddings oder Prompt die Qualität verbessert hat. Ohne dieses Tracking optimieren Sie im Blindflug und können Verbesserungen nicht belegen.

Wie erkenne ich, ob der Retriever oder der Generator das Problem ist?

An den Metriken. Niedrige Context Precision oder Recall zeigen ein Retriever-Problem, dann helfen Chunking, Embeddings oder Re-Ranking. Ist der Kontext gut, aber die Faithfulness niedrig, halluziniert der Generator, dann helfen Prompt-Anpassungen oder ein stärkeres Modell. Diese Trennung ist der Hauptnutzen der Messung.

Wie viele Testfälle brauche ich für eine aussagekräftige Messung?

Für den Anfang reichen zwanzig bis fünfzig sorgfältig gewählte, echte Fragen. Qualität schlägt Menge deutlich: Zwanzig reale Fälle, an denen Ihr System scheitert, sind wertvoller als hundert vom Modell generierte Standardfragen.

Nächster Schritt

Eine RAG-Evaluation aufzusetzen ist der erste Schritt. Die Werte dann auf produktionsreifes Niveau zu bringen, ist die eigentliche Arbeit, und die hängt an Retriever-Tuning, Datenqualität und dem richtigen Modell. Wenn Ihr RAG-System in der Messung durchfällt, sprechen wir darüber.

Verwandte Themen