Data Science prosjekter er i prinsippet software-prosjekter som bruker data og programvare for å gi innsikt og skape verdier. Å bruke god softwareutviklings-disiplin når du jobber med et Proof of Concept (POC) ved bruk av maskinlæring bør være en selvfølge, men det stopper ikke der. Data Science prosjekter er spesielle innen programvareverdenen fordi de kombinerer forskning og utvikling på måter som gjør det vanskelig å iterere på det ene aspektet uten også å iterere på det andre. 

Rigg deg for å kunne gjøre endringer fortløpende

Se for deg et Data Science prosjekt som består av noen grunnleggende trinn: 

  • Datainnsamling og forbehandling (skaffe og rengjøre historiske data) 
  • Opplæring av en maskinlæringsmodell på dataene 
  • Bruk av modellen til å kategorisere nye data som kommer inn, for eksempel salgsrapporter 
  • La sluttbrukeren (eller fageksperten) bruke denne nye informasjonen, for eksempel i et dashbord de kan få tilgang til på selskapets intranett 

Hvis det av en eller annen grunn skjer en endring i hvilke data som leveres i første trinn (la oss si at noen nye forskrifter som GDPR gjør det vanskeligere å analysere kundedata), vil dette bety at produktet som blir utgitt til sluttbrukeren må endre seg. Å trene modellen vil bli et litt annet trinn, og forskjellige resultater vises på dashboardet som fageksperter bruker i beslutningstaking. 

Min erfaring er at dette blir betydelig enklere å gjennomføre hvis teamet benytter seg av prinsippene og teknologiene som ble etablert i programvareverden under navnet «DevOps». Dette betyr at utvikling (development) og operations står i tett dialog og ofte blir gjennomført av samme teamet, som gjør det enklere å introdusere endringer eller nye moduler i et prosjekt. 

I en ikke-DevOps verden kan det å endre litt på en pipeline være et helt nytt prosjekt, som potensielt krever et nytt team av eksperter for å lage løsningen på nytt. Imidlertid kan det å sette hele systemet (og teamet) opp for iterasjon fra start gjøre det mulig å gjøre endringer som dette uten store vansker. Dette inkluderer å sørge for at maskinlæring og statistikkeksperter i teamet er klar over standarder for god programvareutvikling og er i stand til å følge dem. 

Verdi skapes ved å respondere raskt til markedet

Når prosjekter og initiativ innen maskinlæring og kunstig intelligens står i kjernen av hvordan digital virksomhet gjøres i 2020, må vi finne meningsfulle svar på spørsmålet om hvordan disse prosjektene kan oppnå målet sitt: å levere innsikt som skaper forretningsverdi. 

Produksjonsvirsomheten i Goldratts "The Goal", som først introduserte theory of constraints som hele DevOps-verden i dag bygger på, blir snudd mot lønnsomhet ved å identifisere flaskehalser i produksjonslinjen, øke kapasiteten der det er mulig og deretter sette tempo på hele produksjonen slik at flaskehalsenes kapasitet blir maksimalisert. Å kombinere utvikling og drift i DevOps har siden blitt status quo for hvordan moderne programvareorganisasjoner opererer. 

Dette gjør det mulig for utviklere å reagere raskt på markedets krav ved å gi dem mulighet til å sette koden i produksjon ofte og ved å automatisere kvalitetskontrollen. Så hvordan bruker vi disse ideene på Data Science prosjekter? Er det bare å introdusere DevOps-konseptene i prosjektene våre, enten de inkluderer problemer som maskinlæring og kunstig intelligens skal løses eller ikke? Jeg vil gjerne svare begge ja og nei. 

Akkurat som hovedpersonen fra Goldratts "The Goal" identifiserte varmebehandlingsevnen til anlegget hans som flaskehalsen på produksjonen hans, har jeg opplevd at dårlige vedlikeholdte analysescripter ble flaskehalsen i et Data Science prosjekt. Det er en reell risiko at et sted mellom en veloljet ETL-prosess for fremskaffelse av prosjektets rå data og det sterkt polerte PowerBI-dashboardet i den andre enden, er det et Python-, R- eller til og med Matlab-skript gjemt bort. Hvis dette trinnet blir implementert fra et rent analysesynspunkt, kan det være lettere sagt enn gjort å endre det for å finjustere analyseprosessen. Når det gjelder Goldratts tilnærming til lean management, kan et slikt script bli sett på som begrensningen i vårt Data Science system. 

Det er grunnen til at vi må tenke på hvordan vi kan heve kapasitetene til disse begrensningene - hvordan vi kan gjøre dem enklere å vedlikeholde, mer skalerbare og mer fremtidssikre. 

Tips til å komme i gang med DevOps for Data Science

Som IT konsulent har jeg hatt muligheten til å jobbe med Data Science prosjekter i olje- og gassindustrien, telekommunikasjonssektoren og innen financial services. Det som kjennetegner et vellykket Data Science team er at de planlegge for produksjon fra første dag, selv om prosjektet "bare" er en Proof of Concept. Dette betyr ikke at du må kjøre alt i en Kubernetes-cluster fra første dag, men du bør: 

  • Skriv kode for gjenbruk og ikke for å kjøres bare en gang, selv om det er et forskningsprosjekt 
  • Planlegg for å trene modellene på nytt, fordi de underliggende dataene vil endre seg 
  • Verdi arbeidsprogramvare høyere enn omfattende dokumentasjon, men dokumenter dokumentene dine ved å bruke et verktøy som Sphinx (for Python-prosjekter) for å generere dokumentasjon. 
  • Organiser teamet ditt tverrfunksjonelt for å skape buy-in for målet med prosjektet ditt: å skape forretningsverdi fra data. 
  • Bruk metoden “shift left” ved å gjøre det mulig for dine Data Scientister å overvåke modellytelsen både når det gjelder statistisk styrke og med tanke på om modellens prediksjoner holder deg i tråd med de etiske verdiene til selskapet ditt. 

Etter disse trinnene tror jeg at ethvert Data Science team kan komme nærmere å konsekvent levere verdi fra data. Hvis organisasjonen med suksess har drevet et lean Data Science team (eller har slet med å gjøre det), vennligst ta kontakt og del erfaringer

Lennart R. Wilke

Machine Learning Engineering Specialist

Subscription Center
Abonner på Accenture Innsikt Blog Abonner på Accenture Innsikt Blog