Įvadas ir naujoji automatizacijos filosofija
Konnichiwa! Sveiki atvykę į
Taigi, jei kada nors įtarėte, kad jūsų išmanusis agentas galbūt yra kvailesnis už akmenų krūvą, arba jei jūs pats bandote diriguoti Maestro taip, kad lėlė nevirstų robotų maištu – pataikėte į tinkamą dojo. Turiu pasakyti, kai „UiPath“ praėjusių metų pabaigoje paskelbė, jog kurs savo agentus, buvau šiek tiek šokiruotas. Mano susijaudinimo lygis (tarkime taip) nebuvo toks, kad „skrenda iki Mėnulio“. Tačiau kai mus pasirinko kaip vienus iš nedaugelio partnerių, gavusių ankstyvą prieigą, natūraliai paleidome kelis savo protingiausius samurajus išbandyti šiuos naujus įrankius – liepėme jiems išmokti, sulaužyti ir atsiskaityti. Turiu pripažinti – esu maloniai (drįsčiau sakyti) nustebintas. Kaip „UiPath“ suprojektavo šiuos agentus ir integravo juos su visa savo platforma – tai išties tvarkinga, ir žodį „tvarkinga“ aš vartoju ne bet kada.
Čia kalbama ne tik apie dar vieno blizgančio įrankio pridėjimą į technologijų dirbtuves. Kalbame apie visą automatikos filosofiją: gerai suteptą mašiną, kurioje dirbtinio intelekto agentai mąsto (jie įneša žmogiško tipo mąstymo ir sprendimo gebėjimų), robotai ir integracijos veikia (jie atlieka užduotis su tuo saldžiu, tiksliu dvejetainiu tikslumu), o „Maestro“ orkestruoja (jis veikia kaip lėlininkas, tampantis už virvelių), o žmonės vadovauja, nes būtent jie priima galutinius sprendimus (juk kažkas turi būti suaugęs kambaryje).
Dirbtinio intelekto agentų kūrimas „UiPath“ (Agent Builder)
Agentinės funkcijos: užklausos, įrankiai ir kontekstas
Pirmiausia pažvelkime į agentus. Geras pavyzdys būtų anti-phishing agentas – tai agentas, kurį galima naudoti įvairiose automatizacijose, jei jos prasideda nuo el. laiško. „UiPath Agent Builder“ aplinkoje rasite laukus, kurių tikėtumėtės kurdami DI agentą: pavadinimą, aprašymą ir ilgą sistemos užklausą (system prompt). Ši sistemos užklausa turi daug informacijos, joje yra daugybė taisyklių, ir ją galite parašyti patys, tačiau taip pat galite pasitelkti generatyvinį DI (GenAI), kad padėtų sukurti gerą užklausą. Įdomu tai, kaip dirbtinis intelektas jau padeda mums programuoti kitus dirbtinius intelektus.
Turime vartotojo užklausą (user prompt), kuri nurodo agentui, kokio tipo įvesties jis gali tikėtis, tačiau tai, kas suteikia jam tikrą „agentinį“ pobūdį, yra įrankiai (tools). Įrankių skyriuje galima prijungti daugybę skirtingų dalykų. Yra veiklų (activities), kurias „UiPath“ jau paruošė – jas galima naudoti jungiantis prie įvairių paslaugų ir programų. Taip pat yra procesai. Bet kurį procesą, kurį esate paskelbę savo Orchestrator, agentas gali iškviesti tiesiogiai. Jei agentui reikia papildomos informacijos, jis gali iškviesti procesą. Procesas bus paleistas, agentas jam perduos parametrus, procesas įvykdys veiksmus ir grąžins duomenis atgal agentui. Iš esmės tai reiškia, kad vartotojas turi daugybę skirtingų įrankių, kuriuos agentas gali naudoti tiek duomenims gauti, tiek duomenims įvesti į sistemas.
Be to, agentas gali iškviesti kitą agentą. Taigi galima sukurti tarsi „inception“ tipo situaciją, kai vienas agentas klausia kito, kuris specializuojasi tam tikroje srityje, ir gauna iš jo atsakymą. Galimybė pridėti įrankius prie DI agento jau savaime yra didelis laimėjimas. Jei jūsų organizacijoje jau turite daugybę skirtingų procesų (didelių ar mažų, prižiūrimų ar neprižiūrimų), juos visus galima prijungti prie agento.
Žinoma, turime ir kontekstus. Tai yra žinios, kurias galite įtraukti į DI įrankį. Įkeliate tam tikrus dokumentus į saugyklos aplanką (storage bucket) savo Orchestrator aplinkoje, o tada galite nustatyti šį aplanką kaip konkretaus agento kontekstą. Tai reiškia, kad agentas žinos informaciją, esančią tuose failuose, todėl veikdamas jis atsižvelgs į šią informaciją.
Sauga ir eskalacijos (žmogus procese)
Toliau turime eskalacijas. Eskalacija iš esmės reiškia, kad galima nustatyti sąlygas, kada agentas neturėtų priimti sprendimo pats, o turėtų paprašyti žmogaus priimti galutinį sprendimą. Pavyzdžiui, anti-phishing agento atveju, jei jis nėra tikras, ar konkretus el. laiškas yra sukčiavimo bandymas, jis tiesiogiai kreipsis į žmogų. Agentas sukurs veiksmą (Action) „Action Center“ aplinkoje, o žmogus operatorius peržiūrės laišką ir nuspręs, ar tai iš tiesų yra sukčiavimo atvejis. Tokiu būdu žmogus įtraukiamas į procesą, o mes išlaikome kontrolę, ką agentai daro.
Iššūkiai ir agentų testavimo metodologija
Kaip ir dažnai būna su agentais, juos galima testuoti kūrimo metu. Turime langą, kuriame galima paleisti užklausą. Jei, pavyzdžiui, įvesiu el. laiško turinį „Aš esu Etiopijos princas ir noriu atsiųsti jums 1 milijoną dolerių“, agentas jį išanalizuos ir pasakys, kad tai iš tiesų yra sukčiavimo (phishing) laiškas, o išvestyje pateiks kintamąjį, rodantį, jog šio konkretaus el. laiško toliau apdoroti nereikėtų.
Agentų užklausų rašymas yra gana paprastas ir greitas procesas. Didžiausias iššūkis slypi testavime, nes šie algoritmai yra nedeterministiniai – jie gali pateikti skirtingus rezultatus. Kiekvienas pakeitimas užklausoje gali sukelti nenumatytų pasekmių. Testuojant rankiniu būdu galima pridėti konkretų atvejį į vertinimo rinkinį (evaluation set). Kaskart, kai ką nors pakeičiate agente, turite galimybę paleisti visus šiuos testus ir patikrinti, ar rezultatai vis dar atitinka jūsų lūkesčius.
LLM kaip vertintojas
Šis mechanizmas naudoja vadinamąjį LLM kaip vertintoją (LLM as a judge). Jo reikia todėl, kad DI agento išvestys ne visada yra tokios, kurias galima tiesiog greitai palyginti su tikėtais rezultatais. Dažnai gauname, pavyzdžiui, el. laiško turinį – jame bus ta pati informacija, tačiau kiekvieną kartą ji bus išreikšta kitaip, suformuluota skirtingai. Todėl reikia LLM, kuris galėtų įvertinti, ar išvesties esmė iš tikrųjų atitinka laukiamą atsakymą, o ne ar ji sutampa simbolis į simbolį.
Žinoma, turime ir sekimus (traces). Kiekvienam agento vykdymui galime matyti išsamią informaciją: kokie buvo įvesties duomenys, kokie buvo išvesties rezultatai, kokie parametrai buvo naudojami ir kiek laiko agentas praleido „galvodamas“.
Agentai klasikinėje automatizacijoje
Tuos agentus galime naudoti ir klasikinėse automatizacijose. Dažnai automatizacija tam tikru momentu reikalauja sprendimo, kurio logikos neįmanoma išreikšti daugybe „if“ sąlygų. Tokiu atveju klasikinė automatizacija gali iškviesti agentą, perduoti jam tam tikrą informacijos rinkinį ir gauti sprendimą atgal. Tai gali būti tiek paprasta užduotis, pavyzdžiui, gauti tinkamą informaciją iš el. laiško, tiek kur kas sudėtingesnė analizė ar vertinimas.
Galite įsivaizduoti agentą, kuris gauna iš automatizacijos užklausą sukurti klientą ar tiekėją jūsų duomenų bazėse. Agentas, naudodamasis įrankiais, surenka informaciją iš įvairių sistemų (daugelio už jūsų įmonės ribų) ir tada, remdamasis savo sprendimu, nusprendžia, ar galima saugiai dirbti su šia konkrečia įmone, ar galbūt reikėtų, kad žmogus peržiūrėtų duomenis, nes algoritmas pastebi kažką įtartino. Agentų integravimas į klasikinę automatizaciją gali būti tinkamas kelias šiuo atveju.
Maestro: ilgų ir sudėtingų procesų orkestravimas
UiPath agentinė automatizacija yra kur kas daugiau nei tai. Dalis, kuri mane labiausiai sužavėjo, yra tai, ką anksčiau vadino Agentic Orchestration (dabar tai vadinama Maestro; UiPath, jei klausotės, man atrodo, senasis pavadinimas buvo geresnis). UiPath Maestro iš esmės yra būdas orkestruoti ilgus ir sudėtingus procesus, kuriuose yra daugybė tarpusavyje susijusių elementų.
Anksčiau ilgus ir sudėtingus procesus visada skaidydavome į mažesnes automatizacijas, tačiau dažnai tarp šių automatizacijų būdavo žmogus, atliekantis tai, ko automatizacija negali padaryti. „UiPath“ platformoje jau egzistuoja būdas modeliuoti tokio tipo procesus – tai vadinama Long-Running Workflows (ilgai veikiantys darbo srautai), tačiau iki šiol jų taikymas nebuvo itin plačiai paplitęs. Pagrindinė priežastis – tokie procesai yra gana sudėtingi skaityti ir suprasti, kaip jie sukonstruoti.
„Maestro“ aplinkoje turime BPMN diagramą. Ši diagrama aiškiai parodo, ką daro mūsų automatizacija, o jos vykdymo metu galima aiškiai matyti, kur ji juda ir kokie sprendimai buvo priimti. Manau, kad tai išsprendžia daugelį problemų, su kuriomis susidurdavo Long-Running Workflows.
Atvejo analizė: įdarbinimo pagalbininkas „Maestro“ aplinkoje
Kai gavome ankstyvą prieigą prie agentų ir Maestro kaip vieni iš „UiPath“ partnerių, iškart pradėjome kurti keletą prototipų. Vienas iš pavyzdžių, kurį sukūrėme, yra įdarbinimo pagalbininkas (Recruitment Helper). Visas šis procesas siekia kuo labiau automatizuoti administracinius darbus, susijusius su įdarbinimo procesu. Naudojome agentus, integracijas, robotus ir Action Center – stengėmės išnaudoti kuo daugiau skirtingų platformos elementų.
Įdarbinimo procesas žingsnis po žingsnio
Procesas prasideda nuo to, kad gaunamas el. laiškas su prisegtu CV.
- Phishing Guard: pirmiausia veikia Phishing Guard agentas. Šis agentas nusprendžia, ar el. laišką galima toliau apdoroti, ar ne.
- Duomenų ištraukimas (Data Extraction): kai priimamas teigiamas sprendimas, el. laiško duomenys išsaugomi UiPath platformos duomenų bazėje (Data Service). Jei prie laiško yra pridėtas priedas, pasitelkiamas kitas agentas, kuris ištraukia informaciją iš CV. Kadangi CV yra nestruktūrizuoti duomenys, naudojame agentą, kad išgautume būtent tuos duomenų punktus, kurių mums reikia.
- Lygiagretūs agentai (Parallel Agents): kai šie duomenys išgaunami, du kiti agentai pradedami vykdyti lygiagrečiai.
🔸 Duomenų tikrinimo agentas – tikrina, ar pateikti visi reikalingi duomenys (pvz., kalbos mokėjimo lygis). Jei kažko trūksta, žinome, kad reikia paprašyti šios informacijos.
🔸 Atsakymų generatorius (Answer Generator) – šis agentas kaip kontekstą naudoja informaciją apie darbo aprašymą ir pagrindinę įmonės informaciją (panašiai kaip „CyberOla“, kurią rodžiau viename iš ankstesnių epizodų). - El. laiško generavimas ir žmogaus įsitraukimas (Email Generation and Human in the Loop): šių dviejų agentų išvestis perduodama kitam agentui, kuris suformuoja aiškiai ir gražiai parašytą el. laišką. Kadangi nenorime, jog generatyvinis DI (GenAI) tiesiogiai bendrautų su žmonėmis (ši technologija dar nėra pakankamai subrendusi), visada įtraukiame Action Center – vietą, kur žmogus įsitraukia į procesą ir gali peržiūrėti bei patvirtinti pranešimą.
- Peržiūra „Action Center“ aplinkoje (Review in Action Center): žmogus operatorius mato užduotį Action Center lange. Jis mato tris dalykus: lentelę su kandidato profiliu (iš CV išgauti duomenys), originalų kandidato el. laišką ir siūlomą el. laiško tekstą atsakymui.
- Sugeneruoto atsakymo informacija (Generated Response Details): el. laiškas atsako į klausimus (pvz., patvirtina, kad įmonės gyvūnų politika leidžia atsivesti šunis, bet ne kates, nes jos nėra reglamentuotos). Laiškas taip pat paprašo trūkstamų duomenų, pavyzdžiui, kalbos mokėjimo lygio. Jei viskas atrodo gerai, žmogus operatorius gali patvirtinti el. laišką.
Antroji iteracija ir sudėtingesnių rezultatų generavimas
Kai kandidatas atsako (atsiųsdamas atnaujintą CV), procesas paleidžiamas iš naujo. Duomenys ištraukiami ir atnaujinami Data Service sistemoje. Žmogus operatorius mato kandidato profilį su visa pateikta informacija ir patvirtina standartinį padėkos („thank you“) el. laišką.
Procesas tuo nesibaigia. Taip pat naudojame agentus, kad sugeneruotume, pavyzdžiui, galimus pokalbio klausimus. Agentas bando sukurti klausimus, aktualius konkrečiam kandidatui, remdamasis darbo aprašymu ir informacija iš CV. Pavyzdžiui, jei darbo aprašyme nurodyta, kad tikimasi gebėjimo dirbti su UiPath REFramework, o kandidatas apie tai nieko nepaminėjo, vienas iš klausimų būtų: „Kokia jūsų patirtis dirbant su REFramework?“.
Kitas dalykas, kurį įrankis generuoja, yra atitikties profilis (profile fit). Jis sukuria pagrindinį vertinimą, kiek kandidato CV atitinka darbo aprašymą. Mes nenorime, kad DI priimtų sprendimus, ką priimti į darbą – pokalbis ir galutinis sprendimas turi būti atliekami žmogaus. Tačiau siekiame, kad DI padėtų su visa administracine dalimi, susijusia su įdarbinimo procesu.
Platesnės „Maestro Orchestration“ taikymo galimybės
„Maestro“ aplinkoje galime modeliuoti gana ilgus ir sudėtingus procesus.
Įsivaizduokite procesą, kai klientas atsiunčia užsakymą. Agentas jį perskaito, patikrina kliento kreditingumą ir sutartis (naudodamasis Integration Service arba robotais) ir tuomet priima sprendimą. Jei kažkas negerai, agentas eskaluoja situaciją žmogui sprendimui priimti. Jei viskas gerai, jis perduoda užsakymą apdorojimui ir netgi gali stebėti jo įvykdymo eigą.
Pagalvokite apie atlyginimų (payroll) sritį – didelėse įmonėse dirba komandos žmonių, atsakančių į darbuotojų klausimus. Agentų rinkinys, paremtas vidinėmis procedūromis, išoriniais reglamentais ir palaikomas RPA robotų bei integracijų, galėtų atsakyti į daugumą šių užklausų, palikdamas žmonėms tik pačius sudėtingiausius atvejus.
Išvada: slaptoji hipersisteminės automatizacijos (hyperautomation) paslaptis
Viskas, apie ką ką tik kalbėjau, yra visiškai nauja. Generatyvinis DI iš esmės vis dar yra tarsi mažas vaikas, kuris tik mokosi judėti po kambarį neužsikliūdamas už baldų. UiPath agentai ir ta įspūdingoji Maestro orkestracija (šiuo metu, kai tai įrašome) vos kelias savaites egzistuoja „laukinėje“ aplinkoje. Mes tik pradedame.
Visa ši kombinacija – DI agentai kartu su Maestro orkestracija, uždėti ant jūsų senos geros RPA sistemos, – yra tarsi slaptas raktas, atrakininantis daugybę durų, kurias laikėme užvirintomis amžiams. Mes nuolat aptinkame milžiniškus procesų žvėris – tikras automatizacijos aukso gyslas, bet tada atsitrenkiame į realybę: procesas ilgesnis nei „Titanic“ režisieriaus versija ir reikalauja tokio subtilaus sprendimo, kokį paprastai turi tik patyręs barmenas. Įmaišai šiek tiek agentų, šlakelį Maestro, ir staiga daugybė tų „ne, to automatizuoti neįmanoma“ procesų atrodo visai įgyvendinami.
Čia visai ne apie tai, kad reikėtų išmesti savo esamą RPA platformą pro langą. Kalbame apie tai, kad ją galima sustiprinti, suteikti jai supergalių ir išplėsti jos galimybių ribas. Jau daugelį metų mėtomės terminu hiperautomatizacija (hyperautomation). Atrodo, kad pagaliau atėjome į realybę, kur tai nebėra tik madingas žodis PowerPoint skaidrėje, skirtas gauti didesnį biudžetą – dabar tai iš tikrųjų tampa realybe.
Tad štai ir viskas – mūsų gilus pasinėrimas į pašėlusį „UiPath“ agentų pasaulį ir į Maestro, kuris, kaip sakoma, tempia už visų virvelių, baigtas.
Pabaiga
Visiems, kurie klausėsi – dėkojame, kad skyrėte mums savo brangų laiką. Didžiulės ovacijos (ar bent jau mandagus linktelėjimas) mūsų vienintelei ir nepakartojamai Annai Cubal, mūsų prodiuserei, kuri šį tinklalaidės orkestrą valdo su daugiau elegancijos nei bet kuri programinės įrangos platforma. Kaip visada, įrašyta legendinėje Wodzu Beats studijoje. Iki kito karto – prisiminkite, kad ne kiekvienai problemai reikia DI sprendimo. Kartais tereikia išjungti ir vėl įjungti.
