Tijd doodde mijn ML model!

Iedereen van ons heeft de statistiek wel eens gehoord dat 90%, 88%, 87%, 85% of een ander bizar percentage van de ML models de productie nooit haalt. Om heel eerlijk te zijn heb ik geen idee hoe iemand dit heeft berekend en ik ben net zo in de war als deze persoon. Maar dat staat er los van. Idealiter is dat getal veel minder belangrijk dan waarom veel bedrijven moeite hebben om bedrijfswaarde te halen uit Machine Learning- tot nu toe!

Om dit te begrijpen, hebben we 1 uur durende gesprekken gevoerd met 200+ mensen in een 1-op-1 setting om de workflow van het bouwen van ML models te begrijpen, waaronder- het bedenken van business requirements, het vertalen naar sprints, dataverzameling, het bouwen van models, het gereedmaken voor productie, deployen, retrainen, A/B-testen, debuggen, monitoring, observability enz. en het sluiten van de cirkel van elke stap terug naar elke stap in deze volgorde. Dit omvat diverse perspectieven van Business leaders, Engineering leaders, Product managers, Data Scientists, DevOps, Data engineers & ML Engineers! Na deze kwalitatieve gesprekken hebben we ook een objectief onderzoek uitgevoerd om een breder beeld te krijgen van de heersende problemen; de resultaten daarvan zijn hier te vinden.

Hoewel toegepaste Machine Learning een relatief nieuw vakgebied is en er in vrijwel elk onderdeel van de pipeline problemen bestaan, was er één duidelijk en prominent thema dat uit onze gesprekken naar voren kwam-

Tijdsvertraging in en tussen elke stap van het bouwen en lanceren van ML models vermindert het vertrouwen en het moraal van engineering- & leadership-teams, wat ML Models de das omdoet!

In de softwarewereld zijn we gewend om datagestuurde beslissingen te nemen. We willen snel resultaten zien, A/B-tests uitvoeren, de kosten verantwoorden en als een project binnen een redelijke tijd niet genoeg RoI oplevert, leren we om het een halt toe te roepen. En tijd is het enige dat ML heel veel kost! Dit geldt voor bedrijven in het hele spectrum, al is het om verschillende redenen-

1. Early-stage startups (seed tot en met Series C)
2. Traditionele giganten zoals Walgreens, Target, Siemens
3. Techgiganten zoals Uber, Amazon, Netflix enz.

Laten we dit in detail bestuderen.

Early-stage startups

Het bouwen en deployen van Machine Learning pipelines vereist vaak uiteenlopende vaardigheden-

1. Het begrijpen van de business use case — typisch Product Managers
2. Data logging & processing pipelines — typisch Data Engineers
3. Model experimenteren & bouwen — typisch Data Scientists
4. Inference APIs & deployment maken — typisch ML Engineers
5. Model scaling, staging, prod pipelines — typisch het DevOps-team
6. A/B-test frameworks, Monitoring & Observability, Retraining Pipelines

Heel vaak hebben startups niet de middelen om verschillende mensen in te huren voor het hele vaardighedenspectrum. Startups denken naïef dat ze 1–2 echt slimme mensen kunnen aannemen die het allemaal al eens hebben gedaan en al de bovenstaande problemen kunnen oplossen — maar ze realiseren zich niet dat dergelijke mythische wezens buiten de dromen van de oprichter niet echt bestaan!

Uiteindelijk probeert de aangenomen data scientist of ML Engineer zich wel te houden aan het bekende spreekwoord- "in een startup doe je wat nodig is om dingen gedaan te krijgen". Maar de leercurve van technologieën in deze sector (die snel verandert) is erg steil en het kost uiteindelijk veel tijd om al deze verschillende onderdelen te leren en te implementeren. Vanzelfsprekend zijn de pipelines die door deze nieuwkomer worden gebouwd vaak niet waterdicht en beginnen ze op verschillende punten te breken, wat een reeks pleisterprojecten in gang zet — de klassieke reden voor het uitputten van engineering-capaciteit! Op dat punt neemt de gefrustreerde oprichter een hard besluit- "Goed, we zijn nog niet klaar voor Machine Learning- laten we een eenvoudig, makkelijk te onderhouden, op regels gebaseerd systeem bouwen dat gewoon werkt- terug naar de basis!"

Traditionele giganten zoals Walgreens & Target

In grote bedrijven is de reden waarom ML Models te veel tijd kosten evenzeer organisatorisch (of zelfs meer) als technisch. Typisch zal een business user- misschien van een Customer Success- of een Sales-team uit een klantgesprek komen en een idee bedenken voor een Machine Learning-project. Dit gaat door vertaalslagen van Product Managers, middelenallocatie & sprint planning meetings voordat het uiteindelijk in de handen van een Data Scientist belandt. Laten we aannemen dat dit idee een van de eenvoudigere was waarbij de organisatie de data die in het model moet worden ingevoerd al beschikbaar had (bijvoorbeeld de clickstream van gebruikers).

De data scientist bouwt vervolgens het model, maar heeft geen manier om snel feedback te krijgen van de business user, omdat-

1. Het notebook te technisch is voor mensen uit de business
2. Resultaten opgeslagen in Excel-sheets niet interactief zijn
3. Data scientists typisch niet de vaardigheden hebben om het model snel te hosten en een API beschikbaar te stellen.

Hoe weet de DS zonder feedback van de business user-

• Of hun model het probleem oplost dat de business user heeft gevraagd, of dat de intentie verloren is gegaan in de vertaling?
• Of ze kritieke randvoorwaarden missen die, als ze worden vergeten, de klant woedend zouden maken?
• Of ze databronnen gebruiken die vooringenomenheid (bias) in het model kunnen introduceren of bepaalde gebruikerssegmenten negatief kunnen beïnvloeden?

Zelfs als al het bovenstaande op zijn plek valt- wie weet er zeker dat het initiële vermoeden van de business user juist was? De ultieme feedback kan alleen van de eindgebruiker komen. Maar hoe krijg je het model in de handen van de eindgebruiker?

Ja, je raadt het al- je moet het engineering- & productteam erbij betrekken. Er zullen opnieuw meetings zijn over de allocatie van middelen, sprint planning en uiteindelijk zal het model in het product worden geïntegreerd. Dit kan maanden duren en tegen die tijd kan de business user zich realiseren dat de prioriteit van het product is veranderd! En dan komt de vreselijke uitspraak- "Geen zin om meer middelen in dit project te steken- laten we geen goed geld naar kwaad geld gooien!"

Techgiganten zoals Uber & Amazon

Het hoeft geen betoog dat deze bedrijven het verst voorop lopen en ze doen er heel vaak geen maanden over om ML Models naar productie te brengen. Maar zelfs bij deze topbedrijven is het niet ongehoord. En zij hebben een heel uniek probleem in deze context.

Grote techgiganten bouwen heel vaak hun eigen MLOps platform dat alles doet, van het bouwen van feature stores tot algoritme-implementaties, dependency management, deployment, model inference en meer. Het bouwen van dergelijke generieke platformen die voor alle use cases werken is een lastig engineering-probleem en deze systemen nemen uiteindelijk aannames aan in de vorm van-

1. Dit zijn de meest gebruikelijke libraries waarvan we verwachten dat data scientists ze gebruiken
2. Zolang de Data Scientist "out-of-the-box" algoritmes gebruikt, werkt alles naadloos, maar als ze hun eigen model willen ontwikkelen, moeten ze stap X, Y & Z uitvoeren.

Laten we deze aannames onderzoeken en beargumenteren dat deze aannames niet praktisch zijn — ML-algoritmes en toolsets verbeteren voortdurend en geavanceerde oplossingen zijn precies wat nodig is voor de baanbrekende problemen waaraan deze bedrijven werken. Dit betekent dat hoe meer het bedrijf probeert ML-heavy te zijn, hoe meer het maatwerkoplossingen nodig zal hebben en hoe groter de noodzaak om toegewijde engineering-capaciteit in te zetten!

Om deze reden nemen data science-teams heel vaak genoegen met out-of-the-box oplossingen, wat grote alternatieve kosten (opportunity costs) met zich meebrengt. Als de Data Scientist of het bedrijf besluit om de moeilijkere weg te kiezen, d.w.z. hun platform verder ontwikkelen en het bouwen van geavanceerde maatwerkoplossingen mogelijk maken- raad eens, dan moet je een business case maken, de juiste middelen krijgen, praten met mensen van verschillende afdelingen. Of het nu resulteert in een verbeterd platform of niet, het zorgt gegarandeerd voor vertragingen!

En als na veel van deze investeringen de dingen niet lopen zoals gepland wanneer het naar de gebruiker wordt gelanceerd, ontstaat er een bevestiging om voor het volgende project de eenvoudigere out-of-the-box route te kiezen.

Conclusie & Volgende Stappen

Dit thema dat ML models om verschillende redenen "te veel tijd" kosten, kwam heel duidelijk naar voren in al onze gebruikersgesprekken.

1. Een startup die niet over al de menselijke middelen en toolkit beschikt en niet te veel tijd heeft om te itereren en de optimale oplossing uit te zoeken- neemt genoegen met op regels gebaseerde systemen wanneer ML-projecten worden geschrapt!
2. Grote traditionele bedrijven met organisatorische uitdagingen schrappen ML-projecten omdat het te lang duurde voordat ze tot leven kwamen en ze er vaak niet in slagen om een te verantwoorden zakelijke impact te creëren.
3. Moderne techbedrijven met MLOps platforms die zijn geoptimaliseerd voor productie, maar niet zozeer voor open experimenten, nemen uiteindelijk genoegen met "out-of-the-box" ondersteunde algoritmes & libraries. Het benutten van het volle potentieel van Machine Learning kost anders te veel tijd.

We waren versteld om dit gemeenschappelijke thema te zien bij een zo breed spectrum aan bedrijven-

Dat ML models te veel tijd kosten en dat zakelijke impact en feedbackcycli worden vertraagd, is een van de voornaamste redenen waarom veel ML models het daglicht niet zien.

Wij geloven dat als we een oplossing kunnen bieden die naadloze communicatie tussen business users & data scientists mogelijk maakt, evenals snelle feedback van consumenten om de zakelijke impact te verifiëren voordat er veel organisatorische middelen aan ML-oplossingen worden besteed, dit het vertrouwen in en de investeringen in Machine Learning zal vergroten- en die investeringen ook veel waardevoller zal maken.

We beweren nog geen volledige oplossing voor het probleem te hebben, maar we werken eraan. We praten met slimme mensen en onderzoeken hoe we dit probleem kunnen verminderen, zo niet volledig kunnen oplossen.

We zijn er van overtuigd dat een zo groot probleem vraagt om het samenbrengen van diverse perspectieven. Als je jezelf herkent in dit probleem, of gedachten wilt delen, of ideeën hebt over hoe het probleem op te lossen, of onze ideeën wilt horen, nodigen we je van harte uit om te reageren of met ons te komen praten.

Ik ben persoonlijk te bereiken op- nikunjbjj@gmail.com. En hier is de LinkedIn van mij en mijn mede-oprichters-

• Nikunj Bajaj
• Abhishek Choudhary
• Anuraag Gutgutia

Deze blog werd voor het eerst gepubliceerd op Medium op https://medium.com/@nikunjbajaj/time-killed-my-ml-model-48521fad6c4 op 30 aug. 2021