For et år siden ba vår kjære HR-avdeling oss om å skrive en chat-bot som skulle hjelpe med tilpasningen av nykommere til selskapet.
La oss ta forbehold om at vi ikke utvikler våre egne produkter, men vi gir kundene et komplett spekter av utviklingstjenester. Historien skal handle om vårt interne prosjekt, som kunden ikke er et tredjepartsselskap for, men vår egen HR. Og hovedoppgaven, gitt den begrensede tilgjengeligheten av mennesker, ressurser og tid, er å fullføre prosjektet i tide og frigi produktet.
La oss først beskrive problemene som måtte løses.
Utviklere er stort sett introverte mennesker og liker ikke å snakke; det er mye lettere å skrive spørsmålet ditt i en e-postchat. Med en bot trenger du ikke tenke på hvem du skal spørre, hvem du skal ringe, hvor du skal dra, og generelt hvor du skal lete etter informasjon og om den er relevant.
Det andre problemet er informasjon - det er mye av det, det er i forskjellige kilder, det er ikke alltid tilgjengelig og trenger konstant tillegg og oppdatering.
Selskapet har nesten 500 ansatte, de er lokalisert på forskjellige kontorer, tidssoner, byer i Russland og til og med i utlandet, det er vanligvis mange spørsmål, så en annen oppgave er å redusere belastningen på HR-personell knyttet til de hyppigste spørsmålene som stilles av ansatte.
Det var også nødvendig å automatisere prosessene med: nykommere som meldte seg inn i selskapet, sende meldinger til ledere og mentorer for nykommere, sende automatiske påminnelser om kurs og tester som en nykommer må bestå for vellykket tilpasning.
Tekniske krav ble dannet basert på forretningskrav.
Boten må fungere på grunnlag av Skype (historisk sett bruker de den i selskapet), så tjenesten på Azura ble valgt.
For å begrense tilgangen til den begynte vi å bruke autorisasjonsmekanismen via Skype.
ParlAI-biblioteket ble brukt til tekstgjenkjenning
En administrativ nettportal er også nødvendig for konfigurering, opplæring, feilsøking, oppsett av utsendelser og andre oppgaver.
Mens vi jobbet med prosjektet, møtte vi en rekke problemer og vanskeligheter.
For eksempel var det tekniske problemer med en Azure-konto. Microsoft ønsket ikke å aktivere abonnementet vårt på grunn av noen tekniske problemer med tjenesten deres. I nesten to måneder kunne vi ikke gjøre noe med det; Microsofts support rakk til slutt opp og sendte oss til partnere, som satte opp alt og ga oss en konto.
Det vanskeligste stadiet var starten på prosjektet, når du må velge hva vi skal bruke, hva arkitekturen skal være, hvordan og hvor data skal lagres, og hvordan komponentene og modulene i systemet skal samhandle med hverandre.
I vårt tilfelle ble de i hovedsak ordinære problemer med å starte ethvert prosjekt ytterligere komplisert av bemanning. Spesifikasjonene til virksomheten vår er slik at, i motsetning til kommersielle, blir interne prosjekter ofte jobbet med av utviklere som ikke har tilstrekkelig kunnskap på de nødvendige områdene - de rett og slett, etter skjebnens vilje, havnet på benken og ventet på neste stort kult kommersielt prosjekt. Det er logisk at det også var veldig vanskelig med motivasjon i en slik situasjon. Produktiviteten synker lavt, teamet er ofte inaktivt, og som et resultat må du overtale (motivere) eller endre personen. Når du bytter utviklere, må du gjennomføre opplæring, overføre kunnskap og i hovedsak starte prosjektet på nytt. Hver nye utvikler så arkitekturen på sin egen måte og skjelte ut de forrige for beslutningene de tok og andres kode. Omskrivingen begynte fra bunnen av.
Dette pågikk i omtrent seks måneder. Vi markerte bare tid, refaktorerte koden og skrev ikke noe nytt.
Også på interne prosjekter er det som regel nesten ingen dokumentasjon, og det var vanskelig å forstå hva som må gjøres på hvert tidspunkt, og hva de nåværende prioriteringene er. Det var nødvendig å opprette et fast team, etablere prosesser og gjennomføre planlegging og evaluering i minst tre måneder. Men hvordan gjøre dette når prosjektet ikke er kommersielt, noe som betyr at du må investere minimum arbeidstimer, og samtidig få resultatet ikke dårligere enn for en ekstern kunde?
Vi har identifisert en ressurssamling som deltok i utviklingen av prosjektet, er kjent med det og ønsker å jobbe med det. Vi har laget en tidsplan for ansettelse av personer på prosjekter. Vi vurderte og koordinerte arbeidet, og passet disse arbeidene inn i «hullene» mellom hovedprosjektene. Etter 4 måneder mottok vi en fungerende prototype av søknaden.
La oss nå snakke mer detaljert om botens funksjonalitet, arkitektur og tekniske løsninger.
Et av hovedkravene til HR var å gjenkjenne teksten skrevet av brukeren for å svare riktig på spørsmålet. Du kan skrive til ham - jeg ønsker å reise på ferie, jeg vil på ferie eller ønsker å reise på ferie, og han vil forstå og svare deretter. Eller plutselig knekker en ansatts stol og han vil skrive "stolen er ødelagt" eller "stolen min er sprukket" eller "stolryggen har falt av"; med riktig opplæring vil boten gjenkjenne slike forespørsler. Kvaliteten på tekstgjenkjenningen i seg selv avhenger av treningen til boten, som vi vil snakke om senere.
Det neste kravet og en del av funksjonaliteten er robotens dialogsystem. Det ble utviklet et system der boten kan føre en dialog og forstå konteksten til det aktuelle problemet. Som svar på spørsmålet ditt kan han stille eventuelle oppklarende spørsmål og fortsette samtalen hvis vi har trent opp roboten til å gjøre dette. Skype støtter enkle menyalternativer for å spørre brukere om alternativer for å fortsette samtaler. Dessuten, hvis vi hadde en dialog, men plutselig bestemte oss for å stille et spørsmål utenfor emnet, vil roboten også forstå dette.
Boten gjør det mulig å sende ulike artefakter til brukeren basert på hans personlige data. For eksempel på stedet hans. Anta at hvis en person ønsket å finne et toalett, ville han bli vist et kontorkart som fører ham til toalettet. Og kortet vil bli valgt avhengig av hvilket firmakontor den ansatte befinner seg på.
En av de viktigste oppgavene er å beskytte brukernes personopplysninger. Vi kan ikke la alle få tilgang til de sensitive dataene som boten vår driver. Behovet for autorisasjon for en slik bot er en integrert del av den. Boten ber brukeren om å autentisere før han kan føre noen dialog med ham. Dette skjer første gang en ansatt kontakter boten. Selve autorisasjonen omdirigerer brukeren til den aktuelle siden, hvor brukeren mottar et token, som han deretter setter inn i en Skype-melding. Hvis autorisasjonen er vellykket, kan du begynne å kommunisere med boten.
Autorisasjon skjer gjennom Skype – portalautorisasjonstjeneste, bedriftsnettverk og LDAP. Autorisasjonen avhenger derfor av gjeldende brukerdata på bedriftsnettverket.
I prosessen med å utvikle boten innså vi at vi trengte et slags system innebygd i portalfunksjonaliteten som kunne hjelpe HR med å raskt feilsøke boten. Vi har lagt til en portalside der HR kan se feil registrert av brukere når de jobber med boten og løse dem ved hjelp av omskolering eller overlate dem til utviklere.
Muligheten til å trene en bot direkte på portalen var ikke inkludert helt fra begynnelsen. Under utviklingsprosessen innså vi at opplæring av boten er den vanligste oppgaven som ansatte i HR-avdelingen vil utføre når de jobber med den, og å sende tekstfiler til utviklere for ytterligere opplæring av boten er helt uakseptabelt. Dette spiser opp for mye tid og skaper for mange feil og problemer.
Vi skrev et brukergrensesnitt på portalen for Brukervennlig opplæring av boten. Den lar HR se botens nåværende trening, trene den videre og foreta justeringer til gjeldende trening. Trening er representert av en trestruktur der noder, det vil si grener, er en fortsettelse av dialogen med boten. Du kan lage enkle spørsmål og svar, eller du kan skape tungtveiende dialoger, alt avhenger av HR og deres behov.
Noen få ord om løsningsarkitekturen.
Løsningsarkitekturen er modulær. Det inkluderer tjenester med ansvar for ulike oppgaver, nemlig:
• Skype bot-tjeneste på Azure – godtar og behandler brukerforespørsler. Dette er en ganske enkel tjeneste som er den første som mottar en forespørsel og utfører den første behandlingen.
• Admin portal - en tjeneste som gir et nettgrensesnitt for å sette opp portalen og for selve boten. Boten kontakter alltid portalen først, og portalen bestemmer hva den skal gjøre videre med forespørselen.
• Autorisasjonstjeneste – gir autentiseringsmekanismer for boten og for adminportalen. Autorisasjon skjer via Oauth2-protokollen. Ved positiv autorisasjon utfører tjenesten autorisasjon i bedriftsnettverket i henhold til gyldige brukerdata, slik at systemet kan kontrollere feil knyttet til data ute av synkronisering.
• AI-tekstgjenkjenningsmodul, skrevet i Python og bruker ParlAI-rammeverket for selve tekstgjenkjenning. Dette er et nevralt nettverk, i det minste i den nåværende implementeringen. Vi bruker tfDiff-algoritmen for å forstå spørsmålene. Modulen gir et API for å kommunisere med den og lære.
Avslutningsvis vil jeg si at dette er vår første erfaring med å lage en chat-bot, og vi prøvde å gjøre systemet så enkelt som mulig, men samtidig funksjonelt, med minimale arbeidskostnader på det. Jeg synes vi har et veldig interessant produkt. Med eget treningssystem, feillogging, varslingssending kan den også integreres med en hvilken som helst annen messenger.
Kilde: www.habr.com