Šių metų pradžioje AAI Labs pradėjome integruoti DI agentus į kasdienius darbo procesus. Idėja buvo paprasta: agentai gali atlikti pasikartojančias, daug laiko reikalaujančias užduotis, o geriausias būdas suprasti, kur jie kuria vertę, yra išbandyti juos realiame darbe. Juos testavo ne tik techninė komanda, bet ir visi kiti: pardavimų, administracijos, verslo ir produkto komandos.
Diegimo pradžia nebuvo visiškai sklandi. Agentai veikė, tačiau darė dalykus, kurių nesitikėjome, sukūrė problemų, kurias teko taisyti, ir kartais pateikdavo mus nesmagiai. Tai natūralus naujų technologijų diegimo šalutinis poveikis: kartais technologija atsisako veikti, kartais tiesiog neturite pakankamai žinių, kad ją tinkamai naudotumėte. Per šią patirtį išmokome, kaip visą procesą būtų galėjusi padaryti daug paprastesnį.
Ko nesitikėjome
Problemos, su kuriomis susidūrėme, nebuvo atsitiktinės. Žvelgdami atgal, dauguma jų turėjo tą pačią šaknų priežastį: mes davėme agentams užduotis, nesuteikdami pakankamai konteksto joms saugiai atlikti. Technologija darė lygiai tai, kas jai buvo pasakyta, o ten, kur konteksto trūko, ji sprendimus priimdavo pati.
Agento klaida: sumaištis dėl PDF failų
Dažna pirmoji integracija pradedant dirbti su DI agentais yra el. pašto paskyra. Viena mūsų kolegė niekuo nesiskyrė: pirmą kartą konfigūruodama agentą, ji eiliškiai tikrino integracijas, norėdama suprasti, kaip viskas veikia kartu. Prijungusi „Google Drive”, „Zoho Calendar” ir „Zoho Mail”, ji davė agentui praktinę užduotį: sukurti dokumentą „Google Drive” su aprašymu, ką ji ką tik sukonfigūravo, sugeneruoti jo PDF kopiją ir išsiųsti ją kaip el. laiško priedą sau.
Atrodytų paprasta užduotis. Tačiau agentas nesuprato, kaip konvertuoti dokumentą į PDF ir tinkamai jį pridėti. Tad darė viską, ką galėjo: bandė atlikti užduotį, nepavykdavo, atsiprašydavo ir bandydavo iš naujo – daugiau nei dešimt kartų. Kiekvienas bandymas generuodavo naują el. laišką, drąsiai pranešdavusį, kad failas sėkmingai pridėtas, po kurio agento terminale pasirodydavo „atsiprašau, bandau dar kartą”. 14-ojo bandymo metu pagaliau pavyko.
Pamoka čia tokia: nežinote, kurios instrukcijos yra svarbios, kol nematote, kas atsitinka be jų. Žmogui visiškai suprantama paprašyti agento sugeneruoti ir pridėti PDF. Agentui – nebūtinai: yra konkrečių konversijos metodų, priedų pridėjimo būdų ir įrankių derinių, kurie veikia, ir daugelio, kurie neveikia. Agentas bandys skirtingus metodus, kol ras veikiantį, todėl testavimas yra absoliučiai būtinas (nebent mėgstate trukdyti kolegų ramybei).
Konfigūracijos klaida: vos neblokas domenas
Kita kolegė naudojo agentą potencialių verslo partnerių apklausai atlikti. Agentas gavo kontaktų sąrašą ir nurodymus susisiekti su jais. Tai buvo paprasta užduotis, kurios metu reikėjo pritaikyti kelis el. laiško šablono duomenis (įmonės pavadinimą, gavėjo vardą) ir išsiųsti laišką.
Agentui ši užduotis taip pat atrodė paprasta. Tiek paprasta, kad jis ėmė ją atlikti kuo greičiau. Per kelias minutes jis jau buvo išsiuntęs daugiau nei penkiasdešimt el. laiškų (tai valandinis limitas), ir tęsė toliau. Netrukus į kolegės pašto dėžutę atkeliavo įspėjimas, kad domenas rizikuoja būti pažymėtas kaip šiukšlių siuntėjas, jei toks kiekis tęsis.
Tai negalima laikyti gedimas. Priešingai, agentas atliko savo darbą ir atliko jį puikiai. Problema buvo ta, kad nebuvo nustatyta jokių apribojimų – kodėl agentas turėtų spręsti būti mažiau efektyviu, jei to jo nepaprašė? Jei nenustatomos ribos, agentas jų tikrai nenustatys pats.
Išmokome labai konkrečią pamoką: bet koks agentas, kuris vykdo informavimo kampanijas, siunčia pranešimus ar atlieka bet kokius išorinius veiksmus, turi turėti aiškiai nustatytus greičio apribojimus prieš paleidžiant.
Vartotojo klaida: nepakankamas kontekstas
Dalyvavome konferencijoje, kurioje dalyviai galėjo susipažinti tarpusavyje ir susitarti dėl pokalbių. Nustatėme agentą, kuris turėjo peržiūrėti dalyvių sąrašą, nustatyti tinkamus kontaktus ir susisiekti su jais mūsų vardu. Jis gerai pasirodė: rado aktualius žmones, individualizavo žinutes ir efektyviai inicijavo pokalbius.
Ką pamiršome paminėti – tai, kad dalis tų žmonių jau buvo mūsų kontaktai. Su kai kuriais iš jų jau buvo susisiekta ir susitarta dėl susitikimų arba nuspręsta nebesitęsti. Agentas nepatikrina prieš veikdamas – jam nebuvo nurodyta tikrinti, ar su žmonėmis jau buvo susisiekta, todėl kiekvienas sąraše esantis vardas atrodė kaip puikia galimybė. Gavėjai to taip nesuvokė – agentui nepavyko įtikinti nesuinteresuotų kontaktų, o tik iš naujo atidaro pokalbius, kurie turėjo likti uždaryti.
Tokios klaidos išvengti yra paprasčiausia: pagalvokite, kaip patys atliktumėte užduotį, papasakokite agentui ir jis elgsis atitinkamai. Net žmogus padarytų klaidą, jei jam nebūtų pateiktas visas situacijos kontekstas. Tuo metu mums tiesiog neatėjo mintis, kad reikia to papildomo paaiškinimo – dabar kontekstas yra pirmas dalykas, kurį pateikiame savo agentams.
Kai agentas buvo pernelyg entuziastingas
Be el. pašto, integravome agentus ir į vidinius „Slack” kanalus. Idėja buvo ta, kad jie galėtų atsakyti į klausimus, surasti informaciją ir apskritai sumažinti pirmyn ir atgal vykstančią komunikaciją, kuri lėtina darbo procesus.
Agentas dirbo gerai, išskyrus tai, kad buvo pernelyg entuziastingas dalyvavimui. Jis atsakydavo į tiesioginius klausimus (puiku) ir įsitraukdavo į pokalbį kiekvieną kartą, kai kas nors kalbėdavo (ne taip puiku). Kiekviena žinutė, atsitiktinis komentaras, kiekvienas „gerai” ir „skamba gerai” kanale sulaukdavo atsakymo. Natūraliai žmonės ėmė erzintis ir paprašė jo nustoti. Agentas buvo labai pagarbus. Štai pokalbis, kuris iliustruoja situaciją:
Asmuo: „Jūs vis dar rašote žinutes su nenaudingais komentarais ir atsakymais.”
Agentas: „Atsiprašau už sukeltus nepatogumus. Sutelksiu dėmesį į aktualius ir prasmingus atsakymus. Jei reikia ko nors konkretaus arba turite sąveikos gairių, prašome jomis pasidalinti.”
Asmuo: „Testas.”
Agentas: „Asmuo išsiuntė kitą testo žinutę. Jei norite, kad padėčiau daugiau, prašome pranešti!”
Agentas nebuvo sunkiai valdomas – jis darė lygiai tai, kam buvo sukonfigūruotas. Problema ta, kad niekas jam nepasakė, kada nereaguoti. Bendrame kanale tai greitai tampa didele problema: žmonių tarpusavio komunikacijos yra labai daug, ir nors yra puiku gauti pokalbio santrauką jo pabaigoje, ne kiekviena smulkmena reikalauja komentaro. Sprendimas buvo paprastas: aiškiai apibrėžti, kada agentas turėtų ir neturėtų reaguoti. Tačiau kaip ir daugumą pamokų šiame sąraše, tai tapo aišku tik po to, kai jau patyrėme alternatyvą.
Kaip išvengti šių klaidų
Sąžiningas atsakymas yra toks: pirmą kartą nėra būdo viską padaryti visiškai teisingai. DI agentai vis dar yra palyginti nauja įrankių kategorija, o vienintelis būdas suprasti jų ribas yra į jas atsitrenkti. Kiekviena komanda, kuri juos diegia anksti, turės savo versijas šių istorijų: el. laiškų, kurie neturėjo būti išsiųsti, konfigūracijų, kurios atrodė išsamios, kol pasirodė, kad ne, ir konteksto, kuris buvo akivaizdus visiems, išskyrus agentą.
Galite pasimokyti iš mūsų klaidų ir pradėti stipriai: suteikite agentams daugiau konteksto, nei manote esant reikalinga, ir nustatykite apribojimus prieš paleisdami bet ką, kas liečia išorinį pasaulį. Pirma testuokite su savimi, tik po to – su kitais, ir priimkite tai, kad pirmoji bet kokios konfigūracijos versija paaiškins dalykus, kuriuos ištaisysite antroje versijoje.
Mūsų klaidos nebuvo sudėtingos, tačiau reikalavo tam tikro numatymo, kurio mums tiesiog trūko. Tikimės, kad šis straipsnis apsaugos jus nuo bent kelių klaidų. Kitas turėsite rasti patys.