Një vit më parë, departamenti ynë i HR-së i dashur na kërkoi: të shkruajmë një chatbot që do të ndihmojë në adaptimin e të rinjve në kompani.
Të sqarojmë se ne nuk zhvillojmë produkte të veta, por ofrojmë një gamë të plotë shërbimesh në zhvillim për klientët. Historia do të flasë për projektin tonë të brendshëm, për të cilin punëdhënësi nuk është një kompani e jashtme, por HR ynë i vet. Dhe detyra kryesore, në kushte të kufizuara të disponueshmërisë së njerëzve, burimeve dhe kohës, është të realizojmë projektin në kohë dhe të lëshojmë produktin.
Së pari, le të përshkruajmë detyrat që do të duhej të zgjidhen.
Zhvilluesit janë kryesisht introvertë dhe nuk i pëlqejnë bisedat, është shumë më e lehtë të shkruash pyetjen tënde në një bisedë elektronike. Me botin nuk duhet të mendosh se kë të pyesësh, kujt t’i telefonosh, ku të shkosh dhe në përgjithësi, ku të kërkosh informacion dhe a është ai aktual.
Problemi i dytë është informacioni — ai është shumë, ndodhet në burime të ndryshme, dhe jo gjithmonë është i disponueshëm dhe kërkon vazhdimësi në plotësim dhe përditësim.
Në kompani ka pothuajse 500 punonjës, ata ndodhen në zyra të ndryshme, në zona të ndryshme koherente, qytete të Rusisë dhe madje jashtë saj, pyetje zakonisht ka shumë, kështu që një tjetër detyrë është të zvogëlojmë ngarkesën mbi stafin e HR-së lidhur me pyetjet më të zakonshme që bëjnë punonjësit.
Duhej gjithashtu të automatizoheshin proceset: ardhja e të rinjve në kompani, dërgimi i mesazheve menaxherëve dhe mentorëve të të rinjve, dërgimi i përkujtesave automatike për kursit dhe testet që duhet të kalojë të riut për një adaptim të suksesshëm.
Në bazë të kërkesave të biznesit, u formuluan specifikimet teknike.
Boti duhet të punojë mbi Skype (historikisht ka ndodhur që ata përdorin këtë në kompani), prandaj u zgjodh një shërbim në Azure.
Për kufizimet e qasjes, filluam të përdorim mekanizmin e autorizimit nëpërmjet Skype.
Për njohjen e tekstit, përdorëm bibliotekën ParlAI.
Gjithashtu, ne kemi nevojë për një portal web administrativ për konfigurimin, trajnimin, debugging, konfigurimin e shpërndarjeve dhe detyra të tjera.
Në procesin e punës mbi projektin, u përballëm me një mori problemesh dhe vështirësish.
Për shembull, pati probleme teknike me llogarinë Azure. Microsoft nuk dëshiroi të aktivizonte abonimin tonë për shkak të ndonjë vështirësie teknike brenda shërbimit të tyre. Pothuajse dy muaj nuk mundëm të bënim asgjë lidhur me këtë, mbështetje e Microsoft-it përfundimisht u dorëzua dhe na dërgoi tek partnerët, të cilët e konfiguruan me sukses gjithçka dhe na dhanë llogarinë.
Faza më e vështirë ishte nisja e projektit, kur duhej të zgjidhnim se çfarë do të përdornim, cila do të ishte arkitektura, si dhe ku do të ruheshin të dhënat dhe si do të bashkëvepronin komponentët dhe modulet e sistemit me njëri-tjetrin.
Në rastin tonë, problemet e zakonshme të fillimit të çdo projekti u komplikuan edhe më shumë nga stafi. Specifika e biznesit tonë është se, ndryshe nga projektet komerciale, mbi projektet e brendshme shpesh punojnë zhvillues që nuk kanë njohuri të mjaftueshme në fushat e nevojshme – thjesht u gjetën aty për fatin që prisnin projektin tjetër të madh komercial. Është logjike që motivimi në një situatë të tillë ishte gjithashtu mjaft i çrregullt. Produktiviteti bie ndjeshëm, ekipi shpesh ka pushime, dhe përfundimisht duhet të bindësh (të motivosh) ose të ndërroni personin. Kur ndërron zhvilluesin, duhet të kryesh trajnime, të trasferosh njohuri dhe përsëri në thelb të fillosh projektin. Çdo zhvillues i ri e shihte arkitekturën në mënyrën e tij dhe e kritikonte të kaluarin për vendimet e marrë prej tyre dhe kodin e huaj. Fillonte riprogramimi nga e para.
Kështu vazhdoi për rreth gjashtë muaj. Ne thjesht po qëndronim në vend, po rifillnim kodin dhe nuk po shkruanim asgjë të re.
Po ashtu, në projektet e brendshme zakonisht nuk ka pothuajse asnjë dokumentacion, dhe ishte e vështirë të kuptoje se çfarë duhej të bëje në çdo moment dhe cilat ishin përparësitë aktuale. Duhej të krijonim një ekip të përhershëm, të organizonim proceset, të bënim planifikim dhe vlerësim për të paktën tri muaj. Por si ta bënim këtë kur projektin nuk ishte komerciale, dhe kjo do të thoshte se orët e njeriut duhej të investoheshin minimalisht, dhe që rezultati të ishte jo më keq se për një klient të jashtëm?
Ne kemi identifikuar një grup burimesh që morën pjesë në zhvillimin e projektit, janë të njohur me të dhe duan të punojnë mbi të. Kemi përgatitur një orar të angazhimit të njerëzve në projekte. Kemi kryer një vlerësim dhe miratim të punëve, dhe i kemi futur këto punë në "ndarjet" midis projekteve kryesore. Pas 4 muajsh, ne morëm një prototip funksional të aplikacionit.
Tani le të flasim më në detaje për funksionalitetin e bot-it, arkitekturën dhe zgjidhjet teknike.
Një nga kërkesat kryesore të HR-së ishte njohja e tekstit të shkruar nga përdoruesi për të dhënë një përgjigje të saktë në pyetje. Përdoruesit mund të shkruajnë – dua të shkoj në pushim, dua pushim ose do të shkoja në pushim, dhe ai do ta kuptonte dhe do t’i përgjigjej në përputhje me këtë. Ose ndonjëherë, nëse një punonjës ka probleme me karrigen, ai mund të shkruajë – "karrigia është thyer" ose "Karrigia ime ka një çarje" ose "Back i karriges më ka rënë", dhe me trajnimin e duhur, boti do të njohë këto kërkesa. Cilesia e njohjes së tekstit natyrisht varet nga trajnimi i bot-it, për të cilin do të flasim më vonë.
Kërkesa tjetër dhe një pjesë e funksionalitetit është sistemi i dialogëve të bot-it. Kemi zhvilluar një sistem, në të cilin boti mund të zhvillojë një dialog dhe të kuptojë kontekstin e pyetjes aktuale. Ai mund t'i bëjë pyetje sqaruese në përgjigje të pyetjeve tuaja dhe të vazhdojë bisedën, nëse e kemi trajnuar bot-in të bëjë këtë. Skype mbështet pika të thjeshta menusë për të sugjeruar përdoruesve mundësi të mundshme për të vazhduar dialogët. Po ashtu, nëse kemi zhvilluar një bisedë, por papritmas vendosim të bëjmë një pyetje jashtë temës, boti do ta kuptojë këtë gjithashtu.
Boti ofron mundësinë për të dërguar artefakte të ndryshme përdoruesit, bazuar në të dhënat e tij personale. Për shembull, mbi lokacionin e tij. Supozoni se nëse dikush dëshiron të gjejë një tualet, ai do të tregojë një hartë të zyrës, e cila e çon atë në tualet. Dhe harta do të zgjidhet në varësi të zyrës ku ndodhet punonjësi i kompanisë.
Një nga detyrat më të rëndësishme është mbrojtja e informacionit personal të përdoruesve. Ne nuk mund të lejojmë çdo person të ketë qasje në të dhënat e ndjeshme me të cilat operon boti ynë. Kërkesa për autorizim për një bot të tillë është një pjesë e pandarë e tij. Boti kërkon nga përdoruesi të kalojë autorizimin para se të mund të bisedojë me të. Kjo ndodh gjatë kontaktit të parë të punonjësit me botin. Vetë autorizimi e drejton përdoruesin në faqen përkatëse, ku përdoruesi merr një token, të cilin më vonë e vendos në mesazhin e Skype. Nëse autorizimi kalon me sukses, atëherë mund të fillohet komunikimi me botin.
Autorizimi kalon përmes Skype — portali i shërbimit të autorizimit, rrjetit korporativ dhe LDAP. Sidoqoftë, autorizimi varet nga të dhënat aktuale të përdoruesit në rrjetin korporativ.
Gjatë zhvillimit të botit, kuptuam se na nevojitej një sistem, i integruar në funksionalitetin e portalit, që mund të ndihmojë HR-në në debugimin e shpejtë të botit. Ne shtuam një faqe të tillë në portal, ku HR-të mund të shohin gabimet e regjistruara nga përdoruesit gjatë punës me botin dhe t'i zgjidhin ato përmes ri-trajnimit ose t'i lënë për zhvilluesit.
Mundësia për të trajnuar botin drejtpërdrejt në portal nuk ishte parashikuar që nga fillimi. Gjatë zhvillimit ne kuptuam se trajnimi i botit është detyra më e zakonshme që do të kryejnë punonjësit e departamentit të HR gjatë punës me të, dhe dërgimi i skedarëve me tekst te zhvilluesit për stërvitje të mëtejshme të botit është krejtësisht e papranueshme. Kjo merr shumë kohë dhe shkakton shumë gabime dhe probleme.
Ne shkruam një UI në portal për trajnimin e miqësor të botit. Ai lejon HR-në të shohë trajnimin aktual të botit, ta ri-trajnojë atë dhe të bëjë korrigjime në trajnimin aktual. Trajnimi paraqitet në një strukturë të pemës, në të cilën nodet, pra, degët janë vazhdim i dialogut me botin. Mund të krijoni pyetje dhe përgjigje të thjeshta, apo biseda më komplekse, gjithçka varet nga HR dhe nevojat e tyre.
Pak fjalë mbi arkitekturën e zgjidhjes.
Arkitektura e zgjidhjes është modulare. Ajo përfshin shërbime që përgjigjen për detyra të ndryshme, që do të thotë:
• Shërbimi Skype bot në Azure — merr dhe përpunon kërkesat e përdoruesve. Ky është një shërbim mjaft i thjeshtë, i cili e pranon fillimisht kërkesën dhe kryen përpunimin e saj fillestar.
• Portali admin — shërbimi që ofron një ndërfaqe web për konfigurimin e portalit dhe për vetë botin. Boti gjithmonë i qaset fillimisht portalit, dhe portali pastaj vendos se çfarë të bëjë me kërkesën më pas.
• Shërbimi i autorizimit — ofron mekanizma autentikimi për botin dhe për portalin admin. Autorizimi ndodh sipas protokollit Oauth2. Në rast të autorizimit pozitiv, shërbimi kryen autorizimin në rrjetin korporativ sipas të dhënave të vlefshme të përdoruesit, në mënyrë që sistemi të mund të kontrollojë gabimet e lidhura me mospërputhjet në të dhëna.
• Moduli AI për njohjen e tekstit, i shkruar në Python dhe që përdor framework-un ParlAI për njohjen e vetë tekstit. Ky është një rrjet nervor, të paktën në realizimin aktual. Ne përdorim algoritmin tfDiff për të kuptuar pyetjet. Moduli ofron një API për komunikim me të dhe për trajnimin.
Në përfundim, dua të them se kjo është përvoja jonë e parë në krijimin e një chat boti, dhe ne u përpoqëm ta bëjmë sistemin sa më të thjeshtë, por njëkohësisht funksional, me minimumin e përpjekjeve për të. Mendoj se kemi arritur të krijojmë një produkt mjaft interesant. Me sistemin tonë të të mësuarit, regjistrimit të gabimeve, dërgimit të njoftimeve, gjithashtu mund të integrohet me çdo aplikacion tjetër mesazhi.
Burimi: habr.com
