Warum flaky Evals Release-Entscheidungen verfälschen
Wer Prompt-Anpassungen oder Modellwechsel allein am Durchschnitt von Eval-Suiten misst, übersieht reale Regressionen bei einzelnen Intents. Gepaarte, statistisch ausreichend dimensionierte Tests helfen, Schwankungen der Flake Rate von echten Verbesserungen zu unterscheiden.
Ich habe dreimal beobachtet, wie derselbe Release schiefging. Jemand verfeinert einen Prompt oder tauscht ein Modell aus, der Eval-Durchschnitt steigt von 0,81 auf 0,83, der Pull Request wird genehmigt, und zwei Wochen später schlägt eine bestimmte Absicht in der Produktion fehl. Die Regression war real. Die Verbesserung nicht. Niemand hat unachtsam gehandelt. Die Eval lieferte eine Zahl, die wie eine Messung aussah, tatsächlich aber einem Münzwurf glich.
Der unspektakuläre Teil von LLMOps besteht nicht im Prompt-Management oder Tracing. Er besteht darin, dass die meisten Eval-Suiten die Änderungen, die Teams ausliefern, gar nicht zuverlässig erkennen können. Das zu beheben erfordert einen halben Tag Statistik und genau einen CI-Job.
Bevor Sie zwei Konfigurationen vergleichen, sollten Sie wissen, was sich bewegt:
Sie können nicht alle drei eliminieren. Die erste lässt sich jedoch fast vollständig beseitigen, indem man gepaarte Ergebnisse vergleicht: Man führt Baseline und Kandidat auf denselben Beispielen aus und analysiert die Differenz pro Beispiel. Die Schwierigkeit der Beispiele hebt sich auf. Ein Prompt, der einen schwierigen Fall löst und einen anderen beschädigt, zeigt sich nun als ein +1 und ein -1 und nicht als ein Aggregat, über das man erst nachdenken muss.
Bei einem gepaarten Vergleich von Bestehen-oder-Durchfallen-Ergebnissen hängt der Standardfehler der mittleren Differenz von der Diskrepanzrate ab, also davon, wie oft die beiden Konfigurationen bei demselben Beispiel unterschiedlich urteilen, und nicht von der Genauigkeit.
Wenn 15 Prozent der Beispiele zwischen Ihren beiden Konfigurationen kippen und Sie über 200 gepaarte Beispiele verfügen:
Bei diesem Aufbau ist eine Verbesserung von zwei Prozentpunken also unsichtbar. Um unter denselben Annahmen eine Änderung von fünf Punkten zu erkennen, benötigen Sie ungefähr 400 gepaarte Beispiele; für drei Punkte etwa 1.100. Das sind Rechenaufgaben, keine Benchmarks. Setzen Sie einfach Ihre eigene Diskrepanzrate ein, die bei Prompt-Änderungen meist höher ausfällt, als man erwartet.
Daraus folgen zwei Konsequenzen. Erstens: Hören Sie auf, Gate-Entscheidungen auf rohen Durchschnitten aufzubauen. Zweitens: Wenn Ihr Golden Set 200 Beispiele umfasst und Sie es nicht vergrößern können, sollte Ihre Schwelle lauten: keine Regression über X hinaus, statt: Verbesserung erforderlich.
Das Ganze umfasst etwa dreißig Zeilen Python nur mit der Standardbibliothek. Bootstrappen Sie die gepaarten Differenzen, betrachten Sie das Intervall und liefern Sie erst aus, wenn das Intervall klar über null liegt.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
I have watched the same release go wrong three times. Someone tunes a prompt or swaps a model, the eval average moves from 0.81 to 0.83, the PR gets approved, and two weeks later a specific intent is failing in production. The regression was real. The improvement was not. Nobody did anything careless — the eval reported a number that looked like a measurement and was actually a coin flip.
The unglamorous part of LLMOps is not prompt management or tracing. It is that most eval suites cannot detect the changes teams ship on. Fixing that is a half-day of statistics and one CI job.
Before you compare two configurations, know what is moving:
You cannot remove all three. You can remove the first one almost entirely by comparing paired results: run baseline and candidate on the same examples and analyze the per-example difference. Example difficulty cancels out. A prompt that fixes one hard case and breaks another now shows up as one +1 and one -1, not as an aggregate you have to reason about.
For a paired comparison of pass/fail outcomes, the standard error of the mean difference depends on the disagreement rate — how often the two configs disagree on the same example — not on the accuracy.
If 15% of examples flip between your two configurations and you have 200 paired examples:
So on that setup, a 2-point bump is invisible. To see a 5-point change under the same assumptions you need roughly 400 paired examples; to see 3 points, about 1,100. These are arithmetic, not benchmarks — plug in your own disagreement rate, which is usually higher than you expect for prompt changes.
Two consequences follow. First, stop gating on raw averages. Second, if your golden set is 200 examples and you cannot grow it, your gate should be "no regression beyond X" rather than "improvement required."
The whole thing is about thirty lines of stdlib Python. Bootstrap the paired differences, look at the interval, and ship only when the interval clears zero.