Productiegereedheid en technische schuld van ML-systemen evalueren

Machine learning (ML) zorgt voor een revolutie in verschillende industrieën en toepassingen, variërend van de gezondheidszorg en de financiële sector tot zelfrijdende auto's en fraudedetectie. Het inzetten van ML-systemen in productieomgevingen is echter een uitdaging door verschillende factoren, zoals technische schuld en het gebrek aan productiegereedheid. Technische schuld is een voortdurende zorg voor ML-systemen en verwijst naar de cumulatieve kosten van ontwerp-, implementatie- en onderhoudsbeslissingen die worden genomen om software sneller te leveren, met de belofte deze later af te lossen. Elke technische schuld die zich opbouwt kan aanzienlijke kosten met zich meebrengen in termen van tijd, geld en prestaties. Het concept van technische schuld in ML werd voor het eerst voorgesteld in het paper: "Machine Learning: The high-interest credit card of technical debt" door Sculley, Holt et al. in 2014. Productiegereedheid verwijst naar de reeks praktijken, processen en technologieën die ervoor zorgen dat het ML-systeem betrouwbaar, schaalbaar, onderhoudbaar en veilig is.

"Technische schuld is als een creditcard. Het is makkelijk te verzamelen, maar moeilijk af te lossen." - Chris Granger.

Het evalueren van de productiegereedheid en technische schuld van een ML-systeem is cruciaal om ervoor te zorgen dat het systeem effectief en efficiënt kan werken in productieomgevingen. In deze blog definiëren we een aangepaste ML System Robustness Score, een rubriek voor het evalueren van de productiegereedheid en technische schuld van ML-systemen, met inzichten geïnspireerd op het paper: "The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction" door Eric Breck et al. We zullen de verschillende parameters/categorieën verkennen die de ML System Robustness Score vormen die we hebben geformuleerd en de tests die u in elke categorie kunt uitvoeren.

ML System Robustness Score

De ML System Robustness Score heeft als doel een uitgebreid evaluatiekader te bieden voor ML-systemen en potentiële problemen met technische schuld te identificeren. We verdelen de scoring in 6 hoofdcategorieën met 22 subcategorieën, waarin we hieronder dieper op in zullen gaan:

1. Datakwaliteit en -preparatie
2. Model training en prestaties
3. Model evaluatie en interpreteerbaarheid
4. Model deployment en monitoring
5. Infrastructuur en operations
6. Beveiliging en compliance

Datakwaliteit en -preparatie

"We hebben geen betere algoritmen. We hebben gewoon meer data."
- Peter Norvig (Amerikaans computerwetenschapper)

Het citaat van Peter Norvig vat het belang van data in ML-modellen treffend samen. De kwaliteit van de data die wordt gebruikt om het ML-model te trainen en te testen heeft een directe invloed op de prestaties, en het is essentieel om ervoor te zorgen dat de data relevant, nauwkeurig en representatief is voor het probleemdomein. Hieronder staan de belangrijkste subcategorieën van evaluatie:

1. Datakwaliteit en -integriteit: Is de data nauwkeurig, compleet, voldoende om het model te trainen en consistent?
2. Dataprivacy en -beveiliging: Is de data beschermd tegen ongeautoriseerde toegang en gebruik?
3. Databias en eerlijkheid: Is de data representatief en vrij van bias, oftewel divers genoeg om verschillende scenario's en edge cases te vertegenwoordigen?

Model training en prestaties

Het belang van model training en prestaties bij het bereiken van de gewenste resultaten kan niet genoeg worden benadrukt. De voortdurende evolutie van ML-modellen en de toenemende omvang van datasets heeft geleid tot een groeiende vraag naar krachtigere hardware om ze te trainen. De opkomst van Large Language Models (LLMs) heeft het speelveld op het gebied van natuurlijke taalverwerking volledig veranderd.

Om ervoor te zorgen dat modellen goed blijven presteren, is het cruciaal om ze regelmatig te her-trainen met nieuwe data en systemen te bouwen die verschillende typen hardware ondersteunen. Door deze aanpak te hanteren, kunnen ontwikkelaars ervoor zorgen dat de ML-modellen die ze maken up-to-date, efficiënt en in staat zijn om steeds complexere en grotere datasets te verwerken. De evaluatie van modelprestaties kan worden onderverdeeld in verschillende subcategorieën, waaronder de hieronder vermelde:

1. Modelprestatiemetrieken: Zijn de prestatiemetrieken afgestemd op de bedrijfsvereisten?
2. Modelselectie en -tuning: Zijn de juiste modellen geselecteerd en ge-finetuned?
3. Modelstabiliteit en -reproduceerbaarheid: Is het model stabiel en reproduceerbaar in de loop van de tijd?

Model evaluatie en interpreteerbaarheid

Het beoordelen van de prestaties van een ML-model aan de hand van een reeks metrieken is een integraal onderdeel van de modelevaluatie dat zorgt voor nauwkeurige voorspellingen. Aan de andere kant is modelinterpreteerbaarheid even belangrijk, omdat het ontwikkelaars en belanghebbenden in staat stelt de innerlijke werking van het model te begrijpen en geïnformeerde beslissingen te nemen op basis van de outputs. Een gebrek aan interpreteerbaarheid kan ertoe leiden dat het model wordt gezien als een "black box", waardoor het moeilijk is om de outputs te vertrouwen.

Om de prestaties van het model nauwkeurig te evalueren, moeten organisaties rekening houden met verschillende subcategorieën, waaronder de hieronder vermelde:

1. Modelinterpreteerbaarheid: Kunnen de outputs van het model gemakkelijk worden begrepen en uitgelegd? Is het model transparant en eerlijk?
2. Feature-belangrijkheid en -bijdrage: Kunnen de features van het model worden gerangschikt op belangrijkheid en bijdrage?
3. Evaluatie-omgeving: Is de evaluatiedata representatief voor productiedata en is de omgeving vergelijkbaar met de productie-omgeving?
4. Counterfactual verklaringen: Kan het model verklaringen bieden voor counterfactual scenario's?

Model deployment en monitoring

Effectieve model deployment en monitoring kunnen organisaties helpen optimale ML-testscores te behalen en ervoor te zorgen dat hun modellen in de loop van de tijd waarde blijven leveren. Overweeg deze subcategorieën:

1. Deployment-infrastructuur: Is de deployment-infrastructuur schaalbaar en betrouwbaar?
2. A/B-testing en experimenten: Wordt het model getest en gevalideerd in gecontroleerde experimenten? Is het model-rolloutproces soepel om downtime te voorkomen?
3. Monitoring en alarmering: Is er een logging-infrastructuur aanwezig? Zijn er mechanismen om de prestaties van het model te monitoren en te alarmeren wanneer er problemen optreden?
4. Model-updating: Werkt het systeem modellen automatisch bij naarmate er nieuwe data en features beschikbaar komen?

Infrastructuur en operations

We hebben gesproken over infrastructuur onder de categorie training en prestaties; infrastructuur speelt niet alleen een kritieke rol bij het efficiënt en nauwkeurig trainen van ML-modellen, maar ook bij de operations. Hieronder staan de te overwegen subcategorieën:

1. Resourcetoewijzing en -optimalisatie: Worden de resources toegewezen en geoptimaliseerd om de efficiëntie te maximaliseren en de kosten te minimaliseren?
2. Containerisatie en orchestratie: Worden de containers en diensten op een schaalbare en efficiënte manier beheerd?
3. Continuous integration en deployment: Worden wijzigingen in de codebase automatisch getest, gebouwd en gedeployed?
4. ROI-meting: Kunt u de zakelijke impact van het ML-model meten zodra het in productie draait?

Beveiliging, afhandeling van storingen en compliance

Het is de laatste en een van de belangrijkste categorieën, onderverdeeld in de volgende subcategorieën:  

1. Toegangscontrole en autorisatie: Zijn er toegangscontroles en autorisatiebeleid ingesteld om te beschermen tegen ongeautoriseerde toegang?
2. Compliance en regelgeving: Voldoet het systeem aan de relevante regelgeving en vereisten?
3. Foutafhandeling en herstel: Kan het ML-systeem elegant herstellen van storingen en fouten afhandelen die ontstaan door drift in systemen?
4. Databescherming en verschleuteling: Is gevoelige data beschermd en versleuteld in rust en tijdens overdracht?

Uw ML System Robustness Score berekenen

Voor de uiteindelijke scoring kan een bedrijf gebruikmaken van een scoringkader gebaseerd op een schaal van 0-4. Het scoringkader is conform de onderstaande tabel.

1. Een score van <25 betekent dat het ML-systeem waarschijnlijk niet gereed is en dat er veel uitdagingen moeten worden aangepakt.
2. Een score in het bereik van 25-40 is een indicator dat het huidige systeem volstaat, maar mogelijk storingspunten begint te vertonen naarmate u schaalt.
3. Een score in de categorie 40+ weerspiegelt een oplossing die robuust is en zal werken naarmate de systemen schalen.
4. Alles boven de 60 vertegenwoordigt een best-in-class oplossing binnen uw bedrijf.

Het beantwoorden van deze vragen en het uitvoeren van de tests kan een uitgebreide evaluatie bieden van de productiegereedheid van een ML-systeem en potentiële problemen met technische schuld identificeren die kunnen ontstaan tijdens de ontwikkeling en deployment van het ML-systeem. Door deze problemen in een vroeg stadium te identificeren, kunnen stappen worden ondernomen om ze te beperken of te elimineren, waardoor de totale technische schuld van het systeem wordt verminderd.

Technische schuld evalueren vergelijkbaar met softwaresystemen

Hoewel we de ML Test Rubric als basis gebruiken voor het bovenstaande scoringkader, zijn er ook andere kaders voor het evalueren van de gereedheid van ML-systemen.

Conclusie

Concluderend is het evalueren van de productiegereedheid en technische schuld van ML-systemen essentieel voor een succesvolle deployment en onderhoud. De ML Test Score biedt een uitgebreide rubriek voor het evalueren van deze factoren en omvat aspecten zoals datakwaliteit, modelprestaties, evaluatiepraktijken, operations en monitoring. De TRL's voor Machine Learning Systems en andere kaders kunnen ook aanvullende beoordelingen bieden van de volwassenheid en gereedheid van het systeem. Voortdurende monitoring en onderhoud, evenals grondige testen en validatie, zijn cruciaal om technische schuld te minimaliseren en ervoor te zorgen dat het ML-systeem productiegereed blijft.

👉

PS: Ontvang een gratis diagnose van uw ML-systeem!
Als u geïnteresseerd bent in een diagnose van uw gehele ML-infrastructuur, schrijf ons dan op founders@truefoundry.com, en we sturen u een vragenlijst vooraf; we plannen 30 minuten in om enkele vragen door te nemen die ons helpen het systeem te begrijpen.

Daarna werken we met u samen om binnen een week een gratis diagnose en benchmarking van uw ML-systeem te leveren.

Referenties

1. C. Murphy, G. E. Kaiser, and M. Arias, “An approach to software testing of machine learning applications.” in SEKE. Citeseer, 2007
2. D. Sculley, G. Holt, D. Golovin, E. Davydov, T. Phillips, D. Ebner, V. Chaudhary, and M. Young, “Machine learning: The high interest credit card of technical debt,” in SE4ML: Software Engineering for Machine Learning (NIPS 2014 Workshop), 2014
3. A Lavin, C Lee Et Al,"Technology Readiness levels for Machine Learning Systems," in Oct 2022
4. Eric Breck, Shanqing Cai, Eric Nielsen, Michael Salib, D. Sculley Google, Inc, "The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction" , 2017