Heidän luvattiin meille agentteja, mutta saimme vain staattisia ketjuja

Keväällä 2023 maailma innostui LLM-pohjaisista tekoälyagentteista. Voimakkaat demon, kuten AutoGPT ja BabyAGI, osoittivat LLM:n potentiaalin toimia silmukassa, valitsemalla seuraavan toiminnon, havainnoimalla tuloksia ja valitsemalla seuraavan toiminnon yhden askeleen kerrallaan (tunnetaan myös ReACT-kehyksenä). Tästä uudesta menetelmästä odotettiin, että se mahdollistaisi agenttien, jotka suorittavat monivaiheisia tehtäviä autonomisesti ja geneerisesti. Anna sille tavoite ja joukko työkaluja, ja se hoitaa loput. Vuoden 2024 loppuun mennessä maisema on täynnä tekoälyagentteja ja tekoälyagenttikehyksiä. Mutta miten he ovat verrattavissa lupausten toteutumiseen?

On turvallista sanoa, että agentit, jotka perustuvat ReACT-kehykseen, kärsivät vakavista rajoituksista. Anna heille tehtävä, joka vaatii useita askelia, useita työkaluja, ja he epäonnistuvat surkeasti. Latenssin ongelmien lisäksi he menettävät jäljityskykynsä, eivät seuraa ohjeita, lopettavat liian aikaisin tai liian myöhään, ja tuottavat erilaisia tuloksia jokaisella yrittämiskerralla. Ja ei ole ihme. ReACT-kehyksen rajoitukset perustuvat LLM:n ennustamattomuuteen, ja ne yhdistyvät askelten määrään. Agenttien rakentajat, jotka haluavat ratkaista todellisia käyttötapauksia, erityisesti yrityksissä, eivät voi tyytyä tähän tasoon suorituskykyyn. He tarvitsevat luotettavia, ennustettavia ja selitettäviä tuloksia monivaiheisille työvirroille. Ja he tarvitsevat tekoälyjärjestelmiä, jotka lieventävät LLM:n ennustamattomuutta, sen sijaan että lisäisivät sitä.

Niin, miten agentteja rakennetaan yrityksissä tänään? Käyttötapauksille, jotka vaativat useita työkaluja ja useita askelia (esim. keskustelupalvelu RAG), agenttien rakentajat ovat suurelta osin hylänneet ReACT:n dynaamisen ja autonomisen luvan ja siirtyneet staattisen ketjun muodostamiseen – erityisen käyttötapauksen ratkaisemiseen suunniteltujen ketjujen luomiseen. Tämä lähestymistapa muistuttaa perinteistä ohjelmistosuunnittelua ja on kaukana ReACT:n agenttien luvasta. Se saavuttaa korkeamman tason hallintaa ja luotettavuutta, mutta se puuttuu autonomiasta ja joustavuudesta. Ratkaisut ovat kehitykseltään intensiivisiä, soveltamisalaltaan kapeita ja liian jähmeitä osoittamaan korkeita muuttujia syöttö- ja ympäristötilassa.

On kuitenkin varmistettava, että staattisen ketjun käytännöt voivat vaihdella siinä, kuinka “staattisia” ne ovat. Jotkut ketjut käyttävät LLM:ää vain atomisten askelten suorittamiseen (esim. tietojen hakemiseen, tekstin yhteenvedon tekemiseen tai viestin luomiseen), kun taas toiset käyttävät LLM:ää myös dynaamisten päätösten tekemiseen suoritusaikana (esim. LLM reitittää vaihtoehtoisten virran ketjussa tai LLM validoi askelen tuloksen määrittämiseksi, pitäisikö sitä toistaa). Joka tapauksessa, kun LLM:t ovat vastuussa dynaamisesta päätöksenteosta ratkaisussa, joutumme väistämättä luotettavuuden ja autonomian väliseen kompromissiin. Mitä enemmän ratkaisu on staattinen, on sitä luotettavampi ja ennustettavampi, mutta myös vähemmän autonominen ja kapeampi soveltamisala ja kehitykseltään intensiivisempi. Mitä enemmän ratkaisu on dynaaminen ja autonominen, on sitä geneerisempi ja yksinkertaisempi rakentaa, mutta myös vähemmän luotettava ja ennustettava.

Tämä kompromissi voidaan esittää seuraavassa kaaviossa:

Tämä herättää kysymyksen, miksi emme ole vielä nähneet agenttikehyksessä, joka voidaan sijoittaa ylä-oikeaan neljännekseen? Olemme kohtalonomaisesti sidottuja luotettavuuden ja autonomian välistä kompromissiin? Emme voi saada kehyksessä, joka tarjoaa ReACT-agentin yksinkertaisen käyttöliittymän (ota tavoite ja joukko työkaluja ja ratkaise se), ilman luotettavuuden uhraamista?

Vastaus on – voimme ja teemme! Mutta siihen tarvitaan, että ymmärrämme, että olemme tehneet kaiken väärin. Kaikki nykyiset agenttikehykset jakavat yhteisen virheen: ne perustuvat LLM:ään dynaamisena ja autonomisena komponenttina. Mutta se olennainen elementti, jota tarvitaan luotettavien ja autonomisten agenttien luomiseen, on suunnitteluteknologia. Ja LLM:t eivät ole hyviä suunnittelijoita.

Mutta mitä suunnittelulla tarkoitetaan? Suunnittelulla tarkoitamme kykyä mallintaa eri toimintavaihtoehtoja, jotka johtavat haluttuun tulokseen, ja tutkia ja hyödyntää näitä vaihtoehtoja budjettirajoituksissa. Suunnittelun tulisi tapahtua sekä makro- että mikrotasolla. Makro-suunnitelma jakaa tehtävän riippuvaisiin ja riippumattomiin askeliin, jotka on suoritettava halutun tuloksen saavuttamiseksi. Usein huomiotta jäävä seikka on mikro-suunnittelun tarve, jolla voidaan taata halutut tulokset askelkohtaisella tasolla. On olemassa useita strategioita, joilla voidaan parantaa luotettavuutta ja saavuttaa takeet yksittäisellä askelulla käyttämällä enemmän inference-ajan laskentaa. Esimerkiksi voit paraphrasoida semanttisia hakukyselyjä useita kertoja, voit hakea enemmän kontekstia kullekin kyselylle, voit käyttää suurempaa mallia ja voit saada enemmän inference-ja LLM:stä – joista voit valita parhaan tuloksen. Hyvä mikro-suunnittelija voi käyttää inference-ajan laskentaa tehokkaasti saavuttaakseen parhaat tulokset annetun laskennan ja viiveen budjetin puitteissa. Tällä tavoin suunnitelmalliset tekoälyjärjestelmät voivat lieventää LLM:n todennäköisyyden luonnetta ja saavuttaa taatut tulokset askelkohtaisella tasolla. Ilman näitä takeita olemme takaisin kompensaatioprobleman luona, joka vaarantaa jopa parhaimman makro-tason suunnitelman.

Mutta miksi LLM:t eivät voi toimia suunnittelijoina? Ne ovat kykeneviä kääntämään korkean tason ohjeita järkeviksi ketjuiksi ajatuksia tai suunnitelmiksi luonnollisessa kielessä tai koodissa. Syy on, että suunnittelu vaatii enemmän kuin vain sitä. Suunnittelu vaatii kykyä mallintaa eri toimintavaihtoehtoja, jotka voivat johtaa haluttuun tulokseen, sekä odotetun hyödyn ja odotetun kustannusten (laskennan ja/tai viiveen) arvioimisen kullekin vaihtoehdolle. Vaikka LLM:t voivat mahdollisesti luoda edustuksia saatavilla olevista toimintavaihtoehdoista, ne eivät voi ennustaa niiden odotettua hyötyä ja kustannuksia. Esimerkiksi, mitkä ovat odotettu hyöty ja kustannukset mallin X käytöstä verrattuna malliin Y vastauksen luomiseen tietyssä kontekstissa? Mitä on odotettu hyöty etsimästä tiettyä tietoa indeksoituista asiakirjoista verrattuna API-kutsuun CRM:ään? LLM:llä ei ole aavistustakaan. Ja hyvällä syyllä – historialliset jäljet näistä todennäköisyyden piirteistä ovat harvinaisia luonnossa ja eivät sisälly LLM:n koulutusdataan. Ne ovat myös tyypillisesti erityisiä työkaluille ja tietoympäristölle, joissa tekoälyjärjestelmä toimii, toisin kuin yleinen tieto, jonka LLM:t voivat hankkia. Ja vaikka LLM:t voivat ennustaa odotetun hyödyn ja kustannukset, niiden perusteella päätöksenteon logiikka on päättelyteoreettinen deduktiivinen prosessi, jota ei voida olettaa LLM:den seuraavan tokenin ennusteen toteuttavan luotettavasti.

Mitkä ovat puuttuvat ainekset tekoälysuunnitteluteknologialle? Tarvitsemme suunnittelumalleja, jotka voivat oppia kokemuksesta ja simulaatiosta ja mallintaa eri toimintavaihtoehtoja ja niiden hyöty- ja kustannusmahdollisuuksia tietyssä tehtävässä ja työkalu- ja tietoympäristössä. Tarvitsemme suunnitelman määrittelykielen (PDL), jota voidaan käyttää edustamaan ja päättämään näistä toimintavaihtoehdoista ja todennäköisyyksistä. Tarvitsemme suoritustyön moottorin, joka voi suorittaa deterministisesti ja tehokkaasti annetun suunnitelman PDL:ssä.

Jotkut ovat jo kovalla työllä lupaamassa täyttää tämä luvattu asia. Siihen asti, jatkakaa staattisten ketjujen rakentamista. Älkää kuitenkaan kutsuko niitä “agenteiksi”.