Tänä keväänä Bilotin ja Louhian asiantuntijat venyttivät päiväänsä ja käyttivät vapaa-aikansa BilotGo.ai hackathon-kisassa. Olin mukana yhdessä tiimissä – siinä joka lopulta onnekkaasti voitti kilpailun. Tässä blogissa kerron ajatukseni siitä, minkä seikkojen ansiosta onnistuimme. Uskon että ne pätevät muihinkin analytiikka- ja tietojärjestelmäprojekteihin.
1. Oikean kysymyksen tunnistaminen
Olemme varmaan kaikki kuulleet innostavia esimerkkejä tekoälyn ja koneoppimisen käytöstä. Usein nuo esimerkkitapaukset ovat kuitenkin vuosien määrätietoisen työn tuloksia. Tilaajalla pitää olla näkemys siitä, miten tekniikkaa hyödynnetään liiketoiminnassa, mutta tavoitetta kohti edetään pienin askelin. On paljon helpompaa päättää ensin pilotista ja sitten mahdollisista seuraavista iteraatioista kuin hakea hyväksyntää vuosia kestävälle, miljoonien eurojen investointiohjelmalle. Rajauksia joutuu tekemään toteutuksenkin aikana, mutta joka vaiheen tulosten pitää silti olla hyödyllisiä.
Hackathonissa käytimme työn tilaajan kanssa paljon aikaa sopivan tehtävän tunnistamiseksi ja rajaamiseksi. Meidän piti tunnistaa kysymys, jonka vastauksesta olisi selvää hyötyä liiketoiminnassa, ja joka olisi ratkaistavissa käytettävissä olevilla tiedoilla ja ajalla. Aluksi ryhdyimme selvittämään lehmien ruokinnan vaikutusta maidon määrään ja laatuun, mutta työn edetessä jouduimme määrittelemään kysymyksen uudelleen. Kisassa päädyimme ennustamaan maidon määrää lehmän iän ja poikimisten perusteella ja jätimme muut kysymykset jatkoprojekteihin.
2. Tiedon kerääminen
Kun kysymys on selvä, kerätään vastauksen selvittämiseen tarvittavat tiedot. Varsinkin alussa työ voi olla vuorottelua kysymyksen määrittelyn ja tiedon etsimisen välillä, sillä tiedon määrä ja laatu eivät aina vastaakaan käsityksiä.
Hackathonissa ryhdyimme tekemään ennustavaa mallia esimerkkitiedostojen perusteella. Vasta kisan puolivälin jälkeen osoittautui, että nuo tiedostot oli koottu käsin yksittäisistä lähteistä. Varsinaisen aineiston rakenne poikkesi esimerkeistä täysin ja mikä pahinta, tieto ei ollut riittävän kattavaa. Palasimme siis määrittelyyn. Sovimme myös, että kisan jälkeen teemme suunnitelman tiedon keräämiseksi ja jalostamiseksi.
3. Tiedon valmistelu
Yleisesti sanotaan että koneoppimisprojektissa ainakin 80 % työstä on tiedon valmistelua ja alle 20 % ennustavan mallin kehittämistä. Näin oli tässäkin projektissa – toteutusvaiheen osalta! Kun otetaan huomioon määrittely ja julkaisun valmistelu, algoritmien soveltamiseen käytetyn ajan osuus jäi vielä selvästi pienemmäksi.
Keskeisin osa datastamme oli roboteista saatuja mittaustuloksia, joten sen luulisi olevan määrämuotoista ja johdonmukaista. Käytännössä kuitenkin robotit olivat erilaisia ja tuottivat eri muotoista dataa. Sen lisäksi poikkeavien tulosten tulkinta oli vaikeaa. Esimerkiksi kun maidon rasvapitoisuus oli 30 %, kyseessä oli varmasti virhe, mutta olivatko 6 % ja 12 % välillä olevat arvot? Tiedon valmistelu edellyttää sen merkityksen syvää ymmärrystä. Siksi teimmekin sitä tiiviissä yhteistyössä tilaajan kanssa.
4. Julkaisu
Upeakin toteutus jää turhaksi, jollei kohdeyleisö omaksu sitä.
Hackathon-kisamme päättyi siihen, että toteutukset esiteltiin ulkopuolisista asiantuntijoista kootulle tuomaristolle. Niinpä tiimimme omistikin kahdeksan viikon kokonaisajasta yli viikon käyttöliittymän parantamiseen ja loppudemon valmisteluun. Mietimme esityksen kantavan tarinan ja karsimme sisältöä, jotta ratkaisu ja sen hyödyt korostuisivat. Kuten valmentajamme Antti Apunen meitä neuvoi: kohdeyleisöä ei kiinnosta, mihin algoritmiin toteutus perustuu. He luottavat siinä meidän asiantuntemukseemme ja haluavat vain nähdä tulokset ja hyödyn. Kun sisältö oli mietitty, harjoittelimme sen esittämistä toiminto toiminnolta ja jopa sanasta sanaan.
Hackathon päättyi vartin mittaisiin esityksiin, mutta muissakin projekteissa varsinainen julkaisuhetki on lyhyt ja ratkaiseva, oli sitten kyse sisäisen järjestelmän käyttöönotosta tai verkkopalvelun julkaisusta. Kuluttajat harvoin antavat toista mahdollisuutta, eikä ammattikäyttäjienkään kannata olettaa olevan pitkämielisiä. Ratkaisun hyödyn pitää nousta selkeästi esille, ja käytön pitää näyttää helpolta. Siispä projektin loppuvaiheessa täytyy malttaa lopettaa teknisten ominaisuuksien täydentäminen ja panostaa aikansa julkaisuun. Kun julkaisu onnistuu, ratkaisua voi hyvin täydentää seuraavissa iteraatioissa.
Uskon, että hackathonissa viimeistelty esityksemme lopulta ratkaisi kisan, ja palkitsi siten viikkojen uurastuksen. Samoin uskon, että projektin kuin projektin viimeistely varmistaa hyödyt.
Lisää BilotGo.ai-hackathonin ideasta täällä ja kisaamisesta täällä. Esittelemme muiden joukkueiden kanssa hackathonin tuloksia tänä torstaina tapahtumassamme – olethan tulossa?
