Een impactvol ML Model - hoe moeilijk kan het zijn?

Het bouwen van een model om een zakelijke usecase op te lossen klinkt ons allen als een geweldig idee in de oren. Het lijkt intuïtief dat als we de betrokkenheid kunnen vergroten via personalisatie op een bepaalde website met behulp van ML met 5%, dit de omzet met een bepaald percentage zal verhogen.

Wat echter vaak over het hoofd wordt gezien, zijn twee factoren die dit project in gevaar kunnen brengen:

1. Of er voldoende data is om een model te maken dat de personalisatie daadwerkelijk met 5% kan verhogen
2. De investering die nodig is om dat model te bouwen en te deployen, zodat het die impact op continue basis levert.

Nou, zou het niet eenvoudig moeten zijn om deze 2 dingen te testen? Laten we eens dieper ingaan op wat er voor nodig is om van een idee om een model te bouwen eindelijk tot het model in productie te komen en de zakelijke impact te evalueren. Laten we het geval nemen waarin een maaltijdbezorg-app de verwachte bezorgtijd wil tonen zodra een klant een bestelling plaatst op de app. Omdat we de bezorgtijd van tevoren niet weten, moeten we een ML-model bouwen dat de voorspelling kan doen op basis van bepaalde factoren zoals de stad, het restaurant, het tijdstip van de dag, de afstand van klant tot restaurant, enz.

Toon de geschatte bezorgtijd aan de gebruiker voor een maaltijdbezorg-app

De workflow om dit model uit te brengen zal de volgende teams omvatten:

Project-ideatie

De Product Manager zal met het project komen om de bezorgtijd te schatten. De verwachting is dat als de bezorgtijd behoorlijk nauwkeurig is, dit een betere ervaring aan gebruikers zal bieden. Er zullen minder vragen van klanten zijn met betrekking tot bezorgtijden en de algehele klanttevredenheidsscore zou moeten stijgen. Het business team zal het data science team vervolgens vragen om met dit model te komen.

Dataverameling

Data scientists beginnen met het verzamelen van de historische data van alle geplaatste bestellingen en hun bezorgtijden.

• In sommige gevallen is eerdere data mogelijk niet goed gelogd - log de data en verzamel deze eerst (Product Team, Data Engineering Team).
• In sommige gelukkige gevallen is deze data mogelijk gemakkelijk beschikbaar
• In veel gevallen vereist dit dat er ETL-pipelines worden geschreven om de data in het juiste formaat te krijgen. Het Data Engineering team zal de pipelines schrijven om de data in het vereiste formaat te krijgen.

Data-analyse

De data scientist zal vervolgens de data analyseren om te zien of alles er correct uitziet - geen null- of onjuiste waarden en of alle vereiste data aanwezig is. Vaak zal de DS een paar bugs in de dataset ontdekken - of misschien zijn er een paar dagen met slechte data vanwege enkele tijdelijke bugs. We moeten de onjuiste data wieden, want alleen dan kunnen we een goed model bouwen. Dit kan leiden tot een paar iteraties met het Product- en Data Engineering team.

Feature Engineering

Zodra de data er goed uitziet, zullen data scientists in sommige gevallen een pipeline willen hebben voor het berekenen van features en het opslaan van de features, zodat er geen training-serving skew is en het gemakkelijker is om de featurewaarden te verkrijgen tijdens inference.

Dit is echter een optionele stap en wordt overgeslagen wanneer de data of het aantal modellen dat op dezelfde dataset is gebouwd klein is. In het geval dat een team besluit om feature engineering te doen, hebben we een pipeline-orchestratiesysteem nodig zoals Airflow, Prefect en een database / cache om de features op te slaan voor retrieval (bijv. Feast). Het bouwen van een feature store is op zichzelf al een enorme onderneming en vereist aanzienlijke inspanning.

Model Training

Zodra de data helemaal klaar is, zal de data scientist nu experimenteren met verschillende algoritmen, features en modellen om te ontdekken welke het beste presteert. Ze willen alle metrics, parameters en modellen loggen, zodat ze er later naar kunnen verwijzen of ze kunnen delen met andere teamleden. Dit is waar experiment tracking en een model metadata store om de hoek komen kijken.

Model Serving

Zodra het model is gebouwd, moet het model worden gehost als een microservice of als een batch inference job. In ons geval van bezorgtijdvoorspelling moet dit een realtime online service zijn - dus het is waarschijnlijk logisch om het te deployen als een autoscaling service. In dit geval stapt een ML engineer in die het model neemt, het verpakt in een Flask- of FastAPI-service en de Docker image bouwt. Vervolgens zal de ML Engineer samen met de hulp van het Devops team het als microservice deployen op de infrastructuur.

Productintegratie

Zodra de model-API is gehost, moet het product- of backendteam de API in hun code aanroepen om de voorspelde bezorgtijd te gebruiken en te tonen in de app. Dit vereist samenwerking tussen de Data scientist-, Product- en ML Engineering teams. Gedurende deze tijd wil de Product Manager de voorspellingen mogelijk testen en het zou geweldig zijn als ze het model snel kunnen testen op enkele voorbeeld-inputs. Dit vereist mogelijk dat er snel een modeldemo wordt gebouwd.

Model Monitoring

Zodra het model is gedeployed en in het product wordt gebruikt, hebben we metrics nodig over het gedeployde model.

1. Systeemmonitoring: Dit omvat metrics zoals CPU, geheugen, API latency, fouten, crashes van het model en wordt meestal gedaan met Prometheus / Grafana of betaalde oplossingen zoals Datadog / New Relic. Dit zal worden gebruikt door het Engineering-, Product- en Data Science team.

 2. Model Monitoring: Dit omvat de metrics met betrekking tot de modelvoorspelling op de inkomende productie-data. Dit is data waar de Data Scientist voornamelijk in geïnteresseerd zal zijn en omvat metrics zoals modelnauwkeurigheid, feature drift, prediction drift, enz. Dit helpt de data scientist te bepalen of het model zich op een vergelijkbare manier gedraagt als tijdens het trainen, de externe inputdatadistributies niet zijn veranderd en of er nergens anders in het systeem bugs zijn.

Om volledige monitoring rond het model te krijgen, zal het aanzienlijke inspanningen vergen van de Data Science-, Engineering- en DevOps teams.

Volledige Automatisering

Zodra alle monitoring is geregeld, zal de data scientist idealiter de complete her-trainingslus willen automatiseren. Dit vereist een pipeline-orchestratieframework zoals Kubeflow of Airflow.

Evaluatie van Zakelijke Impact:

We moeten dan ook de impact van dit model op de daadwerkelijke gebruikerstevredenheidsmetrics inschatten. Een paar proxy-metrics in dit geval zijn het aantal klantvragen met betrekking tot bezorgtijden, de algehele tevredenheidsscore van klanten voor een bestelling. De zakelijke metrics moeten worden samengevoegd met de modelmetrics en het Data Engineering team zal waarschijnlijk een ETL-pipeline schrijven om deze data te verkrijgen en uit te zetten op een interne dashboardingtool voor business leaders om te observeren.

Om het grofweg samen te vatten, omvat dit 5 belanghebbenden:

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

Het totale proces duurt in elk bedrijf gemakkelijk meer dan 2-3 maanden en kan voor de eerste paar modellen soms wel 6 maanden duren. Het is vanwege de meerdere betrokken belanghebbenden en meerdere betrokken vaardigheden dat het zo veel tijd en initiële investering vooraf kost om ML impactvol te maken.

We hebben het nog niet gehad over enkele van de schaalbaarheids- en betrouwbaarheidsaspecten die bij het proces komen kijken. We hopen een aantal van de onderstaande aspecten in een toekomstig artikel te behandelen.

1. Provisioning van infrastructuur
2. CI / CD-proces
3. Modelexperimentatie inclusief A/B-testing.
4. Schaalbaarheid van infrastructuur.
5. Keuze van deploymentmethodologie.

De oplossing hier is om de onderdelen die geautomatiseerd kunnen worden te automatiseren en de data scientist / ML engineer de autonomie te geven om de meeste stappen uit te voeren zonder alle betrokken tools te hoeven leren. Er gebeurt veel werk in dit domein en hopelijk wordt het maken van een impactvol ML-model over een paar jaar net zo eenvoudig als het bouwen van een landingspagina vandaag de dag!