RAG messbar machen: Testsatz, Kennzahlen und was sie verschweigen

TL;DR

Ohne Testsatz ist jede Änderung am RAG-System eine Wette. Der Aufbau kostet zwei Tage: 50 bis 100 echte Fragen mit den Abschnitten, die die Antwort enthalten. Danach messen Sie Wiederfindung und Genauigkeit im Abruf getrennt von der Antwortqualität — weil 80 Prozent der Fehler im Abruf entstehen, nicht im Modell.

Der Zustand, in dem die meisten Systeme sind

"Das Ergebnis ist besser geworden." — "Woran merkt ihr das?" — "Man sieht es."

Dieses Gespräch führen wir häufiger, als uns lieb ist, und es ist der Grund, warum RAG-Projekte im Kreis laufen. Jemand ändert die Abschnittsgröße von 512 auf 1.024 Token, probiert drei Fragen aus, findet es besser, übernimmt die Änderung. Zwei Wochen später beschwert sich eine Fachabteilung, dass etwas nicht mehr gefunden wird, das vorher ging. Niemand kann sagen, welche Änderung es war.

Die Lösung ist unspektakulär und wird trotzdem übersprungen: ein Testsatz.

Den Testsatz bauen — der Teil, der Arbeit ist

Sie brauchen 50 bis 100 Fragen. Nicht ausgedachte, sondern echte. Die besten Quellen dafür:

• Tickets aus dem internen Support der letzten sechs Monate
• Fragen, die in der Chat-Oberfläche bereits gestellt wurden, falls das System schon läuft
• Eine halbe Stunde mit drei Personen aus der Fachabteilung, die aufschreiben, was sie tatsächlich wissen wollen

Zu jeder Frage brauchen Sie die Angabe, welcher Dokumentabschnitt die Antwort enthält. Das ist der aufwendige Teil, und er lässt sich nicht sinnvoll automatisieren — wer die Referenzantworten von einem Modell erzeugen lässt, misst am Ende, wie ähnlich sich zwei Modelle sind.

[
  {
    "frage": "Welche Prüfintervalle gelten für Druckbehälter über 1000 Liter?",
    "referenz_abschnitte": ["BA-2024-017#s3", "PRUEF-RL#s12"],
    "referenz_antwort": "Innere Prüfung alle 5 Jahre, Festigkeitsprüfung alle 10 Jahre.",
    "kategorie": "vorschriften"
  },
  {
    "frage": "Wer gibt Änderungen an Fertigungszeichnungen frei?",
    "referenz_abschnitte": ["QMH-2025#s44"],
    "referenz_antwort": "Die Konstruktionsleitung, bei sicherheitsrelevanten Teilen zusätzlich die QS-Leitung.",
    "kategorie": "prozesse"
  }
]

Das Feld kategorie ist wichtiger, als es aussieht. Es erlaubt Ihnen später zu sehen, dass Ihr System bei Prozessfragen gut ist und bei Zahlenfragen schlecht — eine Aussage, die zu einer konkreten Maßnahme führt. Ein Gesamtwert von 0,73 führt zu gar nichts.

Nehmen Sie außerdem bewusst 10 Prozent Fragen auf, die das System nicht beantworten kann, weil die Information nicht im Bestand ist. Die richtige Antwort darauf ist "weiß ich nicht". Ein System, das darauf etwas erfindet, ist gefährlicher als eines, das schlechter abruft.

Abruf und Antwort getrennt messen

Das ist der wichtigste methodische Punkt dieses Artikels. Ein RAG-System hat zwei Stufen, und sie versagen aus verschiedenen Gründen. Wer nur die Endantwort bewertet, weiß bei einem schlechten Ergebnis nicht, wo er ansetzen soll.

Stufe 1 — Abruf. Zwei Kennzahlen genügen:

Recall at K: Wie oft ist der richtige Abschnitt unter den ersten K Treffern? Bei K=8 sollte dieser Wert über 0,90 liegen. Wenn nicht, hilft kein besseres Modell — der richtige Text kommt nie beim Modell an.

Precision at K: Wie viele der K Treffer sind tatsächlich relevant? Ein niedriger Wert bedeutet, dass Sie das Kontextfenster mit Rauschen füllen. Das kostet Geld und verschlechtert die Antwort, weil das Modell abgelenkt wird.

def recall_at_k(treffer_ids, referenz_ids, k=8):
    """Anteil der Referenzabschnitte, die in den Top-K auftauchen."""
    top_k = set(treffer_ids[:k])
    return len(top_k & set(referenz_ids)) / len(referenz_ids)

def precision_at_k(treffer_ids, referenz_ids, k=8):
    """Anteil der Top-K-Treffer, die tatsächlich relevant sind."""
    top_k = treffer_ids[:k]
    return sum(1 for t in top_k if t in referenz_ids) / len(top_k)

Diese zwei Funktionen sind zehn Zeilen und liefern mehr Erkenntnis als jedes Bewertungswerkzeug. Fangen Sie damit an, bevor Sie eine Bibliothek installieren.

Stufe 2 — Antwort. Hier braucht es ein Modell als Bewerter, weil die Frage "ist die Antwort korrekt" sich nicht mit Zeichenketten beantworten lässt. Zwei Kennzahlen reichen:

Treue: Lässt sich jede Aussage der Antwort aus den abgerufenen Abschnitten belegen? Das misst Halluzination.

Relevanz: Beantwortet die Antwort die gestellte Frage, oder redet sie am Thema vorbei?

RAGAS: was es leistet und wo es hakt

RAGAS ist die verbreitetste Bibliothek für diese Bewertung. Sie bringt die genannten Kennzahlen mit und noch einige mehr.

from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision
from datasets import Dataset

daten = Dataset.from_dict({
    "question": fragen,
    "answer": antworten,
    "contexts": abgerufene_abschnitte,     # Liste von Listen
    "ground_truth": referenz_antworten,
})

ergebnis = evaluate(daten, metrics=[faithfulness, answer_relevancy, context_precision])
print(ergebnis)

Drei Dinge, die Sie vorher wissen sollten:

Es kostet Geld. Jede Kennzahl löst mindestens einen Modellaufruf pro Frage aus, faithfulness deutlich mehr, weil es die Antwort in Einzelaussagen zerlegt und jede prüft. Bei 100 Fragen und drei Kennzahlen landen Sie schnell bei mehreren hundert Modellaufrufen pro Durchlauf. Setzen Sie dafür ein günstiges Modell ein oder ein lokales.

Die Werte schwanken. Zwei Durchläufe mit identischen Daten liefern nicht identische Zahlen, weil das bewertende Modell nicht deterministisch ist. Setzen Sie die Temperatur auf 0 und interpretieren Sie Unterschiede unter etwa 0,03 nicht als Verbesserung.

Die Standardprompts sind englisch. Bei deutschen Fachtexten führt das zu systematisch niedrigeren Bewertungen, besonders bei answer_relevancy. Passen Sie die Prompts an oder verwenden Sie ein Bewertungsmodell, das mit Deutsch sicher umgeht. Wir haben in Tests Unterschiede von 0,1 und mehr allein durch die Sprache der Bewertungsprompts gesehen.

Unsere Empfehlung: RAGAS für Stufe 2, eigene zehn Zeilen für Stufe 1. Die Abrufkennzahlen brauchen kein Modell und sollten deshalb auch keines verwenden — sie werden dadurch nur langsam, teuer und unzuverlässig.

Ergebnisse festhalten, damit man sie vergleichen kann

Ein Bewertungslauf, dessen Ergebnis in einem Terminal steht, ist nach einer Woche verloren. Sie brauchen eine Ablage, die Konfiguration und Ergebnis zusammenhält: welches Einbettungsmodell, welche Abschnittsgröße, welches Sprachmodell, welche Werte.

MLflow ist dafür naheliegend, weil es genau das kann und im Unternehmensumfeld oft ohnehin steht:

import mlflow

with mlflow.start_run(run_name="chunk-1024-bge-m3"):
    mlflow.log_params({
        "chunk_size": 1024, "chunk_overlap": 128,
        "embedding": "bge-m3", "top_k": 8, "reranker": "keiner",
    })
    mlflow.log_metrics({
        "recall_at_8": 0.91, "precision_at_8": 0.34,
        "faithfulness": 0.87, "answer_relevancy": 0.79,
    })

Wenn MLflow zu schwer ist: eine CSV-Datei mit einer Zeile pro Lauf, im Repository versioniert. Das ist kein Kompromiss, das ist für die meisten Häuser der bessere Weg. Wichtig ist nur, dass die Konfiguration neben dem Ergebnis steht.

Was die Zahlen typischerweise zeigen

Aus Projekten, die diesen Weg gegangen sind, ein wiederkehrendes Muster:

Der erste Durchlauf liefert oft Recall at 8 um 0,75 und Precision at 8 um 0,20. Beide Zahlen sagen dasselbe: Der Abruf holt zu viel Falsches und zu wenig Richtiges. Die Antwortqualität sieht dann trotzdem ordentlich aus, weil das Modell aus dem Rauschen etwas Plausibles baut — und genau das ist die gefährliche Situation.

Was in dieser Lage am meisten bringt, in dieser Reihenfolge:

1. Ein Reranker. Sie holen 30 Treffer statt 8 und lassen ein Cross-Encoder-Modell die besten 8 auswählen. Das hebt Precision at 8 regelmäßig von 0,20 auf über 0,50, bei überschaubarem Latenzaufschlag.
2. Hybride Suche. Wenn Ihre Dokumente Bezeichner enthalten — Teilenummern, Normen, Fehlercodes — findet eine reine Vektorsuche sie schlechter als eine Stichwortsuche. Die Kombination beider ist bei technischen Beständen der größte Einzelhebel.
3. Abschnittsgrenzen an der Dokumentstruktur. Nicht alle 512 Token schneiden, sondern an Überschriften. Tabellen nicht zerreißen.

Erst danach lohnt es sich, über das Sprachmodell nachzudenken. Die Auswahl der Datenbank darunter behandelt der Vergleich von Azure AI Search, pgvector und Qdrant; die Grundlagen des Aufbaus stehen im Leitfaden vom PDF zur Wissensdatenbank.

Häufig gestellte Fragen

Wie viele Testfragen brauche ich für eine belastbare RAG-Bewertung?

50 bis 100 echte Fragen reichen für aussagekräftige Vergleiche zwischen Konfigurationen. Wichtiger als die Anzahl ist die Abdeckung: Die Fragen sollten alle Dokumentarten und Fragetypen erfassen, die im Betrieb vorkommen, und rund 10 Prozent sollten bewusst unbeantwortbar sein, um zu prüfen, ob das System das zugibt.

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

Recall at K misst, ob der richtige Abschnitt überhaupt unter den ersten K Treffern ist — findet das System die Information? Precision at K misst, wie viele der K Treffer relevant sind — wie viel Rauschen kommt mit? Ein hoher Recall bei niedriger Precision bedeutet, dass Sie das Kontextfenster mit Unbrauchbarem füllen. Der übliche Hebel dagegen ist ein Reranker.

Kann ich die Bewertung mit einem lokalen Modell durchführen?

Ja, und bei größeren Testsätzen ist das der sinnvollere Weg, weil jeder Durchlauf hunderte Modellaufrufe auslöst. Achten Sie darauf, dass das Bewertungsmodell mit deutschen Fachtexten sicher umgeht — bei kleineren Modellen wird die Bewertung unzuverlässig. Und behalten Sie dasselbe Bewertungsmodell über alle Läufe bei, sonst sind die Zahlen nicht vergleichbar.

Warum liefert RAGAS bei deutschen Texten schlechtere Werte?

Weil die eingebauten Bewertungsprompts englisch formuliert sind und das bewertende Modell dadurch bei deutschen Antworten strenger urteilt. Besonders betroffen ist die Relevanzbewertung. Passen Sie die Prompts an die Sprache Ihrer Inhalte an, oder werten Sie zumindest nur relative Veränderungen zwischen Läufen aus statt absoluter Werte.

Wie oft sollte die Bewertung laufen?

Bei jeder Änderung an Abschnittsbildung, Einbettungsmodell, Abrufparametern oder Systemanweisung — und einmal im Quartal als Kontrolle, ob sich durch neue Dokumente etwas verschlechtert hat. Ein automatisierter Lauf in der Bereitstellungskette ist ideal, aber ein manueller Lauf mit festgehaltenem Ergebnis ist bereits ein großer Fortschritt gegenüber gar keiner Messung.

Der nächste Schritt

Sammeln Sie 50 echte Fragen aus Ihrem Support-Postfach und schreiben Sie zu jeder auf, in welchem Dokument die Antwort steht. Das ist ein Nachmittag Arbeit und die Grundlage für alles Weitere — ohne diesen Satz sind alle folgenden Verbesserungen Behauptungen. Beim Aufbau der Bewertungskette unterstützen wir gern.