Machine Learning (ML) har forretningspotentiale i stort set alle brancher, og derfor eksperimenterer flere og flere virksomheder med værdien heraf. Eksperimenter er nødvendige, men skaber i sig selv sjældent varig forandring og værdi i en virksomhed. Den høstes for alvor først, når det lykkes at lægge ML-applikationen i produktion og designe et operations setup omkring den, så indsigterne og automatisering folder sig ud dag efter dag.
Overgangen fra at eksperimentere med ML til at søsætte forretningskritiske ML-applikationer er ofte vanskelig og kan skabe nervøsitet i enhver IT-organisation. ML-løsninger er komplekse, og der er flere bevægelige dele i spil sammenlignet med en typisk software applikation. Det skyldes, at data er i konstant forandring, hvor modellen er trænet på gårsdagens data, men skal anvendes på data i produktion - dvs. morgendagens data. I jagten på at optimere ML-modellerne vil også dens karaktertræk, kaldet hyperparametre, ændre sig over tid.
Set fra oven kan et ML-projekt inddeles i fire faser: forretningsafklaring, udvikling, deployment og operation. Mange virksomheder ønsker at ’frikøbe’ udviklerne, dvs. virksomhedens Data Scientists, af den oprindelige ML- model, når den skal i produktion, så udviklerne kan gøre det, de er bedst til, og modellen i stedet håndteres af en centraliseret enhed - som f.eks. et operations- eller supportteam i IT eller BI-afdelingen. Det kan være en god idé, men det er ikke helt simpelt og med risiko for, at modeller i produktion leverer dårlig performance samt fejlagtige og utilsigtede resultater til skade for forretningsværdi og omdømme.
De senere år er begrebet ML Ops kommet til og indrammer en række best practices for processen omkring ML model lifecycle management. Her tilpasses principper fra traditionel softwareudvikling til ML og bidrager til standardisering og strømlining af processer i det omfang, det er muligt. Vi vil i dette blogindlæg tage ML Ops ned på jorden og pege på fem elementer, som vi erfarer forbedrer chancerne for at få succes med at søsætte ML-applikationer og høste skaleringsmuligheder, der hvor de findes.
1. Keep the lights on
En ML-applikation vil ofte spytte tal ud som f.eks. salgsforecasts, prædiktioner af hvilke maskiner, der bør vedligeholdes for at undgå nedbrud eller hvordan sluserne på et rensningsanlæg bør indstilles for kunne modstå presset for et kommende regnskyl. Det absolut vigtigste ved et ML-system er, at systemet sender valide informationer ud til forretningen, og at løsningen er tændt.
For at sikre at løsningen kører, skal der arbejdes med bl.a. opdateringsstrategier, roll backs og livstegnssignaler fra applikationen. Har man en forretningskritisk ML-løsning, kan man kun undervurdere betydningen af at indarbejde tests, som hjælper med at sikre, at der ikke sendes en opdatering afsted, som utilsigtet bryder noget, der tidligere virkede fint.
Det er derfor vigtigt at tage slutbrugerens briller på og designe en række tests, som for alvor tjekker den funktionalitet og de resultater, som slutbrugeren værdsætter højest. Her skal der f.eks. testes på integrationen til databasen, modellens prædiktionsevne på et kendt datasæt eller UI-funktionaliteten, hvis den er vigtig for brugeren.
2. Løbende monitorering af validiteten styrker troværdigheden
Data ligger til grund for enhver ML-model, og data er, som tidligere beskrevet, altid i bevægelse - uanset om det er tekst, billeder, lyd eller tabulære data. De fundamentale karaktertræk, som kendetegner nye data, kan pludselig adskille sig fra det, som modellen er trænet på. Eksempelvis har Corona gjort livet surt for mange forecast-modeller i produktion, som har svært ved automatisk at håndtere et så voldsomt stød til data. Corona er et tydeligt eksempel, som vi alle kan relatere til, men mange gange ligger faren i det usete. En ML-model bliver ofte mindre og mindre præcis over tid i takt med, at de underliggende karaktertræk for data ændres.
En løsning på dette, der ofte er inden for rækkevidde, er at gentræne modellen for at sikre, at den tilpasser sig nye data. Om det er en fordel automatisk at gentræne en model afhænger ofte af domænet, men mange gange er der brug for et manuelt analytisk blik på modellens performance og karaktertræk for at sikre, at den gentrænede model fortsat er valid. Til denne proces er det godt at arbejde med et gulddatasæt, som forretningen står på mål for, validerer og løbende vedligeholder. Det giver et fælles sprog for performance og derved en mere entydig forståelse af, om gentræningen eller modelopdateringen var en fordel eller ej.
Tilsvarende er det en fordel løbende at kigge selvkritisk på ML-modellens prædiktioner. Her kan man arbejde med kontrolgrupper eller A/B tests, og derved belyse, hvad der faktisk sker, når forretningen ikke agerer på modellens resultater. Herved afsløres selvopfyldende profetier, hvor f.eks. kunderne ændrer adfærd, fordi forretningen kontakter dem som følge af ML-modellens forudsigelser.
3. Find skaleringspotentialet
Udviklingen af ML-modeller er i høj grad skræddersyet til den enkelte applikation, og selve udviklingsfasen skalerer derfor dårligt på tværs. Således vil f.eks. HR-afdelingens model for flight risk blandt de ansatte kun sparsomt kunne bruges til inventory forecasting i salgsafdelingen. Det gælder naturligvis ikke områder, som mere kan betragtes som standarder, hvor udviklingen af f.eks. en power forecast model til én vindmøllepark i høj grad kan tilpasses nye vindmølleparker. Heldigvis er der andre områder i fødekæden, hvor man virkelig opnår skaleringsevne.
Deployment
Ofte kan deployment pipelines for en ML-applikation bruges direkte i den næste, da mange af teknologikravene ofte går igen. De skal f.eks. kunne interagere med en SQL server samt en række cloud services, installere bestemte python/R pakker og indgå i en docker-kontekst for at sikre stabil eksekveringsevne over tid. Et af de nyere skud på stammen er muligheden for at konfigurere multistage pipelines, som definerer Continuos Integration og Continuos Deployment-faserne ud fra kildekode. Tilsvarende kan konfigurationen af den infrastruktur, som løsningen skal køre på specificeres ud fra kode, kaldet infrastruktur-som-kode, og tilsammen skaber det de perfekte rammer til skalering, da deployment pipelines altså bygger på kildekode, som kan genbruges.
Operations
Tilsvarende kan man drage fordel af standardisering inden for operations. En ML-applikation skal oftest ses i sammenhæng med andre data-applikationer, hvor f.eks. det natlige ML-prediction job skal køre lige efter data i data warehouset er opdateret. Triggering og schedulering af applikationerne håndteres derfor fra centralt hold, og således kan den pipeline, der håndterer ML-applikationen genbruges på tværs af applikationer. Processer for opsætning og monitorering af applikations-logging, opsætning af alarmer og oprettelse af support tickets mm. kan tilsvarende genbruges.
4. Hvem gør hvad?
Deployment
Ansvarsfordelingen for udviklingen af ML-modellen er klar. Rollefordeling for deployment og operation af ML-applikationer er derimod ofte til diskussion, og der findes ingen entydig ansvarsmodel, der virker alle vegne. Hvornår ansvaret for modellen overdrages fra udvikleren til den næste i fødekæden afhænger af modenhedsniveauet med ML i virksomheden samt erfaringerne med deployment-frameworks og DevOps metoder i udviklingsteamet. Før ML-modellen er afprøvet i et testmiljø, er den ikke rigtig afprøvet, der hvor kampen skal kæmpes. Det taler for at fastholde udviklerne som en vigtig del af deployment-processen også, da det er vanskeligt for andre at forstå de fejl, der opstår undervejs. Skyldes det f.eks. kildekoden, integrationen med eksterne services, fejl i dockerbilledet eller er hardwaren flaskehalsen? Nyere cloud-værktøjer gør det nemmere at øge genbrugeligheden og derved få udviklerne tættere i processen.
Operations
I store organisationer vil der ofte være en central enhed med ansvar for at drifte ML og andre data-applikationer. I takt med den beskrevne kompleksitet kan det virke som en uoverskuelig opgave at holde noget kørende i drift, som konstant er i bevægelse, og som man ikke selv har udviklet. Til dette formål er det godt at formulere en række håndfaste krav og standarder til udviklerne, som skal være overholdt, før modellen overgår til drift i produktionsmiljøet. Løsningen skal opsættes med logging, alarmer, dokumentation af fejltyper samt en supportplan, så det er klart, hvem der gør hvad i en række scenarier. Her er det en fordel at indføre en Acceptance Gate, hvor operationsteamet evaluerer, om modellens støtteværktøjer lever op til kravene førend, at driften af ML-modellen overdrages.
5. Standarder, standarder, standarder
Ligesom standarder er en hjælp for operationsteamet i overdragelsen af ML-modellen, kan man arbejde med genkendelighed og struktur i udviklings- og deployment-fasen. ML kan typisk inddeles i nogle overordnede arkitekturmæssige grupperinger såsom batch, online og streaming modeller. Her kan man vedligeholde deployment skabeloner inden for hver type, som nye projekter kan tage i brug.
Det er samtidig en fordel at vælge fælles værktøjer for f.eks. kodeopbevaring, tracking af ML-eksperimenter, opbevaring af ML-model objekter - som f.eks. AzureML, opbevare private Python-pakker mm. Det kan ligeledes være noget så simpelt som at sikre en fælles folderstruktur og påtvinge en kort beskrivelse af, hvordan man kommer i gang med et ML-projekt, så udviklere kan gå tværs og allerede kender mappestrukturer og filnavne. Et eksempel på sidstnævnte er Cookiecutter, som kan bruges til at lave en skabelon til opstart af nye projekter.
Ofte erstatter ML en eksisterende manuel proces i en forretning, som var mere simpel at forstå og holde kørende. Derfor har en ML-applikation den vigtige opgave at gøre det bedre og gerne skabe synlighed omkring forbedringen. Der er et enormt potentiale i ML-applikationer, og det er desværre hverken helt let at udvikle modellerne eller at imødegå transformationen omkring ML-modeller i produktion.
Vi har i dette blogindlæg forsøgt at beskrive nogle af de forhold, der kan vise, hvor du kan regne med genbrugelighed og skalering inden for ML-livscyklussen og samtidigt vise vejen til at etablere robuste ML-systemer, der er valideret, gennemtestet og hjælper forretningen med at høste potentialet dag efter dag.