Kaksi organisaatiota, sama lisenssi, sama kielimalli. Kummankin organisaation AI-agentille on annettu sama tehtävä: laatia asiakkaalle tarjous. Toisessa tekoäly laatii lähes lähetyskelpoisen tarjouksen. Toisessa lopputulos on yleispätevä luonnos, jolla ei oikeassa elämässä tee mitään ja jonka joutuu kirjoittamaan uusiksi. Mistä ero johtuu?
Tässä kirjoituksessa avaan, mikä erottaa toimivan tekoälyn siitä, joka ei lunasta lupauksia.
Käyn läpi, mitä harness engineering on ja miksi organisaatioiden kannattaisi panostaa nimenomaan siihen. Se ratkaisee pitkälti sen, mitä hyötyä tekoälystä saadaan.
Kun olet lukenut kirjoituksen, ymmärrät, mistä harness engineeringissä on kyse ja mitä voitte tehdä mahdollisimman hyvien agenttien rakentamiseksi.
Tämä on jatkoa aiemmille kirjoituksilleni: Miten chat-pohjainen tekoälysovellus ja kielimallit toimivat(opens in new tab) ja Mitä AI-agenteista kannattaa ymmärtää(opens in new tab).
Aloitetaan siitä, mikä harness engineering oikein on.
Mikä harness engineering on?
Englanninkielinen sana harness tarkoittaa valjaita, ja AI-kontekstissa sillä viitataan tekoälymallin ohjastamiseen. Harness on kaikki se, mikä tekoälymallin ympärille on rakennettu. Se ratkaisee, mitä tekoälymalli tietää meistä ja asiakkaistamme, mihin tietoihin AI pääsee käsiksi ja mitä agentit saavat tehdä.
AI:n tapauksessa harness koostuu esimerkiksi seuraavista osa-alueista:
- Konteksti: Mitä agentti tietää organisaatiosta, asiakkaista ja aiemmin tehdystä
- Skillit ja ohjaus: Ohjeet siitä, miten agentin pitää toimia eri tilanteissa ja missä järjestyksessä edetä
- Työkalut: Miten agentti pääsee käsiksi ympäröivään maailmaan
- Raja-aidat: Mitä agentti saa tehdä, mitä ei, ja milloin ihminen päättää
- Verifiointi: Miten todennetaan, että lopputulos on oikea — ja mitä tehdään, kun se ei ole
Käsittelen näitä tarkemmin tässä kirjoituksessa.
Harnessia voi verrata autoon, jonka moottorina toimii kielimalli, esimerkiksi OpenAI:n GPT-malli tai Anthropicin Opus. Kuten autoissa, sama moottori voi palvella monia erilaisia autoja, jotka ovat luonteeltaan erilaisia sen mukaan, mitä tarkoitusta varten auto on rakennettu.
"Harnessia voi verrata autoon, joka on rakennettu moottorina toimivan kielimallin ympärille."
Vaikka moottori antaa autolle tehon, jota se tarvitsee liikkuakseen, pelkkä moottori ei pysty liikkumaan mihinkään. Tarvitaan alusta, johon moottori kiinnitetään, pyörät, ohjauslaitteet, matkustamo kaikkine hallintalaitteineen. Vasta sitten autoa voi käyttää liikkumiseen.
Samalla tavalla harness tuo kielimallin ympärille kaikki ne komponentit, joita tarvitaan toimivan AI-agentin rakentamiseksi.
Tässä mielessä agentti(opens in new tab) muodostuu siis kielimallista ja sen ympärille rakennetusta harnessista.
Palataan hetkeksi kirjoituksen alun esimerkkiin. Jos agentti tuottaa huonoja lopputuloksia, moni organisaatio tekee helposti väärän johtopäätöksen: tekoäly ei ole vielä valmis. Sitten odotetaan seuraavaa mallisukupolvea, ja sama toistuu.
Johto haluaa tietysti välttää tämän. Jotta se on mahdollista, pitää ymmärtää, miten harness engineering auttaa tässä.
Mitä hyötyä harness engineeringistä on?
Harness engineering on juuri se osa agenttiratkaisua, johon voi itse vaikuttaa. Kun tulee uusi tekoälymalli, kaikkien tulokset paranevat yhtä paljon. Kun taas parannetaan harnessia eli kielimallin ympärille rakennettavaa koneistoa, se parantaa vain sen organisaation tuloksia. Harnessin rakentaminen kielimallin ympärille on siis tapa luoda kilpailuetua organisaatiolle.
Harnessin rakentaminen kielimallin ympärille on tapa luoda kilpailuetua organisaatiolle.
Autojen moottorien väliset erot ovat kaventuneet. Samoin kielimallien väliset erot ovat kaventumassa. Monivaiheisissa tehtävissä harness eli kaikki agentin toimintaa tukeva koneisto selittää yhä suuremman osan agenttien aikaansaamasta lopputuloksesta.
Yksittäisissä tehtävissä harness engineeringin avulla saavutetaan seuraavia hyötyjä:
- Luotettavuus: Sama tehtävä tuottaa saman laatuisen tuloksen kerta toisensa jälkeen.
- Oppiminen: Kerran korjattu virhe ei toistu, koska korjaus rakennetaan pysyvästi harnessiin eikä yksittäiseen promptiin.
- Auditoitavuus: Jälkikäteen voidaan nähdä, mitä tehtiin ja miksi. Tämä on edellytys sille, että agentin annetaan koskea mihinkään oikeasti tärkeään.
- Riippumattomuus mallista: Vaikka mallit vaihtuvat, harness on pysyvä osa kokonaisuutta.
- Erottautuminen: Organisaation osaaminen on rakennettu harnessiin.
Harness engineering on ratkaisu siihen ongelmaan, että tekoälyagentti toimii huonosti ja antaa geneerisiä tuloksia, joita ei voi oikeasti käyttää. Jos haluat, että teidän organisaatiossa ei tuoteta tekoälyllä aineistoa, jonka korjaamiseen muut joutuvat käyttämään aikaa, kannattaa panostaa agentteihin, joiden harness on rakennettu mahdollisimman hyvin.
Pidemmällä aikavälillä harnessin rakentaminen tuo organisaatioille merkittäviä hyötyjä, koska tekoälymallit vaihtuvat, mutta sen ympärille rakennettu kokonaisuus pysyy ja paranee ajan kuluessa, jos kehitystyötä tehdään jatkuvasti.
Harnessin avulla agentit voivat oppia toimimaan oikeiden liiketoimintaprosessien osana tai jopa hoitamaan kokonaisia prosesseja itsenäisesti.
Harnessin avulla agentit voivat oppia toimimaan oikeiden liiketoimintaprosessien osana tai jopa hoitamaan kokonaisia prosesseja itsenäisesti.
Organisaatiot, jotka pystyvät rakentamaan organisaatiotason harnessia, voivat saavuttaa merkittäviä tuottavuushyötyjä verrattuna niihin, jotka käyttävät tekoälyä vain chattina tai perustason agenttina avustamassa vaikka Excelin tai PowerPointin käytössä.
Vaikka kaikki kehittyvät harnessin rakentamisessa ajan myötä, organisaatioon syntyvä kyvykkyys rakentaa toimivia agentteja on vahvuus, joka kantaa hedelmää pitkässä juoksussa.
Tekoälyagentti on kuin uusi työntekijä ensimmäisenä työpäivänä
Tekoälyä voi verrata uuteen työntekijään ensimmäisenä työpäivänä. Työntekijällä voi olla paljonkin tietoa omasta ammatistaan, mutta ei ollenkaan tietoa siitä, miten juuri tässä organisaatiossa toimitaan.
Samalla tavalla tekoälyllä voi olla hyvin laajat tiedot eri aloilta, mutta se ei tiedä meistä tai organisaatiomme tavoista toimia yhtään mitään.
Jotta uusi työntekijä saatetaan kartalle, työt aloitetaan perehdyttämisellä. Ihmiselle kerrotaan organisaatiosta, prosesseista, siitä miten asiat on meillä tehty. Uusi työntekijä tapaa paljon ihmisiä organisaatiosta ja pääsee keskustelemaan heidän kanssaan. Tietoa tulee niin paljon, että kaikkea ei sisäistä ensimmäisellä kerralla, mutta vähitellen työntekijä pääsee sisään organisaation toimintatapoihin ja oppii toimimaan odotetulla tavalla. Nyt hän voi hyödyntää ammatillista osaamistaan organisaation kontekstissa.
Tekoäly ei eroa tästä mitenkään. Se on vielä enemmän pihalla odotetuista toimintatavoista kuin ihminen. Siksi tekoäly pitää tutustuttaa organisaatioon ja sen tapoihin toimia ihan samalla tavalla kuin ihminen pitää perehdyttää.
Vaikka käytetyllä tekoälymallilla on edelleen merkitystä, sen merkitys vähenee, kun saataville tulee yhä enemmän riittävän hyviä malleja. Siksi AI-mallin valinta ei enää ole organisaation tärkein valinta. Huomio kannattaa kääntää mallin ohjaamiseen hyvän harnessin avulla.
Miten agenttia sitten perehdytetään juuri teidän organisaation toimintaan?
Ohjeista agentteja toimimaan oikein
Kun lähdetään miettimään, miten agenteille kerrotaan, miten niiden pitää toimia, on hyvä muistaa yksi asia: agentilla ei ole itsessään älyä. Agentti käyttää kielimallia kaikkeen päättelyyn.
Kielimalli näkee vain sen, mikä on sille lähetetyn promptin mukana. Se ei tiedä meistä mitään. Se ei tiedä prosessejamme, asiakkaitamme eikä sopimusmallejamme eikä sitä, miten meillä on tapana tehdä asiat.
Jos mallille ei kerro näitä asioita, se arvaa. Arvaus koristellaan kauniiksi, ja se voi näyttää vakuuttavalta. Joskus arvaus osuu, mutta useimmiten se ei ihan osu. Miten voidaan estää mallia arvaamasta?
Kielimallille voi tarjota ohjeita kolmella tavalla:
- Ohjetiedosto. Ohjetiedosto on pysyvä ohje, joka kulkee kielimallille mukana joka kerta, kun sille annetaan prompti. Ohjetiedosto voi kertoa, kuka käyttäjä on, mitä organisaatiossa tehdään, mitä ei saa tehdä, millainen lopputuloksen pitäisi olla.
- Ulkoinen tietolähde. Näitä voivat olla kansiot, dokumenttiarkistot, tietokannat, SharePoint, Confluence tai muu paikka, missä pidetään dokumentteja. Näin niitä ei tarvitse liittää promptiin joka kerta.
- Muisti. Agenteilla on muisti, josta voi löytyä aiemmin annettuja ohjeita.
Nyt on hyvä muistaa, että kaikkien mahdollisten ohjeiden kaataminen agentin niskaan ei automaattisesti tee agenteista parempia. Tähän liittyy kaksi ongelmaa:
- Kun mallin konteksti-ikkuna alkaa täyttyä, sen kyky prosessoida tietoa laadukkaasti laskee. Tämä laadun aleneminen alkaa jo paljon aiemmin kuin konteksti-ikkuna on täynnä.
- Jos konteksti-ikkunassa olevat ohjeet sisältävät tehtävän kannalta väärää tietoa, malli ei arvaa, vaan tottelee vääriä ohjeita.
Mallin kyky hahmottaa ohjeita on hyvin samanlainen kuin meillä ihmisillä. Me muistamme usein ne asiat, jotka meille on sanottu aluksi ja lopuksi. Osa siitä, mikä tulee sillä välillä, tuppaa unohtumaan.(opens in new tab) Sama pätee agentteihin. Siksi ei kannata antaa liikaa ohjeita kerralla.
Miten onnistua agentin ohjeistamisessa käytännössä
Käytännön tasolla kannattaa ottaa huomioon seuraavia asioita:
- Jos agentti on tehty yhtä tehtävää tai prosessin osaa varten, kerro sille vain siitä tehtävästä tai prosessista, älä koko organisaation prosesseista. Näin agentti saa vain sen tiedon, mitä se tarvitsee.
- Kysy itseltäsi, mitä kokeneet työntekijät tietävät. Mitä siitä tiedosta on kirjoitettu ylös johonkin? Jos sattuisi, että tästä löytyisi hyvää dokumentaatiota, pääset tässä helpolla.
- Usein hyviä ohjeita ei löydy, minkä vuoksi agentille joudutaan näyttämään hyviä lopputuloksia ja sitä pitää alkaa opettamaan. Tässä on se ongelma, että agentti ei välttämättä hoksaa, mitkä asiat oikeasti tekevät vaikkapa tarjouksesta hyvän. Kielimallit kiinnittävät usein huomiota yksityiskohtiin samalla kun kokonaisuus on hukassa.
- Järjestä työpaja, jossa kokeneet asiantuntijat kertovat, millaisia pieniä valintoja he tekevät, kun rakentavat lopputuotosta. Mitä paremmin niitä saa dokumentoitua, sitä paremmin agentti osaa ottaa ne asiat huomioon.
Agentin ohjeistamiseksi kannattaa nähdä vaivaa. Siitä on hyötyä agentin ohjaamisessa, mutta myös uusien ihmisten perehdyttämisessä.
Mutta mihin nämä ohjeet pitäisi oikein syöttää? Katsotaan seuraavaksi, mihin ne käytännössä kirjoitetaan.
Pysyvät ohjeet ja skillit sisältävät agentille annettavat ohjeet
Ohjeet voi jakaa kahteen kategoriaan: niihin, jotka annetaan agentille aina jokaisen promptin yhteydessä, ja niihin, jotka annetaan sille tarvittaessa.
Pysyvät ohjeet on tallennettu tiedostoon, joka sisältää tärkeitä tietoja organisaatiosta, mitä agentti saa tehdä ja mitä ei, jne. Lisäksi agentille kerrotaan, millaisia tehtäväkohtaisia ohjeita eli skillejä sillä on käytössään.
Skill on paketoitu työohje, jota voi ajatella reseptinä, jonka agentti ottaa esiin vasta kun sitä tarvitaan. Se sisältää ohjeen siitä, miten jokin nimenomainen työ tehdään, tarvittavat mallipohjat ja aineistot, ja tarvittaessa valmiiksi kirjoitetun automatiikan jonkin tehtävän suorittamiseksi.
Käytännön tasolla skill sisältää tekstitiedoston, jota koneen on helppo lukea. Se on yleensä Markdown-tiedosto eli tiedosto, jonka tiedostopääte on .md. Markdown on tekstitiedosto, johon voi pelkän tekstin lisäksi luoda rakennetta.
Markdown-tiedostoon voi merkitä otsikoita laittamalla tekstin eteen #-merkkejä, luetteloita laittamalla tekstin eteen tähden ja lihavointeja laittamalla lihavoitava osuus kahden tähden väliin.
Markdown-tiedoston etu on siinä, että se on tehokas tapa tarjota tietoa koneelle, mutta myös ihminen pystyy lukemaan sitä.
Mikseivät Wordit ja PowerPointit riitä
Jos organisaatiossa on ohjeita, ne on yleensä tuotettu Wordilla, PowerPointilla tai vastaavalla. Ensimmäiseksi tulisi mieleen, että annetaan ne agentille, niin se tietää, mitä tehdä.
Skill on teknisesti kansio, jossa kyllä voi olla malleja Word- sekä Excel- että PowerPoint-tiedostoina. Kuitenkin varsinainen skill pitää antaa tekstitiedostona, jossa sitten viitataan näihin malleihin.
Näitä ei voi antaa agentille sellaisenaan. Kielimalli ei osaa lukea toimistosovellusten formaatteja suoraan, koska nämä tiedostot sisältävät paljon muutakin tietoa kuin pelkän meille näkyvän sisällön. Kielimallin pitää yleensä kirjoittaa koodia, jonka agentti ajaa ja näin tiedoston sisältö voidaan lukea. Tämä tekee tietojen antamisesta agentille hyvin tehotonta suhteessa kulutettuihin tokeneihin.
Toinen toimistosovellusten tiedostojen ongelma liittyy niiden sisältöön. Ne eivät useinkaan sisällä koneen odottamia täsmällisiä toimintaohjeita, vaan saattavat olla enemmän kuvailevia. Word-tiedostossa on paljon ulkoasuun liittyvää tietoa ja PowerPoint sisältää diat muttei sitä varsinaista selostusta, joka pidettyyn esitykseen sisältyy.
Jokaisen promptin yhteydessä agentti lähettää kielimallille siis yleisen ohjetiedoston (Claude Code käyttää CLAUDE.md-tiedostoa, monet muut työkalut AGENTS.md-tiedostoa). Sen yhteydessä kielimallille lähetetään lista käytettävissä olevien skillien nimistä ja kuvauksista. Näiden perusteella kielimalli osaa tarvittaessa kutsua tarvittavaa skilliä.
Koska skilliä kutsutaan vasta tarvittaessa, ei se kuluta kallisarvoista konteksti-ikkunaa eikä hämää poloista kielimallia, joka yrittää ymmärtää kaiken sille syötetyn.
Mistä asioista sitten voisi tehdä oman skillin? Mitä sanoisit näistä:
- Myynti: Näin meillä rakennetaan tarjous tuotteesta X.
- Hankinta: Näin meillä tehdään hinnoittelutaulukko tarjouspyyntöä varten
- Talous: Näin meillä rakennetaan kommentit tulosraporttiin
- HR: Näin meillä laaditaan työpaikkailmoitus
Hyvän skillin rakentaminen voi vaatia paljon työtä. Se voi vaatia projektin, jota johdetaan kuin oikeaa projektia. Hyvää skilliä voidaan hyödyntää, vaikka tekoälymalli vaihtuu. Se voi ratkaista, osaako agentti toimia oikein.
Hyvän skillin rakentaminen voi vaatia projektin, jota johdetaan kuin oikeaa projektia.
Kannattaa rakentaa mieluummin vähemmän, mutta laadukkaita skillejä. Älä siis mittaa skillien määrää vaan ennemminkin niiden avulla tehdyn työn laatua ja tehokkuutta.
Miten päästä liikkeelle:
- Valitse 3–5 toistuvaa työnkulkua, joissa laatu vaihtelee tekijän mukaan ja joissa agentti voisi auttaa. Lähde rakentamaan niille skillejä.
- Nimeä jokaiselle skillille omistaja.
- Projektoi skillien laatiminen ja johda niitä kuin miniprojekteja.
Agentti ei kuitenkaan osaa tehdä asioita ilman, että sille annetaan työkalut. Siksi harness engineering määrittelee myös agentin käyttämät työkalut.
Harness määrittelee työkalut, joita agentilla on käytössään
Kielimalli ei itsessään osaa tehdä mitään muuta kuin kääntää sille syötettyä sisältöä tokeneiksi, prosessoida niitä ja kääntää tokeneita halutuksi sisällöksi. Kaikkeen muuhun tarvitaan työkaluja. Käytännössä agentti käyttää työkaluja, mutta ymmärtämättä itse niistä yhtään mitään, koska se toimii täysin kielimallin antamien ohjeiden varassa.
Kun organisaatio rakentaa agentteja, sen pitää ottaa kantaa siihen, mitä työkaluja agentilla on käytössään. Mitä työkalut oikeastaan ovat?
Työkalut voi jakaa neljään ryhmään:
- Tiedostojärjestelmän käyttäminen. Agentille ei tarvitse antaa kaikkia tiedostoja syötteessä, koska agentit voivat päästä kiinni koneen tiedostojärjestelmään. Skillien ja ohjetiedostojen käyttö vaatiikin tiedostojärjestelmäpääsyä.
- Agentti voi käyttää oikeaa selainta verkkohakuja tehdessään. Tämä tarkoittaa, että agentti näkee kaiken kuten ihminen näkisi: lomakkeet, painikkeet, tekstilaatikot ja muut komponentit näkyvät kuten ihmiselle. Agentti voi tämän ansiosta täyttää lomakkeita ja hoitaa asioita ihmisen puolesta.
- Agentti voi ajaa koodia. Kielimallit kirjoittavat monien tehtävien suorittamiseksi koodia, jonka agentti sitten ajaa.
- Agentti voi käyttää muita järjestelmiä API-rajapintojen kautta. Agentille voi antaa pääsyn mitä moninaisimpiin järjestelmiin antamalla sille API-avaimia järjestelmiin. Näin se voi hoitaa asioita ihmisen puolesta.
Olen kirjoittanut työkalujen käytöstä tarkemmin kirjoituksessa Mitä AI-agenteista kannattaa ymmärtää(opens in new tab).
API-rajapintojen lisäksi agenteilla on käytössään myös toisenlainen pääsy eri järjestelmiin, nimittäin MCP-serveri.
Mikä on MCP-serveri
MCP-serveri on sovitin, joka mahdollistaa kielimallin ja halutun järjestelmän kommunikoinnin tavalla, joka on helppo kielimallille. MCP-serveri on tapa tarjota agentille pääsy johonkin järjestelmään tietojen lukemista tai muuttamista varten.
Teknisesti MCP-serveri voi olla joko paikallisesti ajettava lyhyt koodi tai oikea palvelin.
Useat agentit voivat jakaa yhden MCP-serverin ja käyttää sitä kohdejärjestelmän kanssa keskustelemiseen. Tämä pienentää tarvittavien integraatioiden määrää. Tästä on etua lähinnä ympäristöissä, joissa on tai tulee olemaan useita agentteja.
MCP-serverin käyttämisestä voi olla yritysympäristössä etuja, koska sen avulla voidaan mm. rajata agentille mahdollisia operaatioita ja parantaa siten tietoturvaa.
Kaikki ovat kuulleet tarinoita agenteista, jotka tekevät jotain typerää tai jopa laitonta. Miten sellaisen voi estää? Vastaus liittyy guardraileihin.
Guardrailit estävät agenttia tekemästä mitään luvatonta
Guardrail on rajoite, joka estää agenttia tekemästä vahinkoa — riippumatta siitä, mitä agentti aikoi tehdä. Suomeksi se tarkoittaa suojakaidetta.
Guardrailit ovat kuin moottoritien suojakaiteita, jotka estävät ajautumasta vastaantulijoiden kaistalle. Kaide itsessään ei ohjaa autoa eikä tee kuljettajasta parempaa. Se vain rajaa, kuinka pahasti kuski voi mokata. Sama pätee agenttiin. Se vain rajaa mahdollisia seurauksia.
Siinä missä skill on ohje eli ennemminkin pyyntö agentille, guardrail on este. Jos kirjoittaa skilliin "älä koskaan poista tiedostoja", se on toive. Varsinainen guardrail on se, kun agentilla ei edes ole tiedostojen poisto-oikeutta.
Tässä on muutama guardrail, joita agenttien yhteydessä voi käyttää:
- Hook. Hook on koodi, joka ajetaan määritellyssä kohdassa ja joka voi keskeyttää agentin touhut. Esimerkiksi itse käytän hookia estämään agenttia kirjoittamasta mihinkään muualle kuin sen omaan kansioon. Tämä hook ajetaan aina, kun kielimalli edes suunnittelee kirjoittavansa jotain koneelle. Näin estän muutokset, joita agentti voisi muuten tehdä vahingossa.
- Budjettiraja. Budjettiraja voi rajoittaa agentin loopien määrää, kulutettavia tokeneita tai aikaa. Tämäkin pysäyttää agentin touhut, kun raja täyttyy. Tällä voi estää esimerkiksi kulujen karkaamisen.
- Ihmisen hyväksyntä. Agentti voidaan pakottaa pyytämään kuittaus ihmiseltä. Tämä on hyvä keino oikein käytettynä, mutta voi toisaalta viedä agentilta tehot.
- Käyttöoikeudet. Erittäin hyvä työkalu on antaa agentille oma identiteetti ja antaa sille vain sellaisia oikeuksia, joilla ei saa mitään pahaa aikaiseksi. Tämä ei tosin onnistu omalla koneella ajettavien agenttien kanssa, vaan sopii enemmän yritysympäristöön.
- Työkalujen puuttuminen. Jos agentilla ei ole työkalua tehdä jotain, ei se pysty silloin käyttämään kyseistä työkalua. Jos agentilla ei esimerkiksi ole pääsyä järjestelmään, koska sillä ei ole API-avainta sinne, ei se myöskään voi tehdä mitään.
Guardraileihin pätee periaate, että jos kielimalli ei edes tiedä raja-aidan olemassaolosta, esimerkiksi, että sillä ei ole oikeuksia tai työkalua käytössään, se ei voi mitenkään kiertää sitä. Jos taas raja-aidan totteleminen riippuu kielimallista, on aina olemassa ainakin pieni riski, että se toimii ohjeen vastaisesti.
Guardrailit eivät tee agentin tuottamasta lopputuloksesta parempaa. Ne vain estävät vahinkoja. Lopputuloksista saa parempia, kun arvioi lopputuloksen oikeellisuutta. Siihen tarvitaan evaleita.
Evalit huolehtivat lopputulosten arvioimisesta
Kun kielimalli tuottaa lopputuloksen, se arvioi itse, vastaako lopputulos haluttua. Kun agentille antaa tehtävän, se välittää sen kielimallille ja kielimalli tuottaa tuotoksen, jonka se siis itse arvioi. Miten siis varmistutaan siitä, että lopputulos on riittävän hyvä? Vastaus liittyy taas harnessiin.
Arvioimiseen käytetään arviointikriteereitä, joista käytetään termiä eval. Eval on yksittäinen testitapaus, jolla mitataan, miten agentti suoriutuu tietystä tehtävästä. Evalien avulla voi päätellä, toimiiko rakennettu harness halutusti.
Jos agentille tehtävää annettaessa ei itse määrittele testitapauksia, kielimalli arvioi tuloksia omilla kriteereillään. Arvioinnin tulos voi joskus olla hyvä ja joskus kelvoton.
Koska kielimallin ei kannata antaa arvioida itse, milloin tulos on hyvä, agentin tekijän pitää antaa sille arvioimista varten kriteeristö. Tähän tarvitaan evaleita.
Jokainen eval sisältää tehtävän, lähtötilanteen ja arviointikriteerit, joilla suoritus pisteytetään. Eval ei ole sama asia kuin perinteinen ohjelmistotesti, koska perinteinen testi joko menee läpi tai ei mene. Joka kerta kun ohjelma ajetaan, tulos on sama. Perinteiset ohjelmistot ovat siis deterministisiä. Agentit toimivat eri tavalla.
Kielimallin avulla tuotetut tulokset ovat joka kerta hieman erilaisia. Siksi tuloksia ei voi luokitella yksiselitteisesti oikeaksi tai vääräksi, vaan ajoja pitää tehdä monta kertaa ja katsoa siitä syntyvää dataa.
Evalit voivat koskea yksittäistä skilliä eli niiden avulla voidaan päätellä, tuottaako skill halutun lopputuloksen. Sen lisäksi evaleita voi rakentaa agenttitasolle.
Harnessin skaalaaminen yhdestä käyttäjästä koko organisaatioon
Harnessin rakentaminen yhden ihmisen käyttöön voi vaatia paljon työtä. Kun rakennetaan harnessia koko organisaation agenteille, tekemisen mittakaava kasvaa ja ongelma vaihtuu periaatteessa toiseksi.
Yhden ihmisen tarvitsema harness sijaitsee yleensä omalla koneella. Käyttäjä tai agentti luo tiedostot ja sen jälkeen ne ovat saatavilla. Kun rakennetaan organisaation harnessia, ongelma on monimutkaisempi. Harnessin kehittäminen, julkaiseminen ja hallinta voi alkaa muistuttaa ohjelmistotuotetta, jolla on omistaja, versiot, julkaisuprosessi ja käyttöoikeudet.
Kun käytämme tekoälyagenttia omien tehtävien hoitamiseen, saatamme huomata, että malli päivittyy tai että jokin skill ei enää toimi yhtä hyvin kuin aiemmin. Mutta kun samaa agenttia käyttää 50 tai 100 ihmistä, kenelläkään ei enää ole kokonaiskuvaa. Kaikki käyttävät agenttia, mutta ovat kiinnostuneita vain oman tehtävänsä hoitamisesta, jolloin kukaan ei välttämättä raportoi, että agentti ei toimi yhtä hyvin kuin joskus aiemmin.
Organisaation agenttien kohdalla jo niiden toiminnan arvioiminen ja kehittäminen (agenttien pitäminen kunnossa vaatii usein jatkuvaa vaivannäköä) pitää vastuuttaa jollekin. Tietysti jos agentti tekee selvästi väärän päätöksen, virhe huomataan ja aletaan selvittää, mistä se johtuu.
Organisaation kohdalla pitää miettiä, miten skillit ja muut ohjeet jaellaan käyttäjille. Jos käyttäjä ajaa agenttia omalla koneella, jaetaanko ohjeet käyttäjän koneelle vai luetaanko niitä keskitetystä paikasta?
Mistä agentti ylipäätään löytyy? Missä hyväksytyt, tuotantokelpoiset agentit ovat?
Miten estetään, etteivät agentit pääse tekemään mitään haitallista? Millaisia oikeuksia niille annetaan? Voi hyvin olla, että käyttäjän oikeudet ovat liian laajat agentille annettavaksi ja siksi agentti tarvitsee omat oikeutensa.
Jos agenttia ei ajeta käyttäjän koneella, missä sitä sitten ajetaan? Virtuaalikoneella tai konttiympäristössä? Missä agenttia kannattaisi ajaa, jotta se olisi aina päällä ja kutsuttavissa tarpeen mukaan eri päätelaitteilla?
Nämä kaikki vaativat miettimistä. Ja tässä on se kohta, jonka moni ohittaa: jo pelkkä rakentaminen on organisaatiotasolla vaativaa työtä.
Yhden ihmisen harness syntyy muutamassa illassa kokeilemalla. Organisaation harnessissa ohjeiden pitää päteä muillekin kuin tekijälleen, agentille pitää avata pääsy oikeisiin tietoihin ja järjestelmiin, ja pitää pystyä todentamaan, että lopputulos kestää tarkastelun kerta toisensa jälkeen — ei vain kerran demossa. Se on projekti, joka vaatii oman panostuksensa.
Organisaatiotason agentin rakentaminen on projekti, ei oman toimen ohessa tehtävä viritys.
Rakentaminen ei sekään ole vielä koko työ. Käyttöönoton jälkeen agentti pitää säilyttää toimintakykyisenä: mallit vaihtuvat, skillit alkavat toimia huonosti, tietolähteet muuttuvat, oikeudet pitää tarkistaa.
Tästä seuraa johtopäätös, joka kulkee vastavirtaan siihen keskusteluun nähden, jota tekoälyn vaikutuksesta työpaikkoihin käydään. Agentit eivät vain poista työtä. Ne myös teettävät sitä — ja iso osa siitä työstä on sellaista, jota tänään ei tee juuri kukaan:
- Harnessin suunnittelu ja rakentaminen
- Agenttien omistajuus ja ylläpito
- Agenttien tarvitseman datan saattaminen käyttökuntoon
- Agenttien versiointi ja julkaiseminen
- Agenttien tekninen monitorointi ja hallinta
- Agenttien tietoturva ja pääsynhallinta
- Agenttien vaatiman infran suunnittelu ja rakentaminen
Olennaista on se, että agentit tulevat nykyisen sovelluskannan päälle, eivät sen tilalle. Teknologiaympäristö kasvaa, ja sen hallinta vaatii yhä enemmän aikaa niin liiketoiminnalta, business IT:ltä kuin perinteiseltä IT:ltäkin.
Yhteenveto
Olen käsitellyt tässä kirjoituksessa harness engineeringiä ja sitä, miten se auttaa parantamaan AI-agenttien tuottamia lopputuloksia. Tässä muutama pääkohta, jotka kannattaa muistaa:
- Ero kahden organisaation tuloksissa ei synny mallista vaan sen ympärille rakennetusta harnessista. Samalla lisenssillä ja samalla kielimallilla toinen agentti tuottaa lähes lähetyskelpoisen tarjouksen ja toinen yleispätevän luonnoksen. Ero on siinä, tietääkö agentti teidän organisaatiosta, prosesseista ja hyvän lopputuloksen tuntomerkeistä — vai arvaako se ne.
- Harness on se osa agenttiratkaisua, johon voitte itse vaikuttaa. Uusi mallisukupolvi parantaa kaikkien tuloksia suunnilleen yhtä paljon. Harnessin parantaminen parantaa vain teidän tuloksianne, ja siksi siitä syntyy kilpailuetua.
- Agentti kannattaa perehdyttää kuten uusi työntekijä. Ohjetiedosto kulkee mukana joka kerta, skillit otetaan esiin vasta tarvittaessa ja loput tiedot haetaan ulkoisista tietolähteistä. Kaikkea ei kannata kaataa agentin niskaan kerralla, koska konteksti-ikkunan täyttyessä laatu alkaa laskea.
- Skillejä kannattaa tehdä vähän mutta hyvin. Hyvä skill voi vaatia oman miniprojektinsa ja nimetyn omistajan, mutta se myös kestää mallin vaihtumisen. Mittarina on skillien avulla tehdyn työn laatu, ei skillien lukumäärä.
- Guardrailit ja evalit ratkaisevat eri ongelman. Guardrail rajaa sitä, kuinka pahasti voi mennä pieleen — vahvimmillaan se on silloin, kun agentti ei edes tiedä rajan olemassaoloa. Eval taas kertoo, tuottaako harness oikeasti sen lopputuloksen, jota siltä odotetaan. Kumpikaan ei korvaa toista.
- Organisaatiotason harness on projekti, ei oman toimen ohessa tehtävä viritys. Yhden ihmisen harness syntyy muutamassa illassa kokeilemalla. Kun samaa agenttia käyttää sata ihmistä, mukaan tulevat omistajuus, versiointi, jakelu, pääsynhallinta ja jatkuva ylläpito.
- Agentit eivät vain poista työtä, ne myös teettävät sitä. Harnessin rakentaminen, datan saattaminen käyttökuntoon, agenttien hallinta ja niiden tietoturva ovat työtä, jota tänään ei tee juuri kukaan. Agentit tulevat nykyisen sovelluskannan päälle, eivät sen tilalle.
Tämä kirjoitus on osa sarjaa, jossa käsittelen AI:n hyödyntämistä yritysympäristössä. Jos haluat saada ilmoituksen, kun julkaisen seuraavan osan, tilaa uutiskirjeeni, niin lähetän sinulle viestin, kun uusi kirjoitus on ulkona.