For et år siden bad vores elskede HR-afdeling os om at skrive en chatbot, der kunne hjælpe med tilpasningen af nye til virksomheden.
Lad os tage forbehold for, at vi ikke udvikler vores egne produkter, men vi giver kunderne et komplet udvalg af udviklingstjenester. Historien kommer til at handle om vores interne projekt, hvor kunden ikke er en tredjepartsvirksomhed, men vores egen HR. Og hovedopgaven, givet den begrænsede tilgængelighed af mennesker, ressourcer og tid, er at fuldføre projektet til tiden og frigive produktet.
Lad os først beskrive de problemer, der skulle løses.
Udviklere er for det meste indadvendte mennesker og kan ikke lide at tale; det er meget nemmere at skrive dit spørgsmål i en e-mailchat. Med en bot behøver du ikke tænke på, hvem du skal spørge, hvem du skal ringe til, hvor du skal henvende dig og generelt, hvor du skal søge information, og om den er relevant.
Det andet problem er information - der er meget af det, det er i forskellige kilder, det er ikke altid tilgængeligt og har brug for konstant tilføjelse og opdatering.
Virksomheden har næsten 500 ansatte, de er placeret på forskellige kontorer, tidszoner, byer i Rusland og endda i udlandet, der er normalt mange spørgsmål, så en anden opgave er at reducere byrden på HR-personale i forbindelse med de hyppigste stillede spørgsmål af medarbejdere.
Det var også nødvendigt at automatisere processerne med: nytilkomne, der meldte sig ind i virksomheden, sende beskeder til ledere og mentorer for nyankomne, sende automatiske påmindelser om kurser og tests, som en nytilkommet skal bestå for en vellykket tilpasning.
Tekniske krav blev dannet ud fra forretningskrav.
Botten skal fungere på basis af Skype (historisk set bruger de den i virksomheden), så tjenesten på Azura blev valgt.
For at begrænse adgangen til det begyndte vi at bruge autorisationsmekanismen via Skype.
ParlAI-biblioteket blev brugt til tekstgenkendelse
En administrativ webportal er også påkrævet til konfiguration, træning, fejlretning, opsætning af mails og andre opgaver.
Under arbejdet med projektet stødte vi på en række problemer og vanskeligheder.
For eksempel var der tekniske problemer med en Azure-konto. Microsoft ønskede ikke at aktivere vores abonnement på grund af nogle tekniske problemer i deres tjeneste. I næsten to måneder kunne vi ikke gøre noget ved det; Microsoft-support rakte til sidst hænderne op og sendte os til partnere, som med succes konfigurerede alt og gav os en konto.
Den sværeste fase var starten på projektet, hvor du skal vælge, hvad vi vil bruge, hvad arkitekturen skal være, hvordan og hvor data skal lagres, og hvordan systemets komponenter og moduler vil interagere med hinanden.
I vores tilfælde blev de i det væsentlige almindelige problemer ved at starte et projekt yderligere kompliceret af personale. Specifikationerne i vores forretning er sådan, at i modsætning til kommercielle, bliver interne projekter ofte bearbejdet af udviklere, der ikke har tilstrækkelig viden på de nødvendige områder - de endte simpelthen efter skæbnens vilje på bænken og ventede på det næste. stort fedt kommercielt projekt. Det er logisk, at det også var meget svært med motivation i sådan en situation. Produktiviteten falder lavt, teamet er ofte ledigt, og som følge heraf skal du overtale (motivere) eller ændre personen. Når du skifter udviklere, skal du gennemføre træning, overføre viden og i det væsentlige starte projektet igen. Hver ny udvikler så arkitekturen på sin egen måde og skældte de tidligere ud for de beslutninger, de tog, og andres kode. Omskrivningen begyndte fra bunden.
Dette fortsatte i omkring seks måneder. Vi markerede bare tid, refaktorerede koden og skrev ikke noget nyt.
Også på interne projekter er der som regel næsten ingen dokumentation, og det var svært at forstå, hvad der skal gøres på hvert tidspunkt, og hvad de aktuelle prioriteter er. Det var nødvendigt at oprette et fast team, etablere processer og gennemføre planlægning og evaluering i mindst tre måneder. Men hvordan gør man det, når projektet ikke er kommercielt, hvilket betyder, at man skal investere et minimum af mandetimer, og samtidig får resultatet ikke dårligere end for en ekstern kunde?
Vi har identificeret en pulje af ressourcer, som har deltaget i udviklingen af projektet, er fortrolige med det og ønsker at arbejde med det. Vi har udarbejdet en tidsplan for ansættelse af folk på projekter. Vi vurderede og koordinerede arbejdet og indpassede disse værker i ”hullerne” mellem hovedprojekterne. Efter 4 måneder modtog vi en fungerende prototype af ansøgningen.
Lad os nu tale mere detaljeret om botens funktionalitet, arkitektur og tekniske løsninger.
Et af hovedkravene til HR var at genkende teksten skrevet af brugeren for at svare korrekt på spørgsmålet. Du kan skrive til ham - jeg vil på ferie, jeg vil på ferie eller vil gerne på ferie, og han vil forstå og svare derefter. Eller pludselig går en medarbejders stol i stykker, og han vil skrive "stolen er gået i stykker" eller "Min stol er revnet" eller "Ryggen af stolen er faldet af"; med den rette træning vil botten genkende sådanne anmodninger. Kvaliteten af selve tekstgenkendelsen afhænger af bottens træning, som vi vil tale om senere.
Det næste krav og en del af funktionaliteten er botens dialogsystem. Der blev udviklet et system, hvor botten kan føre en dialog og forstå konteksten af det aktuelle problem. Som svar på dit spørgsmål kan han stille opklarende spørgsmål og fortsætte samtalen, hvis vi har trænet botten til at gøre dette. Skype understøtter enkle menuindstillinger for at bede brugere om muligheder for at fortsætte samtaler. Også, hvis vi havde en dialog, men pludselig besluttede at stille et spørgsmål uden for emnet, vil botten også forstå dette.
Botten gør det muligt at sende forskellige artefakter til brugeren baseret på dennes personlige data. For eksempel på hans sted. Antag, at hvis en person ville finde et toilet, ville han få vist et kontorkort, der fører ham til toilettet. Og kortet vil blive valgt afhængigt af hvilket firmakontor medarbejderen er placeret på.
En af de vigtigste opgaver er at beskytte brugernes personlige oplysninger. Vi kan ikke tillade enhver person at få adgang til de følsomme data, som vores bot driver. Behovet for autorisation til en sådan bot er en integreret del af det. Botten beder brugeren om at autentificere, før han kan føre nogen dialog med ham. Dette sker første gang en medarbejder kontakter botten. Selve autorisationen omdirigerer brugeren til den relevante side, hvor brugeren modtager et token, som han derefter indsætter i en Skype-besked. Hvis godkendelsen lykkes, kan du begynde at kommunikere med botten.
Autorisation sker gennem Skype - portalautorisationstjeneste, firmanetværk og LDAP. Autorisationen afhænger således af de aktuelle brugerdata på virksomhedens netværk.
I processen med at udvikle botten indså vi, at vi havde brug for en form for system indbygget i portalfunktionaliteten, som kunne hjælpe HR med hurtigt at fejlsøge botten. Vi har tilføjet en portalside, hvor HR kan se fejl registreret af brugere, når de arbejder med botten, og løse dem ved hjælp af genoptræning eller overlade dem til udviklere.
Muligheden for at træne en bot direkte på portalen var ikke inkluderet fra begyndelsen. Under udviklingsprocessen indså vi, at træning af botten er den mest almindelige opgave, som medarbejdere i HR-afdelingen vil udføre, når de arbejder med den, og det er fuldstændig uacceptabelt at sende tekstfiler til udviklere for yderligere træning af botten. Dette æder for meget tid og skaber for mange fejl og problemer.
Vi skrev en UI på portalen til Brugervenlig træning af botten. Det giver HR mulighed for at se botens aktuelle træning, videreuddanne den og foretage justeringer af den aktuelle træning. Træning er repræsenteret af en træstruktur, hvor noder, det vil sige grene, er en fortsættelse af dialogen med botten. Du kan skabe simple spørgsmål og svar, eller du kan skabe vægtige dialoger, det hele afhænger af HR og deres behov.
Et par ord om løsningsarkitekturen.
Løsningsarkitekturen er modulopbygget. Det omfatter tjenester med ansvar for forskellige opgaver, nemlig:
• Skype bot-tjeneste på Azure - accepterer og behandler brugeranmodninger. Dette er en ret simpel tjeneste, der er den første til at modtage en anmodning og udføre dens indledende behandling.
• Admin portal - en tjeneste, der giver en webgrænseflade til opsætning af portalen og til selve botten. Botten kontakter altid portalen først, og portalen beslutter, hvad den næste gang skal gøre med anmodningen.
• Autorisationstjeneste - giver godkendelsesmekanismer til botten og for adminportalen. Godkendelse sker via Oauth2-protokollen. Ved positiv autorisation udfører tjenesten autorisation i virksomhedens netværk i henhold til gyldige brugerdata, således at systemet kan kontrollere fejl forbundet med data ude af sync.
• AI-tekstgenkendelsesmodul, skrevet i Python og ved hjælp af ParlAI-rammeværket til selve tekstgenkendelse. Dette er et neuralt netværk, i det mindste i dets nuværende implementering. Vi bruger tfDiff-algoritmen til at forstå spørgsmålene. Modulet giver et API til at kommunikere med det og lære.
Afslutningsvis vil jeg sige, at dette er vores første erfaring med at lave en chatbot, og vi forsøgte at gøre systemet så enkelt som muligt, men samtidig funktionelt, med minimale arbejdsomkostninger på det. Jeg synes, vi har et meget interessant produkt. Med sit eget træningssystem, fejllogning, afsendelse af notifikationer kan den også integreres med enhver anden messenger.
Kilde: www.habr.com