A/B-Tests für Prompts in Produktion
Kontrollierte Experimente mit Prompt-Versionen auf echtem Traffic. Anfragen aufteilen, Qualität messen, Gewinner wählen.
Der Prompt wurde überarbeitet. Ist er wirklich besser?
Der neue Prompt sieht sauberer aus, behandelt Randfälle besser und verbraucht weniger Tokens. Im Playground mit einem Dutzend Beispielen getestet — scheint besser.
Aber „scheint besser bei 12 Beispielen" ist nicht dasselbe wie „performt besser bei 10.000 echten Anfragen." Prompts interagieren mit echtem Nutzer-Input auf Weisen, die Playground-Tests nicht vorhersagen können. Ein Prompt, der für Support-Tickets schärfer ist, könnte bei Abrechnungsfragen halluzinieren.
Der einzige Weg es zu wissen: auf echtem Traffic testen. Genau das machen Prompt-Experimente.
Warum A/B-Tests für Prompts wichtig sind
Prompts sind Code. Sie driften, regredieren und interagieren mit Modell-Updates auf überraschende Weise. Wenn ein Anbieter eine neue Modellversion ausliefert, könnte der sorgfältig getunte Prompt sich anders verhalten — und ohne Messung bleibt das unbemerkt.
Die meisten Teams:
- Ausliefern und hoffen — Neuen Prompt pushen, auf Beschwerden warten, das Beste hoffen.
- In der Sandbox testen — Eine Handvoll Beispiele ausprobieren, Ergebnisse anschauen, fertig.
Beides gibt keine Sicherheit. A/B-Tests auf Produktions-Traffic liefern echte Metriken: Antwortqualität, Latenz-Auswirkung, Kosten-Delta und Erfolgsraten über die reale Nutzerverteilung.
Wie Prompt-Experimente in Grepture funktionieren
Greptures Prompt-Verwaltung unterstützt Experimente nativ. So funktioniert es:
1. Zwei oder mehr Prompt-Versionen veröffentlichen
Jeder Prompt in Grepture hat Versionen. Eine veröffentlichte v3 (der aktuelle Produktions-Prompt) und eine veröffentlichte v4 (der Kandidat). Beide müssen veröffentlicht sein — Entwürfe können nicht an Experimenten teilnehmen.
2. Experiment starten
Im Prompt-Editor das Experiment-Panel öffnen und Varianten konfigurieren:
- Zu testende Versionen auswählen (z.B. v3 und v4)
- Traffic-Gewichte setzen (z.B. 80% auf v3, 20% auf v4)
- Gewichte müssen 100% ergeben
- Mehr als zwei Varianten möglich
3. Traffic wird automatisch geroutet
Wenn die Anwendung einen Prompt per Slug auflöst, weist Grepture jede Anfrage zufällig einer Variante zu — basierend auf den konfigurierten Gewichten. Keine Code-Änderung nötig. Wer bereits Prompt-Slugs nutzt, bekommt Experimente transparent.
// Der Code ändert sich nicht — Experimente passieren am Gateway
const response = await client.chat.completions.create({
model: "gpt-4o",
messages: [
{ role: "system", content: "{{grepture:support-assistant}}" },
{ role: "user", content: userMessage },
],
});
Der Slug support-assistant wird je nach Experiment-Gewichten in v3 oder v4 aufgelöst. Für Anfragen, die nicht am Experiment teilnehmen sollen, eine explizite Version pinnen: {{grepture:support-assistant@3}}.
4. Qualität wird automatisch gemessen
Beim Start eines Experiments erstellt Grepture automatisch einen Relevanz-Evaluator, falls keiner für diesen Prompt existiert. Das ist eine LLM-as-a-Judge-Eval, die jede Antwort auf einer Skala von 0 bis 1 bewertet.
Eigene Evaluatoren — für Ton, Genauigkeit, Sicherheit oder andere Kriterien — können zusätzlich hinzugefügt werden.
5. Ergebnisse in Echtzeit beobachten
Das Experiment-Dashboard zeigt Metriken pro Variante, die alle 30 Sekunden aktualisiert werden:
- Anfragen — Wie viele Anfragen jede Variante bedient hat
- Durchschn. Latenz — Antwortzeit pro Variante
- Durchschn. Kosten — Kosten pro Anfrage
- Erfolgsrate — Anteil fehlerfreier Antworten
- Eval-Scores — Durchschnittliche Qualitätsbewertung pro Evaluator, farbcodiert: Grün (>0,8), Gelb (0,5–0,8), Rot (<0,5)
Die Variante mit dem höchsten Eval-Score bekommt ein Pokal-Icon und einen „Aktivieren & Beenden"-Button.
6. Gewinner wählen
Sobald genug Daten vorliegen, die gewinnende Version aktivieren. Grepture setzt sie als aktive Version und beendet das Experiment. Aller Traffic kehrt zur einzelnen aktiven Version zurück.
Tipps für gute Experimente
Auf ausreichend Traffic warten. Ein paar Dutzend Anfragen reichen nicht. Als Faustregel: mindestens einige hundert Anfragen pro Variante abwarten.
Eine Sache gleichzeitig ändern. Prompt-Text und Modell nicht im selben Experiment ändern — sonst ist unklar, welche Änderung das Ergebnis beeinflusst hat.
Versions-Pins für sensible Anfragen nutzen. Anfragen, die immer den aktuellen Produktions-Prompt verwenden müssen (z.B. Compliance-kritische Flows), mit slug@version-Syntax pinnen.
Kosten neben Qualität prüfen. Eine Variante, die 2% besser bei Relevanz abschneidet, aber 40% mehr pro Anfrage kostet, ist möglicherweise nicht lohnend. Das Dashboard zeigt beides.
Von PromptOps zu datengetriebenen Prompts
Prompt-Experimente schließen den PromptOps-Kreislauf. Prompts versionieren, serverseitig deployen, und jetzt auf echtem Traffic testen bevor man sich festlegt. Der gleiche Workflow, den Software-Engineers für Feature-Flags und Canary-Deploys nutzen — angewandt auf Prompts.
Die Gateway-Architektur macht das ohne SDK-Änderungen oder Application-Deploys möglich. Weil Grepture Prompts auf der Proxy-Ebene auflöst, können Experimente komplett über das Dashboard gestartet, beobachtet und beendet werden.
Wichtigste Erkenntnisse
- A/B-Tests auf echtem Traffic eliminieren Rätselraten — Qualität, Kosten und Latenz über die reale Nutzerverteilung messen.
- Keine Code-Änderungen nötig — wer Prompt-Slugs nutzt, bekommt Experimente transparent auf Gateway-Ebene.
- Automatisch erstellte Evaluatoren bewerten jede Variante mit LLM-as-a-Judge, Qualitätsmetriken ab dem ersten Tag.
- Eine Sache gleichzeitig ändern — Prompt-Änderungen von Modell-Wechseln isolieren für saubere Ergebnisse.
- Kosten neben Qualität prüfen — das Dashboard zeigt beides für fundierte Abwägungen.