Verslo automatizacijų testavimas: 30 tikrų atvejų naudingesni už bet kokį patikrinimą akimis

Kiekviena mūsų paleista AI automatizacija bent kartą sugedo, nors jos niekas nelietė. Pasikeitė modelio versija, nors promptas liko tas pats. Tiekėjas pakeitė numatytąją reikšmę. Kas nors, taisydamas skundą, pakeitė vieną nurodymą ir tyliai pablogino dešimt kitų atvejų. Jei AI naudojate realiame darbe, tai nutiks ir Jums, o klausimas tik toks: ar apie tai pirmas praneš ataskaitų skydelis, ar klientas.

Mūsų sprendimas yra verslo automatizacijų testavimas: fiksuotas tikrų atvejų su laukiamais rezultatais rinkinys, kurį skriptas paleidžia kiekvieną kartą, kai kas nors pasikeičia. Mašininio mokymosi tyrimuose tai įprasta praktika, o smulkaus verslo automatizacijoje beveik nežinoma, ir tai viena svarbiausių priežasčių, kodėl tiek daug tokių automatizacijų pamažu nustoja veikti.

Kas yra testų rinkinys

Nuo trisdešimties iki šimto tikrų atvejų iš Jūsų pačių veiklos, kiekvienas susietas su rezultatu, kurio tikėtųsi kompetentingas darbuotojas, laikomi faile ir skriptu paleidžiami per veikiančią konfigūraciją. Tai ir viskas. Jis užtrunka kelias minutes, ir šios savaitės rezultatą galite palyginti su praėjusios.

Telefono asistentui atvejis yra vienas skambučio scenarijus ir laukiamas rezultatas: užregistravo tinkamo tipo vizitą, užrašė numerį atskambinti, nepažadėjo neegzistuojančios nuolaidos. Dokumentų duomenų ištraukimui tai sąskaita iš Jūsų pačių apskaitos ir tikslūs laukai, kurie iš jos turėtų būti ištraukti.

Kodėl „atrodė, kad viskas gerai“ nepasiteisina

Modeliai atnaujinami, o promptas buvo suderintas pagal seną jų elgseną. Kiekvienas nedidelis prompto pakeitimas, išsprendžiantis vieną skundą, yra netestuotas pakeitimas visam kitam, ką promptas daro, ir po metų tokių pakeitimų niekas nebegali pasakyti, ką jis garantuoja. Tuo tarpu ir pats verslas keičiasi: naujos paslaugos, naujos kainos, kovą pasikeitusi taisyklė, o sistema toliau užtikrintai atsakinėja praėjusio ketvirčio faktais, ir būtent taip pokalbių robotas pradeda išgalvoti atsakymus praėjus mėnesiams nuo tada, kai jį kas nors paskutinį kartą lietė.

Rankiniai atsitiktiniai patikrinimai beveik nieko iš to nepagauna, nes žmonės tikrina atvejus, kuriuos prisimena, o tai atvejai, kurie jau veikė.

Mūsų sukurtas administratorius antrą savaitę užregistravo du klientus į tą patį laiką

Mūsų balso administratorius atsiliepia mūsų įmonės telefonu, ir jis turi testų rinkinį, paleidžiamą prieš kiekvieną diegimą. Antrą jo veikimo savaitę du skambučiai pasiekė kalendorių per tą pačią sekundę, ir jis abu užregistravo į vieną laiką, o tai vienas iš penkių būdų, kaip balso agentas nutraukia skambučius ir dvigubai užregistruoja. Prompte nebuvo jokios klaidos. Įrašas į kalendorių tiesiog nebuvo užrakintas. Šis incidentas tapo nuolatiniu testo atveju, taip atsirado kalendoriaus užrakinimo patikra, ir nuo tada ji paleidžiama prieš kiekvieną diegimą.

Dauguma mūsų rinkinių atvejų atsirado būtent taip, o ne buvo sugalvoti iš anksto. Gedimas įvyksta vieną kartą, tampa testo atveju, ir daugiau nebegali pasikartoti nepastebėtas.

Sudarykite rinkinį iš to, ką jau turite

1. Paimkite neapdorotus įrašus: skambučių išrašus, užklausas, el. laiškus, pateiktus dokumentus. Paprastai užtenka pastarųjų 90 dienų.
2. Atrinkite taip, kad būtų aprėpta viskas. Jums reikia dažnų kelių, retų, bet brangiai kainuojančių (atšaukimai, skundai, atitikties klausimai) ir kiekvieno ankstesnio incidento, dėl kurio teko skubiai taisyti.
3. Atsisėskite su savininku ir kiekvienam atvejui užrašykite laukiamą rezultatą. Šiame žingsnyje ir slypi vertė, nes maždaug pusėje atvejų verslas pastebi, kad niekada nėra nusprendęs, ką išimtiniais atvejais reiškia „teisingai“, o testų rinkinys priverčia tai nuspręsti vieną kartą, raštu, užuot leidus modeliui improvizuoti per kiekvieną skambutį.
4. Parašykite skriptą, kuris kiekvieną atvejį paleidžia per gamybinę konfigūraciją ir įrašo rezultatus. Tai trunka kelias minutes, o kaina paprastai yra keli eurai.

Nauja versija diegiama tik praėjusi testus

Testų rinkinys, kurį paleidžiate, kai prisimenate, yra tik ataskaita. Įtrauktas į diegimo procesą, jis tampa apsauga. Mūsų taisyklė kiekvienoje prižiūrimoje sistemoje: nė vienas prompto pakeitimas, modelio atnaujinimas ar workflow pakeitimas nepatenka į veikiančią sistemą, kol rezultatas nėra toks pat ar geresnis nei anksčiau. Jei nauja versija ištaiso atvejį, kurį taisėte, bet sugadina tris kitus, tai pamatote pirmi ir sprendžiate sąmoningai.

Tai įdiegti užtrunka vieną popietę, ir frazė „manome, kad atnaujinimas tvarkoje“ virsta fraze „atnaujinimas praėjo visus atvejus, išskyrus du, ir štai tie du“. Testų rinkinys yra viena eilutė realiam naudojimui paruoštos sistemos kontroliniame sąraše, ir būtent tos eilutės trūksta dažniausiai.

Kaip vertinti pokalbių atsakymus

Struktūrizuotus rezultatus vertinti lengva: ištraukta suma arba sutampa su sąskaita, arba ne. Pokalbiams reikia daugiau dėmesio, ir čia dauguma savadarbių bandymų sustoja.

Naudokite kriterijų sąrašą. Kiekvienam atvejui apibrėžkite nuo keturių iki šešių taip/ne patikrų (atsakė į užduotą klausimą, nurodė teisingą kainą, pasiūlė registraciją, neišgalvojo jokios taisyklės). Taip/ne patikrą galima vertinti nuosekliai; „kokybės“ balo nuo 1 iki 10 negalima. Tada leiskite antram modeliui vertinti atsakymus pagal kriterijus, šimtams atvejų už kelis eurus, bet jį tikrinkite: kiekvieną ciklą perskaitome atsitiktinę vertintojo sprendimų dalį, nes netikrinamas vertintojas ilgainiui nukrypsta taip pat, kaip ir sistema, kurią jis vertina. Vertintojo ir kriterijų nesutarimai arba balai, pasikeitę nuo paskutinio paleidimo, perduodami žmogui. Tai nedidelė atvejų dalis, ir beveik visi įdomūs gedimai slypi būtent joje.

Net Zapier už tai mokėjo išorės specialistams

Zapier, turinti inžinierių komandą, kuriai pavydėtų dauguma įmonių, pasamdė išorinę testavimo įmonę Fractional AI dirbti su savo integracijų kūrimo įrankio AI dalimi. Viešai paskelbtame atvejo aprašyme nurodoma, kad išgalvotų atsakymų sumažėjo daugiau nei 80 procentų. Mums tai įrodo, kad gebėjimas kurti programinę įrangą ir įprotis matuoti AI elgseną yra skirtingi įgūdžiai; įmonė su šimtais inžinierių vis tiek pasamdė specialistus antrajam.

Penkių žmonių įmonei, naudojančiai vieną DI administratorių ir porą automatizacijų, to reikia dar labiau, nes ji neturi inžinierių, kurie atsitiktinai pastebėtų, kad kažkas pasikeitė. Tokiu mastu viską įdiegti užtrunka kelias dienas.

Kada testų rinkinys nereikalingas: workflow be modelio arba promptui, kuris atlieka vieną siaurą užduotį su struktūrizuotu rezultatu, kurį galite patikrinti pagal schemą. Tokiu atveju pakanka patikrinti schemą ir kelis pavyzdinius duomenis. Testai atsiperka tada, kai rezultatas yra tekstas, kurį klientas skaitys ar girdės.

Jau veikiančioms AI sistemoms testus ir stebėjimą (paslauga „DI sistemos testai ir stebėjimas“) kuriame kaip fiksuotos apimties projektą, kurio kaina pagal apimtį pateikiama pasiūlyme ir priklauso nuo to, kiek yra sistemų ir rezultatų tipų, o kiekviena mūsų sukurta automatizacija tokius testus jau turi. Jei AI naudojate realiame darbe ir šiandien negalėtumėte pasakyti, kiek testo atvejų sistema praeina, puslapyje apie mūsų sistemų kūrimo paslaugą paaiškinta, kaip prie to prieiname.