Der Artikel Prompt-Dokumentation und Versionierung im Team hat gezeigt, wie aus Prompt-Chaos ein sauberes Schema wird: v1.0, Changelog, v1.1. Was er offenlässt, ist die eigentlich entscheidende Frage: Woher weiss man überhaupt, dass v1.1 besser ist als v1.0? «Fühlt sich runder an» ist kein Messwert. Ohne Prüfmethode bleibt jede Versionierung Bauchgefühl mit einer Versionsnummer davor – Verwaltung ohne Qualitätssicherung.
1. Warum „fühlt sich besser an" keine Qualitätsmessung ist
Wer eine neue Prompt-Version an zwei oder drei zufälligen Beispielen ausprobiert und den Eindruck hat, die Antwort klinge runder, hat etwas beobachtet – aber nichts gemessen. Drei Probleme stecken in diesem Vorgehen: Erstens sind Sprachmodelle nicht deterministisch, dieselbe Version kann bei zwei Durchläufen unterschiedlich gute Antworten liefern. Zweitens neigt man dazu, genau die Beispiele auszuwählen, bei denen die neue Version gut aussieht – unbewusst, aber systematisch. Drittens verschwindet das Ergebnis nach dem Test wieder aus dem Kopf; beim nächsten Vergleich fängt man bei null an.
Eine Qualitätsmessung braucht drei Dinge, die dem Bauchgefühl fehlen: dieselben Testfälle bei jedem Vergleich, ein festgehaltenes Ergebnis statt eines flüchtigen Eindrucks, und ein Kriterium, an dem «besser» tatsächlich festgemacht wird. Das klingt nach Aufwand – ist es aber nicht, wenn man klein anfängt.
2. Ein einfaches Testset bauen
Ein Testset ist nichts anderes als eine feste Sammlung von 5 bis 10 typischen Beispiel-Anfragen, die bei jedem Versionsvergleich unverändert bleiben. Die Auswahl entscheidet über die Aussagekraft:
- Typische Fälle: die Anfragen, die im Alltag tatsächlich am häufigsten vorkommen – nicht die exotischsten Sonderfälle.
- Ein bis zwei Grenzfälle: eine ungewöhnlich kurze Anfrage, eine mit fehlenden Angaben, eine mit einer Sonderregel. Genau dort brechen Prompts am ehesten.
- Reale Formulierungen: möglichst aus echten, anonymisierten Fällen – keine künstlich sauberen Testsätze, die im Alltag so nie vorkommen.
Das Testset wird einmal gebaut und dann wiederverwendet, unverändert, bei jedem Versionsvergleich. Nur so ist ein Vergleich zwischen v1.0 und v1.1 überhaupt fair – beide Versionen bearbeiten exakt dieselben Anfragen.
3. Manuelles A/B: alte vs. neue Version an denselben Testfällen
Der einfachste Test überhaupt: Beide Versionen laufen nacheinander gegen dasselbe Testset, die Ausgaben werden nebeneinandergelegt – ohne zu wissen, welche Antwort von welcher Version stammt. Das «Blind»-Element ist wichtig: Wer weiss, dass Antwort B von der neuen, mit Aufwand überarbeiteten Version stammt, ist unbewusst voreingenommen, sie besser zu bewerten.
Testfall 1: [Anfrage-Text] Antwort A: [Ausgabe Version 1] Antwort B: [Ausgabe Version 2] Besser: A / B / gleichwertig — Begründung: ... Testfall 2: ...
Für 5 bis 10 Testfälle ist dieser Vergleich in 20 bis 30 Minuten erledigt – von einer Person, die die Aufgabe kennt, aber nicht weiss, welche Version welcher Buchstabe ist. Das Ergebnis ist kein Prozentwert, sondern eine klare Tendenz: Gewinnt die neue Version deutlich, in etwa der Hälfte der Fälle oder gar nicht?
4. LLM-as-Judge ohne Data-Science-Team
Sobald das Testset wächst oder der Vergleich regelmässig wiederholt werden soll, wird das manuelle Durchlesen mühsam. Hier hilft ein zweites Sprachmodell als Bewerter – in der Fachsprache «LLM-as-Judge» genannt. Das Prinzip: Ein Modell erhält die Anfrage, beide Antworten (wieder ohne Kennzeichnung, welche Version welche ist) und ein kurzes Bewertungskriterium, und liefert eine strukturierte Einschätzung zurück.
Du bewertest zwei Antworten auf dieselbe Anfrage. Kriterium: [z. B. "Beantwortet die Frage vollständig, hält sich an maximal 150 Wörter, Ton: sachlich-freundlich"]. Anfrage: [Text] Antwort A: [Text] Antwort B: [Text] Welche Antwort erfüllt das Kriterium besser: A, B oder gleichwertig? Begründung in maximal zwei Sätzen.
Wichtig ist die Beschränkung: Ein LLM-as-Judge ersetzt keine fachliche Prüfung durch eine Person, die die Aufgabe wirklich versteht. Er ist ein Vorfilter, der bei zehn, zwanzig oder fünfzig Testfällen die eindeutigen Fälle schnell aussortiert – sodass ein Mensch nur noch die knappen oder strittigen Fälle selbst ansieht. Das reduziert den manuellen Aufwand, ohne die Kontrolle vollständig abzugeben.
5. Wann sich eine neue Version lohnt – und wann Perfektionismus nur Zeit kostet
Nicht jede kleine Verbesserung rechtfertigt eine neue Prompt-Version. Zwei Leitfragen helfen bei der Entscheidung:
| Frage | Konsequenz |
|---|---|
| Gewinnt die neue Version im A/B-Vergleich klar (deutlich mehr als die Hälfte der Testfälle)? | Version übernehmen, Changelog-Eintrag schreiben |
| Ist das Ergebnis knapp oder uneinheitlich (mal besser, mal schlechter)? | Alte Version behalten, Änderung verwerfen oder gezielter nacharbeiten |
| Behebt die Änderung ein konkretes, beobachtetes Problem (z. B. zu lange Antworten)? | Version übernehmen, auch bei kleinem Testset-Vorteil – der Praxisnutzen zählt mehr als die Testset-Mehrheit |
Der Umkehrschluss ist genauso wichtig: Eine dritte, vierte oder fünfte Überarbeitung, die im Test keinen messbaren Unterschied mehr zeigt, ist Perfektionismus, kein Qualitätsgewinn. Sobald ein Prompt im Testset konstant gut abschneidet und im Alltag keine Beschwerden auslöst, ist der Punkt erreicht, an dem weiteres Feilen Zeit kostet, die anderswo mehr wert ist.
6. Nächste Schritte
Ein Testprozess lohnt sich nicht für jeden Prompt gleichermassen – am meisten bringt er bei den Prompts, die im Team am häufigsten verwendet werden und bei denen Qualitätsschwankungen am ehesten auffallen. Wer noch keine dokumentierte Bibliothek hat, findet den Einstieg in Prompt-Dokumentation und Versionierung im Team. Wer bereits testet und dabei wiederkehrende Muster sammeln will, findet Struktur dafür im Prompt Pattern Catalog – und vermeidet mit Top 5 Fehler im Prompt Engineering gleich die häufigsten Stolpersteine, die ein Testset ohnehin aufdecken würde.
Für Teams, die einen leichtgewichtigen Testprozess für ihre wichtigsten Prompts aufsetzen wollen – vom Testset bis zum LLM-as-Judge-Workflow – bietet CuonzTech ThinkLab ein massgeschneidertes Workshop-Format für Schweizer KMU an.