Eine KI-Funktion kann die Abnahme bestehen und in der zweiten Woche an Eingaben scheitern, die im Testset nie vorkamen. Erklärt ein Support-Chatbot einem Kunden eine Erstattungsregel, die es so nicht gibt, hat aus Kundensicht das Unternehmen gesprochen, und der Streit darüber kostet mehr als jede Testwoche. Ein A/B-Test für KI muss deshalb mehr beantworten als die Frage, welche Variante besser konvertiert.
Ein KI-Experiment prüft vier Ebenen zugleich
Klassische Software gibt auf dieselbe Eingabe immer dieselbe Antwort. Eine KI-Funktion nicht. Ihre Antworten sind teils vom Zufall bestimmt, Sonderfälle lassen sich schwer vorhersehen, die Antwortzeit schwankt, und jede Anfrage kostet unterschiedlich viel. Ein Experiment prüft deshalb vier Ebenen gleichzeitig. Die meisten Fehlschlüsse entstehen, wenn eine davon fehlt:
- das Verhalten des Modells: Liegt es richtig, erfindet es Fakten, bleibt es stabil?
- den Nutzen: Löst der Nutzer seine Aufgabe besser?
- die Wirtschaftlichkeit: Tragen sich die Kosten pro Anfrage auch bei zehnfachem Volumen?
- Sicherheit und Recht: keine beleidigenden, einseitigen oder rechtlich heiklen Inhalte.
Ein Modell kann die Conversion steigern und gleichzeitig die Kosten pro Antwort verdoppeln. Oder es erzeugt unbemerkt mehr beleidigende Antworten. Die Aufgabe des PM ist, diese vier Ebenen in einem Experiment zu vereinen. Wer sie nacheinander prüft, vergleicht am Ende Ergebnisse aus verschiedenen Wochen. Und dazwischen haben sich Modell und Nutzer längst verändert.
Die Hypothese braucht ein „weil“ und klare Grenzen
Auch eine KI-Hypothese braucht eine Zielkennzahl und einen Mindesteffekt. KI-Antworten schwanken aber stärker als bei einer Button-Farbe. Deshalb legt man zusätzlich Spannen fest: wie schnell die Antwort kommen soll, um wie viele Punkte die erfundenen Antworten sinken sollen, wie viel besser die Sortierung werden soll und welche Fehler in Grenzfällen noch erlaubt sind. So lässt sich das Ergebnis später nicht bequem umdeuten, wenn jemand die ersten Zahlen in seine Richtung lesen möchte.
Eine gute Hypothese verbindet außerdem eine technische Fähigkeit mit einem messbaren Effekt. Beispiel: Wenn das Modell Support-Tickets genauer zuordnet, dann werden Anliegen schneller gelöst, weil weniger Tickets zwischen Teams weitergereicht werden. Ohne dieses „weil“ misst man nur einen Zusammenhang. Verschwindet er, weiß man nicht, was zu korrigieren ist.
KI-Experimente verschlechtern manchmal Dinge, die niemand beobachtet hat. Deshalb gehören vor den Start auch die Grenzen: unzulässige Fehler, eine Obergrenze für erfundene Antworten, ein Kostenlimit und Auslöser für den Sicherheitsstopp. Wird eine Grenze überschritten, ist die Variante durchgefallen, egal was die übrigen Zahlen zeigen. Bei Kundengesprächen gehört eine eigene Grenze dazu: erfundene Zusagen zu Preisen, Fristen oder Erstattungen. Hier liegt die Toleranz bei null.
Jede Kennzahl braucht eine eindeutige Rolle
Drei Gruppen von Kennzahlen laufen nebeneinander. Sie zu vermischen ist der häufigste Fehler.
Outcome-Metriken messen den tatsächlich gelieferten Wert, unabhängig davon, wie das Modell intern arbeitet: erledigte Aufgaben, Wiederkehr, gesparte Zeit, Käufe, Bearbeitungszeit im Support. Für diese Zahlen steht der PM ein.
Daneben beobachtet das Engineering die Modellkennzahlen: Trefferquote (Precision und Recall), erfundene Antworten, Relevanz der Sortierung, Antwortzeiten, Kosten pro Anfrage und ob das Modell mit der Zeit schlechter wird. Sie erklären, warum sich ein Ergebnis bewegt, und sie warnen früh. Eine Variante kann Nutzern in einer Stichprobe gefallen und dann kippen, sobald sich die Verteilung der Anfragen ändert, also wenn Nutzer plötzlich andere Fragen stellen.
Die dritte Gruppe sind Schutzkennzahlen. Sie verhindern, dass eine schöne Verbesserung ein Risiko verdeckt: gefährliche Antworten, Benachteiligung einzelner Gruppen, beleidigende Inhalte, Frust bei Nutzern, technische Ausfälle, plötzliche Kostensprünge. Über die Rücknahme entscheiden sie allein. Die Ergebniskennzahlen reden dabei nicht mit.
Rechenbeispiel: 800 Fehlrouten weniger im Monat
Was die Rollen praktisch bedeuten, zeigt ein Rechenbeispiel mit erfundenen, aber stimmigen Zahlen. Ein Softwareanbieter bearbeitet 20.000 Support-Tickets im Monat. Das bisherige Routing schickt 12 Prozent davon an das falsche Team, ein neues Modell soll die Quote auf 8 Prozent senken. Jedes falsch geroutete Ticket kostet rund 15 Minuten zusätzliche Bearbeitung, eine Arbeitsstunde kostet das Unternehmen 40 Euro.
Der Nutzen: Statt 2.400 Fehlrouten im Monat (12 Prozent von 20.000) wären es noch 1.600 (8 Prozent). Die 800 vermiedenen Fehlrouten sparen 200 Stunden oder 8.000 Euro monatlich. Die Kosten: Das neue Modell kostet 0,6 Cent pro Ticket statt 0,2 Cent, also 80 Euro im Monat mehr. Das Verhältnis ist eindeutig, und genau deshalb ist hier eine andere Frage interessanter: Wie viele Tickets braucht der Test?
Für einen Unterschied von vier Prozentpunkten (12 gegen 8 Prozent) liefert die Faustformel n ≈ 16 × p × (1 minus p) / δ² mit p um 10 Prozent rund 16 × 0,1 × 0,9 / 0,04² ≈ 900 Tickets pro Variante. Das ist in drei Tagen erledigt. Würde das Modell die Quote nur um einen Punkt senken, wären es 16 × 0,12 × 0,88 / 0,01² ≈ 16.900 Tickets pro Variante, also fast zwei Monate des gesamten Volumens. Daraus folgt eine Regel: Je kleiner der erwartete Effekt, desto früher muss feststehen, ob das Volumen ihn überhaupt messbar macht.
Schwankung kostet Nutzer, Disziplin spart sie
Wie viele Daten man für eine verlässliche Aussage braucht, hängt zuerst davon ab, wie stark die Werte schwanken. KI-Antworten schwanken mehr. Für denselben Effekt braucht man deshalb mehr Beobachtungen als in einem klassischen A/B-Test. Vor dem Start werden drei Dinge festgelegt: die Mindestzahl an Fällen, die gewünschte Testschärfe (meist 80 Prozent) und der kleinste Effekt, der einen Rollout rechtfertigt. Wie stark die Ergebnisse schwanken, hängt vom Aufbau des Prompts, von der Art der Anfragen und von der Vielfalt der Daten ab. Diese Quellen schätzt man vorher ab, statt sie unterwegs zu entdecken.
Auch die Reihenfolge zählt. Zuerst kommt der Labortest (die Offline-Prüfung). Dort misst man die Trefferquote und die erfundenen Antworten an einem Golden-Dataset, also einer sorgfältig geprüften Sammlung mit verlässlichen richtigen Antworten. Man prüft auch, ob das Modell seine eigene Sicherheit richtig einschätzt: Ein Modell, das sich zu 80 Prozent „sicher“ ist, sollte auch in etwa 80 Prozent der Fälle richtig liegen. Dazu kommen Relevanz im Vergleich zum alten Modell, Sicherheitsregeln und Kosten pro Anfrage. Der Live-Test beginnt erst, wenn die vorher festgelegten Laborkriterien erfüllt sind. Mit echten Nutzern will man Verhalten beobachten, nicht Fehler finden, die im Labor längst aufgefallen wären.
Den Rest der Schwankung hat das Team selbst in der Hand: Daten immer gleich aufbereiten, Prompt-Versionen sauber nummerieren, gleiche Zwischenspeicher-Regeln, abgestimmte Schwellen und eine stabile Aufteilung der Nutzer. Jede offen gelassene Einstellung bringt Rauschen hinein, das den gesuchten Effekt verdeckt.
Dieselbe Power mit kleinerer Stichprobe
Gegen starke Schwankung gibt es ein bewährtes Mittel. Es heißt CUPED (Controlled-experiment Using Pre-Experiment Data). Die meisten Nutzer haben schon vor dem Experiment eine Vorgeschichte. Man rechnet sie aus der Kennzahl heraus, zum Beispiel die Aktivität im Vormonat. Dann fällt der Teil der Schwankung weg, der nichts mit der Variante zu tun hat. Hängt die Aktivität im Vormonat stark mit der Zielkennzahl zusammen (Korrelation 0,7), sinkt die Schwankung um 49 Prozent. Der Test braucht dann fast nur halb so viele Nutzer.
Für eine KI-Funktion passt das besonders gut: Die Schwankung ist hoch, und Nutzer sind oft knapp. Die Bedingung ist aber streng. Die Vorgeschichte muss vor der Zuteilung gemessen sein und darf nicht von der Variante abhängen. Sonst bringt die Korrektur genau die Verzerrung hinein, die sie beseitigen soll.
Im Support-Beispiel stößt die Methode an eine Grenze: Ein einzelnes Ticket hat keine Vorgeschichte. Dort hilft eher, die Tickets vor dem Test nach Kategorie zu sortieren. Rechnungs-, Technik- und Kontofragen landen dann in beiden Varianten im gleichen Verhältnis, und verglichen wird innerhalb jeder Kategorie. Angenommen, bei Rechnungsfragen landen 4 Prozent beim falschen Team und bei Technikfragen 20 Prozent. Dieser Unterschied fällt dann aus dem Vergleich heraus, statt als Rauschen mehr Tickets zu verlangen. Wie viel das spart, zeigen die Tickets des Vormonats: Je weiter die Quoten der Kategorien auseinanderliegen, desto mehr.
Der zweite Weg, mit weniger Daten auszukommen: nicht zu früh nachsehen. Wer täglich schaut und beim ersten p-Wert unter 0,05 stoppt, bekommt deutlich mehr als die geplanten 5 Prozent Zufallstreffer. Jeder Zwischenblick ist eine weitere Chance, dass der Zufall „gewinnt“. Entweder legt man die Laufzeit fest und liest das Ergebnis einmal am Ende ab. Oder man nutzt sequenzielle Verfahren, die für wiederholtes Hinsehen gebaut sind und die Quote falscher Treffer trotzdem halten.
Wer Experimente startet und wer sie stoppt
Eine KI-Funktion betrifft mehr Teams als eine neue Oberfläche. Klare Zuständigkeiten sorgen dafür, dass Sicherheits- und Rechtsfragen nicht erst hinterher auffallen. Vor dem Start äußern sich Produkt, Data Science, die Modellentwickler, Recht und Compliance, Datenschutz und Design. Der PM leitet die Runde, schlichtet und trifft die Entscheidung.
Für Teams in der EU kommt die KI-Verordnung hinzu. Ihre Pflichten hängen von der Risikoklasse des Systems ab. Unabhängig davon sollte jedes Team, das KI-Funktionen testet und ausrollt, belegen können: Die Beteiligten wissen, was das System kann und wo es versagt. Die Unterlage zum Experiment ist dafür der richtige Ort.
Festgehalten werden Hypothesen, erwartete Bandbreiten, Laborergebnisse, Definitionen der Kennzahlen, Schwellen der Schutzkennzahlen, die Begründung für die Zahl der Fälle und die Regeln für eine Rücknahme. Wird ein Ergebnis angezweifelt, entscheidet diese Unterlage den Streit. Davor stehen die Prüfungen zu Ethik und Recht: Umgang mit personenbezogenen Daten, Erklärbarkeit, riskante Inhalte, Herkunft der Trainingsdaten und das Risiko erfundener Antworten.
Ausrollen, nachtrainieren oder abbrechen?
Die Entscheidung wägt Nutzen, Sicherheit und Kosten ab, in einer festen Reihenfolge mit Vetorecht. Steigen beleidigende Inhalte, erfundene Antworten, Benachteiligung oder Sicherheitsrisiken, wird die Variante zurückgenommen, auch wenn der Nutzen steigt. Darüber wird nicht verhandelt.
Ausgerollt wird nur, wenn die Ergebniskennzahlen steigen, die Modellkennzahlen ihre Schwellen einhalten und die Kosten tragbar bleiben. Eine Variante, die 2 Prozent Conversion gewinnt, aber die Kosten pro Anfrage verdreifacht, ist kein Erfolg, solange niemand die Marge für das volle Volumen gerechnet hat. Kosten, die im Test in Ordnung sind, können im Livebetrieb explodieren: durch mehr Traffic, lange Eingaben oder mehrere KI-Agenten hintereinander. Löst eine Nutzeranfrage vier Modellaufrufe aus, kostet sie viermal so viel wie ein Aufruf.
Nachtrainiert wird, wenn Labor und Live-Test nicht zusammenpassen, das Modell unberechenbar reagiert oder mit der Zeit zu stark nachlässt. Bereit für den Rollout ist eine Variante erst, wenn sie über mehrere Wochen und in allen Nutzergruppen berechenbar bleibt.
Wann sich der volle Aufwand nicht lohnt
Kleine Teams halten dagegen. Abstimmungsrunde, Labortest, Planung der Fallzahl und Lastszenarien kosten Wochen. Für eine Prompt-Änderung, die sich in einer Minute zurücknehmen lässt, ist das zu viel. Das Support-Beispiel zeigt zudem, dass große Effekte schon mit 900 Tickets pro Variante sichtbar werden. Warum also nicht einfach ausrollen und beobachten?
Für umkehrbare Änderungen, die niemand außerhalb sieht, stimmt das. Eine neue Formulierung im internen Routing, die nur der Support bemerkt, braucht keine Ethikprüfung. Anders ist es, sobald die Funktion mit Kunden spricht, Zusagen macht oder personenbezogene Daten verarbeitet. Dann zählt vor allem, was sie bis zur Rücknahme schon gesagt hat.
Die Regel lautet: Ist die Änderung intern, in Minuten umkehrbar und ändert sie die Kosten pro Anfrage um weniger als 20 Prozent (ein frei gewählter Richtwert), reicht ein kurzer Test mit Schutzkennzahlen. Spricht die Funktion mit Kunden oder verarbeitet sie personenbezogene Daten, gilt das volle Verfahren.
Die Stoppregel braucht einen Namen
In Teams scheitern diese Regeln selten am Wissen, eher am Zeitpunkt. Die Fallzahl wird erst nach dem Start geplant, die Kosten erst nach dem Rollout geprüft. Vor dem Experiment steht deshalb fest:
- die Hypothese mit „weil“;
- die drei Gruppen von Kennzahlen mit ihren Schwellen;
- das Laborergebnis und die Kostenrechnung;
- die Freigaben, die Zahl der Fälle und die Laufzeit.
Während des Tests schaut man täglich auf die Schutzkennzahlen und wöchentlich auf die Kosten. Zwischenstände der Ergebniskennzahlen sind ein Hinweis, kein Ergebnis. Danach werden Signifikanz, Ursachen der Schwankung, Verhalten des Modells und die Kosten im großen Maßstab festgehalten, zusammen mit der Entscheidung.
Eine Zeile fehlt in den meisten Unterlagen: der Name der Person, die die Rücknahme auslöst. Fehlt er, sehen alle die rote Schutzkennzahl, aber niemand fühlt sich zuständig. Die Variante bleibt live, bis die Zahlen den Rückzug von selbst erzwingen. Diese Zeile sollte vor dem ersten Kontakt mit Nutzern ausgefüllt sein.