Večina ekip za umetno inteligenco, ki želi izboljšati delovanje agentov, poseže po istih vzvodih: večjih kontekstnih oknih, več dokumentih in pametnejših pozivih. Ta članek zagovarja stališče, da je ta instinkt povsem napačen. Manjkajoča sestavina ni več informacij. Je nadzor. Dobro zasnovana nadzorna plast loči agenta, ki deluje v predstavitvi, od agenta, ki deluje v produkciji.
Večji spomin, več dokumentov ali daljše kontekstno okno agenta UI ne naredijo pametnejšega, temveč le počasnejšega in dražjega. Pravi napredek dosežemo, ko agenta naučimo izbrati, kaj potrebuje in kdaj, namesto da vse porabi naenkrat.
Zanesljivost izhaja iz zanke, ne iz modela. Razlika med agentom, ki navduši v predstavitvi, in takim, ki se obnese v produkciji, ni kakovost UI, temveč to, ali sistem preverja lastno delo. Agenti, ki pri vsakem koraku načrtujejo, ukrepajo, opazujejo in preverjajo, ujamejo lastne napake, namesto da bi se samozavestno motili.
Večina današnjih agentov UI je pravzaprav klepetalnih robotov z dodatnimi koraki: nimajo mehanizma, s katerim bi vedeli, ali so na pravi poti, kdaj naj se ustavijo ali kdaj naj poskusijo drugače. Ustrezna nadzorna plast z jasnimi merili uspeha, strukturiranim stanjem in validacijskimi preverjanji je tisto, kar predmet v obliki agenta spremeni v nekaj, čemur lahko dejansko zaupate.
Kaj ste včeraj jedli za kosilo?
Verjetno niste predvajali vseh svojih spominov, dokler niste zadeli »včeraj + kosilo«. Skočili ste naravnost v del svojih izkušenj, kjer ti pojmi živijo. To je uporaben miselni model za gradnjo agentov:
Ogromno kontekstno okno ni spomin.
Kup pridobljenih dokumentov ni razumevanje.
Dolga veriga sklepanja ni zanesljivost.
To so sestavine. Toda tisto, zaradi česar agent deluje kot agent, je isto, zaradi česar vaši možgani ne preiskujejo celotne življenjske zgodovine z grobo silo: nadzor.
Nedavni pregled Agentic Reasoning for Large Language Models je odlično povzel (in poimenoval) premik, ki smo ga pri gradnji občutili mnogi: od sklepanja znotraj modela k sklepanju skozi interakcijo. Ta objava ni povzetek navedenega članka. Je poskus, da bi ta premik prenesli v praktično zasnovo sistemov:
Če agente gradite kot klepetalne robote z orodji, boste še naprej dobivali značilne napake klepetalnih robotov, le da bodo dražje.
Nekaj časa je bil naš privzeti priročnik za »pametnejši model« v bistvu takšen: boljši pozivi, veriga sklepanja, samodoslednost oziroma izboljšave z vzorčenjem in morda nekaj iskanja.
ReAct je bil prelomnica, ker je vzorec »misel → dejanje → opažanje« z njim postal naraven. Toda upoštevajte implicitno omejitev: veliko tega je še vedno »sklepanje z učenjem iz enega primera, le z več žetoni«. Opredelitev v pregledu je ostrejša: agentsko sklepanje poudarja povečevanje interakcije med izvajanjem, pri čemer sklepanje postane iterativen proces, model, spomin in okolje pa ves čas ostajajo v zanki.
Če ste zgradili (ali uporabljali) agente, ki so v predstavitvah impresivni, v resničnih delovnih tokovih pa krhki, je to za vas.
Naj opišem vzorec, ki sem ga pogosto videl (in njegove različice vsekakor tudi sam gradil):
Vzemite dober klepetalni model
Dodajte nekaj orodij (iskanje, poizvedovanje po zbirki podatkov, morda izvajanje kode)
Dodajte RAG
Dodajte sistemski poziv »ste avtonomen agent«
Vse skupaj zavijte v zanko while, dokler se ne ustavi ali poteče čas
Čestitamo, ustvarili ste predmet v obliki agenta. Vendar praviloma odpove na predvidljive načine:
Napenjanje konteksta: doda se vsako opažanje, zato pozivi postanejo arheološke plasti.
Brezglavo poseganje po orodjih: privzeta napaka postane »samozavestno uporabi napačno orodje«.
Brez pogojev za ustavitev: nadaljuje, ker lahko, ne ker bi moral.
Brez discipline opiranja na dejstva: ne opazi, da se moti, če ga v to ne prisilite.
Spomin = zgodovina klepeta: kar je v bistvu pisanje dnevnikov, ki mu rečemo učenje.
Zato so »agenti« v predstavitvah pogosto videti čarobni, v produkciji pa neurejeni. To potrjujejo tudi naše izkušnje z uvajanjem agentskih sistemov v produkcijo: ko ne ocenjujete več modela, temveč sistem, načini odpovedi vključujejo navigacijo, disciplinirano uporabo orodij, krčenje konteksta in zasnovo vrednotenja, ne le vprašanja »ali je model pravilno odgovoril«.
Vprašanje je torej: kakšen naj bi bil agent?
Da bo manj abstraktno, si oglejmo preprost delovni tok, ki si ga lahko predstavlja večina ljudi: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Običajna izvedba, ki je »videti kot agent«, deluje tako:
Takoj pridobi kopico dokumentov o pravilih letalskih prevoznikov in potovanj (tudi če še niso potrebni).
Pokliče iskalno orodje, v poziv prilepi dolg seznam rezultatov in »izbere enega«.
Prehitro opravi rezervacijo, ne da bi preveril omejitve (čas prihoda, prtljago, sedež in pravila).
Če mu spodleti, poskusi znova na nekoliko drugačen način, vendar brez jasnega razumevanja, kaj se je spremenilo ali česa se je naučil.
Težava ni v tem, da model ne zna sklepati, temveč v tem, da sistem delovnega toka ne nadzoruje.
Bolj agentska različica nalogo obravnava kot interaktiven proces z eksplicitnim stanjem in preverjanji:
NAČRTUJ: ponovi omejitve in navedi manjkajoče podatke (npr. »katero letališče vam bolj ustreza?«/»je en prestop sprejemljiv?«).
UKREPAJ: pokliči iskanje letov s strukturirano poizvedbo (časovno obdobje, omejitev prihoda, proračun).
OPAZUJ: shrani rezultate v zgoščen objekt stanja (pet najboljših možnosti s ceno, prihodom in prestopi), ne v ogromno gmoto prilepljenega besedila.
POSODOBI: če omejitve niso izpolnjene, izboljšaj poizvedbo (npr. »prihod pred 18. uro je preveč omejujoč – naj razširim časovno okno ali zvišam proračun?«).
PREVERI: zaženi validatorje (»prihod < 18:00«, »cena ≤ 900 GBP«, »skladno s pravili«, »izbira sedeža je na voljo«).
USTAVI: šele ko API za rezervacije vrne potrdilo in so vsa preverjanja uspešna.
Sprememba je subtilna, vendar odločilna. Pridobivanje je pogojno (ni refleks), kontekst se upravlja (stanje je strukturirano, ne nakopičeno), preverjanje pa je del zanke (ni prepuščeno uporabniku). »Rezervacijo leta« zamenjajte z »izdelavo naročilnice«, »izdajo vračila«, »spreminjanjem produkcijske konfiguracije« ali »objavo zahtevka za spojitev« in zgodba ostane enaka: ko lahko agent ukrepa, je zanka pomembnejša od poziva.
Zgoraj omenjeni pregled agentsko sklepanje razvršča v tri plasti: temeljno (načrtovanje, uporaba orodij in iskanje), samorazvijajočo se (povratne informacije in spomin) ter kolektivno (usklajevanje več agentov).
Globlji uvid pa je, da sklepanje postane organizacijsko načelo načrtovanja, odločanja in preverjanja, ne le ustvarjanja verjetne verige sklepanja. To zveni abstraktno, dokler ne ugotovite, kaj pomeni za spremembe v arhitekturi. Zapomniti si je treba tri ključne točke:
Dober agent pridobivanja ne bi smel obravnavati kot nekaj, kar je treba »vedno izvesti«. Pridobivanje je odločitev, ne refleks.
Praktično vodilo:
Če vaš sistem pridobiva podatke pri vsakem koraku, niste zgradili pridobivanja, temveč davek na kontekst.
Pri resničnem delu se to dogaja ves čas. Pri odpravljanju produkcijskega incidenta v kontekst ne stresete vseh dnevnikov, temveč se glede na trenutno hipotezo odločite, katere metrike ali dnevnike boste pridobili naslednje. To je »agentsko pridobivanje«. Konkretnejši vzorec je takšen:
Odločite se, ali potrebujete pridobivanje
Če da: sestavite poizvedbo, pridobite podatke, jih preletite in izluščite bistvo
Če si dokazi nasprotujejo: podatke pridobite znova
Šele nato jih povežite v celoto
Tu se začne »agentski RAG« razlikovati od tradicionalnega RAG-a: pridobivanje postane premišljen korak sklepanja, ne privzeta faza cevovoda.
Ko prenehate ocenjevati »model« in začnete ocenjevati »sistem«, postaneta spremljanje stanja in sledenje pomembna.
Panoga je medtem jasneje opredelila tudi opazljivost delovnih tokov agentov. Komplet Agents SDK podjetja OpenAI ima na primer vgrajeno sledenje in nadzorno ploščo Traces, ki beleži izvajanja agentov (generiranja, klice orodij, predaje, varovala in dogodke po meri), da lahko korak za korakom odpravljate napake in preverjate, kaj se je zgodilo.
To ni nekaj, kar je zgolj »lepo imeti«. To je razlika med sistemom, v katerem lahko odpravljate napake, in sistemom, ki ga lahko ocenite le po občutku.
Po mojem mnenju je najbolj praktičen del pregleda neposrednost pri obravnavi povratnih informacij. Povratne informacije deli na tri režime: refleksivne povratne informacije (ustvari → kritiziraj → popravi), parametrično prilagajanje (učenje z dodatnim učenjem/RL) in povratne informacije na podlagi validatorja (ponavljaj, dokler preverjanje ni uspešno).
Večina ekip bi morala začeti s povratnimi informacijami na podlagi validatorja, ker so dolgočasne, a učinkovite. Če lahko napišete kakršen koli validator, ki izvaja teste enot, preverja shemo, uveljavlja poslovna pravila oziroma omejitve (»brez eskalacije ni vračil nad X«) ali preverja dejanskost (»navedba virov je obvezna«), lahko nedeterministični izhod modela spremenite v nekaj, čemur lahko dejansko zaupate.
Eden od premikov med »neznanimi neznankami« je preprost: pri agentih zanesljivost pogosto izhaja bolj iz zanke kot iz modela.
To je najpreprostejša disciplina zanke, za katero sem ugotovil, da brez učenja zanesljivo izboljša vedenje:
Delajte po korakih: načrtuj → ukrepaj → opazuj → posodobi,
po vsakem ukrepu povzemite opažanje v 1–3 alinejah,
ustavite se, ko so merila uspeha izpolnjena ali je proračun porabljen; vrnite najboljši znani rezultat in preostale negotovosti.
Namen ni, da bi bil model gostobeseden. Namen je narediti sistem razumljiv in ga na vsakem koraku prisiliti v »stik z resničnostjo«. Inženirjem zelo domač primer je opiranje na dejstva v zaprti zanki po vzoru CI:
Načrtuj: predlagaj seznam sprememb
Ukrepaj: zaženi teste/preverjanje sloga kode
Opazuj: razčleni napake
Posodobi: popravi in poskusi znova
Nekaj vprašanj, ki navadno razkrijejo nenamerno zasnovo agenta:
»Ali moj agent izbira, kaj naj pridobi, ali podatke vedno pridobim sam?«
Če je pridobivanje brezpogojno, boste plačali z daljšo zakasnitvijo, višjimi stroški, razvodenelim kontekstom in večjim tveganjem, da zaradi slabih vhodnih podatkov dobite slab rezultat.
»Ali lahko moj agent opazi, da se moti?«
Če je edini povratni signal vašega agenta »uporabnik se razjezi«, izvajate RL s človeškim trpljenjem. Zanka ponovnih poskusov na podlagi validatorja je najčistejši način, da agent preveri resničnost.
»Ali je mogoče v spomin zapisovati in ali se ta sčasoma izboljšuje?«
Če vaš »spomin« samo dodaja zgodovino klepeta, v resnici pišete dnevnike. Pomemben je način, kako pregled opredeli spomin: ta postane dinamično rastoč kontekst, ki ga agenti sčasoma izpopolnjujejo, in ne zgolj prepis.
Dnevniki povedo, kaj se je zgodilo, spomin pa, kaj storiti naslednjič. Zgodovina klepeta je prepis. Spomin je razvijajoča se politika o tem, kaj je vredno ohraniti za prihodnost.
Praktično izhodišče je majhna tabela »pridobljenih spoznanj«, v kateri ključ sestavljajo vrsta naloge, orodje in način odpovedi, vrednost pa opisuje, kaj je delovalo in čemu se je treba izogniti. Namen ni zgraditi popolnega grafa znanja. Namen je ustvariti vedenje, ki se z izkušnjami krepi: spomin in povratne informacije agente iz »pomočnikov brez stanja« spremenijo v sisteme, ki se sčasoma izboljšujejo.
Mikavno je problemu preprosto dodati več agentov, vendar to pogosto pomnoži breme usklajevanja. Dober vzorec »najmanjše izvedljive ekipe«:
Koordinator: razčleni in dodeljuje
Izvajalec: kliče orodja in izvaja spremembe
Kritik/ocenjevalec: preverja pravilnost in tveganje
Skrbnik spomina: zapisuje in ureja spoznanja
Če ne morete pojasniti, za kaj je odgovoren vsak agent, več agentov verjetno še ne potrebujete.
Če ta premik paradigme res sprejmemo, bomo verjetno prenehali vse tlačiti v pozive, napake obravnavati kot končne izhode in agente ocenjevati kot klepetalne robote. Agente bomo začeli obravnavati kot to, kar so: programske sisteme, v katerih je jezik nadzorna ravnina, zanesljivost pa izhaja iz zanke.
Preden dodate še en model, dodajte še eno ocenjevalno zanko. Preden pridobite vse, naj bo pridobivanje pogojno. Preden jih uvedete deset, uvedite en validator. Spomin obravnavajte kot odločitve o pravilih, ne kot zbirko podatkov. Ko preidete na več agentov, začnite z dvema, ne z dvajsetimi. To niso pravila, temveč vzorci, ki so prestali preizkus produkcije.