Der Agentenkurs · Evals
Judges und Golden Sets
Lernziele
- Du prüfst einen Judge mit zwei Messungen: Übereinstimmung mit deinen Labels pro Klasse und Schwankung über wiederholte Läufe.
- Du stellst ein Golden Set mit guten und schlechten Beispielen zusammen.
- Du richtest eine Stichprobe aus echten Läufen ein, die das Golden Set jede Woche wachsen lässt.
Verhaltenscheck · engl. behavioural checkEine enge Ja-Nein-Prüfung, ob auf dem Weg zum Ergebnis ein bestimmter Schritt passiert ist, etwa ob der Agent die Bestellung vor der Antwort nachgeschlagen hat. Er läuft als Code über den Trace.Im Glossar sind Code, und Code ist verlässlich. Die Bewertung von Ergebnissen ist meist kein Code. Ob eine Antwort korrekt ist und auf den Quellen beruht, beurteilt nur, wer den Text liest, in der Praxis also ein weiteres Sprachmodell. Ein Judge · engl. LLM as a judgeEin Sprachmodell, das die Ausgabe eines anderen Modells nach einer festen Frage bewertet, etwa ob eine Antwort auf der gefundenen Notiz beruht. Ein Judge ist ein Messgerät und muss gegen eigene Labels geprüft werden.Im Glossar ist ein Messgerät, und kein Messgerät kommt kalibriert aus der Fabrik. Diese Lektion zeigt, wie du den Judge prüfst und danach die Fälle sammelst, die er bewertet.
Judges brauchen selbst eine Prüfung
Zwei Eigenschaften entscheiden, ob die Zahl eines Judges etwas bedeutet.
Die erste ist die Übereinstimmung mit deinen eigenen Labels. Bewerte Ausgaben selbst mit bestanden oder durchgefallen, lass den Judge dieselben Ausgaben bewerten und miss die Übereinstimmung getrennt pro Klasse. Ein Judge, der immer „bestanden“ sagt, erreicht auf überwiegend guten Daten 90 % rohe Übereinstimmung und fängt keinen einzigen Fehler. Lies jede Abweichung. Nach unserer Einschätzung liegt es etwa gleich oft an einer schwammigen Rubrik wie an deinem eigenen Label. Das Vorgehen im Detail und die bekannten Verzerrungen von Judges, etwa durch die Reihenfolge, die Länge oder die Vorliebe für eigene Texte, behandelt das Handbuch Eval Engineering.
Wie viel eine Übereinstimmung wert ist
- Rohe Übereinstimmung
- 90,0 %
- Übereinstimmung bei schlechten Ausgaben
- 0 %
- Schlechte Ausgaben in deinen Labels
- 10
- Unsicherheit der rohen Übereinstimmung (95 %, ±)
- 5,9 Prozentpunkte
Beispielwerte. Mit den Startwerten sagt der Judge immer „bestanden“: 90 % rohe Übereinstimmung, 0 % bei den schlechten Ausgaben. Die Unsicherheit ist eine Näherung für eine Stichprobe dieser Größe.
Stell den Regler für die schlechten Ausgaben auf 80 %. Die rohe Übereinstimmung steigt nur von 90 auf 98 %. Die Zahl, die zählt, springt dagegen von 0 auf 80 %. Schieb danach die Zahl der Labels auf 10. Dann liegt in deinen Labels nur noch eine schlechte Ausgabe, und die Messung für diese Klasse steht auf sehr dünnem Boden.
Die zweite Eigenschaft ist die Schwankung über wiederholte Läufe. Lass denselben Judge mehrmals auf dieselben Eingaben los und sieh nach, wie stark sich die Urteile bewegen. Airbnb beschreibt in seinem Engineering-Blog, wie teuer das werden kann. Die Pipeline erzeugte die von einem Modell geschriebenen Referenzantworten bei jedem Eval-Lauf neu. Laut Airbnb unterschieden sich bei identischen Eingaben etwa drei Viertel dieser Referenzen von Lauf zu Lauf, und derselbe Judge driftete auf denselben Daten um etwa ein Prozent.
Eine Bewegung der Note um zwei Punkte konnte damit dreierlei bedeuten: Der Agent war besser geworden, der Judge war gedriftet, oder die Referenzen waren neu gewürfelt. Die Eval maß ihr eigenes Rauschen. Airbnbs Lösung lohnt sich zum Nachbauen. Referenzen und Urteile des Judges landen in einem Cache, dessen Schlüssel aus Eingabe und Konfiguration besteht. Identische Eingaben liefern dann identische Ergebnisse, und neu erzeugt wird nur mit Absicht.
Das Golden Set bauen
Das Golden SetDie feste Sammlung von Testfällen, gegen die alle Evals laufen. Sie enthält gute und schlechte Beispiele und wächst mit jedem Fehler aus dem Betrieb.Im Glossar ist die feste Sammlung von Fällen, gegen die beide Stufen der Suite laufen. Airbnbs Bericht über eval-getriebene Entwicklung empfiehlt 50 bis 100 Beispiele. Bei der Zusammensetzung ist er deutlich: Das Set muss schlechte Beispiele enthalten, weil sich Urteilsvermögen ohne sie nicht testen lässt. Eine Suite, die nur glatte Fälle kennt, bescheinigt dem Agenten, dass er kann, was er schon kann.
Googles Whitepaper Agent Quality ergänzt die Regel für die Pflege. Jeder Fehler aus dem Betrieb wird, sobald er erfasst und annotiert ist, zu einem dauerhaften Testfall. Nach unserer Einschätzung sind Fehler die wertvollsten Fälle, die du je bekommst, weil hinter jedem eine echte Person mit einem echten Grenzfall steht. Wie du Traces in Fälle verwandelst, zeigt die Lektion Evals in der Praxis.
Halte die Bewertungsmaschinerie klein, während das Set wächst. Airbnb rät dazu: Drei bis fünf gut kalibrierte Judges, jeder für eine Dimension der Korrektheit, schlagen zwanzig oder dreißig verrauschte.
Stichproben aus dem Betrieb und alternde Sets
Ein Golden Set ist ein Foto deiner Nutzerinnen und Nutzer in dem Moment, in dem du es aufnimmst. Danach bewegen sie sich weiter. Neue Formulierungen kommen dazu, neue Dokumenttypen landen im Vault, ein neues Feature verschiebt, wonach Menschen fragen. Nach sechs Monaten kann eine Suite bei 95 % bestehen und trotzdem nur noch die Hälfte dessen abdecken, was im Betrieb wirklich ankommt.
Dagegen hilft ein fester Zufluss aus echtem Verkehr. Airbnb zieht nach eigenen Angaben täglich eine Stichprobe von 5 % des anonymisierten Live-Verkehrs und lässt programmatische Checks und Judges darüber laufen, beschränkt auf Sicherheit und Qualitätssicherung. Die Form passt für jede Größe: Zieh regelmäßig einen Ausschnitt echter Läufe, bewerte ihn und übernimm jeden Fehler in das Golden Set.
Schritt 1 von 4
Stichprobe ziehen
Nach festem Plan einen Ausschnitt echter Läufe ziehen, etwa jede Woche ein paar Dutzend Traces.
Das Set soll jede Woche ein wenig wachsen. Ist der neueste Fall in deinem Golden Set drei Monate alt, ist das Set nach unserer Einschätzung schon gealtert.
Mit kalibrierten Judges, einem Set voller Fehlerfälle und einer Stichprobe, die das Set ehrlich hält, wird die Messung selbst vertrauenswürdig. Die Lektion Evals in der Praxis macht daraus einen Nachmittag mit konkreten Schritten. Sie beginnt bei den zwanzig jüngsten Fehlern deines eigenen Agenten.
Merksätze
- Ein Judge ist ein Messgerät, das du gegen eigene Labels prüfst, getrennt nach guten und schlechten Ausgaben.
- Wiederholte Läufe zeigen, wie stark ein Judge schwankt, und ein Cache auf Eingabe und Konfiguration macht identische Eingaben reproduzierbar.
- Ein Golden Set mit 50 bis 100 Fällen braucht schlechte Beispiele, sonst testet es kein Urteilsvermögen.
- Jeder annotierte Fehler aus dem Betrieb wird ein dauerhafter Testfall.
- Eine regelmäßige Stichprobe aus echten Läufen hält das Set aktuell, und wenige kalibrierte Judges reichen für die Bewertung.
Prüf dich selbst
Denkfrage
Dein Judge stimmt zu 92 % mit deinen Labels überein. Reicht das, um ihm zu vertrauen?
Noch nicht. Erst die Übereinstimmung pro Klasse sagt etwas. Sind 90 % deiner Ausgaben gut, erreicht ein Judge, der immer „bestanden“ sagt, schon 90 %. Prüf, wie viele der schlechten Ausgaben er erkennt, und lies jede Abweichung.
Denkfrage
Die Note deiner Suite schwankt zwischen zwei Läufen ohne Änderung am Agenten um zwei Punkte. Was prüfst du zuerst?
Ob Referenzen oder Urteile bei jedem Lauf neu erzeugt werden. Dann misst die Eval ihr eigenes Rauschen. Leg Referenzen und Urteile in einen Cache mit Eingabe und Konfiguration als Schlüssel und lass den Judge mehrmals auf denselben Daten laufen, um seine Schwankung zu sehen.
Prüf dich selbst
Quellen
- From weeks to a day: how we made LLM evaluation fast enough to iterate on
Etwa drei Viertel der Modell-Referenzen unterscheiden sich zwischen Läufen, Judge-Drift um etwa ein Prozent, Cache auf Eingabe und Konfiguration. Angaben des Unternehmens.
- Eval-driven development: Lessons from evaluating GenAI at scale
Golden Set mit 50 bis 100 Beispielen inklusive schlechter, drei bis fünf kalibrierte Judges, tägliche Stichprobe von 5 % des Verkehrs. Angaben des Unternehmens.
- Agent Quality
Jeder erfasste und annotierte Fehler aus dem Betrieb wird ein dauerhafter Testfall im Golden Set.