„Es sah gut aus, als ich es ausprobiert habe“ ist der Weg, auf dem die meisten Prompt-Regressionen in die Produktion gelangen. Prompt-Tests und -Evaluierung ersetzen das durch Belege: eine feste Menge von Eingaben, eine Definition einer korrekten Ausgabe und eine Prüfung, die bei jeder Änderung des Prompts läuft.
Die beiden Begriffe überlappen sich. Evaluierung heißt, zu messen, wie gut ein Prompt oder seine Ausgabe ist. Testen heißt, diese Messungen automatisch auszuführen und zu scheitern, wenn ein Schwellenwert verfehlt wird.
Zwei Dinge, die Sie evaluieren können
Den Prompt selbst. Ist er so, wie er geschrieben ist, klar, vollständig, konsistent und sicher? Das ist statische Analyse. Sie braucht keinen Modellaufruf, ist also sofort, kostenlos und liefert jedes Mal dasselbe Ergebnis.
Die Ausgabe des Modells. Ist die Antwort bei diesem Prompt und dieser Eingabe korrekt? Dafür braucht es Modellaufrufe und eine Möglichkeit, das Ergebnis zu beurteilen.
Sie fangen unterschiedliche Probleme ab, und ein guter Prozess nutzt beide. Statische Prüfungen laufen bei jedem Tastendruck und jedem Commit. Die Ausgabeevaluierung läuft, wenn eine Änderung das Verhalten beeinflussen könnte.
Schicht 1: statische Prüfungen des Prompts
Eine statische Prüfung liest den Prompt-Text und sucht nach bekannten Mängeln:
- Kein genanntes Ziel oder kein Ausgabeformat.
- Vage Wörter und Größenangaben ohne Zahlen.
- Anweisungen, die einander widersprechen oder wiederholen.
- Template-Variablen, die nicht abgegrenzt sind.
- Injection-Formulierungen, Zugangsdaten oder personenbezogene Daten.
- Token-Zahl über einem Budget.
Das tut die PromptFlowEngine-Prompt-Evaluierung. Der Score ist 100 minus eine feste Strafe pro Fund (30 für kritisch, 10 für Warnung, 3 für Info), gedeckelt auf 50, sobald etwas kritisch ist, mit derselben Arithmetik für jede der acht Dimensionen. Weil die Formel veröffentlicht ist, lässt sich eine Score-Änderung stets auf einen bestimmten Fund zurückführen.
Ein statischer Score sagt Ihnen nicht, ob die Antwort des Modells richtig ist. Er sagt Ihnen, ob der Prompt dem Modell eine faire Chance gibt.
Schicht 2: ein Testset
Ein Testset ist eine Liste von Eingaben mit Erwartungen. Fangen Sie klein an.
| Art des Falls | Warum |
|---|---|
| Typische Eingaben | Bestätigt, dass der Hauptpfad funktioniert |
| Randfälle | Leer, sehr lang, falsche Sprache, fehlerhaft formatiert |
| Adversariale Eingaben | Versuche, Anweisungen zu überschreiben |
| Frühere Fehler | Jeder gefundene Fehler wird zu einem dauerhaften Test |
Zwanzig gut gewählte Fälle schlagen zweihundert nahezu identische. Entnehmen Sie sie wenn möglich echtem Traffic, ohne personenbezogene Daten.
Schicht 3: entscheiden, ob eine Ausgabe besteht
Verwenden Sie die günstigste Methode, die die Eigenschaft beurteilen kann.
Code-Assertions. Deterministisch und kostenlos. Verwenden Sie sie, wo immer möglich.
- Lässt sich als JSON parsen und passt zum Schema.
- Enthält eine bestimmte Zeichenfolge oder enthält sie nicht.
- Länge innerhalb der Grenzen.
- Label entspricht dem erwarteten Label.
- Numerische Antwort innerhalb der Toleranz.
Referenzvergleich. Vergleich mit einer bekannten guten Antwort per exakter Übereinstimmung oder Ähnlichkeitsmaß. Geeignet für Extraktion und Klassifikation, schwach für offenes Schreiben.
Modellbewertete Evaluierung. Ein zweites Modell beurteilt die Ausgabe anhand einer Rubrik. Nutzen Sie sie für Qualitäten, die Code nicht prüfen kann: Treue zu einer Quelle, Tonfall, Vollständigkeit.
You are grading an answer against a source document.
Does the answer contain any claim not supported by the source?
Reply with a JSON object: {"unsupported_claims": [string], "pass": boolean}.
<source>{{source}}</source>
<answer>{{answer}}</answer>
Modell-Grader sind selbst Prompts, mit eigenen Fehlermodi. Beschränken Sie jede Rubrik auf eine Frage, fordern Sie die Belege vor dem Urteil und prüfen Sie den Grader gegen eine Stichprobe menschlicher Urteile, bevor Sie ihm vertrauen.
Menschliche Prüfung. Der Referenzstandard und der teuerste. Nutzen Sie sie, um die automatischen Methoden zu kalibrieren und eine Stichprobe der Produktionsausgabe zu prüfen.
Metriken, die sich zu verfolgen lohnen
| Metrik | Was sie Ihnen sagt |
|---|---|
| Bestehensquote | Anteil der Testfälle, die die Erwartungen erfüllen |
| Formatgültigkeit | Anteil der Ausgaben, die sich parsen lassen |
| Treue | Anteil der Antworten, die vom gelieferten Kontext gestützt werden |
| Ablehnungsgenauigkeit | Lehnt ab, was abzulehnen ist, beantwortet, was zu beantworten ist |
| Konsistenz | Übereinstimmung über wiederholte Läufe einer Eingabe |
| Tokens und Latenz | Kosten der Qualität, die Sie erhalten |
Geben Sie die Bestehensquote mit der Fallzahl an. „90 %“ bei 10 Fällen ist ein Fehlschlag.
Umgang mit Nichtdeterminismus
Derselbe Prompt und dieselbe Eingabe können unterschiedliche Ausgaben erzeugen. Berücksichtigen Sie das:
- Setzen Sie die Temperatur für Aufgaben, die Konsistenz brauchen, niedrig.
- Führen Sie jeden Fall mehrmals aus und berichten Sie die Bestehensquote, nicht ein einzelnes Ergebnis.
- Prüfen Sie Eigenschaften („nennt die Rückerstattungsfrist“) statt exakten Texts.
- Fixieren Sie die Modellversion und führen Sie die Suite erneut aus, wenn sie sich ändert.
Regressionstests in der CI
Tests schützen Sie nur, wenn sie automatisch laufen.
Bei jedem Commit: statische Prüfungen. Sie sind schnell und brauchen keinen API-Schlüssel. Das Prompt-Test-Gate lässt einen Pull Request scheitern, wenn eine Prompt-Datei unter einen Mindest-Score fällt, ein Token-Limit überschreitet oder einen kritischen Fund wie einen geleakten Schlüssel enthält.
- run: promptflow check "prompts/**/*.md" --min-score 70 --max-tokens 1500
Bei Änderungen an einem Prompt oder Modell: das Ausgabe-Testset, mit einem Schwellenwert für die Bestehensquote.
Nach Zeitplan: das vollständige Set gegen das Live-Modell, um anbieterseitige Änderungen abzufangen.
PromptFlowEngine deckt das erste davon ab. Es führt keine Prompts gegen ein Modell aus; die Ausgabeevaluierung braucht Ihren eigenen Test-Runner und Modellzugriff.
Zwei Versionen vergleichen
Wenn Sie zwischen Entwürfen wählen, vergleichen Sie sie mit denselben Eingaben und sehen Sie sich an, was sich geändert hat, nicht nur die Summen: welche Fälle von bestanden auf durchgefallen wechselten, wie sich die Tokens bewegten und ob neue Probleme hinzukamen. Die Vergleichsansicht im Arbeitsbereich meldet die Unterschiede bei Qualität, Tokens und Kosten zwischen zwei Prompts und listet die Funde auf, die jede Version behebt oder einführt.
Ein minimaler Prozess für den Anfang
- Führen Sie die statische Prüfung aus und beheben Sie die Warnungen.
- Schreiben Sie 20 Testfälle mit Erwartungen.
- Fügen Sie Code-Assertions für Format und erforderlichen Inhalt hinzu.
- Halten Sie die Ausgangs-Bestehensquote fest.
- Machen Sie Pull Requests von der statischen Prüfung abhängig.
- Führen Sie das Testset erneut aus, wenn sich Prompt oder Modell ändern.
Wie Sie diese Ergebnisse zur Verbesserung eines Prompts nutzen, steht unter Prompt-Optimierung. Zur Ordnung von Versionen und Ergebnissen siehe Prompt-Verwaltung.