Einen ausgerichteten LLM-Judge bauen

Ein LLM-Judge ist ein Modell, das die Ausgabe eines anderen Modells bewertet. Es bekommt dafür einen Prompt. Manche Eigenschaften lassen sich nur prüfen, indem jemand Prosa liest. Für solche Eigenschaften ist ein Judge der einzige praktikable Weg, die Bewertung zu automatisieren. Zugleich ist er die Komponente, die Teams am häufigsten in Betrieb nehmen, ohne zu prüfen, ob sie funktioniert.

Ein nützlicher Judge unterscheidet sich von einem dekorativen in einem einzigen Schritt: Sie messen den Judge an menschlichen Labels, auf Daten, die er nie gesehen hat. Alles andere in diesem Kapitel dient dazu, dass dieser Schritt eine gute Zahl liefert.

Die siebenstufige Schleife

Das ist Hamel Husains Methode. Sie ist der konkreteste veröffentlichte Prozess für einen Judge, nach dem ein Unternehmen tatsächlich handelt.

1. Einen leitenden Fachexperten bestimmen

Eine Person entscheidet, was für Ihr Produkt richtig ist. Ein Arzt für ein Gesundheits-Tool. Ein Jurist für Vertragsanalyse. Eine Supportleitung für einen Service-Bot. Kein Gremium.

Diese Person soll keine Rubric abnicken, die jemand anderes geschrieben hat. Sie liest Ausgaben und entscheidet. Dabei bringt sie Akzeptanzkriterien ans Licht, die niemand aufgeschrieben hatte. Fachexperten entdecken in diesem Prozess regelmäßig, dass sie selbst nicht konsistent urteilen. Eine berichtete: Das ausformulierte Denken des Modells zu sehen „hat mir klargemacht, dass ich nicht konsistent war“. Diese Entdeckung ist der Nutzen. Sie ist kein Mangel der Methode.

2. Die Antworten sammeln, die gelabelt werden

Der Fachexperte labelt keine Eingaben. Er labelt Antworten. Eine Antwort besteht aus drei Teilen: der Anfrage des Nutzers, dem, was das System dazu abgerufen oder getan hat, und dem, was es geantwortet hat. Das sind dieselben drei Teile wie bei einem Trace. Dieser Schritt hat deshalb zwei Hälften. Erst wählen Sie die Anfragen aus. Dann lassen Sie das aktuelle System darüber laufen. Das aktuelle System ist Ihr Produkt, wie es heute läuft: der heutige Prompt, das heutige Modell.

Das ist nicht Tag 1 noch einmal. An Tag 1 lesen Sie 100 beliebige Traces mit einer offenen Frage: Was ist das Erste, was falsch ist? Daraus entsteht die Liste der Fehlermodi. Hier lesen Sie Traces mit einer einzigen festen Frage aus Schritt 1, etwa „Ist die Zahl belegt?“, und nur solche, auf die diese Frage passt. Daraus entsteht der Judge. Die Traces von Tag 1 nehmen Sie nicht wieder: Sie wurden für eine andere Frage gelesen, ein Teil davon ist inzwischen Eval-Fall, und das System antwortet seit den Bugfixes von Tag 2 anders.

Die Anfragen. Nehmen Sie 100 bis 150 Anfragen aus dem echten Betrieb, geschrieben von echten Nutzern. Nehmen Sie sie nicht aus Ihrem Eval-Set; Ihr erstes Eval in einer Woche erklärt, warum. Behalten Sie nur Anfragen, bei denen die Frage aus Schritt 1 etwas zu prüfen hat. Bei „Ist die Zahl belegt?“ sind das Antworten mit einer Zahl.

Die Abdeckung. Damit die 100 bis 150 nicht alle vom selben Typ sind, sortieren Sie jede Anfrage nach drei Merkmalen ein:

Jede Kombination ist ein Kästchen in einem Raster. Eines davon, ausgeschrieben:

Funktion: Sendungsverfolgung
Szenario: Bestellung nicht gefunden
Persona:  Neukunde
-> „Wo ist meine Bestellung? Hab gestern bestellt, nutze das hier zum ersten Mal.“

Das Raster schreibt das Team. Die Anfragen darin schreiben die Nutzer. Sortieren Sie die echten Anfragen in die Kästchen ein, und die meisten Kästchen sind danach belegt, weil echte Nutzer diese Fälle ohnehin produzieren. Nur für die Kästchen, die leer bleiben, schreiben Sie selbst zwei oder drei Anfragen. Datensatz-Design zeigt, wie. Der Nutzen des Rasters: Sie können auf ein leeres Kästchen zeigen und sagen „Das haben wir nie getestet.“ Und später auf ein volles: „Hier scheitern wir in 75 % der Fälle.“

Die Antworten. Dann lassen Sie das aktuelle System einmal über alle Anfragen laufen und speichern jede Antwort neben ihrer Anfrage. Diese gespeicherten Antworten liest der Fachexperte im nächsten Schritt.

3. Binäre Urteile mit schriftlichen Kritiken

Der Fachexperte bewertet jede Ausgabe mit bestanden oder nicht bestanden. Nie mit 1 bis 5. Dazu schreibt er eine kurze Kritik, die das Urteil begründet.

Die Kritik ist keine Dokumentation. Sie ist das Rohmaterial für den Judge-Prompt. Sie hat zwei Aufgaben:

• Spezifisch genug, dass ein neuer Kollege die Entscheidung versteht
• Ausführlich genug, um als Few-Shot-Beispiel zu dienen

Eine gute Kritik benennt das Hauptziel. Sie sagt, ob das Ziel erreicht wurde. Und sie benennt das eine Merkmal, das den Ausschlag gab. Kritiken zu bestandenen Fällen zählen genauso viel wie Kritiken zu nicht bestandenen. Ein Judge, der nur an Fehlern gelernt hat, sucht überall Fehler.

Zwei Beispiele, wie sie in der Praxis aussehen, für einen Support-Assistenten:

Nicht bestanden. Der Nutzer fragte, wo seine Bestellung ist. Der Assistent erklärte stattdessen die Rückgaberichtlinie. Das Hauptziel war, die Bestellung zu finden. Das wurde nie versucht. Das Werkzeug zur Sendungsverfolgung war verfügbar und wurde nicht aufgerufen.

Bestanden. Der Nutzer fragte, wo seine Bestellung ist. Die Sendungsverfolgung fand keinen Treffer. Der Assistent sagte das klar. Er nannte den wahrscheinlichen Grund (Bestellung vor weniger als 30 Minuten aufgegeben) und bot an, ein Update per E-Mail zu schicken. Ziel erreicht: Der Nutzer kennt den Stand und weiß, wie es weitergeht.

Achten Sie darauf, was die Kritik zum bestandenen Fall leistet. Sie sagt nicht „gute Antwort“. Sie benennt, warum dieser Fall als bestanden zählt. Genau daraus kann ein Judge lernen. „Gute Antwort“ lehrt ihn nichts.

Planen Sie 100 bis 150 Labels insgesamt ein. Teilen Sie sie in zwei Stapel, die sich nie berühren. Der Aufbaustapel hat 30 bis 40 Fälle. Sie wählen ihn von Hand so aus, dass die Hälfte bestanden hat und die Hälfte nicht. Aus ihm stammen die Beispiele für den Judge. Ergänzen Sie ihn so lange, bis der Fachexperte keine neuen Fehlermodi mehr antrifft. Der versiegelte Stapel ist alles Übrige, in der natürlichen Mischung aus bestanden und nicht bestanden, mit mindestens 20 bis 25 echten Fehlern. Er dient zum Messen in Schritt 6. Der Judge sieht ihn nie. Auch nicht, um zu prüfen, ob ein Fall knifflig ist.

4. Die offensichtlichen Bugs zuerst beheben

Beim Sichten der Ausgaben tauchen schlichte Defekte auf. Beheben Sie sie. Erzeugen Sie die Antworten neu, bevor Sie weitermachen. Einen Judge zu bauen, der einen Bug erkennt, den Sie heute Nachmittag beheben könnten, ist ein Kategorienfehler. Außerdem verunreinigt es Ihr Label-Set mit Fehlern, die nie wieder auftreten.

5. Den Judge bauen und iterieren

Der Judge bekommt je Fall alles, was der Fachexperte vor sich hatte: die Eingabe, den abgerufenen Kontext oder die Tool-Ergebnisse, die Antwort und jede Tatsache, von der das Kriterium abhängt, etwa den Tarif des Kunden. Daraus liefert er ein Urteil. Der Prompt hat vier Teile, in dieser Reihenfolge:

1  Aufgabe     Du prüfst eine einzige Sache an einer Support-Antwort: <ein Satz>.
2  Kriterium   PASS, wenn <Definition>. FAIL, wenn <Definition>.
               Randfall: <ein Fall, den der Fachexperte aufgelöst hat, mit Begründung>.
3  Beispiele   Zwei oder drei Kritiken des Fachexperten aus Schritt 3, wörtlich,
               jede mit ihrem Urteil, mindestens ein PASS und ein FAIL.
4  Ausgabe     {"reason": "<zwei bis vier Sätze, die benennen, was geprüft wurde>",
                "verdict": "PASS" | "FAIL"}

Das ist Eugene Yans Checkliste in einem Block: eine Aufgabe und ein Kriterium, präzise Definitionen samt Randfällen, Few-Shot-Beispiele zur Kalibrierung, ein festes Ausgabeformat. So sehen Teil 2 und 4 ausgefüllt aus, für ein Zitat-Kriterium:

Kriterium:
PASS, wenn die Antwort mindestens ein abgerufenes Dokument zitiert und jedes
zitierte Dokument eine Aussage enthält, welche die zugeordnete Behauptung stützt.
FAIL sonst.

Ausgabe:
{"reason": "<Zwei bis vier Sätze. Benenne die geprüfte Behauptung und Zitation.>",
 "verdict": "PASS" | "FAIL"}

Das Ausgabeformat ist immer dasselbe JSON. Der Runner liest daraus nur verdict. Das Praxisbeispiel ergänzt ein Feld quote, weil sein Kriterium ein wörtliches Zitat verlangt, und zeigt die Funktion, die den Judge aufruft und das JSON ausliest.

Die Reihenfolge in Teil 4 ist nicht kosmetisch. Verlangen Sie, dass der Judge seine Begründung vor dem Urteil schreibt. Ein Urteil, das zuerst kommt und danach begründet wird, ist eine Rationalisierung. Das senkt die Qualität messbar.

Dann iterieren Sie. Lassen Sie den Judge über den versiegelten Stapel aus Schritt 3 laufen. Listen Sie jeden Fall auf, in dem er vom Fachexperten abweicht. Lesen Sie zu jedem Fall die Begründung des Judges. Jede Abweichung fällt in eine von drei Schubladen:

Ändern Sie eine Sache pro Runde. Lassen Sie den Judge erneut über denselben versiegelten Stapel laufen. Hören Sie auf, wenn die Trefferquote im nächsten Schritt dort liegt, wo Sie sie brauchen. Zwei oder drei Runden sind normal. Husain berichtet von über 90 % Übereinstimmung nach drei Iterationen in einem Produktionsfall. Das ist rohe Übereinstimmung. Der nächste Schritt lässt sie aus gutem Grund nicht als Maß gelten. Das Kriterium für „fertig“ ist die Trefferquote, nicht diese Zahl. Wenn Sie bei Iteration zehn sind, ist wahrscheinlich das Kriterium unterbestimmt. Nicht der Judge ist unfähig. Das durchgerechnete Beispiel zeigt eine volle Runde: Eine erste Fassung winkt T-48213 mit der Begründung „die Seite enthält 39 €“ durch. Drei Kritiken kommen dazu. Eine zweite Fassung fängt den Fall.

6. Richtig messen

Dieser Schritt entscheidet, ob Sie überhaupt etwas in der Hand haben.

Befund: Berichten Sie Trefferquote (TPR) und Richtig-negativ-Rate (TNR), oder Precision und Recall. Berichten Sie nicht die rohe Übereinstimmung. Husain sagt ausdrücklich: Rohe Übereinstimmung täuscht, wenn die Klassen unausgewogen sind. Und sie sind fast immer unausgewogen. Wenn 90 % der Ausgaben bestehen, erreicht ein Judge, der immer „bestanden“ sagt, 90 % Übereinstimmung. Und er erkennt nichts.

Quelle: Hamel Husain, Creating a LLM-as-a-Judge

Konkret: Sie messen auf dem versiegelten Stapel aus Schritt 3. Der Fachexperte hat ihn gelabelt. Der Judge hat ihn nie gesehen:

Die vier Felder lesen sich so: Richtig positiv heißt, der Judge hat einen Fehler gemeldet, und es war wirklich einer. Falsch negativ heißt, er hat einen echten Fehler durchgewinkt. Aus diesen Feldern ergeben sich zwei Quoten:

• TPR (True Positive Rate, die Trefferquote auf Fehlern): Wie viele von allen tatsächlichen Fehlern hat der Judge gefunden?
• TNR (True Negative Rate, die Richtig-negativ-Rate): Wie viele von allen tatsächlich guten Antworten hat er korrekt durchgelassen?

Eine Konvention müssen Sie kennen, wenn Sie andere Quellen lesen. In diesem Leitfaden heißt positiv: „Der Judge meldet einen Fehler.“ Viele Bibliotheken und Aufsätze nehmen die andere Klasse als positiv. Dann tauschen TPR und TNR die Plätze. Schreiben Sie dazu, was bei Ihnen positiv heißt.

Rechnen wir mit Zahlen. Sie haben 200 Beispiele von Hand gelabelt. 20 davon sind echte Fehler, 180 sind in Ordnung. Der Judge liefert:

TPR = 8 / (8 + 12)   = 8 / 20  = 40 %
TNR = 171 / (171 + 9) = 171 / 180 = 95 %
Rohe Übereinstimmung = (8 + 171) / 200 = 89,5 %

Die 89,5 % sehen gesund aus. Genau das ist die Falle. Der Judge hat 12 von 20 echten Fehlern durchgewinkt. Er findet 40 % dessen, wofür er gebaut wurde. Gute Antworten sind in der Überzahl. Deshalb zieht die hohe TNR die Gesamtzahl nach oben und verdeckt das.

Die TPR ist deshalb meist die Zahl, die zählt. Der Judge existiert, um Fehler zu fangen. Er existiert nicht, um zu bestätigen, dass das Gute gut ist. Und die TPR ist selbst nur eine Schätzung aus wenigen Fällen. 8 von 20 sind 40 %, mit einer Spanne von rund ±21 Punkten. Berichten Sie TPR und TNR deshalb mit der Zahl der Fälle dahinter, also „8 von 20“ statt nur als Prozentwert. Statistik hat die Rechnung.

Setzen Sie die Latte nach den Folgen. Ein Judge, der ein Release freigibt, braucht eine hohe TPR. Ein Judge, der Stichproben aus der Produktion für einen Wochenbericht zieht, verträgt mehr Fehler. Denn die markierten Fälle sehen Sie sich ohnehin an. Als Arbeitslatte, so wie κ ≥ 0,5 im Datensatz-Kapitel: Für ein Release-Gate eine Trefferquote von mindestens 0,8, gemessen an mindestens 25 echten Fehlern. Für Berichte und Stichproben reicht weniger, solange jemand die markierten Fälle liest. Das ist eine Abwägung, keine Regel. Wie Sie beide Quoten aus den Labels und den Judge-Urteilen berechnen, zeigt das Messskript im Praxisbeispiel.

7. Fehler segmentieren, dann spezialisieren

Segmentieren heißt: Sie sehen die Fehlerquote nicht mehr als eine einzige Zahl. Sie teilen sie nach den Merkmalen auf, in denen sich Ihre Anfragen unterscheiden. Das sind dieselben Dimensionen, die Sie in Schritt 2 für den Datensatz festgelegt haben. Bei einem Support-Assistenten wären das etwa Anliegen, Suchergebnis und Nutzertyp.

Ein Beispiel. Der Judge läuft über 2.000 Gespräche. Die Gesamtfehlerquote liegt bei 22 %. Mit dieser Zahl kann niemand etwas anfangen. Aufgeschlüsselt:

Jetzt ist es kein diffuses Qualitätsproblem mehr, sondern ein benennbarer Fall: Die Sendungsverfolgung findet nichts, der Nutzer ist neu, und das System scheitert in drei von vier Fällen. Das ist ein Bug, den Sie beheben können. Die 22 % waren keiner. Genau das verdecken Gesamtwerte.

Bauen Sie zusätzliche enge Judges nur für konkrete Fehlermodi, die diese Analyse überstehen. Ein Judge pro Kriterium. Nicht ein Judge, der alles bewertet.

Was der Judge-Fehler mit Ihrem Eval-Wert macht

Ein Judge mit TPR 0,84 und TNR 0,91 irrt sich in beide Richtungen. Er lässt 16 % der schlechten Entwürfe durch. Und er lehnt 9 % der guten Entwürfe ab. Beides verschiebt die Bestehensquote, die er meldet. Die Verschiebung ist kein Zufall. Sie ist bei jedem Lauf gleich groß, solange der Judge derselbe bleibt.

Ein Beispiel mit 100 Entwürfen, von denen in Wahrheit 70 gut sind und 30 schlecht:

Von den 70 guten lässt der Judge 91 % durch:     0,91 × 70 = 63,7
Von den 30 schlechten lässt er 16 % durch:       0,16 × 30 =  4,8
Gemeldete Bestehensquote:                         63,7 + 4,8 = 68,5 %

Der Judge meldet 68,5 %. Die Wahrheit ist 70 %. Als Formel, so wie sie in anderen Texten steht:

beobachtete Quote = TNR × wahre Quote + (1 − TPR) × (1 − wahre Quote)

Wann das egal ist. Wenn Sie zwei Versionen Ihres Systems mit demselben Judge vergleichen, sind beide Zahlen um denselben Betrag verschoben. Der Unterschied zwischen ihnen bleibt fast unverändert. Das ist der häufigste Fall, und dort können Sie die Verschiebung ignorieren.

Wann es zählt. Wenn Sie eine absolute Zahl behaupten wollen, etwa „70 % unserer Entwürfe sind korrekt“ in einem Bericht. Dann rechnen Sie die Verschiebung heraus:

wahre Quote = (beobachtet − (1 − TPR)) / (TNR − (1 − TPR))
            = (0,685 − 0,16) / (0,91 − 0,16) = 0,70

Die Formel heißt Rogan-Gladen-Korrektur. Sie stammt aus der Epidemiologie. Dort wird sie seit 1978 benutzt, um aus den Ergebnissen eines unvollkommenen Tests die echte Häufigkeit einer Krankheit zu schätzen. Ein Judge ist genau so ein Test.

Eine Bedingung: TPR und TNR müssen auf Daten gemessen worden sein, die den Daten gleichen, über die der Judge dann läuft. Sonst gelten die 0,84 und 0,91 für diese Daten nicht, und die Korrektur rechnet mit falschen Zahlen. Das ist ein weiterer Grund, den versiegelten Stapel aus dem echten Verkehr zu ziehen und nicht aus dem Eval-Set.

Quelle: Rogan & Gladen, Estimating prevalence from the results of a screening test, American Journal of Epidemiology 107(1), 1978 · DOI 10.1093/oxfordjournals.aje.a112510

Das Judge-Modell wählen

Umstritten: Husains Position: Das Modell, das Ihr Produkt antreibt, taugt meist auch als Judge. Voraussetzung ist, dass Sie seine Ausrichtung an menschlichen Labels prüfen. Ist die Ausrichtung schlecht, probieren Sie ein anderes Modell. Die Literatur zur Self-Preference zeigt in die andere Richtung: gpt-4 gab sich selbst eine um 10 % höhere Gewinnrate, claude-v1 sogar 25 %, wenn sie eigene Ausgaben bewerteten.

Beides passt besser zusammen, als es zunächst wirkt. Self-Preference wird im paarweisen Vergleich von Modellen gemessen. Ein punktweiser Judge wendet ein geschriebenes Kriterium auf eine einzelne Ausgabe an. Das ist eine andere Aufgabe mit weniger Spielraum für Selbstbevorzugung. Die sichere Regel: Vergleicht der Judge Ausgaben verschiedener Modelle, nehmen Sie keines dieser Modelle als Judge. Wendet er ein festes Kriterium punktweise an, prüfen Sie die Ausrichtung und machen weiter.

Quelle: Husain & Shankar, LLM Evals FAQ; Self-Preference Bias, 2024

In der Praxis gehen Sie so vor. Fangen Sie mit dem Modell an, das Ihr Produkt antreibt, und messen Sie die Trefferquote. Ein stärkeres Modell nehmen Sie erst, wenn die Trefferquote nach zwei oder drei Prompt-Runden nicht reicht; das ist die dritte Zeile der Tabelle in Schritt 5. Ein kleineres, billigeres Modell nehmen Sie nur, wenn seine Trefferquote auf demselben versiegelten Stapel hält. Was ein Judge kostet, rechnen Sie vorher aus: Fälle, die den Judge aufrufen, mal Token je Aufruf, mal Preis je Token. Im Praxisbeispiel sind das 60 Fälle mal rund 3.000 Token, etwa 0,25 € je Lauf. Bei acht Läufen am Tag rund 60 € im Monat für diesen einen Judge. Jeder weitere Judge kommt obendrauf.

Feintunen Sie einen Judge nicht als ersten Schritt. Feingetunte Judge-Modelle verhalten sich wie Klassifikatoren für eine einzige Aufgabe. Sie sind stark in ihrer Domäne und schwach darin, zu verallgemeinern. Ändert sich das Bewertungsschema, brechen sie leicht ein. Der Aufwand fürs Feintunen ist meist besser angelegt, wenn Sie damit das geprüfte System verbessern.

Wartung

Ein Judge hängt von seinem Modell ab. Ändert sich die Version des Judge-Modells, gilt die gemessene Ausrichtung nicht mehr.

• Nageln Sie die Version des Judge-Modells ausdrücklich fest, samt datierter Snapshot-Endung.
• Behalten Sie den versiegelten Stapel. Messen Sie die Ausrichtung neu, wenn sich Judge-Modell, Kriterium oder Aufgabenverteilung ändern.
• Behandeln Sie diese Neumessung als Pflichtschritt jedes Modell-Upgrades, nicht als Kür.
• Prüfen Sie ohnehin regelmäßig nach. Die Aufgabenverteilung driftet auch dann, wenn sich in Ihrem Stack nichts ändert.
• Messen Sie je Sprache neu, wenn Sie mehr als eine bedienen. Eine Ausrichtungszahl gilt nur für die Sprache, in der sie gemessen wurde. Siehe Mehrsprachige Evaluation.

Häufiger Fehler: Einen Judge ohne versiegelten Stapel gelabelter Fälle in Betrieb nehmen und dann seine Werte in einer Planungssitzung zitieren. Ohne Ausrichtungszahlen haben diese Werte ein unbekanntes Vorzeichen. Sie können nicht sagen, ob eine Änderung, die diese Werte verbessert hat, sonst irgendetwas verbessert hat.