Hva får du hvis du kombinerer fem uker, to konsulenter fra Bouvet, Azure, og en del historisk data fra en av våre samarbeidspartnere? En knakende prediksjonsprototype!
Alt startet med en ide. En ide om hvordan man kan bruke datainnsikt og kunstig intelligens til å skape verdi. Men arbeidet startet den 12 mars, der Sara Rambjør og Olav Rongved fra Bouvet pitchet en konkret prototype for prediksjon i Viking.
Oppgaven? Forutsi pågang for Viking, i form av telefonsamtaler og redningsoppdrag.
Leveranse? Ferdige modeller, som forutsier pågang tre uker fram i tid, og som vises på en automatisk oppdatert nettside.
Men hvordan får man til det på bare fem uker? Og hva kan vi lære om prototypeprosjekter og KI fra prosjektet?
Sara og Olavs prototype-tips
1. Forstå forretningsdomenet.
2. Start med, og bli enig om, et konsept og en enkel plan.
3. Få alle relevante tilganger osv. så fort som mulig.
4. Velg riktig folk og riktig teknologi for problemet.
5. Sikkerhet er like viktig i prototyper.
6. Begrens scope!
7. Aldri glem handover.
8. Planlegg et budsjett passende for en prototype.
1. Forstå forretningsdomenet: Prediksjonsprosjektet for Viking startet med at en av Bouvet sine konsulenter hos Viking, med lang og bred forståelse av Vikings forretning, foreslo en mulig KI-løsning som kunne støtte daglig drift. Det er essensielt for KI-løsninger, på lik linje med alle andre IT-løsninger, at de blir laget for å dekke reelle forretningsbehov. Men like viktig som den forankringen i forretningsdomenet var det at Sara og Olav samarbeidet med Vikings ressurser for å lære domenet, slik at de også kunne lage en hensiktsmessig løsning. Slik samlet Sara og Olav verdifulle tanker og innsikter om bruk av KI og Data i Vikings forretningskontekst. Ikke bare muliggjorde det leveransen, men det ga også Viking en mulighet til å samle tanker og få nye innspill - og dette brukte Sara og Olav i sin avsluttningsrapport, der de delte sine tanker rundt hvordan framtidig satsing på KI kan se ut for Viking.
2. Start med, og bli enig om, et konsept og en enkel plan: Før Sara og Olav startet å kode eller sette opp noe i Azure, presenterte de en konkret plan. Planen inkluderte konsept, leveranser, arkitekturskisse, gjennomføringsplan, og budsjettestimat. Selv om man lager prototyper og ikke alltid trenger å vite alt på forhånd, gjør en plan det mye lettere å bli enige, og å levere et ferdig resultat.
3. Få alle relevante tilganger så fort som mulig: Velykkede prototyper handler også om godt samarbeid. Her er det korte tidsfrister, og da er det essensielt at alle spiller på lag for å sikre at utviklerne har riktige tilganger, utstyr, og alt annet de måtte trenge så raskt som mulig. Sara og Olav samarbeidet med Vikings personale for å raskt sikre tilgang til Azure, DevOps, og å lande på og gjennomføre uttrekk av data fra database.
4. Velg riktig folk og riktig teknologi for problemet: Det var tydelig at prototypeløsningen passet utmerket inn i Vikings Azure-landskap. Da var det helt naturlig å spille inn Sara og Olav, to av Bouvets konsulenter med erfaring innenfor Azure og KI.
Sara og Olav brukte Azure Machine Learning Studio for å lage og levere KI-modeller. Ved å bruke Jupyter Notebooks i Machine Learning Studio sikret de at Vikings data levde i Vikings Azure Tenant. De brukte AutoML i Machine Learning Studio for å raskt teste ut og trene regresjonsmodeller. For å levere på prototyper med begrenset tid er det viktig å ta lure valg for å effektivisere arbeidet. Sara og Olav sparte også mye tid på å anvende Azure Functions til mesteparten av backendkode, og unngikk slik mer kompliserte oppsett. Siden den planlagte nettsiden var svært enkel, utviklet Sara og Olav den i HTML og JavaScript og publiserte den som en statisk nettside, og sparte seg slik for overhead relatert til rammeverk som ikke alltid er det lureste valget for enkle nettsider.
5. Sikkerhet er like viktig i prototyper: I prototyper trenger man å arbeide raskt for å oppnå resultater, men det er fortsatt like viktig å tenke på sikkerhet som i andre løsninger. Prediksjonsprototypen til Viking ble hostet i Vikings egen Azure Tenant med deres eget EntraID-oppsett, som gir de full kontroll over tilgangstyring og eierskap til løsningen.
Men sikkerhet betyr ikke bare autorisering og autentikasjon når man jobber med kundedata. Like viktig kan det være å begrense den dataen man arbeider med for å minimere all risiko. Prototypeprosjektet baserte seg kun på statistikk hentet ut fra database, og hentet ut statistikk om tidsmessig og geografisk begrenset data. Selv om data er essensielt for KI-løsninger, er det viktig å balansere det med datasikkerhet og huske at det er ikke all data som er nyttig.
6. Begrens scope! Husk at Rom ikke ble ikke bygget på en dag, og ikke på fem uker heller. Det er bedre å levere noe "helt ok" og ferdigstilt og som utforsker problemdomenet, enn det er å ikke bli ferdig med noe fantastisk som bare finnes i drømmeland.
7. Aldri glem handover: Selv om det er en prototype, er handover og avslutning like viktig som i andre prosjekter. Sara og Olav passet på å skrive dokumentasjon løpende, og sikret at andre ressurser hos Viking var kjent med løsningen.
Like viktig som å sikre at løsningen blir fulgt opp teknisk er det å sikre at den blir fulgt opp i forretningen. Derfor presenterte Sara og Olav en avsluttningspresentasjon der de forklarte resultatene av arbeidet sitt til flere interessenter i Viking, og kom med konkrete anbefalinger om hvordan de kunne følge opp prototypen videre.
8. Planlegg et budsjett passende for en prototype: Det er ikke alltid man vil bruke haugevis med penger bare for å teste noe. Derfor bruke Sara og Olav sin kunnskap om Azure, og Azure Price Calculator, til å utvikle en løsningsarkitektur som unngikk store kostnader, og til å bli enige om budsjettramme før utviklingsstart.
Sara og Olavs budsjett-tips for maskinlæring i Azure
1. Trenger du egentlig deep learning? Ja, det er kult med nevrale nettverk, men avhengig av problemet ditt kan du komme langt med enklere og billigere algoritmer.
2. Mellomlagre: Å lese ut prediksjoner fra en Azure Table Storage og andre datalagringsverktøy er ofte mye billigere og raskere enn å kjøre KI-modeller.
3. Ferdigtrente modeller i Azure Functions: Når man har en modell som er ferdig trent og klar til bruk, så trenger man en måte å faktisk bruke den. En naturlig løsning er å tilgjengeligjøre modeller gjennom Azure Machine Learning Endpoints, som tilrettelegger for en enkel deploy. I mange tilfeller, vil det kun være støtte for et endepunkt der man er avhengig av en VM som kjører 24/7 - som kan være kostbart. Dette er unødvendig for enkle modeller som blir brukt sjeldent - i vårt tilfelle, en gang per dag. Vurder derfor å laste ned modellene fra Machine Learning Studio og deploy'e de som Azure Functions.
4. Design for begrensede brukermengder: Ofte så er det ikke så mange som skal bruke prototypen. Derfor kan det være lurt å gå for enkelt og greit heller en noe som kan skalere kjempebra.
5. Bli enig om budsjett tidlig (Azure Price Calculator): Hvor mye koster det egentlig å lage en prototype some benytter seg av KI? Svaret er avhengig av flere faktorer, blant annet hva slags VM'er man ønsker å bruke, og hvor lang beregningstid som kreves av de aktuelle modellene. Her kan man komme langt på vei med et estimat gjennom Azure Price Calculator som bidrar til å styre forventningene i forbindelse med fastsetting av budsjett.
6. Skru av VMs når de ikke brukes.
7. Bruk en resource group, og hold et øye med Cost Analysis: Ved bruk av Azure Machine Learning kan kostnadene variere veldig. Dette kommer som et resultat av at forskjellig bruk av ressurser under utvikling, trening av modeller, og bruk av ferdigtrent modell i produksjon. Derfor kan det være nyttig å holde et øye med Cost Analysis underveis i prosjektet.
8. Vanlige grep funker for prototyper også! Prototyper er akkurat som andre løsninger, og ved å ta utgangspunkt i ønsket funksjonalitet og bruksmengde kan man designe løsningsarkitekturer på samme måte som større løsninger.
Interessert i å utforske potensialet for datainnsikt og kunstig inntelligens i din virksomhet? Ta kontakt med Bouvet for en prat, ideeuker eller lengre prototypeprosjekter!
