Agentiniai AI projektai per pastaruosius porą metų tapo tuo, apie ką kalba kone kiekviena technologijų komanda. Idėja atrodo paprasta – vietoj to, kad modelis tik atsakinėtų į klausimus, jis pats planuoja veiksmus, kviečia įrankius, priima sprendimus ir juda link tikslo be nuolatinės žmogaus priežiūros. Skamba puikiai konferencijų skaidrėse, bet realybėje didelė dalis tokių projektų arba miršta pilotinėje stadijoje, arba veikia taip nestabiliai, kad juos tenka uždaryti po kelių mėnesių gamybos. Verta pažiūrėti, kas iš tikrųjų vyksta po gražiais demonstraciniais vaizdo įrašais.
Kai entuziazmas pralenkia architektūrą
Dažniausia klaida – projektas pradedamas nuo įrankio, o ne nuo problemos. Komanda pamato, kad LangChain, CrewAI ar AutoGen leidžia per savaitę surinkti veikiantį prototipą, ir nusprendžia, kad tai pakankamas pagrindas gamybai. Prototipas iš tiesų veikia – kol demonstruojamas kontroliuojamoje aplinkoje su iš anksto paruoštais scenarijais. Realiuose duomenyse, su realiais vartotojais, agentas staiga pradeda elgtis nenuspėjamai.
Problema ta, kad agentinė sistema nėra tas pats, kas paprastas API kvietimas į LLM. Čia atsiranda būsenos valdymas, sprendimų medžiai, klaidų atstatymas, lygiagretūs procesai. Jei architektūra kuriama „kaip nors susidėliosim vėliau“, ta „vėliau“ dažniausiai reiškia perrašymą nuo nulio praėjus trims mėnesiams, kai jau investuota nemaža biudžeto dalis.
Kontekstas dingsta kažkur tarp iteracijų
Vienas dažniausiai nutylimų dalykų – konteksto valdymas ilgose agentų grandinėse. Kai agentas atlieka dešimt ar dvidešimt žingsnių iš eilės, kviesdamas įrankius, gaudamas rezultatus ir priimdamas kitą sprendimą, kontekstinis langas greitai prisipildo šiukšlių. Modelis pradeda „pamiršti“, ką jau bandė, kartoja tuos pačius veiksmus arba ignoruoja ankstesnes instrukcijas.
Komandos dažnai bando spręsti šią problemą tiesiog didindamos konteksto langą arba naudodamos brangesnį modelį su ilgesne atmintimi. Bet tai tik atideda problemą, o ne išsprendžia ją. Tikroji problema – nėra aiškios strategijos, ką laikyti trumpalaikėje atmintyje, ką perkelti į ilgalaikę saugyklą (pavyzdžiui, vektorinę duomenų bazę), o ką tiesiog išmesti. Be tokios strategijos agentas po kelių dešimčių žingsnių tampa panašus į žmogų, kuris pamiršo, ką ką tik pasakė.
Įrankių chaosas ir per didelė autonomija
Kitas dažnas žlugimo scenarijus – agentui suteikiama per daug įrankių ir per daug laisvės juos rinktis. Teoriškai skamba logiškai: kuo daugiau galimybių, tuo lankstesnis sprendimas. Praktiškai gaunasi priešingai – modelis pradeda „bandyti“ įrankius atsitiktine tvarka, nes negali patikimai atskirti, kuris iš dešimties panašių įrankių tinka konkrečiai situacijai.
Yra paprasta taisyklė, kurią daug kas ignoruoja: kiekvienas naujas įrankis eksponentiškai didina galimų klaidų kombinacijų skaičių. Jei agentas turi tris įrankius, klaidų erdvė valdoma. Jei jų dešimt, o dar ir keli agentai kalbasi tarpusavyje – prognozuoti elgesį tampa beveik neįmanoma be griežtos struktūros, kada koks įrankis leidžiamas naudoti.
- Per platus įrankių rinkinys be aiškių apribojimų dažnai reiškia, kad agentas „bando laimę“ vietoj to, kad rinktųsi apgalvotai.
- Per daug autonomijos kritiniuose žingsniuose (pavyzdžiui, mokėjimų vykdymas ar duomenų trynimas) – tai tiesiausias kelias į incidentą, kuris tampa žinia visai komandai apie „AI eksperimento“ nesėkmę.
- Trūkstant aiškių ribų, kada agentas privalo sustoti ir paklausti žmogaus, sistema arba per daug kištis prašo, arba per daug savarankiškai veikia – abu variantai blogi.
Kai niekas nemato, kas vyksta viduje
Klasikinėse programinės įrangos sistemose logai yra savaime suprantamas dalykas. Agentinėse sistemose stebėjimas dažnai lieka paskutinėje vietoje – kol kažkas sugenda gamyboje ir niekas negali paaiškinti, kodėl agentas nusprendė ištrinti ne tą įrašą ar išsiųsti klaidingą laišką klientui.
Be tinkamo trasavimo (tracing) – kur matomas kiekvienas žingsnis, kiekvienas apsisprendimas, kiekvienas įrankio iškvietimas su įvestimi ir išvestimi – debug procesas virsta spėliojimu. Tai ypač skaudu, kai agentas veikia asinchroniškai arba lygiagrečiai su keliais pogrupiais, nes klaida gali kilti dešimtu žingsniu, o pasireikšti tik trisdešimtu.
Šioje vietoje daug projektų tiesiog sustoja – ne todėl, kad technologija netinkama, o todėl, kad komanda negali įrodyti verslui, jog sistema veikia patikimai. Be matomumo pasitikėjimas nesikuria, o be pasitikėjimo projektas neišeina iš pilotinės stadijos.
Kaštai, kurie išauga tyliai
Agentinės sistemos mėgsta „mąstyti“ ilgai. Kiekvienas papildomas žingsnis, kiekvienas savikritikos ciklas (kai agentas pats tikrina savo atsakymą), kiekvienas pakartotinis bandymas – tai papildomi tokenai, o kartu ir papildomi pinigai. Prototipo stadijoje, kai testuojama dešimt užklausų per dieną, kaštai atrodo nereikšmingi. Perkėlus į gamybą su tūkstančiais užklausų, sąskaita gali išaugti dešimt ar dvidešimt kartų greičiau, nei prognozuota.
Dar blogiau, kai agentas patenka į „begalinę kilpą“ – bando pasiekti tikslą, nepasiekia, bando kitaip, vėl nepasiekia, ir taip be aiškios stabdymo ribos. Be maksimalaus žingsnių skaičiaus, be biudžeto limito užklausai, be timeout logikos – tokia sistema anksčiau ar vėliau sugeneruos sąskaitą, kurios niekas nesitikėjo, arba tiesiog užstrigs ir neduos atsakymo iš viso.
Komandos, kurios nesupranta, ką stato
Yra ir žmogiškas aspektas, kurį lengva nuvertinti. Agentinius projektus dažnai stumia entuziastingi produkto vadovai ar vadovybė, kuri nori „AI transformacijos“ greitai. Inžinerinė komanda gauna neaiškų reikalavimą – „padaryk, kad agentas pats sutvarkytų klientų užklausas“ – be jokios aiškios sėkmės metrikos.
Be aiškaus atsakymo į klausimą „kaip mes žinosime, kad tai veikia gerai“, projektas neišvengiamai suklysta viena iš dviejų krypčių: arba komanda per ilgai tobulina sistemą, bandydama pasiekti neapibrėžtą tobulumą, arba paleidžia per anksti ir susilaukia pasitikėjimo krizės po pirmų rimtų klaidų. Abiem atvejais problema ne technologijoje, o proceso ir lūkesčių valdyme.
Receptas, kuris veikia dažniau nei ne
Jei apibendrinti visą tai, kas žlugdo agentinius projektus, matosi aiškus modelis – dažniausiai problema ne modelio galimybėse, o inžinerinėje drausmėje aplink jį. Keletas praktinių dalykų, kurie realiai padeda:
- Pradėk siaurai. Vienas agentas, du-trys įrankiai, vienas aiškiai apibrėžtas uždavinys. Plėsti visada lengviau, nei apkarpyti sistemą, kuri jau tapo per sudėtinga.
- Investuok į stebėjimą nuo pirmos dienos. Tracing, logų struktūra, galimybė peržiūrėti kiekvieną sprendimą – tai ne prabanga, o būtinybė, be kurios debug tampa neįmanomas.
- Nustatyk aiškias ribas autonomijai. Kritiniai veiksmai (mokėjimai, trynimai, išoriniai pranešimai) turi turėti žmogaus patvirtinimo tašką arba bent griežtą taisyklių sluoksnį virš agento sprendimo.
- Valdyk kontekstą sąmoningai. Nuspręsk iš anksto, kas patenka į trumpalaikę atmintį, kas – į ilgalaikę saugyklą, ir kada senas kontekstas tiesiog turi būti pamirštas.
- Nustatyk kaštų ir žingsnių limitus. Maksimalus iteracijų skaičius, biudžeto riba užklausai, timeout logika – tai apsauga nuo tylių, bet skaudžių sąskaitų.
- Apibrėžk sėkmės metrikas prieš pradedant kodinti. Jei niekas negali pasakyti, kaip atrodo „veikia gerai“, projektas rizikuoja niekada nepasiekti gamybos.
Agentinės sistemos nėra magija ir nėra prakeikimas – jos tiesiog reikalauja kitokio mąstymo nei įprasta programinė įranga. Ten, kur klasikinis kodas elgiasi deterministiškai, agentas elgiasi tikimybiškai, o tai reiškia, kad visa aplinkinė infrastruktūra – stebėjimas, ribos, atstatymo mechanizmai – turi kompensuoti tą netikrumą. Komandos, kurios tai supranta iš pradžių, dažniausiai ir sukuria sistemas, kurios išgyvena ilgiau nei pirmasis demonstracinis pristatymas.
