Pred enim letom se je naš ljubljeni HR oddelek obrnil na nas s prošnjo: napisati klepetalnega robota, ki bo pomagal pri prilagajanju novincev v podjetju.
Omejiti se moramo, da ne razvijamo lastnih izdelkov, temveč našim strankam nudimo celoten spekter storitev na področju razvoja. Govor bo o našem notranjem projektu, za katerega naročnik ni zunanje podjetje, temveč naš lastni HR. Glavna naloga je, ob omejeni dostopnosti ljudi, virov in časa, dokončati projekt v roku in izdati izdelek.
Na začetku bomo opisali naloge, ki so jih morali rešiti.
Razvijalci so večinoma introverti in ne marajo govoriti, veliko lažje je postaviti svoje vprašanje v elektronskem klepetu. S botom ni treba razmišljati, koga vprašati, komu poklicati, kam iti in sploh, kje poiskati informacije ter ali so te informacije aktualne.
Druga težava je prav ta informacija — le-teh je veliko, pri različnih virih, ne vedno so na voljo in potrebujejo stalno dopolnjevanje in posodabljanje.
V podjetju je skoraj 500 zaposlenih, ti so v različnih pisarnah, časovnih pasovih, mestih v Rusiji in celo v tujini, vprašanj je običajno zelo veliko, zato je še ena naloga znižati obremenitev HR osebja, povezano z najpogostejšimi vprašanji, ki jih postavljajo zaposleni.
Prav tako je bilo potrebno avtomatizirati procese: prihod novincev v podjetje, pošiljanje sporočil managerjem in mentorjem novincev, pošiljanje samodejnih opomnikov o tečajih in testih, ki jih mora novinec opraviti za uspešno prilagoditev.
Na podlagi poslovnih zahtev so bile oblikovane tehnične specifikacije.
Bot mora delovati na osnovi Skypa (zgodovinsko je tako, da ga uporabljajo v podjetju), zato smo izbrali storitev na Azure.
Za omejitev dostopa smo začeli uporabljati mehanizem avtentifikacije preko Skypa.
Za prepoznavanje besedila smo uporabili knjižnico ParlAI.
Prav tako potrebujemo administrativni spletni portal za nastavitev, usposabljanje, odpravljanje težav, nastavitev pošiljanja in druge naloge.
Med delom na projektu smo se srečali s celotno vrsto težav in zapletov.
Na primer, so bili tehnični problemi — z računom na Azure. Microsoft ni želel aktivirati naše naročnine zaradi nekaterih tehničnih težav znotraj njihovega servisa. Skoraj dva meseca nismo mogli storiti ničesar v zvezi s tem, podpora Microsofta je na koncu obupala in nas napotila k partnerjem, ki so uspešno vse nastavili in nam izročili račun.
Najbolj zahtevna faza je bila start projekta, ko je bilo treba izbrati, kaj bomo uporabili, kakšna bo arhitektura, kako in kje shraniti podatke ter kako bodo komponente in moduli sistema medsebojno delovali.
V našem primeru so se osnovne težave ob začetku projekta še dodatno zapletle zaradi kadrovanja. Specifika našega poslovanja je takšna, da, za razliko od komercialnih projektov, na notranjih projektih pogosto delajo razvijalci, ki nimajo zadostnega znanja na potrebnih področjih – preprosto so se v tistem času znašli v čakalnici za naslednji velik, vznemirljiv komercialni projekt. Logično je, da motivacija v takšnih okoliščinah ni bila ravno najboljša. Produktivnost je bila nizka, v ekipi je pogosto prihajalo do zastojem, na koncu pa je bilo potrebno prepričevati (motivirati) ali zamenjati posameznika. Pri zamenjavi razvijalca je bilo potrebno izvesti usposabljanje, prenesti znanje in spet na novo začeti projekt. Vsak nov razvijalec je arhitekturo videl po svoje in kritikoval prejšnje odločitve in tujo kodo. Začelo se je pisanje od začetka.
To je trajalo približno šest mesecev. Preprosto smo obmetavali sami sebe, refaktorizirali kodo in nič novega niso pisali.
Poleg tega na notranjih projektih praviloma skoraj ni nobene dokumentacije, zato je bilo težko razumeti, kaj je potrebno storiti v vsakem trenutku in kateri so trenutni prioritete. Potrebno je bilo ustvariti stalno ekipo, uvesti procese, izvesti načrtovanje in ocenjevanje vsaj za tri mesece. Ampak kako to storiti, ko projekt ni komercialen, kar pomeni, da je treba človekoužitke vložiti minimalno, ob tem pa doseči rezultat, ki ni slabši od tistega za zunanjega naročnika?
Določili smo nabor virov, ki so sodelovali pri razvoju projekta, se z njim seznanili in želijo delati zanj. Pripravili smo razpored zaposlenih na projektih. Ocenili in uskladili smo delo ter vpisali te naloge v »prostore« med glavnimi projekti. Po 4 mesecih smo dobili delujoč prototip aplikacije.
Zdaj se pogovorimo podrobneje o funkcionalnosti bota, arhitekturi in tehničnih rešitvah.
Ena glavnih zahtev HR je bilo prepoznavanje besedila, ki ga napise uporabnik, za ustrezen odgovor na vprašanje. Uporabnik lahko zapiše — želim iti na dopust, želim na dopust ali šel bi na dopust, in bot bo razumel in ustrezno odgovoril. Ali pa, če se zaposlenemu zruši stol, lahko napiše — "stol se je zrušil" ali "Moj stol se je razpoke" ali "Naslonjalo na stolu se je odlomilo", ob ustreznem usposabljanju bot prepozna takšne poizvedbe. Kakovost prepoznavanja besedila seveda odvisna od usposabljanja bota, o katerem bomo govorili pozneje.
Naslednja zahteva in del funkcionalnosti je sistem dialogov bota. Razvili smo sistem, s katerim lahko bot vodi dialog in razume kontekst trenutnega vprašanja. Lahko postavi dodatna vprašanja v odgovor na vaše vprašanje in nadaljuje pogovor, če smo bota usposobili za to. Skype podpira preproste menije za usmerjanje uporabnikov glede možnih možnosti nadaljevanja dialogov. Prav tako, če smo vodili pogovor, a smo se odločili postaviti vprašanje, ki ni v zvezi s temo, bo bot to tudi razumel.
Bot omogoča pošiljanje različnih artefaktov uporabniku na podlagi njegovih osebnih podatkov. Na primer, glede na njegovo lokacijo. Predpostavimo, da je oseba želela najti stranišče, ji bo prikazana karta pisarne, ki jo vodi v stranišče. In karta bo izbrana glede na to, v katerem pisarni podjetja se nahaja zaposleni.
Ena iz najpomembnejših nalog je zaščita osebnih podatkov uporabnikov. Ne moremo dovoliti, da bi vsakdo dostopal do zaupnih podatkov, s katerimi upravlja naš bot. Potreba po avtorizaciji za tak bot je nepogrešljiv del njegovega delovanja. Bot prosi uporabnika, da opravi avtorizacijo, preden lahko z njim začne kakršenkoli pogovor. To se zgodi ob prvem stiku zaposlenega z botom. Sama avtorizacija preusmeri uporabnika na ustrezen spletni naslov, kjer uporabnik pridobi žeton, ki ga nato vstavi v sporočilo na Skypu. Če avtorizacija uspešno poteka, je mogoče začeti komunikacijo z botom.
Avtorizacija poteka preko Skypa — avtorizacijske storitve, podjetniške mreže in LDAP-a. Tako avtorizacija temelji na trenutnih podatkih o uporabniku v podjetniški mreži.
Med razvojem bota smo spoznali, da potrebujemo nek sistem, vgrajen v funkcionalnosti portala, ki bi pomagal HR hitro odpraviti težave bota. Dodali smo takšno stran portala, na kateri lahko HR-ovci vidijo napake, ki so jih zabeležili uporabniki pri delu z botom, in jih rešijo z dodatnim usposabljanjem ali jih pustijo za razvijalce.
Možnost usposabljanja bota neposredno na portalu sprva ni bila predvidena. Med razvojem smo spoznali, da je usposabljanje bota najpogostejša naloga, ki jo bodo zaposleni v HR-ju izvajali pri delu z njim, in pošiljanje datotek z besedilom razvijalcem za dodatno usposabljanje bota je povsem nepraktično. To vzame preveč časa in povzroči preveč napak in težav.
Napisali smo uporabniški vmesnik na portalu za uporabniku prijazno usposabljanje bota. Ta omogoča HR-u, da vidi trenutno usposabljanje bota, ga dodatno usposobi in vnaša popravke v trenutno usposabljanje. Usposabljanje je predstavljeno v drevesni strukturi, kjer so vozlišča, torej veje, nadaljevanje pogovora z botom. Ustvarjamo lahko preprosta vprašanja in odgovore ali obsežne dialoge, odvisno od potreb HR-a.
Nekaj besed o arhitekturi rešitve.
Arhitektura rešitve je modularna. Vključuje storitve, ki odgovarjajo za različne naloge, in sicer:
• Skype Bot Service on Azure — receives and processes user requests. It is a rather simple service that first receives the request and performs its preliminary processing.
• Admin Portal — a service that provides a web interface for configuring the portal and the bot itself. The bot always first communicates with the portal, and the portal decides what to do with the request further.
• Authorization Service — provides authentication mechanisms for the bot and the admin portal. Authorization occurs via the Oauth2 protocol. Upon successful authorization, the service conducts authentication in the corporate network according to valid user data, allowing the system to monitor errors related to data desynchronization.
• AI Text Recognition Module written in Python, utilizing the ParlAI framework for text recognition. This is a neural network, at least in its current implementation. We use the tfDiff algorithm for understanding questions. The module provides an API for interaction and training.
In conclusion, I want to say that this is our first experience in creating a chat bot, and we tried to make the system as simple as possible while still functional, with minimal labor costs involved. I believe we have developed a very interesting product. With its own training system, error logging, notification broadcasting, it can also be integrated with any other messenger.
Izvor: habr.com
