Miksi tekoälyagentit läpäisevät laadunvalvontatestin, mutta epäonnistuvat tuotannossa

Jatkuva oppiminen on muuttumassa siihen insinööritieteeseen, joka parantaa agenttien toimintaa käyttöönoton jälkeen ilman sitä, että se rikkoisi jo toimivaa toiminnallisuutta.

Tekoälyagentti voi läpäistä jokaisen ennen käyttöönottoa tehdyn arvioinnin ja silti epäonnistua tuotannossa viikon kuluttua. Tämä ei ole ristiriita. Arviointijoukko heijastaa sitä, mitä tiimi tiesi testata ennen käyttöönottoa. Tuotanto on se paikka, jossa puuttuvat tapaukset tulevat esiin: outo sanamuoto, puuttuva konteksti, työkalujen reunatapaukset, kärsivälliset käyttäjät, ristiriitaiset käytännöt ja työnkulut, joita kukaan benchmark-suunnittelija ei ole kuvitellut.

Agentti korjataan käyttäjien toimesta jatkuvasti. Se pettyää käyttäjiä. Sitten istunto päättyy, lokitallennus tallennetaan, ja seuraava käyttäjä kohtaa käytännössä saman järjestelmän.

Tämä on syynä, miksi jatkuva oppiminen on muuttumassa keskeiseksi osaksi agenttien insinööritieteeseen. Se ei ole yhden tuotteen ominaisuus. Se on menetelmien kategoria, jolla agentit paranevat kokemuksesta ja säilyttävät samalla sen, mitä he jo osaavat. Perinteinen jatkuva oppimisen tutkimus määritteli ongelman oppimiseksi ajan myötä ilman katastrofaalista unohtamista. Agentit laajentavat tämän ongelman. Se, mikä muuttuu, voi olla malli, mutta se voi olla myös kehote, työkalu, taito, työnkulu tai muisti.

Tämä ero on tärkeä, koska useimmat agenttien epäonnistumiset eivät ratkea mallin kouluttamisen avulla.

Hienosäätörefleksi on liian kapea

Kun tiimit puhuvat siitä, miten tekoälyjärjestelmää parannetaan, suunnitelma kuulostaa usein näin: kerää epäonnistumisia, merkitse paremmat vastaukset, hienosäädä malli. Tämä vaisto on ymmärrettävissä. Valvottu hienosäätö, suoran preferenssioptimoinnin, ryhmän suhteellisen käyttäytymisoptimoimisen ja parametrin tehokkaat menetelmät, kuten LoRA, ovat hyödyllisiä työkaluja, kun malli itsessään tarvitsee muutosta.

Mutta useat tuotannon epäonnistumiset eivät ole mallipaino-epäonnistumisia. Ne ovat järjestelmän epäonnistumisia.

Agentti voi nojata vanhaan muistiin, ohittaa vaaditun vahvistuksen, kutsua työkalua väärällä argumentilla tai ohjata tapausta väärän työnkulun kautta. Usein ongelma ei ole perusmallin kyvyssä. Se on kontekstissa, muistissa, työkalurajapinnassa tai työnkulussa, joka on sitä ympäröivä.

Nykyinen agentti on useista kerroksista koostuva. Malli päättelee ja luo. Sen ympärillä oleva harness määrittää kehotteet, työkalut, taidot, koodin, reitityksen ja työnkulun. Muisti kantaa tietoja ja opittuja menettelyjä istuntojen yli. Jatkuva oppiminen on päättämisen taito, joka määrittää, mikä kerros pitäisi muuttua, kuinka pieni muutos voi olla ja miten varmistetaan, että muutos todella auttoi.

Joskus oikea korjaus on muistin kirjoitus. Joskus se on kehote, työkalun kuori, reitityssääntö tai työnkulun korjaus. Hienosäätö pitäisi pysyä käytettävissä, mutta se ei pitäisi olla vastaus jokaiseen epäonnistumiseen.

Benchmarkit ovat hyödyllisiä, mutta tuotanto harvoin antaa niitä

On olemassa mielenkiintoista työtä agenttien itse ohjaimen optimoinnissa. Menetelmät, kuten GEPA, Meta-Harness, ja liittyvät kehote- tai työnkulun optimointilähestymistavat käsittelevät agenttia järjestelmänä, jota voidaan muuttaa ja testata. Ne voivat ehdottaa muutoksia kehoitteisiin tai muihin ohjaimen komponentteihin, suorittaa ehdokkaita ja pitää versioita, jotka saavat paremman arvosanan.

Tämä on oikea suunta. Se siirtää parantamisen kapeasta kehyksestä “päivitä painot” laajempaan kehykseen “paranna agenttia”.

Mutta on yksi ongelma: nämä menetelmät olettavat benchmarkin. Ne tarvitsevat tehtävän, jota voidaan suorittaa toistuvasti, ja arvioijan, joka sanoo, kumpi ehdokas on parempi. Ilman sitä optimointi muuttuu arvaukseksi paremmalla työkalulla.

Tämä ei ole sitä, mitä useimmat tiimit tuotannossa ovat.

Heillä on lokit. Heillä on jäljitykset, käyttäjien korjaukset, tukipyynnöt, peukku-alaspäin-tapahtumat, eskaloitumismerkinnät ja satunnaiset asiantuntijapalautteet. Nämä signaalit ovat arvokkaita, mutta ne eivät ole vielä benchmark. Ne kertovat, että jotain tapahtui. Ne eivät kerro, miten toistaa sen, miltä menestys näyttää tai miten arvioida ehdotettua korjausta.

Tämä aukko on se, jossa moni jatkuva oppimisen pyrkimys jumittuu. Tiimillä on kokemus, mutta ei vielä oppimisympäristöä.

Lokit eivät ole opetuksia

Tuotannon lokimerkintä tallentaa yhden polun vuorovaikutukseen. Käyttäjä pyysi lentoa. Agentti etsi. Käyttäjä sanoi, että päivämäärä oli väärä. Tämä on todiste epäonnistumisesta, mutta se ei riitä oppimiseen.

Lokimerkintä ei määrittele vastakkaista tapausta. Pitäisikö agentin pyytää vahvistusta? Pitäisikö se johtaa päivämäärän aiemmasta kontekstista? Pitäisikö se kutsua toista työkalua? Pitäisikö se kieltäytyä jatkamasta, kunnes epäselvyydet olivat ratkaistu? Ihminen saattaa tietää vastauksen lukiessaan jäljityksen, mutta järjestelmä ei saa tätä rakennetta ilmaiseksi.

Jatkuva oppiminen vaatii, että raaka epäonnistuminen muutetaan joksikin, jota voidaan toistaa. Se tarkoittaa tehtävää, jota agentti voi kohdata uudelleen, käyttäjää tai simulaattoria, joka luo relevantin mallin, työkaluja, joita agentti voi kutsua, ja arvioijoita, jotka määrittävät menestyksen. Arvioija voi tarkistaa lopputuloksen, työkalukutsut, käytännön rajat, viiveen, kustannukset tai kaikki edellä mainitut.

Tämä on vähemmän näkyvä osa työtä, mutta se on se osa, joka tekee parantamisen todelliseksi. Kun epäonnistuminen muuttuu toistettavaksi ympäristöksi, voidaan asettaa konkreettinen kysymys: korjasiko ehdotettu muutos todella käyttäytymistä?

Ilman tätä askelta tiimit ovat pääasiassa korjaamassa muistin perusteella.

David Silver ja Richard Sutton ovat kuvailleet tulevaa kokemuksen aikaa, jossa agentit oppivat enemmän vuorovaikutuksesta maailman kanssa kuin staattisesta ihmisten datasta. Yritysagenttien osalta tämä visio riippuu siitä, voidaanko sekasortoisen tuotantokokemuksen muuttaa ympäristöksi, jota voidaan toistaa, arvioida ja uudelleen käyttää.

Kokemus yksinään ei riitä. Se on tehtävä testattavaksi.

Regressio on piilevä kustannus

Vaikka epäonnistuminen muuttuu testattavaksi, haasteellisin osa on edelleen: korjata se ilman, että jotain muuta rikkoontuu.

Kukaan, joka on ylläpitänyt monimutkaista agenttia, on nähnyt tämän mallin. Lisätään ohje, jotta agentti eskaloituu aggressiivisia hyvityspyynnöksiä. Nyt se eskaloituu myös tavanomaisia hyvityksiä, jotka pitäisi käsitellä nopeasti. Vähennetään työkalukutsuja yhdessä työnkulussa. Nyt toisessa työnkulussa ohitetaan vaadittu tarkistus. Korjataan vanha muisti. Nyt agentti yleistää korjauksen toiseen tuotelinjaan.

Jokainen korjaus on järkevä paikallisesti. Järjestelmä kuitenkin kulkeutuu globaalisti.

Tämä on agenttien versio katastrofaalisesta unohtamisesta. Neuroverkoissa tämä ilmiö viittaa yleensä uuden koulutuksen ylikirjoittamiseen vanhoja kykyjä. Agenttien tapauksessa epäonnistuminen on laajempi ja usein vaikeampi havaita. Se ilmenee ei puhdas mitattavissa metrikkana koulutuskaaviossa, vaan käyttäjän sanomana: “Tämä toimi aikaisemmin”.

Tämä on syynä, miksi regressio-ohjaus ei voi olla lopullinen tarkastusvaihe. Se on oltava itse oppimis silmukassa.

Tavoitteena ei ole ainoastaan maksimoida suorituskykyä uusimmassa epäonnistumisessa. Tavoitteena on parantaa uutta tapausta ja säilyttää vanhat tapaukset. Jokainen toimiva korjaus on osa agentin kasvavaa muistia siitä, mitä on säilyttävä toimivana. Käytännössä tämä tarkoittaa, että vanhat epäonnistumiset muuttuvat regressiotesteiksi. Agentin historia muuttuu rajoitteeksi, ei pelkästään arkistoksi.

Tässä jatkuva oppiminen muuttuu enemmän vakavaksi ohjelmistosuunnittelukokemukseksi kuin kehoteviritykseksi. Muutos on hyvä, koska se parantaa mitattua käyttäytymistä eikä regressoi käyttäytymistä, jonka järjestelmä on jo ansainnut.

Mikä jatkuva oppiminen käytännössä vaatii

Tuotantovalmiin jatkuva oppimisen silmukkaan tarvitaan neljä ominaisuutta.

Ensinnäkin, epäonnistumiset on muutettava toistettaviksi. Yksittäinen epäonnistuminen on anekdootti. Toistettava, arvioitu ympäristö on testi. Kunnes agentti voi kohdata saman mallin uudelleen, kukaan ei voi todistaa, että korjaus toimi.

Toiseksi, diagnosoinnin on oltava holistinen. Korjaus voi kuulua malliin, mutta se voi kuulua myös muistiin, kehoteeseen, työkaluun, työnkulkuun tai muistiin. Paras korjaus on usein pienin kestävä muutos, joka selittää epäonnistumisen.

Kolmanneksi, oppimisen on oltava elinikäinen. Agentin ei pitäisi parantaa tällä viikolla siten, että se hiljaisesti kumoaa edellisen viikon kovasti ansaitun käyttäytymisen. Aiemmat menestykset on muutettava rajoitteiksi optimoinnissa, ei yllätyksiksi käyttöönoton jälkeen.

Neljänneksi, silmukan on oltava tehokas. Jos jokainen parannus vaatii neljännesvuosittaisen uudelleenkoulutusprojektin, järjestelmä ei koskaan pysy tuotannon mukana. Silmukan on yritettävä halpoja korjauksia ensin, eskaloitava ainoastaan tarvittaessa ja pitäminen vahvistus lähellä muutosta.

Tämä ei tarkoita, että agenttien on päivitettävä itseään sokeasti. Se tarkoittaa vastakkaisen. Parannus on muutettava mitattavaksi. Jokaisen muutoksen on oltava testi, ennen ja jälkeen pisteytys ja regressiotarkistus.

Tämä on se, mikä muuttaa jatkuva oppimisen epämääräisestä tavoitteesta insinööritieteeksi.

Agenttien tulevaisuus ei määritty vain suuremmista kontekstien ikkunoista, vahvemmista perusmalleista tai enemmistä työkaluista. Nämä asiat tulevat olemaan tärkeitä. Mutta tärkeämpi kysymys yrityksille on, mitä tapahtuu käyttöönoton jälkeen.

Kun agentti epäonnistuu huomenna, voi järjestelmä muuttaa tämän epäonnistumisen testiksi? Voi se ohjata korjauksen oikeaan kerrokseen? Voi se todistaa, että korjaus auttoi? Voi se todistaa, ettei mitään muuta rikkoutunut?

Jos vastaus on ei, agentti ei ole todella oppimassa tuotannosta. Se kasaantuu riskiä.

Seuraavat agentit tekevät jotain paremmin. Ne tulevat kasvamaan.