Useimmat agenttien suorituskykyä parantavat tekoälytiimit tarttuvat samoihin keinoihin: suurempiin konteksti-ikkunoihin, useampiin asiakirjoihin ja älykkäämpiin kehotteisiin. Tämän artikkelin mukaan vaisto on täysin väärä. Puuttuva ainesosa ei ole suurempi tietomäärä. Se on hallinta. Hyvin suunniteltu hallintakerros erottaa demossa toimivan agentin tuotannossa toimivasta.
Suurempi muisti, useammat asiakirjat tai pidempi konteksti-ikkuna eivät tee tekoälyagentista älykkäämpää vaan ainoastaan hitaamman ja kalliimman. Todellinen hyöty syntyy siitä, että agentti opetetaan valitsemaan tarvitsemansa tiedot oikealla hetkellä sen sijaan, että se käsittelisi kaiken kerralla.
Luotettavuus syntyy silmukasta, ei mallista. Demossa vakuuttavan ja tuotannossa kestävän agentin välinen ero ei ole tekoälyn laadussa vaan siinä, tarkistaako järjestelmä oman työnsä. Jokaisessa vaiheessa suunnittelevat, toimivat, havainnoivat ja todentavat agentit huomaavat omat virheensä sen sijaan, että ne olisivat itsevarmasti väärässä.
Useimmat nykyiset tekoälyagentit ovat käytännössä chatbotteja, joihin on lisätty vaiheita. Niillä ei ole mekanismia sen tunnistamiseen, etenevätkö ne oikein, milloin niiden pitäisi lopettaa tai milloin niiden pitäisi kokeilla toista lähestymistapaa. Asianmukainen hallintakerros – selkeät onnistumiskriteerit, rakenteinen tila ja validointitarkistukset – tekee agentin muotoisesta objektista aidosti luotettavan.
Mitä söit eilen lounaaksi?
Et luultavasti käynyt läpi jokaista muistoasi, kunnes löysit kohdan ”eilinen + lounas”. Siirryit suoraan siihen kokemustesi osaan, johon nämä käsitteet kuuluvat. Tämä on hyödyllinen ajattelumalli agenttien rakentamiseen:
Valtava konteksti-ikkuna ei ole muisti.
Noudettujen asiakirjojen pino ei ole ymmärrystä.
Pitkä Ajatusketju ei ole luotettavuutta.
Ne ovat ainesosia. Agentin saa tuntumaan agentilta sama asia, jonka ansiosta aivosi eivät käy väkisin läpi koko elämänhistoriaasi: hallinta.
Tuore katsaus – Agentic Reasoning for Large Language Models – tiivistää ja nimeää erinomaisesti muutoksen, jonka moni meistä on havainnut järjestelmiä rakentaessaan: mallin sisäisestä päättelystä vuorovaikutuksen kautta tapahtuvaan päättelyyn. Tämä kirjoitus ei ole kyseisen artikkelin tiivistelmä. Tässä muutos pyritään muuttamaan käytännön järjestelmäsuunnitteluksi:
Jos rakennat agentit työkaluja käyttäviksi chatboteiksi, saat jatkossakin chatbotin tyypillisiä virheitä – mutta kalliimpina.
Pitkään oletuskeinomme ”tehdä mallista älykkäämpi” olivat käytännössä paremmat kehotteet, Ajatusketju, itsejohdonmukaisuus tai otantaan perustuvat parannukset sekä ehkä jonkinlainen haku.
ReAct oli käännekohta, koska se teki mallista ”ajatus → toiminta → havainto” luontevan. Huomaa kuitenkin piilevä rajoite: suuri osa tästä on yhä ”Yhdellä esimerkillä opettaminen, mutta useammilla tokeneilla”. Katsauksen jäsennys on terävämpi: agenttimainen päättely korostaa testiaikaisen vuorovaikutuksen skaalaamista eli päättelyn muuttamista iteratiiviseksi prosessiksi, jossa malli, muisti ja ympäristö pysyvät mukana silmukassa.
Jos olet rakentanut tai käyttänyt agentteja, jotka vakuuttavat demoissa mutta ovat hauraita todellisissa työnkuluissa, tämä kirjoitus on sinulle.
Kuvaan seuraavaksi usein näkemäni toimintamallin, josta olen itsekin varmasti rakentanut omia versioitani:
Ota hyvä keskustelumalli
Lisää muutama työkalu (haku, tietokantakysely ja ehkä koodin suoritus)
Lisää RAG
Lisää järjestelmäkehote ”olet itsenäinen agentti”
Kääri kaikki while-silmukkaan, joka jatkuu pysähtymiseen tai aikakatkaisuun asti
Onneksi olkoon, sinulla on agentin muotoinen objekti. Se kuitenkin epäonnistuu yleensä ennustettavilla tavoilla:
Kontekstin paisuminen: jokainen havainto lisätään jatkoksi, ja kehotteista muodostuu arkeologisia kerrostumia.
Työkalujen summittainen käyttö: oletusvirheeksi muodostuu ”väärä työkalu mutta täydellä itsevarmuudella”.
Ei lopetusehtoja: se jatkaa, koska pystyy, ei koska sen pitäisi.
Todennettuihin tietoihin sitouttaminen puuttuu: se ei huomaa olevansa väärässä, ellet pakota sitä tarkistamaan asiaa.
Muisti = keskusteluhistoria: käytännössä siis lokien kirjoittamista ja sen kutsumista oppimiseksi.
Siksi ”agentit” vaikuttavat demoissa usein taianomaisilta mutta ovat tuotannossa sotkuisia. Myös kokemuksemme agenttimaisten järjestelmien viemisestä tuotantoon tukee tätä: kun et enää arvioi mallia vaan järjestelmää, virhetilanteet liittyvät navigointiin, työkalujen hallintaan, kontekstin karsimiseen ja arvioinnin suunnitteluun – eivät vain siihen, ”vastasiko malli oikein”.
Kysymys kuuluukin: millainen on tarkoituksellinen agentti?
Tehdään asiasta konkreettisempi työnkululla, jonka useimmat voivat kuvitella: ”Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Tavallinen ”agentin kaltainen” toteutus toimii näin:
Se noutaa heti joukon lentoyhtiöiden ja matkustamisen käytäntöasiakirjoja, vaikkei niitä vielä tarvittaisi.
Se kutsuu hakutyökalua, liittää pitkän tulosluettelon kehotteeseen ja ”valitsee yhden”.
Se tekee varauksen liian aikaisin tarkistamatta rajoitteita, kuten saapumisaikaa, matkatavaroita, istumapaikkaa ja käytäntöjä.
Jos se epäonnistuu, se yrittää uudelleen hieman eri tavalla mutta ei tiedä selvästi, mikä muuttui tai mitä se oppi.
Ongelma ei ole se, ettei malli osaisi päätellä, vaan se, ettei järjestelmä hallitse työnkulkua.
Agenttimaisempi versio käsittelee tehtävää vuorovaikutteisena prosessina, jolla on eksplisiittinen tila ja tarkistukset:
SUUNNITTELE: kertaa rajoitteet ja luettele puuttuvat tiedot (esim. ”which airport preference?” / ”is 1 stop ok?”).
TOIMI: kutsu lentohakua rakenteisella kyselyllä (päivämääräväli, saapumisaikarajoite ja budjetti).
HAVAINNOI: tallenna tulokset tiiviiseen tilaobjektiin (viisi parasta vaihtoehtoa hintoineen, saapumisaikoineen ja välilaskuineen), älä valtavaksi tekstimassaksi.
PÄIVITÄ: tarkenna kyselyä, jos rajoitteet eivät täyty (esim. ”arrival before 6pm is too strict—widen time window or raise budget?”).
TODENNA: suorita validaattorit (”saapuminen < 18.00”, ”hinta ≤ £900”, ”käytäntöjen mukainen”, ”istumapaikan voi valita”).
LOPETA: vasta kun varausrajapinta palauttaa vahvistuksen ja kaikki validaattorit hyväksyvät tuloksen.
Muutos on hienovarainen mutta ratkaiseva. Tietoja noudetaan ehdollisesti eikä refleksinomaisesti, kontekstia hallitaan eli tila on rakenteinen eikä vain kasaannu, ja todentaminen kuuluu silmukkaan eikä jää käyttäjän tehtäväksi. Vaihda ”lennon varaamisen” tilalle ”ostotilauksen luominen”, ”hyvityksen maksaminen”, ”tuotantoympäristön määrityksen muuttaminen” tai ”PR:n julkaiseminen”. Periaate on sama: kun agentti voi toimia, silmukka on kehotetta tärkeämpi.
Edellä mainittu katsaus jakaa agenttimaisen päättelyn kolmeen kerrokseen: perustaan (suunnittelu, työkalujen käyttö ja haku), itse kehittyvään toimintaan (palaute ja muisti) sekä kollektiiviseen toimintaan (useiden agenttien koordinointi).
Syvempi ajatus on kuitenkin se, että päättelystä tulee suunnittelua, päätöksentekoa ja todentamista ohjaava periaate eikä vain uskottavan Ajatusketjun tuottamista. Tämä kuulostaa abstraktilta, kunnes sen yhdistää arkkitehtuurissa tapahtuviin muutoksiin. Muista kolme keskeistä asiaa:
Hyvän agentin ei pidä noutaa tietoja aina. Noutaminen on päätös, ei refleksi.
Tässä on käytännöllinen nyrkkisääntö:
Jos järjestelmäsi noutaa tietoja jokaisella vuorolla, et ole rakentanut tiedonhakua vaan kontekstiveron.
Tätä tapahtuu käytännön työssä jatkuvasti. Kun selvität tuotantohäiriötä, et kaada kaikkia lokeja kontekstiin. Päätät nykyisen hypoteesisi perusteella, mitkä mittarit tai lokit noudetaan seuraavaksi. Se on ”agenttimaista tiedonhakua”. Tässä on konkreettisempi toimintamalli:
Päätä, tarvitsetko tiedonhakua
Jos tarvitset: laadi kysely, nouda, silmäile ja poimi olennainen
Jos näyttö on ristiriitaista, nouda lisää tietoa
Muodosta yhteenveto vasta sitten
Tässä myös ”agenttimainen RAG” alkaa erota perinteisestä RAGista: tiedonhausta tulee harkittu päättelyvaihe eikä prosessin oletusarvoinen vaihe.
Kun arvioinnin kohteena ei enää ole ”malli” vaan ”järjestelmä”, tilan seurannasta ja jäljityksestä tulee olennaisia.
Ala on tähän mennessä alkanut puhua aiempaa selvemmin agenttien työnkulkujen havainnoitavuudesta. Esimerkiksi OpenAI Agents SDK sisältää valmiin jäljityksen ja Traces-koontinäytön. Se tallentaa agenttien suoritukset (generoinnit, työkalukutsut, tehtävänsiirrot, suojakaiteet ja mukautetut tapahtumat), jotta tapahtumia voi selvittää ja tarkastaa vaihe vaiheelta.
Tämä ei ole vain ”mukava lisä”. Se erottaa järjestelmän, jonka virheitä voi selvittää, järjestelmästä, jonka toimivuutta voi arvioida vain mutu-tuntumalla.
Katsauksen käyttökelpoisin osa on mielestäni se, miten suoraan siinä käsitellään palautetta. Siinä palaute jaetaan kolmeen toimintatapaan: reflektoiva palaute (tuota → arvioi kriittisesti → korjaa), parametrinen mukautuminen (oppiminen hienosäädöllä tai vahvistusoppimisella) ja validaattoriohjattu palaute (yritä uudelleen, kunnes validaattori hyväksyy tuloksen).
Useimpien tiimien kannattaa aloittaa validaattoriohjatusta palautteesta, koska se on tylsää mutta tehokasta. Jos pystyt kirjoittamaan minkä tahansa validaattorin, joka suorittaa yksikkötestejä, tarkistaa skeeman, asettaa liiketoimintasääntöjä tai rajoitteita (”ei yli X:n suuruisia hyvityksiä ilman eskalointia”) tai varmistaa paikkansapitävyyden (”lähdeviitteet vaaditaan”), voit muuttaa mallin epädeterministisen tulosteen aidosti luotettavaksi.
Yksi tässä piilevistä ennakoimattomista muutoksista on yksinkertainen: agenttien maailmassa luotettavuus syntyy usein enemmän silmukasta kuin mallista.
Tämä on yksinkertaisin löytämäni silmukkakäytäntö, joka parantaa toimintaa luotettavasti ilman koulutusta:
Etene vaiheittain: suunnittele → toimi → havainnoi → päivitä.
Tiivistä jokaisen toimintavaiheen jälkeen havainnot 1–3 luetelmakohtaan.
Lopeta, kun onnistumiskriteerit täyttyvät tai budjetti täyttyy. Palauta paras tiedossa oleva tulos ja jäljellä olevat epävarmuudet.
Tarkoitus ei ole saada mallia tuottamaan vuolasta tekstiä. Tarkoitus on tehdä järjestelmän toiminnasta ymmärrettävää ja pakottaa se tarkistamaan todellisuus jokaisessa vaiheessa. Insinööreille hyvin tuttu esimerkki on CI-tyylinen suljetun silmukan todennettuihin tietoihin sitouttaminen:
Suunnittele: ehdota muutosluetteloa
Toimi: suorita testit ja linttaus
Havainnoi: jäsennä virheet
Päivitä: korjaa ja yritä uudelleen
Seuraavat kysymykset paljastavat usein vahingossa agenteiksi rakennetut ratkaisut:
”Päättääkö agenttini itse, mitä tietoja noudetaan, vai noudanko niitä aina?”
Jos tietoja noudetaan aina, seurauksena ovat viiveet, kustannukset, kontekstin laimentuminen ja kasvanut riski siitä, että huono syöte tuottaa huonon tuloksen.
”Huomaako agenttini olevansa väärässä?”
Jos agenttisi saa palautetta vain käyttäjän ärsyyntymisestä, harjoitat vahvistusoppimista ihmisten kärsimyksen avulla. Validaattoriohjattu uudelleenyrityssilmukka on selkein tapa pakottaa agentti tarkistamaan todellisuus.
”Voiko muistiin kirjoittaa, ja paraneeko se ajan myötä?”
Jos ”muisti” vain kartuttaa keskusteluhistoriaa, kirjoitat käytännössä lokia. Katsauksen tapa kuvata muistia on tärkeä: muistista tulee ajan myötä agenttien jalostama, dynaamisesti kasvava konteksti – ei pelkkä keskustelutallenne.
Lokit kertovat, mitä tapahtui. Muisti kertoo, mitä ensi kerralla kannattaa tehdä. Keskusteluhistoria on tallenne. Muisti on kehittyvä toimintaperiaate siitä, mitä kannattaa säilyttää tulevaa varten.
Käytännöllinen aloitusratkaisu on pieni oppien taulukko, jonka avaimina ovat tehtävätyyppi, työkalu ja virhetilanne sekä arvoina tieto siitä, mikä toimi ja mitä kannattaa välttää. Tarkoitus ei ole rakentaa täydellistä tietämysgraafia. Tarkoitus on luoda kumuloituvaa toimintaa: muistin ja palautteen avulla agenteista tulee ajan myötä kehittyviä järjestelmiä eikä ”tilattomia apureita”.
Ongelmaan tekee mieli lisätä agenteja, mutta se moninkertaistaa usein koordinoinnin kuormituksen. Hyvä toimintamalli toimivalle vähimmäistiimille:
Koordinaattori: jakaa tehtävän osiin ja osoittaa osat tekijöille
Suorittaja: tekee työkalukutsut ja muutokset
Kriitikko/arvioija: tarkistaa oikeellisuuden ja riskit
Muistinhoitaja: kirjaa ja kuratoi opit
Jos et osaa selittää kunkin agentin vastuualuetta, et todennäköisesti vielä tarvitse useita agentteja.
Jos todella hyväksymme paradigman muutoksen, lakkaamme luultavasti tunkemasta kaikkea kehotteisiin, käsittelemästä epäonnistumisia lopullisina tuloksina ja arvioimasta agentteja chatbotteina. Sen sijaan alamme kohdella agentteja sellaisina kuin ne ovat: ohjelmistojärjestelminä, joissa kieli toimii ohjaustasona ja luotettavuus syntyy silmukasta.
Lisää uusi arviointisilmukka ennen uuden mallin lisäämistä. Tee tiedonhausta ehdollista ennen kuin noudat kaiken. Julkaise yksi validaattori ennen kymmentä. Käsittele muistia toimintaperiaatteita koskevina päätöksinä, älä tietokantana. Kun siirryt useisiin agentteihin, aloita kahdesta äläkä kahdestakymmenestä. Nämä eivät ole sääntöjä vaan tuotantokäytössä kestäviksi osoittautuneita toimintamalleja.