S04E10 - Trends in MLOps - Deel 2 - Dev

Joop Snijder en Willem Meints, Chief Data Scientist @ Aigency, zijn op de conferentie QCon San Francisco en bespreken de trends in MLOps die gepresenteerd zijn op de conferentie.

Dit is deel 2 van een driedelige serie en gaat over het Development deel van Machine Learning modellen.

Let op: De afleveringen zijn wat technischer dan wat je van ons gewend bent en zijn wat meer geschikt voor Data Scientists, Machine Learning experts en verder voor iedereen die enthousiast is over de implementatie van ML-systemen.

De volgende onderwerpen komen aan bod:

• Case van DoorDash - Hoe DoorDash (soort van Thuisbezorgd) declaratief features beschrijft en wat dit betekent
• Het verschil tussen een data catalog en een feature store 
• Real-time streaming en het concept van muffige data en wat doe je met die data
• Voorbeeld van Amazon Retail over het bouwen van machine learning modellen voor mobiele telefoons en welke ontwerpkeuzes zij gemaakt hebben.

Links

• Claypot.ai - Platform for Real-time Machine Learing
• Blog - Introducing Fabricator: A Declarative Feature Engineering Framework
• Boek - Designing Machine Learning Systems - An Iterative Process for Production-Ready Applications van Chip Huyen

Aigency
Aigency ontwerpt en ontwikkelt waardevolle, robuuste en betrouwbare Machine Learning-modellen.

Info Support
Info Support is de specialist in maatwerk software en leidend in kunstmatige intelligentie (AI).

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Schrijf je in voor onze nieuwsbrief en ontvang exclusieve toegang tot nieuws, blik achter de schermen en meer!

Transcript

0:00

Je luistert naar deel 2 van de 3-delige serie over Trends in MLOps. Mijn naam is Joop Sneijder, CTO bij ETC. Voordat we beginnen wil ik opmerken dat deze aflevering wat technischer is dan je voor ons gewend bent, maar blijf vooral luisteren en laat weten of je vaker een technische aflevering wilt luisteren. Veel plezier. Hey welkom Willem. We zitten in het mooie San Francisco op conferentie Q-con San Francisco. Nou best aardig wat gesproken wordt over machine learning, specifiek MLOps. Dat was een hele track over MLOps. MLOps is een manier om over een aanpak waarbij je een set van tools en best practices hebt om machine learning modellen te ontwerpen maken en uiteindelijk in productie te brengen. In het eerste deel hebben we het ML gehad van hoe zet je de modellen op. Nu daadwerkelijk de implementatie van de modellen, dus het dev deel en straks in deel drie komt de operations dus hoe hou je uiteindelijk je model in productie. Maar Willem voordat we beginnen misschien is het even handig dat je je voorstelt aan de luisteraar zou je dat even willen doen? Nou hoor, Ik ben Willem Wijns, ik werk als Chief AI Architect voor Agency, een onderdeel van Infosupport. Daarnaast werk ik veel als Chapter Lead op het gebied van Data & AI voor de WSDIS Unified Finance bij Infosupport. Ja, dankjewel. Willem, zou je eens kunnen beginnen? Wat op het gebied van modelontwikkeling heb je gezien voor het maken van modellen? Wat vond je cool bijvoorbeeld? Ik heb echt een pareltje, denk ik. Want de vorige aflevering hadden we het over declaratieve machine learning pipelines. En dat vond ik al helemaal fantastisch. Maar de man van DoorDash had ook een hele mooie sessie over Fabricator. DoorDash is thuisbezorgd, maar dan Amerikaans variant, hè? Ja, die bezorgen voor heel veel restaurants in Amerika, hebben heel veel data, hebben ook heel veel real-time machine learning. En omdat ze zoveel data hebben, hebben zij een tool bedacht, Fabricator, die hun in staat stelt om declaratief feature engineering pipelines samen te stellen. Een van de dingen die je moet doen voor machine learning is dat je, ja, rieuwe data uit productie moet je eerst omzetten naar iets wat het machine learning model begrijpt. We werken met wiskundige formules, dus we kunnen niet gewoon teksten erin stoppen en gewoon plaatjes erin stoppen. dan moet je toch wel wiskundige zaken op loslaten om daar getallen van te maken, wat dan de originele data representeert. En Fabricator stelt hun dus in staat om dat middels configuratie op te stellen en te hercombineren. Dat vind ik echt mooi om te zien, hoe ze dat hebben gedaan. Zou je kunnen uitleggen hoe dat declaratief werkt? Ik weet niet meer helemaal in detail hoe ze dat gedaan hebben. Ja, het komt erop neer dat zij, ze kunnen databronnen definiëren en ze kunnen dan in Fabricate aangeven, ik wil graag uit deze bron deze colom extraheren en processen op een bepaalde manier. Dus ze kunnen meerdere processing stappen aangeven, bijvoorbeeld het terugschalen van de getallen tussen 0 en 1. Ze kunnen aangeven, nou, ik wil alle 0-value's graag weg. Ik wil graag, als het gaat over tijdlopende zaken, wil ik graag running averages berekenen. En dat kunnen ze allemaal achter elkaar chainen als een soort pipeline. Waarbij je iedere keer zegt van dit wil ik, dubbele punt, en dan bijvoorbeeld inderdaad null values removen ofzo. Ja, het is ook weer dat, de vorige aflevering hadden we het daar ook over, daar hadden we, met die declinatieve pipelines kon je met YAML, kon je dan training aangeven en hoe je de features wilt verwerken in je model. In het geval van Fabricator geef je met YAML aan ik wil graag deze data source hebben en ik wil graag deze kolommen eruit hebben en daarna welke operaties je daarop los wilt laten. En Fabricator zorgt er dan voor dat het netjes wordt omgezet in code en uitgevoerd. En ze lieten ook zien wat daarachter zat, van wat zij gebruikten. Kun je daar iets over vertellen? Ja, zij gebruiken een heel mooie platform. Ray gebruiken zij. En dat is een systeem wat je in staat stelt om je code op je laptop te draaien, maar tegelijkertijd in grote clusters. Doordash doet het allemaal in hele grote clusters natuurlijk. Ze hebben heel veel data, maar ja, die tool kan dus ook op je laptop draaien. En eigenlijk is het een distributed runtime in Python. En distributed betekent in dit geval, ik kan een stuk code op de ene computer draaien, of op de andere. En Ray zorgt er dan voor dat dat automatisch gebeurt eigenlijk. Dat je dat helemaal kunt aangeven. Met één declaratie verander je je dat, hè? Ja, dat vond ik helemaal krachtig. Je begint met een gewoon Python-programma. Dan zeg je, lees deze data, pak deze kolom eruit, map deze kolom naar een ander formaat. Wat allemaal Python-functies zijn, die regulier bestaan. In bijvoorbeeld een library als Pandas of NumPy. En daarna zeg je, boven de functie die dat doet, die die data leest bijvoorbeeld, je "appen start je ray.remote". Maak er maar een remote functie van en dan zodra ik dan zeg "Ray, draai dit programma maar", dan gaat hij zelf zeggen van "oh ja maar die functie die wil ik dan hier hebben op deze node, oh die is vol, ik heb niet meer genoeg CPU beschikbaar, nou dan pak ik een tweede node en ga ik daar de tweede functie op draaien. Ja dus dat is het, dus Ray kan je dan gebruiken, maar eigenlijk hadden ze heel wat open source producten aan elkaar geknoopt, waardoor ze bijvoorbeeld dashboarding hadden van, lopen de features nog goed, is er geen degradatie in het gebruik van de features. Kan je daar nog wat over vertellen? Ja, dus zij hebben best wel een aardige stek in elkaar gezet. Een van de dingen die best wel belangrijk is, is dat je je features ook even netjes opslaat. En vaak zie je dat mensen dat nu nog in een data lake achteromgeving doen. Zij gebruiken daar Feast voor, feature store heet dat. Het idee daarachter is dat, ja, een feature store stelt je in staat om heel eenvoudig alle machine learning features, lees kolommen, netjes op te slaan en te indexeren over tijd, maar ook per entiteit. Dus wat zij dus kunnen doen in hun omgeving is zeggen van nou ik record gewoon het hele jaar door leg ik steeds alle machine learning features vast of ik ze nou gebruiken of niet, maar ze liggen vast en dan kan ik er als ik wil trainer kan ik zeggen tegen Feast ik wil graag de data van deze set klanten over het afgelopen jaar hebben en dan zoekt Feast dat op in de storage en die levert dat jou aan via een universele API. Gewoon op een normale, ja, eigenlijk met één statement kun je dat al doen. Je hoeft daar niks meer te weten over tooling zoals pandas of bestandsformaten zoals parquet, dingen waar mensen allemaal wel van gehoord hebben. Hoef je niet meer over na te denken. Dat regelen zij voor je. En dat maakt het voor data scientist en machine learning engineers heel erg eenvoudig om diezelfde features die zijn vastgelegd voor het ene model misschien ook wel te gebruiken voor het andere model. En dat is wat DoorDash heel erg veel doet. Zij gebruiken al die features over die omgeving heen. Een ander deel wat je ook ziet wat belangrijk is, het is mooi dat je de features hebt vastgelegd en dat je kan trainen, maar ja, wat heb je dan eigenlijk? Dan weet je nog niet precies waar je naar zit te kijken. Dan heb je toch ook wel weer een monitoring oplossing nodig. Zij gebruiken dan Grafana er bovenop met een aantal tools zoals Prometheus en dat soort tools om dan de boel in de gaten te houden terwijl die aan het trainen is. En dat is, ik denk voor heel veel data scientist best wel nieuw, dat je een development tool die door mensen die microservices doen en die al helemaal gewend zijn aan applicaties in productie bouwen, te gebruiken voor machine learning juist. Want ja, uiteindelijk uit een machine learning model als je aan het trainen bent, zie je je performance metric, bijvoorbeeld je precision en je recall, zie je oplopen over de tijd. Je kan dus iedere ronde die je aan het trainen bent, keurig vastleggen. En dat maakt het dan achteraf weer heel eenvoudig om terug te halen. Ging er nou goed met trainen of ging er nou niet goed? En die crossover, development, machine learning, zien we steeds meer. Ja, uiteindelijk is het allemaal, het is een soort software wat we bouwen. Alleen het bijzondere aan het stuk software is dat we de if statements, zo je wilt, dat we die aan het leren zijn. Dat is heel bijzonder eruit. Maar dat vrijwaartje totaal niet van goede monitoring, goede continuous delivery, continuous integration dingen te doen. En dat zie je dus bij DoorDash, dat ze een aantal bijzondere tools gebruiken die ofwel uit de dev komen en die bijzonder zijn in de context van data science, ofwel tools gebruiken die specifiek zijn gemaakt voor data science is, omdat dat al helemaal anders is. Maar het integreert wel heel erg mooi met elkaar wat zij hebben gedaan. Ja, en zij noemden dat product fabricator zelf intern. Ik zal in ieder geval ook een link opnemen in de beschrijving van de podcast ernaartoe. Het jammer was, ik vroeg nog van is het open source? Zo nee, want wij konden het tijdens de sessie niet vinden. Wel een hele goede blog erover, daar zullen we even naar linken. En dan zo nee, gaan jullie dat doen? En daar kwam toch eigenlijk eigenlijk een beetje het antwoord van nee we gaan het niet doen. Het was ja we denken erover na, moeilijk moeilijk moeilijk. Ik had het namelijk de spreker nog eventjes gevraagd van ja wat houdt jullie nou tegen en eigenlijk vonden ze het te hoop gedoe. Er zat wat spul, wat spul klinkt zo een beetje raar, maar er zaten delen in die ze niet naar buiten wilden brengen wat echt proprietary was en dus ik proefde eruit van dat dat niet, op korte termijn gaat het in ieder geval niet gebeuren. Nee, dat is wel heel jammer, maar tegelijkertijd ik denk dat als je de blogpost gaat lezen en je bent op dit moment op zoek naar een omgeving, dan zou je het zelf kunnen doen. Ik weet wel dat wij gebruiken ook een aantal van die tools die zij al gebruiken. Dus ja, onze klanten hebben in ieder geval wel een omgeving die dat al ondersteunt. Maar toch, toen we dat zagen, het was zo mooi aan elkaar gemaakt. Ja, absoluut. Want wat we nog niet behandeld hebben was Amundsen, die ze er ook onder hebben. Ja, daar heb ik het nog niet over over gehad. Kijk, een van de dingen waar ik zelf ook tegenaan loop in mijn dagelijks werk is dat we maken een machine learning dataset en halen we allemaal bewerkingen uit, maar als je dan naar de ruwe data kijkt daarna, dan denk je, ja wat hebben ze nou precies gedaan dan? En kan ik dit wel gebruiken? Dat is natuurlijk best wel lastig. En in de data ops wereld zijn we helemaal gewend om een datacatalogus vast te leggen. En die beschrijft keurig, ik heb deze tabellen in deze database met deze columnen en dat betekent dit en die persoon is de eigenaar en die kun je vragen. Bij machine learning hebben we dat eigenlijk nog niet helemaal. Doordash heeft daarvoor bedacht, wat als we nou een tool uit de data ops omgeving, Amundsen in dit geval, kunnen gebruiken om die datacatalogus op te bouwen. Dan is het eigenlijk niet meer een datacatalogus, maar een featurecatalogus, maar ja dat bestaat niet op deze planeet. Dus ja, De Amundsen biedt eigenlijk die optie om die features goed te beschrijven, zodat je ook naar een website toe kan gaan en kan zoeken. Ik ben op zoek naar de historie over de afgelopen 60 dagen. En die krijg je dan keurig terug. Dat maakt het leven wel heel veel makkelijker. En voor de luisteraar, wat is dan het verschil tussen die Feature Store en die Data Catalog? Oh ja, dat is wel een goeie. Je moet het zo zien. De Feature Store is eigenlijk de database en het transportmechanisme. Dus die bewaart de features en die transporteert ze naar de trainingscode, of naar productie als je dat nodig hebt om voorspellingen te doen. En de datacatalogist beschrijft wat die data betekent. Dus in de feature store staat gewoon column 0 tot en met 9 als je 10 kolommen hebt, maar die 0 tot en met 9 staan in eenmiddelszin keurig vertaald naar van ja, column 0 is het klantnummer, column 1 is hoeveel hij betaalt, column 2 enzovoort. Ja en zou je het ook zo kunnen zeggen dat in de datakataloger staat de ruwe data beschreven en in de feature store staan de features want daar zitten natuurlijk bewerkingen over. We hebben het net over bij de declaratieven dat je geen nul values eruit dat het zaken. Dat staat eigenlijk veel meer beschreven in je feature store hoe je feature eruit ziet wat je ermee kan. Dat is best wel verschillend. Kijk, als je kijkt naar... Er zijn verschillende feature stores te krijgen in de markt op dit moment. Er zijn feature stores die eigenlijk het beschrijvende gedeelte erbij in hebben zitten. En ik zeg dat is een soort hybride tussen een data-catalogus en een feature store. Als je kijkt naar bijvoorbeeld een tool als Feast, die wordt gebruikt door Dash. Dat is puur het opslagmechanisme en het transport. En die heeft geen user interface namelijk. Dat zit er gewoon niet in. Dan heb je zoiets als Amundsen echt wel nodig om die beschrijving erbij te krijgen. Dus dat is wel een heel belangrijk verschil. Dat is denk ik ook wel goed voor mensen die willen beginnen met het gebruik van een feature store. Van let op, er is heel veel te kiezen op dit moment, omdat het erg in beweging is. En wat het beste is, ja, dat moet de tijd uitwijzen. Tijd zal het leren. Dat is inderdaad wel een lastige. En ja, wij hebben allebei, hebben wij het boek van Chip Uwen gelezen. Dat zij is de auteur van Designing Machine Learning Systems. Nou ja, ik heb daar een beetje als een fan zeg maar in de zaal gezeten. Want dat boek, ook die nemen we op in de link van deze podcast. Wat mij betreft is dat het boek waar de meeste kennis, informatie per pagina in staat. Zo compact, flink boek. Ik heb het in een paar dagen uitgelezen en toen tolde echt mijn hoofd van"Dit moet ik onthouden, dat moet ik onthouden, alles aangestreept." Dus wat mij betreft is dit even het boek op het gebied van Machine Learning Systems. Het heet Designing Machine Learning Systems. Het gaat eigenlijk over envelops van voor tot achter. Zij had een presentatie over real-time streaming. En zij had het over muffige data. Dat was echt een mooie term. Stil data in het Engels. Kan jij uitleggen wat was die muffige data, waar zo'n muffige lucht van af komt? Ja, kijk, zij had een heel mooi voorbeeld erbij ook. Credit card fraude vertelde zij over en het belang van niet-muffige, van verse data eigenlijk. Want hoe muffiger, hoe lastiger. En dit idee is eigenlijk van, kijk als iemand jouw creditcard steelt, die zal zo snel mogelijk proberen dat ding te plunderen, want hoe langer die wacht, hoe sneller gaat het gebeuren dat die wordt gepakt. Als je dat nou wilt detecteren, dat je creditcard misbruikt wordt, om wat voor reden dan ook, dan heb je de geschiedenis nodig over wat is er nou in de afgelopen periode gebeurd met de creditcard. Is dat normaal gedrag of is dat wat plunderig gedrag? Nou kun je natuurlijk heel ver terugkijken en daar krijg je een heel stabiel plaatje van wat er met die geschiedenis gebeurt. Alleen dat is best muffig, want je loopt achter op de werkelijkheid. Hoe verder je terugkijkt in de geschiedenis van de creditcard, hoe ouder die data wordt en hoe minder handig dat wordt. Ja en want het ging om real time, dus het kan zijn dat het stellen van de vraag van doen wij zeg maar de de transacties van de afgelopen 10 minuten dat je daardoor de de laatste transacties mist omdat dat niet gelijk loopt. Ja. Dus je mist eigenlijk de de allerlaatste dingen dus zit je eigenlijk naar muffige data te kijken want de meest verse data heb je niet omdat er een latency probleem zit. Dus je bent niet snel genoeg in het ophalen van de gegevens ten opzichte van de transacties die plaatsvinden. Ja want dat is goed om dat erbij te vertellen. Kijk stale data gaat ook inderdaad over oudere gegevens dus in dit geval. Je kijkt verder terug. En latency speelt hier ook zeker een rol mee. Als het 10 minuten duurt om de laatste transactie in jouw machine learning model door te voeren, dan ben je ja dan heeft die persoon al 10 minuten lang iets met die creditcard kunnen doen wat niet de bedoeling was. Dus je wilt de latency zo kort mogelijk hebben en je stilnes van je data, daar wil je wel mee spelen. Want als je dat heel kort maakt, dus als je ook maar van de laatste 10 minuten data gebruikt om te kijken van wat is het patroon, dan wordt het ook heel volatiel. Dan gaat het alle kanten op. Maar ga je te lang, dan krijg je dus echt te maken met muffige oude spullen. Het is net als een brood bakken. Als je een brood net uit de oven haalt, dan zeggen ze altijd van dan moet je niet direct aansnijden, want dan deuk je hem helemaal in en dan is dat heel vervelend. Laat hem heel even afkoelen en ga hem dan lekker eten, dan is hij vers. En als je hem drie dagen laat liggen, dan kun je hem beter niet meer opeten helemaal. En dat is ook zo met data in dit geval, zeker met dit soort scenario's. En kan je je nog herinneren wat de oplossing hiervoor was? De hoe dan? Ja, daar moet ik even heel hard in nadenken. Er zat zo'n key value store tussen, dus eigenlijk op het moment dat je data binnenkrijgt, Probeer je die zo snel mogelijk al te processen, dat je hem klaar hebt staan in een key value store. Dat je latency eigenlijk zo kort mogelijk wordt dat als je die data nodig hebt, dat die klaar staat. Dat je er eigenlijk niks meer mee hoeft te doen, alleen nog maar op te halen. Dat is een soort van preprocessing, zo gauw je data binnenkrijgt. Realtime, zo snel mogelijk preprocessen in de staat waarin je hem later gaat opvragen. Ja, ik heb zoveel content gezien dat ik niet meer helemaal precies weet hoe die tool heet. Ik heb na die tijd nog... Ja, dat was Claypot.ai. Claypot.ai. O ja, dat is wel goed dat je dat zegt. Zij bouwt dat ook zelf. En het idee achter die store is dat het dus een soort streaming store is. Die je kan aansluiten op tools als Kafka. Wat je in staat stelt om data te streamen door je systeem. En Claypod kan dan op een ingesteld time frame eigenlijk dat bewaren en preproces heel snel voor je. Zodat je met zo'n laag mogelijke latency en de juiste versheid je machine en het model kan voeden. Ja, dat was heel indrukwekkend. Dus check de link, dan lees je daar meer over. Het laatste, ik denk dat we dat kort kunnen aanstippen, is dat we van Amazon Retail hebben we een presentatie gevolgd. En wat ze gedaan hebben bij Amazon Retail is dat jij kleding kan laten passen op een avatar van jezelf. Dus je krijgt een... Nou ja... Wat ze doen is dat je met twee foto's een soort van body shape scan maken. Dan gaan ze belangrijke punten van je lichaam bepalen aan de hand van een algoritme. Waardoor ze uiteindelijk daar kleding op kunnen passen. Dat je kan zien hoe een t-shirt, hoe een jas op jou staat, hoe een broek op je staat. Nou, zag er al best wel cool uit. Dat was niet misschien de beste presentatie, maar daar zaten een paar elementen in waar wij wel warm van werden. En één daarvan was hoe zij het grote probleem van... En een body scan, want je moest eerst maar eens kijken van... Staat iemand niet te ver af van de camera of te dichtbij? Kan je alle punten scannen? Passen de foto's bij elkaar? In plaats van dat ze daar één groot deep learning model van hadden gemaakt, wat je toch in de praktijk best wel wat vaker ziet, hadden ze dat in allerlei kleine problemen opgesplitst. Nou, dat staan we er ook vaak voor, hè. Zo kijken wij ook naar de problemen. Dat zagen we terug, hè, hoe ze dat gedaan hadden. Ja, ik vond dat wel heel speciaal. Het was eigenlijk... Nou, ik heb het niet vaker gehoord dat mensen het zo oplossen. En ik vond dat zij deden dat met als reden. Het paste allemaal niet op de mobiel tegelijkertijd. Dus ze hadden... - Oh, dat was een goeie, hè? Want het moest allemaal om de edge draaien. In ieder geval het bepalen van of iemand wel of niet goed voor de camera stond. Ja. - Of die in de juiste houding stond. Want je moest een beetje met je armen zo wijd staan. Net als dat je zo'n body scan krijgt op het vliegveld als je door die poortjes moet. En het bepalen van de... Of ja, die shapes deden ze ook... Nee, die deden ze in de cloud. Van de punten op je lijf. Ja, dus ze hadden een deel van hun spullen in de cloud draaien. Vooral de modellen die extra zwaar zijn, die draaien ze dan in de cloud. Maar de begeleiding voor het correct positioneren voor de camera, dat draaien ze op de mobiel. En zij hadden nog een trucje wat denk ik ook nog wel goed is om erbij te halen. dat ze zeggen van ja je start de app op en dan wordt het model gedownload naar je telefoon zodat ze ten alle tijden ook een nieuwe versie kunnen deployen mochten ze een fout ontdekken of mocht die minder accuraat worden en dat vind ik ook wel mooi dat ze dus aan de ene kant zeggen van we knippen het op in kleine stukjes en we zorgen er dan voor dat het model ook nog dynamisch opgebouwd kan worden. Dat zijn wel goede trucs. En door die modellen in kleine stukjes op te delen konden ze de modellen ook heel klein houden, want ze wilden niet te veel toevoegen aan de grootte van de app. Want ja, bij Amazon heb je niet allerlei verschillende apps, maar je hebt één app. En er zijn natuurlijk andere afdelingen die ook van alles willen in zo'n app. Dus, nou ja, door het in kleine stukjes in te delen. Eerst van, sta je goed voor de camera? Daarna heb je goede houding? En daarna konden ze het verder opsturen. Vond ik echt een hele mooie... Ja, dat is echt een mooi gemaakt oplossing. Nou, ik denk dat we zo helemaal rond zijn qua het dev gedeelte. Dus we hebben ML gehad in deel 1. Dit was deel 2, het dev deel. Wil je weten hoe het verhaal verder gaat over de ops? Hoe hou je het in productie? Blijf van luisteren. Zorg dat je Spotify ons volgt. Dan krijg je een seintje wanneer de volgende klaar staat. Wordt heel snel. En weer bedankt voor het luisteren. TV Gelderland 2021 TV Gelderland 2021