Pred letom dni nas je naša ljubljena kadrovska služba prosila, da napišemo chat bota, ki bi pomagal pri prilagajanju novincev v podjetje.
Pridržimo se, da ne razvijamo lastnih izdelkov, ampak strankam zagotavljamo celotno paleto razvojnih storitev. Zgodba bo tekla o našem internem projektu, za katerega naročnik ni tretje podjetje, ampak lastni kadrovik. In glavna naloga, glede na omejeno razpoložljivost ljudi, sredstev in časa, je dokončati projekt pravočasno in izdati izdelek.
Najprej opišemo težave, ki jih je bilo treba rešiti.
Razvijalci so večinoma introvertirani ljudje in neradi govorijo; veliko lažje je napisati svoje vprašanje v e-poštnem klepetu. Z botom vam ni treba razmišljati, koga vprašati, koga poklicati, kam iti in na splošno, kje iskati informacije in ali so ustrezne.
Drugi problem so informacije – veliko jih je, so v različnih virih, niso vedno na voljo in jih je treba nenehno dopolnjevati in posodabljati.
Podjetje ima skoraj 500 zaposlenih, nahajajo se v različnih pisarnah, časovnih pasovih, mestih Rusije in celo v tujini, vprašanj je običajno veliko, zato je druga naloga zmanjšati obremenitev kadrovskega osebja, povezano z najpogostejšimi vprašanji. s strani zaposlenih.
Prav tako je bilo potrebno avtomatizirati procese: vstopa novincev v podjetje, pošiljanja sporočil vodjem in mentorjem novincev, pošiljanja avtomatskih opomnikov o tečajih in testih, ki jih mora novinec opraviti za uspešno prilagoditev.
Tehnične zahteve so bile oblikovane na podlagi poslovnih zahtev.
Bot mora delovati na osnovi Skypa (zgodovinsko ga uporabljajo v podjetju), zato je bila izbrana storitev na Azuri.
Za omejitev dostopa do njega smo začeli uporabljati avtorizacijski mehanizem prek Skypa.
Za prepoznavanje besedila je bila uporabljena knjižnica ParlAI
Skrbniški spletni portal je potreben tudi za konfiguracijo, usposabljanje, odpravljanje napak, nastavitev poštnih sporočil in druga opravila.
Pri delu na projektu smo naleteli na vrsto težav in težav.
Prišlo je na primer do tehničnih težav z računom Azure. Microsoft ni želel aktivirati naše naročnine zaradi nekaterih tehničnih težav v njihovi storitvi. Skoraj dva meseca nismo mogli narediti ničesar, Microsoftova podpora je na koncu dvignila roke in nas poslala k partnerjem, ki so vse uspešno nastavili in nam dali račun.
Najtežja faza je bil začetek projekta, ko je treba izbrati, kaj bomo uporabljali, kakšna bo arhitektura, kako in kje shranjevati podatke ter kako bodo komponente in moduli sistema medsebojno delovali.
V našem primeru so se v bistvu običajne težave ob začetku katerega koli projekta dodatno zapletle s kadri. Specifičnost našega poslovanja je taka, da za razliko od komercialnih internih projektov pogosto delajo razvijalci, ki nimajo zadostnega znanja na zahtevanih področjih – preprosto so po volji usode pristali na zatožni klopi in čakali na naslednjega. velik kul komercialni projekt. Logično je, da je bilo v takšni situaciji tudi z motivacijo zelo težko. Produktivnost pade nizko, ekipa pogosto miruje, posledično morate osebo prepričevati (motivirati) ali spreminjati. Ko menjate razvijalca, morate izvesti usposabljanje, prenesti znanje in v bistvu začeti projekt znova. Vsak novi razvijalec je videl arhitekturo na svoj način in grajal prejšnje zaradi odločitev, ki so jih sprejeli, in kode drugih ljudi. Prepisovanje se je začelo iz nič.
To je trajalo približno šest mesecev. Samo označevali smo čas, refaktorirali kodo in nismo pisali ničesar novega.
Tudi na internih projektih praviloma skorajda ni dokumentacije in je bilo težko razumeti, kaj je treba narediti v posameznem trenutku in katere so trenutne prioritete. Treba je bilo oblikovati stalno ekipo, vzpostaviti procese ter izvajati načrtovanje in vrednotenje vsaj tri mesece. Toda kako to storiti, ko projekt ni komercialen, kar pomeni, da morate vložiti najmanj delovnih ur, hkrati pa rezultat ni slabši kot za zunanjega kupca?
Identificirali smo skupino virov, ki so sodelovali pri razvoju projekta, ga poznajo in želijo delati na njem. Pripravili smo terminski načrt za zaposlovanje ljudi na projektih. Delo smo ocenili in koordinirali ter ta dela umestili v »luknje« med glavnimi projekti. Po 4 mesecih smo prejeli delujoč prototip aplikacije.
Zdaj pa se podrobneje pogovorimo o funkcionalnosti, arhitekturi in tehničnih rešitvah bota.
Ena glavnih zahtev HR je bila prepoznati besedilo, ki ga je napisal uporabnik, da bi pravilno odgovoril na vprašanje. Lahko mu napišete - želim na dopust, želim na dopust ali bi rad šel na dopust, in on bo razumel in se ustrezno odzval. Ali pa se zaposlenemu nenadoma zlomi stol in želi napisati "stol je polomljen" ali "Moj stol je počen" ali "Naslonjalo stola je padlo"; s pravilnim treningom bo bot prepoznal takšne zahteve. Sama kakovost prepoznave besedila je odvisna od usposobljenosti bota, o čemer bomo govorili kasneje.
Naslednja zahteva in del funkcionalnosti je botov dialog sistem. Razvit je bil sistem, v katerem lahko bot vodi dialog in razume kontekst trenutne težave. Kot odgovor na vaše vprašanje lahko postavi morebitna pojasnilna vprašanja in nadaljuje pogovor, če smo bota za to usposobili. Skype podpira preproste možnosti menija, da uporabnike opozori na možnosti za nadaljevanje pogovorov. Tudi, če smo imeli dialog, a smo se nenadoma odločili, da bomo postavili vprašanje, ki ni povezano s temo, bo bot tudi to razumel.
Bot omogoča pošiljanje različnih artefaktov uporabniku na podlagi njegovih osebnih podatkov. Na primer na njegovi lokaciji. Recimo, če bi oseba želela najti stranišče, bi se ji pokazal zemljevid pisarne, ki bi jo vodil do stranišča. Kartica bo izbrana glede na to, v kateri pisarni podjetja se zaposleni nahaja.
Ena najpomembnejših nalog je varovanje osebnih podatkov uporabnikov. Vsaki osebi ne moremo dovoliti dostopa do občutljivih podatkov, s katerimi upravlja naš bot. Potreba po avtorizaciji za takega bota je sestavni del tega. Bot uporabnika prosi za avtentikacijo, preden lahko z njim vodi kakršen koli dialog. To se zgodi, ko zaposleni prvič stopi v stik z botom. Sama avtorizacija uporabnika preusmeri na ustrezno stran, kjer uporabnik prejme žeton, ki ga nato vstavi v Skype sporočilo. Če je avtorizacija uspešna, lahko začnete komunicirati z botom.
Avtorizacija poteka prek storitve Skype - portal-avtorizacija, korporativnega omrežja in LDAP. Avtorizacija je torej odvisna od trenutnih uporabniških podatkov v omrežju podjetja.
V procesu razvoja bota smo ugotovili, da potrebujemo nekakšen sistem, vgrajen v funkcionalnost portala, ki bi lahko HR pomagal hitro odpraviti napake v botu. Dodali smo portalno stran, kjer lahko kadrovik vidi napake, ki so jih zabeležili uporabniki pri delu z botom in jih reši s prekvalifikacijami ali pa jih prepusti razvijalcem.
Možnost usposabljanja bota neposredno na portalu ni bila vključena že od samega začetka. Med razvojnim procesom smo ugotovili, da je usposabljanje bota najpogostejša naloga, ki jo bodo zaposleni v kadrovski službi opravljali pri delu z njim, pošiljanje besedilnih datotek razvijalcem za dodatno usposabljanje bota pa je popolnoma nesprejemljivo. To požre preveč časa in povzroči preveč napak in težav.
Na portalu smo napisali uporabniški vmesnik za uporabniku prijazno usposabljanje bota. HR omogoča, da vidi trenutno usposabljanje bota, ga dodatno usposobi in prilagodi trenutno usposabljanje. Usposabljanje predstavlja drevesna struktura, v kateri so vozlišča, torej veje, nadaljevanje dialoga z botom. Ustvarite lahko enostavna vprašanja in odgovore ali pa ustvarite tehtne dialoge, vse je odvisno od kadrovika in njegovih potreb.
Nekaj besed o arhitekturi rešitve.
Arhitektura rešitve je modularna. Vključuje službe, odgovorne za različne naloge, in sicer:
• Skype bot storitev na Azure - sprejema in obdeluje zahteve uporabnikov. To je dokaj preprosta storitev, ki prva prejme zahtevo in izvede njeno začetno obdelavo.
• Admin portal - storitev, ki omogoča spletni vmesnik za nastavitev portala in za sam bot. Bot vedno najprej vzpostavi stik s portalom, portal pa se odloči, kaj bo z zahtevo naredil naprej.
• Storitev avtorizacije - zagotavlja mehanizme za preverjanje pristnosti za bota in za skrbniški portal. Avtorizacija poteka prek protokola Oauth2. S pozitivno avtorizacijo storitev izvaja avtorizacijo v korporativnem omrežju glede na veljavne uporabniške podatke, tako da lahko sistem nadzoruje napake, povezane z nesinhroniziranimi podatki.
• Modul za prepoznavanje besedila AI, napisan v Pythonu in uporablja ogrodje ParlAI za samo prepoznavanje besedila. To je nevronska mreža, vsaj v trenutni izvedbi. Za razumevanje vprašanj uporabljamo algoritem tfDiff. Modul ponuja API za komunikacijo z njim in učenje.
Na koncu želim povedati, da je to naša prva izkušnja pri ustvarjanju klepetalnega bota in poskušali smo narediti sistem čim bolj preprost, a hkrati funkcionalen, z minimalnimi stroški dela. Mislim, da imamo zelo zanimiv izdelek. Z lastnim sistemom usposabljanja, beleženjem napak, pošiljanjem obvestil se lahko integrira tudi s katerim koli drugim messengerjem.
Vir: www.habr.com