20.11.2019 / Tia Rautio

Tekniikka kehittyy, ja uusia työkaluja ja ratkaisuja on jatkuvasti saatavilla. Visuaalisten käyttöliittymien taakse kätkeytyy yleensä rajallinen määrä logiikkaa, mutta ohjelmoinnin osaaminen antaa sinulle vapaat kädet toteuttaa toiveesi!

Tässä koulutuksessa tutustutaan Python-ohjelmointiympäristöön ja sen käyttöön datan käsittelyssä ja analysoinnissa. Python on matalankynnyksen ohjelmointikieli, jolla näkee tuloksia nopeasti. Opiskelu tapahtuu pääasiassa käytännön harjoitusten muodossa, mutta aikaisempi kokemus ei ole tarpeen.

Koulutuksen jälkeen osallistujat ymmärtävät ohjelmointitaitojen hyödyllisyyden ja ohjelmoinnin logiikkaa. Lisäksi osallistujat oppivat toteuttamaan mm. datan käsittelyä ja ennustavaa analytiikkaa ohjelmoiden ja tietenkin hyödyntämään Pythonia moninaisissa tilanteissa.

Ennakkoluulottomille tekijöille skriptipohjaiset työkalut tarjoavat käytännössä rajattomat mahdollisuudet kehittää omaa osaamistaan ja tehostaa myös muiden työtä.

Koulutuspäivät:

  • Helsinki 20.-21.11.2019
  • Yrityskohtaiset kurssit sopimuksen mukaan

Ensimmäisen päivän sisältö

Mikä Python on ja mitä sillä voi tehdä?

  • Keskeiset Python-ohjelmointiin liittyvät käsitteet
  • Miten dataa muokataan ja visualisoidaan?
  • Kirjastot (Pandas, Scikit Learn, Numpy)
  • Koneoppimisen perusteita
  • Datan valmistelu ja visualisointi
  • Hold-out menetelmä
  • Python harjoitukset:
    • Datarakenteet
    • Funktiot ja metodit
    • Indeksointi
    • Data operaatiot ja manipulaatiot
    • Datan visualisointi
    • Tilastollinen testaus
    • Ennustemallien toteutus (perusteet)

Toisen päivän sisältö

Mallintaminen & koneoppimisen perusteita

  • Ennustemallien yli- ja alisovittaminen
  • Ristiinvalidointi
  • Tulosten testaus ja validointi
  • Python harjoitukset:
    • Kertaus: Datan rakenteet ja datan manipulointi
    • Asiakaspoistuman ennustaminen
    • Auton hinnan ennustaminen
    • Tulosten yleistettävyyden ja hyvyyden arviointi
    • Indeksointi
  • DEMO: State-of-the-art menetelmät (Deep Learning, LSTM, Tensorflow)

Kouluttajat:

Lasse Ruokolainen / Lasse Liukkonen

Hinta:

2 päivää 1 080 € + ALV hinta sisältää kahvit ja lounaat.
Ilmoittautuminen on sitova.
Mikäli tapahtumaan ilmoittautunut henkilö on estynyt osallistumasta, osallistujan voi vaihtaa ilmoittamalla siitä järjestäjälle.
Alle viikkoa ennen tapahtuman päivämäärää tehdyistä peruutuksista perimme 50 % osallistumismaksusta.
Mikäli ilmoittautumista ei peruta ollenkaan tai se perutaan tapahtumapäivänä, perimme osallistumismaksun kokonaisuudessaan.

Yrityskohtaiset kurssit:

Ota yhteyttä Tiaan ja pyydä kurssiesite hintoineen eri vaihtoehdoista.
tia.rautio@bilot.fi
+358 40 594 0069

Yhteistyökumppanimme Ari Hovin kurssitarjonta:

https://www.arihovi.com/kurssilista/


29.08.2019 / Ilpo Järvinen

Tämä kirjoitus keskittyy Databricksin käytettävyyteen erityisesti Microsoftin Azure-pilviympäristössä.

Moni Microsoft Azuren pilvipalveluja käyttänyt on saattanut törmätä Azure Databricksiin. Databricks onkin kovassa nosteessa. Yhtenä syynä tähän on juuri Databricksin integroituminen osaksi Azure-pilviympäristöä. Tässä kirjoituksessa selvennän, mikä rooli Databricksillä on AI- ja ETL-työkaluna. Lisäksi käyn läpi, mikä Databricks oikeastaan on ja mitä etuja sen integroituminen Azureen tuo tullessaan. Mainittakoon myös, että Databricksin Azure-laajennus on Microsoftin ”first-party service”, minkä vuoksi Databricksin käyttö Azure-ympäristössä on saumatonta ja vastaa yritysmaailman turvallisuusstandardeja.

Databricks pähkinänkuoressa

Databricks tuo käytännössä data science ja data engineering -työskentelyn samaan paikkaan. Kyseessä on siis toteutus, joka mahdollistaa AI-prosessien toteutuksen alusta loppuun. Datan voi ladata useista eri lähteistä, sille voi tehdä transformaatioita, rakentaa mallinnusputkia ja lopulta mallinnusputket voi julkaista tuotantoon useille eri alustoille. Näiden ominaisuuksien avulla Databricks kattaa kaikki AI/ML-toteutuksiin vaadittavat komponentit. Lisäksi se suoriutuu kaikesta tästä erittäin hyvin. Esimerkiksi, datan voi ladata suoraan Databricksiin, tehdä datatransformaatiot SQL-kielellä, opettaa ja tallentaa koneoppimismalleja Pythonilla, ja lopuksi ladata mallit tuotantoon Java tai Scala -formaatissa.

Databricksin ohjelmointiympäristönä toimivat web-pohjaiset Notebookit, jotka muistuttavat monelle datatieteilijälle tuttuja Jupyter Notebookeja. Databricks Notebookit kuitenkin sisältävät vielä lukuisia hyödyllisiä ominaisuuksia, jotka tekevät muun muassa versionhallinnasta sekä tulostaulujen ja diagrammien piirtämisestä erittäin helppoa. Samassa Notebookissa voi käyttää useaa eri ohjelmointikieltä ilman että käyttäjän tarvitsee tehdä minkäänlaista konfigurointia. Notebookit mahdollistavat myös useamman kehittäjän samanaikaisen työskentelyn.

Olennaista on myös, että Databricks on suunniteltu erityisesti big-datan kanssa työskentelyyn. Databricksin ydin on Apache Sparkissa, joka tiivistetysti on suuren datan prosessointiin tarkoitettu laskentamoottori, joka peittoaa muut nopeudellaan, käytettävyydellään ja sovelluskohteidensa laajuudella. Nopeudesta puhuminen veisi turhiin yksityiskohtaisuuksiin, mutta käytettävyyden puolesta vahvuus on Sparkin datataulujen selkeydessä ja siinä, että Spark tarjoaa rajapinnan useaan eri ohjelmointikieleen. Sovelluskohteista muutaman mainitakseni Spark soveltuu datan prosessoinnissa niin eräajoihin kuin striimaukseen eli virtaavan datan prosessointiin, tekoälytoteutuksien rakentamiseen ja SQL-operaatioihin.

Spark – Databricksin ydin

Spark on rinnakkaislaskennan mahdollistava laskentamoottori, jossa laskenta tapahtuu hajautetusti klusterissa. Tämä mahdollistaa laskentaoperaatiot sellaisissa tilanteissa, joissa yksittäisen koneen muisti ei kapasiteetiltaan riittäisi. Juuri tämä tekee Sparkista erinomaisen big-dataan liittyvässä laskennassa.

Käytännössä tämä tekee Sparkin datatauluista erilaisia kuin esimerkiksi Pythonin tai R:n perinteiset datataulut. Sparkin datataulut eivät lepää yhdessä paikassa, vaan ne ovat hajautettu klusterin ylitse. Ominaisuuksiltaan Sparkin datataulut muistuttavatkin pikemminkin tietokantojen tauluja tai Hadoopin hajautettuja tiedostoja.

Spark-tauluille on luotu rajapinta useaan eri kieleen: Pythoniin, Scalaan, R:ään ja SQL:ään. Näistä jonkin (tai useamman) kielen hallitseminen ei kuitenkaan tarkoita saumatonta liukumaa Sparkin käyttämiseen, vaan Sparkin käyttämän taulurakenteen ymmärtäminen ja tauluilla operoiminen vaatii omaa perehtymistä.

Mikään ei tietenkään estä suorittamasta Sparkin avulla operaatioita vaikkapa Pythonilla käyttäen Pandas-kirjaston datataulukoita, mikä voi joissain tilanteissa olla jopa järkevää. Tällöin data on kuitenkin tuomittu lepäämään vain yhdessä klusterin solmussa, jolloin klusterilaskennan hyödyt jäävät saamatta. Sparkin oma taulutyyppi onkin luotu juuri hajautettu laskenta silmällä pitäen. Perinteisiä (Python/R) datataulukoita ei ole suunniteltu tähän.

Spark on myös erittäin hyvä laskentaoperaatioiden optimoinnissa. Sparkin datataulukot tuovat käyttäjälleen sen mukavuuden, että pääasiallisesti laskennan optimointi tapahtuu automaattisesti ilman, että käyttäjän tarvitsee murehtia operaatioiden järjestyksestä tai laskentaresurssien jakamisesta. Toki pieni viilaus on käyttäjän puolesta välillä paikallaan.

Entä sitten Azure Databricks?

Databricks on Apache Sparkin tekijöiden luoma alusta, joka tekee Sparkin hyödyntämisestä helppoa datatieteilijöille ja -insinööreille. Databricks kokoaa kattavan määrän ominaisuuksia yhteen mahdollistaen tekoäly/koneoppimisratkaisujen tekemisen aina datan lataamisesta mallin tuotantovaiheeseen asti. Myös ETL-työt onnistuvat Databricksin avulla.

Sitten on Azure Databricks.

Azure Databricksiä voi ajatella Databricksin ”Azure-laajennuksena”, joka tarjoaa Databricksin integroituna Azure-ympäristöön. Integraation myötä Azure Databricks voi muun muassa hyödyntää Azuren data connectoreita sekä sen sisältämää dataa voi tarkastella Power BI:ssä.

Erityismaininnan arvoinen integraatio on Azure Databricksin soveltuvuus osana Azure Data Factoryn pipelineja eli ETL-putkia. Azure Databricksin notebookit voidaan saumattomasti yhdistää osaksi Azure Data Factoryn pipelinea. Tämä korostaa Azure Databricksin kykyä toimia ETL-työkaluna. Esimerkiksi datan voi pipelinessa koota useista lähteistä Blobiin, jonka jälkeen Azure Databricks tekee datalle halutut transformaatiot ja palauttaa takaisin Blobiin. Viimeisenä vaiheena voi olla esimerkiksi transformoidun datan siirtäminen Blobista SQL-tietovarastoon. Kaikki tämä tapahtuu näppärästi Azure Data Factoryn putkessa.

Ja mitä AI-toteutuksiin tulee, Azure Databricksissä luodut mallit voi rekisteröidä Azure Machine Learning servicen työtilaan, jonka kautta mallit voi julkaista verkkopalveluina. Azure Databricks on siis loistava komponentti osana Azure-pohjaisia ratkaisuja.


21.08.2019 / Tia Rautio

R-ohjelma (lyhyesti R) on Pythonin ohella suosituin koneoppimisen ja tilastollisen mallintamisen ohjelmisto. Avoimen lähdekoodin tuotteena R ei vaadi lisenssihankintoja ja päivittyy nopeasti uusien menetelmien osalta. R:n suosio ei ole mennyt kaupallisiltakaan analytiikkaohjelmistoilta ohitse ja niihin onkin rakennettu lähes poikkeuksetta R-integraatiot.

Koulutuksessa opit käyttämään R-kieltä ja pystyt jatkamaan opiskelua itsenäisesti eteenpäin. Pääset tekemään ennuste- ja segmentointimalleja tilasto- ja koneoppimismenetelmillä
Kaupalliset analytiikkaohjelmistot tukevat R:ää, jolla voi tehdä monimutkaisemmat ja ohjelmalliset mallinnukset ja R-kirjastot päivittyvät aktiivisesti ja pysyvät ajan hermolla eri menetelmien suhteen.

Koulutuspäivät:

  • Helsinki 21.-22-8. 2019
  • Yrityskohtaiset kurssit sopimuksen mukaan

Ensimmäisen päivän sisältö

  • R-ohjelman perusteet
  • Funktiot ja kirjastot
  • Datarakenteet
  • Indeksointi ja datan hallinta
  • Visualisointi
  • Kontrollirakenteet
  • Funktion kirjoittaminen

Toisen päivän sisältö

  • Datan lukeminen eri lähteistä
  • Datan yhdisteleminen
  • Apply-funktiot
  • Ennustavan analytiikan perusteet

Kouluttaja:

Lasse Ruokolainen / Lasse Liukkonen

Hinta:

2 päivää 980 € + ALV hinta sisältää kahvit ja lounaat.
Ilmoittautuminen on sitova.
Mikäli tapahtumaan ilmoittautunut henkilö on estynyt osallistumasta, osallistujan voi vaihtaa ilmoittamalla siitä järjestäjälle.
Alle viikkoa ennen tapahtuman päivämäärää tehdyistä peruutuksista perimme 50 % osallistumismaksusta.
Mikäli ilmoittautumista ei peruta ollenkaan tai se perutaan tapahtumapäivänä, perimme osallistumismaksun kokonaisuudessaan.

Yrityskohtaiset kurssit:

Ota yhteyttä Tiaan ja pyydä kurssiesite hintoineen eri vaihtoehdoista.
tia.rautio@bilot.fi
+358 40 594 0069

 

Kommentteja:

”Olimme pari päivää R-kielen kurssilla Jyväskylässä ja kurssi oli todella hyvä. Voisi jopa sanoa, että paras ”koodauskurssi” missä olen ollut. “

”Ymmärrän paremmin mihin kaikkeen R pystyy, tai mihin se ei niin hyvin sovellu”

”Paljon iloisia onnistumisen elämyksiä”

”Tiivis paketti R:stä, sai hyvän yleiskuvan”

”Mielenkiintoisia harjoituksia”

”Kouluttaja oli hyvin asiantunteva”

 

Yhteistyökumppanimme Ari Hovin kurssitarjonta:

https://www.arihovi.com/kurssilista/


13.06.2019 / Mika Laukkanen

Otsikon kysymys tulee eteen useimmille Data Scientisteille jossakin vaiheessa. Useammankin kerran olen ollut tilanteessa, jossa tekoälystä tai koneoppimisesta innostunut asiakas haluaisi ottaa helpon startin asiaan, ja esittää ko. kysymyksen.

En varsinaisesti ihmettele, että tällaisia keskusteluja syntyy, koska aiheen markkinoinnissa on useammin pää pilvessä kuin jalat maassa. Ei siis moitita kysyjiä.

Mutta eipä noista keskusteluista ole haittaakaan ollut, sillä ne ovat avanneet hyvän tilaisuuden jutella aiheesta tarkemmin.

Data on hyvä renki

Miksi ei sitten kannata edetä data edellä tekoälyprojekteihin? Tässä kolme pointtia.

Ensimmäinen pointti on, että tekoälyratkaisujen ”äly” perustuu (nykyisellään) koneoppimismenetelmiin, jotka eivät ymmärrä asioiden välisiä konteksteja. Siinä mielessä ne eivät ole laskimia älykkäämpiä. Kun meillä runsaasti dataa, niin osa muuttujista voi korreloida keskenään, ilman todellista syy-seurausyhteyttä. Dataa sokeasti louhimalla on hyvä mahdollisuus löytää ”jotakin”, joka ei siis ole oikeasti mitään.

Tässä pari kuvaa aihepiiristä.

 

Toinen pointti on, että vaikka datasta löydettäisiin aitoja yhteyksiä asioiden välillä (ei pelkkää korrelaatiota), niin niillä ei välttämättä ole juurikaan liiketoiminta-arvoa. Esimerkiksi tehdään ennusteita asioista, joita ei kukaan tarvitse tai niitä ei voi käyttää. Kerran keksimme eräässä projektissa ennustaa puuttuvia CRM tietoja asiakkaan ostojen perusteella. Malli toimi hienosti, mutta asiakas ei tarvinnut päivitettyjä tietoja. Samoin kävi myös päivystyskäyntiennusteille ja eräälle tilauskannan realisoitumisennusteelle. Ei tarvetta.

Kolmas pointti on, että datan sokeaa tutkailua voi pitää huonona ajankäyttönä. Paljon dataa, paljon tutkimista. Tutkailun tuloksena sitä lopulta keksii jonkin kysymyksen, esim. ennustettavan kohteen. Tämä jälkeen valmistelee datat, tekee mallit ja tulkitsee tulokset. Jos tulokset olivat huonoja, niin sitten toisen kysymyksen kimppuun. Jos ne taas olivat hyviä, niin silti pointin 2 riski voi realisoitua. Tämä ehkä sopii kesätyöksi opiskelijalle, jolle työnantaja ei keksinyt parempaakaan tekemistä.

Mahdollinen poikkeus

Data edellä eteneminen voi ainakin yhdessä tilanteessa olla perusteltavissa. Nimittäin silloin, kun Data Scientist on sen alueen asiantuntija, jonka dataa hänen tulisi tutkailla.

Esimerkiksi osakemarkkinoihin perehtynyt Data Scientist ymmärtää heti ko. alueen datat ja termit (esim. volatiliteetti, pe-luku, beta tai sharpen luku). Ja millaisia asioita näistä dataseteistä on yleensä järkevää etsiä.

Vastaavasti markkinointiin erikoistunut Data Scientist pystynee porautumaan erilaisiin markkinoinnin datasetteihin, ja tekemään niistä tuloksellistakin louhintaa.

Mutta näissä tapauksissa on hyvä huomioida, että Data Scientistin asiantuntijuus ko. alueella on jo lähtökohtaisesti rajannut tutkittavia vaihtoehtoja eikä se ole vain sokeaa hapuilua.

Kokonaisuutena tällaista louhintaa voi pitää innovatiivisena prosessina, jossa pyritään löytämään uusia lähestymiskulmia ja ideoita. Ei niinkään tiettyyn tulokseen pääsemisenä joissakin budjetti- ja aikatauluraameissa.

Minkä asian haluat ratkaista?

Reaalimaailmassa nuo budjetti- ja aikatauluraamit on kuitenkin huomioitava. Uskoisin että seuraavan muistilistan avulla on helpompaa päästä hyödyllisiin lopputuloksiin kuin vain dataa tutkailemalla ja parasta toivoen.

  • Identifioi minkä ongelman haluat ratkaista tekoälyn avulla. Mitä selvempi ongelma, niin sen parempi. Esimerkiksi, myyntiennuste tuotteille x, y ja z kaksi kuukautta eteenpäin. Tai onko tuotantolinjalla kulkeva tuote kuvan perusteella a) virheellinen, b) virheetön.
  • Mieti jos tekoäly jo toimisi, niin mistä sen taloudellinen hyöty syntyy (ROI)? Vähentävätkö uudet myyntiennusteet esim. hävikkiä? Tai paljonko rahaa säästyy, kun virheellisten tuotteiden palautukset puolittuvat?
  • Ennen projektin aloittamista varmista myös, että teillä on dataa, joka vastaa identifioituun ongelmaan ja sitä on saatavilla alkukokeilujen jälkeen myös tuotantokäytössä.
  • Hanki oikeat ihmiset mukaan eri vaiheisiin (kehittäminen, tuotantokäyttö)

Sinällään tässä postauksessa ei varsinaisesti ollut uusia asioita. Jo 1990-luvulla IBM:n kehittämä CRISP-DM kehikko aloitti Business kysymyksestä. Ja se pitää edelleen pintansa.


10.05.2019 / Lasse Ruokolainen

Reinforcement learning – mistä tässä on oikein kysymys?

Taustaa

Ottaen huomioon koneoppimisen ja tekoälyn hyökyaaltomaisen vyörymisen mediaan, työpaikoille, tuotteisiin ja yhteiskuntaan, monille saattaa tulla yllätyksenä että koneoppimisen nykymenetelmät ovat itse asiassa aika vanhaa perua. Neuroverkot, joihin suuri osa “tekoäly”-sovelluksista nykyään perustuu, keksittiin jo 50-luvulla1. Neuroverkkojen todellinen potentiaali on kuitenkin saatu valjastettua vasta tällä vuosikymmenellä. Tämän ovat mahdollistaneet ennen kaikkea järjestelmällinen datan kerääminen (datan määrä ei ole enää este) sekä pilvipalvelut, jotka tarjoavat käytännössä rajattomat laskentaresurssit tarpeen mukaan (jos kukkaro kestää). Datan ja laskennan saatavuus muillekin kuin suuryrityksille ja valtiollisille toimijoille on niin sanotusti demokratisoinut tekoälyn ja koneoppimisen kehityksen.

Neuroverkkoja, puumalleja ym. koneoppimisalgoritmeja käytetään suurelta osin ns. ohjattuun oppimiseen, minkä tavoitteena on muodostaa malli, joka ennustaa mielenkiinnon kohteena olevaa ilmiötä (esim. sairauden todennäköisyyttä, asiakaspoistumaa, projektien kustannuksia, tilauskannan kokoa tai tuotteiden hintoja). Bisneskontekstissa uusin tulokas koneoppimisen saralla on niin kutsuttu Reinforcement Learning, vapaasti suomennettuna vahvisteoppiminen. Vahvisteoppiminen poikkeaa “perinteisestä” koneoppimisesta siten, että tavoitteena on löytää yrityksen ja erehdyksen kautta optimaalinen toimintastrategia (policy) määritellyssä toimintaympäristössä.


Tekoälyagentin ja toimintaympäristön välinen vuorovaikutus. Kullakin hetkellä (t) Agentti “saa” ympäristön määrittämän tilan (esim. koordinaatit). Agentti tekee toimintastrategiansa mukaisen toimenpiteen (esim. siirtyy johonkin suuntaan), perustuen odotettavissa olevaan palkintoon. Toimenpiteen jälkeen Agentin tila muuttuu ja Agentti saa ympäristön määrittämän palkinnon tälle tilalle.


Laitoin tuossa yllä perinteinen-sanan lainausmerkkeihin ihan tarkoituksella. Vahvisteoppimisen historia ulottuu nimittäin yhtä kauas kuin neuroverkkojen2. Miksi tästä sitten puhutaan isommin vasta nyt? Samasta syystä kuin tekoälystä yleensä; laskentateho ei enää ole rajoittava tekijä. Tästä huolimatta vahvisteoppimisen käytännön soveltaminen on toistaiseksi ollut vähäistä, mille on löydettävissä useitakin eri syitä.

Haasteet

Vahvisteoppimisen yhtenä etuna on usein mainittu se, että siinä missä monimutkaisten neuroverkkojen opettamiseen saatetaan tarvita miljoonia havaintoja, vahvisteoppimiseen ei välttämättä tarvita lainkaan historiadataa (eli havaintoja jostakin asiasta ja siihen liittyvistä tekijöistä). Tämä ei kuitenkaan tarkoita, etteikö vahvisteoppiminen tarvitsisi ollenkaan dataa — päinvastoin. Koska vahvisteoppimisessa tekoälyagentti oppii tekemiensä ratkaisujen seuraukset yrityksen ja erehdyksen kautta, täytyy agentin voida kerätä kokemusta, eli dataa. Mitä enemmän agentti harjoittelee, sen taitavammaksi se tulee (ainakin teoriassa). Ihmisen sanotaan tarvitsevan ainakin 10 000 tuntia harjoitusta tullakseen maailman huipuksi jossain asiassa (perushyvään suoritukseen riittää toki vähempikin). Tekoälyagentti selviää tästä kyllä ajallisesti paljon lyhyemmässä ajassa (esim. Googlen AlphaZero oppi vain neljässä tunnissa päihittämään maailman vahvimman shakkiohjelman), mutta vain jos harjoituskertoja on mahdollista simuloida lukuisia määriä. Ei siis ole ihme, että vahvisteoppimisen kehitystä on opeteltu erilaisten pelien avulla.

Tekoälyagenttien opettamisen haastavuus ei ole ainut hidaste. Ehkä merkittävämpi haaste liittyy osaamiseen. Koneoppimisen soveltaminen on edelleen enimmälti data-analyytikkojen heiniä. Siinä missä koneoppimisalgoritmien hyödyntäminen ei periaatteessa vaadi kummoisia ohjelmointitaitoja (tai ainakin tarvittava osaaminen on hyvin spesifiä laajemmassa kontekstissa), vahvisteoppiminen on hyvin ohjelmointi-intensiivistä. Vaikka agentin oppiminen, joka toki on keskeisessä asemassa, perustuu koneoppimisalgoritmeihin (esim. syviin neuroverkkoihin), tämä ei alkuunkaan riitä. Agentti itsessään, sen toimintalogiikka, toimintaympäristö ominaisuuksineen ja agentin palkitsemismalli pitää yleensä ohjelmoida alusta alkaen. Vain harvalla datatieteilijällä on kykyä tähän, joten käytännössä toimivan ratkaisun kehittäminen vaatii osaavaa tiimiä, jossa analyytikkojen lisäksi on myös ohjelmistokehittäjiä.

Leikitään hetki ajatuksella, että käytettävissä olisi huipputiimi ja Googlen laskentaresurssit. Sitten varmaan syntyisi vahvisteoppimista hyödyntäviä ratkaisuja liukuhihnalta? Ehkä, mutta luulenpa, että näin ei kuitenkaan tapahtuisi. Tämä johtuu siitä, että vahvisteoppiminen ei ole sellainen vasara, jolla voi iskeä jokaista vastaantulevaa naulaa; se ei sovellu läheskään kaikkiin ongelmiin. Kuten mainitsin yllä, vahvisteoppimisen tavoitteena on löytää optimaalinen strategia. Käynkin seuraavaksi läpi tunnistettuja sovelluksia.

Käyttökohteita

Pelaaminen tulikin jo mainittua. Kuuluisampana esimerkkinä tästä on Go-pelin herruus, kun vuonna 2016 Googlen DeepMind-yksikön AlphaGo-ohjelma voitti Go:n moninkertaisen maailmanmestarin Lee Sedolin3. Puhtaalla laskennalla tähän ei päästy, sillä Go:n mahdollisten siirtojen määrä ylittää universumissa olevien atomien lukumäärän, vaan oleellista oli agentin kyky toimia luovasti eri pelitilanteissa. Vaikkei pelailusta itsestään synny kovin kummoisia bisneshyötyjä, on opittu se, että niihin bisnesongelmiin, jotka on käännettävissä peleiksi, vahvisteoppiminen soveltuu kaikkein parhaiten.

Hyvä esimerkki tästä peli-lähestymistavan hyödyntämisestä löytyy itse asiassa hämmästyttävän läheltä, Helsinki-Vantaan lentokentältä. Muiden tekoälysovellusten lisäksi Finavia hinnoittelee nykyään parkkipaikkoja dynaamisesti kysynnän perusteella. Optimaalinen strategia tähän dynaamiseen hinnoitteluun on haettu vahvisteoppimista hyödyntäen.

Ottaen huomioon että Google on vahvisteoppimisen edelläkävijä, olisi outoa, jos se ei itse pyrkisi hyödyntämään sitä. Epäilemättä Googlella panostetaan tähän asiaan melkoisesti ja tuloksiakin on saatu. Joo muutama vuosi sitten Google kertoi pystyneensä vähentämään datakeskuksiensa jäähdytyskuluja peräti 40%. Tähän tarvittiin useita neuroverkkomalleja, perustuen kerättyyn sensoridataan, joilla ennustettiin tulevaa energiatehokkuutta, sekä lähituntien ilman painetta ja -lämpötilaa. Olkoon kuinka tarkkoja hyvänsä, tällaiset ennusteet eivät kuitenkaan yksin riitä; tarvitaan vielä toimintaperiaate ja automatiikka, joka käyttää ennusteita järjestelmän säätämiseen. Tätä toimintamallia optimoitaessa vahvisteoppiminen astuu kuvaan.


PUE = Power Usage Effectiveness. © Google


Analyytikon näkökulmasta yksi hienoimpia vahvisteoppimisen sovelluksia on Googlen AutoML4. Monimutkaisten syvien neuroverkkojen parametrien ja topografian optimointi on todella hankalaa ja jo pitkään on yritetty kehittää parempia menetelmiä tähän ns. NAS-ongelmaan (Neural Architecture Search). Yksinkertaisin, mutta hyvin tehoton, tapa on generoida hirveä määrä satunnaisia malleja (joillakin oletuksilla) ja kokeilla mikä tuottaa parhaan tuloksen. Googlen lähestymistavassa optimointihomma ulkoistetaan tekoälyagentille, jota palkitaan parempien mallirakenteiden löytämisestä. Iteratiivisen prosessin tuloksena saadaan parempia malleja, joiden rakenne voi helposti olla ihmiselle täysin epäintuitiivinen.

Varmasti eniten kiinnostusta vahvisteoppimiseen on herännyt finanssimaailmassa. Jo nyt merkittävä osa kaupankäynnistä tapahtuu automaattisesti. Edelleenkin, siinä missä esim. pörssikurssien muutoksia voidaan yrittää ennustaa tilastollisesti/koneoppimisella (se että onko tässä mitään järkeä on toinen juttu), ennustemalli ei kerro mitä missäkin tilanteessa kannattaa sijoituksillaan tehdä. Päätöksen joutuu tekemään joko ihminen, sääntöpohjainen algoritmi (if/else) tai tekoälyagentti. Laukkasen Mikalta olen kuullut, että ei ole kovin helppo homma kouluttaa toimivaa pörssi-agenttia. Tai ainakaan vielä ei ole Mika päivätöitä lopettanut…

Vahvisteoppimista tarvitaan myös autonomisissa kuljettimissa/kulkuneuvoissa. Esimerkiksi itseohjautuva auto (kuten Waymo) havainnoi ympäristöään jatkuvasti lukuisilla eri sensoreilla, joiden keräämää dataa tulkitaan koneoppimismalleilla. Lisäksi tarvitaan tekoälyagentti (tai mahdollisesti useampia agentteja) tekemään päätöksiä ennustemallien antamien ennusteiden perusteella; lisätäänkö nopeutta?, hiljennetäänkö?, jarrutetaanko?, käännytäänkö?. Autonomisen auton kehittäminen on erityisen haastavaa sen takia, että tekoälyagentin toimintaympäristö ei ole suljettu ja tarkasti määritelty; liikenteessä voi tulla vastaan käytännössä mitä vain, mutta epäonnistumisille on todella alhainen toleranssi. Robottikuljettimen opettaminen toimimaan rakennustyömaalla on jo selvästi helpompi homma, koska toimintaympäristö on yleensä rajattu, eivätkä toimintavaatimukset ole läheskään yhtä haastavat kuin autoissa.


Googlen itseohjautuva auto, Waymo. Mountain View, California. © Lasse Ruokolainen


Ehkä mielenkiintoisin viimeaikainen edistysaskel on tehty tekstinkäsittelyn saralla. Itse asiassa jo 2 vuotta sitten, Salesforce kehitti tekoälyagentin, joka kykenee referoimaan tekstiä. Mitä hyötyä tästä sitten voi olla? No, me hukumme informaatioon; oin täysin mahdoton omaksua kaikkea relevanttia kirjoitettua materiaalia, suppeastakaan aiheesta. Luotettava automaattinen dokumenttien referointi olisi omiaan tehostamaan aika monen ihmisen työtä merkittävästi, kun tarve kahlata läpi lukemattomia sähköposteja tai muita dokumentteja alusta loppuun poistuisi. Tämä myös mahdollistaisi helpomman ja jopa automaattisen yhteenvetojen ja synteesien tuottamisen, mistä olisi valtavasti hyötyä mm. tieteessä.

Myös terveydenhuollossa on potentiaalia vahvisteoppimisen hyödyntämiselle. Esimerkiksi lääkeannostuksen optimointia, kuvantamistuloksiin perustuvaa automaattista diagnosointia ja dynaamista hoitosuosittelua on tutkittu. Tähän soveltamisalueeseen liittyy tosin vähän sama ongelma kuin kaupankäyntiin. Simulaatioilla voidaan kouluttaa agetti joka on teoriassa toimiva, mutta siinä missä robottiautoa voidaan vielä kouluttaa todellisessa tilanteessa, ihmishenkiä ja yritysten tulosta ei hevin anneta automatiikan armoille.

Ja käteen jäi?

Vahvisteoppiminen on avain autonomiseen tekoälyyn. Määrittelemällä “pelisäännöt” ja palkitsemismallit, voidaan tekoälyagentti saada toimimaan optimaalisesti halutussa toimintaympäristössä, ennen kaikkea halutuissa toimintaraameissa. Vahvisteoppimisessa on valtavasti potentiaalia, mutta siitä ei välttämättä ole hyötyä joka tilanteessa. Mitä pelimäisempi ongelma, sen helpommin sovellettavissa. Vahvisteoppimismallien koulutus on myös työlästä ja lisäksi ratkaisuiden kehittäminen vaatii aika erityyppistä osaamista kuin mitä data-analyytkoilta tyypillisesti löytyy. Tässä voisi olla mielenkiintoinen paikka yhteistyölle pelitalojen ja analytiikka-/asiakasorgasaatioiden välillä. Tähän mennessä nähdyt sovellukset luovat kyllä kovia odotuksia siitä mitä tuleman pitää.

 


1. A brief history of neural nets and deep learning.
2. History of Reinforcement Learning
3. Google’s DeepMind defeats legendary Go player Lee Se-dol in historic victory39
4. Using Machine Learning to Explore Neural Network Architecture


15.03.2019 / Mika Laukkanen

Kirjoitan aiheesta, jota olen sivunnut aiemminkin blogeissa ja somepostauksissa. Eli: miksi hyvin menneet AI POC:it ja pilotit meinaavat jäädä pöytälaatikkoversioiksi?

Tässä on viisi keskeistä syytä, jotka olen itse oppinut ns. kantapään kautta.

  1. POC projektissa on kokeiltu vain murto-osa toiminnallisuudesta (eli koneoppimismallin toimivuus), jota tarvittaisiin tuotantoympäristössä. Esimerkiksi tuotannossa pitää järjestää palvelimia, pilvipalveluita, datan automaattisia siirtoja, ETL-prosesseja, ML-mallien päivityksiä, ylläpitoa, jne. Nämä kannattaa miettiä jo jollakin tasolla valmiiksi heti alkuvaiheessa.
  2. Aluksi ei ole pohdittu, kenen tontille mahdollinen tuotantoratkaisu laskeutuu. Kuka sen omistaa ja vastaa siitä? Vaikka POC olisi menestys, niin se ei tarkoita, että kukaan ottaisi koppia sen tuotannollistamisesta ja kehittämisestä.
  3. Tuloksena saadun AI-ratkaisun tulokset saattavat olla vaikeita käyttää ihmiselle. Esimerkiksi, myyjä saa AI-ratkaisulta ehdotuksen “optimaalisesta hinnasta” tarjoukseen, jolla tarjouksen läpimenon todennäköisyys on korkein. Myyjä ajatteli laittavansa hinnaksi 10 000 ja AI ehdottaa 12 000. Myyjä tuntee (mielestään) asiakkaan ja markkinat eikä luota korkeampaan hintaan, etenkään kun AI-ratkaisu ei perustele ehdotustaan. Tässä tarvitaan ns. jalkauttamista, kouluttamista ja kärsivällisyyttä. Tämän asian haastavuutta voi tuskin korostaa liikaa.
  4. POC:in aihe on valittu alueelta, jolla on liian vähäinen merkitys, jotta sitä kannattaisi tuotannollistaa. Tämä on toisinaan seuraus siitä, että aluksi asetetaan rima liian alhaalle. Tahdotaan vain testata, että ”toimiiko koneoppiminen”. Yleisempi syy kuitenkin on, että aluksi ei ole pohdittu riittävästi casen business merkitystä, huomioiden vielä kohdan 1) seikat.
  5. Olen pistänyt merkille, että niissä projekteissa, joissa on henkisesti lähdetty tekemään heti tuotantoversiota (vaikka POC:illa aloitetaan), niin tuotantoversioon päätyminen on huomattavasti todennäköisempää kuin projekteissa, jossa lähdetään vaan kokeilemaan ”toimiiko AI”. Ehkäpä tämä on sitä johdon sitoutumista asiaan? Joka tapauksessa, asenteella on väliä.

Yhteenvetona voi todeta, että onnistuneiden AI POC ratkaisujen pöytälaatikkoon päätyminen johtuu usein liian suppeasta suunnittelusta alkuvaiheessa. Toisaalta tämä on ymmärrettävää, koska harvemmalla organisaatiolla tai konsultillakaan on merkittävää määrää kokemusta AI projektien läpiviennistä. Ollaan uusien asioiden äärellä.


22.11.2018 / Lauri Nurmela

Blogisarjan aikaisemmissa osissa esiteltiin alusta loppuun prosessi, jolla yksinkertaisista lokitiedoista voi rakentaa älykkään mallin, joka hyödyntää koneoppimisen tekniikoita tavoitteenaan helpottaa ihmisten elämää. Lopputuloksena oli (ainakin omasta mielestäni) nätti ja yksinkertainen käyttöliittymä, jota on toivottavasti intuitiivista käyttää. Mikä parasta, nykypäivänä älykkäitä ohjelmistoja, kuten Tableauta, voi käyttää nopealla tutustumisella kuka tahansa edistyneisiinkin analyyseihin.

Tilastotiede <3 visuaalisuus

Visuaalisen analyysin hyöty esiintyy tässäkin projektissa monella tavalla: Vilkaisemalla dataa aivan ensiaskeleina saatiin erittäin nopeasti hyvä kuva siitä, minkälaista tietoa datasta voitaisiin tiivistää. Saman asian olisi toki voinut todeta klassisilla metodeilla, kuten ANCOVA:lla. Tämä olisi kuitenkin vaatinut enemmän resursseja koodauksen muodossa, ja lopputulosta olisi ollut paljon vaikeampi tulkita ja kommunikoida. Tableaun mahdollistamalla visuaalisella analyysilla vältytään osittain koodaukselta, mutta päädytään silti samaan johtopäätökseen, joka on vieläpä helpompi kommunikoida eteenpäin.

Samaan hengenvetoon täytyy kuitenkin todeta, että tarkoituksena ei tässä vaiheessa ole vähätellä tilastotieteen tuntemusta. Päinvastoin, vankka pohja tilastotieteissä auttaa nimenomaan tulkitsemaan visuaaleja ja saamaan ideaa siitä, miten dataa voisi hyödyntää. Itse mallin rakennuksessa tilastotieteiden tuntemus on välttämätöntä. Loppupään visualisointi eli kommunikointi käyttäjien kanssa tapahtuukin sitten taas Tableaulla – loppukäyttäjille on laiha lohtu antaa mallin laskusäännöt ja käskeä laskemaan itse.

Harjoitus onkin hieno esimerkki siitä, miten edistynyt analytiikka ja visuaalisuus voivat kulkea käsi kädessä, tuoden arvoa täsmälleen sinne missä sitä tarvitaan. Hienommat mallit voidaan pyöritellä taustalla, ja loppupään käytettävyys on hyvä toteuttaa visuaalisesti ja intuitiivisesti.

Sovellutuksia liike-elämässä: Where’s the money?

Miten kaikkea tähän mennessä opittua voidaan sitten hyödyntää muualla? Miten malli kääntyy säästöiksi tai lisäarvoksi?

Kaikeksi onneksi tässä sarjassa esitelty lähestymistapa on helposti sovellettavissa: Regressiopohjainen mallinnus on analyyttisistä malleista kenties helpoin toteuttaa. Monitasoinen mallinnus taas toimii parhaiten ympäristöissä, joissa klusterit tuottavat dataan havaittavaa vaihtelua mekanismeilla, joita ei välttämättä ole mahdollista mitata suoraan. Tätä vaihtelua esiintyy tyypillisesti eniten erityisesti datassa, jossa ihmisen tai eläinten käytös korostuu datassa. Logistinen malli taas laskee yksinkertaisia todennäköisyyksiä.

Yksi mahdollinen sovellutusalue voisikin olla vaikkapa käyttäytymisanalyyseissä: Rakennetaan A/B-testauksen tyyliin useita kymmeniä eri vaihtoehtoja nettisivujen toiminnallisuudelle, ja mitataan niillä konversioita. Hyödyntämällä monitasomallinnusta ei jokaista muutosta tarvitsisi erikseen verrata, vaan kaikki arvioidaan samaan aikaan.

Toinen melko suora sovellutus vastaavalle ratkaisulle voisi löytyä vaikkapa valmistusteollisuudesta ennakoivan huollon parista. Kuvitellaan tehdas, jossa yksi tiimi operoi yhtä kohdetta. Jokaisella tiimillä on omat työskentelytavat, ja ajoittain tehtaan laitteistoa pitää korjata. Sovittamalla tehtaan dataan vastaava monitasoinen logistinen regressio, voitaisiin vähäisellä vaivannäöllä rakentaa tehtaalle ratkaisu, joka ennustaa laitteiston huoltotarpeita ja siten optimoi tuotantoa.

Lopuksi voidaan Tableaussa mallintaa vaikkapa tehtaan pohja kartalla, ja sijoittaa sinne toimipisteet. Samanlaisen skenaarion voi vaikkapa kuvitella yritykselle, joka ylläpitää laitteistoa asiakkailla. Jos asiakkaisiin – tai mihin tahansa muuhun klusteroivaan tekijään –  liittyy vaihtelua muuttujissa, jota ei pystytä suoraan mittaamaan, voi monitasoinen mallinnus selittää systeemin toimintaa tehokkaasti.

Toivottavasti tästä sarjasta oli lukijoille iloa – vaikka teksteiltä pituutta löytyykin niin kyseessä on silti melkoinen pintaraapaisu koko kuvioon. Omalta osaltani pääsin helpottamaan omaa elämääni konkreettisella tavalla, ja vieläpä oppimaan uutta ja vahvistamaan vanhoja taitoja yhdistämällä kovaa analyysia visuaalisuuteen ja käytettävyyteen.

Päivittelen mallia taas ensi keväällä kun pyörät palaavat, stay tuned 🙂

Blogisarjan muut osat:


15.11.2018 / Lauri Nurmela

Edellisissä postauksissa käsiteltiin prosessi, jolla päädyttiin malliin, joka ennustaa asemakohtaisia todennäköisyyksiä pyörän saapumiselle kahden minuutin sisällä riippuen asemasta, ajankohdasta ja säästä. Malli on toki omasta mielestäni aika hieno, mutta nyt on vuorossa hauskin kohta: tulosten soveltaminen.

Lisäominaisuus: pyörien saapumisväli

Joten: rakennetaan Tableaulla kartta, jossa jokainen asema on oma pallonsa Helsingin ja Espoon alueella. Pallon väri ja koko kertoo pyörän saapumisen todennäköisyyden: alle 50%:n todennäköisyydellä pyörää ei varmaankaan ole tulossa, ja yli 50%:n todennäköisyyksillä pyörää kannattanee jäädä odottamaan. Pienellä matematiikalla todennäköisyyttä voi myös käyttää laskemaan pyörien keskimääräinen saapumisväli:

jossa t on saapumisväli, P on ennustettu todennäköisyys ja µ on ajankohdalle ja asemalle spesifi pyörien historiaan perustuva keskimääräinen saapumismäärä. µ on tässä kaavassa jaettu kahdella, koska havainnothan ovat edelleen kahden minuutin tasolla.

Kuinka murskata 20 miljoonaa riviä kymmenesosaan?

Yksi haaste on ilmeinen: Miten saada 20:n miljoonan rivin datasetti Tableau Publiciin, kun kovakoodattu raja kyseiseen palveluun on 15 miljoonaa riviä? Vastaus on tietenkin yksinkertaistaa datan rakennetta aggregoimalla pois aikadimensio ja säilyttämällä ainoastaan asema-aikakohtainen keskimääräinen todennäköisyys p(Bike) muine tietoineen. Lopulta nämä rivit yhdistetään R:stä ulos vedettyyn estimaattitaulukkoon, joka näkyy alla nimellä ranef. Ranef-taulukko siis sisältää asemakohtaiset laskuohjeet ennusteille, ja ne on yhdistetty muuhun dataan aseman tunnuksen perusteella.

Kiinteät vaikutukset on kätevää sisällyttää calculated fieldillä, joka sisältää ainoastaan kiinteän estimaatin luvun. Loppujen lopuksi kaavahan tarvitsee vain mainitut parametrit “sää” ja “todennäköisyys” laskeakseen tuloksen. Säätiedot voi syöttää yksinkertaisilla Tableau-parametreilla, todennäköisyydet taas laskettiin äsken aikadimensiota aggregoimalla, ja yksittäisen ennusteen tarvitsemaan pohjatodennäköisyyteen pääsee käsiksi hyödyntämällä now()-funktiota.

Vielä viimeinen muokkaus dataan on aggregoida näitä todennäköisyyksiä hieman ylöspäin kymmenen minuutin tasolle: Espoon uusien asemien ylisuuret estimaatit liioittelevat helposti todennäköisyyksiä lyhyillä 2 minuutin aikaväleillä. Ylöspäin aggregoiminen tasoittaa näitä ”ylilyöntejä”. Todennäköisyys on siis edelleen kahden minuutin aikavälille, mutta se on nyt keskiarvo 10:n minuutin ajanjaksolla.

Tableau Publiciin menevä datasetti sisältää aggregoituna lopulta ~259 000 riviä – noin sadasosa alkuperäisestä. Tällä datamäärällä varmistetaan osaltaan myös kartan jouheva toiminta.

Toimivuuden ja käytettävyyden optimointi Tableaussa

Lopulliset ennusteet on siis yksinkertaisesti laskettu aiemmin mainituilla kaavoilla. Tableaun päässä haasteena on enää saada laskut suoritettua ainoastaan tarvituilla riveillä eli täsmälleen oikeana ajankohtana. Tämän voi varmistaa yksinkertaisilla true/false-filttereillä: Esimerkiksi oikean minuutin varmistaminen:

datepart(‘minute’,now()) – int(right(str(datepart(‘minute’,now())),1)) = [Minute]

Vasemman puolen lasku laskee lähimmän kymmenminuuttisen tunnin sisällä, ja pakottaa siten laskutoimitukset tapahtumaan lähimmän intervallin sisällä. Samankaltaiset filtterit rajoittavat laskuja myös tunnin ja viikonpäivän osalta. Lopulta worksheetille sijoitetaan relatiivinen now-filtteri, joka varmistaa, että kartan arvot muuttuvat ajan kuluessa paremmin.

Käytettävyyttä voi vielä parantaa formatoimalla tooltippiä tyylikkäämmäksi. Sen pitää ensinnäkin kertoa selkeästi aseman nimi. Todennäköisyys on hyvä kuvailla ymmärrettävillä termeillä, ja mukaan on hyvä lisätä ennustettu odotusaika, joka laskettiin aiemmin. Lopuksi näyttävyyttä tuo in-tooltip -visualisaatio, joka kertoo todennäköisyyden jakauman kuluvan päivän ajalta.

Lopputulos näyttää tältä:

Näin ollaan siis toteutettu koneoppimisen tekniikoita hyödyntämällä yksinkertainen mutta tehokas sovellus, joka toivottavasti tuo iloa monien cityfillaristien arkeen. Mallia on myös mahdollista viedä eteenpäin huomattavasti: edistyneessä ratkaisussa todennäköisyyksiä voisi laskea neuroverkolla, ja palvelun voisi toteuttaa omana web servicenään. Tämä mahdollistaisi todennäköisyyksien yhdistämisen reaaliaikaiseen pyörätilanteeseen ja säätietoihin – ollaanko enää kaukana varsinaisesta taikuudesta? 🙂

Blogisarjan muut osat, ja alla vielä itse sovellus:


9.11.2018 / Lauri Nurmela

Blogisarjan edellisessä kirjoituksessa laskettiin melko yksinkertainen logistinen regressio, joka ennustaa pyörien saapumista asemalle riippuen säästä ja ajankohdasta. Nyt sukelletaan syvemmälle, ja lasketaan asemakohtaiset ennusteet käyttämällä monitasoista regressiota.

Pintaraapaisu hierarkkisiin malleihin

Monitasoinen eli hierarkkinen regressio on suunniteltu laskemaan malleja datalle, joka on hierarkisesti jakautunut selkeästi määriteltäviin yksiköihin. Sen juuret ovat koulutuksessa ja lääketieteessä: Esimerkiksi oppilaiden mallintaminen osana luokkia, tai potilaiden mallintaminen osana lääkäreitä, omassa tapauksessamme 2 minuutin välein tehdyt havainnot osana asemia. Tarkoituksena on laskea malli, joka osaa ottaa huomioon yksikköihin tai klustereihin liittyvät ei-mitattavissa olevat muuttujat – toisin sanoen ottaa myös huomioon, että klusterien sisällä voi olla vaihtelevia korrelaatioita. Aiheesta voisi jaaritella vaikka kuinka pitkään, mutta onneksi tähän on paljon loistavaa kirjallisuutta. Itse suosittelen A. Gelmanin & J. Hillin kirjaa ”Data Analysis Using Regression and Multilevel/Hierarchical Models”.

Joka tapauksessa, monitasoisen mallin voi asettaa laskemaan asemakohtaisen estimaatin niin, että asemakohtaisia havaintoja verrataan kaikkiin havaintoihin. Epävarmoissa tapauksissa estimaatti asetetaan lähelle yleistä tasoa, ja tilastollisesti vahvoissa tapauksissa estimaatin annetaan vaihdella enemmän.

Vihdoin maalissa – lopullisen mallin laskenta

Nopealla laskutoimituksella saadaan myös ”oikeutus” monitasoiseen mallinnukseen: tyhjän, pelkästään asemat käsittävän mallin antama ICC on 39%. ICC eli intraclass correlation on perinteisen lineaarisen regression R2-lukuun verrattava mittari, joka tässä tapauksessa kertoo kuinka paljon vaihtelu asemien välisissä eroissa selittää vaihtelusta koko datasetissä. Monitasoisissa malleissa ICC on tyypillisesti n. 10-20%, joten tämä tulos on hyvinkin merkittävä. Toisaalta tulos on myös uskottava: muistattekos ensimmäisen postauksen graafin, jossa näkyi asemakohtainen pyörien saatavuus? Tableaussa tehdyllä visuaalisella analyysillä saatiin jo parissa minuutissa nopeasti vihiä, että monitasoinen mallinnus on todennäköisesti järkevää.

Monitasoista mallinnusta voi tehdä monella tavalla ja prosessi on melko pitkä – omassa tapauksessani päädyin tekemään varying intercept varying slope -mallin, jossa saavat vaihdella sekä leikkauspiste – eli tässä tapauksessa asemakohtainen lähtöpiste – että aiemmin mainitun p(Bike):n estimaatti. Sään suhteen riittää, että lasketaan tasot ylittävä eli kiinteä estimaatti, koska havainnot ovat kaikki samalta sääasemalta, ja siten täsmälleen samat kaikille havainnoille samana ajanhetkenä. Tässä vaiheessa myös mallin laskenta pitää ottaa huomioon, sillä monitasoinen mallinnus vaatii huomattavasti resursseja. Itse pystytin Azureen Data Science Virtual Machinen, jossa tulee R valmiiksi asennettuna. Datat koneelle, koodi sisään ja malli raksuttamaan. Jonkun ajan päästä tulokset odottavat koneella, ja hommassa päästään eteenpäin. Tältä näyttävät asemakohtaiset estimaatit leikkauspisteen ja p(Bike):n suhteen:

Ennustusten johtaminen monitasoisesta logistisesta regressiosta

Nopealla vilkaisulla näyttäisi siltä, että hyvin pienet arvot leikkauspisteellä on annettu kesän keskivaiheilla käyttöön otetuille asemille Espoossa – eli lähtökohtaisesti todennäköisyys on pieni. Suuret arvot taas ovat suosituimmilla asemilla, joissa liikennettäkin on paljon. Datan vähäinen määrä voi vaikuttaa merkittävästi asemien arvioiden luotettavuuteen. P(Bike)-arvoissa pienimmät estimaatit taas ovat menneet kaikista vilkkaimmille asemille, ja vastaavasti vähemmän liikennettä nähneet asemat ovat saaneet suuremmat estimaatit. Toisin sanoen, vähän liikennöidyillä asemilla yksittäisen pyörän saapumisen todennäköisyys vaikuttaa ennusteeseen todennäköisyyttä nostavalla tavalla, ja vilkkailla asemilla todennäköisyyttä laskevalla tavalla. Negatiivinen estimaatti todennäköisyydelle voi ensivilkaisulla vaikuttaa oudolta – selitys on, että näitä asemakohtaisia estimaatteja verrataan yleiseen asemista riippumattomaan tasoon kun lasketaan ennusteita.

Lämpötilan estimaatti on 0.05, eli lämpötilan noustessa pyörien saapumisen todennäköisyys nousee hienoisesti asemasta riippumatta. Tulos käy järkeen, sillä lähtökohtaisesti on järkevää olettaa, että lämpimällä säällä pyöriä on enemmän liikkeellä. Sateella vaikutus on päinvastainen: -0.167. Tällä kertaa myös estimaatin keskivirhe on pienentynyt mitättömäksi, eli luku on luotettava. Nyt meillä onkin siis malli, jolla on helppoa laskea yksityiskohtaisia ennusteita joka asemalle! Yksittäisen ennusteen kaava tässä mallissa on seuraava:

Toisin sanottuna kiinteä leikkauspiste ja asemittain vaihteleva leikkauspisteen satunnainen komponentti, lämpötilan ja sateen kiinteät muuttujat, ja p(Bike):n kiinteä estimaatti sekä asemittain vaihteleva komponentti. Laskettu arvio on logaritmisella asteikolla aiemmin mainittu riski, jonka voi muuntaa todennäköisyydeksi kaavalla

Sehän toimii!

Lopuksi vielä tarkistetaan, että malli todella toimii. Tähän hyödynnän koneoppimisen puolelta tuttua AUC-lukua, joka kuvaa oikeiden ennustusten suhdetta vääriin. Tehdään tämä laskemalla malli näillä parametreillä viikoilta 23 ja 24, ja ennustetaan sillä lukuja viikoilta 27 ja 28.

Tulokset: AUC 0.87, ja ROC näyttää kaunista kurvia:

Ennustustarkkuus mallilla näyttäisi olevan noin 93%, eli 93% ennustetuista ykkösistä ja nollista ovat oikein. Huomioitakoon toki, että binäärisissä vastemuuttujissahan tarkkuus on vähän kyseenalainen mittari. AUC ja ROC ovat paljon parempia mittareita, koska ne kertovat suoraan miten malli pärjää eri raja-arvoilla ykkösten ja nollien päättelyssä.

Näillä arvioilla voidaan todeta, että malli näyttäisi toimivan oikein hyvin. Seuraavassa osassa palataankin maan pinnalle, ja laitetaan malli tositoimiin Tableaussa.

Blogisarjan muut osat: