Evaluation: „fühlt sich besser an“ ist keine Metrik
Einführung · 8 Abschnitte · ~9 Min Lesezeit · Stand
Warum überhaupt messen
Du änderst Chunking, Prompt oder Reranker — und es „fühlt sich besser an“. Das Problem: Bei jeder Änderung verbesserst du eine Fragenklasse und riskierst, eine andere zu verschlechtern. Ohne Messung sind das Blindflüge, die sich als Fortschritt tarnen.
Evaluation macht Qualität zu einer Regressionsfrage: Ist Version B nachweislich besser als A — über einen festen, repräsentativen Satz von Fällen? Das ist die Disziplin, die Profis von Bastlern trennt.
Das Eval-Set: das Herzstück
Ein Eval-Set ist eine kuratierte Menge von Fragen + erwarteten Antworten/Belegquellen. Seine Qualität deckelt die Aussagekraft aller Metriken darüber — ein schlechtes Set misst zuverlässig das Falsche.
- Aus echtem Traffic ziehen, nicht ausdenken — die reale Fragenverteilung schlägt hypothetische Beispiele.
- Fehlerklassen bewusst abdecken: schwere, mehrdeutige, Out-of-Scope-Fälle gehören rein, nicht nur die, die schon funktionieren.
- Synthetische Fragen nur, um echte Lücken zu füllen — mit dem Wissen, dass sie die Produktionsverteilung nicht perfekt treffen.
Was messen — Metrik zeigt auf Komponente
„Besser“ ist nicht eine Zahl. Die gängigen RAG-Metriken messen verschiedene Stufen der Pipeline — und ein niedriger Wert zeigt, wo der Fehler sitzt:
| Context Recall | Retrieval-Abdeckung: ist der belegende Chunk überhaupt dabei? |
|---|---|
| Context Precision | Ranking: stehen die relevanten Chunks weit oben? |
| Faithfulness | Generierung: ist die Antwort durch den Kontext gedeckt (kein Halluzinieren)? |
| Answer Relevance | Antwort: trifft sie tatsächlich die gestellte Frage? |
Komponente vs. Ende-zu-Ende
Miss nicht nur die Endantwort. Isoliere Retrieval und Generierung, sonst zeigt eine gesunkene Gesamt-Metrik nur, dass irgendwo etwas schlechter wurde — nicht wo.
- Retrieval messen (Recall/Precision)
- Generierung messen (Faithfulness)
- Ende-zu-Ende (Answer Relevance)
Automatisch bewerten: LLM-as-Judge
Menschliches Labeln skaliert nicht auf hunderte Fälle pro Lauf. LLM-as-Judge — ein Modell bewertet Antworten gegen Referenz/Rubrik — ist der übliche Ausweg. Aber der Richter ist selbst ein Modell mit systematischem Bias: bekannte Muster sind Präferenz für längere Antworten, für die zuerst gezeigte Option (Position Bias) und für selbstähnlich formulierte Antworten.
Design senkt den Bias: eine klare Rubrik statt vager „Bewerte 1–10“; paarweise Vergleiche (A vs. B) sind oft stabiler als absolute Punkte; Reihenfolge randomisieren gegen Position Bias.
Offline misst nicht alles: Online-Signale
Ein Eval-Set ist ein Offline-Proxy für die Realität. Es altert und deckt nie die volle, driftende Produktionsverteilung ab. Ergänzend braucht es Online-Signale aus dem echten Betrieb: Nutzer-Feedback (👍/👎), Abbruch-/Wiederhol-Raten, gemeldete Fehler.
Schwellenwerte & Goodhart
Um ein Gate zu bauen, brauchst du Schwellen pro Metrik. Achtung vor Goodhart: „Wird ein Maß zum Ziel, taugt es nicht mehr als Maß.“ Optimiert man blind auf eine einzige Zahl, spielt das System sie hoch, ohne wirklich besser zu werden — etwa Faithfulness maximieren, indem es nur noch wörtlich zitiert.
In die CI — und wo der Mensch bleibt
Der Wert eines Eval-Sets entsteht erst, wenn es erzwungen wird: als automatisiertes Regressionsgate in der CI. Jede Änderung an Retrieval/Prompting muss die Schwellen bestehen, bevor sie deploybar ist — Qualitätssicherung als reproduzierbarer Schritt statt als Hoffnung.
Automatisierung ersetzt den Menschen aber nicht dort, wo das Risiko hoch und die eigene Konfidenz niedrig ist. Menschliche Review gehört stichprobenartig nach Risiko × Unsicherheit eingesetzt, nicht flächendeckend — knappe Augen dorthin, wo ein Fehler am meisten kostet.