Eval-Sets und Regressionstests

Ein Refactoring räumt die Prompt-Vorlage auf: Feldnamen klein, Trennzeichen einheitlich, Beispiele alphabetisch. Am Instruktionstext ändert sich nichts, und der Eval-Lauf fällt um 6 Punkte. In einer systematischen Messung lagen bis zu 76 Genauigkeitspunkte zwischen der besten und der schlechtesten von mehreren gleichbedeutenden Formatvarianten.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-04

Warum eine Handvoll Beispiele nichts entscheidet

Die verbreitetste Form der Prompt-Qualitätssicherung ist der Blick auf fünf Beispiele. Sie hat einen strukturellen Defekt: Wer die Änderung gemacht hat, wählt die Beispiele aus — und wählt, ohne es zu wollen, jene, an denen die Änderung wirkt. Zwei Engineers mit je fünf Beispielen können denselben Streit unbegrenzt fortsetzen.

Dieses Modul behandelt das Gegenmittel und nichts anderes: eine feste Menge von Fällen mit erwarteten Ergebnissen, an der jede Änderung vor der Auslieferung gemessen wird. Alles Weitere — welche Fälle, welche Prüfungen, wie viele Läufe, welches Gate — folgt daraus.

MerksatzEine Prompt-Änderung ohne Vorher-Nachher-Messung an fixer Fallmenge ist eine Meinung mit Deployment. Das gilt besonders dann, wenn die Änderung eleganter aussieht.

Ein Eval-Set ist ein Experiment

Der nützlichste Rahmen für die Sache stammt aus der Statistik. Miller hat 2024 vorgeschlagen, Evaluationen konsequent als Experimente zu behandeln: Die Fragen im Set sind eine Stichprobe aus einer größeren, nicht beobachteten Grundgesamtheit, und jedes Ergebnis trägt entsprechend eine Unsicherheit. Ziel ist, Auswertung und Aufbau so zu gestalten, dass statistisches Rauschen klein und die Aussagekraft groß wird.

Daraus folgt die unbequeme Konsequenz für den Alltag: Eine Zahl ohne Unsicherheit ist keine Aussage. Wenn Variante A 87 % und Variante B 89 % erreicht, ist die Frage nicht, welche Zahl größer ist, sondern ob der Unterschied bei dieser Stichprobengröße überhaupt von Rauschen unterscheidbar ist.

Eval-Set — Eine festgelegte, versionierte Menge von Eingaben mit erwartetem Ergebnis, die bei jeder Änderung unverändert erneut ausgeführt wird. Fix zu sein ist ihre wichtigste Eigenschaft — wer sie mit dem Prompt zusammen anpasst, misst nichts mehr.

MerksatzZwei Prozentpunkte Unterschied sind keine Verbesserung, solange niemand gerechnet hat, wie groß der Zufallsanteil bei dieser Fallzahl ist.

Woher die Testfälle kommen

Die beste Quelle für Testfälle sind echte Fehler. Jeder gemeldete Vorfall, jede Beschwerde, jede im Review gefundene Fehlantwort ist ein Fall mit bekanntem Sollwert — kostenlos entstanden und garantiert relevant, weil er tatsächlich passiert ist.

Daraus wird eine Regel, die den Unterschied zwischen einem wachsenden und einem verrottenden Set macht: Kein behobener Vorfall ohne Testfall. Wer einen Fehler behebt, ohne den Fall aufzunehmen, hat ihn für genau einen Zeitpunkt behoben — die nächste Prompt-Änderung kann ihn zurückbringen, und niemand erfährt es.

Vorfall→Fehlerart benennen→Testfall mit Sollwert→Behebung→Testfall hält

Neben den echten Fällen braucht ein Set zwei weitere Sorten: Grundlast — unstrittige Fälle, die zeigen, dass die Basis funktioniert — und Gegenfälle, die prüfen, dass eine Maßnahme nicht übers Ziel schießt. Der letzte Punkt ist der am häufigsten fehlende: Wer nur Ablehnungen und Fehlerfälle prüft, optimiert ungestört in die Übervorsicht.

MerksatzEin Set aus echten Vorfällen ist relevant und einseitig — es enthält nur, was schiefging. Grundlast und Gegenfälle machen daraus eine Messung statt einer Fehlersammlung.

Die Fehler-Taxonomie ist die eigentliche Arbeit

Bevor Fehler in Fälle werden, müssen sie benannt sein. Eine Sammlung von 200 Fehlantworten ohne Klassifikation ist ein Haufen; dieselben 200 in acht benannten Fehlerarten sind eine Arbeitsliste mit Prioritäten. Diese Taxonomie zu bauen ist der Teil, der Zeit kostet und nicht delegiert werden kann.

Fehlerart: Was sie kennzeichnet
Ungestützte Aussage: Inhaltlich falsch, weil die Grundlage im Material fehlte.
Formatverstoß: Struktur weicht ab; der Konsument kann nicht lesen.
Falsche Zuordnung an einer Grenze: Zwei Kategorien kamen in Frage, die falsche gewann.
Regelkonflikt: Zwei gültige Vorgaben widersprachen sich, keine hatte Vorrang.
Übervorsicht: Eine zulässige Anfrage wurde abgelehnt.
Erfundener Wert bei fehlender Angabe: Der leere Fall war nicht spezifiziert.

Der Nutzen zeigt sich in der Maßnahme: Jede dieser Arten hat einen anderen Hebel — Grounding, Schema-Zwang, Beispielwahl an der Grenze, deklarierte Präzedenz, Gegenfälle, benannter Ausgang. Ohne Taxonomie wird jeder Fehler mit dem Werkzeug behandelt, das gerade zur Hand ist.

MerksatzEine Fehlerart ohne Namen bekommt keine Priorität und keinen passenden Hebel. Die Taxonomie ist nicht Buchhaltung, sondern die Voraussetzung dafür, dass Arbeit an der richtigen Stelle landet.

Assertions in drei Härtegraden

Ein Testfall braucht eine Prüfung, und die Wahl der Prüfung entscheidet, was der Test überhaupt sehen kann. Drei Härtegrade, von billig und streng zu teuer und weich:

Exakt — der Wert ist genau dieser. Für Klassifikation, Extraktion, IDs, Zahlen. Billig, deterministisch, keine Deutung.
Strukturell — die Antwort erfüllt eine prüfbare Eigenschaft: Schema gültig, Feld vorhanden, Textstelle im Dokument auffindbar, höchstens fünf Sätze. Billig und ausdrucksstark.
Beurteilt — ein Modell oder ein Mensch bewertet die Qualität. Nötig für freie Prosa, teuer, verzerrungsanfällig.

Die Regel dazu ist unspektakulär und wird oft verletzt: Nimm den härtesten Grad, der die Sache trifft. Für eine Klassifikation ist ein beurteilender Test Verschwendung und ungenauer. Umgekehrt ist ein exakter Textvergleich für eine Zusammenfassung untauglich — zwei richtige Zusammenfassungen sind nie identisch.

MerksatzDie meisten Prompt-Anforderungen lassen sich strukturell prüfen, wenn man sie prüfbar formuliert hat. Wer sofort zum beurteilenden Test greift, hat meist eine unpräzise Nachbedingung.

Ein Modell als Prüfer: was es kann, wo es verzerrt

Für die dritte Stufe wird üblicherweise ein Modell als Prüfer eingesetzt. Zheng und Kollegen haben das systematisch untersucht — und beide Hälften ihres Befundes gehören zusammen genannt. Die gute: Ein starker Modell-Prüfer erreicht über 80 % Übereinstimmung mit menschlichen Präferenzen — dasselbe Niveau, auf dem Menschen untereinander übereinstimmen.

Die andere Hälfte sind vier benannte Schwächen: Positions-Verzerrung (die Reihenfolge der verglichenen Antworten wirkt), Längen-Verzerrung (längere Antworten werden bevorzugt), Selbstbevorzugung (eigene Ausgaben werden besser bewertet) und begrenzte Schlussfähigkeit bei Aufgaben, die eigenes Rechnen oder Ableiten erfordern.

Verzerrung: Gegenmaßnahme im Aufbau
Position: Beide Reihenfolgen bewerten lassen und nur zählen, was in beiden gleich ausgeht.
Länge: Länge als Nebenbedingung strukturell prüfen, nicht dem Prüfer überlassen.
Selbstbevorzugung: Prüfer und Prüfling nicht dasselbe Modell sein lassen.
Begrenzte Schlussfähigkeit: Rechen- und Ableitungsaufgaben exakt prüfen, nicht beurteilen lassen.

MerksatzEin Modell-Prüfer ist brauchbar auf dem Niveau menschlicher Übereinstimmung — mit vier bekannten Verzerrungen, gegen die der Aufbau etwas tun muss. Wer ihn ohne diese Maßnahmen einsetzt, misst teils Länge und Position.

Was `temperature: 0` leistet und was nicht

Für reproduzierbare Messungen greift man zum offensichtlichen Mittel: temperature: 0, damit bei gleicher Eingabe dieselbe Ausgabe entsteht. Das ist richtig und wird regelmäßig überschätzt.

Was es leistet: Was es nicht leistet
Entfernt die Streuung aus dem Sampling: Macht die Antwort nicht richtig — nur reproduzierbar falsch
Macht einen Testlauf vergleichbar: Beseitigt Restschwankungen aus der Infrastruktur nicht zwingend
Isoliert die Wirkung einer Prompt-Änderung: Sagt nichts über das Verhalten in Produktion, wo oft nicht 0 gilt
Ist der richtige Standard im Eval: Ist der falsche Standard, wenn das Verfahren Streuung braucht

Die letzte Zeile ist die, die in Produktionssystemen Schaden anrichtet: Wer im Eval mit temperature: 0 misst und in Produktion mit höherem Wert fährt, hat eine Messung ohne den Streuungsanteil — und genau der erzeugt die Beschwerden über wechselhafte Qualität. Miss unter den Bedingungen, unter denen ausgeliefert wird, und ergänze bei Streuung Mehrfachläufe.

Merksatztemperature: 0 macht die Messung reproduzierbar, nicht die Antwort richtig — und es entfernt genau die Streuung, über die Nutzer sich beschweren. Wer sie messen will, muss sie zulassen und mehrfach laufen.

Brüchigkeit: jedes Ergebnis ist eine Messung

Ein Grund, warum Einzelzahlen trügen: Prompts sind gegenüber bedeutungserhaltenden Formatänderungen empfindlich. Sclar und Kollegen haben bei einem offenen Modell eine Spanne von bis zu 76 Genauigkeitspunkten zwischen der besten und der schlechtesten von mehreren gleichbedeutenden Formatvarianten gemessen — und die Empfindlichkeit blieb bei größeren Modellen, mehr Beispielen und Instruction-Tuning bestehen.

Für dein Eval hat das zwei Folgen. Erstens: Fixiere das Format und ändere es bewusst, nicht beim Aufräumen — sonst vergleichst du zwei Messungen, die sich in etwas unterscheiden, das niemand notiert hat. Zweitens: Wenn ein Vergleich zwischen zwei Prompts kippt, sobald man eine Kleinigkeit an der Darstellung ändert, ist das Ergebnis eine Messung und kein Befund über die Sache.

MerksatzNotiere zu jeder Eval-Zahl, unter welchem Format sie entstand. Ein Formatwechsel im Zuge eines Refactorings kann eine Regression erzeugen, die niemand mit dem Refactoring in Verbindung bringt.

Rauschen von Signal trennen

Damit die Zahlen entscheidbar werden, braucht es drei Gewohnheiten. Gepaart vergleichen: dieselben Fälle für beide Varianten, nicht zwei Stichproben. Mehrfach laufen, wenn Streuung im Spiel ist, und die Schwankung mitberichten. Und die Fallzahl kennen, die nötig ist, um den erwarteten Unterschied überhaupt sehen zu können.

Zwei Prozentpunkte

Szenario

Variante B erreicht 89 % gegenüber 87 % bei Variante A, gemessen an 80 Fällen, je ein Lauf, temperature: 0. Das Team will B ausliefern. Die zwei Punkte entsprechen einer Differenz von 1,6 Fällen.

Anforderungen

Wie gehst du mit dieser Zahl um?
Benenne, was du nach der Prüfung wissen kannst und was nicht.

Schritte

Erkennen, worum es geht: Bei 80 Fällen ist ein Unterschied von zwei Punkten weniger als zwei Fälle — er kann vollständig aus der Auswahl der Fälle stammen.
Gepaart auswerten: Nicht die Quoten vergleichen, sondern die Fälle, in denen A und B unterschiedlich antworten. Wenn B in 3 Fällen besser und in 1 schlechter ist, ist das eine andere Information als zwei Prozentpunkte.
Die unterschiedlich beantworteten Fälle einzeln ansehen. Vier Fälle sind in zehn Minuten geprüft — und liefern eine Begründung statt einer Zahl.
Wenn die Entscheidung wichtig ist: die Fallzahl erhöhen oder mehrfach laufen lassen, bevor ausgeliefert wird. Kleine Unterschiede brauchen große Stichproben.
Das Ergebnis notieren, auch wenn es lautet, dass kein Unterschied nachweisbar ist. Das ist ein Resultat und verhindert, dass die Frage in drei Wochen erneut gestellt wird.

Merksatz: Ein Unterschied von zwei Prozentpunkten bei 80 Fällen ist keine Verbesserung, sondern eine Zahl ohne Aussage — die gepaarte Betrachtung der abweichenden Fälle liefert in derselben Zeit eine begründete Entscheidung. + Du lieferst keine Änderung aus, deren Wirkung du nicht belegen kannst, und lernst aus vier Fällen mehr als aus zwei Punkten. − Es kostet Zeit und endet oft mit dem unbefriedigenden Ergebnis, dass nichts nachweisbar ist — und dann muss jemand entscheiden, ob die Änderung aus anderen Gründen sinnvoll ist.

Der Modellwechsel ist der größte Änderungsfall

Alles in diesem Modul zahlt sich beim Modellwechsel aus — dem Fall, in dem sich alles gleichzeitig ändern kann. Ein Prompt ist auf ein Modell hin eingestellt; ein anderes Modell hat andere Neigungen bei Format, Länge, Ausführlichkeit, Vorsicht und Reasoning.

Ohne Eval-Set ist ein Modellwechsel ein Sprung ins Dunkle: Man merkt Regressionen, wenn Nutzer sie melden. Mit Eval-Set ist er eine Messung — und zwar die einzige Gelegenheit, bei der die Investition in den Fallsatz sich vollständig und sichtbar auszahlt. Die Reihenfolge lohnt sich, weil sie Wirkung isoliert: erst gegen den alten Prompt messen, dann anpassen, dann erneut messen.

Erst messen, nichts ändern — den unveränderten Prompt auf dem neuen Modell laufen lassen. Das trennt Modellwirkung von Prompt-Wirkung.
Die Abweichungen klassifizieren — nach deiner Fehler-Taxonomie. Formatverstöße und Übervorsicht sind die häufigsten Migrationsbefunde.
Gezielt anpassen — je Befund einen Hebel, danach erneut messen. Nicht mehrere Änderungen in einem Schritt.
Den alten Stand messbar halten — solange beide Modelle verfügbar sind, ist der Vergleich jederzeit wiederholbar.

MerksatzEin Modellwechsel ohne Eval-Set ist keine Migration, sondern ein Austausch mit Hoffnung. Und ein Prompt, der nur mit einem Modell funktioniert, ist eine Abhängigkeit, die niemand dokumentiert hat.

Ein Gate, das nicht lügt

Am Ende steht die Frage, was das Set in der Auslieferung bewirkt. Ein Gate blockiert eine Änderung, wenn die Messung sie nicht trägt. Damit es hält, braucht es drei Eigenschaften — und eine Warnung.

Kriterien vorab — welche Größe, welche Schwelle, gemessen woran. Nach dem roten Lauf wird nicht verhandelt.
Beide Richtungen — nicht nur, dass Fehler abnehmen, sondern auch, dass Gegenfälle weiter bestehen.
Über dem Rauschen — eine Schwelle, die von normaler Schwankung ausgelöst wird, wird binnen zwei Wochen abgeschaltet.

Die Warnung betrifft die Wirkung des Gates auf das Set selbst: Sobald eine Kennzahl zum Ziel wird, verliert sie ihre Aussagekraft. Wer den Prompt so lange anpasst, bis das Set grün ist, hat auf das Set optimiert und nicht auf die Aufgabe. Das Gegenmittel ist unbequem und einfach: ein Teil der Fälle bleibt zurückgehalten und wird nicht zur Iteration benutzt.

Zurückgehaltene Fälle sind unbequem, weil sie Arbeit verdoppeln und im Alltag als Bürokratie erscheinen. Die Rechtfertigung ist einfach: Sie sind die einzige Zahl, die nach zwanzig Iterationen noch etwas über die Aufgabe sagt und nicht über das Set. Ein Verhältnis von etwa vier zu eins ist ein brauchbarer Anfang — vier Fünftel zum Iterieren, ein Fünftel unangetastet, und die zurückgehaltene Menge wird nur vor der Auslieferung angesehen.

Kurzcheck

Ein Gate blockiert bei mehr als 5 % Verschlechterung gegenüber dem letzten Lauf. In den letzten sechs Wochen hat es viermal blockiert; jedes Mal war nach Prüfung kein echter Defekt zu finden. Das Team will die Schwelle auf 15 % anheben.

Erst die Schwankung des Sets messen, dann die Schwelle darüber legen
Die Schwelle auf 15 % anheben, weil vier Fehlalarme das Gate unglaubwürdig machen
Das Gate beibehalten und Blockierungen künftig manuell freigeben können
Das Set vergrößern, damit die Messung weniger schwankt

Treffer. Genau. Vier Fehlalarme in sechs Wochen deuten darauf hin, dass 5 % innerhalb der normalen Schwankung liegen. Die Schwelle muss über dem Rauschen liegen — und wie hoch das ist, sagt eine Messung, nicht eine Verhandlung.

Zusammenfassung — gleich im Check

Du kennst jetzt die Bestandteile: das Eval-Set als Experiment mit Unsicherheit, echte Vorfälle als Quelle plus Grundlast und Gegenfälle, die Fehler-Taxonomie als Voraussetzung passender Hebel, Assertions im härtesten passenden Grad, den Modell-Prüfer mit vier bekannten Verzerrungen, temperature: 0 als Messbedingung und nicht als Wahrheitsgarant, Brüchigkeit gegenüber Formatänderungen, gepaarte Auswertung gegen Rauschen, den Modellwechsel als Zahltag und ein Gate mit vorab gesetzten Kriterien samt zurückgehaltenen Fällen.

Gleich im CheckIn den nächsten Aufgaben baust du Fallmengen, wählst Prüfungen und entscheidest über Gates. Die wiederkehrende Falle ist eine Zahl, die eine Entscheidung suggeriert, die sie nicht trägt.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität8 Primärquellen · zuletzt geprüft: 2026-09-04