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.

Von Aktualisiert am

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.

Prompt A gegen Prompt B auf denselben 100 Fällen (hypothetisch)
FälleB bestehtB scheitert
A besteht755
A scheitert812

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.

95-%-Intervall um eine Erfolgsquote von 80 % nach Anzahl der Fälle (Normalapproximation, eigene Berechnung)
FälleIntervallHalbe Breite
10072,2 % bis 87,8 %7,8 Punkte
20074,5 % bis 85,5 %5,5 Punkte
40076,1 % bis 83,9 %3,9 Punkte
100077,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.

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.

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.

Die Schaltfläche bereitet in Ihrem eigenen E-Mail-Programm eine E-Mail vor, die Sie selbst senden. Datenschutzerklärung (Entwurf)