Mitä kukaan ei kerro tekoälyagenttien ajamisesta tuotannossa

Kaava toistuu lähes jokaisessa yrityksessä, joka on vienyt tekoälyautomaation tuotantoon: demo on vakuuttava, pilotti lupaava ja tuotantokäyttöönotto näyttää hyvältä ensimmäiset pari viikkoa. Sitten jokin menee pieleen hiljalleen. Agentti alkaa tuottaa hieman erilaisia tuloksia kuin odotettiin. Dokumenttien käsittelyajo epäonnistuu hiljaisesti. Kustannukset ovat 40 % arvioitua korkeammat. Kenelläkään ei ole runbookia tilanteelle.

Kuilu toimivan demon ja tuotannossa luotettavasti pyörivän automaation välillä ei ole ensisijaisesti mallikvaliteettiongelma. Se on infrastruktuuriongelma — ja useimmat tiimit aliarvioivat sen ennen kuin ovat jo siinä sisällä.

Virheenkäsittely ei ole valinnainen ominaisuus

LLM-rajapinnat kaatuvat. Ne palauttavat 500-virheitä ruuhka-aikoina, aikaoutaavat suurten syötteiden kanssa ja törmäävät rate limitteihin juuri väärällä hetkellä. Useimmilla demo-vaiheen agenteilla ei ole retry-logiikkaa, vaihtoehtoista toimintatapaa eikä hälytystä hiljaisista epäonnistumisista. Ongelma paljastuu usein vasta, kun liiketoimintakäyttäjä huomaa tunteja myöhemmin, ettei erää dokumentteja ole käsitelty lainkaan.

Tekoälyautomaation robusti virheenkäsittely muistuttaa mitä tahansa hajautetun järjestelmän virheenkäsittelyä: eksponentiaalinen backoff tilapäisissä virheissä, dead-letter-jono syötteille joita agentti ei pysty käsittelemään, ja hälytys joka laukeaa ennen kuin ongelma tavoittaa liiketoiminnan. Koodi on suoraviivainen. Vaikeampi osa on päätös rakentaa se ennen kuin sitä tarvitaan. Käytännössä emme juuri koskaan näe tätä valmiina talon sisällä tehdyn tekoälyautomaation ensimmäisessä versiossa — ja lisäämme sen lähes aina ensimmäisen kuukauden aikana.

Havainnoitavuus: et voi debugata sitä, mitä et näe

Kun perinteinen palvelu käyttäytyy odottamattomasti, tarkistat lokit ja löydät stack tracen. Kun tekoälyagentti tuottaa väärää tulosta, lokit näyttävät onnistuneen API-kutsun ja validin JSON-vastauksen. Agentti teki mitä siltä pyydettiin — ongelma on siinä mitä siltä pyydettiin, tai mitä malli päätti tehdä sen kanssa.

Käyttökelpoinen havainnoitavuus tekoälyautomaatiolle tarkoittaa koko promptin lokittamista (sisältäen ajonaikana injektoidun kontekstin), mallin täydellisen vastauksen tallentamista ennen parsimista, token-määrän ja kutsukustannuksen seurantaa sekä lopullisen tulosteen kirjaamista jälkikäsittelyn jälkeen. Ilman kaikkia neljää laadun regression debuggaaminen on arkeologiaa. Niiden kanssa näet tarkalleen milloin ja miksi agentti alkoi tuottaa erilaisia tuloksia — mallin versiopäivitys, syöteformaatin muutos tai prompti joka toimii lyhyillä dokumenteilla mutta hajoaa pitkillä. Eräällä asiakkaallammme oli ekstraktioputki, joka alkoi satunnaisesti tuottaa viallista JSONia mallin päivityksen jälkeen. Ilman raakavastauksen lokia olisi kestänyt päiviä löytää syy.

Kun kustannukset karkaavat

Testausympäristössä käsittelet 200 dokumenttia. Tuotannossa käsittelet 8 000 kuukaudessa, joista osa on 40-sivuisia sopimuksia jotka kuluttavat 15 000 tokenia kappale. Token-kustannukset eivät skaalaudu lineaarisesti dokumenttimäärän kanssa — ne skaalautuvat volyymin, dokumenttikoon, retry-asteen ja promptin rönsyisyyden yhdistelmänä. Testidataan perustuva kustannusarvio voi olla kolminkertaisesti pielessä.

Ratkaisu ei yleensä ole parempi malli — se on paremmat promptit ja parempi arkkitehtuuri. Identtisten pyyntöjen tulosten välimuistitus, suurten dokumenttien pilkkominen kokonaisena passaamisen sijaan, promptien rakentaminen eksplisiittisiksi konversationaalisen sijaan, yksinkertaisten tapausten reititys edullisemmille malleille. Löydämme tyypillisesti 40–60 % kustannusvähennyspotentiaalin ensimmäisessä optimointikierroksessa. Automaation rakentanut tiimi löytää sen myös itse — kunhan heillä on kutsukustannusdata tarkasteltavanaan. Data on edellytys; ilman sitä ei ole mitään mihin optimoida.

Se 3 %, jonka agentti saa väärin

Jokaisella tekoälyautomaatiolla on virhetaso. 97 % tarkkuus kuulostaa hyväksyttävältä, kunnes käsittelet taloudellisia asiakirjoja, potilastietoja tai oikeudellisesti sitovia sopimuksia. Kysymys ei ole siitä, epäonnistuuko agentti — vaan mitä tapahtuu kun se epäonnistuu.

Useimmat automaatiot eivät vastaa tähän kysymykseen. Epäonnistuva tapaus joko lipuu seuraavaan järjestelmään huomaamatta, putoaa pois tai laukaisee geneerisen virheen, johon kenelläkään ei ole prosessia. Oikea suunnittelu kysyy: mitä agentin täytyy nostaa ihmisen arvioitavaksi? Mitä tietoa ihminen tarvitsee korjatakseen sen? Miten korjaukset palautuvat parantamaan järjestelmää? Tämä eskalaatiopolku on vaikeampi rakentaa kuin itse agentti. Se on myös se, mikä tekee eron automaation välillä joka pyörii ja automaation välillä johon oikeasti uskaltaa luottaa tuotantodatan kanssa.

Tuotannossa luotettavasti toimivat tekoälyagentit eivät ole perustavanlaatuisesti erilaisia kuin demo-agentit — mutta ne ympäröidään infrastruktuurilla jota demo ei tarvinnut. Monitorointi, retry-logiikka, kustannuslaskenta, ihmisen eskalaatiopolut. Tiimit jotka rakentavat tämän infrastruktuurin ennen kuin sitä tarvitaan viettävät perjantai-iltansa muissa puuhissa.

Rebooted Solutions suunnittelee ja rakentaa tekoälyautomaatioita, jotka on tarkoitettu toimimaan tuotannossa — ensimmäisestä putkesta havainnoitavuuskerrokseen ja eskalaatiopolkuihin asti. Jos automaatiosi pyörii mutta ei luotettavasti, tai olet siirtämässä pilottia tuotantoon ja haluat saada infrastruktuurin kerralla oikein, ota yhteyttä.