Wo LLM-Judges versagen

Im vorigen Kapitel ging es darum, einen Judge zu bauen, der funktioniert. In diesem Kapitel geht es darum, was „funktioniert“ bedeuten kann und was nicht. Denn die Fehlermodi von LLM-Judges sind systematisch und messbar. In der Ausgabe sieht man sie meist nicht.

Ein Judge meldet keinen Fehler, wenn er verzerrt ist. Er meldet einen Wert.

Erwartungen kalibrieren

Vor den Verzerrungen eine Frage: Wie gut kann ein Judge realistisch werden? Die Antwort brauchen Sie, bevor Sie an Ihrem Judge feilen. Sonst arbeiten Sie an einer Trefferquote von 0,84 weiter, die für die Aufgabe schon so gut ist, wie es geht. Oder Sie geben sich mit 0,6 zufrieden, wo 0,9 erreichbar wäre. Die Grenze kennt man aus Studien, in denen Judges gegen Menschen gemessen wurden. Dieser Abschnitt fasst sie zusammen.

Stellen Sie sich zwei Personen vor. Beide bewerten dieselben 100 Zusammenfassungen als brauchbar oder nicht brauchbar. Bei 85 davon sind sie sich einig. Das sind 85 % Übereinstimmung. Jetzt ersetzen Sie eine der beiden Personen durch ein Modell. Forscher haben genau das viele Male getan. Zwei Ergebnisse sollten Sie sich merken:

• Bei offenen Fragen stimmt ein Judge so oft mit Menschen überein wie Menschen untereinander. MT-Bench besteht aus Gesprächsfragen ohne eine einzige richtige Antwort. Dort stimmte gpt-4 in 85 % der Fälle mit menschlichen Fachleuten überein. Die Fachleute untereinander waren sich nur in 81 % der Fälle einig. Das ist die Zahl, die alle zitieren. Sie ist echt. Aber sie sagt ebenso viel über die Aufgabe wie über den Judge: Wo Menschen selbst uneins sind, ist „so gut wie ein Mensch“ eine niedrige Latte.
• Bei Fragen mit einer richtigen Antwort kommt ein Judge nah an Menschen heran, aber nicht gleichauf. TriviaQA besteht aus schlichten Wissensfragen. Dort sind sich zwei Menschen fast vollständig einig. gpt-4 stimmt mit ihnen deutlich seltener überein. Diese Lücke ist die realistische Obergrenze für einen Judge bei einer klar definierten Aufgabe.

Die TriviaQA-Zahlen fehlen im zweiten Punkt mit Absicht. Um sie zu lesen, braucht es noch eine Idee.

Schlichte Übereinstimmung schmeichelt. Angenommen, 90 von 100 Antworten sind gut. Zwei Personen sagen zu allem „gut“. Dann sind sie sich bei 90 Antworten einig, ohne eine einzige beurteilt zu haben. Deshalb ziehen Forscher die Einigkeit ab, die man schon durch Raten bekäme. Das Ergebnis heißt Cohens κ (Kappa). 0 heißt: nicht besser als Raten. 1 heißt: vollständig einig. Auf TriviaQA erreichen die Menschen κ 0,97, gpt-4 erreicht 0,84. Als schlichte Prozentzahl stünde bei beiden „über 90 %“. Die Lücke wäre unsichtbar.

Korrelation stellt eine andere Frage. Manche Studien fragen nicht: „Haben beide dasselbe Urteil gefällt?“ Sie fragen: „Haben beide die Antworten gleich geordnet?“ Stellt der Mensch eine Antwort über eine andere, tut der Judge das dann auch? Diese Zahlen (Pearson, Spearman ρ, Kendalls τ) laufen ebenfalls von 0 bis 1. Sie messen aber die Reihenfolge, nicht die Urteile. Eine Zeile mit der einen Kennzahl lässt sich nicht mit einer Zeile mit der anderen vergleichen.

Fürs Protokoll: Das haben rund zwei Dutzend Studien gefunden. Lesen Sie jede Zeile nur gegen ihre eigene menschliche Referenz in der letzten Spalte. Nie gegen eine andere Zeile.

Faustregel für alle Kennzahlen: Über 0,8 ist stark. 0,5 bis 0,8 ist mit Vorsicht brauchbar. Unter 0,5 sind Judge und Mensch oft verschiedener Meinung.

Was Sie daraus mitnehmen. Erstens: Ein guter Judge liegt bei einer klar definierten Aufgabe etwa bei κ 0,8 gegen Menschen, nicht bei 1,0. Die Trefferquote von 0,84 im Praxisbeispiel ist also kein Zwischenstand, sondern das, was man erwarten darf. Zweitens: Bevor Sie eine Zahl aus einer Studie mit Ihrer vergleichen, prüfen Sie, welche Kennzahl sie ist. 85 % Übereinstimmung, κ 0,84 und ρ 0,67 beantworten drei verschiedene Fragen. Drittens: Berichten Sie Ihre eigene Messung so, wie Kapitel 5 es verlangt, als Trefferquote und Richtig-negativ-Rate mit ihren Fallzahlen. Dann können Sie sie mit der Zeile für Ihre Aufgabenart vergleichen, und mit nichts sonst.

Befund: Derselbe Effekt zeigt sich bei der Suchrelevanz. Dort erreichen Judges nur ein Cohens κ von 0,3–0,5. Kendalls τ und Spearmans ρ liegen auf denselben Daten bei 0,8–0,9. Die Korrelationskennzahl und die Übereinstimmungskennzahl sind sich also uneins, ob der Judge gut ist. Berichten Sie beide. Oder sagen Sie, welche Sie gewählt haben und warum.

Quelle: Eugene Yan, Evaluating LLM-Evaluators

Die drei klassischen Verzerrungen

Positions-Bias

Im paarweisen Vergleich bevorzugen Judges eine Position statt einer Antwort.

So sieht das in der Praxis aus. Sie zeigen dem Judge zwei Antworten und fragen, welche besser ist:

Runde 1:  A = die knappe Antwort     B = die wortreiche   -> Judge wählt A
Runde 2:  A = die wortreiche Antwort B = die knappe       -> Judge wählt wieder A

Dieselben zwei Antworten, dieselbe Frage, entgegengesetztes Urteil. Der Judge hat die Position gewählt, nicht die Antwort. Sie würden das nie bemerken. Denn ein einzelner Durchlauf zeigt Ihnen immer nur eine der beiden Runden.

Befund: gpt-3.5-turbo bevorzugte die zuerst gezeigte Antwort in 50,0 % der Paare, claude-v1 in 75,0 %. Vertauscht man die Reihenfolge, bleibt das Urteil bei gpt-3.5-turbo in 46,2 % der Fälle gleich, bei claude-v1 in 23,8 %.

Quelle: Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, NeurIPS 2023, Tabelle 2

Die übliche Abhilfe: Sie führen jeden Vergleich zweimal durch, einmal mit vertauschter Reihenfolge. Nur übereinstimmende Urteile zählen. Kippt das Urteil, gilt das als Unentschieden. Das kostet doppelt. Gegen diese Verzerrung wirkt es.

Umstritten: Lange galt als sicher: Wer vom paarweisen Vergleich zur punktweisen Bewertung mit Rubric wechselt, wird den Positions-Bias los. Eine Arbeit aus dem Jahr 2026 hat rubrikbasierte LLM-Judges untersucht. Sie findet Positionseffekte auch bei punktweiser Bewertung. Sind Sie eigens auf Rubrics umgestiegen, um dem Positions-Bias zu entkommen? Dann prüfen Sie diese Annahme auf Ihren eigenen Daten, statt sie zu übernehmen.

Quelle: Position Bias in Rubric-Based LLM-as-a-Judge, 2026

Längen-Bias

Was „aufblähen“ hier heißt, ist konkret und ein wenig absurd. Die Attacke nimmt eine richtige Antwort. Dann wiederholt sie deren Inhalt als Liste. Neues kommt nicht hinzu:

Original:   „Paris ist die Hauptstadt von Frankreich.“

Aufgebläht: „Paris ist die Hauptstadt von Frankreich. Kernpunkte:
             1) Paris ist die Hauptstadt von Frankreich.
             2) Frankreichs Hauptstadt ist Paris.
             3) Der Regierungssitz befindet sich in Paris.“

Keine neue Information. Nach keinem Maßstab, den ein Nutzer anlegen würde, ist die eine Antwort besser als die andere.

Befund: Genau bei dieser Attacke („repetitive list“) bevorzugten claude-v1 und gpt-3.5-turbo die aufgeblähte Fassung in 91,3 % der Fälle. gpt-4 tat das nur in 8,7 % der Fälle.

Quelle: Zheng et al., MT-Bench, Tabelle 3

Die Spannweite ist der eigentliche Befund. Längen-Bias ist kein Naturgesetz der Technik. Er ist eine Eigenschaft des jeweiligen Judge-Modells. Fremde Zahlen sagen Ihnen nicht, wie stark Ihr Judge betroffen ist. Das müssen Sie selbst messen.

Diese Verzerrung ist gefährlich, weil sie die Optimierung überlebt. Angenommen, Sie tunen Prompts gegen einen Judge mit Längen-Bias. Dann erzeugen Sie zuverlässig ein wortreicheres Produkt und einen steigenden Wert. Die Nutzer erleben es als schlechter. Halten Sie das unter Kontrolle: Berichten Sie die Länge mit. Oder normalisieren Sie. Oder sagen Sie dem Judge ausdrücklich, dass Länge kein Qualitätssignal ist. Und prüfen Sie, ob die Anweisung tatsächlich gewirkt hat.

Self-Preference

Befund: gpt-4 sprach sich selbst auf eigenen Ausgaben eine um 10 % höhere Gewinnrate zu, claude-v1 25 %. Die Autoren schränken selbst ein: Die Datenlage reicht nicht aus, um echte Selbstbevorzugung zweifelsfrei nachzuweisen.

Quelle: Zheng et al., MT-Bench, Abbildung 2(b)

Befund: Eine spätere, unabhängige Arbeit liefert einen Mechanismus dazu. Die Stärke der Selbstbevorzugung steigt linear mit der Fähigkeit eines Modells, eigene Ausgaben wiederzuerkennen. Verstärkt man diese Fähigkeit durch Feintuning, wächst die Verzerrung mit.

Quelle: Panickssery, Bowman & Feng, LLM Evaluators Recognize and Favor Their Own Generations

Die praktische Regel aus dem vorigen Kapitel gilt: Ein Modell darf nie Judge in einem Vergleich sein, an dem es selbst teilnimmt.

Die Fehlermodi, die mehr wiegen

Die drei klassischen Verzerrungen sind bekannt und meist abmilderbar. Die folgenden sind schlimmer, weil sie leiser sind.

Recall-Einbruch bei den Fehlern

Befund: gpt-3.5-turbo sollte die faktische Konsistenz von Zusammenfassungen bewerten. Es erkannte über 95 % der konsistenten Zusammenfassungen, aber nur 30–60 % der inkonsistenten.

Quelle: Eugene Yan, Evaluating LLM-Evaluators

In der Sprache des vorigen Kapitels: Das ist eine Richtig-negativ-Rate (TNR) über 95 % bei einer Trefferquote (TPR) zwischen 30 und 60 %. Konkret: 100 Zusammenfassungen widersprechen tatsächlich ihrer Quelle. Der Judge markiert davon zwischen 30 und 60. Den Rest lässt er durch.

Lesen Sie das noch einmal mit Blick auf Ihren Anwendungsfall. Der Judge bestätigt hervorragend, dass gute Ausgabe gut ist. Beim Abfangen der schlechten Ausgabe liegt er nahe am Münzwurf. Dabei haben Sie ihn genau dafür eingesetzt. Fehler abzufangen ist der ganze Zweck. Deshalb ist eine Gesamtgenauigkeit auf einem unausgewogenen Set aktiv irreführend. Genau darum besteht das vorige Kapitel auf der TPR statt auf der Übereinstimmung.

Blindheit gegenüber absichtlicher Verfälschung

Befund: gpt-4-turbo bekam absichtlich verfälschte Antworten vorgelegt. In über 50 % der Fälle gab es ihnen keine niedrigeren Werte, und zwar bei Kohärenz, Faktentreue und Anweisungsbefolgung. Beim Unterscheiden faktischer von halluzinierten Zusammenfassungen erreichte das beste getestete Modell 58,5 % Genauigkeit. Das ist kaum über dem Zufall.

Quelle: Eugene Yan, Evaluating LLM-Evaluators

Das ist das stärkste verfügbare Argument gegen einen LLM-Judge als Haupt-Detektor für Halluzinationen. Ein Judge, der eine absichtlich verfälschte Antwort nicht zuverlässig bemerkt, bemerkt auch keine versehentlich verfälschte.

Übereinstimmung mit Laien

Befund: LLM-Judges stimmen nach Beobachtungen besser mit fachfremden menschlichen Annotatoren überein als mit fachkundigen.

Quelle: Eugene Yan, Evaluating LLM-Evaluators

Das hat eine unangenehme Folge für die gesamte Literatur. Veröffentlichte Korrelationswerte beruhen oft auf Labels von Crowdworkern. Sie könnten systematisch zu optimistisch sein im Vergleich zu dem, was Sie gegen einen Fachexperten messen würden. Zugleich ist das ein direktes Argument für die Methode des leitenden Fachexperten. Labels von Fachexperten sind das schwerere Ziel. Und sie sind das Ziel, auf das es ankommt.

G-Eval und was die meisten Implementierungen tatsächlich sind

Was G-Eval ist. Ein Rezept zum Bau eines Judges, veröffentlicht 2023. Sie finden den Namen auf der Kennzahlen-Liste fast jeder Eval-Plattform. Bekannt wurde das Rezept durch eine Zahl: Seine Urteile korrelierten mit menschlichen Bewertungen zu 0,514. Auf dieser Skala heißt 0 „kein Zusammenhang“ und 1 „perfekte Übereinstimmung“. Für Zusammenfassungen und Dialoge, die Aufgaben der Arbeit, ist das ordentlich.

Das Rezept. Es hat zwei Teile. Der erste ist gewöhnlich: Der Judge bekommt ein Bewertungsformular und muss begründen, bevor er bewertet. Das ist dieselbe Regel wie im Kapitel Judge bauen. Der zweite Teil ist die eigentliche Idee. Wenn ein Modell eine Note von 1 bis 5 wählt, hat es intern zu jeder der fünf Noten eine Zuversicht und meldet die stärkste. Diese Zuversichten heißen Logprobs. G-Eval fragt sie ab und bildet aus allen fünf einen gewichteten Mittelwert, statt nur den Gewinner zu nehmen:

Die interne Zuversicht des Modells zu jeder Note:
  1 → 1 %    2 → 4 %    3 → 15 %    4 → 60 %    5 → 20 %

Einfacher Judge → meldet den Gewinner                        → 4
G-Eval          → (1×0,01)+(2×0,04)+(3×0,15)+(4×0,60)+(5×0,20)  → 3,94

Ein Judge, der zwischen 3 und 4 schwankt, liefert so 3,4. Ein Judge, der sich bei 4 sicher ist, liefert 3,95. Diese feinen Werte korrelieren besser mit menschlichen Urteilen als ganze Zahlen. Das ist der Grund für die 0,514.

Der Haken. Die Logprobs bekommen Sie nur von einer API, die sie herausgibt. Die meisten Chat-APIs tun das nicht. Deshalb ist das, was Eval-Plattformen als „G-Eval“ ausliefern, meist nur der erste Teil des Rezepts:

Befund: G-Evals veröffentlichter Beitrag ist ein Formular-Prompt mit Chain-of-Thought plus wahrscheinlichkeitsgewichteter Summation über die Token-Logits der 1–5-Optionen. Produktive Systeme laufen überwiegend über Chat-APIs. Diese legen keine Logit-Verteilungen offen. Das ausgelieferte Muster schrumpfte deshalb auf einen diskreten Ganzzahlwert mit vorangestellter Begründung. Manchmal wird er umskaliert, damit er kontinuierlich aussieht. Anbieter vermarkten das dann als „G-Eval-Implementierung“ und zitieren die Korrelation von 0,514 aus der Arbeit.

Quelle: Liu et al., G-Eval, 2023

Was das für Sie heißt. Drei Dinge.

1. Heißt eine Kennzahl in Ihrem Tool „G-Eval“, prüfen Sie, ob sie Logprobs abfragt. Im Code ist das eine Suche nach logprobs. Bei einem Anbieter ist es eine Frage an den Support.
2. Fragt sie keine Logprobs ab, haben Sie einen gewöhnlichen Judge mit Begründung. Das ist nicht schlimm. Aber die 0,514 gelten für ihn nicht, denn die Zahl kam aus dem Teil, der fehlt. Wie gut dieser Judge ist, wissen Sie erst, wenn Sie ihn selbst messen: Trefferquote und Richtig-negativ-Rate auf einem versiegelten Stapel, wie in Kapitel 5.
3. Fragt sie doch Logprobs ab, gilt die 0,514 trotzdem nur für Zusammenfassungen und Dialoge, die Aufgaben der Arbeit. Für Ihre Aufgabe müssen Sie so oder so messen.

Kurz: Der Name G-Eval ersetzt keine Messung. Ein gewöhnlicher Judge, den Sie selbst gemessen haben, ist mehr wert als ein „G-Eval“, dessen einzige Zahl aus einer fremden Arbeit stammt.

Wo man gar keinen Judge einsetzen sollte

Manche Eigenschaften sollten Sie keinem LLM-Judge überlassen. Egal, wie gut der Prompt ist:

• Faktische Korrektheit bei Nischenwissen. Der Judge hat dieselben Wissenslücken wie das Basismodell. Er bestätigt dieselben falschen Fakten mit voller Überzeugung. Nutzen Sie Retrieval gegen eine verlässliche Quelle, oder Menschen.
• Korrektheit von Tool-Aufrufen. Code-basiertes AST-Matching ist exakt, kostenlos und sofort da. Ein Judge ist hier in jeder Hinsicht schlechter.
• Alles mit deterministischer Antwort. Schemagültigkeit, Arithmetik, IDs, Datumsangaben, Enum-Zugehörigkeit.
• Sicherheitsentscheidungen mit echten Folgen. Ein dünner Filter auf Judge-Basis ist ein vernünftiges Signal. Eine Kontrolle ist er nicht. Siehe Sicherheit.
• Alleinige Instanz für ein Release-Gate. Kombinieren Sie den Judge mit deterministischen Prüfungen und einer menschlichen Stichprobe.

Jurys

Mehrere Judges einzusetzen und ihre Urteile zusammenzuführen ist eine echte Verbesserung. Ein Panel aus kleineren, verschiedenen Modellen korreliert laut Berichten besser mit Menschen als ein einzelner starker Judge. Das gilt für referenzbasierte Aufgaben. Und es kostet weniger als die naheliegende Alternative.

Es ist keine Heilung. Ein Ensemble senkt die Varianz innerhalb der Judge-Gruppe. Verzerrungen, die alle Judges gemeinsam haben, beseitigt es nicht. Haben alle Mitglieder denselben Längen-Bias, dann hat ihn auch die Jury. Bei Modellen einer Generation ist das eher die Regel als die Ausnahme. Die Stärke schwankt zwar je Modell, wie oben gesehen. Der Bias selbst bleibt. Nutzen Sie eine Jury für Stabilität, nicht für Absolution. Und validieren Sie die Jury gegen menschliche Labels, genau wie einen einzelnen Judge.

Häufiger Fehler: Einen Judge-Wert auf zwei Nachkommastellen berichten. Der Judge hat eine gemessene Fehlerrate gegenüber Menschen. Das Eval-Set ist eine Stichprobe. Die meisten dieser Stellen sind also Dekoration. Berichten Sie den Wert mit einem Konfidenzintervall. Stellen Sie die TPR/TNR des Judges daneben. Oder berichten Sie eine Spanne. Siehe Statistik.