Note 01 · RAG · Evaluation
Wie wir ein RAG-System bewerten, bevor es live geht.
Wir lassen kein RAG-System live gehen, ohne dass es vorher durch unser Eval-Harness gelaufen ist. Sieben Metriken, drei Ground-Truth-Sets, ein Regression-Report bei jedem Modell- oder Index-Wechsel. Diese Note beschreibt, was wir messen, wie wir die Datensätze bauen und warum die üblichen Demo-Antworten irreführend sind.
Ein RAG-System auf Basis von „Demo läuft” zu shippen ist verantwortungslos. Wir messen retrieval-Qualität (recall@5, MRR, hit-rate@k) getrennt von generation-Qualität (faithfulness, groundedness, answer relevance) und tracken beides gegen ein versioniertes Ground-Truth-Set aus echten Kundenfragen. Jeder Commit, der Embeddings, Chunk-Strategie oder den Generator anfasst, läuft automatisch durch das Harness. Regression > 5% blockt den Merge.
1 · Warum die übliche Demo lügt
In jeder RAG-Demo werden die gleichen drei Fragen gestellt, die der Entwickler beim Bauen verwendet hat. Sie funktionieren — weil das System genau auf diese Fragen indirekt optimiert wurde. Sobald ein echter Sachbearbeiter, Anwalt oder Praxis-Mitarbeiter andere Formulierungen verwendet, fallen Recall und Faithfulness.
Wir haben das in einem frühen Projekt schmerzhaft gelernt: ein interner Wissens-Bot wirkte in der Demo brillant, ging zwei Wochen nach Go-Live mit 31% falschen Antworten zurück an uns. Seitdem ist das Eval-Harness ein nicht-verhandelbarer Teil unseres Prozesses.
2 · Die sieben Metriken
Wir trennen strikt zwischen „findet das System die relevanten Dokumente?” (retrieval) und „antwortet das System wahrheitsgemäß auf Basis dieser Dokumente?” (generation). Beide Stufen können unabhängig kaputt sein.
| Stufe | Metrik | Was sie misst | Threshold |
|---|---|---|---|
| Retrieval | recall@5 | Anteil Fragen, bei denen das richtige Dokument in den Top-5 liegt | ≥ 0.92 |
| MRR@10 | Mean Reciprocal Rank — wie weit oben das richtige Doc steht | ≥ 0.78 | |
| hit-rate@1 | Top-1 ist das richtige Doc (für strict-mode Antworten) | ≥ 0.65 | |
| Generation | faithfulness | Wird die Antwort vollständig durch den abgerufenen Kontext gestützt? | ≥ 0.88 |
| answer-relevance | Beantwortet das System tatsächlich die gestellte Frage? | ≥ 0.85 | |
| refusal-rate | Anteil korrekter Verweigerungen bei unbeantwortbaren Fragen | ≥ 0.90 | |
| System | latency P95 | End-to-End-Latenz vom Request bis zur fertigen Antwort | ≤ 2.4 s |
Die Thresholds sind nicht universell — wir kalibrieren sie pro Use-Case. Ein juristisches Recherche-System hat eine viel höhere refusal-rate-Anforderung als ein Marketing-Assistent. Wichtig ist nur, dass die Werte vor dem ersten Sprint vom Kunden gegengezeichnet sind.
3 · Das Ground-Truth-Set aufbauen
Das ist der unromantische, zeitaufwändige Teil — und der wichtigste. Wir bauen pro Projekt drei separate Sets:
- Set A — Realität (80–120 Fragen): aus Kunden-Tickets, E-Mails, Anrufprotokollen. Mit ehrlichen Formulierungen, Tippfehlern, halben Sätzen. Pro Frage: die kanonische Antwort plus die Dokument-IDs, die sie stützen.
- Set B — Adversarial (30–50 Fragen): bewusst irreführende oder mehrdeutige Anfragen, Fragen nach Informationen die nicht im Corpus sind, Out-of-Scope-Anfragen. Hier zählt vor allem die refusal-rate.
- Set C — Regression (wächst): jede Frage, die in Produktion einmal falsch beantwortet wurde, kommt hier rein. Mit der korrekten Antwort. So sehen wir sofort, wenn ein zukünftiger Modell-Wechsel alte Bugs wiederbringt.
Wir versionieren diese Sets in einem privaten Repo neben dem Code. Wenn ein Kunde uns ein neues Dokument liefert, das Antworten ändert, aktualisieren wir das Set. Das ist Arbeit. Es lohnt sich jedesmal.
4 · Die Pipeline
Das Harness ist ein bescheidenes Python-Skript, das gegen die produktive (oder Staging-) Pipeline läuft. Kein eigenes Framework, kein „RAG Eval Studio” — wir wollen lesbaren Code, der in 20 Minuten geändert werden kann.
$ uv run python eval/run.py --set A --tag pre-deploy-2026-05
[1/3] Loading ground-truth set A ............... 104 questions
[2/3] Running pipeline (vllm@l40s, top-k=5) ... ████████ 104/104
[3/3] Computing metrics ........................ done
retrieval/recall@5 ............ 0.943 (Δ +0.012 vs baseline)
retrieval/MRR@10 .............. 0.812 (Δ -0.004 vs baseline)
retrieval/hit-rate@1 .......... 0.683 (Δ +0.021 vs baseline)
generation/faithfulness ....... 0.891 (Δ -0.018 vs baseline)
generation/answer-relevance ... 0.876 (Δ +0.005 vs baseline)
generation/refusal-rate ....... 0.923 (Δ -0.011 vs baseline)
system/latency-p95 ............ 1.94 s (Δ -0.21 s vs baseline)
✓ all thresholds met. Δ-faithfulness within ±0.02 tolerance.
Report written to: eval/reports/2026-05-27-pre-deploy.htmlEin HTML-Report-File geht in ein Verzeichnis, das Teil des Repos ist. Bei jedem PR, der den Generator oder Retriever ändert, wird das Harness automatisch ausgeführt — kein Merge ohne grünes Häkchen.
5 · Was wir wahrscheinlich falsch machen
Ehrlich, weil das nicht gelöst ist:
- Faithfulness mit LLM-as-Judge gemessen ist noisy. Wir verwenden zwei verschiedene Judges (lokales Llama 3.1 + Claude als Zweit-Judge) und nehmen den niedrigeren Score. Wichtig: Der Zweit-Judge läuft ausschließlich auf anonymisierten bzw. synthetischen Eval-Sets — es gehen keine Kundendaten an US-Anbieter. Trotzdem schwanken Werte ±0.03 zwischen Läufen.
- Set A ist nie groß genug. 100 Fragen decken nicht die Long-Tail-Themen ab. Wir kompensieren mit Set C, aber bei neuen Domänen sind wir blind für die ersten Wochen.
- Latenz auf Staging-Hardware ist optimistisch. Wir haben gelernt, P95 immer +30% draufzuschlagen, bevor wir versprochene SLAs gegenüber dem Kunden formulieren.
6 · Warum das für regulierte Branchen entscheidend ist
Eine Hörgeräte-Klinik kann nicht 31% falsche Auskünfte tolerieren. Ein Anwalt nicht 5% halluzinierte Paragrafen. Eine Industrie-Wartung nicht 10% irreführende Reparaturanweisungen. Für genau diese Kunden bauen wir RAG. Das Eval-Harness ist der einzige Weg, vor dem ersten Live-Anruf zu wissen, ob das System die Anforderung trifft.
Wenn ein Anbieter Ihnen ein RAG-System verkauft und dabei nichts über Eval, Ground-Truth oder Regression sagt — fragen Sie nach. Wenn die Antwort vage bleibt, wechseln Sie den Anbieter.