BlogEvaluierung
Wie viele Testfälle ein LLM-Eval braucht, um eine Entscheidung zu tragen
Eine Erfolgsquote um 80 % aus 100 Fällen ist um rund 8 Prozentpunkte in jede Richtung unsicher, deshalb sagen 80 % gegen 83 % für sich genommen fast nichts. Geben Sie zu jedem Ergebnis ein Intervall an, vergleichen Sie beide Versionen auf denselben Fällen und zählen Sie, welche Fälle gekippt sind, und bemessen Sie das Testset nach dem kleinsten Unterschied, auf den Sie reagieren würden. Im Rechenbeispiel von Evan Miller braucht ein Unterschied von 3 Punkten knapp 1000 Fragen.
Warum 80 % gegen 83 % bei 100 Fällen nichts beweist
Angenommen, ein neuer Prompt hebt Ihr Eval von 80 auf 83 bestandene Fälle von 100. Das sieht nach Fortschritt aus, und jemand wird ihn ausrollen wollen. Bevor dieses Gespräch beginnt, sollte um jede der beiden Zahlen ein Intervall stehen.
Wir haben das 95-%-Intervall für 80 von 100 auf zwei Arten berechnet. Die Normalapproximation ergibt einen Standardfehler von 4 Punkten und ein Intervall von 72,2 % bis 87,8 %. Das Wilson-Intervall, das sich bei kleinen Stichproben und Quoten nahe 0 % oder 100 % besser verhält, ergibt 71,1 % bis 86,7 %. Für 83 von 100 liefert Wilson 74,5 % bis 89,1 %. Die beiden Bereiche überlappen stark. Dieses Eval kann die Prompts nicht unterscheiden, und mit neuen Fällen könnte die Reihenfolge genauso gut umgekehrt ausfallen.
Eine Suite mit 100 Fällen lohnt sich trotzdem. Husain und Shankar beschreiben Testsets für CI als klein und zweckgebunden, in vielen Fällen mit 100 Beispielen oder mehr, und ein Set dieser Größe kann eine Änderung erkennen, die etwas deutlich kaputt macht. Zwei Versionen, die wenige Punkte auseinanderliegen, kann es aber nicht ordnen, und genau das wird bei einem Prompt- oder Modellwechsel meist von ihm verlangt.
Standardfehler und warum gruppierte Fragen sie vergrößern
Evan Millers Paper zu Fehlerbalken für Evals, entstanden bei Anthropic, behandelt ein Eval als Experiment und beginnt mit den Grundlagen: den Standardfehler des Mittelwerts über den zentralen Grenzwertsatz berechnen. Für binäre Bewertungen, also bestanden oder nicht bestanden, ist das die Wurzel aus p × (1 - p) / n, und das 95-%-Intervall reicht vom Mittelwert 1,96 Standardfehler nach unten und nach oben. Das ist die Normalrechnung von oben, und sie setzt voraus, dass jeder Fall unabhängig gezogen wurde.
Echte Testsets verletzen diese Annahme oft. Beziehen sich zehn Fragen auf denselben Vertrag oder stammen vierzig Fälle aus einem Support-Thema, liegt das Modell bei ihnen meist gemeinsam richtig oder gemeinsam falsch. Das Set enthält dann weniger unabhängige Belege, als seine Zeilenzahl vermuten lässt. Miller empfiehlt geclusterte Standardfehler, sobald Fragen in zusammengehörigen Gruppen vorliegen, und berichtet, dass sie mehr als dreimal so groß sein können wie die naiven. Beim Benchmark DROP lag sein geclusterter Standardfehler bei 1,34 gegenüber naiven 0,44.
Vergeben Sie in der Praxis schon beim Aufbau des Sets für jeden Fall einen Gruppenschlüssel, etwa Quelldokument, Kunde, Thema oder Gespräch, und clustern Sie die Intervalle danach. Wird das Intervall dadurch deutlich breiter, braucht das Set mehr Gruppen, nicht mehr Fragen pro Gruppe.
Beide Versionen auf denselben Fällen vergleichen
Laufen zwei Prompts oder Modelle auf denselben Fällen, verschenkt der Vergleich zweier Durchschnittswerte Information. Miller empfiehlt stattdessen, die gepaarten Differenzen pro Frage auszuwerten: Hat Version B in diesem Fall besser, schlechter oder gleich abgeschnitten wie Version A? Über den Unterschied sagen nur die Fälle etwas, die gekippt sind.
Ein hypothetischer Support-Assistent zeigt, wie das funktioniert. Auf 100 Testfällen besteht Prompt A 80 und Prompt B 83. Als Kreuztabelle sehen die Ergebnisse so aus.
| Fälle | B besteht | B scheitert |
|---|---|---|
| A besteht | 75 | 5 |
| A scheitert | 8 | 12 |
B besteht 8 Fälle zusätzlich und scheitert an 5, die A bestanden hat, ein Nettogewinn von 3. Das gepaarte 95-%-Intervall für die Differenz haben wir mit -4,1 bis +10,1 Punkten berechnet, gegenüber -7,8 bis +13,8, wenn man die beiden Läufe als unabhängige Stichproben behandelt. Ein gepaarter Bootstrap, der Fälle neu zieht, liefert fast denselben Bereich. Ein exakter McNemar-Test auf den 13 gekippten Fällen ergibt p = 0,58.
Bei dieser Größe würde selbst das sauberste Ergebnis die Frage nicht klären. Würde B 3 Fälle reparieren und keinen verschlechtern, läge das exakte McNemar-p bei 0,25, der Wahrscheinlichkeit, dass drei Münzwürfe alle gleich ausfallen. Nehmen Sie nun ein hypothetisches Set mit 400 Fällen, in dem A 81 % und B 84 % besteht, mit 16 neu bestandenen und 4 neu gescheiterten Fällen. Derselbe Gewinn von 3 Punkten hat dann ein gepaartes Intervall von 0,8 bis 5,2 Punkten und ein p von etwa 0,01. Entscheidend ist, wie viele Fälle gekippt sind und wie einseitig.
Wie viele Fälle ein bestimmter Unterschied braucht
Drehen Sie die Frage um, bevor Sie das Set aufbauen: Welcher Unterschied ist der kleinste, auf den Sie reagieren würden? Miller liefert dafür eine Power-Analyse. In seinem Rechenbeispiel braucht es bei 5 % Signifikanzniveau und 80 % Power etwa 969 Fragen, um einen Unterschied von 3 Punkten zu erkennen, und er empfiehlt Evals mit ungefähr 1000 Fragen oder mehr. Ein halb so großer Unterschied braucht ungefähr viermal so viele Fälle.
| Fälle | Intervall | Halbe Breite |
|---|---|---|
| 100 | 72,2 % bis 87,8 % | 7,8 Punkte |
| 200 | 74,5 % bis 85,5 % | 5,5 Punkte |
| 400 | 76,1 % bis 83,9 % | 3,9 Punkte |
| 1000 | 77,5 % bis 82,5 % | 2,5 Punkte |
Wenn Sie keine weiteren Fälle sammeln können, lassen Sie jeden Fall mehrmals laufen. Miller zeigt, dass bei 198 Fragen zehn Antworten pro Frage statt einer den kleinsten nachweisbaren Effekt von 13,2 % auf 7,5 % senkten. Wiederholungen helfen weniger als neue Fälle, denn sie verringern das Rauschen in den Antworten des Modells, nicht aber den Zufall, welche Fragen im Set gelandet sind.
Miller rät außerdem davon ab, die Temperatur nur deshalb zu senken, um die Varianz zu verringern. Unsere Lesart: Läuft die Produktion mit höherer Temperatur, misst ein Eval bei Temperatur 0 eine Konfiguration, die Ihre Nutzer nie sehen. Ziehen Sie lieber mehrere Antworten.
Wiederholte Läufe: pass@k und pass^k
Mehrere Läufe pro Fall zeigen außerdem etwas, das ein Durchschnitt verdeckt: ob das System konsistent arbeitet. Zwei Metriken fassen wiederholte Versuche gegensätzlich zusammen. pass@k zählt einen Fall als gelöst, wenn mindestens einer von k Versuchen gelingt. pass^k, eingeführt mit dem Benchmark τ-bench, zählt ihn nur, wenn alle k Versuche gelingen. Der Leitfaden von Anthropic zu Agenten-Evals verwendet dasselbe Paar.
Sie beantworten verschiedene Fragen. pass@k passt zu Aufgaben, bei denen jemand oder etwas den gelungenen Versuch auswählt, etwa generierter Code, der Tests bestehen muss, bevor ihn jemand nutzt. pass^k passt zu einem Agenten mit Kundenkontakt, bei dem jedes Gespräch ein weiterer Versuch ist und jeder Fehler bei einem Kunden ankommt.
τ-bench zeigt, wie weit beide auseinanderliegen können. Im Retail-Szenario löste gpt-4o in einem einzelnen Versuch etwa 61 % der Aufgaben, während pass^8, also Erfolg in allen acht Versuchen, unter 25 % fiel. Ein Teil dieser Streuung stammt vom simulierten Kunden. τ-bench lässt ein Sprachmodell die Nutzerrolle spielen und zieht dessen Antworten mit Temperatur 1,0, während der Agent mit Temperatur 0 läuft, sodass jeder Versuch ein anders formuliertes Gespräch ist. pass^k misst dort also auch, wie der Agent mit unterschiedlichen Formulierungen umgeht, nicht nur seinen eigenen Zufall.
Bleiben Sie bei Wiederholungen beim Fall als Einheit. Fünf Läufe über 100 Fälle sind nicht 500 unabhängige Fälle. Clustern Sie die Standardfehler, Millers Logik folgend, nach Fall.
Wie wir Eval-Ergebnisse berichten
Diese Regeln halten wir ein, wenn ein Eval-Ergebnis eine Entscheidung tragen soll.
- Jede Erfolgsquote nennen wir mit ihrem 95-%-Intervall und der Zahl der zugrunde liegenden Fälle, etwa 80 % (71 % bis 87 %, n = 100)
- Versionen vergleichen wir auf denselben Fällen und zeigen die gekippten Fälle: neu bestanden, neu gescheitert, unverändert. Jeder neu gescheiterte Fall wird gelesen
- Ergebnisse schlüsseln wir nach Teilmengen auf, etwa Sprache, Produkt oder Fallart. In einer Teilmenge mit 20 Fällen zählt ein Fall 5 Punkte, deshalb bekommen auch Teilmengen Intervalle
- Jeder Fall trägt einen Gruppenschlüssel, und die Intervalle werden danach geclustert
- Der kleinste Unterschied, der eine Reaktion rechtfertigt, wird vor dem Lauf festgelegt, und das Set wird danach bemessen
- Die kleine CI-Suite fängt Regressionen ab, über den Wechsel entscheidet ein größerer gepaarter Lauf
Dieselbe Logik gilt für Stichproben aus dem Produktionsverkehr. Husain und Shankar empfehlen, für Produktionsmetriken Konfidenzintervalle zu verfolgen und genauer hinzusehen, sobald die untere Grenze Ihren Schwellenwert unterschreitet.
LLM-Evaluierung für KI-ProdukteEin feingetuntes Modell gegen das Modell testen, das es ersetzen sollWas ein KI-Pilot belegen muss, bevor Sie die nächste Phase finanzieren
Fragen
Reicht ein Testset mit 100 Fällen überhaupt jemals?
Als Regressionsschranke oft ja: Es zeigt, dass eine Änderung etwas kaputt gemacht hat, besonders mit deterministischen Prüfungen, die fast immer bestehen sollten. Für die Wahl zwischen zwei Versionen, die wenige Punkte auseinanderliegen, nein. Eine Erfolgsquote um 80 % auf 100 Fällen ist um etwa 8 Punkte in jede Richtung unsicher, und selbst ein gepaarter Vergleich kann bei dieser Größe keinen Gewinn von 3 Punkten bestätigen.
Sollten wir die Normalapproximation oder das Wilson-Intervall verwenden?
In der Mitte des Wertebereichs stimmen beide gut überein, wie das Beispiel mit 80 von 100 zeigt. An den Rändern nicht. Für 98 von 100 liefert die Normalapproximation eine Obergrenze über 100 %, was unmöglich ist, Wilson dagegen etwa 93,0 % bis 99,4 %. Für einzelne Erfolgsquoten nehmen wir standardmäßig Wilson, für Vergleiche gepaarte Verfahren.
Decken diese Intervalle Fehler eines LLM-as-a-Judge ab?
Nein. Sie setzen voraus, dass jedes Urteil, bestanden oder nicht bestanden, korrekt ist. Bewertet ein Modell die Ausgaben, fügen seine eigenen Fehler Unsicherheit hinzu, die das Intervall nicht zeigt, und ein Judge, der in eine Richtung neigt, verschiebt das ganze Ergebnis. Messen Sie den Judge an menschlichen Labels, bevor Sie seine Werte mit einem Intervall versehen.
Verwandte Leistungen
LLM-Evaluierung
Evals für KI-Produkte, Agenten und RAG, aufgebaut aus Ihren eigenen Traces, mit Testset und Release-Gate in Ihrem Repository.
KI-Engineering und -Architektur
Assistenten, Sprachschnittstellen und Agenten in den Produkten, die Sie verkaufen, samt Serving und Retrieval darunter.
KI-Agenten und Prozessautomatisierung
Agenten, die die Routineschritte komplexer Fälle übernehmen und Entscheidungen an Menschen weitergeben, mit ausgewiesenen Kosten pro bearbeitetem Fall.
Mehr aus dem Blog
Feingetunte Modelle bewerten
Wie Sie zeigen, dass ein feingetuntes Modell das bisherige ersetzen sollte: vorab festgelegte Abnahmekriterien, ein fairer Vergleich auf zurückgehaltenen Fällen sowie Kosten und Latenz in derselben Tabelle.
Erfolgskriterien für KI-Piloten
Was ein KI-Pilot zeigen muss, bevor die nächste Phase finanziert wird, und wie Sie Abnahmekriterien festlegen, bevor jemand ein Werkzeug wählt.
Upgrades von Coding-Agenten testen
Wie Sie prüfen, ob ein neues Modell oder eine neue Agentenversion auf Ihren Repositories besser ist, bevor sie Teamstandard wird, mit fixierten Versionen und einem paarweisen Vergleich.
LLM-Judge validieren
Wie Sie einen LLM-Judge an von Hand gelabelten Beispielen prüfen, seine True Positive Rate und True Negative Rate ausweisen und die gemeldete Erfolgsquote korrigieren.
Mit einem Engineer sprechen
Bringen Sie eine Aufgabe mit, die Sie verbessern möchten. Das Gespräch dauert 30 Minuten und braucht keinen Zugriff auf Ihre Systeme oder Ihre Daten.
Die Buchung läuft über Google Kalender.
Lieber zuerst schreiben? Hinterlassen Sie Ihre E-Mail-Adresse und ein paar Zeilen, dann antworten wir mit Terminvorschlägen.
Sehen Sie in Ihrem E-Mail-Programm nach dem Entwurf
Senden Sie ihn von dort ab, und ein Engineer antwortet Ihnen persönlich mit Terminvorschlägen für ein 30-minütiges Gespräch. Hat sich kein Entwurf geöffnet, schreiben Sie uns an miki@cloudsail.com.