tl;dr: monet pahimmista ohjelmistokehittämisen fiaskoista ovat johtuneet siitä, että liiketoimintapäättäjät eivät ole ymmärtäneet, tai heille on annettu väärä kuva, uuden ratkaisun niin sanotun arkkitehtuurin eli syvien päätösten vaikutuksista lopputulokseen.
Jos olet tekemässä päätöstä itsellesi tai organisaatiollesi merkittävästä tekoälyhankkeesta, varmista, että siihen valittu arkkitehtuuri sopii vaatimuksiinne (ja budjettiinne). Lisäksi koesta arkkitehtuurin sopivuus ennen kuin on liian myöhäistä vaihtaa toteutustapaa. Erään tuntemani pörssiyrityksen tekoälyhanke myöhästyi lähes vuodella, kun arkkitehtuuri ei vastannut tarpeita.
Tekoälyn soveltamisen uusimman aallon, itsenäisesti pitkään toimivien ratkaisujen alalla, on kaksi päälinjaa: agentit ja työnkulut, joista molemmilla on hyvät ja huonot puolensa. Väärä valinta voi viedä rahat kankkulan kaivoon.
Mikä ihmeen agentti? Entä työnkulku?
Molemmat kilpailevat ratkaisut, työnkulut ja agentit, ovat niin sanottuja agenttimaisia järjestelmiä (agentic systems) ja näille on yhteistä se, että niillä voidaan toteuttaa laajoja tekoälysovelluksia, joiden alla oleva LLM-malli kätketään käyttäjältä.
Sekä työnkulut että agentit ovat kehittyneempiä ratkaisuja kuin yksinkertaiset kielimallien kutsut, sillä sekä agentti- että työnkulkuvaihtoehdoissa kielimalli yhdistetään ulkoisiin työkaluihin ja lopputulokseen päästään usein monen eri vaiheen kautta. Molemmissa ratkaisuissa työkalulle annetaan enemmän tilaa itsenäiseen päättelyyn kuin tyypillisessä kielimallin kutsussa.
Agentit ovat kuin itsenäisiä konsultteja, jotka ratkaisevat ongelmia omalla tavallaan, kun taas työnkulut ovat kuin sotilaallisesti määriteltyjä jonoja, joissa suunnitelmaa noudatetaan orjallisesti.
Yllä oleva kaavio (via Anthropic) kuvaa hyvin molempien mallien vahvuudet ja heikkoudet.
Työnkuluissa toteutetaan ohjelmistorobottien tavoin hyvin määriteltyjä työnkulkuja, mutta niin, että osa vaiheista teetetään tekoälyavusteisesti. Malli on ennustettava, eikä jätä tekoälylle liiemmälti liikkumavaraa.
Agentit taasen ovat toteutustapansa vuoksi hyvinkin itsenäisiä siinä, miten ne ratkovat niille annettuja pulmia, mutta tässä menetetään ennustettavuuden tuomat edut.
Mihin ohjelmistoarkkitehtuuria tarvitaan?
Hyvä ohjelmisto poikkeaa keskinkertaisesta tai huonosta tyypillisesti niin sanottujen laadullisten piirteiden ansiosta. Hyvä softa tekee pitkälti sen, minkä keskinkertainen, mutta sen olennaiset ominaisuudet, nopeus, skaalautuvuus, muokattavuus jne. ovat selvästi lähempänä ostajan tarpeita kuin huonon softan.
Joskus keskinkertaisen ja hyvän ero on toteutustiimin laadussa, mutta usein hyvän taustalla on keskinkertaista paremmin hankkeen alussa tehdyt ohjelmistoarkkitehtuurin valinnat, joiden ansiosta kehitystyö on tehokkaampaa ja tuloksekkaampaa.
Useimmissa hankkeissa suuri osa arkkitehtuurista lyödään lukkoon ihan hankkeen alkuvaiheessa. Päätetään teknologia, alusta ja tärkeimmät komponentit, ja tämän jälkeen rakennetaan se, mikä tuli suunniteltua. Ohjelmistoarkkitehtuuri tulee tällöin pahimmillaan valittua vahingossa, työkalujen ja kirjastojen valinnan sivutuloksena.
Huono ohjelmistoarkkitehtuurivalinta voi johtaa softalta odotetun kaupallisen buustin saamatta jäämiseen. Olen tavannut urani aikana monia statup-yrittäjiä, joille tilanne on ollut katastrofaalinen – joku on tehnyt heidän 1.0-vaihetta varten täysin väärät valinnat ja juuri kun pitäisi aloittaa myynti, käy ilmi, että viimeisiä ominaisuuksia ei yksinkertaisesti saada rakennettua valitulle alustalle.
Kallein esimerkki urallani on vuosien takaa, valtionyrityksestä, jonka 5M€:n järjestelmä oli sen arkkitehtuurin fataalin laadullisen puutteen vuoksi pakko romuttaa ja aloittaa kehittäminen uudestaan. Ei ollut helppoa tulla tuohon palaveriin tuotoksen tarkastaneen tiimin puhemiehenä, kun tiesi, miten paljon softaa oli odotettu!
Arkkitehtuuri ja raha
Arkkitehtuurivalinnat ovat mitä suurimmassa määrin taloudellisia kysymyksiä. Alustoja myyvät yritykset, kuten OpenAI, Google ja Microsoft pyrkivät aktiivisesti saavuttamaan arkkitehtuurin monopolin tai ainakin suosituimman kaupallisen toteuttajan aseman, sillä markkinaykkönen kerää markkinalta suuren, tai jopa suurimman, osan voitoista.
Arkkitehtuureista on tosi vaikea löytää puolueetonta tietoa. Ne, jotka arkkitehtuurin ja siihen liittyvät kirjastot tuntevat parhaiten, ovat samalla niitä, jotka toivovat saavansa tästä osaamiseen panostamisesta kauppaa aikaiseksi.
Agentit
OpenAI on selvästi agenttileirissä. Yrityksessä uskotaan siihen, että mallit kykenevät kohta suorittamaan vaikeatkin tehtävät ilman, että niiden tueksi koodataan työnkulkuja.
Lähestymistapa on houkutteleva, sillä LLM-mallit kykenevät yllättäviin suorituksiin, kuten korjaamaan pieniä virheitä lähtötiedoissa tai käyttämään näille annettuja työkaluja tavoilla, jotka eivät heti olisi tulleet mieleen. Lisäksi LLM-mallit kehittyvät valtavaa vauhtia. Kehitys on kerta toisensa jälkeen yllättänyt jopa mallien kehittäjät.
Agentti-arkkitehtuurin kanssa rajat vaan tulevat helposti vastaan – helpot tapaukset onnistuvat vaivatta, loput ovat lähes mahdottomia.
Alla oleva kaavio kuvaa hyvin mallien toimintaa. Softan kirjoittajan näkökulmasta työ on aika yksinkertaista: käynnistetään malli oikealla promptilla ja annetaan sen pyöriä, kunnes malli tuottaa vastauksen.
Agentit ovat vahvimmillaan tehtävissä, joissa käyttäjät hyväksyvät epävarmuuden ja jopa jonkin määrän vääriä vastauksia, esimerkiksi siksi, että vastaavaa sovellusta ei ennen ole voinut edes kuvitella. Hyviä esimerkkejä näistä ovat koodia kirjoittavat agentit tai OpenAI:n Deep Research -agentti, joka kirjoittaa OpenAI:n maksaville käyttäjille ihan mukiinmeneviä raportteja vapaavalintaisista teemoista.
Tietoturvahyökkäykset ovat agentti-tyyppisten ratkaisujen ehkä pahin akilleen kantapää. Käyttötapauksissa, joissa käyttäjä käsittelee vain omia tietojaan, riskit ovat helposti hallittavissa, mutta mitä vapaammin agentin annetaan käsitellä esim Internetistä haettua tietoa sitä suuremmat riskit sen käyttö muodostaa.
Arvostetun OWASP-projektin LLM-mallien top-10 tietoturvariskeistä useimmat ovat piinallisen ilmeisiä ja vaikeasti korjattavia nykyisillä agenttiratkaisuilla, jos nämä päästetään toimimaan sellaisen tiedon kanssa, johon hyökkääjä on voinut päästä käsiksi.
Työnkulut
Agenttimallin vaihtoehtona voi nähdä niin sanotun työnkulku eli Workflow-lähestymistavan. Malli perustuu koodiin, joka kriittisissä kohdissa teettää LLM-mallilla vain juuri sen, mitä tarvitaan ja useimmiten tällöin vain sellaisia osia, joihin ilman tekoälyä ei kyettäisi.
Kaaviokuva alla esittelee lähestymistavan, jossa tehtävä, eli työnkulku, on paloiteltu osiin, jotka yksi kerrallaan saatetaan teettää LLM-mallilla, mutta jossa kontrolli pysyy huomattavasti selvemmin työnkulun koodanneella.
Kyse on selvästi enemmän käsityöstä, jossa on valittu ennustettava ja vähemmän luova tapa, sen sijaan että koko pulma jätettäisiin tekoälymallin pureksittavaksi. Hyvin tehty työnkulku ei yllätä positiivisesti eikä negatiivisesti.
Käsityöllä on vahvuutensa, sillä voi:
Saada aikaiseksi sovelluksen, jota ei vielä voisi agentilla tehdä
Pitää käyttökulut helpommin kurissa – kullekin kutsulle voi valita halvimman mallin, joka selviää tehtävästä
Luoda ratkaisu, joka on selvästi paremmin testattu ja joka tuottaa ennustettavampia lopputuloksia
Luoda ratkaisuja, joissa jokainen vastaus siivotaan ennen sen jatkokäyttöä ja näin vähentää tietoturvariskejä
Toteuttaa ratkaisun, joka kykenee vastaamaan nopeammin kuin polveileva LLM-malli.
Toisaalta taas:
Koodaukseen menee helposti huomattavasti enemmän aikaa kuin agentteja käytettäessä
Lähestymistavassa kehittäjien pitää opetella enemmän, sillä työnkuluissa on osattava sekä mallien ohjaus että näiden kutsujen letittäminen kokonaisuudeksi
Toteutus on enemmän sidoksissa tiedon ja tehtävän tarkkaan rakenteeseen. Jomman kumman muuttuessa työnkulkuja on paljon todennäköisemmin korjattava.
Miten käy, jos agenttiratkaisut kehittyvät nopeasti, eikä työnkulkuja enää tarvitse koodaamalla määritellä?
Minkä valitsisin?
Hyvä nyrkkisääntö on valita suoraviivaisin toteutus tässä vaiheessa. Ala kehittyy nopeasti ja mitä suoraviivaisemmalla toteutuksella haluttu lopputulos on saatu aikaiseksi, sitä nopeammin se tulee koodattua ja sitä halvempaa sitä on ylläpitää. Toteutus sisältää toki sekä koodauksen että testauksen. Kaikkein suoraviivaisimmat agenttitoteutukset voivat joskus olla todella vaikeita testata.
Suoraviivaista toteutusta miettiessä pitää pohtia sovelluksen todellisia vaatimuksia ja käydä läpi kaikki neljä vaihtoehtoa:
Moni sovellus ei tarvitse agentteja eikä työnkulkukehikoita. Muutama oikein sijoitettu LLM-kutsu tuottaa sen, mitä haettiin ilman kummankaan lähestymistavan tuomaa kompleksisuutta.
Agentit ovat nopeimpia toteuttaa mutta niiden turvallisuudesta on vaikea tehdä kovin suuria lupauksia eikä niiden testaus ole helppoa. Agentit soveltuvat siksi tosi hyvin protojen tekoon ja tilanteisiin, joissa niillä käsitellään vain käyttäjän omia tiedostoja ilman Internet-käytön tuottamia vaaranpaikkoja.
Kun ennustettavuus on tärkeää niin suorituksen kuin siihen liittyvän kustannuksen, tietoturvan, suorituskyvyn jne. suhteen ja toteutus on muutamaa API-kutsua monimutkaisempi, kannattaa käyttöön ottaa sopiva työnkulku-kehikko (engl. framework.) Olen linkittänyt yhden tällaisia tekevän projektin tekemän vertailun loppuun vertailun puolueellisuudesta huolimatta.
Isommassa sovelluksissa voi olla paikkansa kaikille hybridimallille. Oikea työkalu oikeassa paikassa on selkeämpää kuin se, että agentilla yritetään väkisin tehdä työnkulkua tai päinvastoin.
Onko kustannuksissa eroa?
Tekoälymallien kustannusten vertailu on pirullisen tapauskohtaista. Laskin auki tutun casen, noin tuhannen yrityksen ja viiden tuhannen ostajan ostosignaalien kuukausittaisen tunnistamisen toteutuksen. Softassa haetaan vähän verkkosivuja ja tehdään päätelmiä siitä, miten yrityksillä menee ja miten näitä kannattaisi lähestyä.
Vuoden 2025 toukokuussa julkistetuilla malleilla tuloksia saadaan noin 500€ kuukausikustannuksella työnkulkumaailmassa ja alle 1000€ kuukausikustannuksella agentti-toteutuksessa.
Työnkulun kustannukset pysyvät vakiona ja riippuvat lähinnä webbisivujen pituudesta, agenttien kustannukset sen sijaan voivat pompsahtaa selvästi, jos nämä keksivät pyytää syystä tai toisesta suuremman määrän syöttötietoa kuin yleensä. Halvemmalla pääsee, jos käyttää vanhempaa mallia ja projektiin saa kulumaan 10x rahaa, jos haluaa käyttää markkinoiden parhaita malleja ja antaa näille paljon ajoaikaa.
Caveat emptor
Roomalaisten “caveat emptor” eli ostaja olkoon varuillaan, muistutti tuhansia vuosia vanhassa lainsäädännössä siitä, että ostaja on aina loppujen lopuksi vastuussa valinnastaan.
Useimmiten turvallisinta on valita joustavaa päätöksentekoa ja luovaa ongelmanratkaisua vaativiin osiin agenttitoteutuksia ja toisaalta tiukan ennustettaviin osiin työnkulkuja. Toteutuksen pakottaminen arkkitehtuuriin, joka ei sille sovi on harvoin oikea vaihtoehto.
Linkit
Anthropic-yhtiön suositukset agenttien ja työnkulkujen ympäriltä https://www.anthropic.com/engineering/building-effective-agents?ref=blog.langchain.dev
OpenAI:n agenttisuositukset https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf?ref=blog.langchain.dev
LangChain työnkulkukehikon (framework) tiimin pohdintaa agenttien ja työnkulun suhteesta https://blog.langchain.dev/how-to-think-about-agent-frameworks/
LLM-mallien tietoturva-suojakaiteista (guardrails) https://www.mckinsey.com/featured-insights/mckinsey-explainers/what-are-ai-guardrails
Suojakaiteiden kiertämisen tutkimus https://arxiv.org/abs/2504.11168
LangChain-yhtiön tekemä workflow- ja agenttikehikoiden (framework) vertailu https://docs.google.com/spreadsheets/d/1B37VxTBuGLeTSPVWtz7UMsCdtXrqV5hCjWkbHN8tfAo/edit?gid=0#gid=0
OWASP-projektin 10 tärkeintä LLM-malleihin liittyvää tietoturvariskiä-sivusto https://genai.owasp.org/llm-top-10/
