Deutsch

Modelle in die Produktion bringen, ohne sie zu beschädigen

Das Notebook erzielte 0,91 AUC auf Ihrem Laptop. Das Modell ist jetzt live und gibt für 3 Prozent der Anfragen minus Unendlich zurück, der On-Call-Ingenieur wird um 2 Uhr nachts alarmiert, und Sie können den ursprünglichen Trainingslauf nicht reproduzieren, weil Sie den Random Seed nie festgelegt haben. Willkommen in der Lücke zwischen „Modell funktioniert" und „Modell ist ausgeliefert."

Ich habe diese Szene bei sechs Unternehmen mit fünf verschiedenen ML-Stacks beobachtet, und das Muster ändert sich nicht. Die Verluste sind nicht algorithmisch. Sie sind operativer Natur. Trainings-/Serving-Diskrepanz lässt den Produktions-AUC still um 4 bis 7 Punkte sinken. Eine Feature-Pipeline, die gestern funktionierte, gibt heute NaN-Werte aus, weil jemand ein vorgelagertes Schema geändert hat, ohne Sie zu informieren. Engineering behandelt Ihr Modell als Black Box, weil Sie ihren Service als Black Box behandelt haben.

Das ist das Playbook, das ich mir gewünscht hätte, bevor es meinen ersten Produktionsvorfall gab. Es behandelt die sieben Dinge, die entscheiden, ob Ihr Modell zu einer ruhigen Umsatzlinie oder zu einem wiederkehrenden Nachbetrachtungsthema wird.

Warum das jetzt wichtig ist

Die meisten Data-Science-Teams verlieren 30 bis 50 Prozent des Modellwerts zwischen Offline-AUC und Online-Geschäftsimpact. Das ist keine Kennzahl, die ich mir ausgedacht habe. Rechnen Sie die Zahlen für Ihre letzten drei ausgelieferten Modelle durch: Offline-Lift, Online-Lift, Zeit von „gemergt" bis „vollständig ausgerollt." Die Lücke hat fast immer die Form eines Besetzungsproblems, nicht die Form eines Algorithmusproblems.

Der DS, der Rollback-Disziplin, Modellüberwachung und die Engineering-Schnittstelle verantwortet, liefert fünfmal mehr Wert als der DS mit einer marginal besseren Modellarchitektur. Produktionsreife ist eine Disziplin, keine Tool-Wahl. Sie können es auf AWS Batch und einer Postgres-Tabelle umsetzen. Sie können mit dem teuersten Feature Store auf dem Markt auch spektakulär scheitern.

Feature-Pipeline: Feast vs. Tecton vs. DIY

Jeder Produktions-ML-Fehler, den ich persönlich verursacht habe, lässt sich auf Features zurückführen. Konkret: Die Features, auf denen das Modell trainiert wurde, waren nicht dieselben Features, die das Modell zum Scoring-Zeitpunkt sah. Das nennen wir Trainings-/Serving-Diskrepanz, und es ist der stille Killer.

Drei Optionen:

DIY (Postgres-Tabelle oder Warehouse-View). In Ordnung, wenn Sie ein Modell, Batch-Scoring haben und dasselbe SQL sowohl Trainingsdaten als auch Serving-Daten erzeugt. Die meisten Unternehmen sollten hier beginnen und länger als gedacht dabei bleiben. Die Falle: Wenn Sie anfangen, Echtzeit-Features hinzuzufügen, ist das SQL, das Sie für das Training geschrieben haben (eine 7-Tage-Rollingsumme aus dem Warehouse), nicht dasselbe SQL, das der Serving-Service ausführt (ein Streaming-Aggregat aus Redis). Sie driften auseinander. Stillschweigend.

Feast (Open Source). Kostenlos, selbst gehostet. Lohnt sich, wenn Sie drei oder mehr Modelle haben, die Features teilen, dieselbe Definition für Training und Online-Serving verwenden wollen und bereit sind, Redis/DynamoDB sowie eine Spark- oder Flink-Pipeline zu betreiben. Das ehrliche Preisschild: Sie werden ein Quartal mit dem Onboarding verbringen, bevor Features fließen. Lohnt sich, wenn Sie über die Ein-Modell-Phase hinaus sind.

Tecton (verwaltet). Kaufen Sie es, wenn Feature Engineering ein echter Engpass ist, Sie ein Budget von 80.000 bis 200.000 USD pro Jahr haben und lieber keine Streaming-Infrastruktur betreiben möchten. Tecton löst die Trainings-/Serving-Diskrepanz, indem es eine Definition sowohl für Backfills als auch für Online-Werte erzeugt. Ihr Lineage-Tracking erkennt „dieses Feature wurde letzten Dienstag geändert", bevor Sie es tun.

Die Entscheidung lautet nicht: „Welches Tool ist das Beste?" Sie lautet: Habe ich ein Modell oder viele, Batch oder Echtzeit, und ist Feature-Drift für mich aktuell unsichtbar? Wenn ja-ja-ja, brauchen Sie einen Store. Wenn nein-nein-nein, ist ein Warehouse-View und eine feature_definitions.py-Datei, die Sie sowohl im Training als auch im Serving importieren, mehr als ausreichend.

Reproduzierbarkeit der Trainingspipeline

Könnten Sie den genauen Trainingsjob, der das aktuell in Produktion befindliche Modell erzeugt hat, jetzt von Rohdaten aus mit denselben Splits und denselben Metriken in 30 Minuten erneut ausführen?

Wenn die Antwort nein lautet, haben Sie keine reproduzierbare Pipeline. Sie haben ein Souvenir.

Was Reproduzierbarkeit tatsächlich erfordert:

  1. Jeden Seed festlegen. Nicht nur random_state=42 für den Trainings-/Test-Split. Seed für numpy, seed für PyTorch/TensorFlow, seed für Ihren Sampler, seed für Ihren Data-Shuffler, seed für jede Augmentierung. Ich habe ein Modell debuggt, bei dem zwei Ingenieure 0,86 und 0,91 AUC aus „demselben Notebook" erzielten, weil der CUDA-RNG von torch nicht geseeded war. Drei Tage verloren.

  2. Ihre Splits hashen. Vertrauen Sie train_test_split nicht darauf, über pandas-Versionen hinweg deterministisch zu sein. Berechnen Sie einen stabilen Hash aus einer Zeilen-ID (user_id, transaction_id) modulo dem Split-Verhältnis. Dieselbe Zeile, derselbe Split, für immer. Bonus: Wenn Sie auf neuen Daten neu trainieren, bleiben alte Test-Set-Zeilen im Test-Set.

  3. Den Dataset-SHA im Modellartefakt aufzeichnen. Die Modellkarte sollte enthalten: SHA-256 des Trainingsdatensatzes (nach Feature Engineering), Trainingsfenster (2025-10-01 bis 2026-03-31), Feature-Schema-Version, Code-Commit, Lockfile-Hash der Bibliotheken, Auswertungsmetriken auf dem Holdout-Set, Auswertungsmetriken auf einem eingefrorenen Referenz-Set. Das kommt in dasselbe Git LFS- oder MLflow-Artefakt wie die Modellgewichte.

  4. Die Laufzeitumgebung einfrieren. Ein requirements.lock, poetry.lock oder uv.lock, das neben dem Modell committet wird. Bibliotheksversionen-Drift bricht die Reproduzierbarkeit still. scikit-learn 1.3 vs. 1.4 reicht aus, um Vorhersagen zu verschieben.

Der Test „Trainingslauf von vor 6 Wochen erneut ausführen" ist nicht verhandelbar. Wenn Sie ihn nicht bestehen, können Sie eine Regression nicht glaubwürdig debuggen. Sie raten.

Batch vs. Echtzeit-Serving: wann was

Die meisten „Echtzeit"-Modelle sollten Batch sein. Ich sage es zweimal, weil es jedes Mal ignoriert wird. Die meisten „Echtzeit"-Modelle sollten Batch sein.

Der Entscheidungsbaum:

  • Latenz-Budget über 1 Stunde, Vorhersage verändert sich langsam: nächtliches Batch. Alle um 2 Uhr nachts scoren, in eine Tabelle schreiben, das Produkt liest aus der Tabelle. Lead Scoring, Churn-Risiko, Content-Empfehlungen für Nicht-Cold-Start-Nutzer. p99-Latenz: ein SELECT.
  • Latenz-Budget 5 bis 60 Minuten, Vorhersage benötigt stündliche Aktualität: stündliches Batch. Gleiche Form, häufiger. Bestandsprognosen, Nachfragesignale.
  • Latenz-Budget 30 Sekunden bis 5 Minuten, hängt von Session-Aktivität ab: Microbatch. Streaming-Consumer scort in Batches von 100 bis 1.000 Datensätzen alle 30 Sekunden. Fraud-Signale, Anomalieerkennung, bei der eine Aktion eine Minute warten kann.
  • Latenz-Budget unter 200 ms, Anfrage ist unvorhersehbar: Echtzeit. Ad-Ranking, Suchrelevanz, Fraud-Blockierungen beim Checkout, Echtzeit-Personalisierung. Das ist die teure Variante. Das p99-Latenz-Budget sollte im Schnittstellenvertrag vor dem Training festgelegt werden, nicht nach dem Deployment.

Der Kostenunterschied ist enorm. Ein nächtlicher Batch-Job läuft eine Stunde auf einer einzelnen großen Instanz. Ein Echtzeit-Service benötigt Autoscaling, Warm Pools, p99-Monitoring und ein SRE auf Rotation. Wählen Sie Batch, außer Sie haben einen echten Grund dagegen.

Eine Erfahrung aus der Praxis: Wir haben ein „Echtzeit"-Empfehlungsmodell ausgeliefert, das für drei Feature-Lookups pro Anfrage synchron Postgres aufrief. p99 stieg auf 4 Sekunden, bevor wir es bemerkten. Die Lösung war kein schnelleres Postgres. Sie bestand darin, zuzugeben, dass das Modell nicht Echtzeit sein musste, es auf Batch umzustellen und aus einer vorberechneten Tabelle zu servieren. Die Latenz sank auf 8 ms. Das Produktteam bemerkte die Änderung nicht, weil die Empfehlungen tatsächlich nicht session-abhängig waren.

Modellüberwachung: Datendrift, Konzeptdrift, Geschäftskennzahl

Vier Dinge zu überwachen. Drei davon sind diagnostisch. Nur eines zahlt die Rechnungen.

Datendrift. Sind die Features, die das Modell heute sieht, so verteilt wie die Features, auf denen es trainiert wurde? Verfolgen Sie den Population Stability Index (PSI) pro Feature täglich. PSI über 0,1: untersuchen. PSI über 0,25: Ihre Trainingsverteilung und Ihre Produktionsverteilung sind nicht mehr gleich. Alarm. Führen Sie für kontinuierliche Features zusätzlich einen Kolmogorov-Smirnov-Test gegen ein Referenzfenster durch. Günstig, schnell, erkennt Schema-Brüche, bevor Vorhersagen schlecht werden.

Vorhersagedrift. Sind die Outputs des Modells so verteilt wie letzte Woche? Manchmal ist Datendrift unsichtbar (Feature-Interaktionen verschieben sich), aber Vorhersagedrift ist laut. Verfolgen Sie p10/p50/p90 des Modell-Outputs täglich.

Konzeptdrift (mit Berücksichtigung der Label-Verzögerung). Hat sich die Beziehung zwischen Features und dem Label verändert? Das können Sie nur prüfen, wenn Labels ankommen, was bei vielen Modellen Tage oder Wochen später ist. Bauen Sie eine verzögerte Auswertungspipeline: Wenn Labels eintreffen, berechnen Sie AUC/MAE für diese Zeilen neu und stellen Sie es über die Zeit dar. Die Falle besteht darin, AUC am Tag nach dem Deployment zu alarmieren, wenn noch keine Labels vorhanden sind. Sie werden auf 0 starren.

Die Geschäftskennzahl. Umsatz. Conversion-Rate. CAC. Lifetime Value. Das, wofür das Modell existiert. Das ist die einzige Kennzahl, die entscheidet, ob das Modell bestehen bleibt. Alarmschwellen für Datendrift und Vorhersagedrift sind diagnostisch. Alarmschwellen für die Geschäftskennzahl sind existenziell.

Ich habe Teams gesehen, die ein Modell mit schön kalibrierten Drift-Dashboards und null Sichtbarkeit darauf ausgeliefert haben, ob der Umsatz sich bewegt hat. Seien Sie nicht dieses Team. Das erste Dashboard ist das Geschäfts-Dashboard. Die Drift-Dashboards existieren, um zu erklären, warum sich die Geschäftskennzahl bewegt hat, nicht um sie zu ersetzen.

Der Shadow-Mode-Rollout

Scoren, aber nicht handeln. Für ein bis zwei Wochen. Auf demselben Traffic. Vergleichen Sie die Vorhersagen des neuen Modells mit denen des Incumbents und mit den tatsächlichen Ergebnissen, wenn Labels ankommen.

Das ist die einzelne wirkungsvollste Praxis, die ich im Produktions-ML kenne, und die meisten Teams überspringen sie.

Der Shadow-Rollout-Ablauf:

  1. Setzen Sie das neue Modell neben dem Incumbent ein. Beide scoren jede Anfrage. Nur die Vorhersagen des Incumbents beeinflussen das Produktverhalten.
  2. Protokollieren Sie beide Vorhersagen plus alle verwendeten Features.
  3. Vergleichen Sie nach 7 bis 14 Tagen:
    • Verteilungsüberlappung: Treffen die beiden Modelle ähnliche Vorhersagen für dieselben Inputs? Wenn 30 Prozent abweichen, finden Sie heraus warum, bevor Sie umschalten.
    • Abgleich mit Offline-Erwartungen: Entspricht das Online-Verhalten des neuen Modells dem, was Ihre Holdout-Auswertung vorhergesagt hat? Wenn die Offline-Auswertung plus 5 Prozent Lift angab und der Shadow zeigt, dass sie identisch sind, waren Ihre Trainingsdaten undicht.
    • Latenz, Fehlerrate, Randfälle (NaN-Inputs, fehlende Features): Handhabt das neue Modell den Long Tail?
  4. Schalten Sie erst um, wenn die Shadow-Daten die Offline-Geschichte bestätigen.

Champion/Challenger ist dieselbe Idee, formalisiert. Der Incumbent ist der Champion. Das neue Modell ist der Challenger. Sie befördern den Challenger erst, wenn er unter realem Traffic gewonnen hat, nicht nur auf einem Test-Set.

Der Rollout selbst sollte stufenweise erfolgen: 1 Prozent, 5 Prozent, 25 Prozent, 50 Prozent, 100 Prozent, mit mindestens 24 bis 48 Stunden zwischen den Schritten und Überwachung der Geschäftskennzahl auf jeder Stufe. Wenn sich etwas in die falsche Richtung bewegt, pausieren Sie. Rationalisieren Sie nicht.

Engineering-Partnerschaftsmuster: Schnittstellenverträge

Das „Pickle über die Wand werfen"-Modell scheitert jedes Mal. Das funktioniert stattdessen.

Bevor Sie mit dem Training beginnen, setzen Sie sich mit dem Platform Engineer zusammen und schreiben Sie einen einseitigen Schnittstellenvertrag. Er umfasst:

  • API-Schema. Eingabefelder, Typen, erlaubte Nullwerte, Validierungsregeln. Ausgabefelder, Typen, Bereiche. Wie sieht die Antwort aus, wenn das Modell nicht scoren kann (fehlende Features, Modell-Server ausgefallen)?
  • Latenz-SLO. p50, p95, p99 in Millisekunden. Das bestimmt, ob Sie Echtzeit-Feature-Lookups durchführen können, welche Modellarchitekturen nicht in Frage kommen, ob GPU-Inferenz erforderlich ist.
  • Durchsatz-SLO. Anfragen pro Sekunde beim Spitzenaufkommen. Bestimmt die Autoscaling-Konfiguration.
  • Fehlerbudget. Wie viel Prozent der Anfragen darf der Service scheitern? 0,1 Prozent? 1 Prozent? Das legt die Messlatte für die Strenge der Input-Validierung fest.
  • Verantwortungsgrenze. Wer wird alarmiert, wenn das Modell falsche Vorhersagen zurückgibt, gegenüber wenn der Service 500er zurückgibt? DS verantwortet das Erste. Engineering verantwortet das Zweite. Beide verantworten das Dritte (Modell ist oben, aber Vorhersagen sind schlecht).
  • Rollback-Berechtigung. Wer kann die Notabschaltung ohne Eskalation auslösen? Um 3 Uhr nachts sollte die Antwort „der On-Call-Ingenieur" lauten, nicht „Camellia anpingen."

Schreiben Sie das auf. Unterzeichnen Sie es. Heften Sie es an. Wenn der unvermeidliche Produktionsvorfall eintritt, ist der Vertrag das, was das Gespräch über die Behebung des Problems hält, statt über die Aushandlung von Verantwortlichkeiten.

Der DS, der zu diesem Meeting mit einem Vertragsentwurf erscheint, gewinnt Vertrauen in dem Moment, in dem er den Raum betritt. Der DS, der mit einem Notebook erscheint und fragt „Wie deployen wir das?", startet bei null.

Rollback-Disziplin

Jedes Deployment wird mit einem getesteten Rollback-Pfad ausgeliefert. Nicht einem dokumentierten. Einem getesteten.

Drei Komponenten:

  1. Versions-Tagging. Jedes Modell erhält eine Version (pricing-model-v23). Jede protokollierte Vorhersage enthält die Version, die sie generiert hat. Wenn Sie eine Regression untersuchen, können Sie nach Version filtern.
  2. Die Notabschaltung. Ein Konfigurations-Flag, das Traffic vom neuen Modell in unter 60 Sekunden auf das vorherige zurückschaltet. Kein Redeployment. Ein Flag-Flip. Der Serving-Service liest das Flag zur Anfragezeit.
  3. Rollback-Übungen. Führen Sie jeden Quartal den Rollback in der Produktion 5 Minuten lang während eines Zeitfensters mit geringem Traffic durch. Wenn Sie den Auslöser in 90 Tagen nicht betätigt haben, ist der Rollback theoretisch, was bedeutet, dass er nicht funktioniert.

Das erste Mal, wenn Sie einen Rollback benötigen, ist nicht der Zeitpunkt, um herauszufinden, dass das Artefakt des vorherigen Modells von S3 gelöscht wurde, die Feature-Pipeline refaktoriert wurde oder die Notabschaltung nie funktioniert hat. Ich habe alle drei persönlich erlebt.

Häufige Fallstricke

  • Training auf Daten, die das Modell zum Serving-Zeitpunkt nicht sehen kann. Datenleckage. Die häufigste Form: ein Feature, das nur nach dem Ereignis berechenbar ist, das Sie vorhersagen. Ein „Tage seit letztem Login"-Feature, das aus dem Warehouse berechnet wird, enthält Logins nach dem Vorhersage-Zeitstempel, außer Sie schneiden explizit ab.
  • random_state=42 festlegen, aber den vorgelagerten Sampler nicht seeden. Ihre Splits sind deterministisch, Ihr Training nicht.
  • Deployment ohne Champion/Challenger. Sie raten, ob das neue Modell besser ist.
  • Alarmierung auf AUC statt auf Umsatz. AUC ging von 0,84 auf 0,82, schlecht? Sie wissen es nicht. Vielleicht stieg der Umsatz.
  • Kein Rollback-Test in 90 Tagen. Sie haben keinen Rollback. Sie haben einen Wunsch.
  • Engineering als Service-Desk statt als Partner behandeln. Sie werden Ihr Modell genauso behandeln.

Vorlagen und Tools

Die vier Dokumente, die jedes ausgelieferte Modell haben sollte:

  • Modellkarte. Dataset-SHA, Trainingsfenster, Seed, Feature-Schema-Version, Auswertungsmetriken auf Holdout und eingefrorener Referenz, Serving-SLO, Owner, Deploy-Datum, Rollback-Verfahren.
  • Shadow-Mode-Vergleichs-Checkliste. Verteilungsüberlappung, Offline-Online-Abgleich, Latenz, Fehlerrate, Randfallbehandlung, Sign-Off-Anforderungen pro Stakeholder.
  • Rollback-Runbook. Schritt-für-Schritt-Notabschaltung, wie man überprüft, ob das vorherige Modell Traffic serviert, wen man benachrichtigt, Nachbetrachtungsvorlage.
  • Eng/DS-Schnittstellenvertrag. Eine Seite. API-Schema, SLOs, Fehlerbudget, Verantwortungsgrenze, Rollback-Berechtigung. Unterzeichnet von DS, Engineering Lead und der On-Call-Rotation.

Erfolg messen

Sie machen es richtig, wenn:

  • Sie den genauen Trainingslauf jedes Produktionsmodells von Rohdaten aus in unter 30 Minuten erneut ausführen können.
  • Jedes Deployment mit einem getesteten Rollback verbunden ist, der in den letzten 90 Tagen geübt wurde.
  • Modellüberwachung Datendrift erkennt, bevor sich die Geschäftskennzahl bewegt, nicht danach.
  • Ihr Platform Engineer sagt: „Die Zusammenarbeit mit Ihnen ist einfach," ohne dass Sie danach gefragt haben.
  • Die letzten drei Deployments langweilig waren.

Langweilige Deployments sind das Ziel. Drama ist Scheitern. Der DS, der Langweiliges ausliefert, liefert oft, und der DS, der oft liefert, schafft schneller Wert als jeder mit einer marginal besseren Modellarchitektur.

Weiterführende Artikel