Lösungen für
Bitte auswählen
Web-App testen
ki-konzepte

LLM-Qualität messen — Evals, Benchmarks, Judges

Redaktion ·

Warum dich LLM-Evaluation angeht

„Funktioniert unser RAG-System gut?” ist die einzige Frage, die wirklich zählt — und gleichzeitig die, vor der die meisten Teams kapitulieren. Stattdessen wird auf das Bauchgefühl der Demo-Runde gehört, auf einen Screenshot mit drei guten Antworten, oder auf Public-Benchmark-Scores, die das eigene Problem überhaupt nicht abbilden. Drei Wochen später ist unklar, warum die Antwortqualität in Produktion eingebrochen ist — weil es nie eine Messlatte gab.

LLM-Evaluation ist die Antwort darauf. Sie funktioniert anders als klassische Software-Tests, weil die Ausgabe eines Sprachmodells nicht binär richtig oder falsch ist. Eine Antwort kann faktisch korrekt, aber irrelevant sein. Sie kann gut klingen und trotzdem halluziniert sein. Sie kann besser sein als die Vorgängerversion in 80 Prozent der Fälle, aber in den restlichen 20 Prozent katastrophal regressieren. Wer das messen will, braucht drei Ebenen — öffentliche Benchmarks, eigene Evals, LLM-as-a-Judge — und vor allem Klarheit darüber, was jede Ebene leistet und was nicht.

Die drei Ebenen der LLM-Evaluation

Ebene 1 — Öffentliche Benchmarks

Public Benchmarks sind standardisierte Testsets, an denen Modellanbieter ihre Modelle messen. Sie beantworten die Frage „Wie schlau ist Modell X im Allgemeinen?” — nicht „Wie gut funktioniert es für meinen Anwendungsfall?”. Trotzdem sind sie der erste Anhaltspunkt bei der Modellauswahl.

Die wichtigsten:

  • MMLU (Massive Multitask Language Understanding): 57 Multiple-Choice-Themengebiete von Mathe bis Jura. Misst Faktenwissen und einfaches Reasoning.
  • HumanEval: 164 Python-Programmieraufgaben mit Unit-Tests. Misst Code-Generierung in der Kleinform.
  • SWE-Bench Verified: 500 echte GitHub-Issues aus Open-Source-Python-Repos. Das Modell bekommt Issue + Repo und muss einen Diff erzeugen, der die Tests grün macht. Misst Coding-Agent-Fähigkeit auf realistischer Aufgabe.
  • GPQA: Graduate-Level-Fragen aus Physik, Chemie, Biologie — bewusst so gestaltet, dass Google nicht hilft.
  • Chatbot Arena (Arena): Crowd-sourced Pairwise-Vergleich, bei dem Nutzer zwei anonyme Modellantworten gegeneinander voten. Ergebnis ist ein Elo-Rating. Misst menschliche Präferenz statt Faktentreue.

Was Public Benchmarks nicht leisten: Aussagen über deinen konkreten Use Case. Ein Modell mit 90 Prozent MMLU kann auf deinen Support-Tickets unterirdisch performen, weil dein Domain-Vokabular im MMLU-Trainingsset nicht vorkam.

Ebene 2 — Eigene Evals

Eigene Evals sind das Werkzeug, das die meisten Teams brauchen, aber die wenigsten bauen. Im Kern: ein fester Datensatz mit erwarteten Outputs (oder zumindest erwarteten Eigenschaften), gegen den jede Modell- oder Prompt-Änderung läuft.

Aufbau:

  1. Datensatz — 50 bis 500 reale Fälle aus deiner Domäne. Einseitig zusammengestellt geht nicht: Du brauchst die einfachen Fälle (Sanity Check), die typischen Fälle (Volumen) und die fiesen Fälle (Edge Cases, die in Produktion sonst alle paar Tage auftauchen).
  2. Metriken — pro Fall eine messbare Eigenschaft. Bei Klassifikation: Accuracy, F1. Bei freitextlichen Antworten: keyword-basierte Checks („Antwort enthält die Telefonnummer”), Regex-Pattern, oder LLM-as-a-Judge (siehe Ebene 3).
  3. Pipeline — automatisierter Lauf, der Datensatz × Modellversion durchschleust und Ergebnisse persistiert. Idealerweise als CI-Job, der bei jedem Prompt-PR den Diff zur Vorgängerversion zeigt.

Der Sprung von „wir haben 20 manuelle Tests in einem Notebook” zu „CI-Eval läuft bei jedem Merge” ist der wichtigste Reife-Schritt. Ohne ihn ist jede Modell- oder Prompt-Änderung Bauchgefühl.

Ebene 3 — LLM-as-a-Judge

Bei freitextlichen Antworten skaliert manuelle Bewertung nicht. Die Lösung: ein zweites LLM bewertet die Ausgaben des ersten. Das Judge-Modell bekommt Frage, Antwort und Bewertungs-Kriterien als Prompt und liefert eine Note.

Das funktioniert überraschend gut — und hat überraschend viele Bias-Probleme. LLM-as-a-Judge ist kein Allheilmittel.

Stolperfallen — wo Evaluation in der Praxis schiefgeht

Benchmark-Sättigung und Daten-Kontamination

Public Benchmarks veralten schnell. MMLU liegt bei Frontier-Modellen 2026 bei 97–99 Prozent — die Werte differenzieren nicht mehr. Schlimmer: Studien zeigen, dass MMLU-Fragen wortwörtlich oder in Quasi-Form in Trainingscorpora moderner Modelle auftauchen. Das verzerrt Scores um geschätzt 8–15 Punkte nach oben. HumanEval ist seit 2021 öffentlich — dass Modelle dort 92 Prozent erreichen, sagt wenig darüber, wie sie auf neuem Code abschneiden. Eine Audit-Auswertung Anfang 2026 fand: Modelle mit 92 Prozent HumanEval-Score lieferten auf neuen Enterprise-Codebases nur in 61–74 Prozent der Fälle produktionsreifen Code.

Konsequenz: Frontier-Vergleiche brauchen kontaminations-resistente Benchmarks — LiveCodeBench mit rollierenden Fragen, SWE-Bench Verified mit echten Issues, Chatbot Arena mit menschlicher Präferenz. Die alten Klassiker bleiben für Sanity-Checks am unteren Modellrand nützlich, aber nicht für „welches der besten drei Modelle nehmen wir”.

Judge-Bias

LLM-as-a-Judge hat drei dokumentierte Bias-Klassen:

  • Position-Bias: Bei A/B-Vergleichen bevorzugt der Judge systematisch die Antwort an einer bestimmten Position (oft die erste oder letzte). Mitigation: jeden Vergleich zweimal mit getauschter Reihenfolge laufen lassen.
  • Verbosity-Bias: Der Judge belohnt längere, strukturierter wirkende Antworten — auch wenn der Inhalt dünn ist. Eine prägnante richtige Antwort verliert gegen eine ausschweifende richtige Antwort. Mitigation: Längen-Constraint im Judge-Prompt, oder Length-Normalisierung.
  • Self-Preference-Bias: Ein Judge-Modell bevorzugt Outputs, die seinem eigenen Stil ähneln — das eigene Modell schneidet überproportional gut ab. Forschung führt das auf niedrigere Perplexität bei stilverwandten Texten zurück. Mitigation: nicht das Modell als Judge verwenden, das auch generiert; idealerweise mehrere Judges aus unterschiedlichen Familien.

Eine RAND-Studie 2026 stellte fest, dass kein Judge über alle Benchmarks hinweg verlässlich ist — Frontier-Modelle hatten auf anspruchsvollen Bias-Benchmarks Fehlerraten über 50 Prozent. Heißt: Judge-Scores sind ein Indikator, kein Wahrheitsserum.

Goodhart-Effekt

„When a measure becomes a target, it ceases to be a good measure.” Sobald du ein Eval-Set hast und gegen die Score optimierst, drift das System darauf — und nicht zwangsläufig auf die echte Qualität. Ein Prompt, der den Judge zuverlässig zufriedenstellt, ist nicht automatisch ein Prompt, der echte Nutzer zuverlässig zufriedenstellt. Mitigation: Eval-Sets in „dev” (für Iteration) und „holdout” (nur für gelegentliche Realitätschecks) trennen, und periodisch reale User-Logs samplen.

Eval-Aging

Eval-Datensätze altern. Neue Produktfeatures, neue Domain-Begriffe, neue Use Cases tauchen auf — das Eval bildet die alte Welt ab. Faustregel: Eval-Set quartalsweise um 10–20 Prozent neue Fälle ergänzen, alte Fälle aussortieren, wenn sie keinen Edge-Case mehr abdecken.

RAG-Spezifik — die RAGAS-Metriken

RAG-Systeme haben eine zusätzliche Schwierigkeit: zwei Komponenten können unabhängig versagen — der Retriever findet die falschen Dokumente, oder der Generator interpretiert die richtigen falsch. Allgemeine „ist die Antwort gut?”-Metriken erkennen nicht, welcher Teil bricht.

Das RAGAS-Framework adressiert das mit vier Kernmetriken:

| Metrik | Was sie misst | Komponente | |---|---|---| | Faithfulness | Sind alle Aussagen der Antwort durch den abgerufenen Kontext gedeckt? | Generator | | Answer Relevancy | Beantwortet die Antwort die ursprüngliche Frage? | Generator | | Context Precision | Stehen relevante Chunks oben im Ranking, nicht unten? | Retriever | | Context Recall | Decken die abgerufenen Chunks alle Aspekte der Frage ab? | Retriever |

Mit dieser Trennung lassen sich Probleme zuordnen: Faithfulness niedrig → das Modell halluziniert oder weicht vom Kontext ab. Context Recall niedrig → der Retriever liefert nicht genug. Context Precision niedrig → der Retriever liefert zu viel Rauschen, das den Generator ablenkt.

RAGAS hat darüber hinaus weitere Metriken (Context Entities Recall, Noise Sensitivity, Response Relevancy), aber die vier oben sind der pragmatische Einstieg. Wichtig: Auch RAGAS nutzt intern LLM-as-a-Judge — alle Bias-Probleme aus Ebene 3 gelten weiter.

Vom ersten Test zum CI-Eval — ein Reifegrad-Modell

| Stufe | Was vorhanden ist | Was fehlt | Nächster Schritt | |---|---|---|---| | 0 — Bauchgefühl | Ein Demo-Lauf, drei Screenshots | Reproduzierbarkeit | 20 reale Fälle in ein Spreadsheet | | 1 — Manuelles Eval | 20–50 Fälle, manuell durchgespielt bei Änderungen | Zeit-Aufwand, Inkonsistenz | Skript, das Modell × Datensatz automatisiert ausführt | | 2 — Automatisiertes Eval | Eval-Skript läuft auf Knopfdruck, Ergebnisse als JSON/CSV | Bewertung der Outputs | Metriken (Regex, Keywords, LLM-as-a-Judge) hinzufügen | | 3 — CI-Eval | Eval läuft automatisch bei jedem Prompt-/Modell-PR, blockiert Merges bei Regression | Production-Realität | Periodisches Sampling realer User-Logs ins Eval-Set | | 4 — Production-Aware Eval | Eval-Set wird kontinuierlich um reale Fälle ergänzt, Drift wird beobachtet | — | Eval-Pipeline pflegen, Set rotieren |

Die meisten Teams sitzen auf Stufe 0 oder 1 und springen mit der Begründung „unsere Outputs sind zu offen für Tests” über die nächsten Stufen. Das ist fast immer ein Trugschluss — auch freitextliche Outputs lassen sich automatisch bewerten, nur eben nicht mit assertEqual.

FAQ

Brauche ich überhaupt eigene Evals, wenn ich nur die OpenAI-API nutze?
Ja, sobald du Prompts iterierst oder zwischen Modellen wechselst. Public Benchmarks sagen dir nicht, ob dein Prompt nach der letzten Änderung in deinen Edge-Cases noch funktioniert.
Wie groß muss mein Eval-Datensatz sein?
50 Fälle reichen für die ersten Iterationen. 200–500 sind solide für CI. Mehr ist nur sinnvoll, wenn die Fälle echte Diversität abbilden — 5.000 Varianten desselben Musters helfen nicht.
Welches Modell als Judge nehmen?
Idealerweise ein anderes als das, was du evaluierst — und ruhig ein günstigeres. Judge-Calls summieren sich. Ein Sonnet-Judge auf Haiku-Outputs ist ein guter Default. Vermeide Self-Judging.
Was kosten Evals laufend?
Bei einem 200-Fall-Set mit Judge-Bewertung pro Fall liegen die Kosten pro Lauf bei rund 20–80 Cent (abhängig vom Judge-Modell). Bei zehn Läufen pro Tag also wenige Euro im Monat — vernachlässigbar gegen die Engineering-Zeit, die du sparst.
Reicht Chatbot Arena nicht als Eval?
Nein. Arena-Elo sagt dir, welches Modell Menschen im Schnitt bevorzugen. Es sagt dir nichts darüber, wie ein Modell auf deinen Daten arbeitet. Arena ist Modellauswahl, eigene Evals sind Modellbetrieb.

Fazit

Wer LLM-Systeme produktiv betreibt, kommt ohne eigene Evals nicht aus. Public Benchmarks helfen bei der initialen Modellauswahl, aber sie messen nicht dein Problem. LLM-as-a-Judge skaliert die Bewertung, hat aber dokumentierte Bias-Klassen, die man kennen muss. Für RAG-Systeme bringen die RAGAS-Metriken zusätzlich die Trennung zwischen Retriever- und Generator-Fehlern.

Pragmatischer Einstiegspfad: 50 reale Fälle in ein Spreadsheet, drei Wochen später ein Skript, das die Fälle automatisch durchläuft, drei Monate später ein CI-Eval, das jeden Prompt-Merge gegen die Vorgängerversion vergleicht. Damit bist du in der Liga, in der Modell- und Prompt-Änderungen begründbar sind statt geraten.

Und immer im Hinterkopf: Goodhart. Sobald du eine Score optimierst, optimierst du auf die Score, nicht auf die Wirklichkeit. Halte einen Holdout-Datensatz zurück, sample reale User-Logs, schau gelegentlich mit den eigenen Augen rein. Eval-Frameworks sind Werkzeuge, keine Wahrheit.

Themenuebersicht

KI-KonzepteEvaluation