FI
SV
EN
Ohjelmistokehitystä viime vuodet kovalla kädellä ravistelleiden tekoälysovellusten ja -agenttien kehitysaskeleet ovat pitäneet keskustelun vilkkaana myös toimistojen kahviautomaateilla. Riippumatta henkilökohtaisista tai toimintayksiköiden resursseista, kehitykselle ei maailmanlaajuisesti investoitujen biljoonien myötätuulessa ole luvassa hidasteita.
Kaiken tämän uuden keskellä voimme kuitenkin löytää ja havaita entuudestaan tuttuja konsepteja. Tässä blogissa pohdin tekoälyagenttien roolia sovellustason arkkitehtuurissa nostamalla esiin erään näkemyksen yhden agentin ja moniagenttisten ratkaisujen eroista. Lisäksi tarjoilen yleiskuvan nykypäivän tekoälyagenttien tuomista mahdollisuuksista ohjelmiston ja sen ominaisuuksien kehitykseen.
Mikä agentti oikeastaan on?
Tekoälyagentti terminä juontaa juurensa jo vuosikymmenten päähän, mutta kun kysyin asiasta kielimallilta, tämän päivän vastaus oli seuraava:
”Tekoälyagentti = ohjelmallinen entiteetti, joka käyttää tekoälyä itsenäisesti suorittaakseen tehtäviä, tekee päätöksiä, käyttää työkaluja ja kommunikoi ympäristönsä tai muiden agenttien kanssa tavoitteen saavuttamiseksi.”
Hyvä! Agentti siis suorittaa tehtäviään saatavissa olevien resurssien avulla, joten määritelmä ei olennaisilta osin juuri poikkea historian havinasta. Tarvitsemme kuitenkin jonkinlaista konkretiaa, sillä nykyäänkään tekoälypohjaiset sovellukset eivät ”suorita tehtäviä”, vaan ne ”suorittavat tehtävän” juuri pyydetyllä tavalla ja siten kuin ne ovat ohjelmoitu. Tämän ajatuksen pohjalta voimme luokitella tekoälyagentit esimerkiksi niille määrättyjen tehtävien mukaan seuraavasti:
Kielenkäsittely- ja sisällöntuotantoagentit
• Tulkitsevat tai tuottavat luonnollista kieltä, kuten käännöskoneet
Tiedonhaku- ja analyysiagentit
• Suorittavat hakukyselyitä, yhdistelevät tietoa ja tuottavat raportteja
Toimintapohjaiset agentit
• Kutsuvat rajapintoja, lähettävät viestejä, DevOps
• Seuraavan sukupolven nocode?
Orkestrointi- ja valvonta-agentit
• Tehtävien jako, työvirtojen ohjaus, priorisointi
Päätöksenteko- ja suositusagentit
• Riskianalyysi, suositukset, strategia
Validaatio- ja tarkistusagentit
• Järkevyys, loogisuus, laadunvarmistus
Oheinen listaus herättänee etenkin kollegoissani tiukkoja kysymyksiä ja vastaväitteitä. Hyvä niin. Tärkeintä on kuitenkin pystyä erottelemaan erilaisia tekemisen tyyppejä ja tapoja, mikä auttaa meitä pohtimaan peruskysymystä: voiko yksi tekoälyllä tehostettu moottori ratkaista kaikki käsillä olevat ongelmamme, vai voimmeko hyödyntää (tätä tai kenties parempaa) jaottelua tunnistaaksemme tarvittavat kyvykkyydet kulloinkin käsillä olevaan ongelmaan?
Yhden agentin periaate
Seuraavaksi pieni ajatusleikki. On vuosi 2151. Teknologinen kehityksemme on mahdollistanut poimuajon kautta tähtienvälisen matkailun, ja olemme luoneet ensimmäistä kertaa kontaktin maan ulkopuoliseen elämään. Mutta miten kommunikoimme uusien naapuriemme kanssa? Toki lingvistiemme osaamisen kautta olemme jo aiemmin kehittäneet hyvin toimivat SaaS-palvelut kielikäännösten reaaliaikaiseen luomiseen, mutta nyt meillä on edessämme, ei ainoastaan yksi, vaan useita aurinkokuntia täynnä elämää. Mitä siis voimme tehdä?
Yksi vaihtoehto on se, että muokkaamme kehittämäämme SaaS-järjestelmää tunnistamaan rakenteita meille entuudestaan tuntemattomasta kielestä. Rakenteiden kautta tunnistamme konjunktioita ja sanoja, lopulta olemme tunnistavinamme vieraan kielen hienoimpia nyansseja ja jopa sarkasmin kaltaisia ilmaisutapoja. Olemme kuitenkin niin tottuneet omassa kuplassamme kielten samankaltaisuuteen, ettemme ole koskaan ajatelleet näin suuria laajennustarpeita nykyisessä käännösjärjestelmässämme.
Yllä oleva kuva esittää, miten SaaS-palvelu ottaa vastaan jonossa käännettävät kommunikeat. Ongelma on helposti hahmotettavissa: älykkäät kielen tunnistus- ja kääntämispalvelumme tuntevat jotkin kielet jo entuudestaan paremmin kuin uudet tai esoteerisemmat kielet. Helposti käsiteltävät asiat jäävät kuitenkin prosessijonoon, koska agenttimme tekee kaiken yhden monoliittisen palvelun resurssien rajoissa – ja siksi uudet, vaikeat asiat kuluttavat resurssejamme.
Moniagenttinen ratkaisu
Jos luomme yhden tekoälyvahvistetun sovelluksen ratkaisemaan ongelmamme, luomme helposti vähänkin monimutkaisemmissa prosesseissa edellä nähdyn kaltaisia turhia pullonkauloja. Entä jos erottelemmekin selkeästi suorittavat yksiköt omiin lokeroihinsa tarkalleen määritellyn tehtävänsä perusteella.
Voimme siis luoda monoliittisen agentin sijaan useampia agentteja, joilla kaikilla on oma hyvin määritelty roolinsa. Yksi agentti on tarkoitettu kielen tunnistamiseen, toinen kyseisen kielen kääntämiseen halutulle kohdekielelle. Kolmas taas voi arvioida onko käännetty teksti sisällöltään koherentti (me kaikki tiedämme, miten kielimalli voi hairahtua sivupoluille).
Entä mitä tästä hyödymme? Voimme skaalata ja monistaa juuri niitä palveluita, joita tarvitsemme. Voimme esimerkiksi käynnistää 17 saksan kieltä prosessoivaa agenttia yhtä suomenkielistä kohti. Ja näin voimme keskittää resurssit sinne, missä niitä eniten tarvitaan. Aivan kuten mikropalveluarkkitehtuurin mukaisessa pilviympäristössä.
Skaalautuvuuden lisäksi parannamme järjestelmämme selkeyttä, kun rakennamme yksittäiselle agentille mahdollisimman kapean ja tarkasti määritellyn roolin. Tämän jaottelun ansiosta voimme myös helpommin keskittyä optimoimaan jonkin tietyn palvelun suorituskyvykkyyttä sotkematta muita rinnalla itsenäisesti toimivia prosesseja. Yksittäinen agentti kun on helpommin korvattavissa uudella ja tehokkaammalla toteutuksella.
Agenttien vuorovaikutuksesta
Tekoälyagenteista puhuttaessa nousee usein esiin ajatus siitä, miten eri agentit toimivat yhteistyössä – ja miten ne suorittavat niille osoitettuja tehtäviä itsenäisesti. Moniagenttiseen ratkaisuun liittyy kuitenkin väistämättä kysymyksiä agenttien vuorovaikutuksesta, kommunikaation toteutumisesta sekä itsenäisiin prosesseihin liittyvistä uhkakuvista.
Ajatus keskenään ristiin keskustelevista agenteista voikin tuntua melko kaoottiselta, ja epäilemättä koko toiminnan prosessi hämärtyy helposti, mikäli yhteistyötä ei aseteta järjestelmälliseen ympäristöön. Erään ratkaisun tähän ongelmaan tarjoaa aiemmassa kuvassa esiintynyt supervisor-agentti, jonka tehtävä muistuttaa hyvin läheisesti projektipäällikön työnkuvaa. Sen rooli moniagenttisessa järjestelmässä on lyhyesti:
- lukea käyttäjän tai muun järjestelmän antama tehtävänanto
- pilkkoa tehtävänanto konkreettisiksi työpaketeiksi
- reitittää tehtävät oikeille agenteille
- seurata töiden valmistumista
- koota palautteet ja lopputulokset
- tehdä tarvittaessa korjaavia päätöksiä.
Toisin sanoen, supervisor-agentti ei itse tee varsinaista työtä, vaan toimii orkesterin kapellimestarina.
Entäpä tietoturvan hallinta?
Yhden agentin järjestelmään verrattuna moniagenttinen järjestelmä tarjoaa toiminnan selkeyden ja hallittavuuden ohella myös arvokkaan mahdollisuuden tiukempaan tietoturvan hallintaan. Kuvitelkaamme toiminnallinen agentti, jolla on oikeudet tietokannan manipulointiin, pääsy useisiin API-päätepisteisiin ja tiedostojärjestelmään. Häiriötilanteessa kyseisellä agentilla on laaja kirjo oikeuksia, joilla voi saada aikaan mittaviakin vahinkoja.
Moniagenttisessa järjestelmässä voimme ajatella yksittäistä agenttia kuin mitä tahansa järjestelmää käyttävää entiteettiä, jolle määritellään halutut oikeudet. Jollakin agentilla saattaisi olla esimerkiksi rajattu lukuoikeus tietokantaan – ja toisella oikeus käyttää jotakin tarkasti rajattua API-päätepisteiden osajoukkoa. Tällaisen osittaisenkin zero trust -paradigman mukaisen arkkitehtuurin soveltaminen moniagenttiseen järjestelmään rajoittaa järjestelmän riskitekijöitä, tarjoaa selkeät kanavat toiminnan valvomiseen sekä selkeyttää yksittäisen agentin roolia kokonaisuudessa.
Agenttien vuorovaikutus teknisesti on oma ja laaja aiheensa itsessään, ja tämä aihe ansaitsisi jo ihan oman bloginsa. Tästä aiheessa kiinnostuneita suosittelen etsimään tietoa muun muassa hakusanoilla model context protocol tai agent-to-agent protocol. Näiden tekniikoiden takana on yllätyksetön tarve luoda standardimalleja agenttien väliseen kommunikoitiin.
Moniagenttinen ratkaisu: kyllä vai ei?
Kuvailin edellä usean agentin muodostaman järjestelmän tuomia hyötyjä, painottaen pitkälti positiivisia seikkoja. On kuitenkin mainittava, että mitä ilmeisimmin moniagenttinen arkkitehtuuri lisää omalta osaltaan ratkaisun kompleksisuutta ja toteutukseen tarvittavaa työpanosta.
Kuten monella muullakin elämänalueella, viisautta on tunnistaa milloin kannattaa kulkea sieltä, mistä aita on matalin. Yhtä lailla viisautta on tunnistaa myös ne tilanteet, jolloin ollaan toteuttamassa monimutkaista ratkaisua vain kiehtovan monimutkaisuuden tähden.
Mikäli olisin itse tutkimassa jonkin tekoälytehostetun ratkaisun soveltuvuutta tiettyyn ongelmaan, päätyisin luultavasti hahmottelemaan ajatusta nopean proof of conceptin kautta. Kun näkyviä tuloksia halutaan nopeasti, ei monimutkainen toteutustapa välttämättä ole oikea lähestymistapa. Tai jos ratkaistava ongelma on hyvin kapea, yhtä lailla lienee ajanhukkaa luoda toteutus moniagenttimallina. Avainsanat tässäkin tilanteessa ovat: ratkaisun tulee olla korkeintaan ongelman mittainen.
Kirjoittaja on näppäimistö savuten kehittävä ratkaisuarkkitehti Digialla. Siviilielämässään hän aikansa kuluksi käskee tietokoneitaan suorittamaan mahdottomia tehtäviä sekä paijaa kissojaan.