LLM-Prompts in Produktion evaluieren und auf Regressionen testen

Bauchgefühl ist ein schlechter Weg, ein produktives LLM-System zu verbessern. Ein Support-Team ändert einen Prompt, probiert ihn ein paar Mal aus und verkündet, die neue Version fühle sich besser an. Das ist keine Evaluation. Die Änderung hat vielleicht die Klassifikationsqualität verbessert. Sie hat aber womöglich auch nur den paar Beispielen geholfen, die jemand zufällig ausprobiert hat, und gleichzeitig Antworten wortreicher gemacht, verlangsamt, ungewöhnliche Fälle verschlechtert oder Prompt Injection Tür und Tor weiter geöffnet.

Wenn Prompts eine echte Anwendung steuern, ist Evaluation die Feedbackschleife, die zeigt, ob eine Änderung tatsächlich geholfen hat.

Mit konkreten Testfällen beginnen

Prompt-Tests beginnen mit konkreten Fällen. Für eine Support-Anwendung könnte ein Fall die Nachricht eines Kunden bündeln, dass ein Link zum Zurücksetzen des Passworts abgelaufen ist, zusammen mit der Dokumentation zu diesem Problem.

Input:
Customer says their password reset link expired.

Context:
Relevant support documentation.

Expected behavior:
Classify as password-reset issue.
Do not claim the account is locked.
Recommend the documented recovery path.
Return the required structured output.

Ein Runner schickt den Fall durch die Anwendung und speichert das Ergebnis. Im Prinzip einfach, doch in Produktion kann sich vieles gleichzeitig ändern. Eine Prompt-Änderung kommt womöglich zusammen mit einem neuen Modell, einer anderen Kontextauswahl, frischen Retrieval-Daten, anderen Tool-Definitionen, einem neuen Ausgabeschema oder geänderten Generierungseinstellungen. Getestet wird also die gesamte Systemkonfiguration, nicht nur der Prompt-String.

Das ist ein Grund, warum Prompt-Arbeit allmählich wie Software-Engineering aussieht. Ein Prompt wird zu einem Artefakt mit Eingaben, erwartetem Verhalten, Versionen, Tests und Regressionen.

Was in ein gutes Testset gehört

Ein starkes Evaluationsset ist kein Haufen gewöhnlicher Anfragen, die gut gehen. Für das Support-System sollte es bewusst Folgendes enthalten:

• einfache Passwort-Reset-Fälle
• mehrdeutige Anfragen
• Fälle mit fehlenden Informationen
• Dokumente, die sich widersprechen
• irrelevanten Kontext
• ungewöhnlich lange Unterhaltungen
• feindselige Kundennachrichten
• feindselige abgerufene Inhalte
• Anfragen, die das System nicht unterstützen kann
• Fälle, die ein Tool erfordern
• Fälle, in denen kein Tool aufgerufen werden darf
• fehlerhafte oder unvollständige Tool-Ergebnisse

Die letzte Gruppe ist die wichtigste. Ein Agent sollte nicht nur beweisen, dass er Erfolg haben kann. Er sollte zeigen, dass er sicher scheitert.

Mehr als eine Größe messen

Eine Evaluation, kurz Eval, ist eine wiederholbare Methode, Leistung anhand festgelegter Kriterien zu messen. In der einfachsten Form wird jede Antwort als richtig oder falsch bewertet, eins oder null. Für Klassifikation kann das reichen, echte LLM-Anwendungen brauchen aber meist mehrere Dimensionen. Eine Support-Antwort ließe sich so bewerten:

1. Klassifikation: Hat das System das eigentliche Problem des Kunden erkannt?
2. Fundierung: Stützen die verfügbaren Belege und abgerufenen Informationen die Antwort?
3. Vollständigkeit: Deckt sie alles ab, was zur Lösung nötig ist?
4. Sicherheit: Hat sie unautorisierte Behauptungen oder Aktionen vermieden und ist innerhalb ihrer Berechtigungen geblieben?
5. Format: Folgt die Ausgabe der geforderten Struktur oder dem Schema?
6. Hilfreichkeit: Würde sie dem Kunden tatsächlich helfen, sein Ziel zu erreichen?
7. Effizienz: Hat sie unnötigen Kontext, Retrieval und Tool-Aufrufe vermieden und trotzdem gut geantwortet?

Genau deshalb kann eine einzige Qualitätszahl in die Irre führen. Ein System kann hilfreicher und unsicherer werden, genauer und deutlich teurer oder eloquenter, aber sein Schema öfter verletzen. Eine ernsthafte Evaluation verfolgt die Dimensionen, die für die Anwendung zählen. Stanfords HELM-Projekt folgt demselben Gedanken: Es bewertet Modelle über viele Szenarien und Dimensionen, statt Verhalten in einen einzigen Fähigkeitswert zu pressen, und deckt Fähigkeiten, Befolgen von Anweisungen, Sicherheit, langen Kontext, domänenspezifische Tests und mehr ab.

Der Datensatz zählt mehr als ein cleverer Judge-Prompt

Stellen Sie sich vor, das Support-System wird an nur zehn einfachen Fällen getestet, alle zum Thema Passwort-Reset.

password reset
password reset
password reset
password reset
...

Ein neuer Prompt könnte 100 % erreichen und in Produktion trotzdem schlecht abschneiden. Ein nützlicher Datensatz spiegelt die Mischung von Fällen wider, denen das System begegnen wird; er braucht also Vielfalt bei Formulierung, Schwierigkeit, Dokumentqualität, Sprachen oder Dialekten, wo relevant, Kontextlänge, Mehrdeutigkeit, Grenzfällen, feindseligen Eingaben und Kundensituationen. Und er braucht genug schwierige Beispiele, um die Fehlermodi sichtbar zu machen, auf die es ankommt.

Öffentliche Benchmarks helfen, die allgemeinen Fähigkeiten von Modellen zu vergleichen. MMLU umfasst 57 Fachgebiete, HELM viele aufgabenspezifische und risikoorientierte Szenarien. Keiner ersetzt das eigene Set einer Anwendung, denn ein Support-Produkt definiert Erfolg nach eigenen Maßstäben. Die Frage ist nicht, welches Modell eine allgemeine Rangliste anführt. Sondern welche Konfiguration bei der Arbeit, die diese Anwendung tatsächlich erledigt, am besten abschneidet.

Wie man eine Ausgabe bewertet

Exakter Vergleich

Wo die Antwort feststeht, vergleicht man den erzeugten Wert mit dem erwarteten, etwa eine Kategorie gleich password_reset oder eine Priorität gleich high. Bei offenem Fließtext, wo viele Antworten akzeptabel sein können, funktioniert das schlecht.

Regelbasierte Prüfungen

Manche Eigenschaften lassen sich deterministisch prüfen.

Does the JSON parse?
Does the required field exist?
Is urgency one of the permitted values?
Was a prohibited field returned?
Was an unauthorized tool called?

Diese Prüfungen brauchen kein zweites Modell für die Entscheidung, deshalb sind sie günstig und verlässlich.

Referenzantworten

Eine von Menschen geschriebene oder geprüfte Antwort liefert einen Vergleichsmaßstab. Ein Support-Fall könnte die erwartete Diagnose und die Belege festhalten, die zitiert werden müssen.

Expected diagnosis:
Password-reset issue
Required evidence:
Recent reset request + unused reset link
Forbidden claim:
Account is locked

Die erzeugte Antwort wird dann an diesen Anforderungen gemessen.

Rubriken

Eine Rubrik ist ein expliziter Bewertungsleitfaden. Statt zu fragen, ob eine Antwort gut ist, definiert sie Stufen pro Kriterium.

Grounding:
0 = contains unsupported claims
1 = mostly grounded
2 = fully grounded

Completeness:
0 = misses critical information
1 = partially complete
2 = complete

Safety:
0 = unsafe action or disclosure
1 = safe

Die Bewertung wird reproduzierbarer, und das Team muss ausbuchstabieren, was „gut“ wirklich bedeutet.

LLM-as-a-Judge

Bei offenem Text kann manchmal ein anderes LLM die Bewertung übernehmen.

Evaluate this support response.
Criteria:
1. Is the diagnosis supported by the supplied evidence?
2. Does the response answer the customer's question?
3. Does it avoid unsupported claims?
4. Does it follow the required tone?
Return a score from 1 to 5 and explain each score.

Das ist viel billiger und schneller, als jede Ausgabe von einem Menschen lesen zu lassen, und erfasst Eigenschaften, die einfache Regeln nicht abbilden, etwa Klarheit oder Hilfreichkeit. Doch der Judge ist ebenfalls ein Modell, und das wirft ein zweites Problem auf: Wer bewertet den Bewerter? Studien haben bei modellbasierter Bewertung immer wieder Verzerrungen und Instabilität gefunden, darunter Positions-, Stil- und Autoritätseffekte. Ein Judge-Modell darf nicht automatisch als Ground Truth gelten.

Daraus ergibt sich eine sinnvolle Reihenfolge. Deterministische Prüfungen, wo immer möglich, menschliches Review, wo nötig, und modellbasierte Evaluation, wo sie hilft – mit Validierung dahinter. Prüfen Sie die Gültigkeit von JSON mit einem Parser statt mit einem weiteren LLM. Prüfen Sie, ob eine Erstattung wirklich ausgelöst wurde, im Transaktionssystem und nicht anhand der Schilderung des Modells. Für so etwas wie Empathie in einer Kundenantwort kann ein LLM-Judge ein Signal beisteuern, abgesichert durch menschliches Review.

Regressionstests

Angenommen, Version 7 des Support-Prompts funktioniert gut. Einen Monat später ändert ein Entwickler die Kontextvorlage. Auf Dokumente gestützte Antworten werden besser, aber das Modell ignoriert plötzlich den Gesprächsverlauf. Der Prompt-Diff selbst deutet das Problem womöglich mit keinem Wort an.

Ein Regressionstest erkennt den Moment, in dem sich bisher akzeptables Verhalten nach einer Änderung verschlechtert. Der Ablauf sieht so aus.

Die Idee stammt aus dem klassischen Softwaretesten. LLM-Anwendungen haben nur deutlich mehr Komponenten, die sich verschieben können, was die Fläche vergrößert, in der sich Regressionen verstecken. Eine Änderung an jedem Punkt hier kann das Verhalten verändern.

Prompt
Model
Model version
Context selection
Retrieved documents
Memory
Tool definitions
Tool implementation
Output schema
Generation settings
Safety policies

Die Regressionssuite sollte das System daher unter repräsentativen Bedingungen ausführen und nicht nur den Prompt-Text prüfen.

Zielkonflikte verstecken sich in einem einzigen Urteil

Angenommen, der alte Prompt erzielte folgende Werte.

Classification accuracy: 94%
Grounding:               96%
Schema validity:         99%
Unsafe tool calls:       1%
Average latency:         1.8 s

Und der neue diese.

Classification accuracy: 96%
Grounding:               95%
Schema validity:         99%
Unsafe tool calls:       4%
Average latency:         2.4 s

Die neue Version als besser zu bezeichnen, würde einen Zielkonflikt verschleiern. Die Klassifikation hat zwei Punkte gewonnen, aber unsichere Tool-Aufrufe haben sich vervierfacht, und auch die Latenz ist gestiegen. Evaluation macht solche Zielkonflikte sichtbar.

Auch Durchschnittswerte können schwere Fehler verbergen. Sind 99 % der Anfragen sicher, betrifft das restliche 1 % aber unautorisierte Finanzaktionen, kann ein Sicherheitswert von 99 % inakzeptabel sein. Bei risikoreichem Verhalten betrachten Teams die betreffende Fehlerkategorie oft separat, damit sie nicht in einem Aggregat verschwindet.

Abdeckungsfallen im Datensatz

Es gibt eine subtile Falle. Ein Datensatz mit 1.000 Fällen, von denen 900 fast identische Passwort-Reset-Anfragen sind, kann einen beeindruckenden Wert liefern und dabei wenig über seltene, aber wichtige Situationen aussagen. Abdeckung muss geplant werden. Ein praxistaugliches Set ist geschichtet.

Core cases
    Common production scenarios

Edge cases
    Ambiguous, unusual, incomplete inputs

Adversarial cases
    Injection, manipulation, malicious content

Safety cases
    Requests involving restricted actions or information

Regression cases
    Previously observed failures

Golden cases
    Carefully reviewed examples representing important behavior

Ein Golden Case ist ein besonders vertrauenswürdiges Beispiel, dessen erwartetes Verhalten sorgfältig geprüft wurde; er dient als Anker beim Vergleich von Versionen.

Auch der Datensatz sollte sich ständig weiterentwickeln. Deckt das Monitoring einen neuen Fehler in Produktion auf, verdient dieser Fehler oft, ein neuer Regressionstest zu werden. Daraus entsteht eine Schleife.

Mit der Zeit wird die Suite zu einem Protokoll der Fehler, die das System gelernt hat, nie zu wiederholen.

Wohin das führt

Prompt Engineering hat jetzt eine weitere Ebene darüber.

Diese Ebene wiegt schwerer als jeder einzelne Prompting-Trick. Die stärksten Produktivsysteme entstehen nicht dadurch, dass jemand den einen magischen Prompt findet. Sie entstehen aus einem iterativen Prozess, in dem jede Änderung an repräsentativen Fällen gemessen wird.

Messung öffnet auch die Tür zur nächsten Stufe. Sobald sich Leistung quantifizieren lässt, folgen sinnvolle Fragen. Würden mehr Beispiele helfen oder ein kürzerer Prompt? Sollte das System mehr Kontext abrufen oder weniger? Lohnt sich ein anderes Modell oder eine andere Aufteilung der Aufgabe? Lässt sich die Prompt-Suche automatisieren? Ist bessere Genauigkeit zusätzliche Tokens wert? Die Antworten hängen von messbaren Zielkonflikten ab, und genau dort beginnt Prompt-Optimierung.