Rok temu nasz kochany dział HR zwrócił się do nas z prośbą: abyśmy napisali chatbota, który pomoże nowym pracownikom w adaptacji do firmy.
Załóżmy, że nie rozwijamy własnych produktów, ale zapewniamy naszym klientom pełen zakres usług rozwojowych. Historia będzie dotyczyć naszego wewnętrznego projektu, dla którego klientem nie jest firma zewnętrzna, ale nasz własny HR. A głównym zadaniem, biorąc pod uwagę ograniczoną dostępność ludzi, zasobów, czasu, jest ukończenie projektu na czas i wydanie produktu.
Najpierw opiszmy zadania, które należało rozwiązać.
Programiści są w większości introwertykami i nie lubią rozmawiać, znacznie łatwiej jest napisać pytanie na czacie elektronicznym. Z botem nie musisz myśleć o tym, kogo zapytać, do kogo zadzwonić, dokąd pójść i ogólnie, gdzie szukać informacji i czy są one istotne.
Drugim problemem jest informacja - jest jej dużo, pochodzi z różnych źródeł, nie zawsze jest dostępna i wymaga ciągłego uzupełniania i aktualizacji.
Firma zatrudnia prawie 500 pracowników, którzy rozlokowani są w różnych biurach, strefach czasowych, miastach w Rosji, a nawet za granicą. Zazwyczaj jest dużo pytań, więc kolejnym zadaniem jest odciążenie personelu HR, związanego z najczęściej zadawanymi przez pracowników pytaniami.
Należało także zautomatyzować procesy: przyjmowania nowych pracowników do firmy, wysyłania wiadomości do managerów i opiekunów nowych pracowników, wysyłania automatycznych przypomnień o kursach i testach, które musi zdać nowy pracownik, aby pomyślnie się zaaklimatyzować.
Na podstawie wymagań biznesowych ustalono wymagania techniczne.
Bot ma działać w oparciu o Skype'a (historycznie tak się składa, że firma z niego korzysta), dlatego wybrano obsługę na platformie Azure.
Aby ograniczyć do niego dostęp, zaczęliśmy używać mechanizmu autoryzacji Skype'a.
Do rozpoznawania tekstu wykorzystano bibliotekę ParlAI.
Do konfiguracji, szkolenia, debugowania, konfiguracji poczty i innych zadań wymagany jest również administracyjny portal internetowy.
W trakcie pracy nad projektem napotkaliśmy szereg problemów i trudności.
Na przykład były problemy techniczne z kontem Azure. Microsoft nie chciał aktywować naszej subskrypcji z powodu pewnych trudności technicznych w ramach swojej usługi. Przez prawie dwa miesiące nie mogliśmy nic z tym zrobić, w końcu pomoc techniczna Microsoftu rozłożyła ręce i wysłała nas do partnerów, którzy pomyślnie wszystko skonfigurowali i dali nam konto.
Najtrudniejszym etapem był początek projektu, gdy trzeba było wybrać, co wykorzystać, jaka będzie architektura, jak i gdzie przechowywać dane oraz w jaki sposób komponenty i moduły systemu będą ze sobą oddziaływać.
W naszym przypadku typowe problemy związane z rozpoczęciem każdego projektu komplikowała obsada kadrowa. Specyfika naszej działalności jest taka, że w przeciwieństwie do komercyjnych, nad projektami wewnętrznymi często pracują developerzy, którzy nie mają wystarczającej wiedzy w wymaganych obszarach - po prostu z woli losu znaleźli się na ławce rezerwowych, czekając na kolejny duży fajny projekt komercyjny. Logicznie rzecz biorąc, w takiej sytuacji było też dość trudno z motywacją. Produktywność spada nisko, zespół często stoi w miejscu, a w efekcie trzeba przekonać (zmotywować) lub zmienić osobę. Zmieniając developera, trzeba przeprowadzić szkolenie, przekazać wiedzę i w zasadzie zacząć projekt od nowa. Każdy nowy developer widział architekturę na swój sposób i strofował poprzednich za podejmowane przez nich decyzje i czyjś kod. Przepisywanie zaczynało się od zera.
Trwało to około sześciu miesięcy. Po prostu odmierzaliśmy czas, refaktoryzowaliśmy kod i nie pisaliśmy niczego nowego.
Ponadto projekty wewnętrzne zazwyczaj nie mają prawie żadnej dokumentacji i trudno było zrozumieć, co należy zrobić w danym momencie i jakie są obecnie priorytety. Trzeba było stworzyć stały zespół, ustalić procesy, prowadzić planowanie i ewaluację przez co najmniej trzy miesiące. Ale jak to zrobić, gdy projekt nie jest komercyjny, co oznacza, że trzeba zainwestować roboczogodziny do minimum, a jednocześnie uzyskać wynik nie gorszy niż dla zewnętrznego klienta?
Zidentyfikowaliśmy pulę zasobów, które uczestniczyły w rozwoju projektu, są z nim zaznajomione i chcą nad nim pracować. Stworzyliśmy harmonogram zatrudnienia ludzi w projektach. Oceniliśmy i skoordynowaliśmy pracę, a następnie wprowadziliśmy tę pracę do „dziur” między głównymi projektami. W ciągu 4 miesięcy otrzymaliśmy działający prototyp aplikacji.
Przyjrzyjmy się teraz bliżej funkcjonalności, architekturze i rozwiązaniom technicznym bota.
Jednym z głównych wymagań HR było rozpoznawanie tekstu napisanego przez użytkownika, aby poprawnie odpowiedzieć na pytanie. Możesz napisać do niego - Chcę iść na urlop, Chcę iść na urlop lub Chciałbym iść na urlop, a on zrozumie i odpowie odpowiednio. Albo nagle pracownikowi zepsuło się krzesło i chce napisać - "krzesło się zepsuło" lub "Moje krzesło pękło" lub "Oparcie krzesła odpadło", przy odpowiednim szkoleniu bot rozpozna takie prośby. Jakość rozpoznawania tekstu zależy naturalnie od szkolenia bota, o którym porozmawiamy później.
Kolejnym wymogiem i częścią funkcjonalności jest system dialogowy bota. Opracowano system, w którym bot może prowadzić dialog i rozumieć kontekst bieżącego pytania. Może zadawać pytania wyjaśniające w odpowiedzi na Twoje pytanie i kontynuować konwersację, jeśli wyszkoliliśmy bota, aby to robił. Skype obsługuje proste elementy menu, aby informować użytkowników o możliwych opcjach kontynuowania dialogów. Ponadto, jeśli prowadziliśmy dialog, ale nagle zdecydowaliśmy się zadać pytanie niezwiązane z tematem, bot również to zrozumie.
Bot umożliwia wysyłanie różnych artefaktów użytkownikowi na podstawie jego danych osobowych. Na przykład jego lokalizacji. Powiedzmy, że osoba chciałaby znaleźć toaletę, zostanie jej pokazana mapa biura prowadząca ją do toalety. A mapa 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ć każdej osobie na dostęp do poufnych danych, którymi operuje nasz bot. Konieczność autoryzacji dla takiego bota jest jego integralną częścią. Bot prosi użytkownika o przekazanie autoryzacji, zanim będzie mógł przeprowadzić z nim jakikolwiek dialog. Dzieje się tak, gdy pracownik po raz pierwszy kontaktuje się 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 się powiedzie, możesz rozpocząć komunikację z botem.
Autoryzacja odbywa się za pośrednictwem Skype - portal - usługa autoryzacji, sieć korporacyjna i LDAP. Autoryzacja zależy zatem od aktualnych danych o użytkowniku w sieci korporacyjnej.
Podczas opracowywania bota zdaliśmy sobie sprawę, że potrzebujemy systemu wbudowanego w funkcjonalność portalu, który mógłby pomóc HR w szybkim debugowaniu bota. Dodaliśmy stronę portalu, na której HR-owcy mogą zobaczyć błędy zarejestrowane przez użytkowników podczas pracy z botem i rozwiązać je poprzez ponowne przeszkolenie lub pozostawienie ich deweloperom.
Możliwość trenowania bota bezpośrednio na portalu nie była uwzględniona od samego początku. Podczas procesu rozwoju zdaliśmy sobie sprawę, że trenowanie bota jest najczęstszym zadaniem, jakie pracownicy HR będą wykonywać podczas pracy z nim, a wysyłanie plików z tekstem do deweloperów w celu dodatkowego przeszkolenia bota jest całkowicie niedopuszczalne. Zabiera to zbyt dużo czasu i generuje zbyt wiele błędów i problemów.
Napisaliśmy interfejs użytkownika na portalu do przyjaznego użytkownikowi szkolenia botów. Pozwala on HR zobaczyć bieżące szkolenie bota, szkolić go dalej i wprowadzać zmiany do bieżącego szkolenia. Szkolenie jest prezentowane jako struktura drzewa, w którym węzły, tj. gałęzie, są kontynuacją dialogu z botem. Możesz tworzyć proste pytania i odpowiedzi lub ciężkie dialogi, wszystko zależy od HR i ich potrzeb.
Kilka słów o architekturze rozwiązania.
Architektura rozwiązania jest modułowa. Obejmuje usługi odpowiedzialne za różne zadania, mianowicie:
• Usługa Skype bot na platformie Azure — akceptuje i przetwarza żądania użytkowników. Jest to dość prosta usługa, która najpierw akceptuje żądanie i wykonuje jego wstępne przetwarzanie.
• Portal administracyjny to usługa, która zapewnia interfejs sieciowy do konfigurowania portalu i samego bota. Bot zawsze najpierw kontaktuje się z portalem, a portal następnie decyduje, co zrobić z żądaniem.
• Usługa autoryzacji — zapewnia mechanizmy uwierzytelniania dla bota i portalu administracyjnego. Autoryzacja odbywa się za pośrednictwem protokołu Oauth2. Jeśli autoryzacja jest pozytywna, usługa wykonuje autoryzację w sieci korporacyjnej zgodnie z prawidłowymi danymi użytkownika, dzięki czemu system może kontrolować błędy związane z desynchronizacją danych.
• Moduł rozpoznawania tekstu AI, napisany w Pythonie i wykorzystujący framework ParlAI do samego rozpoznawania tekstu. Jest to sieć neuronowa, przynajmniej w obecnej implementacji. Używamy algorytmu tfDiff, aby zrozumieć pytania. Moduł zapewnia API do komunikacji z nim i nauki.
Podsumowując, chcę powiedzieć, że jest to nasze pierwsze doświadczenie w tworzeniu chatbota i staraliśmy się, aby system był możliwie najprostszy, ale jednocześnie funkcjonalny, przy minimalnych kosztach pracy. Myślę, że mamy bardzo interesujący produkt. Dzięki własnemu systemowi szkoleniowemu, rejestrowaniu błędów, wysyłaniu powiadomień można go również zintegrować z dowolnym innym komunikatorem.
Źródło: www.habr.com
