Du änderst einen Prompt, um einen Fall zu reparieren, der dich gestört hat. Er ist jetzt behoben. Was du nicht siehst: Drei andere Fälle, die vorher liefen, sind durch dieselbe Änderung kaputtgegangen. Du merkst es nicht beim Testen des einen Falls, du merkst es Wochen später — von einem Kunden, nicht von dir.
Das ist der Normalzustand, solange Prompts wie Zettel behandelt werden, an denen man mal eben dreht. Dabei sind sie Code. Sie steuern Verhalten, sie haben Randfälle, sie brechen bei Änderungen. Und Code, der etwas wert ist, wird getestet. Diese Seite zeigt, wie man das auf Prompts überträgt — was dabei anders ist als bei normalem Code, und warum die naheliegende Methode nicht funktioniert.
Du testest nicht den Text, sondern Eigenschaften
Der erste Reflex ist, die Ausgabe mit einer erwarteten Ausgabe zu vergleichen. Das funktioniert bei Prompts nicht. Ein Modell formuliert denselben Inhalt jedes Mal anders, also schlägt ein Vergleich auf Textgleichheit ständig fehl, ohne dass etwas falsch wäre. Das ist der Fehler, an dem die meisten zuerst scheitern.
Stattdessen testest du Eigenschaften — was über die Ausgabe gelten muss, egal wie sie formuliert ist. Strukturelles: Ist es gültiges JSON, passt es zum Schema? Enthalten oder nicht: Kommt die geforderte Angabe vor, fehlt jedes verbotene Wort und jede personenbezogene Information? Grenzen: Länge, Format, erlaubte Werte. Und inhaltlich: Stimmt die Aussage — das beurteilt ein bewerteter Modell-Richter gegen eine Vorgabe, wie bei der Bewertung eines Archivs. Harte Eigenschaften prüfst du im Code, weiche über den Richter.
Jeder Produktionsfehler wird ein Test
Woher die Testfälle kommen, entscheidet, ob die Tests etwas taugen. Drei Quellen: repräsentative echte Eingaben, die Randfälle und Angriffsversuche, die gern übersehen werden — und vor allem jeder Fehler, der dir je in Produktion begegnet ist.
Das ist das eigentliche Regressions-Prinzip: Was einmal kaputt war, wird ein Testfall, damit es nie wieder unbemerkt kaputtgeht. Mit der Zeit wächst daraus ein Netz, das genau deine wunden Punkte abdeckt — nicht irgendeinen allgemeinen Maßstab, sondern die Fälle, die bei dir wirklich vorkommen.
Wie ich das angehe
Echte Eingaben, plus jeder Fehler, der dir je begegnet ist, plus Randfälle und Angriffsversuche. Die Sammlung ist die Messlatte.
Pro Fall notieren: welche Struktur, was muss enthalten sein, was darf nicht vorkommen, und stimmt der Inhalt. Das ist die Erwartung, gegen die geprüft wird.
Die harten Eigenschaften prüft Code zuverlässig. Die weichen — ist die Antwort sinnvoll — beurteilt ein bewerteter Modell-Richter.
Jeder Prompt-Tweak, jeder Modellwechsel, jede Parameteränderung löst den Testlauf aus. Nicht einmal am Anfang, sondern jedes Mal.
Sinkt die Quote gegenüber vorher, geht die Änderung nicht raus — egal wie gut sie sich anfühlt.
Das Modell ist nicht deterministisch
Ein Punkt, der normales Testen auf den Kopf stellt: Derselbe Prompt liefert nicht jedes Mal dieselbe Ausgabe. Ein einzelner Durchlauf ist deshalb kein Test — er kann zufällig durchgehen oder zufällig scheitern.
Die Antwort darauf ist, einen Fall mehrfach laufen zu lassen und nicht auf ein einzelnes Bestehen zu setzen, sondern auf eine Bestehensquote: Wie oft von zehn Versuchen hält die Eigenschaft? Du arbeitest mit Schwellen, nicht mit einem harten Ja oder Nein aus einem Schuss. Wer den Nicht-Determinismus ignoriert, baut Tests, die selbst zufällig sind.
Wo es in der Praxis kippt
Die Textgleichheits-Falle. Auf den genauen Wortlaut zu testen scheitert ständig grundlos. Eigenschaften prüfen, nicht Strings.
Der fehlbare Richter. Der Modell-Richter für die inhaltliche Prüfung irrt selbst. Wie bei der Archiv-Bewertung gehört er gegen menschliche Stichproben kalibriert, sonst wäscht er deine Annahmen sauber.
Der stille Modellwechsel. Ein neues, „besseres” Modell ist im Schnitt besser und auf deinen konkreten Fällen manchmal schlechter. Ohne Testlauf vor dem Wechsel merkst du die Regression erst beim Kunden.
Die Kosten des Laufens. Ein großer Testsatz bei jeder Änderung kostet Tokens und Zeit. Ein schneller Kern für jede Änderung, der volle Satz seltener — sonst testest du irgendwann gar nicht mehr.
Tests veralten. Ändert sich die Aufgabe, veralten die Fälle. Die Sammlung gehört gepflegt, sonst misst du gegen Gestern.
Was es kostet — und woran
Wie bei den strukturierten Ausgaben ist der Preis vor allem Disziplin, dazu etwas Rechenzeit fürs Laufen der Tests. Der Aufbau lohnt sich nicht ab dem ersten Prompt, aber sehr schnell ab dem Moment, in dem mehrere Leute oder mehrere Fälle an einem Prompt hängen. Spätestens vor jedem Modellwechsel zahlt er sich aus.
Der unsichtbare Gewinn ist der, den man nie sieht: die Verschlechterung, die nicht in Produktion gelangt ist, weil ein Test sie vorher gefangen hat. Wer ohne solche Tests an Prompts schraubt, spielt Schlag-die-Maus — und merkt die Treffer immer zuletzt.
Wie ein ehrlicher Einstieg aussieht
Sammle zehn bis zwanzig deiner wichtigsten echten Eingaben und jeden Fehler, der dir bisher untergekommen ist. Schreib zu jedem auf, was gelten muss. Lass sie einmal laufen, mach dann deine nächste Prompt-Änderung, und lass sie erneut laufen. Mit hoher Wahrscheinlichkeit siehst du beim ersten Mal eine Regression, die du sonst übersehen hättest. Genau dieser Moment überzeugt mehr als jedes Argument.
Worauf du achtest, wenn dir das jemand baut
- Wird auf Eigenschaften geprüft, nicht auf Textgleichheit? Letzteres ist das Warnsignal, dass jemand LLMs wie normale Funktionen behandelt.
- Werden echte Fehler zu Testfällen, oder bleibt es bei Schönwetter-Beispielen?
- Läuft der Test auch bei einem Modellwechsel, nicht nur bei Prompt-Änderungen?
- Wird der Nicht-Determinismus über eine Bestehensquote behandelt, statt über einen einzelnen Lauf?
- Ist der Richter kalibriert, und ist der Testsatz gepflegt?
Die inhaltliche Prüfung kannst du sofort mit einem Richter-Prompt anlegen. Dieser nimmt eine Ausgabe und deine Anforderungen und urteilt streng:
Du prüfst, ob die Ausgabe eines anderen KI-Schritts bestimmte Eigenschaften erfüllt.
Ich gebe dir: die EINGABE, die AUSGABE und eine Liste von ANFORDERUNGEN.
Prüfe jede Anforderung einzeln und urteile streng:
- Muss-enthalten: ist es vorhanden?
- Darf-nicht-enthalten (verbotene Wörter, erfundene Angaben, personenbezogene Daten): verletzt?
- Form / Länge / erlaubte Werte: eingehalten?
- Inhaltlich korrekt (gegen die Eingabe oder eine Referenz): ja / teilweise / nein?
Urteile nur anhand des Gegebenen, nicht aus eigenem Wissen.
Gib je Anforderung aus: erfüllt / verletzt + kurze Begründung. Am Ende: BESTANDEN, wenn ALLE
Muss-Anforderungen erfüllt und KEIN Verbot verletzt ist, sonst DURCHGEFALLEN.Du schraubst an einem Prompt und weißt nie, ob du woanders etwas kaputt machst? Dann reden wir über die zehn Eingaben, die bei dir am wichtigsten sind — daraus wird ein erster Testsatz, der dir vor dem Ausrollen sagt, ob eine Änderung trägt oder heimlich schadet.