Boten vil hjelpe oss

For ett år siden ba vår kjære HR-avdeling oss om å skrive en chatbot som kan hjelpe nykommere med å tilpasse seg i selskapet.

Vi må presisere at vi ikke utvikler egne produkter, men tilbyr kundene et komplett spekter av utviklingstjenester. Historien handler om vårt interne prosjekt, hvor kunden ikke er et tredjepartsfirma, men vår egen HR. Hovedoppgaven er å gjennomføre prosjektet i tide og utgi produktet, til tross for begrenset tilgjengelighet av folk, ressurser og tid.

La oss først beskrive oppgavene som måtte løses.

Utviklerne er i sin natur introverte og liker ikke å snakke, det er mye lettere å skrive spørsmålet sitt i en elektronisk chat. Med boten slipper man å tenke på hvem man skal spørre, hvem man skal ringe, hvor man skal gå, og generelt hvor man skal finne informasjon, og om den er relevant.

Det andre problemet er informasjon — det er mye av den, den er spredt over forskjellige kilder, finnes ikke alltid og trenger kontinuerlig oppdatering og supplement.

Selskapet har nesten 500 ansatte som befinner seg i forskjellige kontorer, tidssoner, byer i Russland og til og med i utlandet, spørsmålene er vanligvis mange, så enda en oppgave er å redusere belastningen på HR-personalet knyttet til de mest stilte spørsmålene fra ansatte.

Det var også nødvendig å automatisere prosessene: nykommere som kommer til selskapet, utsendelse av meldinger til ledere og mentorer for nykommere, samt å sende automatiske påminnelser om kurs og tester som nykommere må ta for å tilpasse seg vellykket.

Basert på forretningskravene ble de tekniske kravene formulert.

Boten må operere på Skype (historisk har det blitt brukt i selskapet), derfor ble Azure valgt som tjeneste.

For tilgangsbegrensninger begynte vi å bruke en autorisasjonsmekanisme via Skype.
For tekstgjenkjenning brukte vi biblioteket ParlAI.

Det var også behov for et administrativt webportal for konfigurasjon, opplæring, debugging, innstilling av utsendelser og andre oppgaver.

I løpet av arbeidet med prosjektet støtte vi på en rekke problemer og utfordringer.

For example, we faced technical issues with our Azure account. Microsoft was unwilling to activate our subscription due to some internal technical difficulties within their service. For almost two months, we couldn't resolve this, and Microsoft's support eventually shrugged and referred us to partners who successfully configured everything and provided us with the account.

The most challenging phase was the project's kickoff, where we had to decide what to use, what the architecture would be, how and where to store the data, and how the system's components and modules would interact with each other.

In our case, the usual challenges of starting any project were further complicated by staffing issues. The nature of our business is such that, unlike commercial projects, internal projects are often tackled by developers who lack sufficient expertise in the necessary areas—they simply found themselves on the bench waiting for the next big commercial project. It's logical that motivation in such situations was also quite low. Productivity dropped significantly, team members often faced idle time, and ultimately, we had to persuade (motivate) or replace people. When swapping developers, we had to conduct training, transfer knowledge, and effectively restart the project. Each new developer viewed the architecture differently and criticized the prior team's decisions and code. Rewriting everything from scratch began.

This continued for about six months. We were simply treading water, refactoring code without producing anything new.

Additionally, internal projects usually have almost no documentation, making it difficult to understand what needed to be done at any given moment and what the current priorities were. It was essential to establish a permanent team, streamline processes, and conduct planning and evaluation for at least three months. But how can this be accomplished when the project is not commercial, meaning that human resources need to be minimized, while still achieving results that match those for external clients?

Vi har definert et ressurspool som deltok i utviklingen av prosjektet, er kjent med det og ønsker å jobbe med det. Vi har laget en timeplan for folks tilgjengelighet på prosjektene. Vi har utført vurdering og avtalt arbeider, og skrevet disse arbeidene inn i 'hullene' mellom hovedprosjektene. Etter 4 måneder fikk vi en fungerende prototype av applikasjonen.

La oss nå gå mer i dybden på botens funksjonalitet, arkitekturen og de tekniske løsningene.

Et av hovedkravene fra HR var å gjenkjenne tekst skrevet av brukeren for å gi et korrekt svar på spørsmålet. Man kan skrive - jeg ønsker å ta ferie, jeg vil ta ferie eller jeg vil gjerne ta ferie, og den vil forstå det og svare deretter. Eller hvis en ansatt for eksempel har ødelagt stolen sin, og ønsker å skrive - 'stolen er ødelagt' eller 'stolen knakk' eller 'ryggen på stolen falt av', med riktig opplæring vil boten kunne gjenkjenne slike forespørsel. Kvaliteten på tekstgjenkjenning avhenger selvfølgelig av botens opplæring, som vi vil snakke mer om senere.

Det neste kravet og en del av funksjonaliteten er systemet for dialoger med boten. Det ble utviklet et system der boten kan føre en dialog og forstå konteksten av det nåværende spørsmålet. Den kan stille oppfølgingsspørsmål som svar på ditt spørsmål og fortsette samtalen, hvis vi har lært boten å gjøre dette. Skype støtter enkle menyvalg som hjelper brukerne med mulige alternativer for å fortsette dialogene. Dersom vi har vært i dialog, men plutselig bestemmer oss for å stille et spørsmål utenfor tema, så vil boten også forstå dette.

Boten gir mulighet til å sende forskjellige artefakter til brukeren, basert på deres personlige data. For eksempel, basert på deres plassering. La oss anta at en person ønsker å finne toalettet, så vil det bli vist et kart over kontoret som leder dem til toalettet. Og kartet vil bli valgt avhengig av hvilket kontor selskapet den ansatte befinner seg i.

En av de viktigste oppgavene er å beskytte brukernes personlige informasjon. Vi kan ikke la hvem som helst få tilgang til konfidensielle data som vår bot håndterer. Behovet for autorisasjon for en slik bot er en uunngåelig del av den. Boten ber brukeren om å gjennomføre autorisasjon før de kan føre en samtale med den. Dette skjer ved første henvendelse fra en ansatt til boten. Selve autorisasjonen omdirigerer brukeren til den relevante siden, hvor brukeren mottar en token som deretter settes inn i Skype-meldingen. Hvis autorisasjonen er vellykket, kan samtalen med boten begynne.

Autorisasjonen skjer via Skype – portalen for autorisasjonstjenester, bedriftsnettverket og LDAP. Dermed avhenger autorisasjonen av de nåværende dataene om brukeren i bedriftsnettverket.

I løpet av utviklingen av boten innså vi at det trengs et system innebygd i portalens funksjonalitet, som kan hjelpe HR med å raskt feilsøke boten. Vi la til en slik side i portalen, hvor HR-ansatte kan se feil registrert av brukerne under samhandling med boten og løse dem ved å justere opplæringen eller la dem være for utviklerne.

Muligheten for å trene boten direkte på portalen ble ikke inkludert fra begynnelsen. Under utviklingen innså vi at opplæring av boten er den mest vanlige oppgaven som HR-ansatte vil utføre i samhandling med den, og å sende filer med tekst til utviklerne for ytterligere opplæring av boten er helt uakseptabelt. Dette tar for mye tid og genererer for mange feil og problemer.

Vi har skrevet en UI på portalen for brukervennlig opplæring av boten. Den lar HR se botens nåværende opplæring, trene den videre og gjøre justeringer i den nåværende opplæringen. Opplæringen presenteres i en trestruktur der nodene, altså greinene, er fortsettelse av dialogen med boten. Det er mulig å lage enkle spørsmål-svar, eller man kan lage omfattende dialoger, avhengig av hva HR trenger.

Noen ord om løsningen sin arkitektur.

Løsningen har en modulær arkitektur. Den inkluderer tjenester som er ansvarlige for forskjellige oppgaver, nemlig:
• Skype-bot-tjeneste på Azure — mottar og behandler brukerforespørselen. Dette er en ganske enkel tjeneste som først mottar forespørselen og gir den første behandlingen.
• Admin-portalen — en tjeneste som tilbyr et webgrensesnitt for å konfigurere portalen og selve boten. Boten kontakter alltid portalen først, og portalen avgjør deretter hva som skal gjøres med forespørselen.
• Autoriseringstjenesten — gir autentiseringsmekanismer for boten og admin-portalen. Autoriseringen skjer via Oauth2-protokollen. Ved positiv autorisering gjennomfører tjenesten autoriseringen i det profesjonelle nettverket i henhold til gyldige brukerdata, slik at systemet kan kontrollere feil knyttet til datadysynkronisering.
• AI-modul for tekstgjenkjenning, skrevet i Python og bruker rammeverket ParlAI for selve tekstgjenkjenningen. Dette er et nevralt nettverk, i hvert fall i den nåværende implementeringen. Vi bruker tfDiff-algoritmen for å forstå spørsmål. Modulen tilbyr et API for kommunikasjon og trening.

Til slutt vil jeg si at dette er vår første erfaring med å lage en chatbot, og vi har prøvd å gjøre systemet så enkelt som mulig, men samtidig funksjonelt, med minimale arbeidsressurser. Jeg tror vi har fått til et ganske interessant produkt. Med sitt eget opplæringssystem, feillogg og varslinger kan det også integreres med enhver annen meldingstjeneste.

Kilde: habr.com