# Eval-Sets und Regressionstests > Prompt-Änderungen messbar machen: das Eval-Set als Experiment, Testfälle aus echten Vorfällen, eine Fehler-Taxonomie mit passenden Hebeln, Assertions in drei Härtegraden, die Verzerrungen eines Modell-Prüfers, Brüchigkeit gegenüber Formatänderungen, Modellwechsel — und ein Gate, das nicht lügt. Track: [Prompt Engineering](https://physar.tech/learn/prompt-engineering) Kanonische Fassung: https://physar.tech/learn/prompt-engineering/prompt-testing-regression Stand: 2026-09-04 Interaktiver Teil: 9 Checks (nur im Browser) ## Eval-Sets und Regressionstests ### 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. > **Merksatz:** Eine 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. > **Merksatz:** Zwei 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. > **Merksatz:** Ein 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. > **Merksatz:** Eine 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. > **Merksatz:** Die 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. | > **Merksatz:** Ein 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. > **Merksatz:** `temperature: 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. > **Merksatz:** Notiere 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 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. > **Merksatz:** Ein 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. - [x] 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 > 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 Check:** In 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. ## Quellen - Miller, Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations, 2024 — https://arxiv.org/abs/2411.00640 - Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, NeurIPS 2023 — https://arxiv.org/abs/2306.05685 - Sclar et al., Quantifying Language Models' Sensitivity to Spurious Features in Prompt Design, ICLR 2024 — https://arxiv.org/abs/2310.11324 - Röttger et al., XSTest: A Test Suite for Identifying Exaggerated Safety Behaviours in Large Language Models, NAACL 2024 — https://arxiv.org/abs/2308.01263 - Anthropic — Define success criteria and build evaluations — https://platform.claude.com/docs/en/test-and-evaluate/develop-tests - Liu, Zhang und Liang, Evaluating Verifiability in Generative Search Engines, EMNLP 2023 Findings — https://arxiv.org/abs/2304.09848 - Laban et al., LLMs Get Lost In Multi-Turn Conversation, 2025 — https://arxiv.org/abs/2505.06120 - Zhao et al., Calibrate Before Use: Improving Few-Shot Performance of Language Models, ICML 2021 — https://arxiv.org/abs/2102.09690