In der Praxis sehen wir oft denselben Ansatz: Ein Prompt liefert nicht mehr die gewünschten Ergebnisse, also wird er angepasst. Wenn es besser wird, behält man die Änderung. Wenn nicht, dreht man sie zurück. Das funktioniert — für einzelne Prompts. Es funktioniert nicht für Multi-Agent-Workflows, in denen die Änderung eines Agenten das Verhalten des gesamten Systems beeinflusst.
Warum klassisches Prompt-Tuning nicht reicht
Ein Multi-Agent-Workflow besteht aus verketteten Agenten: Der Output des einen ist der Input des nächsten. Wenn Sie das Prompt des ersten Agenten ändern, verändert sich die Eingabe für den zweiten — und die Gesamtwirkung ist schwer vorhersehbar. Ohne kontrollierte Experimente können Sie nicht unterscheiden, ob eine Verbesserung auf die Änderung zurückgeht oder auf einen anderen Faktor (Tageszeit, Datenqualität, Model-Update).
Drei Dimensionen des A/B-Tests im Agent-Kontext
Prompt-Variants
Die häufigste Variante: Zwei oder mehr Versionen desselben Prompts laufen parallel auf denselben Eingabedaten. Gemessen wird anhand einer definierten Outcome-Metrik (Approval-Rate, FCR, Similarity-Score). Vorteil: isolierte Veränderung, klare Kausalität.
Routing-Variants
Veränderung der Agent-Auswahl oder -Reihenfolge. Beispiel: Anstelle dass der Klassifikations-Agent direkt an den Bearbeitungs-Agent übergibt, wird ein Zwischenschritt mit Validierung eingefügt. Routing-Variants testen nicht einen Agenten, sondern die Architektur des Workflows.
Tool-Variants
Austausch des Tools hinter einem Agenten: Statt einer Vektordatenbank wird ein Keyword-Index verwendet, statt GPT-4 ein lokales Modell. Tool-Variants testen die Infrastruktur, nicht das Verhalten.
Statistische Signifikanz — kein optionales Nice-to-have
Ohne Signifikanztest wissen Sie nicht, ob ein Ergebnis echt oder Zufall ist. Bei Multi-Agent-Systemen kommt eine Komplikation hinzu: Sie messen oft mehrere KPIs gleichzeitig. Die Wahrscheinlichkeit, dass mindestens einer davon rein zufällig signifikant wird, steigt mit jeder zusätzlichen Metrik. Abhilfe: Bonferroni-Korrektur — das Signifikanzniveau wird durch die Anzahl der KPIs geteilt. Bei fünf KPIs und α = 0,05 wird das korrigierte Niveau zu 0,01. Strenger, aber ehrlich.
Faustregel für die Praxis: Mindestens 200 Interaktionen pro Variante, mindestens 7 Tage Laufzeit (um Tages- und Wochengang-Effekte zu eliminieren).
Bandit-Algorithmen als Alternative
Klassisches A/B-Testing hat einen Nachteil: Die unterlegene Variante läuft weiter, bis das Experiment beendet ist — Verschwendung von Ressourcen und potenziell schlechtere Ergebnisse für echte Nutzer. Multi-Armed-Bandit-Algorithmen (z. B. Thompson Sampling oder UCB) lösen dieses Problem, indem sie die Traffic-Verteilung dynamisch anpassen: Die Variante mit den besseren Ergebnissen erhält zunehmend mehr Traffic, die schwächere weniger. Am Ende haben Sie nicht nur einen Gewinner, sondern haben während des gesamten Experiments bessere Ergebnisse erzielt als mit statischem A/B.
Praxis-Setup: Vom Experiment zur kontinuierlichen Optimierung
Ein etabliertes A/B-Testing-Programm für Agent-Systeme läuft typischerweise so:
- Hypothese formulieren: „Wenn wir den Validierungs-Agenten um eine Plausibilitätsprüfung erweitern, steigt die Approval-Rate um mindestens 5 Prozentpunkte.“
- Variante implementieren und im Shadow-Modus validieren (kein Produktiv-Traffic).
- Traffic schrittweise freigeben: 10 % → 25 % → 50 %, mit automatischem Rollback bei Regression > 2 Prozentpunkte.
- Nach Erreichen der Signifikanz: Gewinner zum neuen Standard erklären und dokumentieren.
- Vierteljährlich: Routing-Review — welche Agenten wurden getestet, was wurde gelernt, welche Hypothesen stehen noch aus?
Systematisch besser werden heißt nicht, alles zu ändern. Es heißt, eine Änderung zu machen, ihre Wirkung zu messen und nur zu behalten, was nachweislich besser ist.