Die Umstellung von klassischem maschinellem Lernen auf Deep Learning in einer mobilen AdTech-Plattform war eines der anspruchsvollsten Projekte, die wir als Technologiepartner eines AdTech-Unternehmens umgesetzt haben. Die Demand-Side-Plattform (DSP) des Kunden nutzte maschinelles Lernen, um vorherzusagen, ob eine angezeigte Werbeeinblendung dazu führt, dass ein Nutzer klickt und eine App installiert. Mit Deep Learning erzielten wir zwar schnell konkurrenzfähige Ergebnisse bei Offline-Metriken, doch die Bereitstellung der Modelle im Produktivbetrieb brachte unerwartete Herausforderungen mit sich.
Das CloudZen-Team testete zunächst Deep-Learning-Modelle mit Keras und Vertex AI und verglich sie wiederholt mit den vorhandenen logistischen Regressionsmodellen. Im Laufe der Zeit konnten wir die Leistung verbessern und unsere ML-Pipeline modernisieren. Die Umstellung verlief jedoch nicht reibungslos: Dabei traten mehrere Vorfälle auf.
In Systemen, die auf maschinellem Lernen beruhen, lassen sich Fehler nicht vollständig vermeiden. Bei Twitch verwendeten wir für Nachbesprechungen das Fünf-W-Fragen-Modell: Wir untersuchten, was schiefgelaufen war, wann und wo es passiert war, wer beteiligt war und warum es dazu kam. Anschließend setzten wir Maßnahmen um, um Wiederholungen zu verhindern. Mit diesem strukturierten Vorgehen konnten wir unsere ML-Plattform systematisch stärken.
Acht wichtige Vorfälle und Erkenntnisse
1. Nicht trainierte Embeddings
Problem: Viele unserer bereitgestellten Modelle, darunter Modelle zur Vorhersage von Klicks und Installationen, waren schlecht kalibriert. Ihre vorhergesagten Konversionsraten lagen deutlich über den tatsächlich beobachteten Raten der ausgelieferten Werbeeinblendungen. Eine genauere Untersuchung zeigte, dass die Fehlkalibrierung bei kategorialen Merkmalen mit wenigen Trainingsdaten besonders stark war. Schließlich stellten wir fest, dass die Embedding-Schichten unseres Installationsmodells Vokabulareinträge ohne zugehörige Trainingsdaten enthielten. Einige Gewichtungen behielten daher ihre zufällig initialisierten Werte, was zu ungenauen Vorhersagen führte. Für manche kategorialen Merkmale fehlten Trainingsdaten, sodass bestimmte Gewichtungen in den Embedding-Schichten untrainiert blieben und die Modellkalibrierung verschlechterten.
Behebung: Wir begrenzten die Größe der Vokabulare und setzten nicht trainierte Embeddings auf null. Schließlich verzichteten wir darauf, Vokabulare für verschiedene Aufgaben wiederzuverwenden.
Erkenntnis: Nicht trainierte Embeddings machten die Modelle instabil. Wir entwickelten Werkzeuge, um Veränderungen der Gewichtungen zwischen Trainingsläufen zu verfolgen.
2. Padding-Problem bei TensorFlow Serving
Problem: Sparse Tensors, etwa Listen installierter Apps, wurden beim Training und bei der Bereitstellung unterschiedlich verarbeitet. Das führte zu falschen Vorhersagen.
Behebung: Wir vereinheitlichten den Umgang mit leeren Arrays in allen Pipelines. Zunächst passten wir die Trainingspipeline an die Logik bei der Bereitstellung an und ersetzten leere Arrays durch „[0]“. Das behob das Problem jedoch nur teilweise. Für eine vollständige Lösung erweiterten wir den Vokabularbereich von [0, n-1] auf [0, n], führten 0 als Platzhalter ohne eigene Bedeutung ein und fügten ihn jedem Tensor hinzu. So enthielt jeder Sparse Tensor mindestens einen Wert und konnte im Batch verarbeitet werden.
Erkenntnis: Die fehlende Abstimmung zwischen Trainings- und Bereitstellungspipeline führte zu Unterschieden bei der Merkmalsverarbeitung. Deshalb bezogen wir Data Scientists in die Prüfung von Pull Requests für die Produktionspipeline ein, um solche Probleme früher zu erkennen.
3. Bereitstellung eines nicht trainierten Modells
Problem: Ein fehlerhafter Trainingslauf erzeugte ein Modell, das durchgehend eine Klickrate von 25 % vorhersagte.
Behebung: Wir stellten die vorherige Modellversion wieder her, ergänzten Validierungsprüfungen und automatisierten das Zurücksetzen auf eine frühere Version.
Erkenntnis: Schutzmaßnahmen wie Validierungsmetriken und Echtzeitüberwachung sind unverzichtbar. Zusätzlich richteten wir in Datadog Warnungen für größere Veränderungen der Metrik p50 p_ctr ein und arbeiteten daran, das Zurücksetzen von Modellen zu automatisieren.
4. Ungeeignete Warmup-Daten für TensorFlow Serving
Problem: Warmup-Dateien und Modelltensoren passten nicht zusammen, sodass Bereitstellungen fehlschlugen.
Behebung: Wir prüften Warmup-Dateien vor der Bereitstellung gegen die Modelltensoren.
Erkenntnis: Staging-Umgebungen für TensorFlow-Modelle sind entscheidend für einen stabilen Betrieb.
5. Problematische zeitbezogene Merkmale
Problem: Relative Zeitangaben, etwa „vor einigen Wochen“, führten zu unbeabsichtigten Verzerrungen.
Behebung: Wir entfernten diese Merkmale, nachdem A/B-Tests eine bessere Leistung im Livebetrieb ohne sie gezeigt hatten.
Erkenntnis: Merkmale, die Offline-Metriken verbessern, können im Produktivbetrieb Verzerrungen verursachen.
6. Feedback-Merkmale und Fehler bei der Kennzeichnung
Problem: Ein Merkmal für Gebotspreise verstärkte Verzerrungen. Die Leistung verschlechterte sich, nachdem ein Experiment falsch positive Ergebnisse eingeführt hatte.
Behebung: Wir entfernten das Merkmal und verwendeten stattdessen andere Gebotssignale.
Erkenntnis: Feedback-basierte Merkmale können Kettenreaktionen von Fehlern auslösen.
7. Fehlerhafte Kodierung von Merkmalen
Problem: Beim Training und bei der Bereitstellung wurden Divisionen durch null unterschiedlich behandelt.
Behebung: Wir vereinheitlichten die Kodierungslogik.
Erkenntnis: Prüfungen auf einheitliche Merkmalsverarbeitung zwischen Training und Bereitstellung sind entscheidend.
8. Unterschiede bei der Verarbeitung von Zeichenfolgen
Problem: Unterschiedliche Verfahren zur Bereinigung von Zeichenfolgen führten bei kategorialen Merkmalen zu Problemen mit Werten außerhalb des Vokabulars (OOV).
Behebung: Wir vereinheitlichten die Parsing-Logik und verbesserten die Vorverarbeitung des Vokabulars.
Erkenntnis: Eine einheitliche Verarbeitung von Zeichenfolgen bei der Datenaufnahme reduziert nachgelagerte Probleme.
Die wichtigsten Erkenntnisse
- Alles überwachen: Merkmalswerte, kodierte Werte, Tensoren und Vorhersagen protokollieren, um Abweichungen zu erkennen.
- Vor der Bereitstellung validieren: Modellvalidierung und Testumgebungen einrichten, um fehlerhafte Veröffentlichungen zu verhindern.
- Fallstricke bei Merkmalen beachten: Manche Merkmale verursachen Verzerrungen oder Rückkopplungsschleifen, die die Leistung verschlechtern.
- Zusammenarbeit im Team sicherstellen: Trainings- und Bereitstellungspipelines gemeinsam prüfen, damit sie übereinstimmen.
- Bewährte MLOps-Praktiken anwenden: Methoden aus DevOps übernehmen, um Zuverlässigkeit und Reaktion auf Vorfälle in ML-Systemen zu verbessern.
Die Bereitstellung von Deep Learning im Produktivbetrieb bringt Herausforderungen mit sich. Ein solides Vorfallmanagement und kontinuierliche Verbesserungen helfen jedoch dabei, belastbare ML-Plattformen aufzubauen.
