Ein neues Underwriting-Modell validiert man produktiv, indem man es parallel zum aktiven Modell laufen lässt, ohne dass es irgendetwas entscheidet. Der Champion trifft weiterhin die echten Entscheidungen. Der Challenger scort dieselben Anträge im Hintergrund, und seine Entscheidungen landen in einem Log statt bei einem Kunden. Man vergleicht beide auf Live-Traffic, wartet, bis die Outcomes ausreifen, und leitet dann echte Entscheidungen um. Das ist Shadow Deployment.
Warum dieser Aufwand? Weil eine Kreditentscheidung nicht so reversibel ist wie die Farbe eines Checkout-Buttons. Lehnt man jemanden ab, der hätte genehmigt werden sollen, verliert man den Kunden und zieht womöglich eine Adverse-Action-Beschwerde nach sich. Genehmigt man jemanden, den der Challenger abgelehnt hätte, trägt man den Verlust jahrelang im Buch. Ein leichtfertiger A/B-Test auf einer Live-Population übersetzt Modellunsicherheit direkt in Kreditverluste und Conduct-Risiko. Der Shadow-Modus verschafft dir Evidenz, bevor du das Geld anderer aufs Spiel setzt.
Zuerst Shadow, dann ein dosierter Challenger
Shadow Deployment bedeutet, dass der Challenger exakt denselben Feature-Vektor konsumiert, den der Champion gesehen hat, zum selben Zeitpunkt, und einen Score sowie eine Entscheidung erzeugt, die nirgendwohin außer in eine Log-Tabelle gehen. Das ist die sicherste Stufe. Und zugleich die, die am häufigsten falsch gemacht wird.
Die Falle heißt Point-in-Time-Korrektheit. Dein Challenger braucht meist Features, die der Champion nie genutzt hat, und es ist verlockend, sie aus dem aktuellen Zustand deines Warehouse rückzubefüllen. Tu es nicht. Liest ein Feature einen Wert, der erst bekannt war, nachdem der Antrag entschieden wurde, hast du Leakage, und die Shadow-Ergebnisse sehen wunderbar aus, aus Gründen, die sich in Produktion nie reproduzieren lassen. Die Disziplin ist dieselbe, die du schon deinem Trainingsset schuldest: Jedes Feature, das der Challenger liest, muss zum Entscheidungszeitpunkt materialisiert sein, idealerweise aus demselben Feature Store, aus dem der Champion zieht, mit derselben Freshness und derselben Null-Behandlung.
Sobald die Shadow-Zahlen standhalten, geht man zu einem Live-Challenger über, aber zu einem dosierten. Route einen kleinen, zufällig zugewiesenen Anteil des Traffics, damit der Challenger tatsächlich entscheiden darf. Halte den Anteil klein und die Zuweisung pro Antragsteller stabil, damit ein Kunde, der erneut beantragt, nicht zwischen den Modellen hin- und herspringt. Zäune das Exposure ein:
- Deckle den Anteil des Challengers an neuen Bookings und das Dollar-Exposure, das er originieren darf.
- Schließe Segmente aus, in denen eine falsche Entscheidung teuer oder sensibel ist, zumindest anfangs.
- Setze Kill-Switch-Schwellen auf Genehmigungsquote, Durchschnitts-Score und Override-Rate, die das Routing automatisch stoppen.
Was du tatsächlich vergleichst
Der ehrliche Vergleich lautet nicht “welches Modell hat die höhere AUC auf den Daten des letzten Quartals”. Das war geklärt, bevor du überhaupt etwas deployt hast. In Produktion testest du, ob die Offline-Story den Kontakt mit Live-Traffic übersteht und ob die beiden Modelle auf eine Weise divergieren, die zählt.
Score-Übereinstimmung ist der erste Schnitt. Berechne den Population Stability Index zwischen den Score-Verteilungen von Champion und Challenger und lies dann die Disagreement-Matrix: die Zellen, in denen das eine genehmigt und das andere ablehnt. Auf ein einzelnes Segment konzentrierte Divergenz ist ein Signal, meist ein Feature, das sich in Produktion anders verhält als in deiner Stichprobe.
Die Entscheidung, die zählt, fällt auf ausgereiften Outcomes. Ein Challenger sieht an Tag eins großartig aus, weil du noch nicht sehen kannst, wer ausfällt. Die Outcomes müssen ausreifen. Das heißt, das Urteil zurückzuhalten, bis genügend der Shadow-gescorten Konten Zeit hatten, schlecht zu werden, was bei einem Consumer-Ratenkreditbuch in Monate geht. Bis dahin vergleichst du Proxys, und das solltest du laut aussprechen. Was sich durch die Wartezeit hindurch zu tracken lohnt:
- Genehmigungs- und Ablehnungsquoten nach Segment, gemessen gegen den Champion statt gegen ein Ziel.
- Score-Drift und Feature-Drift auf den Inputs des Challengers, denn ein neues Modell stützt sich oft auf Features, die der Champion ignorierte und daher nie überwachte.
- Das False-Positive-Budget: wie viele gute Antragsteller der Challenger ablehnt, die der Champion gebucht hätte, aufgerechnet gegen die Verluste, die er vermeidet.
- Adverse-Action-Reason-Codes, damit ein befördertes Modell weiterhin compliante, korrekte Ablehnungen nach ECOA erzeugen kann.
Lineage, Audit Trail und das Promotion-Gate
Jeder Shadow-Score muss reproduzierbar sein. Logge die Modellversion, die Feature-Werte wie ausgeliefert, den Feature-Store-Snapshot oder Timestamp und die resultierende Entscheidung, alles so verschlüsselt, dass du wieder auf das spätere Outcome joinen kannst. Wenn ein Validator oder ein Prüfer fragt, warum der Challenger vor acht Monaten einen bestimmten Antragsteller abgelehnt hat, rekonstruierst du das aus dem Log, statt aus einem erneuten Lauf gegen die heutigen Daten, der klammheimlich ein anderes Ergebnis liefern würde.
Promotion ist ein Governance-Ereignis, kein Deploy. Behandle den Wechsel vom Champion zum Challenger so, wie du jede andere Änderung an der Kreditpolitik behandelst: versioniert, geprüft und reversibel, wenn sich die Zahlen gegen dich wenden. Das Gate sollte eine ausgereifte Outcome-Performance verlangen, die eine vorab registrierte Latte überspringt, Drift innerhalb der Toleranz, Adverse-Action-Codes, die standhalten, und ein Sign-off des Model Risk. Nach SR 11-7 tritt der Challenger in den Geltungsbereich, sobald er eine Live-Entscheidung beeinflusst, also gehört die Arbeit an Effective Challenge und Dokumentation an das Promotion-Gate und nicht aufgeschoben bis nach dem Go-live.
Halte den alten Champion nach der Promotion warm. Stufe ihn zum Shadow herab, statt ihn zu löschen, damit du, falls das neue Modell driftet oder ein Segment degradiert, einen bereits validierten Fallback und eine Live-Baseline zum Messen hast. Champion/Challenger ist kein Bake-off, den man einmal gewinnt und dann davongeht. So lebt ein Kreditmodell dauerhaft in Produktion: ein Modell entscheidet, ein anderes beobachtet es, und ein reproduzierbares Log verbindet die beiden, sodass du im Nachhinein jederzeit für eine Entscheidung geradestehen kannst.
Häufige Fragen
Wie lange sollte ein Challenger-Modell im Shadow laufen, bevor es befördert werden kann?
Lange genug, um eine statistisch belastbare Zahl ausgereifter Outcomes für das relevante Segment anzusammeln, was bei den meisten Consumer-Portfolios eher mehrere Monate an Bookings bedeutet als ein paar Wochen. Der Engpass ist die Reifung von Ausfällen, nicht die Rechenleistung.
Können wir ein Modell im Shadow testen, das Daten braucht, die wir zum Entscheidungszeitpunkt noch nicht berechnen?
Nein. Wenn ein Feature zum Zeitpunkt, an dem der Champion feuert, nicht point-in-time verfügbar ist, ist der Shadow-Score nicht vergleichbar, und man misst eine Fantasie. Verdrahte das Feature zuerst in den echten Entscheidungspfad, dann folgt der Shadow-Betrieb.
Erfordert der Betrieb eines Challengers ein vollständiges Model-Risk-Review nach SR 11-7?
Reine Shadow-Challenger, die keinen Kunden berühren, unterliegen in der Regel einem leichteren Monitoring. Doch sobald ein Challenger eine Live-Entscheidung beeinflusst, fällt er in den Geltungsbereich von Validierung, Dokumentation und Effective Challenge. Behandle die Promotion, nicht die Entwicklung, als Auslöser.