# Evaluation

> „Fühlt sich besser an“ ist keine Metrik: Eval-Sets, LLM-as-Judge und Regressionsgates in CI.

Track: [LLMOps](https://physar.tech/learn/llmops)  
Kanonische Fassung: https://physar.tech/learn/llmops/evaluation  
Stand: 2026-07-22  
Interaktiver Teil: 11 Checks (nur im Browser)

## Evaluation: „fühlt sich besser an“ ist keine Metrik

### 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.

> **Merksatz:** Ohne fixes Eval-Set ist jede Qualitätsaussage eine Meinung. Mit ihm ist sie ein Messwert, den man vorher/nachher vergleichen kann.

### 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.

> **Auswahl-Falle:** Ein Set nur aus Fragen, die das System heute richtig beantwortet, zeigt nie eine Schwäche. Genau die harten Fälle sind der Zweck der Übung.

### 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? |

> **Diagnose-Wert:** Wähle die Metrik nach dem Symptom. Ein einzelner „Score“ verschleiert, ob dein Retrieval oder deine Generierung das Problem ist.

### 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)

> **Warum trennen:** Wenn du weißt, dass der richtige Kontext ankam, aber die Antwort trotzdem falsch ist, ist es ein Generierungs-Problem — ein völlig anderer Fix als schlechtes Retrieval.

### 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.

> **Unverzichtbar:** Kalibriere den Judge regelmäßig gegen menschliches Urteil an einer Stichprobe. Ein fixes Eval-Set macht die Messung reproduzierbar — es beseitigt nicht den Bias des Richter-Modells.

### 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.

> **Zwei Blickwinkel:** Offline fängt Regressionen **vor** dem Deploy; Online fängt, was das Eval-Set nicht abbildet. Das eine ersetzt das andere nicht.

### 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.

> **Balance:** Mehrere Metriken zusammen betrachten (Faithfulness gegen Answer Relevance), damit ein Hochtreiben der einen die andere sichtbar kostet. Schwellen sind Pflege-Fläche, kein Einmal-Wert.

### 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.

> **Gleich im Check:** Du entscheidest jetzt selbst: welche Metrik bei welchem Symptom, wie du das Set baust und pflegst, wo LLM-as-Judge trägt — und wo der Mensch unersetzlich bleibt.

## Quellen

- RAGAS: Automated Evaluation of Retrieval Augmented Generation — Es et al., 2023
- Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena — Zheng et al., 2023
- G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment — Liu et al., 2023
- Goodhart's Law — Strathern, 1997 (‚Improving ratings: audit in the British University system‘)
- RAGAS: Automated Evaluation of Retrieval Augmented Generation — Es, James, Anke, Schockaert, 2023
- Goodhart's Law — Strathern, 1997