Shadow, Canary, A/B und Bandits: ML-Modelle sicher ausrollen

Angenommen, ein Team hat monatelang an einem neuen Machine-Learning-Modell gearbeitet, und die Offline-Evaluierung sieht hervorragend aus: höhere Precision, höherer Recall, weniger False Positives und eine akzeptable Latenz. Die naheliegende Frage lautet, ob es in Produktion gehen kann. Wahrscheinlich ja. Doch dann folgt eine wichtigere Frage: Soll es sofort 100 % des Produktionstraffics bekommen? Meist nicht. Ein Modell, das auf historischen Daten glänzt, kann sich ganz anders verhalten, sobald es auf echte Kunden, echten Traffic, unerwartete Eingaben, Infrastrukturausfälle und sich verschiebende Datenverteilungen trifft.

Teams mit ML in Produktion greifen deshalb zu vier Strategien, jede mit einer eigenen Aufgabe:

• Shadow Deployment lässt Sie ein neues Modell beobachten, ohne nach seinen Antworten zu handeln.
• Ein Canary Release gibt ihm einen kleinen Teil des Live-Traffics.
• Ein A/B-Test vergleicht es direkt mit dem alten.
• Ein Multi-Armed Bandit verschiebt den Traffic, sobald Ergebnisse eintreffen, zu dem, was am besten funktioniert.

Das durchgehende Beispiel: Betrugserkennung

Eine Finanzplattform verarbeitet 1 Million Transaktionen pro Tag, und jede läuft durch ein Modell zur Betrugserkennung. Das aktuelle Produktionsmodell ist V1. Das ML-Team hat V2 gebaut.

Customer Transaction
        ↓
    Payment API
        ↓
  Feature Service
        ↓
 Fraud Model V1
        ↓
  Fraud Risk Score
        ↓
 ┌──────┼────────┐
 ↓      ↓        ↓
Approve Review  Decline

Offline sieht V2 besser aus. Es auf einen Schlag für alle eine Million Transaktionen einzusetzen, bringt trotzdem unnötiges Risiko, denn je größer der sofortige Rollout, desto größer der mögliche Schadensradius. Also wird V2 schrittweise eingeführt.

Shadow Deployment: beobachten, bevor man handelt

Shadow Deployment gehört zu den sichersten Wegen, ein neues Modell mit Produktionstraffic zu testen. Echter Traffic geht an das neue Modell, seine Vorhersagen werden protokolliert, und die Kunden merken nichts davon. Die Architektur:

Production Transaction
                         ↓
               ┌─────────┴─────────┐
               ↓                   ↓
          🟢 Model V1         🔵 Model V2
           Production             Shadow
               ↓                   ↓
       Actual Decision        Log Prediction
               ↓
            Customer

Nehmen wir eine Transaktion wie diese:

Amount: $4,800
Location: Dallas
Device: New device
Transactions last 5 min: 4
Merchant risk: Medium

V1 gibt ihr eine Betrugswahrscheinlichkeit von 0,31 und genehmigt sie. V2 gibt 0,82 und würde sie zur Prüfung schicken. Da V2 im Shadow-Modus läuft, berührt seine Antwort den Kunden nicht, sie wird nur aufgezeichnet. Mit der Zeit lassen sich anhand der Logs vergleichen:

• Abweichungen in den Vorhersagen
• Precision und Recall
• False Positives und False Negatives
• Inferenzlatenz
• Verfügbarkeit der Features
• Data Drift
• Ressourcenverbrauch

Der Shadow-Modus beantwortet, wie sich V2 in Produktion verhalten würde, ohne ihm die Kontrolle zu geben. Shadow heißt: sehen, bevor man umschaltet.

Canary Release: klein anfangen, mit Zuversicht wachsen

Angenommen, V2 wirkt nach dem Shadow-Test gesund. Jetzt soll es echte Entscheidungen treffen, aber der Schritt geht nicht von 0 % auf 100 %. Er beginnt mit einem kleinen Teil des Traffics:

Production Traffic
                 ↓
          ┌──────┴──────┐
          ↓             ↓
        99%             1%
          ↓             ↓
     🟢 Model V1   🟡 Model V2

Von einer Million täglicher Transaktionen gehen weiterhin rund 990.000 an V1 und etwa 10.000 an V2, und die Entscheidungen von V2 zählen jetzt. Solange die Metriken halten, steigt der Anteil in Stufen (1 %, 5 %, 10 %, 25 %, 50 %, dann 100 %). In jeder Stufe sollte man verfolgen, wie viel Geld durch Betrug verloren geht, wie viele legitime Kunden abgelehnt werden, die Genehmigungsquote, die Latenz, Fehler und Timeouts, wie viele Fälle in der manuellen Prüfung landen und die Last auf der Infrastruktur.

Nehmen wir nun an, die Zahl falscher Ablehnungen schnellt hoch, als V2 10 % erreicht:

V2 reaches 10%
       ↓
🚨 Guardrail triggered
       ↓
Stop rollout
       ↓
Rollback
       ↓
100% → V1

Ein Canary beantwortet, ob V2 sicher genug für einen schrittweisen Rollout ist. Canary heißt: den Schadensradius kontrollieren.

A/B-Tests: die Daten entscheiden lassen

Sobald beide Modelle stabil laufen, ändert sich die Frage. Es geht nicht mehr nur darum, ob V2 sicher ist, sondern ob es tatsächlich bessere Geschäftsergebnisse liefert. Der infrage kommende Traffic wird zufällig aufgeteilt:

Eligible Traffic
                    ↓
            Random Assignment
              ↙           ↘
            50%           50%
             ↓             ↓
        🔵 Model V1   🟣 Model V2
          Group A       Group B

Dann werden die Ergebnisse verglichen. Die Werte unten dienen nur der Veranschaulichung.

Metrik	Modell V1	Modell V2
Betrugserkennung	92,0 %	95,1 %
Falsche Ablehnungen	1,8 %	1,2 %
Durchschnittliche Latenz	42 ms	51 ms
Manuelle Prüfung	4,5 %	3,7 %

In dieser Tabelle steckt eine Lehre: Das genaueste Modell ist in Produktion nicht automatisch das beste. V2 könnte Betrug besser erkennen und dabei die Latenz spürbar erhöhen, oder den Recall steigern und zu viele legitime Kunden in die manuelle Prüfung schicken. Beurteilen muss man das gesamte Geschäftsergebnis.

Verwechseln Sie die beiden Methoden nicht. Ein Canary fragt, ob V2 sicher ausgerollt werden kann. Ein A/B-Test fragt, ob V2 wirklich besser ist als V1. Beim Letzteren sollen die Daten den Sieger bestimmen.

Multi-Armed Bandits: lernen und dabei optimieren

Ein A/B-Test hält die Traffic-Aufteilung in der Regel über die ganze Laufzeit fest. Bandits sind anders, weil sich die Aufteilung ändern kann, während das System lernt. Stellen Sie sich drei Empfehlungsmodelle vor, die mit einer gleichmäßigen Aufteilung starten:

Model A → 33%
Model B → 33%
Model C → 34%

Nach dem Sammeln von Ergebnissen:

A → 3.0% conversion
B → 4.2% conversion 🏆
C → 2.7% conversion

Das System kann den Traffic dann schrittweise verschieben:

Model A → 20%
Model B → 70% 🚀
Model C → 10%

Warum nicht alles an B schicken? Weil das System weiter lernen muss. Das ist das Spannungsfeld zwischen Exploration, also Alternativen auszuprobieren, um herauszufinden, ob es etwas Besseres gibt, und Exploitation, also mehr Traffic an die Option zu geben, die gerade die beste Belohnung bringt.

Explore
   ↓
Learn
   ↓
Update Expected Reward
   ↓
Exploit
   ↓
Continue Learning

Zu den gängigen Algorithmen gehören Epsilon-Greedy, UCB und Thompson Sampling. Bandits passen zu Empfehlungen, Suchranking, Werbung, Angebotsauswahl, Personalisierung von Inhalten und der Optimierung von Benachrichtigungen. Kurz gesagt: lernen, anpassen, optimieren.

Bandits für Betrugsentscheidungen?

Hier ist Vorsicht geboten. Probiert ein Empfehlungssystem einen schwächeren Vorschlag aus, ignoriert ihn ein Kunde schlimmstenfalls. Probiert ein Betrugssystem eine schwächere Entscheidungsregel aus, wird womöglich eine betrügerische Transaktion genehmigt. Exploration kostet in beiden Fällen sehr Unterschiedliches, deshalb muss die Deployment-Strategie das Geschäftsrisiko berücksichtigen, nicht nur die Modellqualität. Systeme mit hoher Tragweite brauchen strengere Leitplanken und Zulassungsregeln, menschliche Prüfung, Compliance-Kontrollen, gute Observability und eine Möglichkeit zum Rollback.

Alles zusammen

Ein ausgereifter Weg für ML in Produktion kann so aussehen:

🧠 Train Model V2
        ↓
📊 Offline Evaluation
        ↓
🔵 Shadow Deployment
        ↓
🔍 Compare V1 vs V2
        ↓
🟢 Canary Release
        ↓
   1% → 5% → 10%
        ↓
🟣 A/B Testing
        ↓
📈 Validate Business KPIs
        ↓
🚀 Full Rollout
        ↓
👀 Continuous Monitoring
        ↓
🔄 Retraining / Model V3

Bei geeigneten Optimierungsproblemen geht es so weiter:

Continuous Monitoring
        ↓
🟠 Multi-Armed Bandit
        ↓
Learn + Optimize

Wenn etwas schiefgeht

Stellen Sie sich vor, V2 erreicht 25 % des Traffics, und das Monitoring meldet 45 % mehr Latenz, dreimal so viele Timeouts und 2,1 % mehr falsche Ablehnungen. Das Produktionssystem sollte von selbst reagieren:

🚨 Threshold Exceeded
        ↓
🛑 Stop Rollout
        ↓
↩️ Route Traffic to V1
        ↓
🔔 Alert ML / SRE Teams
        ↓
🔍 Investigate

Darum gehört Observability von Anfang an zum ML-Deployment und ist kein nachträglicher Gedanke. Drei Gruppen von Metriken sollte man verfolgen:

• Modellmetriken: wie gut die Vorhersagen sind (Precision, Recall, F1, AUC, beide Fehlerarten) und Drift in den Daten
• Systemmetriken: wie sich der Dienst hält, also Latenz, Durchsatz, Fehler, Timeouts, CPU, Speicher und Verfügbarkeit
• Geschäftsmetriken: was das Ergebnis wert ist (Conversion, Umsatz, Betrugsverluste, abgelehnte Kunden, manuelle Prüfungen, Engagement)

Ein Modell kann statistisch hervorragend sein und trotzdem im Betrieb oder kommerziell scheitern.

Dieselben Ideen für E-Commerce-Empfehlungen

In einem Umfeld mit geringerem Risiko sehen die Strategien anders aus:

• Shadow: V2 erzeugt Empfehlungen, aber die Kunden sehen weiterhin die von V1.
• Canary: 5 % der Kunden sehen allmählich die Empfehlungen von V2.
• A/B-Test: 50 % bekommen V1 und 50 % V2, und Sie vergleichen CTR, Conversion, durchschnittlichen Bestellwert, Umsatz pro Sitzung und Kundenbindung.
• Bandit: Der Traffic wandert zu Strategien mit besserer Belohnung, während kontrollierte Exploration weiterläuft.

Die vier Strategien im Vergleich

Strategie	Hauptfrage	Auswirkung auf Kunden	Traffic
Shadow	Wie wird sich V2 verhalten?	Nein	Gespiegelt
Canary	Ist V2 sicher?	Ja	Schrittweise erhöht
A/B	Ist V2 besser?	Ja	Feste Aufteilung im Experiment
Bandit	Welche Option sollte jetzt mehr Traffic bekommen?	Ja	Dynamisch

Eine kleine Eselsbrücke: Shadow beobachtet, Canary rollt vorsichtig aus, A/B vergleicht, und ein Bandit optimiert laufend neu.

Risikomanagement

Wer über KI und ML spricht, redet meist über Algorithmen, Features, Training, Genauigkeit und GPUs. Produktion bringt eine weitere Dimension ins Spiel: Risikomanagement. Die eigentliche Frage geht über gute Vorhersagen hinaus. Sie lautet, ob man das Modell sicher einführen, beobachten, seine Wirkung messen, den Schadensradius klein halten, Ausfälle erkennen und es zurückrollen kann. Eine erfolgreiche ML-Plattform in Produktion ist mehr als ein Modell hinter einer API. Sie verbindet Modelle, Daten, Infrastruktur, Experimente, Observability, Leitplanken, Rollback und Geschäftsmetriken. Das Training macht ein Modell bereit, und das Production Engineering entscheidet, ob es Vertrauen verdient.