Rok temu nasz ukochany dział HR poprosił nas o napisanie chat bota, który pomógłby w adaptacji nowicjuszy do firmy.
Zastrzegajmy, że nie rozwijamy własnych produktów, lecz zapewniamy klientom pełen zakres usług deweloperskich. Historia będzie dotyczyła naszego wewnętrznego projektu, dla którego klientem nie jest obca firma, ale nasz własny HR. A głównym zadaniem, biorąc pod uwagę ograniczoną dostępność ludzi, zasobów i czasu, jest terminowe ukończenie projektu i wydanie produktu.
Najpierw opiszemy problemy, które należało rozwiązać.
Programiści to w większości osoby introwertyczne, które nie lubią rozmawiać; znacznie łatwiej jest napisać pytanie na czacie e-mailowym. Dzięki botowi nie musisz zastanawiać się, kogo zapytać, do kogo zadzwonić, gdzie się udać i w ogóle, gdzie szukać informacji i czy są one istotne.
Drugim problemem są informacje – jest ich mnóstwo, znajdują się w różnych źródłach, nie zawsze są dostępne i wymagają ciągłego uzupełniania i aktualizowania.
Firma zatrudnia prawie 500 pracowników, są oni zlokalizowani w różnych biurach, strefach czasowych, miastach Rosji, a nawet za granicą, pytań jest zwykle wiele, dlatego kolejnym zadaniem jest zmniejszenie obciążenia personelu HR związanego z najczęściej zadawanymi pytaniami przez pracowników.
Niezbędna była także automatyzacja procesów: dołączania nowo przybyłych do firmy, wysyłania wiadomości do menedżerów i mentorów nowo przybyłych, wysyłania automatycznych przypomnień o kursach i testach, które nowicjusz musi przejść, aby pomyślnie się zaadaptować.
Wymagania techniczne zostały utworzone w oparciu o wymagania biznesowe.
Bot musi działać w oparciu o Skype'a (historycznie używają go w firmie), dlatego zdecydowano się na usługę na Azurze.
Aby ograniczyć do niego dostęp, zaczęliśmy wykorzystywać mechanizm autoryzacyjny przez Skype.
Do rozpoznawania tekstu wykorzystano bibliotekę ParlAI
Administracyjny portal internetowy jest również wymagany do konfiguracji, szkolenia, debugowania, konfigurowania korespondencji i innych zadań.
Pracując nad projektem napotkaliśmy szereg problemów i trudności.
Na przykład wystąpiły problemy techniczne z kontem Azure. Microsoft nie chciał aktywować naszej subskrypcji ze względu na problemy techniczne w ramach swojej usługi. Przez prawie dwa miesiące nie mogliśmy nic z tym zrobić, w końcu wsparcie Microsoftu rozłożyło ręce i wysłało nas do partnerów, którzy pomyślnie wszystko skonfigurowali i udostępnili nam konto.
Najtrudniejszym etapem był start projektu, kiedy trzeba było wybrać, z czego będziemy korzystać, jaka będzie architektura, jak i gdzie przechowywać dane oraz jak komponenty i moduły systemu będą ze sobą współdziałać.
W naszym przypadku zasadniczo zwykłe problemy związane z rozpoczęciem dowolnego projektu zostały dodatkowo skomplikowane przez personel. Specyfika naszej działalności jest taka, że w odróżnieniu od projektów komercyjnych, nad projektami wewnętrznymi często pracują deweloperzy, którzy nie posiadają wystarczającej wiedzy w wymaganych obszarach – po prostu, zrządzeniem losu, wylądowali na ławce rezerwowych w oczekiwaniu na kolejne duży fajny projekt komercyjny. Logiczne jest, że w takiej sytuacji sprawy z motywacją były również bardzo trudne. Produktywność spada, zespół często stoi bezczynnie, przez co trzeba kogoś przekonać (motywować) lub zmienić. Zmieniając programistę trzeba przeprowadzić szkolenie, przekazać wiedzę i w zasadzie rozpocząć projekt od nowa. Każdy nowy programista widział architekturę na swój sposób i karcił poprzednich za podjęte decyzje i kod innych osób. Przepisywanie zaczęło się od zera.
Trwało to około sześciu miesięcy. Po prostu liczyliśmy czas, refaktoryzowaliśmy kod i nie pisaliśmy niczego nowego.
Również w przypadku projektów wewnętrznych z reguły prawie nie ma dokumentacji i trudno było zrozumieć, co należy zrobić w każdym momencie i jakie są aktualne priorytety. Należało stworzyć stały zespół, ustalić procesy, przeprowadzić planowanie i ewaluację przez co najmniej trzy miesiące. Ale jak to zrobić, gdy projekt nie jest komercyjny, czyli trzeba zainwestować minimum roboczogodzin, a jednocześnie uzyskać efekt nie gorszy niż dla klienta zewnętrznego?
Zidentyfikowaliśmy pulę zasobów, które brały udział w rozwoju projektu, znają ją i chcą nad nią pracować. Opracowaliśmy harmonogram zatrudnienia osób przy projektach. Ocenialiśmy i koordynowaliśmy prace, wpasowując je w „dziury” pomiędzy głównymi projektami. Po 4 miesiącach otrzymaliśmy działający prototyp aplikacji.
Porozmawiajmy teraz bardziej szczegółowo o funkcjonalności bota, architekturze i rozwiązaniach technicznych.
Jednym z głównych wymagań HR było rozpoznanie tekstu napisanego przez użytkownika, aby poprawnie odpowiedzieć na pytanie. Możesz do niego napisać - chcę jechać na wakacje, chcę jechać na wakacje lub chciałbym jechać na wakacje, a on zrozumie i odpowiednio zareaguje. Albo nagle pracownikowi zepsuje się krzesło i chce napisać „krzesło jest zepsute”, „Moje krzesło jest pęknięte” lub „Odpadło oparcie krzesła” – po odpowiednim przeszkoleniu bot rozpozna takie prośby. Jakość samego rozpoznawania tekstu zależy od wyszkolenia bota, o czym porozmawiamy później.
Kolejnym wymaganiem i częścią funkcjonalności jest system dialogowy bota. Opracowano system, w którym bot może prowadzić dialog i rozumieć kontekst aktualnego problemu. W odpowiedzi na Twoje pytanie może zadać dowolne pytania wyjaśniające i kontynuować rozmowę, jeśli przeszkoliliśmy bota, aby to robił. Skype obsługuje proste opcje menu, które wyświetlają użytkownikom monity o opcje kontynuowania rozmów. Ponadto, jeśli prowadziliśmy dialog, ale nagle zdecydowaliśmy się zadać pytanie nie na temat, bot również to zrozumie.
Bot umożliwia wysyłanie użytkownikowi różnych artefaktów na podstawie jego danych osobowych. Na przykład w jego lokalizacji. Załóżmy, że jeśli ktoś chce znaleźć toaletę, zostanie mu pokazana mapa biura prowadząca do toalety. A karta zostanie wybrana w zależności od tego, w którym biurze firmy znajduje się pracownik.
Jednym z najważniejszych zadań jest ochrona danych osobowych użytkowników. Nie możemy pozwolić, aby każda osoba miała dostęp do wrażliwych danych, którymi operuje nasz bot. Potrzeba autoryzacji dla takiego bota jest jego integralną częścią. Bot prosi użytkownika o uwierzytelnienie, zanim będzie mógł z nim przeprowadzić jakikolwiek dialog. Dzieje się tak przy pierwszym kontakcie pracownika z botem. Sama autoryzacja przekierowuje użytkownika na odpowiednią stronę, gdzie użytkownik otrzymuje token, który następnie wstawia do wiadomości Skype. Jeśli autoryzacja przebiegła pomyślnie, możesz rozpocząć komunikację z botem.
Autoryzacja odbywa się poprzez Skype - usługę autoryzacji portalu, sieć firmową i LDAP. Zatem autoryzacja zależy od aktualnych danych użytkownika w sieci firmowej.
W trakcie tworzenia bota zdaliśmy sobie sprawę, że potrzebujemy jakiegoś systemu wbudowanego w funkcjonalność portalu, który pomógłby działowi kadr w szybkim debugowaniu bota. Dodaliśmy stronę portalu, na której HR może zobaczyć błędy zarejestrowane przez użytkowników podczas pracy z botem i rozwiązać je poprzez przeszkolenie lub pozostawić programistom.
Od samego początku nie uwzględniono możliwości szkolenia bota bezpośrednio na portalu. Podczas procesu rozwoju zdaliśmy sobie sprawę, że szkolenie bota jest najczęstszym zadaniem, jakie będą wykonywać pracownicy działu HR podczas pracy z nim, a wysyłanie plików tekstowych do programistów w celu dodatkowego przeszkolenia bota jest całkowicie niedopuszczalne. Pochłania to zbyt wiele czasu i powoduje zbyt wiele błędów i problemów.
Na portalu napisaliśmy interfejs użytkownika umożliwiający przyjazne dla użytkownika szkolenie bota. Dzięki temu dział HR może zobaczyć aktualny trening bota, dalej go szkolić i wprowadzać zmiany w bieżącym szkoleniu. Trening reprezentowany jest przez strukturę drzewiastą, w której węzły, czyli gałęzie, są kontynuacją dialogu z botem. Możesz tworzyć proste pytania i odpowiedzi lub możesz tworzyć ważkie dialogi, wszystko zależy od HR i jego potrzeb.
Kilka słów o architekturze rozwiązania.
Architektura rozwiązania jest modułowa. Obejmuje służby odpowiedzialne za różne zadania, a mianowicie:
• Usługa bota Skype na platformie Azure – akceptuje i przetwarza żądania użytkowników. Jest to dość prosta usługa, która jako pierwsza otrzymuje żądanie i wykonuje jego wstępne przetwarzanie.
• Portal administracyjny – usługa udostępniająca interfejs sieciowy do konfiguracji portalu i samego bota. Bot zawsze jako pierwszy kontaktuje się z portalem, a portal decyduje, co dalej zrobić ze zgłoszeniem.
• Usługa autoryzacji – zapewnia mechanizmy uwierzytelniania dla bota i portalu administracyjnego. Autoryzacja następuje poprzez protokół Oauth2. Przy pozytywnej autoryzacji usługa dokonuje autoryzacji w sieci firmowej na podstawie prawidłowych danych użytkownika, dzięki czemu system może zapanować nad błędami związanymi z brakiem synchronizacji danych.
• Moduł rozpoznawania tekstu AI, napisany w Pythonie i wykorzystujący framework ParlAI do samego rozpoznawania tekstu. Jest to sieć neuronowa, przynajmniej w jej obecnej realizacji. Do zrozumienia pytań używamy algorytmu tfDiff. Moduł udostępnia API umożliwiające komunikację z nim i naukę.
Podsumowując, chcę powiedzieć, że jest to nasze pierwsze doświadczenie w tworzeniu chatbota i staraliśmy się, aby system był jak najprostszy, ale jednocześnie funkcjonalny, przy minimalnych kosztach pracy. Myślę, że mamy bardzo ciekawy produkt. Dzięki własnemu systemowi szkoleń, rejestrowaniu błędów, wysyłaniu powiadomień, można go także zintegrować z dowolnym innym komunikatorem.
Źródło: www.habr.com