A/B-Tests für KI-Agenten: Prompts sicher verbessern

Ein Team schreibt den System-Prompt neu und wechselt von Gemini 2.5 zu Sonnet 4.6. Der Agent wirkt schneller und vielleicht auch etwas präziser, daher wird die neue Version veröffentlicht. Zwei Tage später füllt sich die Support-Queue, weil sie mit Sonderfällen schlechter zurechtkommt. Der produktive Traffic ist damit Teil eines unkontrollierten Experiments.

KI-Agenten sind nicht deterministisch. Derselbe Input kann in verschiedenen Runs zu unterschiedlichen Outputs führen. Eine Prompt-Änderung, die eine Kategorie von Anfragen verbessert, kann eine andere verschlechtern. Anders als bei klassischer Software können Unit-Tests nicht jede mögliche Interaktion abdecken. Teams brauchen eine Möglichkeit, Änderungen mit echtem Traffic zu testen, ihre Wirkung zu messen und anhand von Daten zu entscheiden.

Genau das leisten A/B-Tests. Mit Connic führen Teams kontrollierte Experimente mit Agenten durch. Der Traffic wird zwischen der aktuellen Version und einer Variante aufgeteilt. Kosten, Latenz, Erfolgsrate und Qualitätswerte werden für beide Versionen verglichen, sodass die Entscheidung auf Messwerten basiert.

Warum KI-Agenten per A/B-Test verglichen werden sollten

Jede Änderung an einem KI-Agenten ist eine Hypothese: „Dieser Prompt wird präziser.“ „Dieses KI-Modell wird günstiger, ohne an Qualität zu verlieren.“ „Dieses neue Tool beschleunigt die Antworten.“ A/B-Tests machen aus diesen Hypothesen Experimente mit messbaren Ergebnissen.

So funktioniert es

Das Prinzip ist einfach. Ein Basisagent dient als Kontrollversion, und eine Variante enthält die zu testende Änderung. Unsere Plattform routet einen Anteil des Live-Traffics an die Variante, während der Rest weiterhin an die Kontrollversion geht. Beide Versionen verarbeiten echte Requests parallel. Jeder Run wird erfasst und seiner Gruppe zugeordnet.

Varianten sind reguläre Agentenkonfigurationen. Sie können alles verändern: KI-Modell, System-Prompt, Tools oder Temperatur. Eine Namenskonvention macht sofort deutlich, welcher Agent die Basis und welcher die Variante ist:

order-processor.yaml                    # base agent (control)
order-processor-test-faster-model.yaml  # variant: testing a cheaper model
order-processor-test-new-prompt.yaml    # variant: testing a rewritten prompt

Beide werden nebeneinander bereitgestellt. Die Variante bleibt inaktiv, bis ein Test erstellt und Traffic an sie weitergeleitet wird.

Was getestet werden kann

Varianten sind vollständige Agentenkonfigurationen. Den Experimenten sind daher kaum Grenzen gesetzt.

name: order-processor-test-faster-model
model: connic/gpt-5.6-luna        # faster, high-volume model
description: "Processes incoming customer orders"
system_prompt: |
  You process incoming orders...
tools:
  - orders.process
  - inventory.check

Alles andere bleibt gleich. Die Variante übernimmt exakt denselben Workflow. Der einzige Unterschied ist die getestete Variable.

Einen Test durchführen

Sobald die Variante bereitgestellt ist, dauert das Einrichten eines Tests weniger als eine Minute.

• 1.Die Variante bereitstellen. Das YAML der Variante neben den Basisagenten pushen. Nach dem Deployment erscheint sie als verfügbare Testvariante.
• 2.Den Basisagenten öffnen und im Header auf Manage A/B-Tests klicken.
• 3.Einen neuen Test erstellen. Die Variante auswählen, den Traffic-Anteil festlegen und eine minimale Stichprobengröße konfigurieren.
• 4.Den Test starten. Tests beginnen mit dem Status Draft, damit die Konfiguration vor dem Go-live geprüft werden kann.
• 5.Den Test beobachten und beenden. Die Vergleichsmetriken füllen sich mit neuen Ausführungen. Sobald die geplante Stichprobengröße und der geplante Endpunkt erreicht sind, lassen sich die Ergebnisse vergleichen und ein Gewinner bestimmen.

Ergebnisse auswerten

Die Testdetailansicht vergleicht alle relevanten Metriken direkt miteinander:

Jede Ausführung in der History trägt ein Varianten-Badge. So ist sofort erkennbar, welche Anfragen an welche Version gingen. Die Ausführungstabelle lässt sich nach Variantennamen filtern, um einzelne Ergebnisse genauer zu untersuchen.

Auto-Rollback als Sicherheitsnetz

Experimente dürfen den Produktivbetrieb nicht beeinträchtigen. Wenn Auto-Rollback aktiviert ist, überwacht Connic die Fehlerrate der Variante über ein gleitendes Fenster der letzten Runs. Überschreitet sie den konfigurierten Schwellenwert, wird der Test pausiert und es fließt kein Traffic mehr an die Variante.

Wird ein Rollback ausgelöst, geht der gesamte Traffic sofort zurück an den Kontrollagenten. Der Test bleibt pausiert und zeigt eine klare Fehlermeldung zur Ursache. So kann das Team den Fehler untersuchen, die Variante korrigieren und es erneut versuchen.

A/B-Testing mit Judges kombinieren

A/B-Testing zeigt, welche Version besser ist. Judges erklären, warum. Wenn das Team für den Basisagenten einen Judge konfiguriert, bewertet er automatisch die Runs von Control und Variante. Der durchschnittliche Judge-Score erscheint im A/B-Testvergleich und ergänzt Kosten und Latenz um ein Qualitätssignal. Dabei übernimmt automatisiertes Agenten-Scoring die Bewertung. Der Vergleich berücksichtigt damit sowohl die Output-Qualität als auch den Erfolg des Runs.

Sticky Sessions

Wenn Agenten mehrteilige Unterhaltungen führen, soll ein Nutzer nicht mitten in einer Session zwischen Control und Variante wechseln. Sind Sessions konfiguriert, hält Connic denselben Nutzer während der gesamten Unterhaltung auf derselben Version. Wird der Test beendet oder pausiert, werden die Sessions wieder dem Basisagenten zugeordnet.

Praktische Szenarien

Diese Experimente funktionieren in der Praxis besonders gut:

Bewährte Vorgehensweisen

Erste Schritte

Das erste Experiment folgt diesen Schritten:

• 1.Genau eine Sache für den Test auswählen: ein anderes KI-Modell, einen neuen Prompt oder ein aktualisiertes Tool
• 2.Das Varianten-YAML mit dieser Änderung erstellen und neben der Basis bereitstellen
• 3.Den Basisagenten öffnen, auf Manage A/B-Tests klicken und einen Test mit 10 % Traffic erstellen
• 4.Auto-Rollback aktivieren, die minimale Stichprobengröße aus dem Plan festlegen und den Test starten
• 5.Daten abwarten, die Ergebnisse vergleichen und den Gewinner veröffentlichen

Die Ergebnisse aus echtem Traffic zeigen, welche Version sich für den vollständigen Rollout eignet.

Der vollständige Einrichtungsleitfaden steht in der A/B-Testing-Dokumentation. Für den Einstieg in Connic lässt sich mit dem Quickstart-Leitfaden ein erster Agent bereitstellen und anschließend ein erstes Experiment starten.