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/


14.11.2019 / Antti Lyytikäinen

Noniin! Olet lukenut edelliset blogikirjoitukseni ja tullut siihen tulokseen, että tietovarastosi haisee kellarilta ja on ehkä aika tehdä jotain.

Mikäli olet SAP-asiakas, sinua varmastikin askarruttaa mihin SAP:n tietovarastotarjooma on menossa ja mitkä olisivat aikaa kestäviä valintoja esimerkiksi kolmen vuoden aikajänteellä. Suunta vaikuttaa hyvin selvältä – SAP keskittyy isoin satsauksin pilvitarjoomansa kehittämiseen.

Pilviratkaisut tuovatkin niitä tuttuja hyötyjä: nopeutta, joustavampaa hinnoittelua, yksinkertaisuutta ja skaalautuvuutta. Uusimpaan tietovarastotuotteeseen SAP Data Warehouse Cloudiin on luvattu juuri tätä ja ajatuksena tämä tietenkin kutkuttaa, varsinkin kun perinteisesti on-premise-pokerin hinta on ollut jotain aivan muuta kuin nyt luvattu käytettyyn tallennustilaan ja prosessoriaikaan perustuva kuukausihinnoittelu.

Tarkempia hintatietoja varmaan saadaan lähiaikoina, niitä odotellessa voi tutustua SAP Data Warehouse Cloudin ilmaiseen kokeilujaksoon.

Onko tuote sitten valmis itsenäisesti korvaamaan esimerkiksi ikääntyvän SAP Business Warehouse 7.x :n vai tulisiko harkita esimerkiksi SAP BW/4HANA-projektia?

Otin osaa SAP Data Warehouse Cloudin beta-ohjelmaan ja vaikka osa toiminnallisuuksista ei ollut beta-vaiheessa kokeiltavissa, uskoisin että yksinkertaisempiin tarpeisiin pilviratkaisu soveltunee varsin nopeasti. Lisää kokemuksia uudesta tuotteesta sain SAP TechEdissä ja varsinkin mallinnuksen helppous sekä suoraan tietovarastovälineeseen integroitu  SAP Analytics Cloud yhdessä teki vaikutuksen jopa kaltaiseeni vanhaan kyynikkoon.

Spaces-konseptin myötä tietomallinnus on toteutettu siten, että mennään aika paljon lähemmäs visiota itsepalvelu-BI:stä, jossa myös loppukäyttäjät pystyvät yhdistelemään tietoja joustavasti. SAP HANA Cloud -alustalla toimiva SAP Data Warehouse Cloud tuo uutta myös persistenssiin: tietoa voidaan säilöä usean tehoisella ja hintaisella medialla aina muistista data laken kautta hadoopiin asti ja lisäksi ratkaisuissa voidaan käyttää myös virtualisointia, jossa tiedot luetaan lähteestä säilömättä niitä erikseen tietovarastoon. Kaiken kaikkiaan olen pitänyt näkemästäni tähän mennessä.

Tuote on kuitenkin uusi ja ominaisuuksiltaan vielä rajattu ja varmasti juuri tästä syystä SAP tarjoaa lähitulevaisuuteen hybridimallia on-premise-sovellusten ja pilvimaailman välillä. Siirtymävaihe on varmaan arkitodellisuudessakin juuri tätä, eli nykyratkaisua kehitetään ja ylläpidetään ja pilviratkaisua kokeillaan uusiin tarpeisiin ja laajennetaan tarvittaessa. Toisaalta kilpailijoiden ratkaisutkaan eivät ole 100% verrattavissa esimerkiksi ominaisuuksilla kyllästettyyn BW:hen. Yhdellä hyppäyksellä pilvitietovarastoon ei siis ehkä vielä mennä, mutta ajateltavaa riittää, mikäli vanhan uusiminen on kovinkin ajankohtaista.

SAP Data Warehouse Cloudin kehitystahti on uskottavan ripeä – uusia iteraatioita uusine ominaisuuksineen julkaistaan muutaman viikon välein. Samalla vauhdikkaalla metodilla kehitetty SAP Analytics Cloud on melko lyhyessä ajassa kasvanut hyvinkin uskottavaksi tuotteeksi raportoinnin, analyyttisten sovellusten,  visualisoinnin ja suunnittelutoimintojen saralla.  Tämän vahvistaa esim. BARC BI Survey, joka on hyvin mielenkiintoista luettavaa.

Analytics Cloudin ottaminen integroiduksi osaksi lähes jokaisen SAP-pilvituotteen (S/4HANA Cloud, Successfactors, Cloud for Customer jne.) operatiivista analytiikkaa osoittaa myös SAP:n omaa uskoa tuotteeseen. Tästä kertoo myös se, että SAC on jatkossa SAP:n analytiikkatuotestrategian kärjessä, ks. tämä tuore  SAP Analytics & Business Intelligence statement of direction.

SAP Analytics Cloud onkin melko luonteva paikka aloittaa analytiikan pilvisiirtymä huokean hintansa ja tuotteen maturiteetin ansiosta. Seuraava askel voi olla sitten sen tietovaraston seuraaminen perässä.

Blogisarjan muissa osissa:

 


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:


2.11.2018 / Lauri Nurmela

Blogisarjan edellisessä tekstissä esiteltiin malli, joka laski ennusteita perustuen sateen määrään, lämpötilaan ja kategorisiin aikakomponentteihin. Alustavasti malli vaikutti siltä, että tuloksia on mahdollista laskea. Yksityiskohtaisten ennusteiden laskeminen on kuitenkin ongelmallista kahdesta syystä: parametrejä on näillä yhdistelmillä 170, eikä malli ota huomioon asemakohtaista vaihtelua.

Todennäköisyysmatematiikkaa ja jakaumia

Nämä ongelmat päätin taklata kahdella melko suurella muutoksella. Käydään ensin läpi, miten aikakomponenttia voi tarkastella fiksummin. Pienen pohdiskelun jälkeen palasi mieleen vanha tuttu yliopiston matematiikan luennoilta: Poisson-jakauman tiheysfunktio, jota voidaan käyttää laskemaan pistetodennäköisyys jokaiselle riville. Toisin sanoen: lasketaan arvo kaikista tapahtumista, jotka ovat tapahtuneet samalla asemalla samana viikonpäivänä, tuntina ja 2 minuutin intervallilla. Kutsutaan tätä todennäköisyyttä vastedes nimellä p(Bike). Koska dataa on 4 kuukauden ajalta 20 miljoonaa riviä, on jokaiselle asemakohtaiselle 2 minuutin pituiselle hetkelle keskimäärin 15 riviä. Poisson-jakaumasta ja todennäköisyyksistä löytää nopealla googlauksella lisää materiaalia, vaikkapa Wikipediasta »

Poisson-jakauman oletus täytyy kuitenkin tarkistaa, ennen kuin voidaan edetä pidemmälle; varianssin täytyisi vastata keskiarvoa. Tällä datalla keskiarvo (pelkästään pyörien saapumisilla 2 minuutin intervalleilla) on 0,07947, ja varianssi 0,1120. Close enough. Meitä kiinnostaa tässä tapauksessa todennäköisyys, että asemalle tulee vähintään yksi pyörä – eli halutaan laskea vastatodennäköisyys sille, että asemalle ei tule yhtään pyörää:

Kaavassa e on vanha tuttu Neperin luku, ja µ on aiemmin mainittu asema- ja minuuttikohtainen keskiarvo saapuneista pyöristä.

Pistetodennäköisyyden käyttäminen ennustajana helpottaa mallinnusta huomattavasti. Koska luku on hyvin pitkälti rivikohtainen, voidaan korvata aikaisemmat ~160 parametriä lähes yhtä paljon informaatiota sisältävällä p(Bike)-ennustajalla. Tämä helpottaa huomattavasti sekä ennusteiden laskemista että tulkitsemista.

Datan visualisointi p(Bike)-muuttujalla tuottaa myös selkeämmän ”pulssin”, joka ilmentää kaupungin sykettä:

Oikotiellä tehokkuutta mallinnukseen

Tsekataan miltä aikaisempi malli näyttää todennäköisyysennustajalla aikakomponenttien sijaan:

Ensinnäkin malli saatiin laskettua samalla 1.5%:n näytteellä silmänräpäyksessä verrattuna aiempaan useiden minuuttien urakkaan. Leikkauspisteen, sateen ja lämpötilan estimaatit muuttuivat suuntiinsa suuremmiksi, ja sateen p-arvo puolittui 0.08:n. P(Bike)-ennustaja sai suuren, 9.345-arvoisen estimaatin hyvin pienellä p-arvolla. Lopuksi residual deviance on itse asiassa 18 142 yksikköä pienempi kuin aikaisemmalla mallilla. Tulos ei sinänsä yllätä, koska kyseessähän on aikamoinen oikotie: ennalta laskettu todennäköisyys ottaa malliin mukaan aikakomponenttien sisältämän informaation, joka on prosessoitu etukäteen. Mutta hei, jos malli toimii ja antaa hyviä arvoja, niin mikäs siinä.

Toinen ongelma on kuitenkin vielä ratkaisematta: Kuinka antaa asemakohtaisia ennusteita? Nopea ratkaisu olisi sisällyttää asemat kategorisena muuttujana malliin suoraan. Tässä lähestymistavassa on kuitenkin ongelma: Malli käyttäisi ensimmäistä satunnaista asemaa (Kaivopuisto) vertailukohtana sille, miten todennäköisyys eroaa toiseen asemaan verrattuna. Ennusteiden laskeminen olisi edelleen monimutkaista. Lisäksi kyseinen lähestymistapa voisi helposti johtaa ylisovitukseen, eli malli keskittyisi liian rajatusti yksittäisiin asemiin. Mikä siis avuksi? Tähän en välttämättä olisi löytänyt vastausta, jos en olisi sattunut tekemään graduani samalla metodologialla: monitasoinen regressio!

Seuraavassa osassa siis tutkitaan, miten voidaan hajauttaa regressio toimimaan useammilla hierarkkisilla tasoilla.

Blogisarjan muut osat:


26.10.2018 / Lauri Nurmela

Blogisarjan edellisessä postauksessa visioitiin malli, joka laskisi ennusteen pyörän saapumisen todennäköisyydelle lyhyellä aikavälillä. Tämänkaltaiseen ongelmaan löytyy onneksi hyvin laajalti käytetty ja hyväksi havaittu yksinkertainen mallinnustapa, jolla saadaan nimenomaan kysymykseen vastaava luku: Logistinen regressio.

Logistinen regressio: perusteet

Logistisessa regressiossa mallinnetaan binääristä vastemuuttujaa, eli lukua, joka voi olla joko 1 tai 0. Vastemuuttujaa koitetaan mallintaa käyttämällä selittäviä muuttujia, jotka voivat olla muodoltaan numeerisia tai kategorisia. Esimerkkinä voi vaikkapa kuvitella jäätelökioskin, joka on auki riippuen täysin siitä, huvittaako sen omistajaa sinä päivänä. Pilvisinä arkipäivinä, kun lämpötila on ollut alle 23 astetta, jäätelökioski ei yleensä ole ollut auki. Sen sijaan aurinkoisina ja helteisinä viikonloppuina kioski on yleensä ollut auki. Tällaisessa mallissa vastemuuttuja olisi kioskin aukiolo (1 = auki, 0 = kiinni), selittävinä muuttujina taas viikonpäivä (kategorinen = maanantai, tiistai jne.) ja sääolosuhteet eli pilvisyys (tämän voi määritellä monella tavalla, mutta käytetään tässä yksinkertaista esimerkkiä eli 1 = aurinkoista, 0 = pilvistä) ja lämpötila (numeerinen muuttuja).

Logistinen malli laskee datan perusteella, missä suhteessa selittävät muuttujat vaikuttavat vasteeseen, ja antaa sitten ulos joukon estimaatteja, jotka yhdistämällä voidaan laskea niin kutsuttu riski (odds) aukiololle. Riski ilmaistaan tyypillisesti logaritmisessa muodossa, jonka saa nopealla laskutoimituksella muunnettua todennäköisyydeksi. Toisin sanottuna, jos malli todetaan toimivaksi, voidaan sen antamilla estimaateilla arvioida todennäköisyys jäätelökioskin aukiololle tiettynä päivänä, jos vain tiedetään sen päivän viikonpäivä, pilvisyys ja lämpötila.

Logistisen regressiomallin määrittely

Mutta palataanpa takaisin pyörien pariin. Vastemuuttuja on tässä tapauksessa melko helppoa määritellä: Tuleeko asemalle vähintään yksi pyörä lyhyen aikavälin (eli omalla pinnallani kahden minuutin) sisällä? Vastemuuttuja voidaan mallintaa datasta nopeasti järjestämällä rivit asema- ja aikajärjestykseen, ja laskemalla sen jälkeen erotus pyörien saatavuudesta. Jos pyörien määrä on kasvanut, asemalle on tullut pyöriä. Päinvastaisessa tapauksessa sieltä taas on poistunut pyöriä.

Tässä vaiheessa on aika jatkaa preppailua ja datan rikastusta, jossa hyödynnän sekä R:ää että Tableau Prepiä. Lopulta datasetti sisältää seuraavat muuttujat: Kellonaika, kuukausi, viikonpäivä, viikkonumero, asemien pyörämäärien positiiviset muutokset ja kahden minuutin tasolle aggregoitu aikasarja. Näitä hyödyntämällä saa todennäköisesti jo ihan pätevän mallin, mutta voisiko tähän yhdistää vielä jotain muuta dataa? Voisihan toki, nimittäin säätiedot! Säätiedot tarjoaa Ilmatieteen Laitos niin ikään avoimena datana, jotka voi ladata portaalista parilla klikkauksella.

Säätiedot tulevat Helsingin alueella Kaisaniemen asemalta, ja ne sisältävät lämpötilan, sateen määrän, pilvien määrän, ilmanpaineen, kosteuden ja tuulen nopeuden. Mittauksia on 10 minuutin välein. Lasketaan siis datasettiin 10 minuutin tasolle aggregoitu aikasarja, ja joinataan nämä kaksi toisiinsa.

Ihan sivuhuomiona, Tableau Prepillä on muuten perhanan kätevää mallintaa dataa ainakin ad hoc -projekteissa.

Eli tässä vaiheessa mallilla on siis käytettävissä:

  • Vastemuuttuja: Asemalle on tullut pyöriä 2 minuutin sisällä, tai ei ole (= vastemuuttuja 1 tai 0).
  • Aikatiedot: Kellonaika tunteina, viikonpäivä, kahden minuutin tasolle aggregoitu data.
  • Säätiedot: Lämpötila, sade, pilvisyys ja kaikkea muuta kivaa.

Alustava malli ja sen arviointi

Tässä vaiheessa voidaan jo laskea alustava malli, ja katsoa miltä homma näyttää. Ja sehän näyttää ihan hyvältä: malli, joka käyttää inputeinaan muuttujia ”sade”, ”lämpötila”, ”viikonpäivä”, ”kellonaika” sekä kellonajan ja viikonpäivän välistä interaktiota. Interaktio on mukana mallissa, koska käytännössä viikonpäivä ja kellonaika vaikuttavat myös yhdessä – esimerkiksi lauantain kello 11 on eri asia kuin maanantain kello 11. Koska dataa on kahden minuutin tasolla n. 20 miljoonaa riviä, otetaan datasta tässä vaiheessa asemien mukaan stratifioitu 1.5%:n prosentin näyte. Mallin estimaatit näyttävät seuraavilta:

  • Jäännösdevianssi on 9234 yksikköä pienempi kuin nolladevianssi, kun vapausasteet pienenevät 169 yksikköä.
  • Suurin osa mallin estimaateista on virheen ja z-arvon perusteella luotettavia. Alla olevat visuaalit havainnollistavat. Väri indikoi p-arvoa 0.05 alfalla; estimaatit on listattu pystypäin ja interaktiot horisontaalisesti:

Arvioista nähdään, että pääosin estimaatit vaikuttavat luotettavilta. Sateen estimaatin virhe tosin oli suuri. Sitä ei kuitenkaan mallista kannata tässä vaiheessa pudottaa, koska sade on tänä kesänä ollut melko vähäistä, joten todennäköisesti sateisia aikoja ei 1.5% näytteeseen vain osunut tarpeeksi.

Pelkkä normaali logistinen regressio interaktiotermeillä on toki mielenkiintoinen, mutta miten sitä voisi soveltaa käytännössä? Tällä hetkellä arvojen ennustaminen mallin pohjalta olisi hyvin monimutkaista, koska termejä on niin paljon. Tämän lisäksi itse ennusteiden laskeminen voisi laskennalliselta kannalta olla myös raskasta ja monimutkaista.

Ja vielä se suurin ongelma: Tällä hetkellä malli ennustaa haluttua todennäköisyyttä kaikille asemille yhdessä. Visualisointi ei siis olisi lainkaan mielenkiintoinen kartalla, koska kaikilla asemilla olisi aina sama ennuste. Seuraavassa tekstissä sukelletaankin syvemmälle asemakohtaisten ennusteiden laskemiseen.

 

Blogisarjan muut osat:


18.10.2018 / Lauri Nurmela

Kaikki alkaa valmistelusta

Blogisarjan edellisessä osassa esittelin tämän sarjan aiheen pintapuolisesti: Älyn tuominen kaupunkipyöräilyyn kolmessa osassa. Nehän ovat:

  1. Historioitujen asemakohtaisten tilastojen lataus ja preppaus
  2. Käyttötilastojen analysointi ja mallinnus
  3. Mallin tulosten visualisointi ja hyödyntäminen

Aineistot tähän projektiin löytyvät HSL:n avoimen datan portaalista. Kyseisestä portaalista löytyy myös kaikkea muuta jännää, kuten esimerkiksi rajapintoja reittisuunnitteluun!

Tässä tapauksessa meitä kuitenkin kiinnostaa käyttötilastot kaupunkipyöristä. Tilastoja voi tutkia REST API:n ja GraphQL-konsolin kautta, ja dataa löytyy myös historioituna JSON-muodossa. Nopean tarkastelun perusteella historioitua dataa oli hyvin tarjolla, joten latasin elokuun alkupuolella kaikki tilastot huhtikuun alusta heinäkuun loppuun, kaikkiaan neljän kuukauden ajalta.

Data on strukturoitu niin, että kaikkien asemien tilanteesta otetaan snapshot minuutin välein, ja jokainen erillinen tiedosto kuvaa juuri sen hetken tilannetta jokaisella asemalla. Ajanhetken voi päätellä tiedoston nimestä, esimerkiksi tiedostonimi stations_20180701T095801Z kertoo, että tiedosto sisältää ajankohdan 01.07.2018 klo 09:58:01 tilanteen kaikkien asemien pyöristä. Koska tiedostot on nimetty tietyn logiikan mukaan, voi lyhyellä koodinpätkällä koko setistä parsia yhden csv-tiedoston, joka sisältää käyttötilastot aikasarjana asemittain. Itse käytin tähän R:ää. Tämän jälkeen onkin luontevaa alkaa tutkiskella, miltä data oikeastaan näyttää.

Tableau Prep & Desktop – voimakas yhdistelmä

Tähän tutkiskeluun käytän mielelläni yhtä lempityökaluistani, Tableauta. Mutta vaikka tiedot on nyt parsittu CSV-muotoon, eksploraation jouhevoittamiseksi voi datasetistä ensin koostaa uudella Tableau Prepillä valmiin datalähteen, joka auttaa itse Tableauta lukemaan dataa paljon nopeammin. Lisäksi tässä vaiheessa on kätevää myös parsia pari apukenttää, eli itse aikadimensio ja asemien koordinaatit:

Tableaun käyttämän .hyper-mallin parsimiseen menee pari minuuttia, ja tämän jälkeen tiedoston voi avata Tableau Desktopilla ja alkaa selailla dataa. Mainitsin aiemmin, että hyper-pohjaisena Tableau toimii paljon nopeammin. Mutta kuinka paljon? Otin aikaa, ja alla olevaan kuvaan Tableaun piti csv-pohjaisena ensin ladata dataa n. 6 minuuttia, jonka jälkeen laskutoimitukset pystyi tekemään parin sekunnin laskennalla. Hyper-pohjaisena kaiken datan sai ruudulle ilman näkyvää viivettä.

Heti ensimmäiseksi pistää silmään, että asemien välillä on aika mielenkiintoisen näköistä vaihtelua. Alla oleva kuva näyttää asemien keskimääräisen pyörämäärän tunneittan ja asemittain jaettuna viikonpäivien mukaan:

Tästä voidaan vetää nopea johtopäätös, että asemia selkeästi käytetään eri tavoilla riippuen aseman sijainnista – eli asemien välisissä käyttötavoissa on mitattavia eroja. Myös etenkin viikonloppu vs. arki -jaottelu näyttäisi olevan merkittävä. Aikasarjaa tutkiskelemalla taas näkee hienosti kaupungin ”sykkeen”, esimerkkinä satunnainen viikko toukokuulta:

Eksploraatiosta ideaan

Tässä vaiheessa datasta alkaa jo olla aika hyvä kuva – kyseessähän ei ole mikään kovin monimutkainen datasetti, sillä se kuvaa vain pyörien tilannetta asemien ja ajanhetken kannalta. Seuraava askel on keksiä, mitä mielenkiintoista tästä voisi rakentaa. Hmm.

Idea analytiikalle kumpusi nopeasti omista kokemuksista – olen jo pitkään itse hyödyntänyt cityfillarien reaaliaikaisen rajapinnan päälle tehtyjä sovelluksia, jotka kertovat pyörien tämänhetkisen tilanteen; harmittavan usein olen kuitenkin joutunut huomaamaan, että saapuessani asemalle joko pyörä on ehtinyt kadota, tieto on ollut virheellistä, tai asemalla oleva pyörä ei ole käyttökunnossa. Mielenkiintoista olisikin tietää, kannattaako asemalle jäädä odottelemaan, jos vaikka parin minuutin sisällä asemalle tulisikin toinen fillari?

Toisin sanottuna minulle hyödyllinen sovellus kertoisi todennäköisyyden, jolla asemalle saapuu uusi pyörä lyhyen aikavälin sisällä, ja voisin sen perusteella jäädä joko kokeilemaan onneani tai valita toisen tavan liikkua. Mitenkäs sellaista voi sitten laskea? Lue lisää seuraavasta postauksesta!

 

Blogisarjan muut osat:


11.10.2018 / Lauri Nurmela

Iloa ja älyä kaupunkipyöristä

Yksi viime vuosien ilahduttavimmista lisäyksistä Helsingin katukuvaan ovat olleet pirteän keltaiset kaupunkipyörät. Fillarin voi vuokrata kuka tahansa vuorokaudeksi, viikoksi tai koko kaudeksi lokakuun loppuun asti. Itse olen hyödyntänyt kaupunkipyöriä sekä työmatkoissa että vapaa-ajan riennoissa, ja myös ihan silkasta pyöräilyn ilosta. Kilometrejä tältä kesältä on kertynyt karvan alle 300km, eli karkeasti laskettuna Turkuun ja takaisin.

Kaupunkipyörät ovat suuren suosion myötä herättäneet tietenkin kiinnostusta siitä, miten koko järjestelmä on saatu toimimaan niin sulavasti. Nopealla uutishaulla löytyy viitteitä esimerkiksi tekoälyn hyödyntämisestä pyörien saatavuuden optimointiin (YLE) » Nämä asiat tietenkin kiinnostavat meitä Bilotilla ja (entisellä) Louhialla myös alan puolesta; kun eräänä hiljaisena kesäpäivänä sitten törmäsin HSL:n avoimeen dataan fillariasemien käyttötilastoista, oli kesän ”puhdeprojekti” selvillä.

Projektin tuloksena loihdin koneoppimisesta tuttua logistista regressiota hyödyntävän kartan, joka auttaa käyttäjäänsä päätöksenteossa vastaamalla seuraavaan kysymykseen: kannattaako odotella uutta pyörää?

Miksi kaupunkipyörät?

Kaupunkipyörät ovat julkinen palvelu: Niiden käyttämiseen liittyvät kuviot ja tilastot kuvaavat hienosti ihmisten yleistä liikehdintää kaupungilla. Tämä tekee niistä aiheena mielenkiintoisen: Joillakin asemilla pyörien vaihtuvuus on suurimmillaan ruuhka-aikoina eli aamuisin ja iltapäivisin. Toiset asemat taas ovat selkeitä iltakohteita, ja toiset suosittuja vain viikonloppuisin. Asemien käyttötilastoja tarkastelemalla ja analysoimalla voidaan päästä käsiksi mielenkiintoisiin havaintoihin koko Helsingin toiminnasta – miksi esimerkiksi Eteläesplanadin asemalla näkyy selkeä piikki torstai-iltaisin?

Toinen syy tälle aihealueelle on myös röyhkeän omakohtainen: Olen itse kaupunkipyörien innokas käyttäjä, ja harmittavan usein olen törmännyt tilanteeseen, jossa asema on joko tyhjä tai siellä olevat pyörät eivät ole käyttökunnossa. Analytiikan avulla voin näin ollen helpottaa ainakin omaa elämääni, ja toivottavasti myös muiden. 🙂

Miten?

Parsin minuuttikohtaiset JSON-tiedostot ensin yhdeksi CSV-muotoiseksi aikasarjaksi. Tämän jälkeen tein nopean valmistelun Tableau Prepillä, jonka avulla pääsin nopeasti kiinni datan rakenteeseen ja sen sisäisiin suhteisiin. Kun datasta oli hyvä kuva, aloin hahmotella mallia, joka vastasi tutkimusongelmaani.

Kun idea sopivasta mallinnustavasta oli valmis, etenin datan rikastamiseen ja säätietojen yhdistämiseen hyödyntäen sekä R:ää että Tableau Prepiä. Valmiin datamallin pohjalta pystyin laskemaan yksinkertaisen logistisen regression, joka validoi lähtestymistavan. Pienen hiomisen jälkeen rakensin mallista kaksitasoisen regression, joka mahdollisti asemakohtaisten ennusteiden laskemisen, joita hyödynnetään vastaamaan itse kysymykseen.

Mallin valmistuttua jäljellä oli enää tulosten visualisointi merkityksellisessä muodossa: nopea valmistelu Tableau Prepissä, ja tulokset kartalle. Loppu olikin enää kartan käytettävyyden hiomista ja lisäominaisuuksien hahmottelua.

Blogisarjan muut osat: