Год таму наш любімы HR аддзел звярнуўся з просьбай: напісаць чат робата, які дапаможа ў адаптацыі пачаткоўцаў у кампаніі.
Абмовімся, што мы не распрацоўваем уласных прадуктаў, але кліентам аказваем поўны спектр паслуг па распрацоўцы. Аповяд пайдзе аб нашым унутраным праекце, для якога замоўцам з'яўляецца не іншая кампанія, а наш уласны HR. І галоўная задача пры абмежаванай даступнасці людзей, рэсурсаў, чакай выканаць праект у тэрмін і выпусціць прадукт.
Для пачатку апішам задачы, якія трэба было вырашыць.
Распрацоўнікі - людзі ў большасці сваёй інтраверты і не любяць размаўляць, значна прасцей напісаць сваё пытанне ў электронным чаце. З ботам не трэба думаць, каго спытаць, каму патэлефанаваць, куды ісці і наогул, дзе шукаць інфармацыю, і ці актуальная яна.
Другая праблема гэта і ёсць інфармацыя - яе шмат, яна ў розных крыніцах, не заўсёды ёсць і мае патрэбу ў пастаянным дапаўненні і абнаўленні.
У кампаніі амаль 500 супрацоўнікаў, яны знаходзяцца ў розных офісах, гадзінных паясах, гарадах Расіі і нават за мяжой, пытанняў звычайна вельмі шмат, таму яшчэ адна задача – знізіць нагрузку на HR персанал, звязаную з найбольш частымі пытаннямі, якія задаюцца супрацоўнікамі.
Неабходна было таксама аўтаматызаваць працэсы: прыходу пачаткоўцаў у кампанію, рассыланні паведамленняў мэнэджарам і настаўнікам пачаткоўцаў, адпраўкі аўтаматычных напамінкаў аб курсах і тэстах, якія неабходна прайсці пачаткоўцу для паспяховай адаптацыі.
На аснове бізнес-патрабаванняў былі сфарміраваны тэхнічныя.
Бот павінен працаваць на аснове Скайпа (гістарычна так склалася, што карыстаюцца ў кампаніі ім) таму абраны быў сэрвіс на Азуры.
Для абмежаванняў доступу да яго мы сталі выкарыстоўваць механізм аўтарызацыі праз скайп.
Для распазнання тэксту выкарыстоўвалі бібліятэку ParlAI
Гэтак жа неабходны адміністрацыйны web партал для наладкі, навучанні, адладкі, налады рассылак і іншых задач.
У працэсе работы над праектам мы сутыкнуліся з шэрагам праблем і складанасцей.
Напрыклад, былі праблемы тэхнічнага характару – з акаўнтам да Azure. Майкрасофт ніяк не жадаў актываваць нашу падпіску з-за нейкіх тэхнічных складанасцяў усярэдзіне іх сэрвісу. Амаль два месяцы мы не маглі нічога з гэтым зрабіць, падтрымка Майкрасофта ў выніку развяла рукамі і адправіла нас да партнёраў, якія паспяхова ўсё настроілі і выдалі нам акаўнт.
Найбольш складаным этапам быў старт праекта, калі трэба выбраць, што выкарыстоўваем, якая будзе архітэктура, як і дзе захоўваць дадзеныя і як кампаненты і модулі сістэмы будуць узаемадзейнічаць сябар з сябрам.
У нашым выпадку ў сутнасці радавыя праблемы старту любога праекту ўскладняліся яшчэ і стафіраваннем кадрамі. Спецыфіка нашага бізнесу такая, што ў адрозненне ад камерцыйных, над унутранымі праектамі часта працуюць распрацоўшчыкі, у якіх няма дастатковых ведаў у патрэбных галінах - яны проста воляю лёсу апынуліся на лаўцы ў чаканні наступнага вялікага крутога камерцыйнага праекта. Лагічна, што з матывацыяй у такой сітуацыі справы ішлі таксама вельмі няпроста. Прадукцыйнасць падае нізка, у камандзе часта просты, у выніку даводзіцца ўгаворваць (матываваць) або мяняць чалавека. Пры змене распрацоўшчыка трэба праводзіць навучанне, перадаваць веды і зноў па сутнасці стартаваць праект. Кожны новы распрацоўшчык бачыў архітэктуру па-свойму і лаяў папярэднія за прынятыя імі рашэнні і чужы код. Пачыналася перапісванне з нуля.
Так працягвалася каля паўгода. Мы проста тапталіся на месцы, рэфактарылі код і нічога не пісалі новага.
Таксама на ўнутраных праектах, як правіла, няма амаль ніякай дакументацыі, і складана было зразумець, што трэба рабіць у кожны момант часу, і якія зараз прыярытэты. Неабходна было стварыць пастаянную каманду, наладзіць працэсы, правесці планаванне і ацэнку хаця б на тры месяцы. Але як гэта зрабіць, калі праект не камерцыйны, а гэта значыць, што чалавекагадзіны інвеставаць трэба па мінімуму, і пры гэтым вынік атрымаць не горш, чым для знешняга заказчыка?
Мы вызначылі пул рэсурсаў, якія ўдзельнічалі ў распрацоўцы праекту, знаёмыя з ім і жадаюць над ім працаваць. Склалі расклад занятасці людзей на праектах. Правялі адзнаку і ўзгадненне прац, і ўпісалі гэтыя працы ў "дзіркі" паміж асноўнымі праектамі. Праз 4 месяц мы атрымалі працоўны прататып прыкладання.
Зараз давайце пагаворым падрабязней аб функцыянальнасці робата, аб архітэктуры і тэхнічных рашэннях.
Адным з галоўных патрабаванняў HR было распазнанне тэксту, напісанага карыстальнікам для карэктнага адказу на пытанне. Яму можна напісаць — я хачу пайсці ў водпуск, хачу ў водпуск або пайсці б у водпуск, і ён зразумее і адкажа адпаведным чынам. Або раптам у супрацоўніка зламаўся крэсла, і ён хоча напісаць – «крэсла зламаўся» або «У мяне крэсла трэснуў» або «Спінка ў крэсла адвалілася», пры правільным навучанні робат распазнае такія запыты. Якасць распазнання тэксту само сабой залежыць ад навучання робата, аб якім мы пагаворым пазней.
Наступным патрабаваннем і часткай функцыяналу з'яўляецца сістэма дыялогаў робата. Была распрацавана сістэма, пры якой робат можа весці дыялог і разумець кантэкст бягучага пытання. Ён можа ў адказ на ваша пытанне задаць якія-небудзь удакладняючыя пытанні і працягнуць размову, калі мы навучылі робата зрабіць гэта. Скайп падтрымлівае простыя пункты меню для падказкі карыстальнікам аб магчымых варыянтах працягу дыялогаў. Таксама калі мы вялі дыялог, але раптам вырашылі задаць пытанне не па тэме, то робат таксама гэта зразумее.
Робат дае магчымасць адпраўляць розныя артэфакты карыстачу, засноўваючыся на яго асабістых дадзеных. Напрыклад, на яго лакацыі. Выкажам здагадку, калі чалавек захацеў знайсці туалет, то яму будзе паказана карта офіса, якая вядзе яго ў туалет. І карта будзе абрана ў залежнасці ад таго, у якім офісе кампаніі знаходзіцца супрацоўнік.
Адной з найважнейшых задач з'яўляецца абарона асабістай інфармацыі карыстальнікаў. Мы не можам дазволіць кожнаму чалавеку атрымаць доступ да канфідэнцыйных дадзеных, якімі аперуе наш бот. Неабходнасць у аўтарызацыі для такога робата з'яўляецца неад'емнай яго часткай. Бот просіць у карыстальніка прайсці аўтарызацыю перш, чым ён зможа весці з ім які-небудзь дыялог. Гэта адбываецца пры першым звароце супрацоўніка да робата. Сама аўтарызацыя пераадрасуе карыстальніка на адпаведную старонку, дзе карыстальнік атрымлівае токен, які потым устаўляе ў скайп-паведамленне. Калі аўтарызацыя праходзіць паспяхова, то можна пачынаць зносіны з ботам.
Аўтарызацыя праходзіць праз скайп – партал-authorization service, карпаратыўную сетку і LDAP. Такім чынам, аўтарызацыя залежыць ад бягучых дадзеных аб карыстачу ў карпаратыўнай сетцы.
У працэсе распрацоўкі робата мы зразумелі, што патрэбна нейкая сістэма, убудаваная ў функцыянал партала, якая зможа дапамагчы HR вырабляць хуткую адладку робата. Мы дадалі такую старонку партала, на якой HRы могуць убачыць памылкі, зафіксаваныя карыстальнікамі пры працы з ботам і вырашыць іх з дапамогай перанавучання або пакінуць для распрацоўшчыкаў.
Магчымасць навучання робата прама на партале не была закладзена з самага пачатку. У працэсе распрацоўкі мы зразумелі, што навучанне робата гэта самая частая задача, якую будуць выконваць супрацоўнікі аддзела HR пры працы з ім, і адпраўляць файлы з тэкстам распрацоўнікам для дадатковага навучання робата зусім непрымальна. Гэта з'ядае зашмат часу і спараджае зашмат памылак і праблем.
Мы напісалі UI на партале для User-frirendly навучання бота. Ён дазваляе HR бачыць бягучае навучання бота, данавучаць яго і ўносіць карэктывы ў бягучае навучанне. Навучанне прадстаўлена дрэвападобнай структурай, у якой ноды, гэта значыць галіны з'яўляюцца працягам дыялогу з ботам. Можна ствараць простыя пытанні-адказы, а можна важкія дыялогі, усё залежыць ад HR і іх патрэб.
Некалькі слоў аб архітэктуры рашэння.
Архітэктура рашэння модульная. У яе ўваходзяць сэрвісы, якія адказваюць за розныя задачы, а менавіта:
• Сэрвіс скайп бота на Azure - прымае і апрацоўвае запыты карыстальнікаў. Гэта дастаткова просты сэрвіс, які першым прымае запыт і вырабляе яго першасную апрацоўку.
• Адмін партал - сэрвіс, які прадстаўляе вэб-інтэрфейс для налады партала і для самога робата. Бот заўсёды звяртаецца спачатку да партала, а партал ужо вырашае, што рабіць з запытам далей.
• Сэрвіс аўтарызацыі - дае механізмы аўтэнтыфікацыі для бота і для адмін партала. Аўтарызацыя адбываецца па пратаколе Oauth2. Пры дадатнай аўтарызацыі сэрвіс праводзіць аўтарызацыю ў карпаратыўнай сетцы паводле валідных дадзеных карыстача, так што сістэма можа кантраляваць памылкі, злучаныя з рассінхронам у дадзеных.
• AI Модуль распазнання тэксту, напісаны на пітоне і які выкарыстоўвае фрэймворк ParlAI для самога распазнання тэксту. Гэта нейронавая сетка, па меншай меры ў бягучай рэалізацыі. Мы выкарыстоўваем алгарытм tfDiff для разумення пытанняў. Модуль дае API для зносін з ім і навучання.
У зняволенні жадаю сказаць, што гэта наш першы досвед у стварэнні чат робата, і мы імкнуліся зрабіць сістэму як мага прасцей, але пры гэтым функцыянальнай, пры мінімальных працавыдатках на яе. Мяркую, у нас атрымаўся вельмі цікавы прадукт. Са сваёй сістэмай навучання, лагіравання памылак, рассыланняў апавяшчэнняў, гэтак жа яго можна інтэграваць з любым іншым мэсаджарам.
Крыніца: habr.com