Väčšina tímov AI, ktoré sa usilujú zlepšiť výkon agentov, siaha po rovnakých nástrojoch: väčších kontextových oknách, väčšom množstve dokumentov a inteligentnejších príkazoch. Tento článok tvrdí, že takýto inštinkt je úplne nesprávny. Nechýba viac informácií. Chýba riadenie. Dobre navrhnutá riadiaca vrstva odlišuje agenta fungujúceho v ukážke od agenta fungujúceho v produkcii.
Väčšia pamäť, viac dokumentov ani dlhšie kontextové okno neurobia agenta AI inteligentnejším, iba pomalším a drahším. Skutočné zlepšenie prichádza, keď sa agent naučí vybrať si, čo a kedy potrebuje, namiesto toho, aby naraz spracoval všetko.
Spoľahlivosť vychádza zo slučky, nie z modelu. Rozdiel medzi agentom, ktorý zaujme v ukážke, a agentom, ktorý obstojí v produkcii, nespočíva v kvalite AI, ale v tom, či systém kontroluje vlastnú prácu. Agenti, ktorí v každom kroku plánujú, konajú, pozorujú a overujú, zachytia vlastné chyby namiesto toho, aby sebavedomo poskytovali nesprávne výsledky.
Väčšina dnešných agentov AI sú v podstate chatboty s krokmi navyše. Nemajú mechanizmus, ktorý by im povedal, či postupujú správne, kedy skončiť alebo kedy skúsiť iný prístup. Až vhodná riadiaca vrstva – jasné kritériá úspechu, štruktúrovaný stav a validačné kontroly – zmení objekt podobný agentovi na niečo, čomu môžete skutočne dôverovať.
Čo ste mali včera na obed?
Pravdepodobne ste si neprehrávali každú spomienku, až kým ste nenarazili na „včera + obed“. Preskočili ste priamo do časti skúseností, kde sa tieto pojmy nachádzajú. Je to užitočný mentálny model na tvorbu agentov:
Obrovské kontextové okno nie je pamäť.
Hromada načítaných dokumentov nie je porozumenie.
Dlhé reťazenie myšlienok nie je spoľahlivosť.
To sú iba prísady. To, vďaka čomu agent pôsobí ako agent, je však rovnaké ako to, čo vášmu mozgu bráni hrubou silou prehľadávať celú životnú históriu: riadenie.
Nedávna štúdia Agentic Reasoning for Large Language Models výborne zhrnula (a pomenovala) posun, ktorý mnohí z nás vnímame pri tvorbe systémov: od uvažovania vnútri modelu k uvažovaniu prostredníctvom interakcie. Tento príspevok nie je zhrnutím danej práce. Je pokusom pretaviť tento posun do praktického návrhu systému:
Ak vytvárate agentov ako chatboty s nástrojmi, budú naďalej zlyhávať ako chatboty, len ich chyby budú drahšie.
Istý čas bol náš štandardný recept na „inteligentnejší model“ v zásade takýto: lepšie príkazy, reťazenie myšlienok, sebakonzistentnosť či zlepšenia založené na vzorkovaní a možno aj trochu vyhľadávania.
ReAct bol zlomovým momentom, pretože vďaka nemu pôsobila sekvencia „myšlienka → akcia → pozorovanie“ prirodzene. Všimnite si však implicitné obmedzenie: veľká časť z toho stále končí ako „jednopríkladová inferencia, len s väčším počtom tokenov“. Štúdia to formuluje presnejšie: agentné uvažovanie zdôrazňuje škálovanie interakcie počas testovania – mení inferenciu na iteratívny proces, v ktorom zostávajú model, pamäť aj prostredie súčasťou slučky.
Ak ste vytvorili (alebo používali) agentov, ktorí v ukážkach pôsobia pôsobivo, ale v reálnych pracovných postupoch sú krehkí, toto je pre vás.
Opíšem vzor, s ktorým sa často stretávam (a ktorého verzie som určite vytvoril aj sám):
Vezmite dobrý chatovací model
Pridajte niekoľko nástrojov (vyhľadávanie, dopyt do databázy, prípadne spúšťanie kódu)
Pridajte RAG
Pridajte systémový príkaz „you are an autonomous agent“
Všetko uzavrite do slučky while, kým sa systém nezastaví alebo nevyprší časový limit
Gratulujeme, máte objekt podobný agentovi. Zvykne však zlyhávať predvídateľnými spôsobmi:
Nafukovanie kontextu: každé pozorovanie sa pripája a príkazy sa menia na archeologické vrstvy.
Tápanie medzi nástrojmi: predvoleným režimom zlyhania je „sebavedomé použitie nesprávneho nástroja“.
Žiadne podmienky ukončenia: pokračuje, pretože môže, nie preto, že by mal.
Žiadna disciplína pri napojení na fakty: nevšimne si, že sa mýli, ak ho k tomu nedonútite.
Pamäť = história chatu: v podstate zapisovanie denníkov vydávané za učenie.
Preto „agenti“ často pôsobia v ukážkach čarovne a v produkcii chaoticky. Potvrdzujú to aj naše skúsenosti s nasadzovaním agentných systémov do produkcie: keď už nehodnotíte model, ale systém, medzi režimy zlyhania patria navigácia, správne používanie nástrojov, orezávanie kontextu a návrh hodnotenia, nielen otázka, či „model odpovedal správne“.
Otázka teda znie: ako má cielený agent vyzerať?
Aby to nebolo také abstraktné, pozrime sa na jednoduchý pracovný postup, ktorý si vie predstaviť väčšina ľudí: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Bežná implementácia, ktorá sa „podobá na agenta“, vyzerá takto:
Okamžite načíta množstvo dokumentov o pravidlách leteckých spoločností a cestovania (aj keď zatiaľ nie sú potrebné).
Zavolá vyhľadávací nástroj, vloží dlhý zoznam výsledkov do príkazu a „jeden vyberie“.
Predčasne rezervuje let bez overenia obmedzení (čas príletu, batožina, sedadlo, pravidlá).
Ak zlyhá, skúsi to znova trochu inak, no bez jasnej predstavy o tom, čo sa zmenilo alebo čo sa naučil.
Problémom nie je, že model nedokáže uvažovať, ale že systém pracovný postup neriadi.
Agentnejšia verzia považuje úlohu za interaktívny proces s explicitným stavom a kontrolami:
PLÁN: zopakovať obmedzenia a uviesť chýbajúce informácie (napr. „ktoré letisko uprednostňujete?“/„môže byť jeden prestup?“).
AKCIA: zavolať vyhľadávanie letov so štruktúrovaným dopytom (rozsah dátumov, obmedzenie času príletu, rozpočet).
POZOROVANIE: uložiť výsledky do kompaktného objektu stavu (5 najlepších možností s cenou, príletom a prestupmi), nie ako obrovský vložený blok.
AKTUALIZÁCIA: ak obmedzenia nie sú splnené, upraviť dopyt (napr. „prílet pred 18:00 je príliš prísny – rozšíriť časové okno alebo zvýšiť rozpočet?“).
OVERENIE: spustiť validátory („prílet < 18:00“, „cena ≤ 900 £“, „v súlade s pravidlami“, „výber sedadla je dostupný“).
KONIEC: až keď rezervačné API vráti potvrdenie a všetky validátory uspejú.
Zmena je nenápadná, ale rozhodujúca. Načítanie je podmienené (nie reflexívne), kontext sa riadi (stav je štruktúrovaný, nie hromadený) a overovanie je súčasťou slučky (nezostáva na používateľovi). Nahraďte „rezerváciu letu“ „vytvorením objednávky“, „vrátením peňazí“, „zmenou produkčnej konfigurácie“ alebo „nasadením PR“ a platí to isté: keď agent dokáže konať, slučka je dôležitejšia než príkaz.
Uvedená štúdia rozdeľuje agentné uvažovanie do troch vrstiev: základnej (plánovanie, používanie nástrojov, vyhľadávanie), samostatne sa rozvíjajúcej (spätná väzba a pamäť) a kolektívnej (koordinácia viacerých agentov).
Hlbšia myšlienka však spočíva v tom, že uvažovanie sa stáva organizačným princípom plánovania, rozhodovania a overovania, nielen vytváraním vierohodného reťazenia myšlienok. Znie to abstraktne, kým si neukážete, čo to mení vo vašej architektúre. Treba si zapamätať tri hlavné body:
Dobrý agent by nemal načítavať informácie automaticky. Načítanie je rozhodnutie, nie reflex.
Praktická pomôcka:
Ak váš systém načítava informácie pri každom ťahu, nevytvorili ste načítavanie, ale daň za kontext.
V praxi sa to objavuje neustále. Pri ladení produkčného incidentu nevkladáte do kontextu všetky denníky; podľa aktuálnej hypotézy rozhodujete, ktoré metriky alebo denníky načítať ako ďalšie. To je „agentné načítavanie“. Konkrétnejší postup vyzerá takto:
Rozhodnúť, či treba načítať informácie
Ak áno: pripraviť dopyt, načítať, prebehnúť a extrahovať
Ak si dôkazy odporujú: načítať znova
Až potom syntetizovať
Práve tu sa „agentné RAG“ začína líšiť od tradičného RAG: načítanie sa stáva zámerným krokom uvažovania, nie predvolenou fázou procesu.
Keď prestanete hodnotiť „model“ a začnete hodnotiť „systém“, sledovanie stavu a trasovanie nadobudnú význam.
Jednou z oblastí, ktoré už odvetvie pomenúva oveľa konkrétnejšie, je pozorovateľnosť pracovných postupov agentov. Napríklad súprava Agents SDK od OpenAI obsahuje vstavané trasovanie a panel Traces, ktorý zaznamenáva behy agentov (generovania, volania nástrojov, odovzdania, ochranné mechanizmy, vlastné udalosti), aby ste mohli krok za krokom ladiť a auditovať, čo sa stalo.
Nie je to len niečo, čo je „dobré mať“. Je to rozdiel medzi systémom, ktorý môžete ladiť, a systémom, ktorý môžete hodnotiť iba podľa pocitu.
Podľa mňa je najpraktickejšou časťou štúdie jej priamy pohľad na spätnú väzbu. Spätnú väzbu delí do troch režimov: reflexívna spätná väzba (vytvoriť → posúdiť → upraviť), parametrická adaptácia (učenie dolaďovaním/RL) a spätná väzba riadená validátorom (opakovať pokus, kým validátor neuspeje).
Väčšina tímov by mala začať spätnou väzbou riadenou validátorom, pretože je síce nudná, ale účinná. Ak dokážete napísať akýkoľvek validátor, ktorý vykonáva jednotkové testy, kontroluje schému, uplatňuje obchodné pravidlá či obmedzenia („bez eskalácie nevracať sumy nad X“) alebo overuje faktickosť („vyžadujú sa citácie“), môžete z nedeterministického výstupu modelu vytvoriť niečo, čomu sa dá skutočne dôverovať.
Jeden z menej zjavných posunov je jednoduchý: vo svete agentov spoľahlivosť často vychádza viac zo slučky než z modelu.
Toto je najjednoduchší disciplinovaný postup v slučke, ktorý podľa mojich skúseností spoľahlivo zlepšuje správanie bez trénovania:
Postupujte po krokoch: Naplánovať → Vykonať → Pozorovať → Aktualizovať,
po každom vykonaní zhrňte pozorovanie do 1 až 3 bodov,
skončite po splnení kritérií úspechu alebo vyčerpaní rozpočtu; vráťte najlepší známy výsledok a zostávajúce neistoty.
Nejde o to, aby bol model rozvláčny. Ide o zrozumiteľnosť systému a vynútenie „kontaktu s realitou“ v každom kroku. Príkladom blízkym každému technikovi je napojenie na fakty v uzavretej slučke na spôsob CI:
Naplánovať: navrhnúť zoznam zmien
Vykonať: spustiť testy/lintovanie
Pozorovať: analyzovať zlyhania
Aktualizovať: opraviť a skúsiť znova
Niekoľko otázok, ktoré zvyknú odhaliť nechtiac vzniknuté návrhy agentov:
„Rozhoduje môj agent, čo má načítať, alebo vždy načítavam všetko?“
Ak sa načítava bezpodmienečne, zaplatíte za to vyššou latenciou, nákladmi, rozriedením kontextu a väčším rizikom nekvalitného vstupu aj výstupu.
„Dokáže môj agent rozpoznať, že sa mýli?“
Ak je jediným signálom spätnej väzby pre vášho agenta podráždený používateľ, robíte RL prostredníctvom ľudského utrpenia. Slučka opakovaných pokusov riadená validátorom je najčistejší spôsob, ako ho konfrontovať s realitou.
„Dá sa do pamäte zapisovať a zlepšuje sa časom?“
Ak vaša „pamäť“ iba pripája históriu chatu, v podstate len zapisujete denníky. Pohľad štúdie na pamäť je dôležitý: pamäť sa stáva dynamicky rastúcim kontextom, ktorý agenti časom zdokonaľujú, nie iba prepisom konverzácie.
Denníky hovoria, čo sa stalo; pamäť hovorí, čo nabudúce urobiť. História chatu je prepis konverzácie. Pamäť je vyvíjajúca sa stratégia určujúca, čo sa oplatí uchovať do budúcnosti.
Praktickým začiatkom je malá tabuľka „získaných poznatkov“, ktorej kľúč tvorí typ úlohy, nástroj a režim zlyhania a hodnotu to, čo fungovalo a čomu sa vyhnúť. Cieľom nie je vytvoriť dokonalý znalostný graf. Cieľom je vytvoriť kumulatívne zlepšovanie správania: pamäť a spätná väzba menia agentov z „pomocníkov bez stavu“ na systémy, ktoré sa časom zlepšujú.
Je lákavé nasadiť na problém viac agentov, no často sa tým znásobí réžia spojená s koordináciou. Dobrý vzor „minimálneho životaschopného tímu“:
Koordinátor: rozkladá úlohy a prideľuje ich
Vykonávateľ: volá nástroje a vykonáva zmeny
Kritik/hodnotiteľ: kontroluje správnosť a riziká
Správca pamäte: zapisuje a triedi poznatky
Ak neviete vysvetliť zodpovednosť každého agenta, viacerých agentov zrejme ešte nepotrebujete.
Ak tento posun paradigmy naozaj prijmeme, zrejme prestaneme vkladať všetko do príkazov, považovať zlyhania za konečné výstupy a hodnotiť agentov ako chatboty. A začneme k agentom pristupovať takí, akí sú: ako k softvérovým systémom, v ktorých jazyk tvorí riadiacu rovinu a spoľahlivosť vychádza zo slučky.
Skôr než pridáte ďalší model, pridajte ďalšiu hodnotiacu slučku. Skôr než načítate všetko, podmieňte načítavanie. Nasaďte jeden validátor skôr než desať. S pamäťou zaobchádzajte ako so strategickými rozhodnutiami, nie ako s databázou. A pri prechode na viacerých agentov začnite dvoma, nie dvadsiatimi. Nie sú to pravidlá, ale vzory, ktoré obstáli v produkcii.