Tekoälyagentit kaatuvat harvoin. Ne epäonnistuvat huomaamatta, ja tutkimus selittää miksi

Suuria kielimalleja hyödyntävät agentit vastaavat nyt tukipyyntöihin, tekevät hakuja tietokannoista ja suunnittelevat matkoja. Kun jokin menee pieleen, ne antavat yleensä itsevarman vastauksen ja onnistumiskoodin. Yhä laajempi tutkimus auttaa ymmärtämään, miksi näitä virheitä on vaikea havaita ja miten suunnittelutiimit oppivat mittaamaan niitä.

Epäonnistuminen, joka näyttää onnistumiselta

Perinteiset ohjelmistot epäonnistuvat yleensä näkyvästi. Funktio heittää poikkeuksen, palvelin palauttaa virhekoodin ja valvontanäkymä muuttuu punaiseksi. Tekoälyagentti toimii toisin. Se toimii silmukkana: kielimalli lukee kehotteen, päättää kutsua työkalua, kuten hakurajapintaa tai tietokantaa, lukee tuloksen ja päättää, mitä tekee seuraavaksi. Jokaisessa vaiheessa voi mennä jokin pieleen, vaikka kaikki ketjun verkkopyynnöt onnistuisivat.

Ajatellaan tavallista tilannetta. Sääpalvelutyökalu epäonnistuu ja palauttaa muuten tavanomaisen vastauksen sisällä tekstin ”palvelu ei ole käytettävissä”. Malli lukee tekstin ja joko pahoittelee kohteliaasti tai, mikä pahempaa, laatii uskottavalta kuulostavan ennusteen koulutusdatansa perusteella. Käyttäjä saa sujuvan vastauksen. Palvelimen lokit osoittavat, että pyyntö onnistui ja viive oli tavanomainen. Tavanomainen valvontajärjestelmä ei kirjaa mitään merkkiä siitä, että jokin olisi mennyt pieleen.

Mallipalveluntarjoajat kuvaavat samaa puutetta omassa dokumentaatiossaan. Googlen Gemini API -opas huomauttaa, että malli ”ei suorita funktiota itse”. Se ehdottaa vain funktion nimen ja argumentit, ja kehittäjän sovellus suorittaa kutsun. Sovellus on siis järjestelmän ainoa osa, joka näkee todellisen tuloksen. Anthropicin agenttien rakentamista käsittelevä suunnitteluopas nostaa esiin samankaltaisen asian: agentit tarvitsevat ympäristöstä ”todellista tietoa” jokaisessa vaiheessa, esimerkiksi työkalujen tuloksia, jotta ne voivat arvioida edistymistään. Kun työkalu ilmoittaa epäonnistumisesta tavallisena tekstinä, tämä tieto ei pidä paikkaansa, eikä agentilla ole keinoa huomata sitä.

Kyse ei ole uudenlaisesta ongelmasta, vaan vanhan ongelman kärjistyneestä versiosta. Vuonna 2015 Googlen insinöörit, joiden johtajana toimi D. Sculley, kuvasivat ”koneoppimisjärjestelmiin kätkeytyvää teknistä velkaa”. Heidän mukaansa suurin osa tuotantokäytössä olevan koneoppimisjärjestelmän riskeistä liittyy mallikoodin ulkopuolisiin tekijöihin, kuten datariippuvuuksiin, määrityksiin ja järjestelmän osia yhdistävään koodiin. Agentit lisäävät tähän luetteloon uuden kerroksen. Kehotteet ja työkalujen kuvaukset ovat määrityksiä, jotka voivat muuttaa järjestelmän toimintaa ilman koodimuutoksia.

Pienillä muokkauksilla suuret vaikutukset

Kuinka paljon pieni kehotteen muutos voi vaikuttaa? ICLR 2024 -konferenssissa esitellyssä tutkimuksessa Melanie Sclar Washingtonin yliopistosta ja hänen kollegansa muuttivat vain muutaman esimerkin kehotteiden muotoilua: erottimia, välilyöntejä ja kirjainkokoa. Merkitys pysyi samana. Suorituskyky vaihteli silti saman tehtävän yhteydessä jopa 76 tarkkuuspisteen verran LLaMA-2-13B-mallissa. Herkkyys ei kadonnut suuremmilla malleilla, useammilla esimerkeillä eikä ohjehienosäädöllä.

Kirjoittajat suosittelevat ilmoittamaan suorituskyvyn vaihteluvälin useissa uskottavissa kehotemuodoissa yhden luvun sijaan. Suunnittelutiimeille käytännön opetus on yksinkertaisempi. Kehotteen muokkaaminen on koodimuutos. Se edellyttää versiohistoriaa ja testaamista ennen kuin muutos tulee käyttäjien saataville.

Sama koskee työkalujen kuvauksia, jotka malli lukee osana kehotettaan. Anthropicin opas suosittelee kiinnittämään työkalumäärittelyihin ”yhtä paljon huomiota kehotteiden suunnittelussa” kuin pääkehotteeseen. Oppaassa kuvataan koodausagentti, joka teki toistuvasti virheitä suhteellisten tiedostopolkujen kanssa. Kun työkalun käyttöä muutettiin niin, että se edellytti absoluuttisia polkuja, malli käytti työkalua virheettömästi. Malli ei muuttunut. Vain sen lukema kuvaus muuttui.

Yksi onnistuminen ei todista paljoakaan

Toisessa tutkimussuunnassa tarkastellaan johdonmukaisuutta. Shunyu Yaon ja hänen Sierra-yhtiössä työskentelevien kollegoidensa julkaisema τ-bench-vertailutesti, joka esiteltiin ICLR 2025 -konferenssissa, simuloi asiakaspalvelukeskusteluja, joissa agentin on käytettävä työkaluja ja noudatettava liiketoimintasääntöjä. Kirjoittajat esittelivät pass^k-nimisen mittarin: se kuvaa todennäköisyyttä, että agentti ratkaisee saman tehtävän oikein kaikilla k:lla yrityskerralla.

Tulokset olivat huolestuttavia. GPT-4o-agentti ratkaisi vähittäiskaupan tehtävistä noin 61 % yhdellä yrityksellä. Kun sen piti onnistua saman tehtävän suorittamisessa kahdeksan kertaa peräkkäin, osuus laski noin 25 prosenttiin. Kerran toimiva esittely kertoo vain vähän siitä, miten järjestelmä toimii tuhannennella suorituskerralla.

Missä usean agentin järjestelmät pettävät

Monet tiimit ketjuttavat nyt useita agentteja niin, että yksi suunnittelee, toinen toteuttaa ja kolmas tarkistaa työn. UC Berkeleyn vuonna 2025 tekemässä tutkimuksessa ”Miksi usean agentin suurten kielimallien järjestelmät epäonnistuvat?” analysoitiin yli 1 600 kommentoitua suoritusjälkeä seitsemästä suositusta usean agentin viitekehyksestä. Mert Cemrin johtama tutkimusryhmä kehitti MAST-luokittelun, johon kuuluu 14 virhetyyppiä kolmessa ryhmässä: järjestelmän suunnitteluun liittyvät ongelmat, agenttien välinen epätahta ja tehtävän tarkistaminen.

Tutkimuksen keskeinen havainto on, että monet virheet johtuvat järjestelmän suunnittelusta, eivät pelkästään pohjana olevan mallin rajoituksista. Agentit sivuuttavat niille annetun roolin, kadottavat keskustelun punaisen langan tai ilmoittavat tehtävän valmiiksi tarkistamatta tulosta. Näistä virheistä ei jää virheilmoitusta. Ne ovat havaittavissa vain, jos joku pystyy lukemaan, mitä kukin agentti todella teki. Unite.AI:n kirjoitus usean agentin paradoksista nostaa esiin vastaavan arkkitehtuuria koskevan huomion: agenttien lisääminen voi voimistaa varhaista virhettä sen sijaan, että se kumoaisi sen.

Näkymättömän tekeminen näkyväksi

Tekninen ratkaisu on lainattu hajautetuista järjestelmistä, joissa pyyntöjä on jo pitkään seurattu useiden palvelujen läpi jäljityksen avulla. Kun samaa menetelmää sovelletaan agentteihin, jokaisesta käyttäjän pyynnöstä muodostuu jäljitys ja jokaisesta mallikutsusta tai työkalukutsusta sen sisäinen ”span”. Span tallentaa syötteen, tulosteen, käytettyjen tokenien määrän ja suoritusajan. Tämän alan standardointiorganisaatio OpenTelemetry laatii generatiivisen tekoälyn spanien yhteisiä käytäntöjä. Vuonna 2026 nämä käytännöt ovat edelleen kehitysvaiheessa, joten attribuuttien nimet saattavat vielä muuttua.

Useat avoimen lähdekoodin projektit, kuten Langfuse, Arize Phoenix ja AcruxCore, soveltavat tätä ajatusta jo. Niiden lähdekoodi on julkinen, joten tiimit voivat tarkastella, miten jäljitys tallennetaan, ja ajaa ohjelmistoa omilla palvelimillaan. Projektit tallentavat malli- ja työkalukutsut yhden jäljityksen spaneina ja antavat tiimien liittää niihin laatupisteitä. Työkalun valinta ei ole yhtä tärkeää kuin yksi yksityiskohta: työkalun spanin on tallennettava, mitä työkalu todella palautti, eikä vain sitä, onnistuiko verkkopyyntö. Ilman tätä edellä kuvattu säätyökalun virhe jää näkymättömiin.

Alan kyselytutkimusten mukaan jäljitys on nyt yleistä, mutta testaus laahaa perässä. LangChainin Agenttitekniikan tilaa käsittelevässä raportissa kyselyyn vastasi 1 340 alan ammattilaista vuoden 2025 loppupuolella. Laatu oli useimmin mainittu este agenttien tuotantokäytölle: sen mainitsi 32 % vastaajista. 89 % organisaatioista ilmoitti käyttävänsä jonkinlaista agenttien havainnointia, ja 62 % seurasi yksityiskohtaisesti yksittäisiä vaiheita ja työkalukutsuja. Vain 52,4 % teki offline-arviointeja testiaineistoilla, ja 37,3 % arvioi tuotantoliikennettä. Useimmat tiimit näkevät, mitä niiden agentit tekivät. Harvemmat tarkistavat, toimivatko ne oikein.

Vastausten arviointi suuressa mittakaavassa

Jäljitykset kertovat, mitä tapahtui. Ne eivät kerro, oliko vastaus hyvä. Jokaisen keskustelun lukeminen käsin ei skaalaudu, joten tiimit käyttävät yhä useammin toista mallia arvioijana. Tätä lähestymistapaa kutsutaan LLM-tuomaroinniksi. Lianmin Zhengin ja hänen kollegoidensa NeurIPS 2023 -tutkimusartikkelissa havaittiin, että vahvat mallit, kuten GPT-4, olivat samaa mieltä ihmisten mieltymysten kanssa yli 80 % ajasta – suunnilleen yhtä usein kuin ihmiset olivat samaa mieltä keskenään.

Samassa tutkimusartikkelissa kuvattiin myös menetelmän heikkouksia. Arviointimallit suosivat ensin näytettyä vastausta ja pidempiä vastauksia, ja ne voivat suosia itse kirjoittamaansa tekstiä. Arviointimallien pisteet ovatkin arvioita. Niistä on hyötyä suuressa mittakaavassa, mutta ne on tarkistettava pienellä joukolla ihmisten merkitsemiä esimerkkejä, joissa vastausten järjestys on satunnaistettu.

Käytännöistä toimintaperiaatteiksi

Tämä mittaustyö on muuttumassa myös hallinnolliseksi odotukseksi. Yhdysvaltain National Institute of Standards and Technology julkaisi tekoälyn riskienhallintakehyksensä tammikuussa 2023. Yksi sen neljästä keskeisestä toiminnosta, ”Mittaa”, edellyttää, että organisaatiot määrittävät tekoälyyn liittyvät riskit määrällisesti, seuraavat niitä ja dokumentoivat niitä ajan mittaan. Agenttien kohdalla jäljitykset ja arviointipisteet ovat tämän toiminnon edellyttämää näyttöä.

Mitä tiimit voivat tehdä nyt

Tämä vastaa tällä alustalla esitettyä näkemystä siitä, että agenttisen tekoälyn todellinen koetinkivi on luotettavuus. Edellä kuvattu tutkimus täydentää tätä näkemystä mittaamisen yksityiskohdilla: luotettavuus ei ole ominaisuus, jonka voi havainnoida kerran, vaan vaihteluväli, jota on mitattava jatkuvasti.

Tutkimus nostaa esiin muutamia toimintatapoja, joista myös suuret mallipalveluntarjoajat suosittelevat monia. OpenAI:n käytännön oppaassa agenttien rakentamiseen kehotetaan tiimejä ”ottamaan arvioinnit käyttöön suorituskyvyn lähtötason määrittämiseksi” ennen optimointia sekä siirtämään ohjaus ihmiselle, kun agentti ylittää ennalta määritetyn epäonnistuneiden yritysten määrän tai kohtaa suuren riskin sisältävän toiminnon. Anthropic suosittelee ”laajaa testausta hiekkalaatikkoympäristöissä” ennen kuin agentit alkavat toimia itsenäisesti.

Käytännössä tämä tarkoittaa muutamaa konkreettista toimenpidettä. Pidä kehotteet ja työkalujen kuvaukset versionhallinnassa koodin tavoin. Testaa jokainen kehotemuutus kiinteällä aineistolla ja varaudu tulosten vaihteluväliin yhden luvun sijasta. Aja jokainen testitapaus useita kertoja, sillä yksittäinen testikierros peittää epäjohdonmukaisuudet. Tallenna työkalujen tulosteet jäljityksiin, jotta työkaluvirhe ei jää piiloon onnistumiskoodin taakse. Käsittele automaattisen arvioijan pisteitä arvioina ja tarkista ne ihmisten avulla.

Mikään näistä toimintatavoista ei edellytä läpimurtoa mallien suorituskyvyssä. Ne edellyttävät, että tekoälyagenttia käsitellään sellaisena kuin se on: todennäköisyyksiin perustuvana järjestelmänä, jota on mitattava, sillä se ilmoittaa harvoin omista virheistään.