True ML Talks #2 - Machine Learning Workflow @ Stitch Fix

We hebben erg bemoedigende reacties ontvangen op onze eerste aflevering van  True ML Talks. In deze serie duiken we diep in de ML-pipeline van enkele vooraanstaande ML-bedrijven, en in de aflevering van vandaag spreken we met Stefan Krawczyk.

Stefan bouwt aan DAGWorks, een collaboratief open-source platform voor data science-teams om model-pipelines te bouwen en te onderhouden, waarmee wordt ingehaakt op bestaande MLOps- en datainfrastructuur (lees hun YC Launch). Hij heeft meer dan 15 jaar ervaring bij bedrijven als Nextdoor, LinkedIn en Stitch Fix op het gebied van data en machine learning. Hiervoor gaf hij leiding aan het Model Lifecycle-team bij Stitch Fix, waar hij uitgebreide ervaring opdeed met het bouwen van self-service tooling voor een intern MLOps-machine learning platform. Hij is ook een regelmatige spreker op conferenties en de auteur van het populaire open-source framework Hamilton.

📌

Onze gesprekken met Stefan zullen draaien om vier centrale thema's:
1. Machine Learning use cases voor de organisatie.
2. Hoe het team van Stitch Fix is gestructureerd om de zakelijke resultaten te optimaliseren.
3. Uitdagingen bij de opbouw van de ML-stack, met specifieke uitdagingen die horen bij de sector.
4. Een overzicht van geavanceerde innovaties die zijn toegepast tijdens het bouwen en schalen van de ML-infrastructuur.

Bekijk de volledige aflevering hieronder:

ML Use Cases @Stitch Fix: Een online personal styling service

1. Aanbevelingssysteem → Modellen voor voorspellingen en simulaties, die een overzicht bieden van maten en toewijzingsbereiken.
2. Voorspelling en simulatie → Wanneer inkopers beslissen hoeveel kleding ze kopen, moeten ze de maten en de te bedienen populatie bepalen. Dit omvat een voorspellingscascade van elementen die intern worden gebruikt om te helpen simuleren of voorspellen. Het algoritmefunctieteam bij Stitch Fix bouwt hier modellen voor, die een overzicht bieden van maten en toewijzingsbereiken. Lees er hier meer over.
3. Intern enterprise resource planning-systeem → Stitch Fix heeft in feite een eigen intern ERP-systeem gebouwd met behulp van algoritmen. Dit systeem helpt bij het plannen van voorraad, opslag in magazijnen en het optimaliseren van verzendtarieven. Lees er hier meer over.
4. Route-optimalisatie door het magazijn → Stitch Fix heeft een team dat de routes door het magazijn optimaliseert, zodat het kortste pad wordt genomen om bestellingen te verzamelen. Deze optimalisatie helpt bij het minimaliseren van de kosten en de verwerkingstijd voor bestellingen.
5. Magazijnlogistiek → Het algoritmefunctieteam bij Stitch Fix werkt ook aan het optimaliseren van het proces van het verzamelen van kleding uit bakken om aan bestellingen te voldoen. Stitch Fix kan kosten besparen en de verwerkingstijden van bestellingen minimaliseren door dit proces te versnellen.

ML-systeemworkflow bij Stitch Fix

Stitch Fix heeft twee teams die aan hun machine learning (ML)-systemen werken: het data science-team en het platformteam.

• Data Science-team: Het data science-team, georganiseerd in verticale bedrijfstakken die verschillende onderdelen van de organisatie ondersteunen, heeft als taak modellen te bouwen om andere teams in de organisatie te helpen beslissingen te nemen.
• Platformteam: Het Platformteam bouwt abstracties en tooling zodat de data scientists minder hoeven te engineeringen om hun werk gedaan te krijgen. Het team is onderverdeeld in verschillende onderdelen, zoals Spark, Hadoop, Kafka, infrastructuur, orchestratiesysteem en omgevingen. Er is ook een team verantwoordelijk voor de recommendations-stack en microservice-deployment, evenals A/B-testen en experimenten. Het team richt zich op operationaliseringselementen, zoals het eenvoudiger maken van het trainen, deployen en onderhouden van modellen.

👉

Het Data Science-team is verantwoordelijk voor het eigenaarschap van de modellen en de resultaten. Het Platformteam zorgt voor de beschikbaarheid van de deployment-infrastructuur en de bijbehorende componenten.

Er was geen "overdracht" van het model tussen het Data Science-team en het Platformteam. Dit helpt om veel sneller veel meer iteraties met het model uit te voeren.

Toewijzing van infrastructuur beheren

De toewijzing van infrastructuur wordt beheerd door het Platformteam, dat over het algemeen eigenaar was van de quota van wat beschikbaar was. Data scientists konden nodes of andere Spark-clusters aanvragen op een UI. Er wordt een vorm van administratie bijgehouden om ervoor te zorgen dat de kosten niet ongemotiveerd uit de hand lopen. Het platformteam probeerde het mensen gemakkelijk te maken om te krijgen wat ze wilden zonder al te veel handmatig werk, en er waren teams die eigenaar waren van de quota en ervoor zorgden dat de kosten onder controle bleven.

Unieke uitdagingen in Machine Learning en MLOps bij Stitch Fix

1. Bij Stitch Fix werken meer dan 100 data scientists aan het ontwikkelen van modellen. Omdat elke data scientist eigenaar is van een model met een gemiddelde levensduur van ten minste twee jaar, waren er veel teams die veel modellen bouwden. Het mogelijk maken van eigenaarschap voor een team was een aanzienlijke uitdaging. Het platformteam bij Stitch Fix heeft veel oplossingen in-house gebouwd en maar een paar zaken aangekocht vanwege de heterogeniteit in gebruikte libraries en frameworks. Standaardisatie zou sommige platforms eenvoudiger hebben gemaakt, maar verschillende teams hadden verschillende problemen en libraries die beter pasten bij die specifieke problemen. Het platformteam bij Stitch Fix moest eigen oplossingen bouwen, zoals Model Envelope en Hamilton, omdat er geen open-sourceoplossingen waren die goed aansloten bij hun behoeften.
2. Hoewel het eenvoudig is om modellen te maken, moet iemand alle ETL's onderhouden, en als iemand het bedrijf verlaat, kan dat problemen veroorzaken. Code weggooien is verspilling, en nieuwe teamleden worden vertraagd totdat ze kunnen uitzoeken en begrijpen wat er voor hen al lag. Omdat mensen bovendien vaak voortbouwen op de modellen van andere teams om als features te gebruiken, zijn er onderlinge afhankelijkheden tussen ETL's waarmee rekening moet worden gehouden.

"Een reden waarom ik zo lang bij Stitch Fix ben gebleven, was precies vanwege die uitdagingen en het uitzoeken hoe we ze konden oplossen." - Stefan

Innovaties in het Stitch Fix ML-platform

1. Model Envelopes: Het platformteam van Stitch Fix bouwde een systeem waarmee data scientists hun modellen samen met andere noodzakelijke componenten konden verpakken en eenvoudig konden opleveren. Het is een op API's gebaseerd systeem dat veel zaken vastlegt, en met één knop en extra configuratie kunnen data scientists hun modellen in minder dan een uur in productie deployen. Het systeem maakte ook batch-jobs mogelijk en maakte het eenvoudig om modellen op een gedistribueerde manier op Spark uit te voeren.
2. Configuration-Driven ETL's: Het platformteam van Stitch Fix gebruikte YAML en Jinja om data scientists in staat te stellen het ETL-proces te beschrijven, inclusief SQL- en Python-code voor model fitting. Het idee was om het orchestratiesysteem te abstraheren en het platformteam in staat te stellen verschillende componenten uit de Docker-container te wisselen, wat het beheren en onderhouden van de codebase eenvoudig maakte.
3. Hamilton: Hamilton is een declaratief micro-framework voor het beschrijven van datastromen. Het platformteam van Stitch Fix heeft het ontwikkeld om te helpen bij feature engineering, met name voor time series forecasting, waar eenvoudig duizenden features bij komen kijken. Hamilton helpt bij het structureren van het probleem, vergelijkbaar met DBT voor SQL, maar dan voor Python-transformaties. Het maakt het mogelijk om de datastroom te beschrijven zonder Python-scripts te hoeven beheren. Functies declareren een datastroom, en de definities kunnen eenvoudig worden gedeeld en uitgevoerd in zowel offline- als online-contexten.

👉

Voor het uitwisselen van Docker-componenten probeerde het platformteam een golden API te creëren waarin data scientists konden beschrijven wat ze wilden dat er gebeurde, zonder dat ze zich zorgen hoefden te maken over platformafhankelijkheden. Dit werd gedaan via configuratiegestuurde model-pipelines, waar data scientists tekst konden aanleveren met daarin subsets van wijzigingen. Het platformteam kon vervolgens dingen wijzigen zonder dat het data scientist-team hun Docker-containers hoefde te updaten of te upgraden. Het platformteam kon ook logs of metainformatie upgraden zonder dat gebruikers hun pipelines opnieuw hoefden te deployen of te herschrijven. Dit nam de noodzaak voor teams weg om zaken te beheren en bij te werken, en stelde het platformteam in staat om efficiënter zaken te beheren en bij te werken zonder migratie te vereisen van het data scientist-team.

Het verbeteren van de bouwtijd van Docker-containers en de debugging-tijd bij remote development: strategieën toegepast bij Stitch Fix

1. Caching om het aanmaken van containers te versnellen - Het platformteam van Stitch Fix probeerde het aanmaken van Docker-containers te versnellen door libraries en omgevingen die vaak werden gebruikt te cachen. Ze voegden bijvoorbeeld caching toe om ervoor te zorgen dat als dezelfde vereisten opnieuw nodig waren, ze niet opnieuw geïnstalleerd hoefden te worden. Ze sloegen ook omgevingsbestanden op, zipten ze en haalden ze vervolgens weer op om het proces te versnellen.
2. Lokale ontwikkeling om containerbuilds en debugging-tijd te minimaliseren - Het platformteam van Stitch Fix moedigde ontwikkelaars aan om lokaal te ontwikkelen of manieren te vinden om te voorkomen dat ze moesten wachten op een volledige cyclus van bouwen, uitvoeren en debuggen van de Docker-container. Ze maakten het mogelijk om lokale loops uit te voeren voor individuele stappen van de ETL door wat data op te halen en te cachen voor ontwikkelaars, naast andere bruikbaarheidsfuncties. Deze aanpak hielp het ontwikkel- en debuggingproces te versnellen.
3. Nieuwe benaderingen verkennen om containerbuilds en debugtijd te verbeteren - Hoewel het platformteam van Stitch Fix probeerde verbeteringen aan te brengen in de build- en debugging-tijd met caching en lokale ontwikkeling, erkenden ze dat het proces sneller kon. Sommige ontwikkelaars werken aan wijzigingen in Docker om dit proces te verbeteren, vooral voor modellen. Deze aanpak omvat het aanpassen van Docker en het herstarten ervan om het beter en efficiënter te maken.

MLOps-toolingaanbevelingen van Stefan Krawczyk

Het is belangrijk om tools te kiezen op basis van zakelijke impact en SLA's. Zaken die met een enkele node kunnen worden gedaan, moeten worden geoptimaliseerd met een orchestratiesysteem. Voor dataversiebeheer en model registries kan het opslaan van zaken in S3 in een gestructureerde padstructuur en het daarin opslaan van metadata volstaan. Als het gaat om een model registry, zouden open-sourcetools zoals MLflow moeten helpen, maar er zijn ook gehoste managementoplossingen zoals TrueFoundry.

Het is belangrijk om een A/B-testsysteem in de stack te hebben om de waarde te begrijpen die het model voor de organisatie oplevert. Dit helpt bij het nemen van beslissingen over waar te investeren in MLOps-praktijken op basis van de impact die het model heeft.

Aanbevelingen voor MLOps-tools  

1. Houd rekening met de heterogeniteit in libraries en frameworks: Als er een aanzienlijke heterogeniteit is in de gebruikte libraries en frameworks, kan het bouwen van in-house oplossingen noodzakelijk zijn, omdat er mogelijk geen kant-en-klare oplossingen zijn die aan uw behoeften voldoen.
2. Standaardisatie kan sommige platforms eenvoudiger maken: Hoewel verschillende teams verschillende problemen kunnen hebben, kan standaardisatie op bepaalde tools en processen het bouwen en onderhouden van MLOps platforms eenvoudiger maken.
3. Geen open-sourceoplossingen die aan uw behoeften voldoen? Bouw uw eigen: Als er geen open-sourceoplossingen zijn die goed aansluiten bij uw behoeften, kan het bouwen van uw eigen oplossingen, zoals Model Envelope en Hamilton, noodzakelijk zijn om uw MLOps-doelen te bereiken.

Uitdagingen rond ETL in Machine Learning

In machine learning is Extract, Transform, Load (ETL) een cruciaal proces voor het omzetten van ruwe data in waardevolle inzichten. ETL in machine learning-systemen brengt echter verschillende uitdagingen met zich mee die moeten worden aangepakt.

ETL's in machine learning-systemen kunnen stilvallend falen door upstream wijzigingen, waardoor het voor dataspecialisten moeilijk wordt om inputs naar het model te herleiden, wat leidt tot problemen bij het onderhouden van ETL's. De complexiteit van ETL's groeit naverloop van tijd ook, waardoor het voor teams moeilijk wordt om bij te blijven.

DAGWorks: Een open-source ETL-platform voor data science-teams

Om de uitdagingen uit de vorige sectie op te lossen, bouwt DAGWorks aan een open-source ETL-platform voor data science-teams dat hun afhankelijkheid van engineering vermindert. De open source draait om het eerder genoemde Hamilton. Hamilton stelt dataspecialisten zonder software engineering-achtergrond in staat om code te schrijven die naar productie gaat en om machine learning ETL-artefacten te beheren op hun bestaande infrastructuur. Hamilton biedt ook een centrale featuredefinitiestore en lineage, wat helpt om debugging eenvoudiger te maken en kan worden gebruikt voor compliance-cases.

Hamilton is ontworpen als een abstractielaag die kan worden gebruikt met verschillende orchestratietools zoals Airflow of Argo. Stefan is van mening dat data scientists zich geen zorgen zouden moeten maken over de topologie van waar dingen draaien, maar zich in plaats daarvan moeten concentreren op het bouwen van modellen en iteraties. DAGWorks probeert manieren en abstracties te vinden om het gemakkelijker te maken om van datakwaliteitsleverancier te veranderen zonder dingen te hoeven herschrijven.

Hoewel Hamilton tools zoals Metaflow aanvult, probeert het deze niet te vervangen. In plaats daarvan stelt het mensen in staat om productiever te zijn bovenop die systemen door hen in staat te stellen het microniveau binnen een taak te modelleren. Over het geheel genomen probeert DAGWorks het voor data science-teams gemakkelijker te maken om machine learning ETL-artefacten te beheren en te onderhouden.

Hieronder staan enkele interessante artikelen van Stefan & zijn team:  

What I Learned Building Platforms at Stitch Fix

Deployment for Free - A Machine Learning Platform for Stitch Fix's Data Scientists

The Function, the Context, and the Data—Enabling ML Ops at Stitch Fix

Lees ons vorige bericht in de serie

‍

True ML Talks #1 - Machine Learning Workflow @ Gong

Ontdek hoe Gong, een revenue intelligence-platform, machine learning gebruikt om klantinteracties te analyseren en inzichten te bieden aan salesteams. Ontdek de uitdagingen van het beheren van ML-workflows, dataprivacy en databeveiliging.

TrueFoundry Blog TrueFoundry

‍

Blijf kijken naar de TrueML youtube-serie en lees de gehele TrueML blogserie.

TrueFoundry is een ML Deployment PaaS over Kubernetes om workflows van ontwikkelaars te versnellen, terwijl ze volledige flexibiliteit behouden bij het testen en deployen van modellen met gegarandeerde beveiliging en controle voor het infrateam. Via ons platform stellen we Machine Learning-teams in staat om modellen in 15 minuten te deployen en te monitoren met 100% betrouwbaarheid, schaalbaarheid en de mogelijkheid om binnen seconden terug te draaien - waardoor ze kosten besparen en modellen sneller in productie nemen voor echte bedrijfswaarde.