Siirrettävät liiketoimintaontologiat tekoälyagenteille

”Ontologia” on nyt muotisana. Miksi? Agentit ja niitä käyttävät suuret kielimallit tarvitsevat liiketoimintaan liittyvää kontekstia.

Ennen kuin sitoudut ontologian käyttöön, kysy toimittajalta: ”Miten työntekijämme voivat korjata ontologiaa, kun se kuvaa liiketoimintaamme väärin – ja mikä on jatkossakin riippuvaista teistä?” Vastaus kertoo paljon siitä, kenen liiketoimintamalliin olet sitoutumassa. Se tuo esiin myös laajemmat panokset: kykysi kehittää mallia liiketoiminnan muuttuessa ja varmistaa, että siihen tehty investointi pysyy hyödyllisenä, vaikka vaihtaisit alustaa.

Ontologia on hyvä erottaa tietämysgraafista, vaikka nämä kaksi usein limittyvätkin.

Ontologia määrittää, millaisia asioita on olemassa, mitä suhteet tarkoittavat ja mitä sääntöjä sovelletaan. Tällaisia asioita ovat esimerkiksi laitteet, komponentit, tiimit, roolit ja prosessit. Ontologiassa voidaan esimerkiksi määritellä tyyppi ”Laite” ja suhde ”Sisältää” komponenttiin. Tietämysgraafi voi tämän jälkeen ilmaista: ”Pumppu P-101 sisältää tiivisteen S-7” – eli kaksi yksittäistä entiteettiä ja niiden välisen suhteen.

Kuvittele, että pyydät agenttia: ”Laske saman myymälän myynnin kasvu ja esitä rinnakkain ensin kaikki myymälät sisältävä laskelma ja sitten laskelma, josta on rajattu pois alle 2 vuotta avoinna olleet myymälät. Erittele sen jälkeen molempien laskelmien luvut kotimaan, kansainvälisen ja yhdistetyn osuuden mukaan.”

Pyyntö edellyttää tietoja, joita agentti ei voi arvata:

• mitä myymälöitä on olemassa ja milloin ne avattiin
• missä ne sijaitsevat
• miten ”saman myymälän myynti” määritellään yrityksen sisällä

Käytännössä myymälät voidaan jättää laskennan ulkopuolelle, kunnes ne ovat olleet avoinna vuoden. Pyydetty kahden vuoden ryhmä tuo tähän vielä yhden rajauksen. Verrataanko tällöin kalenterikuukausia heti, kun myymälä täyttää ehdon, vai otetaanko se mukaan vasta kokonaisen edeltävän tilikauden jälkeen?

Ontologian on yhdistettävä myymälät laskentaa ohjaavaan käytäntöön. Liittyvien tietojen löytäminen auttaa, mutta vastauksesta tekee hyödyllisen oikean säännön soveltaminen.

Ennen kysymykseen vastaamista agentti voi hakea olennaista kontekstia hyödyntämällä graafin suhteita. Eikä ihme, että niistä on hyötyä, sillä tietämysalueet voivat helposti muuttua hyvin monimutkaisiksi.

Kuva 1: Kaavio: yhdistetyt julkiset SysML-mallit: TMT Thirty Meter Telescope (Open-MBEE/JPL, Apache-2.0), CubeSat System Reference Model (© 2022 INCOSE SSWG & OMG SDTF, CC BY 4.0), Architecting Spacecraft with SysML (Friedenthal & Oster, BSD-2-Clause) sekä fiktiivisen MDC-konstellaation sisältöä ja julkisia määrityksiä (IS-GPS-200, IS-GPS-705, GSFC-STD-7000B). Esitetty Kamiwaza Kaizenissa.

Tietojen poiminta voi kuitenkin myös kirjata virheitä. Tiimit voivat käyttää samasta entiteetistä eri nimiä, jolloin syntyy kaksoiskappaleita. Lähteet voivat olla keskenään ristiriidassa tai vanhentua. Suuren kielimallin tulkinta voi olla väärä silloinkin, kun lähde on moitteeton. Virheiden esittäminen auktoritatiivisina ei tee niistä yhtään vähemmän vaarallisia.

Riskit kasvavat, kun liiketoimintaa kuvaavasta mallista tulee järjestelmä, joka toimii sen perusteella. Väärä suhde voi silloin johtaa väärään toimintaan, ei pelkästään väärään vastaukseen.

Ontologiatuotteiden riskit

Varo ensinnäkin joustamattomia malleja. Kaikki valmiina -ratkaisun nimissä toimittaja saattaa tehdä omista entiteeteistään ensisijaisia ja samalla rajoittaa sitä, mitä omilla entiteeteilläsi voi tehdä. Mukauttamisesta ei ole hyötyä, jos mukautetut tyypit menettävät haku-, validointi- tai toimintavalmiutensa.

Toiseksi selvitä, miten tiedon löytämisestä edetään sen hallintaan. Työkalun pitäisi mahdollistaa graafin alustava muodostaminen suuren kielimallin havaitsemien tietojen perusteella ja sen jälkeen graafin validointi selkeitä rajoitteita vasten. Poikkeustapaukset pitäisi voida siirtää ihmisten käsiteltäviksi ja alustavasti karttunut tieto säilyttää käsittelemättä sitä hyväksyttynä liiketoimintatietona.

Suurin riski on sitoa liiketoimintaprosessit alustaan, josta et voi lähteä. Ontologiasi kuvaa liiketoimintaasi: sen tietoja, prosesseja ja suhteita. Tiedon kuratointiin ja liiketoimintalogiikkaan tekemäsi investoinnin pitäisi pysyä hyödyllisenä, vaikka vaihtaisit työkalua. Miksi toimittajan pitäisi saada lukita se omakseen?

Missä graafiupotuksista on hyötyä

Kun tietämysgraafit kasvavat hyvin suuriksi, voi olla järkevää valita työkalu tai toimittaja, joka tukee graafiupotuksia. Ne muistuttavat läheisesti semanttisia upotuksia, joita käytetään monissa RAG-sovelluksissa. Niistä voi olla hyötyä kahdella tavalla.

Ensinnäkin tiheästi kytkeytyneessä graafissa muutama siirtymä voi tuottaa käsiteltäväksi liian monta entiteettiä. Upotukset oppivat entiteettien ja suhteiden numeerisia esityksiä ja tarjoavat toisen tavan löytää graafista olennaisia osia. Oikeassa tehtävässä tämä voi olla tehokkaampaa kuin graafin läpikäynti.

Toiseksi upotusmallit voivat asettaa ehdokkaana olevat puuttuvat suhteet paremmuusjärjestykseen. Sama oppiminen voi paljastaa tietylle entiteettityypille tyypillisiä attribuuttien ja suhteiden malleja ja auttaa näin täydentämään graafia.

Jatkuvan kehittämisen puolesta

Miten voit hallita omaa tulevaisuuttasi, välttää toimittajalukon ja mallintaa todellista liiketoimintaasi toimittajan sanelemasta karikatyyrisestä versiosta poikkeavasti ilman suurta määrää asiakkaan käyttöön sijoitettuja insinöörejä? Tässä nykyaikainen tekoäly pääsee mielestäni oikeuksiinsa, jos työkalut mahdollistavat etenemisen tiedon löytämisestä sen varmentamiseen.

Käytä ensin automaattista tiedonhakua ja poimintaa. Voit muodostaa alustavan kuvan toimialueesta yritysasiakirjojen, käytäntöjen, sähköpostien tai Slack-viestien pohjalta. Olennaista on, ettei tietojen paikkansapitävyyteen voi luottaa ennen niiden tarkistamista.

Toinen vaihe on tietojen tarkistaminen. Työkalujesi on tarjottava sujuva polku poimituista ehdokkaista lähteisiin perustuviin väitteisiin ja vastuuhenkilön tai auktoritatiivisen järjestelmän vahvistamaan tietoon. Säilytä jokaisen väitteen lähde.

Tietojen ajantasaisuus vaatii jatkuvaa työtä. Tukipyynnön käsittelyprosessi tai vastaus kysymykseen ”kuinka monta myymälää New Jerseyssä on” ei välttämättä ole tänään sama kuin kolme vuotta sitten. Nykyisen tiedon päivittäminen ei kuitenkaan saa pyyhkiä pois eilistä todellisuutta. Faktan kirjaamisajankohta ja ajankohta, jolloin se piti paikkansa, voivat olla eri; hyödyllisen ontologian on tuettava sekä nykyhetkeä koskevia vastauksia että tarkkaa historiallista näkymää. Jonkun on silti pidettävä tiedot ajan tasalla.

Laajuus voi olla valtava. Aloita pienemmästä aineistosta, mallinna hyödyllinen toimialue ja rakenna kohti kattavaa kokonaiskuvaa samalla, kun tuotat arvoa matkan varrella.

Asiakastuki on yksi hyödyllinen rajattu kokonaisuus: saapuvat puhelut ja sähköpostit, tikettijärjestelmä, automaattisesti ratkaistavat tapaukset, asiakkaille vastaamaan pystyvä tukitiimi sekä prosessi todellisten ohjelmistovirheiden eskalointiin kehitystiimille. Se yhdistää tiedon toimintaan ja tuo esiin samat riskit ja hyödyt hallittavassa kokonaisuudessa.

ServiceNow’n Common Service Data Model havainnollistaa rajoitetta. Sen CSDM 5 -valkoisessa kirjassa varoitetaan: ”Jos näitä tietoja ei ole määritetyissä tauluissa, et välttämättä saa täyttä hyötyä ServiceNow AI Platformista.” Varoitus luo itsessään suunnitteluun ja toimintaan liittyvän rajoitteen: nojaatko vahvasti toimittajan malliin vai hyväksytkö riskin? Entä jos se tarkoittaa, että yrität sovittaa pyöreää tappia heidän nelikulmaiseen reikäänsä?

Oletetaan seuraavaksi, että ontologia-alusta tarjoaa myös tiedon sisäänlukuun, muunnoksiin, toimintoihin ja liiketoimintasääntöihin tarvittavat ominaisuudet. Entiteetit, attribuutit ja suhteet saattaa pystyä viemään alustalta. Mutta pystytkö siirtämään myös muunnokset ja toimintoputket, jotka tekevät muutoksia tietokantoihisi, kutsuvat webhookeja ja aiheuttavat muita sivuvaikutuksia? Tiiviisti kytketyt integraatiot voivat lukita itse liiketoiminnan toimittajaan.

Miksi joustavuudella on nyt merkitystä

Ohjelmistot valtaavat maailman, ja tekoäly ohjelmistot. Kun tiimit käyttävät tekoälyä sekä ohjelmistojen rakentamiseen että niiden toiminnan voimanlähteenä, yhä suurempi osa liiketoimintalogiikasta voi sitoutua näihin alustoihin. Jokaisesta hyödyllisestä automaatiosta voi samalla tulla uusi riippuvuus alustasta luopumista suunniteltaessa. On vaarallista antaa toimittajan tulla sinun ja ketteryytesi väliin.

Johtopäätökset

On mahtavaa olla elossa juuri nyt! Ei ihme, että ihmiset tutkivat ontologioiden mahdollisuuksia tarjota agenteille kontekstia. Kontekstin laajentaminen prosesseihin ja integraatioihin voi tuottaa todellista arvoa. Palataan alussa esitettyyn kysymykseen. Työntekijöidesi tekemien korjausten pitäisi saada malli heijastamaan liiketoimintaasi entistä paremmin. Tämä karttuva ymmärrys on liian arvokasta menetettäväksi alustaa vaihdettaessa. Nurkkaan ajautuminen on myös todella huono vaihtoehto.