Prieš porą metų dauguma įmonių dar diskutavo, ar verta integruoti ChatGPT tipo pokalbių langelį į klientų aptarnavimo skyrių. Šiandien pokalbis jau kitoks – kalbama apie sistemas, kurios pačios planuoja veiksmus, naudoja įrankius, prisijungia prie duomenų bazių ir atlieka darbus be nuolatinės žmogaus priežiūros. Tai ir yra agentinis AI – ir jis keičia verslo procesus daug giliau, nei atrodo iš pirmo žvilgsnio.
Kuo agentinis AI skiriasi nuo įprasto chatbot’o
Klasikinis kalbos modelis veikia pagal principą „klausimas – atsakymas“. Vartotojas parašo užklausą, modelis sugeneruoja tekstą, ir tuo viskas baigiasi. Agentinis AI eina toliau – jis geba suprasti tikslą, susidėlioti žingsnių planą, iškviesti API ar kitus įrankius, patikrinti gautą rezultatą ir, jei reikia, pakoreguoti savo veiksmus. Kitaip tariant, tai jau ne tiesiog teksto generatorius, o savotiškas skaitmeninis darbuotojas, kuris geba veikti autonomiškai konkrečiose ribose.
Paprastas pavyzdys: jei paprašysite chatbot’o „suplanuok man susitikimą su klientu X“, jis gali tik pasiūlyti tekstą laiškui. Agentinis AI tuo tarpu patikrins kalendorių, ras laisvą langą, parašys ir išsiųs kvietimą, o po susitikimo net sugeneruos santrauką CRM sistemoje. Skirtumas – ne kokybiškesnis tekstas, o gebėjimas realiai veikti aplinkoje.
Kas vyksta po gaubtu: orkestravimas ir įrankiai
Techniškai agentinės sistemos remiasi keliais esminiais komponentais. Pirma, tai pats kalbos modelis (LLM), kuris atlieka „mąstymo“ funkciją – sprendžia, ką daryti toliau. Antra – įrankių rinkinys (angl. tools arba function calling), leidžiantis modeliui kreiptis į išorines sistemas: duomenų bazes, API, dokumentų saugyklas, el. pašto serverius.
Trečias, ir dažnai nepastebimas, elementas – orkestravimo sluoksnis. Būtent jis nusprendžia, kokia seka kviečiami įrankiai, kaip saugoma konteksto atmintis tarp žingsnių, kaip apdorojamos klaidos. Populiarūs sprendimai šioje srityje – LangChain, LlamaIndex, CrewAI, taip pat OpenAI ir Anthropic pateikiami „agent“ SDK. Kai kurios įmonės renkasi kurti savo orkestravimo logiką nuo nulio, ypač jei procesai jautrūs ar reikalauja griežtos audito sekos.
Svarbu suprasti, kad agentinis AI nėra viena „stebuklinga“ technologija – tai architektūrinis sprendimas, sudėtas iš kelių dalių, kurios kartu veikdamos sukuria autonomiją. Būtent todėl diegimas dažnai užtrunka ilgiau, nei tikisi vadovai, žiūrėję demonstracinius vaizdo įrašus internete.
Kur tai realiai naudojama versle
Praktikoje agentinis AI šiandien labiausiai prigijęs ten, kur procesas kartotinis, taisyklinis, bet reikalauja kelių žingsnių ir sprendimų priėmimo tarp jų. Keletas konkrečių pavyzdžių:
- Klientų aptarnavimas – agentas ne tik atsako į klausimus, bet ir tikrina užsakymo statusą sistemoje, inicijuoja grąžinimą, eskaluoja sudėtingus atvejus žmogui su jau paruošta santrauka.
- Finansų ir buhalterijos automatizavimas – sąskaitų faktūrų apdorojimas, duomenų suderinimas su ERP sistema, neatitikimų aptikimas ir pranešimas apie juos.
- Pardavimų kvalifikavimas – agentas patikrina potencialaus kliento duomenis viešuose šaltiniuose, CRM’e, sugeneruoja pirminį įvertinimą ir pasiūlo, kam iš komandos perduoti lygį.
- IT palaikymas – tikettų klasifikavimas, dažniausių problemų sprendimas be žmogaus įsikišimo, serverio būklės stebėjimas ir automatinis reagavimas į incidentus.
- Turinio ir rinkodaros darbai – nuo tyrimo iki juodraščio, publikavimo grafiko sudarymo ir rezultatų analizės vienoje grandinėje.
Įdomu tai, kad didžiausią naudą įmonės gauna ne iš vieno „super agento“, o iš kelių specializuotų agentų, kurie bendradarbiauja tarpusavyje – vienas renka duomenis, kitas analizuoja, trečias priima sprendimą. Tokia architektūra vadinama daugiaagente sistema (multi-agent system), ir ji leidžia lengviau valdyti klaidas, nes kiekvienas agentas atsakingas už siauresnę sritį.
Rizikos, apie kurias niekas nekalba per daug garsiai
Autonomija – dviašmenis kalavijas. Kuo daugiau sprendimų sistema priima pati, tuo didesnė žala, jei ji suklys. Halucinacijos, kurios chatbot’e tėra nekoks atsakymas, agentinėje sistemoje gali virsti realiu veiksmu – neteisingai išsiųstu mokėjimu, ištrintu įrašu, klaidingai suformuota sutartimi.
Dar viena problema – „prompt injection“ atakos, kai piktavalis per įvestą tekstą (pvz., el. laišką ar dokumentą, kurį agentas skaito) bando priversti sistemą atlikti nenumatytus veiksmus. Kadangi agentas turi prieigą prie realių įrankių, tokia ataka gali būti daug pavojingesnė nei paprastas duomenų nutekėjimas.
Todėl atsakingai diegiama agentinė sistema visada turi turėti:
- aiškiai apibrėžtas veikimo ribas (kokius veiksmus agentas gali atlikti be patvirtinimo, o kokius – tik su žmogaus sankcija);
- audito seką – kiekvienas žingsnis turi būti loginamas ir atsekamas;
- „circuit breaker“ mechanizmus – galimybę bet kada sustabdyti agento veiklą;
- testavimą su realistiniais, o ne tik idealiais scenarijais.
Kompanijos, kurios skuba diegti agentinius sprendimus be šių apsaugų, dažniausiai susiduria su incidentais praėjus vos kelioms savaitėms po paleidimo. Ne todėl, kad technologija bloga, o todėl, kad ji naudojama be pakankamos kontrolės sistemos aplink ją.
Kaip pradėti neapsigaunant patys sau
Verslo vadovai dažnai klausia – nuo ko pradėti, jei ligšiol dirbome tik su paprastais automatizavimo įrankiais ar Zapier tipo sprendimais? Realistiškiausias kelias – ne šuolis į pilną autonomiją, o laipsniškas perėjimas.
Pirmas žingsnis – pasirinkti vieną siaurą, gerai suprantamą procesą, kuriame klaidos kaina nedidelė. Tai gali būti, pavyzdžiui, dokumentų kategorizavimas ar pirminis klientų užklausų filtravimas. Antras žingsnis – įdiegti agentą su „human in the loop“ principu, kai kritiniai veiksmai vis dar tvirtinami žmogaus. Tik surinkus pakankamai duomenų apie sistemos tikslumą, verta plėsti autonomijos ribas.
Techniniu požiūriu verta apsvarstyti šiuos dalykus:
- Ar naudoti gatavą platformą (pvz., Microsoft Copilot Studio, OpenAI Agents SDK) ar kurti savo sprendimą – priklauso nuo to, kiek specifinis jūsų procesas ir kiek turite vidinių inžinerinių resursų.
- Kokie duomenys agentui bus prieinami – verta apriboti prieigą pagal principą „minimaliai reikalingo“, o ne suteikti pilną prieigą prie visos sistemos.
- Kaip matuosite sėkmę – be aiškių metrikų (tikslumas, laiko sutaupymas, klaidų dažnis) sunku pagrįsti tolimesnes investicijas.
- Kas atsakingas už priežiūrą – agentinė sistema nėra „diegk ir pamiršk“, jai reikalinga nuolatinė stebėsena, panašiai kaip produkciniam programinės įrangos kodui.
Verta paminėti ir kaštų klausimą – kiekvienas agento žingsnis reiškia papildomą modelio kvietimą, o tai reiškia realius pinigus API sąskaitose. Sudėtingesnės daugiaagentės grandinės gali kainuoti žymiai daugiau, nei atrodo iš pirmo skaičiavimo, todėl verta iš anksto testuoti ekonominį modelį, o ne tik technines galimybes.
Vietoj banalios pabaigos: ką tai reiškia jūsų verslui rytoj
Agentinis AI – ne mados žodis, kurį galima nurašyti kaip laikiną technologinę bangą. Tai realus poslinkis, kaip programinė įranga bendrauja su realiu pasauliu: nebe per fiksuotas taisykles, o per sprendimus priimantį modelį, kuris geba prisitaikyti prie situacijos. Bet kaip ir su kiekviena galinga technologija, čia svarbiau ne kiek greitai ją įsidiegsite, o kiek atsakingai tai padarysite.
Jei jūsų komanda dar tik svarsto pirmuosius žingsnius – pradėkite nuo mažo, gerai apibrėžto proceso, laikykite žmogų kontrolės grandinėje ilgiau, nei atrodo reikalinga, ir nebijokite investuoti į loginimą bei stebėseną – tai atsipirks pirmą kartą, kai sistema pasielgs nenuspėjamai. O tai, tikėkitės, anksčiau ar vėliau nutiks – tokia jau kalbos modelių prigimtis.
Ir paskutinė mintis – nesivaikykite technologijos vien todėl, kad konkurentai apie ją kalba konferencijose. Agentinis AI atneša tikrą vertę tik ten, kur procesas jau šiandien aiškus, pasikartojantis ir turintis matuojamą rezultatą. Jei jūsų procesai chaotiški popieriuje – jie liks chaotiški ir su pačiu protingiausiu agentu prie vairo.
