LLM-Judge Evals: Threshold tunen statt 0.50 übernehmen
Warum der Default-Threshold von Decision Models und LLM-Judges Evals verschlechtert und wie du Precision, Recall und Kalibrierung per Agent prüfst.
- 1Gelabelte Traces sammelnVon Menschen als pass oder fail markiert. Ohne Labels lässt sich kein Threshold prüfen.
- 2Mindestwerte festlegenPrecision und Recall nach Einsatzzweck, zum Beispiel beide mindestens 80 % für Alerting.
- 3Threshold pro Modell tunenMit Cross-Validation auf gespeicherten Scores, nicht mit dem Default 0.50.
- 4Kalibrierung messenNur wenn Scores als Konfidenz dienen sollen. Platt Scaling testen, nicht blind anwenden.
- 5Kosten gegen Qualität abwägenFür die gewünschte Qualität das günstigste Modell wählen, das die Mindestwerte schafft.
Grafik: Vibecoding Pro · Grundlage: die Quellen unten
Du lässt Claude Code im Headless Mode laufen, sammelst Traces und willst automatisch erkennen, welche Runs schiefgingen: falscher Tool-Call, behauptete Erledigung ohne Aktion, ignorierte Anweisung aus der CLAUDE.md. Dafür nimmst du einen LLM-Judge oder eines der neuen Decision Models, übernimmst den Default und baust darauf ein Dashboard. Genau da liegt der Fehler.
Hamel Husain hat in How To Use Decision Models for Evals sechs Decision Models auf demselben Datensatz verglichen: Jev 1.13, Perplexity Decider 1.1 27B, Liquid d1 und d1-ultra, Cloudflare Clef Flash und OpenAI Decisions (GPT-6 Luna). Die Ergebnisse zu einzelnen Modellen sind dabei weniger interessant als die Methode. Die gilt für jeden Judge, auch für den, mit dem du Skills, Prompts oder Subagent-Outputs bewertest.
Das Setup
Der Datensatz: 100 Traces, also Logs von Gesprächen und Aktionen eines Agenten für Wohnungsvermietung. Aufgabe: Traces mit Fehlern finden, etwa eine gescheiterte Buchung oder eine verpasste Übergabe an einen Menschen. Jedes Modell bekam dieselben Kriterien und lieferte pro Trace eine Fehlerwahrscheinlichkeit. Verglichen wurde gegen Traces, die Menschen als pass oder fail gelabelt hatten.
Husain empfiehlt ausdrücklich binäre pass/fail-Evals statt Skalen: Sie erzwingen klare Kriterien und lassen sich leichter mit menschlichen Urteilen abgleichen.
Der Default-Threshold ist ein stiller Bug
Die APIs liefern einen Score von 0 bis 1 und machen daraus bei 0.50 ein fail. Viele übernehmen diesen Wert ungeprüft. Das Problem lässt sich mit einem Gedankenexperiment zeigen: Ein Modell gibt allen echten Fehlern 0.40 und allen guten Traces 0.10. Bei 0.30 trennt es perfekt, bei 0.50 findet es keinen einzigen Fehler.
In echten Daten überlappen die Verteilungen. Ein niedrigerer Threshold fängt mehr Fehler, erzeugt aber mehr Fehlalarme. Die Wahl ist ein Trade-off zwischen:
- Precision: Anteil der markierten Traces, die wirklich einen Fehler enthalten.
- Recall: Anteil der echten Fehler, die das Modell findet.
Husain setzt für ein automatisches Alerting als Beispiel mindestens 80 % für beide. Modelle, die das nicht schaffen, fliegen raus, bevor überhaupt optimiert wird. Danach optimiert er auf F1, das harmonische Mittel aus beiden, betont aber, dass F1 nur eine Annahme ist. Mit F-beta kannst du Precision (beta < 1) oder Recall (beta > 1) stärker gewichten.
Tuning ist ein Job für den Agenten
Der praktischste Teil: Mit gelabelten Traces und gespeicherten Scores kann ein Coding-Agent das Tuning übernehmen. Husain liefert dafür einen Prompt. Sinngemäß, als Task für Claude Code:
Nimm scores.json (Fehlerwahrscheinlichkeit pro Trace) und labels.json (1 = fail).
Tune pro Modell einen Threshold auf maximales F1 mit Precision >= 0.8 und Recall >= 0.8.
Stratified 5-fold Cross-Validation, gleiche Splits für alle Modelle.
Threshold nur auf Trainings-Folds wählen, auf Validierungs-Folds messen.
Wenn kein Threshold die Mindestwerte schafft: melden, nicht lockern.
Vergleich mit 0.50 ausgeben. Keine neuen Modell-Calls, nur gespeicherte Scores.Die letzte Zeile ist wichtig: Das Tuning kostet dann nichts außer Rechenzeit. Und die Regel „nicht lockern“ verhindert, dass der Agent sich das Ergebnis schönrechnet.
Kalibrierung: Scores sind keine Wahrscheinlichkeiten
Wenn du Scores als Konfidenz nutzen willst, etwa „ab 0.8 automatisch Issue anlegen“, musst du prüfen, ob sie stimmen. Ein Score von 0.80 sollte heißen, dass etwa 80 % ähnlich bewerteter Traces Fehler enthalten. Im Test lag eine Gruppe von Clef-Flash-Traces bei rund 8 % vorhergesagter Fehlerwahrscheinlichkeit, tatsächlich enthielten 60 % Fehler.
Platt Scaling, also eine einfache nachgeschaltete Kurve, brachte Perplexity, Liquid d1 und Clef Flash näher an die Diagonale. Jev und Liquid d1-ultra waren schon gut kalibriert. Bei OpenAI wurden die Werte mit der verwendeten Variante sogar leicht schlechter. Heißt: Kalibrierung testen, mit Brier Score messen, nicht pauschal einbauen.
Kosten und Scope
Im Vergleich erreichte OpenAI Decisions das beste F1 (0.87), kostete aber etwa das 4,5-Fache von Perplexity (F1 0.79). Husain betont, dass die Modellleistung je nach Aufgabe und Datensatz stark schwankt. Seine Empfehlung: mit einem größeren Modell starten, das die Aufgabe ausreichend löst, und dann prüfen, ob kleinere Modelle mithalten. Außerdem: einen Judge pro Fehlerart statt eines breiten „findet alles“-Judges.
Was das für deinen Workflow bedeutet
Wenn du Agenten-Runs aus CI oder Headless Mode automatisch bewertest, prüfe drei Dinge:
- Labels: Gibt es eine von Menschen gelabelte Stichprobe? Ohne sie ist jeder Threshold geraten.
- Threshold: Steht irgendwo 0.50, weil es der Default war? Dann ist das ein Befund.
- Scope: Bewertet ein Judge alles, oder gibt es einen pro Fehlerart, etwa „behauptet Erledigung ohne Tool-Call“?
Die Verifikation im Repo selbst, also Tests als Orakel für den Agenten, behandelt Agentic Verification. Deterministische Regeln, die gar keinen Judge brauchen, gehören in Hooks. Ein Judge ist für alles, was sich nicht deterministisch prüfen lässt.
Fazit
Ein Eval ist ein Klassifikator, und für Klassifikatoren gelten die alten Regeln: Mindestanforderungen festlegen, Threshold tunen, Kalibrierung messen, Kosten abwägen. Nichts davon ist neu, aber laut Husain setzen viele Teams Decision Models direkt mit Default-Einstellungen ein.
Du willst wissen, ob dein Agenten-Setup inklusive Eval- und CI-Workflow auf belastbaren Checks steht oder auf Defaults? Setup-Review anfragen.
Häufige Fragen
Was ist ein Decision Model im Kontext von Evals?
Ein Modell, das schnell und günstig klassifiziert und für jede Eingabe einen Score zwischen 0 und 1 zurückgibt, etwa die Wahrscheinlichkeit, dass ein Trace einen Fehler enthält. Es ist eine günstigere Alternative zu einem LLM-Judge für automatisierte pass/fail-Evals.
Warum ist der Default-Threshold von 0.50 problematisch?
Die APIs machen aus dem Score erst bei 0.50 ein fail. Liegen alle echten Fehler zum Beispiel bei 0.40 und alle guten Traces bei 0.10, trennt das Modell perfekt bei 0.30, findet bei 0.50 aber nichts. Deshalb muss der Threshold gegen gelabelte Daten getunt werden.
Precision oder Recall: was ist wichtiger?
Das hängt vom Einsatz ab. Precision ist der Anteil der markierten Traces, die wirklich fehlerhaft sind, Recall der Anteil der echten Fehler, die gefunden werden. Für ein automatisches Alerting nennt Hamel Husain als Beispiel mindestens 80 % für beide.
Kann ich den Score eines Decision Models als Wahrscheinlichkeit lesen?
Nicht ungeprüft. Ein Score von 0.80 sollte bedeuten, dass etwa 80 % ähnlich bewerteter Traces Fehler enthalten. Im Test von Hamel Husain hatte eine Gruppe von Clef-Flash-Traces rund 8 % vorhergesagte Fehlerwahrscheinlichkeit, tatsächlich enthielten aber 60 % Fehler.
Einen Judge für alles oder einen pro Fehlerart?
Die Empfehlung lautet: einen eigenen Judge pro Fehlerart. Mit engerer Aufgabe und konkreterer Anleitung sollten auch die Unterschiede zwischen Modellen kleiner werden.