Velen van ons als ontwikkelaars zullen het gevoel kennen dat we worstelen met de balans tussen de tijd die we met gebruikers doorbrengen om hun behoeften te begrijpen en de tijd die we besteden aan het ontwikkelen van software. Dit is nog duidelijker in de data wetenschap, want om een effectief systeem te bouwen is veel domeinkennis van dat systeem nodig. In de afgelopen paar jaar dat ik als ML-ingenieur met verschillende data wetenschap teams heb ik mezelf vaak afgevraagd hoe ik de verantwoordelijkheden van het optimaliseren van de nauwkeurigheid van modellen en het bouwen van alle software die nodig is om dat model functioneel te maken, van elkaar kan scheiden. Mijn bescheiden mening is dat data wetenschappers prioriteit moeten geven aan de nauwkeurigheid van hun modellen, terwijl ML engineers prioriteit moeten geven aan het feit dat die modellen gebruikt kunnen worden door het bredere bedrijf.

Als algemene vuistregel bij data wetenschapsprojecten geldt: hoe meer iteraties u uitvoert, hoe beter. Laten we dus eens kijken waarom het vanaf dag 1 inschakelen van een ML-engineer u zal helpen bij het itereren, en dus uw kansen op het bouwen van een succesvol systeem zal vergroten. Om alle aspecten te behandelen, zullen we elke reden opsplitsen in drie belangrijke onderwerpen van data wetenschappelijke projecten: data, modellen en infrastructuur.

Voordat ik hierop inga, wil ik eerst even definiëren wat ik bedoel met iteratie. In dit artikel verwijs ik naar end-to-end iteraties van het volledige product, vaak inclusief stappen van: data ingestion, preprocessing, modeltraining & -evaluatie, provisioning infrastructuur, enz. Wat ik betekenen niet is een snelle model iteratie in een notebook met de aanpassing van een hyperparameter. Als u gewend bent om in een agile framework te werken, kunt u deze iteraties ook zien als project sprints.

Het bouwen van een skelet waarop u kunt itereren is de eerste prioriteit en kan een langdurig proces zijn. Dit skelet is meestal een POC die uw initiële basismodel bevat en een demo van een toepassing of manier om de uitvoer van het model te gebruiken.

Infrastructuur: Het selecteren van compatibele cloud middelen (VM's, verbindingen met verschillende data bronnen) en het ontwerpen van de cloud architectuur zijn enkele eerste overwegingen voor de ML Engineer.

Data: het verkrijgen van de nodige data om te beginnen met het bouwen van een model en ervoor te zorgen dat data uit verschillende bronnen beschikbaar is, met de optie om indien nodig nieuwe stromen te ontwikkelen.

Modellen: ervoor zorgen dat de modellen die getest worden daadwerkelijk compatibel zijn met de voorgestelde cloud architectuur voor modelimplementatie en technische vereisten (bijv. latentie, vereiste compute, vereisten voor de productieomgeving).

De ML Engineer kan in deze fase ook helpen bij het definiëren van best practices op het gebied van software engineering met versiebeheer, linting, code-architectuur, tests, enz.

Zodra u die eerste build hebt bereikt, zijn de eerste paar iteraties vaak moeilijk en langzaam. Door iteraties te versnellen, kunt u kleinere iteraties uitvoeren met een enkele functieverandering - een veel effectievere manier van ontwikkelen dan veel dingen in een model veranderen voordat u feedback krijgt.

Infrastructuur: Er kan tijd bespaard worden bij het optimaliseren van de opslag- en rekeninfrastructuur. Tijdens deze iteraties kan een ML-ingenieur kijken naar de versie van de infrastructuur zelf, met Infrastructure as Code (IaC) tooling zoals Terraform. Het gebruik van IaC maakt het mogelijk om de uitrol van infrastructuur direct te automatiseren met CI/CD-pijplijnen, de integratie van wijzigingen die in de bestaande infrastructuur moeten worden aangebracht te versnellen en verschillende cloud-omgevingen (dev, staging, productie) te creëren. Ook het gebruik van specifieke cloud componenten kan uw workflow versnellen, bijvoorbeeld het op afstand bouwen van images met behulp van GCP's Wolk bouwen.

Data: preprocessing pipelines kunnen snel gebouwd worden door data wetenschapsteams om snel tot modellering te komen. Een ML Engineer kan in deze fase helpen om uw verwerkingsquery's te stroomlijnen, of ze nu in sql, pandas, pyspark etc. zijn. Door dit in een vroeg stadium te doen, kunt u op de lange termijn veel tijd besparen op iteraties, aangezien deze code wordt uitgevoerd. veel.

Modellen: Complexe modelarchitecturen kunnen zorgen voor een langdurig trainingsproces. Wanneer een data wetenschapper naar een “model” verwijst, kan het zijn dat hij in feite verwijst naar een groep van 100 modellen die getraind zijn op verschillende segmenten van de data, elk met een SHAP-uitleg voor het afleiden van het belang van eigenschappen. Een ML-ingenieur kan zich richten op het parallel maken van de trainingspijplijn, of dat nu op een VM met multiprocessing in python is, of het verdelen van uw werklast over meerdere nodes op de cloud. Hier valt op zich nog wel aan te sleutelen, maar hier kan met verrassend weinig moeite grote winst worden geboekt. De implementatie van uw model automatiseren met een CI/CD/CT pijplijn ook uw iteraties aanzienlijk versnellen en voor herhaalbaarheid zorgen.

Een technicus hebben die het cloud budget van uw project bewaakt is van cruciaal belang, vooral voor data intensieve toepassingen.

Infrastructuur: Kosten zijn een belangrijke variabele in de infrastructuurselectie. Zodra de infrastructuur is gekozen, kunnen budgetwaarschuwingen worden ingesteld om ervoor te zorgen dat dure onderdelen nauwlettend in de gaten worden gehouden.

Data: intelligente queries en data opslag kunnen de kosten van elke iteratie ook aanzienlijk verlagen. Het samenvoegen van data moet bijvoorbeeld spaarzaam gebeuren tijdens modeliteraties.

Modellen: Door uw trainingspijplijn te parallelliseren kunt u ook besparen op uptimes van dure machines of runtime van serverloze componenten.

Het bereiken van snelle iteraties met een kwalitatieve feedbacklus in uw project is geweldig, maar als u niet elk van deze scenario's kunt replay, heeft het niet veel zin. Het hebben van een herhaalbare pijplijn betekent impliciet dat u een manier moet hebben om de runs van de pijplijn te monitoren, om runs te identificeren op basis van specifieke parameters of prestatiecijfers waarnaar u indien nodig kunt terugrollen. Door dit robuust op te zetten tijdens de ontwikkeling, kunnen data wetenschappers vrij experimenteren (zonder de beruchte Untitled12.ipynb) en wordt de pijplijn voorbereid op productiemonitoring.

Infrastructuur: Het koppelen van de versie van de trainingscode aan de versie van de infrastructuurcode is hier de “extra mijl”, maar is noodzakelijk om volledige terugdraaimogelijkheden naar een vorige run te bieden. Zorgen voor herhaalbaarheid en monitoring op basis van pijplijnruns is voor mij het essentiële eerste niveau van ML Ops waar teams naar zouden moeten streven. Cloudplatforms hebben diensten (GCP's Vertex AI (bijvoorbeeld) die snel op te zetten zijn, maar u kunt ook overwegen om de “beste van het ras”-aanpak te gebruiken met open source-tooling. De afweging is hier tussen de grotere functionaliteit van specifieke open source tools en de toegenomen complexiteit van de algehele infrastructuur van het systeem.

Data: het opslaan van alle data objecten in elk stadium van de pijplijn. Afhankelijk van de volumes wordt prioriteit gegeven aan het opslaan van trainings-/testsets van elke run.

Modellen: zoals hierboven, waarbij u alle modellen voor elke run opslaat met alle benodigde parameters en metriek. Een andere tip is om bij elke run een opmerking te loggen met wat er voor die specifieke run is veranderd om alle experimenten tijdens de ontwikkeling te loggen, zoals u zou doen met een git commit bericht.

Toen de data wetenschap opkwam, was het zeer verkennend en was er een enorme inspanning nodig met een groep software engineers om een model te implementeren zodra het goede prestaties had laten zien op historische data. Deze “industrialisatiefase” is een zeer pijnlijke ervaring, omdat de ontwikkelomgeving (platte bestanden & python-notebook) heel anders is dan de productieomgeving (geautomatiseerde data-stromen met productie data & productiecodeeromgeving). De meest succesvolle projecten waaraan ik heb gewerkt, zijn die waarbij we de productieomgeving al in een vroeg stadium zo goed mogelijk hebben kunnen kopiëren in dev. Dit verkort de productietijd en stelt u in staat om veilig te itereren in dev, waarbij u naar prod kunt deployen wanneer u tevreden bent met een iteratie.

Infrastructuur: Het emuleren van noodzakelijke productie-infrastructuur in dev is niet altijd gemakkelijk en kan kostbaar zijn. Dit is waar infrastructure as code nuttig is en u gemakkelijk tussen omgevingen kunt laten wisselen.

Data: iets dat data wetenschapsontwikkeling scheidt van traditionele software engineering of zelfs data engineering is dat data wetenschappers productie data nodig hebben in dev. Sandbox data (met uitzondering van een aantal data of met inbegrip van een aantal synthetische test data) voor reguliere data engineering is een goede praktijk tijdens de ontwikkeling, maar kan een grote verspilling van tijd voor data wetenschap en kan grote gevolgen hebben voor de hele data wetenschap pijplijn. Alleen-lezen toegang tot productietabellen is dus iets om vanaf dag 1 met uw data team over te onderhandelen.

Modellen: Vanaf het begin van het project mag er slechts één model (of modelleerbenadering) aanwezig zijn in uw productiecode. Alle experimenten moeten in notitieblokken of aparte tijdelijke scripts in een andere map blijven. Dit voorkomt dat u dode code ophoopt in uw productiecodebasis, en is gemakkelijker te onderhouden of om andere ontwikkelaars aan boord te halen.

Samengevat zouden het bouwen van modellen en het bouwen van de software rond die modellen twee prioriteiten moeten zijn vanaf het begin van elk project. Het hebben van daarom aparte stromen met verschillende verantwoordelijkheden kan teams helpen om zich op beide tegelijk te concentreren. De rol van de ML Engineer evolueert met de dag, en ik hoor graag uw mening over alles wat ik gemist heb!