LLM-as-judge: KI bewertet KI

Zweite Folge der Reihe über das Testen von KI-Systemen. In der ersten haben wir den Massstab gebaut: Golden Dataset und Testset. Hier geht es darum, wer ihn in der Hand hält, wenn das Volumen wächst — also ein Modell, das ein anderes bewertet. Der Mensch, der im Kreis bleibt, ist Thema des dritten Artikels.

Das Ausgangsproblem

Man hat einen Assistenten in Produktion, der Fragen zur internen Dokumentation beantwortet. Er funktioniert. Dann ändert man den System-Prompt, um einen von einer nutzenden Person gemeldeten Grenzfall zu erledigen, und hält kurz inne, bevor man ausliefert.

Woher weiss man, dass man die anderen zweihundert Antworten nicht verschlechtert hat?

Die klassischen Optionen taugen nicht:

• Exakter Vergleich: es gibt keine einzige Antwort. «Der Endpunkt verlangt einen Bearer-Token» und «Du musst einen Bearer-Token im Authorization-Header mitgeben» sind beide korrekt und teilen auf Zeichenebene fast nichts.
• BLEU, ROUGE und Verwandte: sie zählen n-Gramm-Überlappungen. Sie sagen, wie ähnlich sich zwei Texte sind, nicht ob der zweite richtig ist. Eine perfekte Antwort mit anderen Wörtern als die Referenz bekommt einen miserablen Wert. Eine falsche Antwort, die den Wortschatz des Kontexts wiederverwendet, bekommt einen hohen.
• Menschliche Review: funktioniert bestens und ist genau das, was man nicht bei jedem Commit über zweihundert Fälle machen kann.

Daraus entsteht die Idee: verlangt das Urteil Sprachverständnis, nehmen wir etwas, das Sprache versteht.

Was es genau ist

LLM-as-judge heisst, ein Sprachmodell als Bewerter des Outputs eines anderen Systems (oder seiner selbst) einzusetzen. Der Judge bekommt:

• den ursprünglichen Input (die Frage der nutzenden Person)
• den zu bewertenden Output (die Antwort des Systems)
• gegebenenfalls eine Referenz (die «Gold»-Antwort oder den vom RAG geholten Kontext)
• ein ausdrückliches Beurteilungskriterium

und liefert ein Urteil: einen Wert, ein Bestanden/Nicht bestanden oder eine Präferenz zwischen zwei Alternativen.

So gesagt klingt es banal. Der Unterschied zwischen einem Judge, der funktioniert, und einem, der als Kennzahl verkleidetes Rauschen erzeugt, liegt vollständig in den Details des Aufbaus.

Die wichtigsten Varianten

Pointwise Scoring

«Bewerte die Vollständigkeit dieser Antwort von 1 bis 5.»

Die anschaulichste Form und die anfälligste. Modelle sind miserabel darin, numerische Skalen zu kalibrieren: fragt man nach einer Note von 1 bis 10, bekommt man eine auf 7 und 8 zusammengedrückte Verteilung. Die vermeintliche Feinheit ist eine Illusion: geht das System nach einer Änderung von 7,8 auf 7,9, hat man nichts gelernt.

Es taugt nur einigermassen, wenn man jede Stufe der Skala an eine konkrete Verhaltensbeschreibung bindet («5 = beantwortet die Frage und zitiert mindestens eine Quelle aus dem Kontext; 3 = beantwortet teilweise; 1 = beantwortet nicht oder widerspricht dem Kontext»). Ohne solche Anker fragt man nach einer Meinung.

Pairwise Comparison

«Welche ist zwischen Antwort A und Antwort B nach diesem Kriterium die bessere?»

Deutlich verlässlicher. Das Modell muss keinen Output auf einer abstrakten Skala verorten, sondern nur eine relative Präferenz äussern — eine Aufgabe, in der es merklich besser ist. Es ist die Form der Wahl, um zwei Versionen Ihres Systems, zwei Prompts, zwei Modelle zu vergleichen.

Sie hat einen erheblichen Mangel (Position Bias, dazu gleich mehr), der zwingend abgemildert werden muss.

Rubrik / binäre Kriterien

Statt zu fragen «wie gut ist diese Antwort», zerlegt man den Qualitätsbegriff in atomare Ja/Nein-Fragen:

• Enthält die Antwort Aussagen, die der bereitgestellte Kontext nicht deckt?
• Geht die Antwort tatsächlich auf die gestellte Frage ein?
• Zitiert die Antwort mindestens eine Quelle?
• Enthält die Antwort Ratschläge rechtlicher Natur?

Statistisch ist das der robusteste Ansatz. Jede Prüfung ist einfach, nachvollziehbar, und wenn sie fehlschlägt, weiss man genau, was schiefging. Aggregiert wird dann nach Belieben: Anteil bestandener Prüfungen oder Kaskadenlogik (schlägt Prüfung 1 fehl, ist der Fall durchgefallen und der Rest muss nicht bewertet werden).

Der Preis ist die Entwurfsarbeit im Vorfeld: Sie müssen wirklich entscheiden, was «gut» in Ihrer Domäne heisst. Diese Arbeit lohnt sich ohnehin.

Reference-based vs. reference-free

Mit Referenz: man vergleicht den Output mit einer Gold-Antwort. Das verlangt einen annotierten Datensatz — das Thema des ersten Artikels dieser Reihe —, aber das Urteil ist weit stabiler.

Ohne Referenz: man bewertet den Output für sich oder gegen den geholten Kontext. Es ist die einzig praktikable Option in der Produktion, wo die Fragen neu sind und keine Gold-Antwort vorliegt.

Im RAG ist der nützlichste Fall hybrid: die «Referenz» ist der geholte Kontext, und das Kriterium ist Groundedness — jede Aussage der Antwort muss von diesem Kontext gedeckt sein. Dieser Judge-Typ ist verlässlich, weil die Aufgabe fast mechanisch ist: eine Enthaltung prüfen, nicht Schönheit beurteilen.

G-Eval und Varianten

Ein Ansatz, der sich durchgesetzt hat: man lässt den Judge vor dem Urteil eine ausdrückliche Gedankenkette erzeugen und gewichtet — wo man Zugriff auf Logprobs hat — den Wert mit den Token-Wahrscheinlichkeiten, was einen kontinuierlichen Wert statt einer diskreten Stufe ergibt. Das mildert das Problem der groben Kalibrierung.

Der auch ohne Logprobs übertragbare Punkt: die Begründung gehört vor das Urteil, nie danach. Fragt man zuerst nach der Note und dann nach der Begründung, bekommt man eine nachträgliche Rationalisierung.

Jury / Panel

Mehrere verschiedene Judges stimmen ab, aggregiert wird per Mehrheit, Mittelwert oder Eskalation an einen Menschen bei Uneinigkeit. Das senkt Streuung und Verzerrung des einzelnen Modells. Es kostet mehr — man hebt es sich für Rubriken mit hoher Tragweite auf.

Agent-as-judge

Die jüngere Entwicklung für agentische Systeme: nicht nur die finale Antwort bewerten, sondern die gesamte Trajektorie — welche Tools aufgerufen wurden, in welcher Reihenfolge, mit welchen Parametern, wie man sich von Fehlern erholt hat. Für Chatbots gedachte Rubriken («Nützlichkeit», «Flüssigkeit») passen nicht zu einem Agenten, der APIs verketten muss, und die Forschung von 2026 drängt zu Rubriken, die für die konkrete Aufgabe erzeugt werden, statt für das ganze System festzustehen.

Wann man ihn einsetzt (und wann nicht)

Die praktische Regel lautet: keinen Judge dort einsetzen, wo eine deterministische Prüfung existiert.

Das reife Muster ist ein Hybrid aus drei Ebenen: deterministische Prüfungen für alles mechanisch Messbare, ein Judge für das, was Verständnis verlangt, ein Mensch für den kleinen Prozentsatz, den eines der beiden als zweifelhaft markiert hat.

Die konkreten Anwendungsfälle

• Regressionstests in der CI. Der solideste Fall. Man hat zweihundert Testfälle, ändert etwas, der Judge sagt, ob man schlechter geworden ist. Man braucht keine wahre absolute Zahl, man braucht einen wiederholbaren Vergleich.
• Vergleich von Modellen oder Prompts. Man muss zwischen zwei Anbietern wählen oder klären, ob das günstigere Modell reicht. Pairwise über ein festes Set.
• Filterung synthetischer Daten. Man erzeugt hunderttausend Beispiele und behält den Anteil, den der Judge für gültig hält.
• RLAIF / Rubrics-as-Rewards. Der Judge liefert das Präferenzsignal für das Alignment anstelle menschlicher Annotierender. Hier misst der Judge nicht, er trainiert — und seine Mängel werden zu Mängeln des Endmodells.
• Monitoring im Betrieb. Man zieht einen Anteil des echten Traffics und bewertet ihn asynchron auf Treue, Ton, Richtlinienverstösse. Man sieht Probleme vorbeiziehen, bevor eine Kundin sie meldet.
• Online-Guardrails. Der Judge blockiert oder erzwingt eine Neugenerierung, bevor die nutzende Person die Antwort sieht. Hier zählen Latenz und Kosten stark, und es braucht einen kleinen, schnellen Judge.

Geschichten aus der Praxis

Der Judge, der belohnte, wer mehr redete

Bei einem internen Assistenten für technische Dokumentation hatten wir einen Pointwise-Judge mit einem allgemeinen Kriterium «Antwortqualität», Skala 1-5. Beim Iterieren am System-Prompt stieg der Durchschnittswert stetig: 3,4 → 3,7 → 3,9. Alles schien in Ordnung.

Dann hat jemand die Antworten gelesen.

Sie waren riesig geworden. Das Modell hatte gelernt — durch uns, die wir auf den Wert hin optimierten —, Vorbemerkungen, Zusammenfassungen, Kontextnotizen und Hinweise anzuhängen. Der Judge belohnte Weitschweifigkeit, weil eine lange Antwort vollständiger aussieht. Die echten Nutzenden, die eine Zeile und einen Link wollten, waren unzufriedener als vorher.

Die Lehre: der Wert stieg, weil wir die Kennzahl optimierten, nicht das Produkt. Wir haben das eine Kriterium durch vier binäre Prüfungen ersetzt, eine davon ausdrücklich «enthält die Antwort Informationen, nach denen nicht gefragt wurde?». Der Durchschnittswert brach ein und wurde wieder aussagekräftig.

Der Tag, an dem wir den Judge gemessen haben

Monatelang haben wir die Zahlen des Judge in Präsentationen verwendet, ohne je zu fragen, ob sie stimmen. Dann haben wir das Naheliegende getan: zweihundert von zwei Personen von Hand gelabelte Fälle, verglichen mit dem Urteil des Judge.

Beim Kriterium Groundedness war die Übereinstimmung ausgezeichnet — es ist eine fast mechanische Aufgabe. Beim Kriterium «die Antwort ist für die nutzende Person nützlich» lag die Übereinstimmung knapp über dem Zufall. Der Judge mass etwas, aber nicht das, was wir dachten, und nichts, worauf sich Entscheidungen sinnvoll stützen liessen.

Das wertvollste Nebenprodukt war die Entdeckung, dass wir beiden Menschen uns untereinander bei einem Fünftel der Fälle nicht einig waren. Bevor man ein Modell bittet, ein Kriterium anzuwenden, muss das Kriterium existieren. Die halbe Wirkung der Übung lag darin, die operative Definition von «nützlich» aufzuschreiben.

Die Kosten, die niemand eingeplant hatte

Ein Judge mit Chain-of-Thought, auf einem Modell der oberen Klasse, auf jeder Produktionsantwort. Auf dem Papier kostet «KI, die KI bewertet» nichts. In der Praxis erzeugte der Judge mehr Output-Token als das bewertete System, weil er vor dem Antworten überlegte, und der Kostenposten war dem des Produkts vergleichbar geworden.

Die Lösung ist banal, sobald man darüber nachdenkt: Stichproben (ein Bruchteil des Live-Traffics), der grosse Judge nur in den Kalibrierungsläufen, ein kleiner spezialisierter Judge im Betrieb und — vor allem — die Kosten des Judge als eigener Posten geführt statt in der Gesamtsumme versteckt.

Die Verzerrungen: der Teil, der wehtut

Dieser Abschnitt ist der wichtigste. Ein Judge ist kein neutrales Messgerät: er ist ein Sprachmodell mit all seinen systematischen Neigungen.

Position Bias. Im Pairwise neigt das Modell dazu, die erste (oder die zweite) Antwort unabhängig vom Inhalt zu bevorzugen. Das ist kein zufälliges Rauschen, es ist systematisch und variiert von Modell zu Modell. Zwingende Gegenmassnahme: immer beide Reihenfolgen bewerten. Kippt das Urteil beim Tausch von A und B, ist der Vergleich nichtig und als Unentschieden zu behandeln oder zu eskalieren.

Verbosity Bias. Längere Antworten gewinnen, auch bei gleichem Inhalt. In Benchmarks, die diesen Effekt ausdrücklich prüfen, fällt die Längenempfindlichkeit oft stärker aus als die Positionsempfindlichkeit. Manche Modelle sind widerstandsfähiger und bestrafen Füllmaterial, aber keines ist immun. Gegenmassnahme: Kriterien, die Knappheit ausdrücklich nennen, und Kontrolle der Längenverteilung zwischen den verglichenen Gruppen.

Self-Preference / Self-Enhancement Bias. Ein Modell bewertet die eigenen Ausgaben tendenziell besser. Die überzeugendste Erklärung in der Literatur ist nicht Narzissmus, sondern Perplexität: Modelle belohnen Texte, die ihnen vertrauter, also nach ihrer Verteilung wahrscheinlicher sind. Das heisst, die Verzerrung trifft auch Texte, die sie nicht erzeugt haben, die aber stilistisch ähnlich sind. Gegenmassnahme: ein Judge aus einer anderen Familie als der Generator. Immer.

Preference Leakage. Die heimtückischere Variante: hat man die synthetischen Daten mit Modell X erzeugt und nimmt als Judge ein mit X verwandtes Modell, ist der Judge kontaminiert. Das gilt auch zwischen «Lehrer»-Modell und destilliertem Modell.

Sycophancy. Der Judge glaubt, was man ihm schreibt. Behauptet der zu bewertende Text selbstsicher, eine Quelle zitiert zu haben, nimmt der Judge das meist ungeprüft hin. Erfundene Zitate kommen durch.

Overconfidence. Die Konfidenzwerte, die ein Judge angibt, sind nach oben schlecht kalibriert. Nicht als Wahrscheinlichkeiten behandeln.

Prompt-Empfindlichkeit und Drift. Formuliert man ein Kriterium um, ändern sich die Ergebnisse. Wechselt die Version des Judge-Modells, ändern sich die Ergebnisse. Operative Folge: der Judge-Prompt gehört wie Code versioniert, und jeder Wechsel des Judge-Modells entwertet die Metrikhistorie, bis neu kalibriert wurde.

Nichtdeterminismus. Gleicher Input, unterschiedliche Urteile. Temperatur auf null hilft, beseitigt das Problem aber nicht.

Goodhart, oder: das Grundproblem

Sobald eine Kennzahl zum Ziel wird, ist sie keine gute Kennzahl mehr.

Das gilt für jede Kennzahl, bei Judges aber besonders bösartig, aus zwei Gründen.

Erstens: die Optimierungsschleife ist blitzschnell. Prompt ändern, Wert ansehen, wieder ändern. In wenigen Stunden hat man Dutzende Selektionsdurchgänge gegen die Schwächen des Judge gefahren, ohne es zu merken. Man verbessert nicht das System, man betreibt gerichtete Evolution auf die blinden Flecken des Bewerters zu.

Zweitens: liefert der Judge das Reward-Signal für ein Training (RLAIF, Rubrics-as-Rewards), optimiert das Modell direkt gegen ihn, mit weit mehr Kraft und Geduld, als man selbst hat. Jede ausnutzbare Abkürzung wird ausgenutzt.

Das einzige echte Gegenmittel ist ein unabhängiger Wahrheitskanal: eine Stichprobe menschlicher Review, die nie in die Optimierungsschleife gerät, und ein regelmässiger Blick auf echte Antworten. Steigt der Wert und die Nutzenden merken nichts davon, lügt der Wert.

Wie man einen Judge baut, dem man traut

Eine operative Checkliste, nach Wichtigkeit geordnet.

1. Bewerten Sie den Bewerter. Der Schritt, den fast alle überspringen. Es braucht 100-200 von Hand gelabelte Fälle, möglichst von zwei Personen, und ein Mass für die Übereinstimmung zwischen Judge und Menschen (Genauigkeit, Cohens Kappa). Die in der Praxis genutzten Schwellen: unter 0,6 Kappa ist der Judge für Entscheidungen unbrauchbar; über 0,8 ist er solide. Ohne diese Zahl haben Sie keine Kennzahl, sondern einen Erzeuger beruhigender Ziffern.

2. Messen Sie auch die Übereinstimmung unter Ihren eigenen Leuten. Sind sich zwei interne Prüfende nicht einig, ist das Kriterium mehrdeutig und kein Modell wird es stabil anwenden. Der Judge kann nicht konsistenter sein als die Definition, die Sie ihm gegeben haben.

3. Ziehen Sie Binär und Pairwise den numerischen Skalen vor. Ein sauber definiertes Bestanden/Nicht bestanden ist mehr wert als ein vages 1-10.

4. Zerlegen Sie «Qualität» in atomare, unabhängige Kriterien, jedes mit eigener Definition, positiven Beispielen und — vor allem — Grenzbeispielen. Die Randfälle sind mehr wert als die offensichtlichen.

5. Begründung vor dem Urteil, strukturierter Output als JSON mit festem Schema. Das dient nicht nur der Urteilsqualität: es dient Ihnen selbst beim Debuggen, wenn etwas nicht aufgeht.

6. Ein Judge aus einer anderen Familie als der Generator.

7. Wechselnde Reihenfolge im Pairwise. Nicht verhandelbar.

8. Versionieren Sie den Judge-Prompt, das Modell, die Parameter. Eine Änderung an einem der drei entwertet historische Vergleiche.

9. Kalibrieren Sie regelmässig neu. Modelle werden unter Ihnen aktualisiert, Ihre Daten ändern sich, Kriterien nutzen sich ab. Eine Kalibrierungsrunde monatlich oder bei jeder relevanten Änderung.

10. Nehmen Sie Stichproben, statt alles zu bewerten. In der CI können Sie sich volle Abdeckung des Testsets leisten; im Betrieb reicht eine Stichprobe bei Weitem.

11. Lassen Sie den Judge asynchron laufen, sofern er kein blockierendes Guardrail ist. Die nutzende Person soll nicht die Latenz Ihrer Kennzahl bezahlen.

12. Führen Sie die Kosten des Judge als eigenen Posten.

Ein minimales Gerüst, nur um die Form festzuhalten:

Bereitgestellter Kontext: {context}
Frage: {question}
Zu bewertende Antwort: {answer}

Begründe zu jedem Kriterium in einem Satz und gib dann das Urteil ab.
1. Ist jede Tatsachenbehauptung der Antwort durch den Kontext gedeckt?
2. Führt die Antwort Informationen ein, die im Kontext fehlen?
3. Geht die Antwort auf die gestellte Frage ein?

Antworte ausschliesslich mit:
{"reasoning": "...", "supported": bool, "hallucinated": bool, "relevant": bool}

Man beachte, was nicht darin steht: keine Aufforderung zu einer Gesamtnote, keine Skala, kein vages Adjektiv wie «gut» oder «hochwertig».

Wohin das führt

Drei Richtungen, die man im Auge behalten sollte.

Rubriken als Reward. Der Übergang von «der Judge misst» zu «der Judge trainiert». Rubriken werden zur Brücke zwischen der Sprache der Unternehmensrichtlinien und einem Signal, das eine Maschine optimieren kann. Die Kehrseite ist, dass jede Mehrdeutigkeit der Rubrik zu einem strukturellen Mangel des entstehenden Modells wird.

Hybride Norm mit verifizierbaren Rewards. Wo Korrektheit mechanisch prüfbar ist (Mathematik, Code, Tool-Nutzung), verwendet man deterministische Verifikation; Rubriken bleiben für den offenen Teil. Die Kombination schlägt beide Ansätze für sich genommen.

Adaptive Rubriken. Statt dieselben drei Dimensionen auf jede Aufgabe anzuwenden, die Kriterien für die konkrete Aufgabe erzeugen. Für einen Agenten, der APIs verkettet, sind die sinnvollen Dimensionen die Wahl des Aufrufs, die Richtigkeit der Parameter und die Fehlererholung — keine davon taucht in einer generischen Rubrik zur «Nützlichkeit» auf.

Ein Kollege mit dokumentierten Marotten

LLM-as-judge ist das richtige Werkzeug, um relative Unterschiede zwischen Versionen Ihres Systems zu messen, in grossem Umfang, zu überschaubaren Kosten, an Kriterien, die keine syntaktische Kennzahl erfassen kann.

Es ist das falsche Werkzeug, wenn Sie es als objektives Mass absoluter Qualität behandeln, wenn Sie es nie mit echten menschlichen Urteilen verglichen haben, oder wenn Sie es anstelle einer deterministischen Prüfung einsetzen, die Sie in zehn Zeilen hätten schreiben können.

Der Judge ist nicht die Wahrheit. Er ist ein geduldiger, unermüdlicher, sehr schneller Kollege mit einigen gut dokumentierten Marotten — und er gehört genauso im Blick behalten, wie man einen Kollegen mit diesen Eigenschaften im Blick behalten würde.

Ein Judge muss trotzdem an etwas gemessen werden: das Golden Dataset aus dem ersten Artikel ist dieses Etwas, und ohne es gibt es nichts, woran man ihn kalibrieren könnte. Im dritten bleibt der Mensch, den der Judge nicht ersetzt.

Quellen

Paper

• Zheng et al. (2023), Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena — arXiv:2306.05685. Die grundlegende Arbeit: sie benennt Position-, Verbosity- und Self-Enhancement-Bias und misst die Übereinstimmung zwischen Judges und Menschen.
• Liu et al. (2023), G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment — arXiv:2303.16634. Chain-of-Thought plus Gewichtung des Werts mit Token-Wahrscheinlichkeiten.
• Shi et al. (2024), Judging the Judges: A Systematic Investigation of Position Bias — arXiv:2406.07791. Zeigt, dass Position Bias systematisch ist und kein zufälliges Rauschen.
• Wataoka & Takahashi (2024), Self-Preference Bias in LLM-as-a-Judge — arXiv:2410.21819. Der Zusammenhang zwischen Self-Preference und Perplexität.
• Li et al. (2025), Preference Leakage: A Contamination Problem in LLM-as-a-judge — arXiv:2502.01534. Kontamination zwischen dem Erzeuger synthetischer Daten und dem Bewerter.
• Kim et al. (2024), Prometheus 2: An Open Source Language Model Specialized in Evaluating Other Language Models — arXiv:2405.01535 · Repository. Offene Evaluatoren, trainiert auf nutzerdefinierten Rubriken.
• Tan et al. (2024), JudgeBench: A Benchmark for Evaluating LLM-based Judges — arXiv:2410.12784. Ein Benchmark zur Bewertung der Judges selbst.
• Lambert et al. (2024), RewardBench: Evaluating Reward Models for Language Modeling — arXiv:2403.13787.
• Park et al. (2024), OffsetBias: Leveraging Debiased Data for Tuning Evaluators — arXiv:2407.06551. Minderung der Verzerrungen auf Ebene der Trainingsdaten des Judge.
• Koo et al. (2023), Benchmarking Cognitive Biases in Large Language Models as Evaluators — arXiv:2309.17012.

Artikel und Praxisleitfäden

• LLM-as-a-Judge in 2026: How It Works, When It Fails, and How to Calibrate — Tabellen zu Kalibrierung, Kappa-Schwellen, Kosten und Deployment-Mustern.
• LLM-as-Judge Best Practices: Calibration, Bias, and Cost — operative Checkliste.
• LLM-as-judge: A complete guide to evaluation best practices — Überblick über die Methoden und die Validierung gegen menschliche Baselines.
• What Is LLM-as-a-Judge? Definition and Best Practices — Einführung mit Fokus auf strukturierten Output und Rubriken.
• LLM-as-a-Judge: Top evaluation techniques and best practices — Vergleich zwischen G-Eval, Entscheidungsgraph-Metriken und Pairwise-Judges.
• Rubric-Based Evaluations & LLM-as-a-Judge — Rubriken als Brücke zwischen Richtlinien und verifizierbaren Rewards.