Rok temu nasz ulubiony dział HR zwrócił się z prośbą: stworzyć chatbota, który pomoże w adaptacji nowicjuszy w firmie.
Zaznaczmy, że nie opracowujemy własnych produktów, ale klientom oferujemy pełny zakres usług w zakresie rozwoju. Opowiadamy o naszym wewnętrznym projekcie, którego zamawiającym jest nie zewnętrzna firma, ale nasz własny HR. Głównym zadaniem w warunkach ograniczonej dostępności ludzi, zasobów i czasu jest ukończenie projektu na czas i wypuszczenie produktu.
Na początek opiszemy zadania, które należało rozwiązać.
Programiści to w większości introwertycy i nie lubią rozmawiać, znacznie łatwiej jest napisać swoje pytanie w czacie elektronicznym. Z chatbotem nie trzeba myśleć, kogo zapytać, do kogo zadzwonić, dokąd pójść i ogólnie, gdzie szukać informacji oraz czy jest ona aktualna.
Drugim problemem jest sama informacja — jest jej dużo, pochodzi z różnych źródeł, nie zawsze jest dostępna i wymaga ciągłego uzupełniania oraz aktualizacji.
W firmie jest prawie 500 pracowników, znajdują się w różnych biurach, strefach czasowych, miastach Rosji, a nawet za granicą, pytań zwykle jest bardzo dużo, dlatego jeszcze jedno zadanie — zmniejszenie obciążenia personelu HR związane z najczęściej zadawanymi pytaniami przez pracowników.
Należało także zautomatyzować procesy: przybycia nowicjuszy do firmy, wysyłki wiadomości do menedżerów i mentorów nowicjuszy, wysyłki automatycznych przypomnień o kursach i testach, które nowicjusz musi przejść, aby skutecznie się zaadoptować.
Na podstawie wymagań biznesowych zostały sformułowane wymagania techniczne.
Bot musi działać na Skype (historycznie tak się złożyło, że używa się go w firmie), dlatego wybrano usługę na Azure.
W celu ograniczenia dostępu do niego zaczęliśmy korzystać z mechanizmu autoryzacji przez Skype.
Do rozpoznawania tekstu użyto biblioteki ParlAI.
Potrzebny był również administracyjny portal webowy do konfiguracji, szkolenia, debugowania, ustawiania wysyłek oraz innych zadań.
W trakcie pracy nad projektem napotkaliśmy szereg problemów i trudności.
Na przykład, mieliśmy problemy techniczne — z kontem Azure. Microsoft w żaden sposób nie chciał aktywować naszej subskrypcji z powodu jakichś trudności technicznych wewnątrz ich usługi. Prawie przez dwa miesiące nie mogliśmy nic z tym zrobić, wsparcie Microsoftu w końcu rozłożyło ręce i odesłało nas do partnerów, którzy pomyślnie wszystko skonfigurowali i wydali nam konto.
Najtrudniejszym etapem był start projektu, kiedy trzeba było wybrać, co używamy, jaka będzie architektura, jak i gdzie przechowywać dane oraz jak komponenty i moduły systemu będą ze sobą współpracować.
W naszym przypadku typowe problemy związane z rozpoczęciem jakiegokolwiek projektu były dodatkowo komplikowane przez kadry. Specyfika naszego biznesu jest taka, że w przeciwieństwie do projektów komercyjnych, nad projektami wewnętrznymi często pracują deweloperzy, którzy nie mają wystarczającej wiedzy w potrzebnych obszarach – po prostu z powodu okoliczności znaleźli się na etacie czekając na następny duży komercyjny projekt. Logicznym jest, że z motywacją w takiej sytuacji sprawy też nie były proste. Wydajność spada, w zespole często są przestoje, a w końcu trzeba przekonywać (motywować) lub zmieniać pracownika. Przy zmianie dewelopera konieczne jest przeprowadzenie szkoleń, przekazywanie wiedzy i ponowne uruchamianie projektu. Każdy nowy deweloper widział architekturę po swojemu i krytykował poprzednich za ich decyzje i obcy kod. Zaczynało się przepisywanie od nowa.
Tak trwało przez około pół roku. Po prostu tkwiliśmy w miejscu, refaktoryzując kod i nie pisząc nic nowego.
Także w projektach wewnętrznych zazwyczaj nie ma prawie żadnej dokumentacji, więc trudno było zrozumieć, co należy robić w danym momencie oraz jakie są aktualne priorytety. Należało stworzyć stały zespół, usprawnić procesy, przeprowadzić planowanie i ocenę przynajmniej na trzy miesiące. Ale jak to zrobić, gdy projekt nie jest komercyjny, a to oznacza, że trzeba inwestować minimalną ilość godzin roboczych, i jednocześnie uzyskać rezultat nie gorszy niż dla zewnętrznego klienta?
Określiliśmy pulę zasobów, które brały udział w rozwoju projektu, znają go i chcą nad nim pracować. Sporządziliśmy harmonogram zatrudnienia ludzi w projektach. Przeprowadziliśmy ocenę i zatwierdzenie prac, a następnie wpisaliśmy te prace w "dziury" między głównymi projektami. Po 4 miesiącach otrzymaliśmy działający prototyp aplikacji.
Teraz porozmawiajmy szczegółowo o funkcjonalności bota, architekturze i rozwiązaniach technicznych.
Jednym z głównych wymagań HR było rozpoznawanie tekstu napisanego przez użytkownika, aby udzielić poprawnej odpowiedzi na pytanie. Można napisać — chcę iść na urlop, chcę na urlop lub chciałbym pójść na urlop, a bot to zrozumie i odpowie odpowiednio. Albo jeśli pracownik ma zepsute krzesło i chce napisać — "krzesło się zepsuło" lub "Mam krzesło pęknięte" albo "Oparcie krzesła odpadło", przy odpowiednim przeszkoleniu bot rozpozna takie zapytania. Jakość rozpoznawania tekstu zależy oczywiście od przeszkolenia bota, o którym porozmawiamy później.
Kolejnym wymaganiem i częścią funkcjonalności jest system dialogów bota. Opracowano system, w którym bot może prowadzić dialog i rozumieć kontekst aktualnego pytania. Może on w odpowiedzi na twoje pytanie zadać dodatkowe pytania i kontynuować rozmowę, jeśli nauczyliśmy bota to robić. Skype obsługuje proste punkty menu, aby sugerować użytkownikom możliwe opcje kontynuacji dialogów. Również, jeśli prowadziliśmy dialog, ale nagle postanowiliśmy zadać pytanie niezwiązane z tematem, bot również to zrozumie.
Bot daje możliwość przesyłania różnych artefaktów użytkownikowi, w oparciu o jego dane osobowe. Na przykład na podstawie jego lokalizacji. Załóżmy, że osoba chciała znaleźć toaletę, to zostanie jej pokazana mapa biura, prowadząca do toalety. A mapa będzie wybrana w zależności od tego, w jakim biurze firmy znajduje się pracownik.
Jednym z najważniejszych zadań jest ochrona danych osobowych użytkowników. Nie możemy pozwolić, by każdy miał dostęp do poufnych informacji, którymi dysponuje nasz bot. Wymóg autoryzacji dla takiego bota jest integralną częścią jego działania. Bot prosi użytkownika o przeprowadzenie autoryzacji, zanim będzie mógł prowadzić z nim jakikolwiek dialog. Dzieje się to przy pierwszym kontakcie pracownika z botem. Sama autoryzacja przekierowuje użytkownika na odpowiednią stronę, gdzie otrzymuje token, który następnie wstawia do wiadomości na Skype. Jeśli autoryzacja przebiegnie pomyślnie, można rozpocząć rozmowę z botem.
Autoryzacja przebiega przez Skype — portal- authorization service, sieć korporacyjną i LDAP. W ten sposób autoryzacja zależy od bieżących danych o użytkowniku w sieci korporacyjnej.
W trakcie tworzenia bota zrozumieliśmy, że potrzeba jakiegoś systemu, wbudowanego w funkcjonalność portalu, który pomoże HR w szybkim debugowaniu bota. Dodaliśmy taką stronę portalu, na której pracownicy HR mogą zobaczyć błędy zgłoszone przez użytkowników podczas pracy z botem i rozwiązać je poprzez ponowne uczenie lub pozostawić dla programistów.
Możliwość szkolenia bota bezpośrednio na portalu nie była przewidziana od samego początku. W trakcie rozwoju zrozumieliśmy, że uczenie bota to najczęstsze zadanie, jakie będą wykonywać pracownicy działu HR podczas pracy z nim, a wysyłanie plików z tekstem do programistów w celu dodatkowego szkolenia bota jest całkowicie nieakceptowalne. To pochłania zbyt dużo czasu i generuje zbyt wiele błędów i problemów.
Stworzyliśmy interfejs użytkownika na portalu do przyjaznego użytkownikowi uczenia bota. Umożliwia on pracownikom HR monitorowanie bieżącego szkolenia bota, dalsze uczenie go i wprowadzanie korekt do aktualnego szkolenia. Uczenie przedstawione jest w postaci struktury drzewiastej, w której węzły, czyli gałęzie, są kontynuacją dialogu z botem. Można tworzyć proste pytania-odpowiedzi, a także rozbudowane dialogi, wszystko zależy od potrzeb HR.
Kilka słów o architekturze rozwiązania.
Architektura rozwiązania jest modułowa. Składa się z usług odpowiadających za różne zadania, mianowicie:
• Usługa bota Skype na Azure — przyjmuje i przetwarza zapytania użytkowników. To stosunkowo prosty serwis, który jako pierwszy odbiera zapytanie i przeprowadza wstępne przetwarzanie.
• Portals administracyjny — usługa oferująca interfejs webowy do konfiguracji portalu oraz samego bota. Bot zawsze najpierw zwraca się do portalu, a portal decyduje, co dalej robić z zapytaniem.
• Usługa autoryzacji — zapewnia mechanizmy uwierzytelniania dla bota i portalu administracyjnego. Autoryzacja odbywa się zgodnie z protokołem Oauth2. Po pomyślnej autoryzacji usługa przeprowadza weryfikację w sieci korporacyjnej na podstawie poprawnych danych użytkownika, co pozwala systemowi kontrolować błędy związane z niespójnością danych.
• Moduł AI do rozpoznawania tekstu, napisany w Pythonie i wykorzystujący framework ParlAI do samego rozpoznawania tekstu. To sieć neuronowa, przynajmniej w obecnej realizacji. Używamy algorytmu tfDiff do zrozumienia pytań. Moduł oferuje API do komunikacji z nim i do nauki.
Na zakończenie chciałbym powiedzieć, że to nasze pierwsze doświadczenie w tworzeniu bota czatu i staraliśmy się uczynić system jak najprostszy, ale jednocześnie funkcjonalny, przy minimalnym nakładzie pracy. Myślę, że udało nam się stworzyć dość interesujący produkt. Z własnym systemem uczenia, logowania błędów, powiadomieniami, a także można go zintegrować z każdą inną aplikacją do przesyłania wiadomości.
Źródło: habr.com
