Siekdamos pagerinti agentų veikimą, dauguma DI komandų renkasi tuos pačius svertus: didesnius konteksto langus, daugiau dokumentų ir išmanesnes užklausas. Šiame straipsnyje teigiama, kad toks instinktas iš esmės klaidingas. Trūksta ne daugiau informacijos. Trūksta valdymo. Gerai suprojektuotas valdymo sluoksnis skiria agentą, veikiantį demonstracijoje, nuo veikiančio realioje aplinkoje.
Didesnė atmintis, daugiau dokumentų ar ilgesnis konteksto langas DI agento nepadaro išmanesnio – tik lėtesnį ir brangesnį. Tikroji nauda atsiranda išmokius agentą pasirinkti, ko ir kada jam reikia, užuot viską naudojus iš karto.
Patikimumą lemia ciklas, o ne modelis. Agentą, kuris stebina demonstracijoje, nuo patikimai veikiančio realioje aplinkoje skiria ne DI kokybė, o tai, ar sistema tikrina savo darbą. Kiekviename žingsnyje planuojantys, veikiantys, stebintys ir tikrinantys agentai patys aptinka savo klaidas, užuot užtikrintai klydę.
Dauguma dabartinių DI agentų iš esmės yra pokalbių robotai su papildomais veiksmais – jie neturi mechanizmo, kuris leistų suprasti, ar juda tinkama kryptimi, kada sustoti ar kada išbandyti kitą būdą. Tinkamas valdymo sluoksnis – aiškūs sėkmės kriterijai, struktūruota būsena ir patvirtinimo patikros – agentą primenantį objektą paverčia tuo, kuo iš tiesų galima pasitikėti.
Ką vakar valgėte pietums?
Tikriausiai neperžiūrėjote visų savo prisiminimų, kol radote „vakar + pietūs“. Iš karto perėjote prie tos patirties dalies, kurioje glūdi šios sąvokos. Tai naudingas mentalinis agentų kūrimo modelis:
Milžiniškas konteksto langas nėra atmintis.
Krūva gautų dokumentų nėra supratimas.
Ilga minčių grandinė nėra patikimumas.
Tai tik sudedamosios dalys. Tačiau agentui agento savybių suteikia tas pats dalykas, dėl kurio smegenys neperžiūri visos jūsų gyvenimo istorijos: valdymas.
Naujausioje apžvalgoje „Agentic Reasoning for Large Language Models“ puikiai apibendrintas (ir įvardytas) daugelio kuriant sistemas jaučiamas pokytis: nuo protavimo modelio viduje prie protavimo sąveikaujant. Šis įrašas nėra to straipsnio santrauka. Tai bandymas šį pokytį paversti praktiniais sistemų projektavimo principais:
Jei agentus kursite kaip pokalbių robotus su įrankiais, ir toliau susidursite su pokalbių robotų klaidomis – tik jos kainuos brangiau.
Kurį laiką mūsų įprastas būdas „padaryti modelį išmanesnį“ iš esmės buvo toks: geresnės užklausos, minčių grandinė, savęs suderinamumas ar atranka pagrįsti patobulinimai ir galbūt paieška.
„ReAct“ tapo lūžio tašku, nes seka „mintis → veiksmas → stebėjimas“ tapo natūrali. Tačiau atkreipkite dėmesį į numanomą apribojimą: dažnai visa tai vis tiek tėra „išvedimas naudojant vieną pavyzdį, tik su daugiau leksemų“. Apžvalgoje formuluojama tiksliau: agentinis protavimas pabrėžia sąveikos vykdymo metu mastelio didinimą – išvedimas paverčiamas kartotiniu procesu, kurio cikle nuolat lieka modelis, atmintis ir aplinka.
Jei kūrėte (ar naudojote) agentus, kurie įspūdingai atrodo demonstracijose, bet yra nepatikimi realiuose darbo procesuose, tai skirta jums.
Apibūdinsiu dažnai matytą modelį (ir tikrai paties kurtus jo variantus):
Paimkite gerą pokalbių modelį
Pridėkite kelis įrankius (paiešką, DB užklausas, galbūt kodo vykdymą)
Pridėkite RAG
Pridėkite sistemos užklausą “you are an autonomous agent”
Viską vykdykite „while“ cikle, kol sustos arba baigsis skirtasis laikas
Sveikiname, turite agentą primenantį objektą. Tačiau jis paprastai nuspėjamai klysta:
Konteksto išsipūtimas: kiekvienas stebėjimo rezultatas pridedamas, todėl užklausos tampa archeologiniais sluoksniais.
Chaotiškas įrankių naudojimas: numatytąja klaida tampa „užtikrintai pasirinktas netinkamas įrankis“.
Nėra sustojimo sąlygų: jis tęsia darbą todėl, kad gali, o ne todėl, kad turėtų.
Nėra faktinio pagrindimo tvarkos: jis nepastebi, kad klysta, jei nepriverčiate to padaryti.
Atmintis = pokalbių istorija: tai iš esmės reiškia rašyti žurnalus ir vadinti tai mokymusi.
Todėl „agentai“ demonstracijose dažnai atrodo stebuklingi, o realioje aplinkoje – chaotiški. Mūsų patirtis diegiant agentines sistemas realioje aplinkoje tai patvirtina: kai vertinate jau ne modelį, o sistemą, klaidos apima navigaciją, tvarkingą įrankių naudojimą, konteksto mažinimą ir vertinimo projektavimą, o ne vien klausimą „ar modelis atsakė teisingai“.
Taigi kyla klausimas: koks yra tikslinis agentas?
Kad būtų mažiau abstraktu, štai paprastas daugumai lengvai įsivaizduojamas darbo procesas: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Įprastas agentą primenantis sprendimas atrodo taip:
Iš karto gauna daugybę oro linijų ir kelionių taisyklių dokumentų (net jei jų dar nereikia).
Iškviečia paieškos įrankį, į užklausą įklijuoja ilgą rezultatų sąrašą ir „pasirenka vieną“.
Užsako per anksti, nepatikrinęs apribojimų (atvykimo laiko, bagažo, vietos ar taisyklių).
Jei nepavyksta, bando dar kartą šiek tiek kitaip, tačiau aiškiai nesupranta, kas pasikeitė ar ko išmoko.
Problema ne ta, kad modelis nemoka protauti, o ta, kad sistema nevaldo darbo eigos.
Agentinis variantas užduotį laiko interaktyviu procesu, turinčiu aiškią būseną ir patikras:
PLANUOTI: pakartoti apribojimus ir išvardyti trūkstamą informaciją (pvz., „kuriam oro uostui teikiate pirmenybę?“ arba „ar tinka vienas persėdimas?“).
VEIKTI: iškviesti skrydžių paiešką pateikiant struktūruotą užklausą (datų intervalą, atvykimo apribojimą, biudžetą).
STEBĖTI: išsaugoti rezultatus kompaktiškame būsenos objekte (5 geriausius variantus su kaina, atvykimo laiku ir persėdimais), o ne kaip didžiulį įklijuotą teksto bloką.
ATNAUJINTI: patikslinti užklausą, jei apribojimai netenkinami (pvz., „atvykti iki 18 val. per griežta – išplėsti laiko intervalą ar padidinti biudžetą?“).
PATIKRINTI: paleisti tikrintuvus („atvykimas < 18:00“, „kaina ≤ 900 GBP“, „atitinka taisykles“, „galima pasirinkti vietą“).
SUSTOTI: tik kai užsakymo API pateikia patvirtinimą ir visi tikrintuvai patvirtina rezultatą.
Pokytis subtilus, bet esminis. Duomenys gaunami tik prireikus, kontekstas valdomas (būsena struktūruojama, o ne kaupiama), o tikrinimas įtrauktas į ciklą (nepaliekamas naudotojui). Pakeiskite „skrydžio užsakymą“ į „pirkimo užsakymo kūrimą“, „pinigų grąžinimą“, „darbinės aplinkos konfigūracijos keitimą“ ar „PR pateikimą“ ir principas liks tas pats: kai agentas gali veikti, ciklas tampa svarbesnis už užklausą.
Minėtoje apžvalgoje agentinis protavimas skirstomas į tris sluoksnius: pagrindinį (planavimas, įrankių naudojimas, paieška), savarankiškai tobulėjantį (grįžtamasis ryšys ir atmintis) bei kolektyvinį (kelių agentų koordinavimas).
Tačiau gilesnė mintis tokia: protavimas tampa planavimo, sprendimų priėmimo ir tikrinimo pagrindu, o ne vien būdu generuoti įtikinamą minčių grandinę. Tai skamba abstrakčiai, kol nesusiejate su architektūros pokyčiais. Svarbu prisiminti tris pagrindinius dalykus:
Geras agentas neturėtų duomenų gavimo laikyti veiksmu, kurį reikia atlikti visada. Tai sprendimas, o ne refleksas.
Štai praktiška taisyklė:
Jei sistema gauna duomenis kiekviename žingsnyje, sukūrėte ne duomenų gavimo mechanizmą, o konteksto mokestį.
Praktiniame darbe tai pasitaiko nuolat. Derindami darbinės aplinkos incidentą į kontekstą nesuverčiate visų žurnalų – remdamiesi dabartine hipoteze nusprendžiate, kokius rodiklius ar žurnalus gauti toliau. Tai – „agentinis duomenų gavimas“. Štai konkretesnis modelis:
Nuspręsti, ar reikia gauti duomenų
Jei taip: parengti užklausą, gauti, peržvelgti ir išskirti
Jei įrodymai prieštarauja vieni kitiems: gauti dar kartą
Tik tada apibendrinti
Čia „agentinis RAG“ pradeda skirtis nuo tradicinio RAG: duomenų gavimas tampa apgalvotu protavimo žingsniu, o ne numatytuoju duomenų apdorojimo proceso etapu.
Vos nustojate vertinti „modelį“ ir pradedate vertinti „sistemą“, būsenos stebėjimas ir veiksmų atsekamumas tampa svarbūs.
Viena iš sričių, kurioje sektorius jau pasiekė daugiau aiškumo, yra agentų darbo eigų stebimumas. Pavyzdžiui, „OpenAI Agents SDK“ turi integruotą sekimą ir atsekamumo įrašų skydelį, kuriame registruojami agento vykdymai (generavimai, įrankių iškvietimai, perdavimai, apsaugos priemonės, pasirinktiniai įvykiai), kad galėtumėte žingsnis po žingsnio derinti ir audituoti tai, kas įvyko.
Tai nėra tik „pravartu turėti“. Būtent tuo sistema, kurią galite derinti, skiriasi nuo sistemos, kurią galite vertinti tik iš nuojautos.
Mano nuomone, praktiškiausia apžvalgos dalis yra tai, kaip tiesiai joje kalbama apie grįžtamąjį ryšį. Grįžtamasis ryšys skirstomas į tris režimus: refleksyvųjį (generuoti → kritikuoti → taisyti), parametrinį pritaikymą (mokytis papildomai derinant arba pasitelkiant RL) ir tikrintuvais grindžiamą grįžtamąjį ryšį (kartoti, kol tikrintuvas patvirtins).
Daugumai komandų verta pradėti nuo tikrintuvais grindžiamo grįžtamojo ryšio, nes jis nuobodus, bet veiksmingas. Jei galite parašyti bet kokį tikrintuvą, kuris atlieka vienetinius testus, tikrina schemą, taiko verslo taisykles ar apribojimus („negrąžinti daugiau nei X be perdavimo aukštesniam lygiui“) arba patvirtina faktinį tikslumą („būtinos citatos“), nedeterministinę modelio išvestį galite paversti tuo, kuo iš tiesų galima pasitikėti.
Vienas iš netikėtų pokyčių čia paprastas: agentų pasaulyje patikimumą dažniau lemia ciklas, o ne modelis.
Štai paprasčiausia mano atrasta ciklo tvarka, kuri patikimai gerina veikimą be mokymo:
Dirbkite etapais: planuokite → veikite → stebėkite → atnaujinkite,
po kiekvieno veiksmo apibendrinkite stebėjimo rezultatus 1–3 punktais,
sustokite, kai pasiekti sėkmės kriterijai arba išnaudotas biudžetas; pateikite geriausią žinomą rezultatą ir likusias abejones.
Tikslas nėra priversti modelį daugžodžiauti. Tikslas – padaryti sistemą suprantamą ir kiekviename žingsnyje priversti ją pasitikrinti tikrovėje. Inžinieriams puikiai pažįstamas pavyzdys – CI principu veikiantis uždarojo ciklo faktinis pagrindimas:
Planuoti: pasiūlyti pakeitimų sąrašą
Veikti: paleisti testus ir statinę analizę
Stebėti: išanalizuoti klaidas
Atnaujinti: pataisyti ir bandyti dar kartą
Keli klausimai, dažnai atskleidžiantys netyčia sukurtus agentų sprendimus:
„Ar mano agentas pasirenka, ką gauti, ar duomenis visada gaunu automatiškai?“
Jei duomenys gaunami besąlygiškai, už tai mokėsite delsa, sąnaudomis, konteksto praskiedimu ir didesne rizika pagal principą „šiukšlės įeina – šiukšlės išeina“.
„Ar mano agentas gali pastebėti, kad klysta?“
Jei vienintelis agento grįžtamojo ryšio signalas yra „naudotojas susierzina“, vykdote pastiprinamąjį mokymąsi žmonių kantrybės sąskaita. Tikrintuvu grindžiamas kartojimo ciklas yra paprasčiausias būdas padėti jam pasitikrinti tikrovėje.
„Ar į atmintį galima rašyti ir ar laikui bėgant ji gerėja?“
Jei jūsų „atmintis“ tik papildo pokalbių istoriją, iš esmės tiesiog rašote žurnalus. Apžvalgoje pateikta atminties samprata svarbi: atmintis tampa dinamiškai augančiu kontekstu, kurį agentai ilgainiui tobulina, o ne vien pokalbio išklotine.
Žurnalai nurodo, kas įvyko, o atmintis – ką daryti kitą kartą. Pokalbių istorija yra išklotinė. Atmintis yra kintanti strategija, nusakanti, ką verta išsaugoti ateičiai.
Pradžiai praktiška turėti nedidelę „išmoktų pamokų“ lentelę, kurios raktą sudaro užduoties tipas, įrankis ir klaidos pobūdis, o reikšmę – kas suveikė ir ko vengti. Tikslas nėra sukurti tobulą žinių grafą. Tikslas – sukurti ilgainiui stiprėjantį veikimą: atmintis ir grįžtamasis ryšys paverčia agentus iš „būsenos neturinčių pagalbininkų“ sistemomis, kurios laikui bėgant gerėja.
Kyla pagunda problemai spręsti pasitelkti daugiau agentų, tačiau tai dažnai tik padidina koordinavimo sąnaudas. Geras „minimalios veiksmingos komandos“ modelis:
Koordinatorius: skaido ir paskirsto užduotis
Vykdytojas: iškviečia įrankius ir atlieka pakeitimus
Kritikas arba vertintojas: tikrina teisingumą ir riziką
Atminties prižiūrėtojas: užrašo ir atrenka pamokas
Jei negalite paaiškinti, už ką atsakingas kiekvienas agentas, tikriausiai kelių agentų jums dar nereikia.
Jei iš tiesų pripažįstame šį paradigmos pokytį, turbūt nustojame viską grūsti į užklausas, klaidas laikyti galutiniais rezultatais ir agentus vertinti kaip pokalbių robotus. Ir pradedame agentus laikyti tuo, kas jie yra: programinės įrangos sistemomis, kuriose kalba yra valdymo lygmuo, o patikimumą užtikrina ciklas.
Prieš pridėdami dar vieną modelį, pridėkite dar vieną vertinimo ciklą. Prieš gaudami visus duomenis, nustatykite tam sąlygas. Pirmiausia išleiskite vieną tikrintuvą, o ne dešimt. Atmintį laikykite strateginių sprendimų rinkiniu, o ne duomenų baze. O pereidami prie kelių agentų pradėkite nuo dviejų, o ne dvidešimties. Tai ne taisyklės, o realią aplinką atlaikę modeliai.