26.11.2019 / Mika Laukkanen

Olen ollut  lukuisia kertoja tilanteessa, jossa (mahdollinen) asiakas kysyy “Paljonko tämä suunniteltu AI ratkaisu maksaa kokonaisuutena?”

Luonnollisesti kysymys on relevantti ja oikeutettu, kukapa ei haluaisi tietää kustannuksia ostopäätöksiä tehdessään. Järkevän vastauksen antaminen ei ole aina ihan yksinkertaista, ja tätä dilemmaa avaan tässä jutussa tarkemmin.

Aloitetaan siitä, että miten räätälöidyt AI projektit vaiheistuvat.

Yleensä aloitetaan AI työpajoilla tai vastaavilla määrittelyprojekteilla, jossa arvioidaan business case monesta eri näkökulmasta. Mitä paremmin tässä onnistuu, niin sitä todennäköisempää on, että ratkaisu päätyy myöhemmin tuotantoonkin.

Toinen vaihe on tyypillisesti POC-projekti, jonka keskeisin tavoite on testata toimiiko koneoppiminen käytettävissä olevalla datalla. Tässä samalla myös arvioidaan, että onko itse data riittävän laadukasta ja onko sitä tarpeeksi.

POC-projektin onnistuttua ratkaisua voidaan pilotoida, eli kokeillaan sitä oikeassa ja rajatussa kontekstissa. Esimerkiksi, pilotoidaan asiakaspoistumaennusteiden pohjalta tehtyjä toimenpiteitä rajatulle joukolle asiakkaita. Verrokkiryhmien avulla nähdään erikseen, että toimiiko ennustemalli ja tehty toimenpide.

Ja mikäli POC ja pilotti onnistuivat, niin sitten on valmiudet skaalata ratkaisu tuotantokäyttöön saakka. Muussa tapauksessa, prosessissa voidaan palata taaksepäin, ja tehdä muutoksia/korjauksia tai päättää projekti ylpeästi kokemusta rikkaampana.

Kustannuksiin vaikuttavat tekijät

Otetaan mukaan kolme esimerkkiä, jotka havainnollistavat mistä projektin kokonaiskustannukset muodostuvat.

  • Case 1) yhden tuotteen menekin ennustaminen
  • Case 2) asiakaspoistuman ennustaminen vakuutusyhtiössä
  • Case 3) konenäkö tuotantolinjan laadunvalvonnassa

Kaikissa tapauksissa kahden ensimmäisen vaiheen kustannusten arviointi on suhteellisen helppoa, koska niiden sisältö, tehtävät ja vaiheistus on etukäteen yleensä hyvin selvillä. Eli määritellään business case, kerätään (staattinen) datasetti ja testataan koneoppimista ja datan validiteettia.

Kun arvioidaan pilotoinnin ja tuotantoratkaisun kustannuksia, niin asiat saattavat mutkistua olennaisesti. Miksikö? Seuraava kuva antaa tästä osviittaa.

Kuvan lähde (Google, Inc): “Hidden Technical Debt in Machine Learning Systems”, D. Sculley, Gary Holt, Daniel Golovin, Eugene Davydov, Todd Phillips, Dietmar Ebner, Vinay Chaudhary, Michael Young, Jean-Francois Crespo, Dan Dennison

Tuolla keskellä näkyvä punainen ympyrä kuvaa, mitä  POC-projektissa yleensä koeponnistetaan – eli mennään minimillä. Tuotantoratkaisun toteuttamiseksi kaikki muutkin boxit saattavat olla välttämättömiä.

Pilotti/tuotantoratkaisun kustannukset case-esimerkkien osalta?

Case 1) yhden tuotteen menekin ennustaminen, esim. vihreiden omenien.  Tämä on  hypoteettinen esimerkki kaikkein yksinkertaisimmasta ja myös halvimmasta skenaariosta. Nimittäin tässä organisaatiossa tarvittava data on jo valmiiksi tietovarastossa, joka päivittyy joka vuorokausi. Lisäksi POC:issa todettiin, että ennustemallina perinteinen ARIMA toimi mitä parhaiten. Ei tarvita LSTM neuroverkkoja tai muuta hienoa.

Tässä tapauksessa tuotantoratkaisu voisi olla, että ko. ennustemalli ajetaan ETL ajojen mukana kerran vuorokaudessa ja ennusteet tallennetaan tietovarastoon, josta ne lisätään loppukäyttäjän PowerBI Dashboardille. Käytännössä ennustemalli saataisiin tuotantoon hyvin pienellä kustannuksella heti POC:in jälkeen, ja ilman uusia infra- tai ohjelmistokustannuksia.

On mahdollista, että POC-vaihe olisi kustannuksiltaan jopa suurempi kuin varsinainen tuotannollistaminen.

Case 2) asiakaspoistuman ennustaminen vakuutusyhtiössä. Tässä tapauksessa ennustemallin toteutukseen tarvittava data löytyy neljästä eri lähdejärjestelmästä, jotka eivät ole keskenään yhteensopivia, eli tarvitaan huomattava määrä ETL-koodia (~ manuaalista työtä) datan harmonisoinnin toteuttamiseksi.

Näistä järjestelmistä ei myöskään ole liityntää pilvesssä toimivaan tietovarastoon. Niinpä sinne on rakennettava dataputket, tietomallit, käyttäjäoikeudet, jne.

Myös AI ympäristö toteutetaan nyt ensimmäistä kertaa pilveen (esim. ottaen käyttöön Databricks ja Python). Ja uusien teknologioiden käyttöönotto voi hyvinkin johtaa tarpeeseen hankkia koulutuksia asian piirissä toimiville henkilöille.

Eikä tässä vielä välttämättä kaikki, nimittäin Servicedesk järjestelmään aiotaan tuoda poistumaennusteet asiakaspalvelijan tueksi.

Kaiken kaikkiaan kustannuksia generoituu monesta eri lähteestä, ja niiden arviointi alkuvaiheessa on aika haastavaa. Tärkeintä olisikin tunnistaa, että mitä erilaisia kulueriä syntyy ja mikä on niiden kokoluokka?

Tässä tapauksessa POC-vaihe saattaisi olla ehkä 10-20% kokonaiskustannuksista. Jos asiakastiedot jo olisivat harmonisoituna ja kattavasti tietovarastossa, niin tuotannollistaminen olisi merkittävästi edullisempaa. Silloin niistä datoista olisi toki hyötyä muussakin asiakasanalytiikassa.

Case 3) konenäkö tuotantolinjan laadunvalvonnassa. Oletetaan tämä case on toteutettu käyttäen valmista ja maksullista konenäkö API:a, jota on opetettu omilla kuvilla ja tulokset ovat erinomaisia. Eli konenäkö spottaa tuotantolinjalta erehtymättömästi virheelliset tuotteet – kunhan vaan saa kuvia. Tekniseksi ratkaisuksi aiotaan hankkia tehokas laskentapönttö tuotantolinjan välittömään läheisyyteen.

Tähän saakka kustannukset ovat melko hyvin ennakoitavia, mutta tarinaa on vielä jäljellä.

Nimittäin kuvien tuottaman informaation perusteella pitäisi ohjata tuotantolinjan toimintaa. Eikä tuotantolinjan konfiguraation muuttaminen ole välttämättä ihan pieni juttu. Ja mikäli tuotantontilinjalla ei ole vielä kameroita ollut, niin nekin pitää hankkia, asentaa, testata ja huomioida ylläpitoasiat.

Luultavasti POC-vaihe, jossa testattaisiin konenäön kyvykkyyttä tunnistaa virheelliset tuotteet, olisi vain pienehkö osa kokonaiskustannuksesta.

 

Kolme vinkkiä kustannusten pohdintaan

  1. Varmista aluksi, että sinulla on riittävän tärkeä business case ratkaistavaksi. Pitää tulla lisää tuloja, karsia menoja tai optimoida toimintoja.
  2. Mieti tarkkaan, että mitä kaikkia kulukohteita tulee eteen – aina alkuvaiheesta tuotantoon saakka. Arvioi kulukohteiden kokoluokka karkeasti ja plussaa yhteen. Sitten kerro tulos jollakin mielestäsi sopivalla riskikertoimella, sillä jotain jäi kuitenkin listalta pois tai tuli väärin arvioitua.
  3. Vedä yhteen kohdat 1 ja 2, laske uudelleen että onko business case riittävän tärkeä vs. siihen tarvittava investointi.

Mainittakoon vielä lopuksi, että nyt eletään AI ajan alkuvaihetta, jonka vuoksi tarvitaan alkuinvestointeja (esim. data- ja AI ympäristöt sekä osaamisen kehittäminen).

Uskon siis, että jatkossa räätälöityjen AI-projektien toteutus tehostuu ja tulee kustannusmielessä alaspäin.

 


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.


6.08.2019 / Mika Laukkanen

AI projektit ovat monella tapaa vaikeita saada onnistumaan ja viedä tuotantokäyttöön saakka. Erilaisten selvitysten mukaan vain 5% – 10% aloitetuista AI projekteista päätyy tuotantokäyttöön.

BilotGo AI-hackissa toteutimme 2018 neljä projektia, joista kaikki ovat tuotantokäytössä 2019 aikana. Kuluvan vuoden AI-hack päättyi nyt kesäkuussa, joten näistä ratkaisuista ei vielä mikään ole ehtinyt tuotantokäyttöön, mutta aika hyvältä näyttää.

Tarkennuksena mainittakoon, että AI-hackissa siis ratkotaan asiakkaiden oikeita business ongelmia tekoälyn avulla. Kisaamassa ovat tähän saakka olleet Reima, Altia, Kone, RaisioAgro (nyk. Lantmännen Feed), Skanska, VTV ja Metsä Wood.

En käy tässä kirjoituksessa tarkemmin kisaa lävitse, mutta kerron kolme tärkeintä asiaa, joiden avulla AI projektien onnistumisprosentti on saatu nostettua korkeaksi.

Business ongelman valinta

Rohkenen väittää, että oikeanlaisen business ongelman valinta on ylivoimaisesti tärkein asia AI projektin onnistumisen kannalta. Mikään teknologia tai huipputason osaaminen ei pelasta, jos business ongelma on löperösti valittu. Sun Tzukin painotti tiedustelun ja oikeiden taisteluiden valintaa. Tässä on vähän samasta kyse.

Projektien alkuvaiheessa me pidetään strukturoitu AI-Työpaja, joissa käydään asiakkaan valitsemat business ongelmat lävitse kriittisen tarkastelun kautta. Esimerkiksi tuosta AI-hackista on jäänyt pois kiinnostuneita asiakkaita, koska kriteerit täyttävää business ongelmaa ei ole kyetty identifioimaan AI-Työpajassa.

Datan verifiointi alkuvaiheessa

Tekoäly tarvitsee dataa riittävästi ja riittävän laadukkaana. Ja se mikä on riittävästi, vaihtelee huomattavasti eri ratkaisujen välillä. Alkuvaiheessa tehtävän datan verifioinnin lisäksi on tärkeää ymmärtää, että miten data saadaan käyttöön luotettavasti ja riittävän nopeasti myös tuotantoratkaisussa. Moni AI-POC (proof-of-concept) on tähän kompastanut.

Oikeat ihmiset ja osaaminen

Onnistuneen AI ratkaisun luomiseksi ihmisiä tarvitaan yleensä useista eri funktioista ja erilaisilla osaamisilla. Kyseessä ei siis ole nerokkaan Data Scientistin yksilösuoritus. Esimerkiksi tänä vuonna AI-Hackin voittaneessa tiimissä oli osaamista seuraavasti:

  • Osaavat projektipäälliköt (asiakas ja Bilot)
  • Syvää liiketoimintaosaamista (asiakkaan edustajat)
  • Datan mallinnus ja kerääminen (Data Engineer)
  • Koneoppiminen ja tekoäly (Data Scientist)
  • Tulosten visualisointi (Service Designer ja BI expert)

Toiseksi tulleessa joukkueessa kokoonpano oli hieman erilainen, sisältäen mm. verkkokauppaosaamista, koska kyseessä oli verkkokaupan AI ratkaisu.

Kun ratkaisut tuotannollistetaan, niin usein tarvitaan vielä lisää osaamista, jotta tehdyt ratkaisut voidaan integroida osaksi nykyisiä IT ratkaisuja.

BilotGo AI-Hackathon 2019 esittelytilaisuus 12.9.2019

Mikäli haluat tarkemmin kuulla kuluvan vuoden AI-hack projekteista, niin ilmoittaudu mukaan oheisesta linkistä.

https://www.bilot.fi/event/bilotgo-ai-2019/

Aluksi Jaakko Lempinen Yleltä ja Kimmo Pentikäinen Elisalta kertovat miten tekoälyä heillä hyödynnetään. Tämän jälkeen lavan valtaavat VTV:n (Valtiontalouden tarkastusvirasto), Skanskan ja Metsä Woodin AI hackathon esitykset.

Konkreettista ja hyödyllistä tekoälyasiaa siis tiedossa. Unohtamatta aamiaista ja ilmaista lounasta.

Varaa paikkasi ja nähdään 12.9.2019!

Alla voittajatiimin tuuletukset


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.


27.05.2019 / Mika Laukkanen

Heti aluksi on mainittava, että tämä blogi on kohdistettu pääasiassa henkilöille, joilla on liittymäpintaa Business Intelligence ratkaisuihin ja nyt niiden parantaminen tekoälyn avulla on alkanut kiinnostaa.


Tekoälyyn liittyvissä esityksissä käytetään usein seuravaanlaista esitystapaa, kun halutaan kuvata mihin tekoäly asemoituu datan hyödyntämisessä.

 

Kuvan alkupää lähtee perusraportoinnista (mitä tapahtui) ja etenee kohti edistyneempää analytiikkaa (ennustamista) – samalla kun vaikeusaste ja ratkaisun arvo kasvaa. Loppupäässä on luonnollisesti kyse nykytermein tekoälystä tai AI:sta.

Pitäisikö kuvaa tulkita niin, että tekoäly on kehittyneempää Business Intelligenceä? 

Yllättävän usein olen törmännyt eri yrityksissä ajatteluun, jossa tekoälyn kehittäminen on sidottu Business Intelligence järjestelmien kehittämiseen. Ajatuksena se, että kun kerätään dataa ja tehdään raportteja, niin sen jälkeen ollaan kypsiä hyödyntämään koneoppimista (tekoälyä) samassa aihepiirissä.

Eli tekoälyprojektien aloittamista saatetaan (turhaan) viivytellä, jos “perusraportointi ei ole kunnossa”.

Kynttilöistä ei kehittynyt hehkulamppuja

Jos katsotaan reaalimaailman tekoälysovelluksia, niin vain melko harvassa niistä on havaittavissa em. kehityskulku raportoinnista tekoälyyn. Seuraavissa tapauksissa ko. esitystapa ei oikein edes toimi. Eikä varmaan ole tarkoituskaan.

  • Kuvantunnistus ja konenäkö
  • Tekstianalytiikka ja luonnollisen kielen tunnistus
  • Ennakoiva huolto reaaliaikaisella IoT datalla
  • Anomalioiden löytäminen Big Datasta
  • Musiikin tai kuvien tuottaminen tekoälyn avulla

Eli tekoälyratkaisuja syntyy paljon alueille, joissa perinteisellä Business Intelligencellä ei ole roolia.

Toisaalta, tekoälyratkaisuja voidaan usein kehittää ilman taustalla olevaa BI ratkaisua vaikka se toisikin lisäarvoa tai asioiden välillä näyttäisi olevan luonnollinen jatkumo.

Otetaan esimerkki asiakasanalytiikasta, vaikka asiakaspoistuma. Jos BI:n ja AI:n sitoo toisiinsa, niin on luonnollista rakentaa ensiksi BI-järjestelmä, jossa asiakastiedot ovat tietovarastossa, josta tehdään nippu raportointia, esim. “kuinka monta % asiakkaista poistuu vuosittain”.  Ja kun tämä on valmiina, niin hyödynnetään tekoälyä ennustamaan, että ketkä ovat seuraavat kytkimen nostajat.

Näin voi toimia, mutta käytännön elämässä on toimittu myös käänteisesti.

Kuvassa on esitetty erään oikean tekoälyprojektin vaiheet. Siinä aloitettiin keräämällä asiakastietoja monista eri lähteistä, vain ennustamista varten. Kun myöhemmin ennustemallit huomattiin toimiviksi (olivat jo tuotannossa), niin ko. tietoja alettiin tuoda BI-järjestelmään.

Kuulin joskus hauskan vertauksen, jossa todettiin ettei kynttilöistä kehittynyt hehkulamppuja. Siinä oli kyse disruptiivista keksinnöistä, hehkulamppu ei ollut vain parempi kynttilä. Mielestäni sama analogia toimii myös aika hyvin BI:n ja AI:n välillä.

Eri tarkoitus, eri kehityspolut

Business Intelligence -ratkaisut ovat nyt ja jatkossa kivijalka yritysten raportoinnille ja analytiikalle, jota ilman ei tule toimeen. Omenakauppiaan tulee tietää monta omenaa meni kaupaksi eilen, viime viikolla ja joulumyynnissä.

Tekoälyratkaisut eivät auta omenakauppiasta vain ennustamaan omenoiden menekkiä, vaan myös tulkkaamaan kiinalaisten turistien omenatiedustelut ja automatisoimaan kirjanpidon.

BI ja AI ratkaisuilla on yleensä eri tavoitteet, mutta myös itse projektit saattavat erota kuin yö ja päivä toisistaan. Näistä syistä en sitoisi niiden kehittämissuunnitelmia liian tiukasti toisistaan riippuvaiseksi.


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ä.


15.02.2019 / Mika Laukkanen

Tekoälyhuuman mainingeissa on alettu puhua tekoälystrategioista, jotka ovat kuitenkin pääasiassa olleet valtiotason nostoja. Harvemmassa yrityksessä asiaa lienee vielä mietitty lainkaan. Strategioiden sijasta on tartuttu tuumasta toimeen, ja lähdetty liikkeelle pistemäisillä AI-POC projekteilla. Tämä on itse asiassa tapa, jota taitaa esim. Andrew Ng (tunnettu tekoälyhahmo) suositella eräässä kirjoituksessaan. Hänellä oli kuitenkin hyvät kriteerit noille alkupään projekteille.

Shakkilegenda Capablanca totesi aikanaan, että ”Huonokin suunnitelma on parempi kuin ei mitään suunnitelmaa.”

Mielestäni tämä sitaatti pitää hyvin paikkaansa myös tekoälyn tai koneoppimisen hyödyntämiseen liittyen. Suunnitelmallisuus ja tavoitteellisuus vievät enemmän eteenpäin kuin yksittäiset kokeilut sellaisenaan.

Tekoäly käsitetään liian kapea-alaisesti

Useissa yrityksissä tekoälyn hyödyntäminen ajatellaan siten, että tehdään projekteja itse tai kumppanin kanssa. Eli kerätään dataa, ajetaan koneoppimismalleja ja saadaan tuloksia.

Perspektiiviä tekoälyn hyödyntämiseksi voi kuitenkin laajentaa myös koskemaan ei-itse-koodattuja-ratkaisuja. Sanotaan niitä vaikka vertikaalisiksi tekoälyratkaisuiksi, esimerkiksi

  • CRM jossa on valmiiksi tekoälykomponentteja
  • Taloushallinnon ohjelmisto, jossa tekoäly kykenee hoitamaan perusasioita
  • Matka- ja kululaskujen käsittely mobiilisti (kuvantunnistusta yms.)
  • Terveysaiheinen mobiilisovellus työntekijöille
  • Älykäs ajankäyttösovellus työntekijöille
  • Sopimustenhallinnan tekoälysovellus
  • Chatbotit asiakaspalvelussa tai sisäisesti
  • ..

Lisäksi kannattaa muistaa, että esimerkiksi kun myynnissä ja markkinoinnissa hyödyntää Facebookia, Googlea tai Amazonia, niin niiden tekoälyt tekevät työtä käskettyä ja pientä korvausta vastaan. Tämäkin on yksi tapa hyödyntää tekoälyä.

Mielestäni tekoälystrategian yksi perustehtävistä olisi huomioida tekoäly näin laajemmassa perspektiivissä. On kuitenkin tärkeää ymmärtää, että tekoäly on vain osa digitalisaatiota, jolloin nämä asiat on myös mahdollista upottaa digistrategiaan tai vastaavaan. Suunnitelman nimi ei ole tärkein pointti.

Voittaja vie kaiken

On sanottu, että tekoälyn tehokas hyödyntäminen johtaa markkinoihin, joissa ”winner-takes-all”. Esimerkkinä on käytetty aiemmin mainittuja Googlea, Facebookia ja Amazonia. Itse uskon, että tämä ilmiö tullaan näkemään monilla eri toimialoilla, kunhan tekoälyratkaisut tulevat laajemmin käyttöön.

Otetaan esimerkiksi hypoteettinen teollisuusyritys X, joka on päättänyt mennä all-in tekoälyn kanssa. Muutaman vuoden päästä heillä on tilanne, jossa tekoäly

  • Optimoi myyntiä ja markkinointia eri kanavissa
  • Valvoo tuotannon laatua ja tehokkuutta
  • Optimoi logistiikkaa
  • Hoitaa työvuorosuunnittelua
  • Ennakoi poissaoloja ja tarjoaa ennakoivia toimenpiteitä
  • Hoitaa ainakin yksinkertaiset asiakaspalvelutehtävät
  • Pystyy tekemään ja hinnoittelemaan tarjoukset
  • ..

Listaa voisi jatkaa, mutta pointti lienee selvä. Kun useilla eri osa-alueilla saavutetaan parannuksia, niin kumulatiivinen hyöty kasvaa suureksi. Ja tämän pitäisi näkyä dramaattisesti parempina tuotteina, palveluina ja hinnoitteluvoimana.

Nyt kun hypoteettinen yritys X alkaa tuottaa tuotteitaan vaikkapa -20% alemmalla hinnalla kuin kilpailijat, ja tarjoten loistavaa asiakaskokemusta, niin se alkaa niittää satoa vauhdilla. Uusien asiakkaiden myötä kyvykkyys hyödyntää tekoälyä paranee entisestään, kun datamäärät kasvavat, opitaan aiemmista tekoälyprojekteista ja tehdään niistä entistä parempia. Kilpailijoiden on tässä vaiheessa todennäköisesti myöhäistä hypätä tekoälykelkkaan.

Tämä oli toki hypoteettinen esimerkki ja jää nähtäväksi toteutuuko se koskaan, mutta miksi ei? Historia on täynnä esimerkkejä tilanteista, joissa teknologinen murros on muuttanut markkinoita. Epäilemättä moni hevoskyytien tarjoaja ei lähtenyt panostamaan autoihin sata vuotta sitten, koska ei pitänyt epävarmasti toimivia ja kalliita peltilehmiä vakavana uhkana. Eikä videoliikkeet pitäneet 6-7 vuotta sitten Netflixiä ja vastaavia olennaisina kilpakumppaneina.

 Askelmerkkejä

Tekoälyn hyödyntämistä ja strategiaa pohdittaessa kannattaa huomiota kiinnittää mm. näihin seikkoihin.

  • Miten tekoäly suhtautuu muuhun digitalisaatiokehitykseen?
  • Millä liiketoiminta-alueilla hyödyt ovat merkittävimmät?
  • Millä osa-alueilla kilpailijoiden tiedetään tekevän tekoälyratkaisuja?
  • Mitkä ovat yksittäiset ja jo tunnistetut tekoälyn hyödyntämiskohteet?
  • Ovatko tunnistetut kohteet automatisointia vai augumentointia?
  • Onko datavarannot kunnossa tekoälyn hyödyntämiseksi?
  • Mitä tehdään itse tai kumppanin kanssa?
  • Mitä osaamista oma organisaatio tarvitsee?
  • Millaisia järjestelmiä, sovelluksia, yms. hankitaan jatkossa?
  • Miten varmistetaan, että organisaatio tuottaa tekoälykelpoista dataa tulevaisuuden tarpeita ajatellen? Vanhanmallinen tietovarastoajattelu ei tässä toimi.
  • Paljonko ollaan valmiita investoimaan ja tekemään?
  • Kuka tai ketkä organisaatiossa vastaavat, että nämä asiat etenevät?
  • Miten ratkaisut tuodaan käytettäväksi, jotta ihmiset tottuvat ja luottavat niihin?

Ei mikään täydellinen lista, mutta jotain alkua kuitenkin.

Loppuun vielä pieni mainos. Mikäli tarvitset apua tällä osa-alueella, niin otapa yhteyttä ja jutellaan vaikka kahvikupin äärellä tekoälysuunnitelmista.

 


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: