LLM-as-a-Judge validieren: So prüfen Sie den Judge an menschlichen Labels

Jeder Judge prüft genau einen Fehler

Husain und Shankar empfehlen, einen LLM-Judge als Klassifikator einzusetzen, der für einen bestimmten Fehler Pass oder Fail zurückgibt, statt eine allgemeine Qualitätsnote zu vergeben. In der Praxis heißt das: ein Judge pro Fehlertyp aus der Fehleranalyse. Bei einem hypothetischen Support-Assistenten wäre das etwa ein Judge für Erstattungen, die außerhalb der Richtlinie zugesagt werden, und ein zweiter für Antworten, die an der eigentlichen Frage des Kunden vorbeigehen.

Binäre Urteile machen auch die menschlichen Labels verlässlicher. Die FAQ der beiden stellt fest, dass Menschen auf einer Skala gern auf mittlere Werte ausweichen, um harte Entscheidungen zu vermeiden, und auch die Evaluierungsrichtlinien von OpenAI raten zu Pass/Fail oder Paarvergleichen.

Lassen Sie den Judge vor dem Urteil eine kurze schriftliche Kritik verfassen. Die Claude-Dokumentation von Anthropic empfiehlt, ein bewertendes Modell zuerst begründen zu lassen, bevor es bewertet. Sind Judge und Fachperson uneinig, hilft die Kritik zu erkennen, ob die Bewertungskriterien unklar sind oder der Judge die Konversation falsch gelesen hat. Ein Judge-Prompt für einen einzelnen Fehler braucht vier Dinge:

• Den Fehler in den Worten der Fachperson, einschließlich dessen, was nicht zählt
• Einige gelabelte Pass- und Fail-Beispiele aus dem Train-Split
• Nur die Teile der Konversation, die für die Entscheidung nötig sind
• Zuerst die Kritik, dann Pass oder Fail

Von Hand labeln, dann dreifach aufteilen

Die Referenz ist eine Menge von Beispielen, die eine Fachperson für denselben Fehler mit Pass oder Fail gelabelt hat, jeweils mit einem Satz zur Begründung. Der Leitfaden von Anthropic zu Agenten-Evals verlangt dasselbe von modellbasierten Bewertern: Sie müssen eng an menschlichen Fachleuten kalibriert sein. Husain und Shankar schlagen vor, die gelabelten Beispiele in drei Teile aufzuteilen.

1. 1

   Train: 10 bis 20 %

   Beispiele, die als Few-Shot-Beispiele im Judge-Prompt stehen dürfen. Wählen Sie eindeutige Fälle auf beiden Seiten.

2. 2

   Dev: 40 bis 45 %

   Für die Arbeit am Prompt. Lassen Sie den Judge laufen, lesen Sie die Abweichungen von der Fachperson, passen Sie an und lassen Sie ihn erneut laufen.

3. 3

   Test: 40 bis 45 %

   Wird einmal am Ende bewertet und liefert die Zahlen, die Sie berichten. Beim Tuning schaut niemand in diese Beispiele.

Die FAQ warnt, dass wiederholtes Tuning am Dev-Split zu Overfitting führt. Fällt das Testergebnis deutlich schlechter aus als das letzte Dev-Ergebnis, hat der Prompt wahrscheinlich die Dev-Beispiele gelernt und nicht den Fehler.

Bei 5 % Fehleranteil enthält ein zufälliger Test-Split mit 80 Beispielen etwa vier Fehlerfälle, und eine Rate aus vier Fällen sagt fast nichts. Ergänzen Sie Fehlerfälle aus der Fehleranalyse, bis der Test-Split etwa 30 Beispiele jeder Klasse enthält. TPR und TNR werden innerhalb einer Klasse gemessen, deshalb verzerrt diese Anreicherung sie nicht, solange die ergänzten Fehlerfälle denen aus der Produktion ähneln, aber der Fehleranteil im gelabelten Set sagt dann nichts mehr über die Produktion.

TPR und TNR statt Accuracy ausweisen

Husain und Shankar definieren die True Positive Rate als den Anteil der tatsächlichen Fehler, die der Judge erkennt, und die True Negative Rate als den Anteil guter Ausgaben, die er korrekt durchlässt. Die positive Klasse ist hier also der Fehler. Accuracy, der Anteil aller Urteile, die mit der Fachperson übereinstimmen, vermischt beide Raten und wird von der größeren Klasse bestimmt.

Das folgende Beispiel ist unsere eigene Überlegung mit erfundenen Zahlen. Nehmen Sie 1000 Konversationen des hypothetischen Support-Assistenten, von denen 50 den Fehler enthalten. Judge A lässt alles durch. Judge B erkennt 40 der 50 Fehler und markiert fälschlich 95 der 950 guten Konversationen.

Judge A gewinnt bei der Accuracy und findet keinen einzigen Fehler. Mit Judge B lässt sich arbeiten, aber seine TNR von 90 % hat einen Preis: 95 seiner 135 Markierungen sind Fehlalarme. Genau davor warnen Husain und Shankar: Bei seltenen Fehlern erzeugt schon eine kleine Fehlalarmrate viele unnötige Prüfungen. Allgemeingültige Zielwerte nennen sie nicht; sie raten, die akzeptablen Werte an den Folgen für Ihre Anwendung auszurichten. Eine übersehene Erstattungszusage gegen die Richtlinie kostet mehr als eine höfliche Antwort, die jemand ein zweites Mal liest.

Die Erfolgsquote vor dem Berichten korrigieren

Ein Judge mit bekannten Fehlerraten meldet eine verzerrte Erfolgsquote. Shankars Bibliothek judgy schätzt die tatsächliche Erfolgsquote, indem sie diese Verzerrung herausrechnet. In der oben verwendeten Schreibweise, mit dem Fehler als positiver Klasse, lautet die Schätzung: (beobachtete Pass-Quote + TPR - 1) / (TPR + TNR - 1).

judgy setzt stattdessen TNR in den Zähler, weil die Beispiele der Bibliothek Pass als 1 kodieren und ein Pass dort die positive Klasse ist. Die Rechnung ist dieselbe, nur die Namen sind vertauscht. Prüfen Sie vor dem Einsetzen die Konvention Ihres Codes: Wer die beiden Raten im Zähler verwechselt, erhält ein falsches Ergebnis, sobald sie sich unterscheiden.

Weiter mit dem hypothetischen Beispiel: Die Fachperson labelt 200 Konversationen, angereichert mit Fehlerfällen, und teilt sie in 40, 80 und 80 auf. Von den 80 Testbeispielen enthalten 30 den Fehler. Der fertige Judge erkennt 27 der 30 (TPR 90 %) und lässt 46 der 50 guten durch (TNR 92 %). In der Produktion lässt er 1700 von 2000 Konversationen durch, eine beobachtete Pass-Quote von 85 %.

Die korrigierte Schätzung ist (0,85 + 0,90 - 1) / (0,90 + 0,92 - 1) = 0,75 / 0,82, also etwa 91,5 %. Dieser Judge ist strenger als die Fachperson, und der Rohwert unterschätzt den Assistenten um mehr als sechs Prozentpunkte. Berichten Sie jetzt 85 % und wechseln später auf einen nachsichtigeren Judge, kommt die scheinbare Verbesserung vom Judge und nicht vom Assistenten.

Die Korrektur setzt voraus, dass TPR + TNR größer als 1 ist, der Judge also besser als der Zufall urteilt; judgy nennt diese Annahme. Außerdem sind TPR und TNR selbst Schätzungen aus 30 und 50 Beispielen: Läge die wahre TPR bei 80 %, ergäbe dieselbe beobachtete Quote korrigiert etwa 90,3 %. judgy legt per Bootstrap ein Intervall um die Schätzung, und dieses Intervall gehört in den Bericht.

Auf die bekannten Verzerrungen testen

Zheng und Kollegen haben 2023 LLM-Judges auf MT-Bench und Chatbot Arena untersucht. Starke Judges erreichten über 80 % Übereinstimmung mit menschlichen Präferenzen, etwa so viel, wie Menschen untereinander übereinstimmen. Die Arbeit dokumentiert aber auch systematische Verzerrungen. Die getesteten Modelle (GPT-4, GPT-3.5 und Claude-v1) sind inzwischen alt. Verstehen Sie die Zahlen deshalb als Anlass, Ihren eigenen Judge zu testen, nicht als Schätzung für ihn.

• Positionsverzerrung. Die meisten Judges bevorzugten im Paarvergleich die erste Antwort. Bei vertauschter Reihenfolge blieb GPT-4 in 65,0 % der Fälle bei seinem Urteil, GPT-3.5 in 46,2 % und Claude-v1 in 23,8 %. Die Autoren rufen den Judge deshalb zweimal mit vertauschter Reihenfolge auf und werten einen Sieg nur, wenn in beiden Durchläufen dieselbe Antwort vorne liegt; alles andere gilt als Unentschieden.
• Längenverzerrung. In einem Test mit sich wiederholenden Listen, der Antworten länger macht, ohne Information hinzuzufügen, ließen sich Claude-v1 und GPT-3.5 in 91,3 % der Fälle täuschen, GPT-4 in 8,7 %. Auch die Evaluierungsrichtlinien von OpenAI raten, die Antwortlänge zu kontrollieren.
• Selbstbevorzugung. GPT-4 bevorzugte eigene Antworten mit einer um 10 % höheren Siegquote, Claude-v1 mit einer um 25 % höheren. Die Autoren betonen, dass ihre Daten nicht ausreichen, um festzustellen, ob es sich um eine echte Selbstbevorzugung handelt. Wir lassen das bewertete Modell trotzdem nicht sein eigener Judge sein.

Die ersten beiden lassen sich auf Ihrem Dev-Split günstig prüfen: Wiederholen Sie Paarvergleiche mit vertauschter Reihenfolge, und blähen Sie einige gute Antworten mit Wiederholungen auf, um zu sehen, ob sich das Urteil verschiebt.

Mit Kriterien-Drift rechnen und neu validieren

Shankar und Kollegen beschreiben ein Phänomen, das sie Criteria Drift nennen: Menschen brauchen Kriterien, um Ausgaben zu bewerten, aber erst beim Bewerten finden sie heraus, was ihre Kriterien sind. Rechnen Sie damit, dass sich die Definition des Fehlers in den ersten Labelrunden ändert. Wenn das passiert, schreiben Sie die Kriterien neu und labeln Sie die früheren Beispiele nach der neuen Fassung. Sonst mischt der Test-Split zwei Definitionen, und die berichtete TPR gehört zu keiner davon.

Danach fixieren Sie den Judge. Halten Sie die vollständige, datierte Modellkennung fest, die Prompt-Version, die Version der Kriterien sowie TPR und TNR, die mit genau dieser Kombination gemessen wurden. Validieren Sie auf dem Test-Split neu, sobald sich einer dieser Bestandteile ändert. Wer immer wieder gegen denselben Test-Split validiert, macht ihn allmählich zu einem Dev-Split. Ergänzen Sie ihn deshalb um neu gelabelte Beispiele aus der aktuellen Produktion.

Der Validierungsbericht selbst ist kurz: der geprüfte Fehler, die Modellkennung, die Zahl der Fehlerfälle und guten Ausgaben im Test-Split, TPR, TNR, die korrigierte Erfolgsquote mit Intervall und das Datum. Hängen Sie ihn an jedes Dashboard und jeden Bericht, der Zahlen dieses Judges zeigt.

LLM-Evaluierung für KI-ProdukteFehleranalyse für LLM-AnwendungenWie viele Testfälle ein LLM-Eval braucht