Konkarin neuvoja koneoppimishankkeisiin teollisissa ympäristöissä – ”Ylläty positiivisesti, jos data ei ole likaista ja oikuttelevaa”
Koneoppiminen, Machine Learning, lyhyesti ML, alkaa olla useilla teollisuudenaloilla jo perusedellytys. Sen avulla toimintaa ennakoidaan ja saadaan tärkeää tietoa esimerkiksi teollisten prosessien toiminnasta tai tuotantohyödykkeiden suorituskyvystä.
Jarkko Pukkila, Sofigaten Senior Advisor, on taklannut haasteita lukemattomissa koneoppimisen hankkeissa eri toimialoilla – erityisesti teollisissa ympäristöissä. Millaisia oppeja ML-hankkeista on jäänyt mieleen?
1. Aseta hankkeessa lähtöhypoteesi: Machine Learning -mallille ojennettava teollisuuden data on yllättävän useinkin likaista ja oikuttelevaa. Ylläty myöhemmin positiivisesti, jos näin ei ole.
Sensorit ovat mukamas kunnossa ja lähettävät hanakasti raakadataa pilvessä hostatulle ML-mallille tuntipohjaisen ennusteen generointia varten. Sitten lattiatasolla selviää että, viimeiset puoli vuotta sensori on kyllä lähettänyt luotettavasti dataa kuin sveitsiläinen kello, mutta kyseinen data on ollut mitä sattuu. Tämä siksi, koska sensori on jossain vaiheessa mennyt väärään asentoon tai muuta yhtä yksinkertaista.
Usein nämä opit tulevat vastaa viiveellä, koska moni sensori on mm. sijaintinsa tai huoltoturvallisuutensa vuoksi sen luontoinen, että sitä voi huoltaa vain tehtaan huollon vuosikellon rajoissa, kun tuotantolinja on pysähdyksissä. Mitä sitten pitäisi tehdä?
Jokaisen hankkeen tulisi ja alussa varautua tähän henkisesti ja myös lukuisin käytännön keinoin. Millainen monitorointijärjestelmä tarvitaan? Sen on valvottava, että osana vikaantumiseneston tai prosessioptimoinnin palvelua ML-malli saa tarvitsevansa datan säännöllisen luotettavasti ja eheänä.
Tällaista monitorointia varten voidaan hankkeissa kehittää yksinkertaisia sääntöpohjaisia logiikoita. Ne esimerkiksi hälyttävät, kun datan lähetyksen taajuus ei noudata totuttua väliä tai lähetetyt arvot poikkeavat totutusta.
Palvelumuotoilun puolestaan tulee ottaa kantaa, mitä tapahtuu palvelumuotoilun service blueprintissä ”back-stagella”, jotta tällaisista tilanteista saadaan kiinni osana jatkuvaa palvelun toimitusprosessia.
Datatieteen puolella tulee harkita, voidaanko jonkun ennusteen tuottamisen tarvittavan datapisteen osalta olla armeliaita vai onko viisainta pultata kyseinen ”saastunut” datapiste irti ML-mallista pois sitä häiritsemästä.
Oikuttelevan datapisteen vaikutus ML-mallille ja sen myötä kokonaispalvelulle riippuu tilanteesta. Jos data on huonoa tai tietyn sensorin yhteys pätkii, koko palvelutoimitus saattaa keskeytyä. Toisena ääripäänä on se, että palvelutoimitus jatkuu, mutta ennustetarkkuus kärsii hieman.
2. Ekosysteemiympäristöissä data kulkee joskus Machine Learning -mallille monen mutkan kautta. Mikä on hyväksyttävä latenssi, kun huomioidaan loppukäyttäjän tarve?
Kun ratkaisua luodaan ekosysteemissä, jossa ML-malli generoi ennusteensa monelta yritykseltä reaaliaikaisesti streamatun datan pohjalta, raakadata usein kulkee monen välietappina toimivan järjestelmän kautta. Usein eri välietapit ovat vieläpä eri yritysten IT:n hallussa.
Kun välietappeja on monta, on syytä muistaa, että päätepysäkillä kyseisestä datasta ottaa kopin datatietelijä, ja hänen on ensiarvoista tietää, jos matkan varrella dataa muotoillaan millä tahansa keinoin, esimerkiksi keskiarvoistuksin.
Yksinkertainenkin ja päällisin puolin viattoman näköinen datan muotoilusääntö jonkin välietapin integraation tehostamiseksi tai integraatioinfran kustannusten optimoimiseksi voi muuttua ML-projektille turmiolliseksi. Näin on vaarassa käydä silloin, jos päätepysäkillä dataa vastaan ottaa datatieteilijä ei säännöstä tiedä, vaan olettaa datan olevan aina alkuperäisessä raakamuodossaan.
Kun välietappeja on monia, myös aikamääre lattiatason mittauksesta ennusteen generoimiseen kasvaa. Palvelumuotoilun tulee palvelun kohderyhmän haastatteluin ja muiden palvelumuotoilun keinojen avulla pystyä toimittamaan datatieteilijöille ja teknisille sidosryhmille tieto mikä on hyväksyttävä latenssi. Kuinka nopeasti tehtaan lattiatasolla orastavaan ongelmaan pitää pystyä reagoimaan?
Sekä tekniset sidosryhmät että datatieteilijät voivat tällöin pitää kyseisiä oppeja ohjenuoranaan, kun he trimmaavat integraatioarkkitehtuuri ja ennustemallien käyttäytymistä määritteleviä sääntöjä. Jos näitä asioita ei huomioida, syntyy riski: vaikka kokonaispalvelun osakomponenttina oleva ennustekyvykkyys on tarkka, kokonaispalvelu ei toimi, koska ennusteen tuottamat suositukset saapuvat liian myöhään asioihin vaikuttamiseksi.
3. Pelillistäminen voi tuoda jännitystä koneoppimisen mallien kehittämiseen. Päätös mallista ei kuitenkaan ole peliä.
Kun ML-hankkeessa on mukana useampi datatieteilijä, pelillistämisen keinoin on järjestettävissä kutkuttavan jännittäviä mallinnushetkiä! Silloin datatietelijät kehittävät ennustavia malleja eri lähtökohdista: esimerkiksi yksi datatietelijä keskittyy puupohjaisiin ennustemalleihin ja toisen taas neuroverkkoihin.
Jotta suoriutumista voitaisiin myöhemmin puntaroida, on tärkeää, että jo ennen kehitystä on hyväksytty yhdessä KPI-mallin tarkkuus ja muut mahdolliset evaluoinnin pelisäännöistä. On syytä muistaa, että matemaattisesti tarkin ML-malli ei välttämättä ole liiketoiminnallisen muotoilun näkökulmasta suotuisin malli.
ML-mallin valinnalla voi olla monenlaisia heijastevaikutuksia liiketoiminnan näkökulmasta. Esimerkkitilanteena olkoon lopputulos, jossa on kaksi kilpailevaa ennustemallia – puumalli ja neuroverkko – ovat lähes yhtä tarkkoja.
Jos tarkkuuden kannalta ei ole väliä, kumpi malli otetaan osaksi asiakkaille tarjottavaa kokonaispalvelua, on syytä huomioida muita näkökulmia. Jos neuroverkko kuluttaa ennusteen generoimiseksi sata kertaa enemmän dataa kuin puumalli, päästään mielenkiintoisiin keskusteluihin: toisella puolella vaakakupissa painaa mallin matemaattinen tarkkuus, toisella puolella taas datan liikuttamiseen tarvittavan infrastruktuuri ja sen suorituskyvyn kustannukset.
Jarkko Pukkila, Senior Advisor, keskittyy Sofigatella teollisen internetin ja koneoppimisen hankejohtamiseen. Käytännön kokemuksena Machine Learning -hankkeiden haasteiden aktiivisessa taklaamisessa Jarkolla takanaan yli 1500 tuntia. Hän on johtanut ennustuskyvykkyyteen tähtäävää data science-työtä useiden eri asiakkaiden ja projektien parissa. Hän on kiinnostunut datatieteen, muotoilun ja ohjelmistokehittämisen välisestä dynamiikasta hankkeiden sisällä ja näiden kompetenssien luovasta törmäyttämisestä.
Essi Ahokas on koukussa uuden oppimiseen, ja siitä hyötyy koko tiimi
Panostatko hankinnoissa säästöihin vai työntekijäkokemukseen – vai molempiin?
