Ein einflussreiches ML-Modell – wie schwer kann das schon sein?

Ein Modell zur Lösung eines geschäftlichen Anwendungsfalls zu entwickeln, klingt für uns alle nach einer großartigen Idee. Es erscheint intuitiv, dass eine Erhöhung des Engagements durch Personalisierung auf einer bestimmten Website mittels ML um 5 % die Umsätze um einige Prozent steigern wird.

Was jedoch häufig übersehen wird, sind zwei Faktoren, die dieses Projekt gefährden können:

1. Ob genügend Daten vorhanden sind, um ein Modell zu erstellen, das die Personalisierung tatsächlich um 5 % steigern kann
2. Die erforderlichen Investitionen, um dieses Modell zu entwickeln und bereitzustellen, damit es diesen Effekt dauerhaft erbringt.

Sollte es nicht einfach sein, diese beiden Dinge zu testen? Tauchen wir tief in das ein, was nötig ist, um von der Idee eines Modellbaus bis zur finalen Bereitstellung des Modells in der Produktion und der Bewertung der geschäftlichen Auswirkungen zu gelangen. Betrachten wir den Fall, dass eine Essensliefer-App die voraussichtliche Lieferzeit anzeigen möchte, sobald ein Kunde eine Bestellung auf der App aufgibt. Da wir die Lieferzeit nicht im Voraus kennen, müssen wir ein ML-Modell entwickeln, das die Vorhersage auf der Grundlage bestimmter Faktoren wie Stadt, Restaurant, Tageszeit, Entfernung vom Kunden zum Restaurant usw. treffen kann.

Anzeigen der geschätzten Lieferzeit für den Nutzer einer Essensliefer-App

Der Workflow zur Bereitstellung dieses Modells wird die folgenden Teams einbeziehen:

Projekt-Ideenfindung

Der Product Manager entwickelt das Projekt zur Schätzung der Lieferzeit. Die Erwartung ist, dass eine angemessen genaue Lieferzeit den Nutzern ein besseres Erlebnis bietet. Es wird weniger Kundenanfragen bezüglich der Lieferzeiten geben und die Gesamtzufriedenheit der Kunden sollte steigen. Das Business-Team fordert daraufhin das Data-Science-Team auf, dieses Modell zu entwickeln.

Datenerfassung

Data Scientists beginnen mit der Erfassung der historischen Daten aller getätigten Bestellungen und deren Lieferzeiten.

• In einigen Fällen wurden vorherige Daten möglicherweise nicht ordnungsgemäß protokolliert – erfassen und sammeln Sie die Daten zuerst (Product Team, Data Engineering Team).
• In einigen glücklichen Fällen sind diese Daten leicht verfügbar
• In vielen Fällen erfordert dies das Schreiben von ETL-Pipelines, um die Daten in das richtige Format zu bringen. Das Data Engineering Team schreibt die Pipelines, um die Daten im erforderlichen Format bereitzustellen.

Datenanalyse

Der Data Scientist wird dann die Daten analysieren, um zu prüfen, ob alles korrekt aussieht – keine Null- oder fehlerhaften Werte und ob alle erforderlichen Daten vorhanden sind. Sehr oft entdeckt der Data Scientist einige Fehler im Datensatz – oder es gibt fehlerhafte Daten von einigen Tagen aufgrund vorübergehender Bugs. Wir müssen die fehlerhaften Daten aussortieren, da wir nur dann ein gutes Modell bauen können. Dies kann zu einigen Iterationen mit dem Product- und Data Engineering Team führen.

Feature Engineering

Sobald die Daten gut aussehen, möchten Data Scientists in einigen Fällen eine Pipeline zur Berechnung von Features und zur Speicherung dieser Features nutzen, damit kein Training-Serving Skew entsteht und die Feature-Werte während der Inferenz leichter abzurufen sind.

Dies ist jedoch ein optionaler Schritt und wird übersprungen, wenn die Datenmenge oder die Anzahl der auf demselben Datensatz aufgebauten Modelle gering ist. Falls sich ein Team für Feature Engineering entscheidet, benötigen wir ein Pipeline-Orchestrierungssystem wie Airflow oder Prefect und eine Datenbank / einen Cache zur Speicherung der Features für den Abruf (z. B. Feast). Der Aufbau eines Feature Store ist an sich schon ein riesiges Unterfangen und erfordert erheblichen Aufwand.

Modelltraining

Sobald die Daten bereitstehen, experimentiert der Data Scientist mit verschiedenen Algorithmen, Features und Modellen, um herauszufinden, welches am besten abschneidet. Es sollen alle Metriken, Parameter und Modelle protokolliert werden, um später darauf zurückzugreifen oder sie mit anderen Teammitgliedern zu teilen. Hier kommen Experiment-Tracking und ein Modell-Metadaten-Store ins Spiel.

Model Serving

Sobald das Modell entwickelt ist, muss es als Microservice oder als Batch-Inferenz-Job gehostet werden. In unserem Fall der Lieferzeit-Vorhersage muss dies ein Echtzeit-Online-Dienst sein – es ist also wahrscheinlich sinnvoll, ihn als auto-skalierenden Dienst bereitzustellen. In diesem Fall kommt ein ML Engineer zum Einsatz, der das Modell nimmt, es in einen Flask- oder FastAPI-Dienst einbettet und das Docker-Image erstellt. Anschließend stellt der ML Engineer das Modell zusammen mit dem DevOps-Team als Microservice auf der Infrastruktur bereit.

Produktintegration

Sobald die Modell-API gehostet ist, muss das Produkt- oder Backend-Team die API in ihrem Code aufrufen, um die vorhergesagte Lieferzeit zu nutzen und in der App anzuzeigen. Dies erfordert die Zusammenarbeit zwischen den Data-Science-, Produkt- und ML-Engineering-Teams. Während dieser Zeit möchte der Product Manager möglicherweise die Vorhersagen testen, und es wäre ideal, wenn das Modell schnell mit einigen Beispieleingaben getestet werden könnte. Dazu muss eventuell eine schnelle Modell-Demo erstellt werden.

Modellüberwachung

Sobald das Modell bereitgestellt ist und im Produkt verwendet wird, benötigen wir Metriken für das bereitgestellte Modell.

1. Systemüberwachung: Dies umfasst Metriken wie CPU, Speicher, API-Latenz, Fehler und Abstürze des Modells und wird üblicherweise mit Prometheus / Grafana oder kostenpflichtigen Lösungen wie Datadog / New Relic durchgeführt. Dies wird von den Engineering-, Produkt- und Data-Science-Teams genutzt.

 2. Modellüberwachung: Dies umfasst die Metriken bezüglich der Modellvorhersage auf den eingehenden Produktionsdaten. Dies sind Daten, an denen der Data Scientist primär interessiert ist, darunter Metriken wie Modellgenauigkeit, Feature Drift, Prediction Drift usw. Dies hilft dem Data Scientist zu entscheiden, ob sich das Modell ähnlich wie beim Training verhält, ob sich die externen Eingabedatenverteilungen nicht verändert haben und ob an anderer Stelle im System keine Fehler vorliegen.

Um eine vollständige Überwachung rund um das Modell zu erreichen, sind erhebliche Anstrengungen seitens der Data-Science-, Engineering- und DevOps-Teams erforderlich.

Vollständige Automatisierung

Sobald die gesamte Überwachung geregelt ist, möchte der Data Scientist idealerweise die komplette Retraining-Schleife automatisieren. Dazu ist ein Pipeline-Orchestrierungs-Framework wie Kubeflow oder Airflow erforderlich.

Bewertung der geschäftlichen Auswirkungen:

Wir müssen dann auch die Auswirkungen dieses Modells auf die tatsächlichen Nutzerzufriedenheitsmetriken abschätzen. Einige Proxy-Metriken wären in diesem Fall die Anzahl der Kundenanfragen zu Lieferzeiten und der Gesamtzufriedenheitswert der Kunden für eine Bestellung. Die Geschäftsmetriken müssen mit den Modellmetriken zusammengeführt werden, und das Data Engineering Team wird voraussichtlich eine ETL-Pipeline schreiben, um diese Daten abzurufen und auf einem internen Dashboard-Tool für Führungskräfte darzustellen.

Zusammenfassend sind daran etwa 5 Stakeholder beteiligt:

1. Product Manager / Business-Team
2. Data Engineering Team
3. Data Science Team
4. ML Engineering Team
5. Backend Engineering Team
6. DevOps-Team

Der gesamte Prozess dauert in jedem Unternehmen leicht über 2–3 Monate und kann bei den ersten Modellen manchmal bis zu 6 Monate in Anspruch nehmen. Aufgrund der vielen beteiligten Stakeholder und unterschiedlichen Kompetenzen dauert es so lange und erfordert hohe Vorabinvestitionen, um ML effektiv nutzbar zu machen.

Wir haben noch nicht über einige der Skalierbarkeits- und Zuverlässigkeitsaspekte gesprochen, die bei diesem Prozess eine Rolle spielen. Wir hoffen, einige der folgenden Aspekte in einem zukünftigen Artikel zu behandeln.

1. Bereitstellung der Infrastruktur
2. CI / CD-Prozess
3. Modell-Experimentierung einschließlich A/B-Testing
4. Skalierbarkeit der Infrastruktur
5. Wahl der Bereitstellungsmethodik

Die Lösung besteht darin, die automatisierbaren Teile zu automatisieren und dem Data Scientist / ML Engineer die Autonomie zu geben, die meisten Schritte auszuführen, ohne alle beteiligten Tools erlernen zu müssen. In diesem Bereich tut sich derzeit sehr viel, und hoffentlich wird die Entwicklung eines einflussreichen ML-Modells in einigen Jahren genauso einfach sein wie das Erstellen einer Landingpage heute!