Pelkkä data ei riitä nostamaan tekoälyä yksittäisten tehtävien suorittajasta strategiseksi kumppaniksi. Jotta agentit pystyvät hahmottamaan syy-seuraussuhteita ja tekemään itsenäisiä päätöksiä, ne tarvitsevat prosessikartan: kokonaiskuvan organisaation riippuvuuksista ja toimintalogiikasta.
Rakensin äskettäin yksinkertaisen tekoälypohjaisen analytiikkatyökalun. Syötin muutamien Grafana-näkymien metatiedot (otsikot, näkymien kuvaukset ja kyselytiedot) vektori-tietokantaan ja loin tiedon päälle tekoälyagentin, joka upotti graafit pyydettäessä suoraan chat-käyttöliittymään.
Käyttäjän kysyessä: “Näytä churn viimeiseltä viideltä päivältä.” tekoäly ymmärsi kyselyn, löysi poistumisasteen kuvaavan graafin ja upotti sen suoraan keskusteluun oikein aikavalinnoin. Näin käyttäjälle saatiin vastaus kysymykseen “Mitä tapahtui?”.
Mutta käyttäjän seuraava kysymys on oikeastaan aina “Miksi?“:
- Miksi churnissa on piikki aina keskiviikkoisin?
- Mikä aiheutti poikkeaman X?
Työkalu ratkaisi tarpeen, mutta synnytti suoraan uuden tarpeen. Jäin pohtimaan, voiko ongelmaa edes ratkaista?
Epäilen, että emme pysty ratkaisemaan “miksi?”-ongelmaa esimerkiksi analytiikka-agenttien kontekstissa vielä lähivuosina – kyseessä on uskomattoman vaikea ongelma! Sen sijaan ongelmaa voisi tutkia jonkin toisen käyttötapauksen kautta. On olemassa strukturoidumpi “miksi?”-ongelma, jonka voimme ratkaista paljon nopeammin: koodausagenttien puolella.
Junior-kehittäjän haasteet
Tekoälykehitys on nosteessa. Koko ajan syntyy uusia agentteja, jotka ovat hieman fiksumpia kuin edelliset, sisältävät enemmän keskustelun kontekstia kuin edelliset ja pienillä lisäyksillä parantavat käyttäjän kokemaa edellisiin verrattuna.
Tällä hetkellä agentit ovat erittäin hyviä ratkaisemaan “juniorikoodaaja”-ongelmia. Anna tekoälylle tehtävä, niin se tekee suunnitelman, jonka jälkeen kirjoittaa halutun koodin.
Testivetoisella kehityksellä (TDD) voidaan hallita koodin generointia vahvemmin: tekoäly kirjoittaa ensin testit ja sitten koodin. Näin tekoäly pystyy lisäämään uusia ominaisuuksia rikkomatta vanhaa ja koodin laatu on parempaa.
Ollaan kuitenkin edelleen siilossa: juniorikehittäjä (tai tekoäly ilman karttaa) lisää aina uuden ominaisuuden nykyiseen koodikantaan.
Oletetaan, että meillä on monimutkainen järjestelmä, joka toteuttaa verkkokaupan. Jos pyydät “personoitu paketointi” -ominaisuutta ja annettu koodikanta tietää vain kassa-palvelun, rakentaa juniori todennäköisesti sen kyseiseen palveluun.
Juniorilla ei ole keinoa tietää vastauksia kysymyksiin:
- Mitkä ovat kassa-palvelun rajat?
- Kuuluuko uusi feature lainkaan kassa-palveluun?
- Onko paketointi erillinen kokonaisuus, jolla pitäisi olla oma palvelunsa? Entä personointi, missä sen pitäisi asua?
Juniori ei pysty vastaamaan näihin kysymyksiin, koska häneltä puuttuu kartta, joka näyttää oman palvelun suhteen muihin palveluihin. Oikeassa elämässä avuksi astuvat tässä vaiheessa seniorikehittäjä ja toisaalta yhteiset arkkitehtuuripäätökset.
Tekoäly ei kuitenkaan pysty kysymään kaverilta tai arkkitehdeiltä, joten miten voisimme nostaa tekoälyn kehityksen seuraavalle tasolle? Miten pidämme agentit ajan tasalla koko palveluarkkitehtuuristamme?
Prosessikartta: agentin opas ymmärrykseen
Tekoälyagenteiltamme puuttuu selvästi prosessi-ymmärrys. Ymmärtämällä yrityksen prosesseja ja niissä mukana olevia järjestelmiä agentti pystyy tekemään parempia päätöksiä, jopa arkkitehtuurisia valintoja. Kartta tulisi olla automaattisesti päivittyvä, jotta myös agenttien uudet päätökset tulevat osaksi karttaa.
Koodaavan agentin osalta riittäisi, jos agentille pystytään kuvaamaan järjestelmät ja niiden väliset riippuvuudet. Lähdetään tästä liikkeelle.
Modernissa järjestelmässä prosessikartassa on muutamia osia: Synkronisissa palveluissa API-dokumentaatio (esim. OpenAPI-määritys) on palveluiden välinen sopimus. Se kertoo myös tekoälylle, mitä on missäkin saatavilla, mutta se ei näytä, kuka mitäkin kutsuu. Tarvitaan siis lisäksi palvelukartta (saadaan usein Service Mesh:stä tai APM-työkalusta). Palvelukartta näyttää API:en väliset riippuvuudet. Kun käyttäjät ovat tiedossa, puhutaan joissain tapauksissa myös näiden välisistä sopimuksista (Data Contract).
API-dokumentaatio ja palvelukartta rakentavat prosessikartan järjestelmäkehityksen näkökulmasta. Tekoälyagentti pystyy näiden perusteella ymmärtämään, mihin uusi ominaisuus kuuluisi.
Entä asynkroniset event-pohjaiset palvelut? Yksi vaihtoehto olisi rakentaa tapahtumaluettelo (Service Catalog): Tapahtumaluettelo sisältää palvelumääritykset (service descriptions), tapahtumamääritykset (event descriptions) ja putkimääritykset (pipe descriptions), joilla saadaan ymmärrys, kuka luo mitäkin tapahtumia mihin putkiin ja kuka niitä kuluttaa. Tapahtumaluettelo kartoittaa luonnostaan sekä “mitä?” että “kuka?” koko asynkronisessa arkkitehtuurissa.
Juniorista senioriksi
Annetaan nyt koodausagentillemme koostamamme “prosessikartta” (API-määritykset & Palvelukartta ja/tai Tapahtumaluettelo) ja sama tehtävä: “Lisää personoitu lahjapakkaus -optio ostoskorin maksuvaiheeseen”.
Tekoälyn ajatusprosessi voisi olla seuraavanlainen:
- Analysoi pyyntö: Käyttäjä haluaa lisätä personoidun lahjapakkauksen. Tämä on osa ostoprosessia.
- Analysoi oma koodikanta: Onko meillä jo personoituja ominaisuuksia? Tietääkö koodikantani käyttäjästä ylipäätään mitään?
- Kysy “Prosessikartalta”: Nyt, kun tiedän, mitä uusi ominaisuus tarkoittaisi koodikannallemme, missä tämän ominaisuuden pitäisi olla? Tarkistan prosessikartasta kokonaisuudet ja palvelut. Pitäisikö minun tehdä tämä, vai pitäisikö minun siirtää pyyntö toisen palvelun kehittäjille?
- Muotoile arkkitehtuurisuunnitelma (DDD-ajattelu): Paketointi kyseisellä monimutkaisella logiikalla on oma liiketoimintakonseptinsa. Sillä on oma logiikkansa (personointiattribuutit, käärimismaksut, käärevarasto, sesonkitarrat). Tämän pitäisi siis olla uusi palvelu ja kassa-palvelu kutsuisi uutta palvelua API:n kautta (kuten yleisesti tämän yrityksen järjestelmissä). Paketointi-palvelu lähettää myös omat tapahtumansa, joita tarvitaan varasto-palveluun.”
- Luo dokumentaatio prosessimuutoksesta
Näin tekoäly ei vain lisännyt ominaisuutta. Se teki perustellun arkkitehtuurisen päätöksen käytettyjen periaatteiden perusteella, aivan kuten arkkitehti tekisi.
Se lisäsi myös uudet ominaisuudet nykyiseen dokumentaatioomme. Tekoäly ei ole vielä hyvä lukemaan ja piirtämään arkkitehtuurikaavioita, mutta se pystyy koodaamaan melko hyvin. Kun dokumentaatio sijaitsee lähellä koodia, se voi tehdä tarvittavat muutokset suoraan dokumentaatioon.
Staattisten datakatalogien tuolla puolen
Mietitään tulevaisuutta ja aikaa, jolloin tekoälymallit pystyvät entistä paremmin vastaamaan kysymykseen “miksi?” useissa eri konteksteissa. Siinä vaiheessa järjestelmät esimerkiksi seuraavat liiketoimintaamme reaaliajassa ja tekevät ehdotuksia seuraavista toimenpiteistä.
Mitä tietoja tällainen järjestelmä tarvitsisi?
Uskoisin, että tarvitaan edelleen staattiset metatiedot itse datasta: datakatalogit, API-kuvaukset, ja muut vastaavat. Metatiedot datan löytämiseksi ovat välttämättömiä tekoälyagenttien (ja ihmisten) tutkiessa “mitä tapahtui?”. Nämä voivat olla tietokantojen ja taulujen kuvauksia tai vaikkapa tapahtumakuvauksia.
Tekoälyllä on siis riittävä osaaminen yhdistää tieto tarpeeseen eli kysymykseen, mutta agentti ei pysty ymmärtämään syy-seuraus -suhteita tiedon taustalla. Jotta agentti pääsee tähän se tarvitsee myös prosessikirjallisuutta: tarpeeksi tietoa liiketoimintaymmärryksen rakentamiseen. Toisin sanoen ymmärryksen prosesseista, järjestelmistä, järjestelmien rooleista, sekä riippuvuuksista. Koneelle prosessit näyttäytyvät tietovirtojen kautta.
Yhteinen tieto ei ole vain API-dokumentaatiota tai datakatalogeja. Kun itsenäiset tekoälyagentit integroituvat yhä vahvemmin yrityksiemme prosesseihin, yhteisestä tiedosta tulee kriittinen voimavara – olennainen sääntökirja, joka mahdollistaa toimimisen turvallisesti ja tehokkaasti.
Arked on auttanut useita yrityksiä ymmärtämään miten omaa prosessi- ja järjestelmäkokonaisuutta tulisi dokumentoida uusien tarpeiden kasvaessa. Autamme mielellämme vastaavissa haasteissa!
