LLM as a Judge: Wer bewertet den Bewerter? 100 KI-Urteile von Hand nachgeprüft

Für die zweite Runde meines lokalen KI-Benchmarks sind 41 Modelle gegen 100 Aufgaben angetreten, jede Aufgabe zehnmal wiederholt: 41.000 Antworten. Kein Mensch liest 41.000 Antworten. Also bewerten KI-Modelle die Antworten anderer KI-Modelle – „LLM as a judge" nennt sich das Verfahren, und es steckt inzwischen hinter fast jedem Benchmark, den man so liest.

Nur: Woher weiß ich, dass die Bewerter richtig bewerten? Das habe ich diesmal nicht einfach angenommen, sondern systematisch geprüft. Mit verdeckten Zweitprüfern, einem komplett überarbeiteten Bewertungssystem, zwei unabhängigen Judge-Familien – und am Ende mit 100 Antworten, die ich selbst von Hand bewertet habe, ohne die Urteile der Judges zu kennen. Das Ergebnis: Die Judges sind besser als ich erwartet hätte. Aber der Weg dahin hat einige unbequeme Fehler ans Licht gebracht.

In aller Kürze

• 41 Modelle × 100 Aufgaben × 10 Wiederholungen = 41.000 Antworten, jede von mehreren KI-Judges bewertet
• Ein blindes Stichproben-Audit der ersten Bewertungsrunde fand echte Fehler: einen Software-Bug, der „nicht erfüllt" als „erfüllt" verbuchte, Verbindungsabbrüche, die als 0 Punkte zählten, und beschädigte Modell-Dateien
• Das neue Bewertungssystem (Scoring v2) prüft jede Bedingung einzeln statt ganzer Kriterienkataloge auf einmal – und kombiniert LLM-Urteile mit deterministischen Python-Checks
• Zwei unabhängige Judge-Familien (Qwen 3.8-27B und Gemma 4-31B) bewerten alles doppelt – ihre Ranglisten stimmen mit einer Rangkorrelation von 0,996 überein
• Der Härtetest: 100 Antworten von Hand bewertet, blind. Die v2-Judges treffen mein Urteil in 81 bis 82 % der Fälle (Vorgänger-Judges: 65 bis 77 %) – bei binären Kriterien sogar in 100 %
• Nebenbei gelernt: Der Mensch braucht dieselben Bewertungsregeln wie die Maschine – sonst vergleicht man Äpfel mit Birnen

Alle Ergebnisse, Antworten und Einzelurteile sind wie immer im interaktiven Viewer einsehbar.

Warum das überhaupt ein Problem ist

Wenn ein Benchmark behauptet „Modell X schafft 92 von 100 Punkten", dann steckt hinter dieser Zahl eine Kette von Entscheidungen: Wer hat bewertet? Nach welchen Regeln? Und hat der Bewerter die Regeln verstanden – oder nur so getan?

Bei Testrunde 1 liefen zwei Judges parallel und stimmten in über 85 % der Fälle überein. Das klang beruhigend. Aber Übereinstimmung zwischen zwei Judges beweist nur, dass beide dasselbe denken – nicht, dass beide das Richtige denken. Zwei Bewerter können sich auch einig im Irrtum sein.

Für Testrunde 2 mit dreimal so vielen Aufgaben wollte ich es genauer wissen.

Schritt 1: Das blinde Audit – und was dabei aufflog

Der erste Schritt war ein verdecktes Audit: Stichproben aus den Bewertungen wurden unabhängigen Prüf-Instanzen vorgelegt – mit der Aufgabe und den Bewertungsregeln, aber ohne das Urteil des Judges. Erst danach wurden beide Urteile verglichen.

Dabei kamen Dinge ans Licht, die kein Dashboard der Welt anzeigt:

Fehler 1: Der „False"-Bug. Einer der Judges lieferte seine Urteile gelegentlich als Text („False") statt als echten Wahrheitswert. Die Auswertung interpretierte den Text „False" als – wahr. Ergebnis: über 800 Bewertungen, bei denen „Kriterium nicht erfüllt" als „erfüllt" gezählt wurde. Ein klassischer Programmierfehler, unsichtbar in jeder Statistik, gefunden nur durch den Abgleich von Hand.

Fehler 2: Verbindungsabbrüche als Nullpunkte. Ein Judge-Server stürzte zwischendurch ab. Über 3.000 Bewertungen waren in Wirklichkeit gar keine Bewertungen, sondern Fehlermeldungen – gezählt als 0 Punkte für das jeweils getestete Modell.

Fehler 3: Beschädigte Modell-Dateien. Beim Umzug auf eine neue SSD wurden mehrere Modell-Dateien still beschädigt – die Kopie lief durch, die Prüfsumme stimmte nicht. Betroffene Modelle produzierten unter bestimmten Bedingungen nur noch Zeichenmüll. Die Benchmark-Läufe selbst waren zum Glück sauber (sie liefen noch gegen die Originale), aber die Lektion sitzt: Nach jedem Datenträger-Umzug Prüfsummen kontrollieren.

Alle drei Fehler wurden behoben, alle betroffenen Bewertungen neu berechnet. Und alle drei wären ohne systematisches Audit nie aufgefallen.

Scoring v2: Jedes Kriterium einzeln prüfen, mit Zitat-Pflicht

Das Audit zeigte auch ein strukturelles Problem: Die Judges bekamen ganze Kriterienkataloge auf einmal vorgelegt („Prüfe: enthält Datum X, Betrag Y, Namen Z, keine Preisnennung, Sie-Form …"). Je länger die Liste, desto häufiger übersah der Judge einzelne Punkte oder vermischte sie.

Scoring v2 dreht das um:

• Jede Bedingung wird einzeln geprüft. Statt einer Sammelfrage stellt das System pro Kriterium eine eigene, fokussierte Prüffrage – mit Beleg-Pflicht: Der Judge muss die Textstelle zitieren, auf die er sein Urteil stützt. Das Zitat wird automatisch gegen die Antwort abgeglichen.
• Was ein Computer besser prüft, prüft ein Computer. Wortlimits, JSON-Struktur, Code-Ausführung, Anrede-Form: dafür braucht es kein Sprachmodell, sondern reguläre Ausdrücke und eine Python-Sandbox. Aber – und das war mir wichtig – inhaltliche Kriterien entscheidet weiterhin das LLM. Ein Datum kann in hundert Schreibweisen auftauchen; ein starrer Textabgleich würde korrekte Antworten durchfallen lassen.
• Zwei unabhängige Judge-Familien. Alles wird doppelt bewertet: von Qwen 3.8-27B (NVFP4, über NInfer) und von Gemma 4-31B (Q4, über llama.cpp). Zwei verschiedene Modellfamilien, zwei verschiedene Hersteller, zwei verschiedene Inferenz-Engines. Wenn beide unabhängig zum selben Schluss kommen, ist das ein deutlich stärkeres Signal als ein Judge allein.

Das Ergebnis der Doppelbewertung: Die Ranglisten der beiden Judge-Familien korrelieren mit Spearman 0,996 – praktisch identisch. Auf Ebene einzelner Urteile stimmen sie je nach Fragetyp in 85 bis 96 % der Fälle überein.

Das Gold-Set: 100 Antworten von Hand bewertet

Bleibt die Frage vom Anfang: Zwei Judges können sich einig im Irrtum sein. Der einzige Weg, das auszuschließen, ist ein menschliches Referenz-Urteil.

Also habe ich ein Gold-Set gebaut: 100 Antworten, stratifiziert gezogen (zur Hälfte Fälle, in denen sich die alten Judges uneinig waren – also gezielt die schwierigen), über 39 der 41 Modelle verteilt. Die habe ich selbst bewertet, in einem eigens gebauten Labeling-Tool: blind, ohne die Judge-Urteile zu sehen, nach denselben schriftlichen Regeln, die auch die Judges bekommen. Das hat richtig viel Zeit gekostet – und war sie wert.

So schlagen sich die Judges gegen das menschliche Referenz-Urteil:

*GPT hat nur einen Teil der Antworten bewertet (n=51).

Aufgeschlüsselt nach Fragetyp wird deutlich, wo v2 gewonnen hat:

Drei Dinge stechen heraus:

1. Binäre Kriterien: 100 %. Bei Ja/Nein-Kriterien („Verweigert das Modell die Antwort?") treffen die v2-Judges mein Urteil in allen Fällen. Die Einzelbedingungs-Prüfung mit Beleg-Pflicht funktioniert.

2. Faktenprüfung: rund 10 Prozentpunkte besser als v1. Genau da, wo die alten Sammelkatalog-Prompts patzten, holt v2 am meisten auf.

3. Die schwierigen Fälle bleiben schwierig – und eine Kategorie geht an v1. Bei den 50 gezielt ausgewählten Streitfällen liegen die v2-Judges bei 74 % Übereinstimmung mit mir, die alten bei 38 bis 62 %. Wobei ich ehrlich sagen muss: Bei einigen dieser Grenzfälle war ich mir selbst nicht sicher – perfekte Übereinstimmung ist hier kein realistisches Ziel, zwei menschliche Prüfer würden sie untereinander auch nicht erreichen. Die eine Kategorie, in der v2 schlechter abschneidet, ist die E-Mail-Rubrik: Dort bewerten die v2-Judges nach ihrem verschärften Regelwerk etwas strenger, als ich es tue – meist um eine Qualitätsstufe. Nach der Regel-Nachkalibrierung liegt die mittlere Abweichung mit 1,6 bis 1,8 Stufen (auf der 10er-Skala) zwar gleichauf mit den alten Judges, die Pass/Fail-Grenze ziehen die alten aber noch etwas öfter wie ich. Freie Qualitätsbewertung bleibt die schwierigste Disziplin – für Mensch wie Maschine.

Die unbequemste Erkenntnis: Ich war Teil des Problems

Eine Anekdote, die ich nicht unterschlagen will, weil sie das Kernproblem von „LLM as a judge" besser illustriert als jede Statistik.

Bei den E-Mail-Aufgaben (bewertet auf einer 5-Punkte-Skala mit beschriebenen Qualitätsstufen) wichen die v2-Judges massiv von meinen Urteilen ab – und zwar ausnahmslos nach unten. Erste Vermutung: Die Judges sind kaputt. Die Wahrheit: Mein Labeling-Tool hatte mir die Detail-Definitionen der Qualitätsstufen nicht angezeigt. Die Judges bewerteten nach dem vollständigen Regelwerk („‚ideal' zählt als unzulässige Übertreibung"), ich nur nach den Kurzbeschreibungen – und intuitiv milder.

Nach dem Fix habe ich die betroffenen Fälle neu bewertet und dabei zwei Dinge gelernt: Erstens rückten meine Urteile näher an die Judges heran. Zweitens fand ich einzelne Regeln beim Nachlesen selbst zu streng – etwa dass die Formulierung „ein anderer Kandidat" als verbotene Preisgabe des Geschlechts zählte, oder dass ein Datums-Platzhalter („[Datum], 10–11 Uhr") als unkonkret abgewertet wurde, obwohl die Aufgabe gar kein heutiges Datum nennt, aus dem sich ein echtes Datum ableiten ließe. Diese Regeln habe ich geändert, und die drei betroffenen Aufgaben wurden für alle 41 Modelle neu bewertet – an der Spitze der Rangliste änderte das nichts.

Die Lehre: Der Judge ist immer nur so gut wie das Regelwerk – und das Regelwerk testet man nur, indem ein Mensch es selbst anwendet. Wer LLM-Judges einsetzt, ohne je selbst nach denselben Regeln zu bewerten, merkt nie, ob die Regeln überhaupt das messen, was er meint.

Was das für die Benchmark-Ergebnisse heißt

• Die veröffentlichten Stände vom 18.08. und 24.08. bleiben unverändert online – inklusive ihrer bekannten Schwächen. Ergebnisse nachträglich still zu ändern wäre Gift für die Vertrauenswürdigkeit.
• Die v2-Bewertung wird als neuer, klar gekennzeichneter Stand veröffentlicht – mit beiden Judge-Familien, allen Einzelurteilen und diesem Validierungsbericht.
• An der Spitze der Rangliste ändert sich übrigens wenig: Die Rangkorrelation zwischen v1 und v2 liegt bei 0,966. Die groben Aussagen der bisherigen Stände bleiben gültig – aber jetzt mit belastbarem Fundament.

LLM-as-a-Judge in der Praxis: 6 Lehren

1. Übereinstimmung zwischen Judges ist kein Beweis für Richtigkeit. Zwei Judges mit demselben Prompt machen dieselben Fehler. Erst ein menschliches Referenz-Set macht Qualität messbar.
2. Eine Bedingung pro Prüffrage. Sammelkataloge produzieren übersehene Kriterien. Einzelprüfung mit Zitat-Pflicht ist aufwendiger – und messbar besser.
3. Deterministisch prüfen, was deterministisch prüfbar ist – aber Inhaltsfragen dem LLM lassen. Ein Regex erkennt keine hundert Datumsschreibweisen.
4. Fehlerzustände sind keine Nullpunkte. Verbindungsabbrüche, Timeouts und Parse-Fehler müssen als „unbewertet" markiert und wiederholt werden, nie als 0 gezählt.
5. Typ-Prüfung ernst nehmen. Der Text „False" ist in vielen Programmiersprachen wahr. Klingt banal, hat hier über 800 Urteile gedreht.
6. Der Mensch braucht dieselben Regeln wie die Maschine. Sonst validiert man nicht den Judge, sondern die eigene Intuition.

Was du jetzt tun kannst

Die kompletten Ergebnisse inklusive aller Einzelurteile beider Judge-Familien sind im interaktiven Benchmark einsehbar – jede Antwort, jedes Kriterium, jede Begründung.

Wenn du selbst KI-gestützte Bewertung oder Qualitätssicherung in deinem Unternehmen einsetzen willst – ob für Benchmarks, Dokumentenprüfung oder automatisierte Kontrolle von KI-Ausgaben – buche einen Potenzialcheck. Ehrliche Einschätzung, keine Verkaufsshow. Die Fehler, die ich hier selbst gemacht habe, musst du nicht wiederholen.