Enamik agentide paremat jõudlust taotlevaid tehisintellektimeeskondi kasutab samu hoobasid: suuremad kontekstivaated, rohkem dokumente ja nutikamad viibad. Selle artikli väitel on see täiesti vale vaist. Puudu pole mitte rohkem teavet. Puudu on juhtimine. Hästi kavandatud juhtimiskiht eristab demos töötavat agenti tootmiskeskkonnas toimivast agendist.
Suurem mälu, rohkem dokumente või pikem kontekstivaade ei tee tehisintellektiagenti nutikamaks, vaid üksnes aeglasemaks ja kallimaks. Tegelik kasu tuleb sellest, kui õpetada agenti valima, mida ja millal tal vaja on, selle asemel et kõike korraga töödelda.
Töökindlus tuleneb tsüklist, mitte mudelist. Demos muljet avaldavat agenti eristab tootmiskeskkonnas vastupidavast agendist mitte tehisintellekti kvaliteet, vaid see, kas süsteem kontrollib oma tööd. Agendid, kes igal sammul plaanivad, tegutsevad, vaatlevad ja kontrollivad, avastavad oma vead, selle asemel et enesekindlalt eksida.
Enamik praegusi tehisintellektiagente on sisuliselt lisasammudega vestlusrobotid: neil puudub mehhanism, mis ütleks, kas nad liiguvad õigel teel, millal lõpetada või millal proovida teistsugust lähenemist. Korralik juhtimiskiht – selged edukriteeriumid, struktureeritud olek ja valideerimiskontrollid – muudab agendilaadse objekti millekski, mida saab päriselt usaldada.
Mida sa eile lõunaks sõid?
Tõenäoliselt ei kerinud te läbi kõiki oma mälestusi, kuni jõudsite kombinatsioonini „eilne + lõuna“. Läksite otse oma kogemuste selle osa juurde, kus need mõisted asuvad. See on agentide loomisel kasulik mõttemudel:
Hiiglaslik kontekstivaade pole mälu.
Hunnik hangitud dokumente pole mõistmine.
Pikk mõttekäik pole töökindlus.
Need on koostisosad. Kuid agendi muudab agendiks sama asi, tänu millele ei pea teie aju jõuga kogu elulugu läbi töötama: juhtimine.
Hiljutine ülevaade „Agentic Reasoning for Large Language Models“ võttis hästi kokku ja andis nime muutusele, mida paljud meist on süsteeme luues tajunud: mudeli sees toimuvast arutlusest interaktsiooni kaudu toimuva arutluseni. See postitus pole kõnealuse teadusartikli kokkuvõte. See püüab selle muutuse praktilise süsteemiarhitektuuri keelde panna:
Kui loote agente nagu tööriistadega vestlusroboteid, tabavad neid ikka vestlusrobotite tüüpilised tõrked, ainult et vead lähevad kallimaks.
Pikka aega koosnes meie tavapärane „mudeli nutikamaks muutmise“ käsiraamat sisuliselt parematest viipadest, mõttekäigust, enesejärjepidevusest või valimipõhistest täiustustest ning vahel ka otsingust.
ReAct oli pöördepunkt, sest muutis ahela „mõte → tegevus → vaatlus“ loomulikuks. Pange aga tähele varjatud piirangut: suur osa sellest taandub endiselt „ühe näitega järeldamisele, kuid rohkemate tokenitega“. Ülevaate käsitlus on täpsem: agendipõhine arutlus rõhutab testimisaegse interaktsiooni skaleerimist, muutes järeldamise iteratiivseks protsessiks, mille tsüklis püsivad mudel, mälu ja keskkond.
Kui olete loonud või kasutanud agente, mis demos muljet avaldavad, kuid päris töövoogudes kergesti lagunevad, on see mõeldud teile.
Kirjeldan mustrit, mida olen sageli näinud ja millest olen kindlasti ka ise versioone loonud:
Võta hea vestlusmudel
Lisa mõni tööriist (otsing, andmebaasipäring, võib-olla koodi käivitamine)
Lisa RAG
Lisa süsteemiviip „you are an autonomous agent“
Pane see kõik while-tsüklisse, mis kestab peatumise või ajalõpuni
Palju õnne, teil on nüüd agendilaadne objekt. Kuid see kipub ennustatavatel viisidel ebaõnnestuma:
Konteksti paisumine: iga vaatlus lisatakse konteksti ja viipadest saavad arheoloogilised kihid.
Tööriistadega lahmimine: vaikimisi tõrkeks saab „vale tööriist, aga enesekindlalt“.
Peatumistingimused puuduvad: agent jätkab, sest saab, mitte sellepärast, et peaks.
Teabe kinnitamise kord puudub: agent ei märka oma eksimust, kui teda selleks ei sunnita.
Mälu = vestluse ajalugu: see tähendab sisuliselt logide kirjutamist ja selle õppimiseks nimetamist.
Seepärast mõjuvadki „agendid“ demos sageli maagiliselt, kuid on tootmiskeskkonnas kohmakad. Seda kinnitab ka meie kogemus agendipõhiste süsteemide tootmisse viimisel: kui hindate mudeli asemel süsteemi, hõlmavad tõrked lisaks küsimusele „kas mudel vastas õigesti?“ ka navigeerimist, tööriistade nõuetekohast kasutust, konteksti kärpimist ja hindamise ülesehitust.
Seega tekib küsimus: milline on eesmärgipärane agent?
Et asi oleks vähem abstraktne, vaatame lihtsat töövoogu, mida enamik inimesi oskab ette kujutada: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Levinud „agendilaadne“ teostus näeb välja nii:
Hangib kohe hulga lennufirmade ja reisireeglite dokumente, isegi kui neid pole veel vaja.
Kutsub otsingutööriista, kleebib viipa pika tulemuste loendi ja „valib ühe“.
Broneerib liiga vara, kontrollimata piiranguid, nagu saabumisaeg, pagas, istekoht ja reeglid.
Kui see ebaõnnestub, proovib agent veidi teisiti, kuid tal puudub selge arusaam sellest, mis muutus või mida ta õppis.
Probleem ei seisne selles, et mudel ei suudaks arutleda, vaid selles, et süsteem ei juhi töövoogu.
Agendipõhisem versioon käsitleb ülesannet interaktiivse protsessina, millel on selgelt määratletud olek ja kontrollid:
PLAANI: sõnasta piirangud uuesti ja loetle puuduv teave (nt „millist lennujaama eelistate?“ või „kas üks vahemaandumine sobib?“).
TEGUTSE: käivita lennuotsing struktureeritud päringuga (kuupäevavahemik, saabumisaja piirang, eelarve).
VAATLE: salvesta tulemused kompaktsesse olekuobjekti (viis parimat kandidaati koos hinna, saabumisaja ja vahemaandumistega), mitte tohutu kleebitud tekstiplokina.
UUENDA: täpsusta päringut, kui piirangud pole täidetud (nt „saabumine enne kella 18 on liiga range – kas laiendada ajavahemikku või suurendada eelarvet?“).
KONTROLLI: käivita validaatorid („saabumine < 18.00“, „hind ≤ 900 £“, „vastab reeglitele“, „istekohta saab valida“).
LÕPETA: alles siis, kui broneerimise API tagastab kinnituse ja kõik validaatorid läbivad testi.
Muutus on peen, kuid otsustav. Andmete hankimine on tingimuslik, mitte refleks; konteksti hallatakse ehk olek on struktureeritud, mitte kuhjatud; ja kontrollimine kuulub tsüklisse, mitte ei jää kasutaja ülesandeks. Asendage „lennu broneerimine“ näiteks „ostutellimuse loomise“, „tagasimakse tegemise“, „tootmiskeskkonna konfiguratsiooni muutmise“ või „PR-i avaldamisega“ ning lugu on sama: kui agent saab tegutseda, on tsükkel viibast olulisem.
Eespool mainitud ülevaade jagab agendipõhise arutluse kolmeks kihiks: aluskiht (plaanimine, tööriistade kasutamine ja otsing), ise arenev kiht (tagasiside ja mälu) ning kollektiivne kiht (mitme agendi koostöö).
Sügavam mõte on aga see, et arutlusest saab plaanimise, otsustamise ja kontrollimise korraldav põhimõte, mitte pelgalt usutava mõttekäigu genereerimise vahend. See kõlab abstraktselt, kuni seostate selle oma arhitektuuris toimuvate muudatustega. Meeles tasub pidada kolme põhipunkti:
Hea agent ei tohiks lähtuda põhimõttest „hangi alati“. Andmete hankimine on otsus, mitte refleks.
Praktiline rusikareegel:
Kui teie süsteem hangib andmeid igal sammul, pole te loonud andmehankemehhanismi, vaid kontekstimaksu.
Päris töös kohtab seda pidevalt. Tootmiskeskkonna intsidendi silumisel ei paisata konteksti kõiki logisid, vaid otsustatakse praeguse hüpoteesi põhjal, millised mõõdikud või logid järgmisena hankida. See on „agendipõhine andmehange“. Konkreetsem muster on järgmine:
Otsusta, kas pead andmeid hankima
Kui jah, koosta päring, hangi andmed, vaata need üle ja eralda vajalik
Kui tõendid on vastuolulised, hangi lisaandmeid
Alles seejärel tee kokkuvõte
Siin hakkab ka „agendipõhine RAG“ tavapärasest RAG-ist erinema: andmete hankimisest saab teadlik arutlussamm, mitte konveieri vaikimisi etapp.
Niipea kui lõpetate „mudeli“ hindamise ja hakkate hindama „süsteemi“, muutuvad oleku jälgimine ja toimingute logimine oluliseks.
Valdkonnas räägitakse nüüd palju selgemalt agentide töövoogude jälgitavusest. Näiteks sisaldab OpenAI Agents SDK sisseehitatud jälgimist ja juhtpaneeli Traces, mis salvestab agentide käitused (genereerimised, tööriistakutsed, üleandmised, kaitsepiirded ja kohandatud sündmused), et saaksite toimunut samm-sammult siluda ja auditeerida.
See pole lihtsalt „hea lisavõimalus“. Sellest sõltub, kas süsteemi saab siluda või üksnes kõhutunde järgi hinnata.
Minu arvates on ülevaate kõige praktilisem osa selle otsekohene käsitlus tagasisidest. Tagasiside jagatakse kolmeks: reflektiivne tagasiside (genereeri → kritiseeri → paranda), parameetriline kohandamine (õppimine peenhäälestuse või stiimulõppe kaudu) ja validaatoripõhine tagasiside (proovi uuesti, kuni validaator testi läbib).
Enamik meeskondi peaks alustama validaatoripõhisest tagasisidest, sest see on igav, kuid tõhus. Kui suudate kirjutada kas või ühe validaatori, mis teeb ühikteste, kontrollib skeemi, rakendab ärireegleid või piiranguid („üle X-i ulatuvaid tagasimakseid ei tehta ilma eskaleerimiseta“) või kontrollib faktilisust („viited on kohustuslikud“), saate mittedeterministliku mudeli väljundi muuta millekski, mida võib päriselt usaldada.
Üks siinseid „tundmatuid tundmatuid“ on lihtne: agentide maailmas tuleneb töökindlus sageli rohkem tsüklist kui mudelist.
See on lihtsaim tsükliline tööviis, mis on minu kogemuse põhjal käitumist ilma treenimiseta järjepidevalt parandanud:
Tegutse sammhaaval: plaani → tegutse → vaatle → uuenda.
Pärast iga toimingut võta vaatlus 1–3 punktiga kokku.
Lõpeta, kui edukriteeriumid on täidetud või eelarve ammendatud; tagasta parim teadaolev tulemus ja allesjäänud ebakindlused.
Eesmärk pole panna mudelit pikalt rääkima. Eesmärk on muuta süsteem arusaadavaks ja sundida seda igal sammul reaalsusega kontakti looma. Inseneridele hästi tuttav näide on CI-laadne suletud tsükliga teabe kinnitamine:
Plaani: paku välja muudatuste loend
Tegutse: käivita testid ja lintimine
Vaatle: analüüsi tõrkeid
Uuenda: paranda ja proovi uuesti
Mõned küsimused, mis kipuvad kogemata loodud agentide ülesehitust paljastama:
„Kas minu agent otsustab, mida hankida, või hangin ma alati?“
Kui andmeid hangitakse tingimusteta, maksate selle eest suurema latentsuse ja kulu, konteksti hajumise ning suurema „prügi sisse, prügi välja“ riskiga.
„Kas minu agent suudab märgata, et ta eksib?“
Kui teie agent saab tagasisidet üksnes kasutaja ärritumisest, teete stiimulõpet inimese kannatuste arvelt. Validaatoripõhine kordustsükkel on kõige selgem viis agenti reaalsusega vastamisi panna.
„Kas mällu saab kirjutada ja kas see paraneb aja jooksul?“
Kui teie „mälu“ üksnes täiendab vestluse ajalugu, kirjutate sisuliselt logisid. Ülevaate käsitlus mälust on oluline: mälust saab dünaamiliselt kasvav kontekst, mida agendid aja jooksul täiustavad, mitte lihtsalt vestluse üleskirjutus.
Logid ütlevad, mis juhtus; mälu ütleb, mida järgmisel korral teha. Vestluse ajalugu on üleskirjutus. Mälu on arenev poliitika selle kohta, mida tasub tulevikuks säilitada.
Praktiline algus on väike „saadud õppetundide“ tabel, mille võtmeks on ülesande tüüp, tööriist ja tõrke laad ning väärtuseks toimiv lahendus ja see, mida vältida. Eesmärk pole luua täiuslikku teadmiste graafi. Eesmärk on luua kumulatiivselt paranev käitumine: mälu ja tagasiside muudavad agendid „olekuta abilistest“ süsteemideks, mis aja jooksul täiustuvad.
Kiusatus on saata probleemi lahendama rohkem agente, kuid sageli kasvatab see koordineerimisega seotud lisatööd. Hea „minimaalse toimiva meeskonna“ muster:
Koordinaator: tükeldab ja määrab ülesanded
Täitja: kutsub tööriistu ja teeb muudatusi
Kriitik/hindaja: kontrollib õigsust ja riske
Mälu haldur: talletab ja korrastab õppetunde
Kui te ei oska selgitada, mille eest iga agent vastutab, pole teil tõenäoliselt veel mitut agenti vaja.
Kui me seda paradigmamuutust tõesti usume, lõpetame tõenäoliselt kõige viipadesse toppimise, tõrgete lõpptulemusena käsitlemise ja agentide hindamise vestlusrobotitena. Selle asemel hakkame käsitlema agente sellena, mis nad on: tarkvarasüsteemid, kus keel toimib juhtimiskihina ja töökindlus tuleneb tsüklist.
Enne järgmise mudeli lisamist lisage veel üks hindamistsükkel. Enne kõige hankimist muutke andmehange tingimuslikuks. Võtke kasutusele üks validaator, enne kui võtate kasutusele kümme. Käsitlege mälu poliitiliste otsuste, mitte andmebaasina. Ja mitme agendi kasutuselevõtul alustage kahest, mitte kahekümnest agendist. Need pole reeglid, vaid mustrid, mis on tootmiskeskkonnas vastu pidanud.