Agentinė stebėsena: kodėl DI sistemoms prireiks naujų taisyklių

Agentinė stebėsena skamba kaip dar vienas terminas, kurį kažkas sugalvojo konferencijai. Bet čia yra gana ūkiškas dalykas: kai DI agentas pats jungiasi prie įrankių, pats renkasi veiksmą ir pats taiso problemą, senas „pažiūrėkim logus“ metodas pradeda braškėti.

Prieš kelis metus stebėseną buvo galima įsivaizduoti paprastai. Serveris gyvas arba negyvas. Užklausa greita arba lėta. Klaida yra arba jos nėra. Dabar atsiranda dar vienas sluoksnis: kodėl agentas taip nusprendė?

KAS PASIKEITĖ

Microsoft savo naujame tekste apie debesijos operacijas rašo apie situaciją, kur programinė įranga tampa vis labiau agentinė. Tai reiškia, kad sistemos ne tik vykdo fiksuotą komandą, bet ir pačios renkasi kelią iki rezultato. Skamba patogu. Ir kartu truputį nejauku.

Įsivaizduokime klientų aptarnavimo sistemą. Seniau ji galėjo parodyti užklausą žmogui. Vėliau – pasiūlyti atsakymo šabloną. Dabar agentas gali patikrinti kliento istoriją, sukurti užduotį CRM, inicijuoti grąžinimą ir dar parašyti žinutę sandėliui. Vienas mažas „padėk klientui“ virsta dešimčia veiksmų.

Ir tada klausimas nebe toks: ar sistema veikia? Klausimas: ar ji veikia taip, kaip mes jai leidome veikti?

KODĖL ĮPRASTI LOGAI NEPAKANKA

Įprasti logai gerai parodo, kas įvyko. Bet DI agentų pasaulyje reikia matyti ir ketinimą. Kokį įrankį agentas pasirinko? Kokią informaciją perskaitė? Ar jis turėjo teisę tai daryti? Ar žmogus buvo įtrauktas ten, kur turėjo būti?

Čia ir atsiranda agentinė stebėsena. Ji turi sujungti techninį veikimą, saugumą, kaštus, sprendimo eigą ir žmogaus kontrolę. Kitaip gaunasi toks tvarkingas chaosas: visi grafikai žali, bet versle kažkas jau parašė klientui nesąmonę.

Man čia labai primena pirmą kartą, kai įmonės prisijungė automatizacijas tarp programų. „Tik persiųsim duomenis iš formos į lentelę.“ Po mėnesio ta lentelė maitino penkis procesus, o niekas nebežinojo, kas ją pakeitė. Su DI agentais tas pats, tik greičiau.

KĄ VERSLUI DARYTI DABAR

Pirma, nepradėti nuo didžiausio proceso. Agentus verta leisti ten, kur klaidos kaina aiški ir ribota. Pavyzdžiui, vidinė dokumentų paieška, pirmas incidento aprašymas, sąskaitų klasifikavimas ar IT užklausų triage.

Antra, reikia turėti veiksmų žemėlapį. Ne tik „agentas gali naudoti CRM“, bet konkrečiai: ką jis gali skaityti, ką gali keisti, kada turi paklausti žmogaus. Tai ne biurokratija. Tai stabdžiai automobiliui, kuris pagaliau pradėjo važiuoti pats.

Trečia, kaštų stebėjimas turi būti proceso dalis nuo pirmos dienos. Agentas, kuris dešimt kartų bando tą patį veiksmą su skirtingais įrankiais, gali atrodyti atkaklus. Sąskaitoje jis atrodo kitaip.

KUR ČIA LIETUVOS ĮMONĖMS NAUDA

Lietuvos verslai dažnai turi mažas komandas ir daug rankinio darbo. Tai gera terpė agentams. Bet mažoje komandoje viena bloga automatizacija greitai tampa visų problema.

Todėl agentinė stebėsena turėtų būti ne „enterprise“ prabanga, o paprasta taisyklė: jei agentas gali atlikti veiksmą, tas veiksmas turi būti matomas, paaiškinamas ir atšaukiamas.

Šią savaitę verta pasiimti vieną procesą ir užduoti tris klausimus: kur agentas galėtų padėti, kokios klaidos kaina ir kaip pamatytume, kad jis nuklydo? Atsakymai dažnai būna blaivesni už bet kokį gražų demo.

Pirminis šaltinis: Microsoft. Jei norite praktiškai suprasti, kaip tokie agentai galėtų atrodyti jūsų darbe, verta pradėti nuo MasterSprint DI mokymų – be mistikos, su realiais procesais.

DUK

Kas yra DI agentas?

DI agentas yra sistema, kuri ne tik atsako į klausimą, bet gali planuoti veiksmus, naudoti įrankius ir atlikti užduotis pagal nustatytas taisykles.

Kodėl DI projektams reikia žmogaus kontrolės?

Nes DI gali suklysti, neteisingai suprasti kontekstą arba atlikti veiksmą, kurio pasekmės verslui per didelės automatiniam sprendimui.

Nuo ko pradėti įmonėje?

Pradėkite nuo vieno aiškaus proceso, ribotos rizikos, gerai aprašytų duomenų ir testų, kurie parodo ne tik rezultatą, bet ir agento elgesį.