Hei,
Tiedon mallinnus (data modeling) on tietysti vanha konsepti, mutta AI:n aikakaudella siitä puhutaan taas erityisen paljon. Nyt kaikki puhuvat semanttisesta kerroksesta ja malleista, ontologioista, kontekstin tärkeydestä ja merkityksen luomisesta datalle.
Välillä tuntuu, että tapahtuu klassinen “keksitään pyörä uudelleen” -efekti. Ei siinä mitään, se on luonnollista. Vanhat hyvät ideat eivät täysin katoa.
Ennen puhuttiin käsitemallista (conceptual modeling), jonka tarkoitus on selvittää käsitteiden merkitys kaikille osapuolille ennen kuin mennään “fyysiseen” toteutukseen eli tehdään mitään teknistä.
Tekoälyn promptaamisen ehkä paras vertaus, jonka olen kuullut, on tämä: se on kuin opettaisi uutta, hieman kokemattomampaa (mutta fiksua) työntekijää. Kuten uudelle työntekijällekin, jos haluat opettaa häntä tekemään itsenäisesti työtään, on hyvä auttaa häntä ymmärtämään merkityksiä ja kontekstia.
Semanttinen kerros, ontologia ja taksonomia eivät ole uusia termejä, päinvastoin, ne ovat todella vanhoja. Mutta nyt ne ovat tulleet muotiin, kuten 90-luvun musiikki konsanaan.
Semanttinen kerros on nyt hype-termi, ja toteutukset vaihtelevat, mutta perusidea (shared meaning) on sama.
Kieli liittyy osastojen kulttuuriin
Data-alan yksi suurimmista ikuisuushaasteista on se, miten yhdistetään eri näkökulmien määritykset tietosisällöille.
Klassinen esimerkki: “Customer” eli asiakas voi tarkoittaa markkinoinnille yhtä ja myynnille toista. Merkitykset voivat olla lähes samoja, tai vaihdella melkoisesti.
Eräällä yrityksellä, joka ostaa metsää metsänomistajilta, on perinteisesti kutsuttu “asiakkaiksi” yksityishenkilöitä, jotka myyvät metsää yhtiölle. Siitä huolimatta, että yleensä ostavaa tahoa kutsutaan asiakkaaksi, heillä homma toimii toisinpäin. Heidän talousjohtajansa sanoi, että tämä vanha käytäntö aiheuttaa hänelle harmaita hiuksia.
Koko tämä merkitysten moninaisuus johtuu eri yksiköiden välisestä kulttuurista ja sen käyttämästä kielestä.
Me data-alan ihmiset välillä kiroamme, että ala on täynnä termejä: on data lakehousea, allasta, data meshiä, Fabricia, governancea, metadataa ja mitä kaikkea.
Totuus on, että kaikilla funktioilla on oma sanastonsa. Koita vaikka mennä markkinoinnin, tuotekehityksen tai talousihmisten Teams-palavereihin, varmaan puolet jutuista menisi ohi.
Tämä kaikki vaikeuttaa data-analytiikkaa, erityisesti jos eri osastojen dataa pitäisi yhdistellä tai esittää datalla “totuuksia”, jotka kaikki hyväksyisivät.
Määritykset ovat tärkeämpiä kuin data-alusta
Tietoa voi tulkita hyvin eri tavoin ja eri tarkoitusperien kautta. Data-alalla puhutaan single source of truthista, eli että olisi joku teknologia, ehkä data-alusta tai datakatalogi, jossa olisi se “virallinen totuus”.
Onko olemassa virallista ja universaalia totuutta datasta? On ja ei. Asia ei ole mustavalkoinen. Vastaus on minusta: se riippuu kontekstista.
Määritykset tiedolle ovat se ratkaisevin juttu. Jos niistä päästään yksimielisyyteen, voidaan päästä lähemmäs “yhtä totuutta”.
Moni ajattelee, että esimerkiksi data lakehouse olisi ratkaisu tähän, mutta ei se ole, jos määritykset eivät ole yhteiset.
Esimerkiksi HUS:illa aikanaan mietittiin, kuinka monta potilaskäyntiä heillä on per yksikkö per kuukausi. Luulisi olevan yksinkertainen kysymys, mutta ei se ollut.
Lasketaanko potilaskäynteihin, jos potilas käy hoitojen välissä kotona? Onko potilaskäynti sama kuin lääkärin vastaanotto, vai mitä ylipäätään lasketaan “käynniksi”? Entä kotihoito?
Nämä ovat puhtaasti määrittelykysymyksiä. Eri määrittelyillä saadaan täysin eri luvut. Ei siinä auta mitkään medallion-arkkitehtuurit.
Kaikkien mittareiden (kuten KPI:den) pohja menee, jos emme tiedä, mitä mittaamme.
Esimerkkejä on vaikka kuinka:
“Kuinka monta asiakasta meillä on per kuukausi?”
Lasketaanko vain ne, jotka ostivat juuri sinä kuukautena, vai myös ne, joilla on kanta-asiakkuus ja jotka ostavat muina kuukausina?
Liidin määritelmä on joka firmassa eri. Onko liidi se, joka tilaa uutiskirjeen, vai se, jonka myyntihenkilö on tavannut kerran? Pelkällä määrittelyllä liidien määrä voidaan helposti tuplata.
Metadata on semanttisen kerroksen tärkein “polttoaine”
Voimme ajatella, että “ok, jos merkitykset ovat erilaisia, niin ehkä IT-järjestelmien syövereistä löytyy totuus?” Sinnehän ne tallentuvat, mitä tulkinnanvaraa niissä voisi olla?
Haaste on sama sielläkin: yhdessä systeemissä asiakas on “Customer” ja toisessa “Client”. Mistä data engineerin pitäisi tietää, ovatko ne sama asia?
Tietokannassa voi olla avaimia kuten client_id ja customer_id. SQL-haku on haastavaa ilman, että määrityksiä on mietitty. Ja jos SQL-haku tehdään tekoälypromptilla (kuten nykyisin on tapana), sekaannus voi olla vielä suurempi.
Tässä kohtaa semantiikan arvo nousee korkeaksi.
Jos lisäämme määrityksiin metadataa, attribuutteja, kuvauksia, omistajuutta, validointistatusta, liiketoimintalogiikkaa jne, alkaa tekoälyn hyödyntäminen data-analytiikassa helpottua.
Klassinen tiedon mallinnus, jossa edetään käsitemallista loogiseen ja lopulta fyysiseen, taklaa juuri tätä haastetta. Ja tämä on hyvä uutinen: voidaan käyttää jo hyväksi todettua menetelmää.
Palaan takaisin analogiaan: tekoälyn opetus on kuin uuden työntekijän perehdyttämistä. Käsitemallinnuksen idea on vähentää kommunikaatiovirheitä ihmisten välillä: selvitetään, mitä “asiakkaalla” tai “potilaskäynnillä” tarkoitetaan.
Nyt se auttaa ihmisen ja koneen välisen kommunikaation parantamisessa.
Ennen saatettiin ajatella “ollaan agileja ja moderneja” ja hypätään semantiikan ja määritysten yli ja ruvetaan vaan koodaamaan. Näin ei enää kannata ajatella.
Et voi hypätä tämän yli, jos promptaat tekoälyä tosissaan.
AI-aikakaudella käsitemallinnuksella ja semantiikalla voidaan määrittää datan merkitys niin, että relaatiot ja standardit tekevät siitä ymmärrettävää sekä ihmiselle että koneelle.
Semantiikkaa informaalista formaaliin
Miten tämä käytännössä tehdään? Eri funktioiden kieli on syvään juurtunutta, miten saavutetaan yksimielisyys?
Voidaan järjestää käsitemallinnusworkshopeja, joissa käydään keskeiset termit läpi: selitykset, synonyymit (ja myös homonyymit) ja sovitaan yhteiset nimitykset.
Jo pelkkä keskustelu on usein silmiä avaavaa: kun data engineer ymmärtää paremmin mistä on kyse, on alustojen tekeminenkin paljon helpompaa.
Jos halutaan lisää systemaattisuutta, voidaan hyödyntää taksonomiaa ja luokitella käsitteet hierarkkisesti, eli luodaan viralliset säännöt.
Klassinen vanhempi–lapsi-hierarkia on monelle tuttu:
vaate → urheiluvaate → juoksuhousut.
Juttelin juuri Katariina Karin kanssa. Hän on kansainvälisesti tunnettu ontologia- ja knowledge graph -osaaja ja on rakentanut osaamista mm. Zalandolle ja IKEA:lle.
Jos mietitään nettikauppaa, niin ilman taksonomiaa tuotteiden hakeminen on yllättävän vaikeaa. Kaikki me ollaan tehty hakuja tyyliin “koti → huonekalut → olohuone → sohva” tai “makuuhuone → sängyt”.
Nettikaupoissa ja tuotehallinnassa tätä on tehty pitkään, mutta datan hallinnan kontekstissa tämä ei ole vielä kaikille tuttua.
Edelleen formaaliutta voidaan lisätä ontologian muodossa: muutetaan käsitteet ja relaatiot ontologiaksi standardoituun, koneellisesti luettavaan muotoon. Esimerkiksi yleisimmät standardit ovat:
- RDF (Resource Description Framework) → kolmikot: subjekti – predikaatti – objekti
- RDFS (RDF Schema) → luokat, aliluokat, perusrelaatiot
- OWL (Web Ontology Language) → rikkaammat säännöt, rajoitteet, päättely
Mikä ero on käsitemallinnuksella ja ontologialla?
Voisi sanoa, että käsitemallinnuksen keskeinen tavoite on vangita tietyn organisaation sisäinen kieli ja termit, ja yhdistää ne dataan. Ontologia pyrkii tekemään tiedosta koneluettavaa formalisoimalla kieltä, jolloin se suuntautuu enemmän ulospäin.
Kannattaako tämä työ?
Monesti käsitemallinnusta (eli semanttisen kerroksen määritystä) tehdään “ohimennen” osana vaatimusmäärittelyä. Systemaattisuuden taso vaihtelee firmasta firmaan.
Kyse on oikeastaan siitä, tehdäänkö sitä intentionaalisesti ja dokumentoidusti vai sivumennen. Panostetaanko mallien jakamiseen, uudelleenkäytettävyyteen ja päivitykseen, vai onko “tallennuspaikkana” projektihenkilöstön päässä oleva sisäinen kovalevy?
Joka tapauksessa sitä tehdään aina jollain tasolla, usein BI-kerroksessa ja KPI-määritysten yhteydessä.
Haaste on, että jos määritystyö tehdään vasta BI-kerroksessa, ratkaisut jäävät pistemäisiksi. Siksi semanttinen kerros kannattaa tehdä alemmalla tasolla, lähemmäs fyysistä dataa (ja lähdejärjestelmiä).
Jos mietitään, että teoriassa kuvitteellinen Firma X ymmärtäisi semantiikan merkityksen datan hyödyntämisessä ja AI:ssa, määrityksiä tehtäisiin systemaattisesti ja dokumentoitaisiin järkevästi, tästä olisi valtava hyöty myös kaiken data governance -tekemisen kannalta.
Itse asiassa moni data governance -haaste johtuu nimenomaan business-käsitteiden määrittelyn puutteesta.
Datan laadunvalvonta helpottuisi, koska ymmärretään dataa paremmin sekä mistä ja miten se muodostuu. Data-alustat voidaan toteuttaa business-käsitteiden ja logiikan läpi, luoda selkeät nimeämiskäytännöt tauluille, mapping helpottuisi ja omistajuusasiat selkiytyisivät.
Etuja olisi niin pitkä lista, ettei yksi blogi siihen riitä.
Ja kirsikkana kakun päällä on uusi käyttötapaus: tekoäly.
Firma X olisi etulyöntiasemassa, koska se voisi oikeasti “hakea promptaamalla” mitä vain dataa omista IT-järjestelmistään niin, että tekoäly ymmärtää, kuten junior-analyytikko tai data engineer, mitä tarkoitat.
Ihan toinen kysymys on se, miten tämä vaikeaselkoinen käsite/ontologia/semanttinen tekeminen myydään liiketoiminnalle. Se kuulostaa alkuun kun istuisi yliopistossa filosofian luonnolla ja yhteys yrityksen johtamiseen ja niin sanottuun ”bisnekseen” ei heti avaudu.
Uskon senkin olevan mahdollista, jos se tehdään oikein: business-hyötyjen kautta (ja älkää unohtako sanoa taikasanaa “tekoäly”, niin liiketoimintaa alkaa kiinnostaa, koska golf-klubilla kaikki bisnestyypit kehuvat, että meidän firmassa tehdään tekoälyä viimeisen päälle ja ollaan näin kehityksen aallonharjalla:)
Tarvittavat työkalut
Me IT-ihmiset helposti lähdetään miettimään työkaluja ja teknologioita. Se ei ole tämän kirjoituksen pointti, mutta relevantti kysymys yhtä kaikki.
Yksi esimerkki työkalusta käsitemallinnukseen on Ellie.ai, jota käytetään käsitteiden ja määritysten tekemiseen yhteistyössä business- ja dataihmisten välillä. Sen kautta olen myös tutustunut johtaviin ontologia-asiantuntijoihin, kuten Katariina Kariin ja amerikkalaiseen Jessica Talismaniin.
Kun Ellie.ai:ta alun perin lähdettiin kehittämään, ajatus oli tukea kielen yhdenmukaistamista ihmisten välillä. Sama lähestymistapa toimii nyt myös ihmisen ja koneen välisessä kommunikaatiossa.
Työkalussa voidaan liittää käsitteitä konkreettisiin tietolähteisiin ja tauluihin, mikä helpottaa käsitekerroksen ja fyysisen datan välistä yhteyttä.
Datakatalogituotteet ovat keskeisiä työkaluja semanttisen kerroksen ja metadatan hallinnassa, joskin monet niistä ovat varsin teknisiä ja raskaita business-käyttäjän näkökulmasta.
Yhtä kaikki, datakatalogit tuovat merkittävää lisäarvoa metadatan hallintaan ja governancen tukemiseen.
Käsitemallit voidaan tarvittaessa viedä formaalimpaan muotoon, kuten OWL-muotoisiksi ontologioiksi, ja jatkokäsitellä esimerkiksi Protégé-työkalulla.
En lähde tässä luettelemaan data-alustatyökaluja tai tekoälysovelluksia sen enempää. Valitset sitten Fabricin, Databricksin, Snowflaken, Copilotin tai Clauden, varmasti homma etenee.
Oleellisempaa on, että merkitykset ja määritykset on tehty huolella.
Ja tietysti se, että meillä on jokin suunnitelma, jonka pohjalta etenemme.
Tässä muuten hyvä artikkeli aiheesta:
https://medium.com/@alexpongpech/dont-skip-the-data-modeling-the-hidden-foundation-of-every-good-knowledge-graph-b84c9752da88
Jessica Talisman, Katariina Kari ja kumppanit ovat nyt järjestämässä uutta The Knowledge Graph Academy course -koulutusta, jonne on jo satoja ilmoittauneita, sillä aihe on nyt todella ajankohtainen.
Olemme työskennelleet valtaosan Suomen 30 suurimman yrityksen kanssa, syvennä osaamistasi DAMA Data Management Fundamentals –koulutuksessa tai vie data ja tekoäly käytäntöön kokeneiden asiantuntijoiden avulla Hovi Data Hubin kautta.
Ystävällisin terveisin,
Johannes Hovi
