Hvordan lykkes med AI: Realisering

13/01/21

Aurora Voje

- Eksperimentelle feil og bommerter kan resultere i innovasjon. Det har vi sett gang på gang. Så gi datautviklerne tid til å løse problem med AI. Det er gull verdt for bedriften om det gjøres riktig, sier Aurora Voje som hjelper bedrifter i Norge med å skape verdi fra data.

Applikasjoner med innskudd av kunstig intelligens har blitt vanlig i våre liv. – Flere bedrifter satser på utvikling av AI-løsninger, men det er mange fallgruver, forteller Aurora Voje, Senior Data Scientist i PwC. Her er guiden til hvordan du får det til i din bedrift!

Applikasjoner med AI låser opp mobilen vår med ansiktsgjenkjenning, forstår talen vår via den digitale assistentens innebygde talegjenkjenning og omsetter ord til praktiske handlinger, tipser oss om hvilke serier, filmer og musikk vi kommer til å like, oversetter språk, og gir oss fremtidsprognoser. Dette er bare noen få eksempler, og antallet av implementerte AI-løsninger vokser raskt. 

AI-løsninger krever dette : Data og prediktiv modell. Og litt til.

AI – løsninger er programvareprodukter med en intrikat vri. I tillegg til å inneha en standard programvarekomponent, er løsningen avhengig av en datakomponent og en prediktiv modellkomponent. For å sy disse sammen til et funksjonelt produkt kreves det følgende grunnpilarer i tillegg til en god idé; organisatorisk forankring , implementert IT- og dataarkitektur, og data av god nok kvalitet for oppgaven som skal gjennomføres. Sist men ikke minst – det kreves også at selve utviklingen går gjennom spesifikke faser, og at disse håndteres av personell med rett faglig kompetanse.

Maskinlæringsmaskineriet er hjernen i AI-løsninger. Seks steg for å komme i mål: 

  1. Basert på problemdefinisjon bygger du et datasett. 

  2. Dette deles så i flere deler, hvor den ene brukes til modelltrening, og resterende data brukes til å teste modellens treffsikkerhet. 

  3. Deretter velger du en algoritmehovedgruppe tilpasset problemstillingen, og flere modellprototyper bygges og trenes på data. 

  4. Modelltrening gjentas til prediksjonsevnen tilfredsstiller visse krav. 

  5. Når dette er gjort, settes modellen i produksjon. 

  6. Etter en tid i produksjon vil modellens prediksjonsevne svekkes, og den må trenes på nytt med oppdaterte data.

For å bygge og opprettholde maskinlæringsmaskineriet må produktet gjennom tre ulike faser; Konseptutvikling, integrasjon og monitorerings- og vedlikeholdsfasen. Disse fasene har hver sine fallgruver som mange bedrifter og organisasjoner faller inn i. Det er vanskelig å vite på forhånd hva som kan gå galt, når man ikke har jobbet med problemstillingene før.

Konseptutviklingsfasen - ideen, dataen, modellen og organisasjonen:

Ideen: Sett av nok(!) tid til datautforskning

Realisering av all art starter alltid med en tanke eller en idé. Et Data Science prosjekt i konseptutviklingsfasen begynner med å undersøke om en konseptuell problemstilling bør og kan løses ved hjelp av data og maskinlæringsalgoritmer.

Teamet som skal få den praktiske ballen til å rulle er typisk en konstellasjon av fagpersoner med en spesifikk domenekompetanse, dataforskere (Data Scientists) med analytisk kompetanse og dataingeniører med teknisk datakompetanse. Disse skal sammen jobbe med å bygge datasett som er riktig fra både et datateknisk, statistisk og et domenespesifikt perspektiv. – En typisk fallgruve mange bedrifter går inn i, er at Data Scientist ikke får tilstrekkelig tilgang på domenekompetanse, og må gjette seg frem til en sammenstilling og tolkning av data. En tydelig anbefaling her er å sette av tilstrekkelig med tid og ressurser med domenekompetanse tidlig, slik at tiden går til datautforskning, og ikke organisasjonspløying etter faglige ressurser, sier Aurora Voje, Senior Data Scientist i PwC. 

Skal du lykkes, må du eksperimentere!

Når man jobber med konseptutvikling bør teamet være forankret av en eksperimentell tankegang og metodikk. Sitter man på bestillerens side av bordet, må man være klar over at prosjektet i løpet av utforskningsfasen kan gå gjennom en potensiell re-definisjon av selve idéen, eller at utforming av en annerledes problemstilling må til, rett og slett fordi dataen krever det. En eksperimentell organisatorisk tankegang og en eksperimentell arbeidsmetodikk er per nå ikke implementert i alle bedrifter og organisasjoner. - Dersom man vil lykkes med datadrevet produktutvikling anbefaler jeg sterkt å bruke denne metodikken, sier Voje.  

Undersøkelser viser at hyppig eksperimentering innen en bedrift vil på sikt være mer lønnsomt, enn å eksperimentere lite, sjeldent eller aldri. Eksperimenterer man aldri vil man ikke feile der og da, men man vil heller ikke komme nye steder. Den eksperimentelle tankegangen handler om å være inneforstått med at de fleste testene vil feile, og at bare noen få, og kanskje tilfeldige, forsøk kan gi bemerkelsesverdige resultater. Eksperimentelle feil og bommerter kan dessuten også resultere i innovasjon, hvilket vi har sett gang på gang gjennom historien. Den eksperimentelle prosessen må fra bedriftens side anses som mulighet for vekst og læring istedenfor som tap av kostbar tid og ressurser. Dette igjen krever endring av organisasjons- og bedriftskultur, og at ansatte over hele kommandolinjen er nysgjerrige, lærevillige og har et åpent sinn. Denne prosessen åpner dessuten for datadrevet forankring, som vil enten bekrefte eller avkrefte synsing. Eksperimentell arbeidsmetodikk kommer hånd i hånd med Data Science. Som eksempel kan Hypotese- og A/B testing, deskriptiv og prediktiv analyse nevnes.

Den essensielle datakvaliteten

Uten data av god nok kvalitet for utfordringen som skal løses, ingen AI. Data må innhentes og pre-prosesseres, slik at maskinlæringsalgoritmen forstår den. Innhenting av data fra ulike kilder, undersøkelse av kvalitet og generell datavask, og deretter sammenstilling og bygging av datasett er en tidkrevende prosess.-  Ofte viser det seg at man trenger større datamengder, bedre oppløsning, eller andre typer data enn det bedriften selv eier. Det kan innebære økt kostnad og investering. Dessuten er det usikkert at dataen man kjøper vil være av høy relevans for modellens prediksjonsevne. Man vet ikke før man har testet, og analysert modellen, sier Voje. I tillegg er det viktig å gi dataforskerne tilgang til ekte data fortest mulig. Å bygge modeller på ekte data i stedet for enkeltfiler og fragmenterte uttrekk med manglende versjonshåndtering introduserer komplikasjoner med å lose prosjektet over i integrasjonsfasen. 

Slik får du orden på dataene dine

Modellen trenes opp til å bli god til en ting

Data Science, maskinlæring og AI er ikke magi. Selv i eksperimentelle prosjekter er det viktig å tidlig etablere en forventningsavklaring til hva maskinlæringsmodellene predikerer. Mange bedrifter som bestiller maskinlæringsmodeller, blir ofte skuffet over leverandørene ved at modellene ikke besvarer alle spørsmål slik de hadde håpet. Det er essensielt å vite at en maskinlæringsmodell per nå er en såkalt «Artificial Narrow Intelligence» (ANI), og trenes opp til å bli god på kun én oppgave. – Dersom man har utviklet en prediksjonsmodell som forteller at noe vil skje med en viss sannsynlighet, vil den ikke kunne svare på spørsmålet hvorfor dette skjer, uten videre ekstensiv manuell modellanalyse, forteller dataforskeren. 

Integrasjonsfasen – en tidkrevende skreddersøm

Integrasjonsfasen er en kritisk overgangsfase hvor utforskingsteamet samarbeider med integrasjonsteamet om å omskrive eksplorativ kode til produksjonskode. Eksplorativ kode er ofte rotete, manuell og kjører sakte. Teamets oppgave er å generalisere, automatisere og optimere den. Denne typen kode skal skrives for dataflyter (data pipelines) og modellflyter (model pipelines). Teamet består av dataforsker (Data Scientist), dataingeniør fra utforskningsfasen og maskinlæringsingeniør. På store prosjekter er det naturligvis flere av hver rolle. Maskinlæringsingeniører er en nyere og etterspurt rolle, og jobber primært med skalering, automatisering og integrering av maskinlæringsmodeller inn i bedriftens data- og IT-arkitektur. Dataingeniørene på sin side gjør det samme med dataflytene.

Fellestrekket for disse oppgavene er at de er tidkrevende og ekstremt skreddersydde. De skal tilfredsstille kravene til maskinlæringsproduksjon, og samtidig integreres inn mot bedriftens eksisterende IT og arkitekturløsninger, og tilfredsstille kravene til disse også.

Fallgruver i integrasjonsfasen

For å nevne fallgruver for integrasjonsfasen er mangel på organisatorisk fasilitering av god overlevering fra konseptutviklingsteamet til integrasjonsteamet en gjenganger. En annen fallgruve er manglende kompetanse på maskinlæringsingeniører kombinert med lite allokert tid til gjennomføring. Har du en lovende Data Scientist som kan lære seg oppgavene til maskinlæringsingeniør er det supert, men da må det settes av tid til læring og testing, og dette vil sakke ned integrasjonsprosessen. Det skal ikke stikkes under en stol at en vellykket integrering av en maskinlæringsmodell er en bragd!

Monitorering- og vedlikeholdsfasen – fikse raskt og fikse riktig

Å vite når en produksjonssatt modell gir “dårlige” prediksjoner, hva grunnene til dette er, og hvordan feilene kan rettes opp, er hovedoppgavene i denne fasen.

Her jobbes det primært med oppsett og drift av systemer og løsninger som håndterer monitorering og vedlikehold av integrerte dataflyter og modellflyter.  Dataflytene preges ofte av brudd, noe som kan drastisk påvirke modellens prediksjoner. Dersom databruddet ikke oppdages, eller noe er feil i dataflyten selv etter at et oppdaget databrudd er fikset, er det en risiko for at prediksjonene baseres på feil input og går videre i verdikjeden. I verste fall kan dette resultere i organisatoriske beslutninger med særdeles uheldige konsekvenser. Modellens prediksjonsevne påvirkes ikke kun av databrudd, men også av at prediksjonsevnen naturlig svekkes over tid, da prosessen dataen gjenspeiler naturlig endrer seg. For å ta hensyn til slike endringer, må modellen jevnlig tilbake til “laboratoriet” og trenes på nytt. Når og hvor ofte dette er nødvendig å gjennomføre, skal også fanges opp av monitoreringssystemet.

Oppgavene beskrevet ovenfor gjennomføres av rollene MLOps (Machine Learning Operations) og Driftsutvikler (Site Reliability Engineer). Førstnevnte rolle er tett knyttet til rollen maskinlæringsingeniør, og skal primært håndtere feilretting av maskinlæringskomponentene. Sistnevnte rolle håndterer typisk drift og feilretting av systemets oppetid og kommunikasjon og samspill mellom monitoreringssystemet og andre IT-systemer.

Fallgruver i overvåkingsfasen

Typiske fallgruver i denne fasen er manglende kompetanse og erfaring, da det er snakk om nye roller i et nytt fagfelt i full utvikling. I tillegg spiller organisatorisk forankring av ansvarsfordeling og iverksetting av problemløsende tiltak en viktig rolle. For en bedrift med mange maskinlæringsmodeller i produksjon er det viktig å ha roller og rutiner på plass som skal sikre en god daglig drift, en god håndtering innen problemløsning, og en planlagt håndtering av unntakstilfeller hvor man bør ha en beredskapsplan og en nødløsning klar, dersom noe må rulles tilbake til en tidligere versjon i likhet med “vanlig” programvareutvikling.

Kontakt oss

Aurora Voje

Aurora Voje

Senior Manager, PwC Norway

Tlf: 970 98 303

Lars Meinich Andersen

Lars Meinich Andersen

Partner | Data & Analytics, PwC Norway

Tlf: 916 62 243