Machine Learning (ML) har affärspotential i nästan alla branscher, och därför experimenterar allt fler företag med dess värde. Experiment är nödvändiga, men skapar sällan bestående förändring och värde i ett företag. Det är först när ML-applikationen framgångsrikt sätts i produktion och en operativ setup är designad kring den som insikter och automatisering kan utvecklas dag efter dag..
Övergången från att experimentera med ML till att lansera affärskritiska ML-applikationer är ofta svår och kan skapa osäkerhet i vilken IT-organisation som helst. ML-lösningar är komplexa och det finns flera rörliga delar på spel jämfört med en vanlig mjukvaruapplikation. Det beror på att data ständigt förändras, där modellen tränas på gårdagens data men behöver appliceras på produktionsdata – morgondagens data. I jakten på att optimera ML-modeller kommer dess egenskaper, kallade hyperparametrar, också att förändras över tiden.
Ur top-down-perspektiv kan ett ML-projekt delas in i fyra faser: verksamhetsförtydligande, utveckling, implementering och drift. Många företag vill ”släppa” utvecklarna, som är företagets datavetare, från den ursprungliga ML-modellen när den går i produktion så att utvecklarna kan göra det de är bäst på, och modellen hanteras istället av en centraliserad enhet – som t.ex. ett drift- eller supportteam inom IT eller BI-avdelningen. Det kan vara en bra idé, men det är inte helt enkelt och det finns en risk att modeller i produktionen levererar dåliga prestanda och felaktiga och oavsiktliga resultat på bekostnad av affärsvärde och anseende.
Under de senaste åren har konceptet ML Ops dykt upp, som ramar in en uppsättning bästa praxis för ML-modellens livscykelhanteringsprocess. Här anpassas principer från traditionell mjukvaruutveckling till ML och bidrar till standardisering och effektivisering av processer i den mån det är möjligt. I det här blogginlägget kommer vi att föra ner ML Ops till jorden och peka ut fem element som vi tycker förbättrar chanserna att framgångsrikt lansera ML-applikationer och skörda skalbarhetsmöjligheter där de finns.
Här listar vi fem tips för att få maskininlärning i produktion
1. Upprätthåll driften
En maskininlärningsapplikation (ML) kommer ofta att producera siffror såsom försäljningsprognoser, förutsägelser om vilka maskiner som bör underhållas för att undvika haverier, eller hur grindarna vid en reningsanläggning bör justeras för att klara trycket från en kommande regnstorm. Den viktigaste aspekten av ett ML-system är att det ger giltig information till verksamheten och att lösningen är igång.
För att säkerställa att lösningen fungerar måste arbete göras med uppdateringsstrategier, återställningar och livssignaler från applikationen. Om du har en affärskritisk ML-lösning kan du inte underskatta vikten av att inkludera tester som hjälper till att säkerställa att en uppdatering inte skickas som av misstag bryter något som tidigare fungerade bra.
Det är därför viktigt att sätta på sig slutanvändarens glasögon och utforma en rad tester som verkligen kontrollerar den funktionalitet och de resultat som slutanvändaren värderar mest. Till exempel bör integrationen med databasen testas, modellens prediktiva förmåga på en känd datamängd, eller UI-funktionaliteten om den är viktig för användaren.
2. Kontinuerlig kontroll av giltighet stärker trovärdigheten
Data är grunden för varje ML-modell och, som tidigare beskrivits, är data alltid i rörelse – oavsett om det är text, bilder, ljud eller tabelldata. De grundläggande egenskaperna som kännetecknar ny data kan plötsligt skilja sig från vad modellen tränades på. Corona har till exempel gjort livet surt för många prognosmodeller i produktion, som har svårt att automatiskt hantera en så våldsam chock till data. Corona är ett tydligt exempel som vi alla kan relatera till, men många gånger ligger faran i det osynliga. En ML-modell blir ofta mindre och mindre exakt med tiden då de underliggande egenskaperna hos datan förändras.
En lösning på detta som ofta ligger inom räckhåll är att omskola modellen för att säkerställa att den anpassar sig till ny data. Om det är en fördel att automatiskt omskola en modell beror ofta på domänen, men många gånger behövs en manuell analytisk titt på modellens prestanda och egenskaper för att säkerställa att den omskolade modellen förblir giltig. För denna process är det bra att arbeta med en gulddatauppsättning som verksamheten är på mål för, validerar och kontinuerligt underhåller. Det ger ett gemensamt språk för prestation och därmed en tydligare förståelse för om omskolningen eller modelluppdateringen var en fördel eller inte.
På motsvarande sätt är det en fördel att kontinuerligt ta en självkritisk titt på ML-modellens förutsägelser. Här kan du arbeta med kontrollgrupper eller A/B-tester och därigenom belysa vad som faktiskt händer när verksamheten inte agerar på modellens resultat. Detta avslöjar självuppfyllande profetior, där t.ex. kunderna ändrar sitt beteende eftersom verksamheten kontaktar dem som ett resultat av ML-modellens förutsägelser.
3.Hitta skalningspotentialen
Utvecklingen av ML-modeller är till stor del skräddarsydd efter den individuella applikationen och själva utvecklingsfasen skalar därför dåligt över hela linjen. Sålunda kan t.ex. HR-avdelningens modell för flygrisk bland de anställda kunde endast användas sparsamt för lagerprognoser på försäljningsavdelningen. Detta gäller givetvis inte områden som mer kan betraktas som standarder, där utvecklingen av t.ex. en effektprognosmodell för en vindpark kan till stor del anpassas till nya vindkraftsparker. Som tur är finns det andra områden i näringskedjan där man verkligen uppnår skalbarhet..
Deployment
Ofta kan distributionspipelines för en ML-applikation användas direkt i nästa, eftersom många av de tekniska kraven ofta återkommer. Till exempel måste de kunna interagera med en SQL-server samt en rad molntjänster, installera vissa Python/R-paket och vara en del av ett Docker-kontext för att säkerställa stabil exekveringsförmåga över tid. Ett av de nyare tilläggen är möjligheten att konfigurera flerstegspipelines, som definierar faserna av kontinuerlig integration och kontinuerlig driftsättning baserat på källkod. På samma sätt kan konfigurationen av infrastrukturen som lösningen körs på specificeras från kod, kallad infrastruktur-som-kod, och tillsammans skapar de det perfekta ramverket för skalning, eftersom distributionspipelines är baserade på källkod som kan återanvändas.
Tillvägagångssätt
På samma sätt kan standardisering utnyttjas inom verksamheten. En ML-applikation ses ofta i sammanhang med andra dataapplikationer, där till exempel det nattliga ML-prediktionsjobbet ska köras direkt efter att data i datalagret har uppdaterats. Därför hanteras triggning och schemaläggning av applikationerna centralt och därmed kan pipelinen som hanterar ML-applikationen återanvändas över applikationerna. Processer för bland annat att sätta upp och övervaka applikationsloggning, sätta upp larm och skapa supportbiljetter kan också återanvändas.
4. Vem gör vad?
Två sätt att organisera inom data science:
Sammantaget finns det två modeller för att organisera datavetenskapliga profiler. Den centrala och funktionella organisationsmodellen, där maskininlärning och datavetenskapsprofiler är centralt placerade i en shared service-funktion. Fördelen med denna modell är att det inte blir mycket ledig tid, eftersom den kritiska massan är större och kunskapsdelning har optimala förutsättningar. Nackdelen är att datavetenskap inte är direkt knuten till ett kritiskt affärsområde, vilket gör det svårare för verksamheten att förstå hur teamet kan utnyttjas. Idéer kommer ofta från datavetenskapsteamet och kanske inte nödvändigtvis stämmer överens med verksamhetens färdplaner.
Den decentraliserade organisationsmodellen, där kompetens knyts till verksamhetens ansvar och produkter, används av många stora företag där datainsikter är centrala för deras verksamhet. Här sitter datavetenskapsprofiler vid sidan av datateknikteam, ofta under samma produktchefer, och är därmed direkt kopplade till en affärskritisk funktion. Nackdelen är att kunskapsdelning och sparring är svårare, eftersom teamet av datavetenskapliga profiler ofta är mindre i denna modell.
Givetvis kan en mix av de två modellerna användas, med större fokus på projektbaserat arbete, vilket kan introducera overhead när det kommer till kunskapsdelning och kommunikation.
Rätt val beror förstås på företagets storlek och bedömning av potentialen med datavetenskap och maskininlärning. Rätt val beror på om företaget har åtagit sig en datastrategi där datavetenskap är en integrerad del av beslutsprocessen eller om datavetenskap mer ses som en leverantör av statistik och ad hoc-analyser.
Rollfördelning för implementering:
Ansvarsfördelningen för utvecklingen av ML-modellen är tydlig. Rollfördelningen för driftsättning och drift av ML-applikationer är dock ofta under diskussion, och det finns ingen enskild ansvarsmodell som fungerar överallt. När ansvaret för modellen överförs från utvecklaren till nästa person i kedjan beror på mognadsnivån på ML i företaget, samt erfarenheterna av deployment frameworks och DevOps metoder i utvecklingsteamet. Innan ML-modellen testas i en testmiljö testas det inte riktigt var striden ska utkämpas. Detta talar för att utvecklare ska vara en viktig del av implementeringsprocessen, även för att det är svårt för andra att förstå de fel som uppstår längs vägen. Till exempel, beror det på källkoden, integration med externa tjänster, fel i Docker-bilden eller är det hårdvaran som är flaskhalsen? Nyare molnverktyg gör det lättare att öka återanvändbarheten och därigenom komma utvecklare närmare i processen.
Rollfördelning för verksamheten
I stora organisationer finns ofta en central enhet som ansvarar för driften av ML och andra dataapplikationer. Med tanke på komplexiteten kan det verka som en överväldigande uppgift att hålla igång något i produktionen som ständigt förändras och som man inte har utvecklat själv. För att komma till rätta med detta är det bra att formulera en uppsättning konkreta krav och standarder som utvecklarna ska följa innan modellen lämnas över till produktion. Lösningen bör sättas upp med loggning, larm, dokumentation av feltyper och en supportplan så det är tydligt vem som gör vad i olika scenarier. Det är även fördelaktigt att införa en Acceptance Gate, där driftteamet utvärderar om modellens stödverktyg uppfyller kraven innan driften av ML-modellen överlämnas.
5. Standarder, standarder, standarder
Precis som standarder hjälper verksamhetsteamet i överlämnandet av ML-modellen kan man arbeta med igenkännlighet och struktur i driftsättningsfasen. ML kan vanligtvis delas in i några övergripande arkitektoniska grupperingar som batch-, online- och streamingmodeller. Här kan du underhålla distributionsmallar inom varje typ som nya projekt kan använda.
Det är även en fördel att välja vanliga verktyg för till exempel kodlagring, spårning av ML-experiment, lagring av ML-modellobjekt – som AzureML, lagra privata Python-paket etc. Det kan också vara så enkelt som att säkerställa en gemensam mapp struktur och införa en kort beskrivning av hur man kommer igång med ett ML-projekt, så att utvecklare kan gå tvärfunktionellt och redan känner till mappstrukturer och filnamn. Ett exempel är Cookiecutter, som kan användas för att skapa en mall för att starta nya projekt.
Ofta ersätter ML en befintlig manuell process i en verksamhet som var lättare att förstå och hålla igång. Därför har en ML-applikation den viktiga uppgiften att göra det bättre och helst skapa synlighet kring förbättringen. Det finns en enorm potential i ML-applikationer, och tyvärr är det inte helt enkelt att utveckla modellerna eller ta itu med transformationen kring ML-modeller i produktionen.
I det här blogginlägget har vi försökt att beskriva några av de faktorer som kan visa var du kan förvänta dig återanvändbarhet och skalning inom ML-livscykeln samtidigt som vi visar vägen för att etablera robusta ML-system som är validerade, noggrant testade och hjälper verksamheten att skörda potentialen dag efter dag.
Vill du veta mer om Machine Learning och dess affärspotential?
Kontakta oss idag genom att fylla i formuläret.