For et år siden kontaktede vores elskede HR-afdeling os med en anmodning: at skrive en chatbot, der hjælper nyansatte med at tilpasse sig i virksomheden.
Lad os understrege, at vi ikke udvikler egne produkter, men vi tilbyder vores kunder et fuldt spektrum af udviklingstjenester. Historien vil handle om vores interne projekt, hvor kunden ikke er et eksternt firma, men vores egen HR. Og den primære opgave var at gennemføre projektet til tiden med begrænset adgang til folk, ressourcer og tid og udgive produktet.
Lad os først beskrive de opgaver, der skulle løses.
Udviklerne er i deres væsen ofte introverte og foretrækker at stille spørgsmål skriftligt i et elektronisk chatrum. Med robotten behøver man ikke at tænke over, hvem man skal spørge, hvem man skal ringe til, hvor man skal gå hen, og hvor man egentlig skal finde information, og om den er relevant.
Det andet problem er informationen - der er meget af den, den findes i forskellige kilder, og det er ikke altid tilgængeligt og kræver konstant opdatering og udfyldning.
Virksomheden har næsten 500 medarbejdere, der befinder sig i forskellige kontorer, tidszoner, byer i Rusland og endda i udlandet. Der er normalt mange spørgsmål, så endnu en opgave er at reducere belastningen på HR-personalet i forbindelse med de mest almindelige spørgsmål, der stilles af medarbejdere.
Det var også nødvendigt at automatisere processerne: tilgangen af nyansatte i virksomheden, udsendelse af meddelelser til nye medarbejderes ledere og mentorer, samt at sende automatiske påmindelser om kurser og tests, som nyansatte skal gennemføre for en vellykket tilpasning.
Baseret på forretningskravene blev der udarbejdet tekniske specifikationer.
Botsystemet skal fungere på basis af Skype (historisk set er det det, virksomheden bruger), derfor blev der valgt en tjeneste på Azure.
For at begrænse adgangen til det, begyndte vi at bruge et autoriseringssystem gennem Skype.
Til tekstgenkendelse brugte vi bibliotekerne ParlAI.
Der kræves også en administrativ webportal til konfiguration, træning, fejlfinding, indstillinger af udsendelser og andre opgaver.
Under arbejdet med projektet stødte vi på en række problemer og udfordringer.
For eksempel var der tekniske problemer med Azure-kontoen. Microsoft ville ikke aktivere vores abonnement på grund af nogle tekniske vanskeligheder i deres service. I næsten to måneder kunne vi ikke gøre noget ved det, og Microsofts support trak til sidst på skuldrene og sendte os videre til partnere, som succesfuldt fik alt sat op og gav os kontoen.
Det mest udfordrende skridt var opstarten af projektet, hvor vi skulle vælge, hvad vi skulle bruge, hvilken arkitektur der skulle være, hvordan og hvor vi skulle opbevare data, samt hvordan komponenter og moduler i systemet ville interagere med hinanden.
I vores tilfælde blev de typiske opstartsproblemer for ethvert projekt kompliceret yderligere af personalemangel. Vores forretningsspecifik er sådan, at i modsætning til kommercielle projekter arbejder udviklere ofte på interne projekter, som ikke har tilstrækkelig viden indenfor de nødvendige områder – de befinder sig bare på bænken i forventning om det næste store, spændende kommercielle projekt. Det er logisk, at motivationen i en sådan situation også var ret vanskelig. Produktiviteten faldt til et lavt niveau, der var ofte stille i teamet, og til sidst måtte vi overtale (motivere) eller skifte medarbejderen. Ved udskiftning af udvikleren skal der gennemføres træning, overføres viden, og projekten skal i princippet startes forfra. Hver ny udvikler så arkitekturen på sin måde og kritiserede de tidligere for deres beslutninger og andres kode. Det begyndte at blive skrevet fra bunden.
Sådan fortsatte det i omtrent et halvt år. Vi stod stille, refaktorerede koden og skrev ingenting nyt.
Derudover er der som regel ikke meget dokumentation på interne projekter, og det var svært at forstå, hvad der skulle gøres på ethvert givet tidspunkt, og hvilke prioriteter der var. Det var nødvendigt at danne et permanent team, etablere processer, og lave planlægning og vurdering for mindst tre måneder. Men hvordan gør man det, når projektet ikke er kommercielt, og det betyder, at timerne skal investeres minimalt, samtidig med at man skal opnå resultater som for en ekstern kunde?
Vi har defineret en pulje af ressourcer, der deltager i udviklingen af projektet, er bekendt med det og ønsker at arbejde på det. Vi har oprettet en tidsplan for menneskers tilgængelighed på projekterne. Vi har gennemført en vurdering og godkendelse af opgaverne og indarbejdet disse opgaver i 'hullerne' mellem hovedprojekterne. Efter 4 måneder fik vi en fungerende prototype af applikationen.
Lad os nu tale mere detaljeret om botens funktionalitet, arkitektur og tekniske løsninger.
Et af de vigtigste krav fra HR var at genkende teksten, der er skrevet af brugeren for at give et korrekt svar på spørgsmålet. Man kan skrive til den — jeg vil gerne tage på ferie, jeg ønsker ferie eller jeg vil tage på ferie, og den vil forstå og svare passende. Eller hvis en medarbejder har haft en stol, der er brudt, og han vil skrive — 'stolen er brudt' eller 'Jeg har en stol, der er sprunget' eller 'Ryggen på stolen er faldet af', så kan boten, med korrekt træning, genkende sådanne forespørgsler. Kvaliteten af tekstgenkendelsen afhænger naturligvis af træningen af boten, som vi senere vil tale om.
Det næste krav og en del af funktionaliteten er botens dialogsysten. Der blev udviklet et system, hvori boten kan føre en dialog og forstå konteksten af det aktuelle spørgsmål. Den kan stille opklarende spørgsmål som svar på dit spørgsmål og fortsætte samtalen, forudsat at vi har trænet boten til at gøre dette. Skype understøtter enkle menupunkter for at hjælpe brugerne med mulige fortsættelser af dialogerne. Også hvis vi har ført en dialog, men pludselig besluttede at stille et spørgsmål, der ikke er relateret, vil boten også forstå det.
Boten giver mulighed for at sende forskellige artefakter til brugeren baseret på hans personlige data. For eksempel, baseret på hans placering. Antag, at en person ønsker at finde et toilet, så vil han få vist et kort over kontoret, der fører ham til toilettet. Og kortet vil blive valgt afhængigt af, hvilken kontorplads medarbejderen befinder sig i.
En af de vigtigste opgaver er at beskytte brugernes personlige oplysninger. Vi kan ikke tillade, at enhver får adgang til de fortrolige data, som vores bot håndterer. Kravet om autorisation for en sådan bot er en uundgåelig del af dens funktionalitet. Botten beder brugeren om at gennemgå autorisation, før de kan føre en samtale med den. Dette sker ved første henvendelse fra en medarbejder til botten. Selve autorisationen sender brugeren til den relevante side, hvor brugeren får en token, som derefter indsættes i Skype-beskeden. Hvis autorisationen er vellykket, kan samtalen med botten begynde.
Autorisationen foregår gennem Skype – portalen - autorisationstjenesten, det interne netværk og LDAP. På den måde afhænger autorisationen af de aktuelle oplysninger om brugeren i det interne netværk.
I forbindelse med udviklingen af botten indså vi, at der var behov for et system, der var integreret i portalfunktionaliteten, som kunne hjælpe HR med hurtigt at fejlfinde botten. Vi har tilføjet en sådan side til portalen, hvor HR kan se de fejl, der er blevet rapporteret af brugerne under arbejde med botten, og løse dem enten ved at genuddanne botten eller lade udviklerne tage sig af dem.
Muligheden for at træne botten direkte på portalen var ikke indbygget fra starten. Under udviklingen indså vi, at træning af botten var den mest almindelige opgave, som HR-afdelingen ville udføre i arbejdet med den, og at det at sende filer med tekst til udviklerne til yderligere træning af botten var helt uacceptabelt. Det spilder for meget tid og skaber for mange fejl og problemer.
Vi har skrevet en brugergrænseflade på portalen til brugervenlig træning af botten. Den giver HR mulighed for at se botens aktuelle træning, tilpasse den og foretage ændringer i den nuværende træning. Træningen præsenteres i en træstruktur, hvor noder, det vil sige grene, er fortsættelser af samtalen med botten. Man kan oprette enkle spørgsmål-svar, men også omfangsrige dialoger, alt afhænger af HR og deres behov.
Et par ord om arkitekturen af løsningen.
Løsningens arkitektur er modulær. Den omfatter tjenester, der er ansvarlige for forskellige opgaver, nemlig:
• Skype-bot service på Azure — modtager og behandler brugerforespørgsler. Det er en relativt simpel service, der først modtager forespørgslen og udfører den indledende behandling.
• Admin portal — en service, der tilbyder et webinterface til konfiguration af portalen og selve botten. Botten henvender sig altid først til portalen, og portalen afgør derefter, hvad der skal gøres med forespørgslen.
• Autorisationsservice — giver autentifikationsmekanismer til botten og admin portalen. Autorisation sker via Oauth2-protokollen. Ved positiv autorisation udfører servicen autentificering i det virksomhedsniveau baseret på gyldige brugeroplysninger, så systemet kan overvåge fejl relateret til datasynergi.
• AI-modul til tekstgenkendelse, skrevet i Python og anvender frameworket ParlAI til selve tekstgenkendelsen. Det er et neuralt netværk, i det mindste i den nuværende implementering. Vi bruger algorithmen tfDiff til at forstå spørgsmål. Modulet giver et API til kommunikation og træning.
Afslutningsvis vil jeg sige, at dette er vores første erfaring med at skabe en chatbot, og vi har forsøgt at gøre systemet så enkelt som muligt, men samtidig funktionelt, med minimale arbejdsomkostninger. Jeg tror, vi har fået et ret interessant produkt. Med sit eget læringssystem, fejllogning, og notifikationsudsendelser kan det også integreres med enhver anden messenger.
Kilde: habr.com
