Një vit më parë, departamenti ynë i HR-së, që e duam shumë, na kërkoi të shkruajmë një chatbot, i cili do të ndihmojë në adapimin e të rinjve në kompaninë tonë.
Duhet të theksojmë se ne nuk zhvillojmë produkte të veta, por ofrojmë një gamë të plotë shërbimesh zhvillimi për klientët tanë. Ky përshkrim do të jetë për projektin tonë të brendshëm, për të cilin klient është jo një kompani e jashtme, por HR-ja jonë. Detyra kryesore ishte që, me burime dhe njerëz të kufizuar, të përfundojmë projektin në kohë dhe të lëshojmë produktin.
Fillimisht do të përshkruajmë detyrat, të cilat duhej të zgjidhen.
Programuesit — shumica janë introvertë dhe nuk pëlqejnë të flasin; është më e lehtë të shkruash pyetjen tënde në një bisedë elektronike. Me chatbotin, nuk është e nevojshme të mendosh se kujt t'i drejtohesh, kujt t'i telefonosh, ku të marrësh informacion dhe nëse ai informacion është aktual.
Problemi tjetër është informacioni — ka shumë prej tij, ai është në burime të ndryshme, nuk është gjithmonë në dispozicion dhe ka nevojë për plotësim dhe azhurnim të vazhdueshëm.
Në kompani ka pothuajse 500 punonjës, ata ndodhen në zyra të ndryshme, zona kohore, qytete të Rusisë dhe madje edhe jashtë saj, zakonisht ka shumë pyetje, kështu që një detyrë tjetër është të ulin ngarkesën ndaj stafit të HR-së, që lidhet me pyetjet më të shpeshta që bëjnë punonjësit.
Ishte e nevojshme 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 njoftimeve automatike për kurset dhe testet që duhet të përfundojë i rinj për një adaptim të suksesshëm.
Baza e kërkesave të biznesit ishin formuluar kërkesat teknike.
Bot duhet të punojë mbi Skype (historikisht, ky është ai që përdoret në kompani), prandaj u zgjodh një shërbim në Azure.
Për kufizimet e aksesit, filluam të përdorim mekanizmin e autorizimit përmes Skype.
Për njohjen e tekstit, përdorëm bibliotekën ParlAI.
Ishte gjithashtu e nevojshme një portal admin web për konfigurimin, trajnimin, debuggimin, konfigurimin e dërgimeve dhe detyrave të tjera.
Gjatë punës mbi projektin, u përballëm me një sërë problemi dhe vështirësish.
Për shembull, kishte probleme me natyrë teknike — me llogarinë në Azure. Microsoft nuk donte të aktivizonte abonimin tonë për shkak të vështirësive teknike brenda shërbimit të tyre. Pothuajse dy muaj nuk mundëm të bënim asgjë, mbështetja e Microsoft-it përfundoi duar të lidhura dhe na dërgoi te partnerët, të cilët i konfiguruan me sukses dhe na dhanë llogarinë.
Faza më e vështirë ishte fillimi i 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ëveprojnë komponentet dhe modulat e sistemit.
Në rastin tonë, problemet e zakonshme të fillimit të çdo projekti u komplikuan edhe më shumë nga stafi i përshtatur. Specifika e biznesit tonë është që, ndryshe nga ato tregtare, mbi projektet e brendshme shpesh punojnë programues, të cilët nuk kanë njohuri të mjaftueshme në fushat e nevojshme — ata thjesht për rastësi janë vendosur në pritje për projektin e madh të ardhshëm. Logjikisht, motivimi në një situatë të tillë është gjithashtu shumë i komplikuar. Produktiviteti bie në nivele të ulta, në ekip shpesh ka ndërprerje, në fund duhet të bindim (motivim) ose të ndryshojmë personin. Kur ndërohet programuesi, duhet të bëjmë trajnim, të kalojmë njohuri dhe përsëri në thelb të fillojmë projektin. Çdo programues i ri e shihte arkitekturën në mënyrën e tij dhe kritikonte vendimet e marra më parë dhe kodin e të tjerëve. Fillonte rishkrimi nga e para.
Kjo ka vazhduar për rreth gjashtë muaj. Ne thjesht ishim në një vend, duke refaktorizuar kodin dhe nuk shkruanim asgjë të re.
Gjithashtu, mbi projektet e brendshme, zakonisht nuk ka asnjë dokumentacion dhe ishte e vështirë të kuptohej se çfarë duhej bërë në çdo moment, dhe cilat ishin tani përparësitë. Duhej të krijonim një ekip të qëndrueshëm, të organizonim proceset, të bënim planifikim dhe vlerësim për të paktën tre muaj. Por si ta bënim këtë, kur projekti nuk është tregtar, dhe kjo do të thotë se duhet të investojmë orët e punës në minimum, dhe po ashtu rezultati të jetë jo më keq se ai për një klient të jashtëm?
Ne identifikuam fondet e burimeve që morën pjesë në zhvillimin e projektit, janë të njohur me të dhe dëshirojnë të punojnë mbi të. Kemi përgatitur një kalendar për angazhimin e njerëzve në projekte. Bëmë vlerësimin dhe miratimin e punëve, dhe i vendosëm ato në "hapësirat" midis projekteve kryesore. Pas 4 muajsh, morëm një prototip funksional të aplikacionit.
Tani le të flasim në detaje për funksionalitetin e chatbot-it, arkitekturën dhe zgjidhjet teknike.
Një nga kërkesat kryesore të HR ishte njohja e tekstit të shkruar nga përdoruesi për t'i dhënë një përgjigje të saktë pyetjes. Ai mund të shkruajë - dua të shkoj në pushim, dua pushim ose do të shkoja në pushim, dhe ai do të kuptojë dhe do të përgjigjet përkatësisht. Ose ndoshta punonjësi ka thyer karrigen e tij dhe dëshiron të shkruajë - "karrigia është e thyer" ose "Kam një ndarje në karrige" ose "Mbështetësja e karriges më ra", me stërvitjen e duhur, boti do të njohë këto kërkesa. Cilësia e njohjes së tekstit varet natyrisht nga stërvitja e botit, për të cilin do të flasim më vonë.
Kërkesa tjetër dhe pjesë e funksionalitetit është sistemi i bisedave të botit. U zhvillua një sistem ku boti mund të zhvillojë biseda dhe të kuptojë kontekstin e pyetjes aktuale. Ai mund të bëjë pyetje sqaruese në përgjigje të pyetjes suaj dhe të vazhdojë bisedën, nëse ne e kemi stërvitur botin të bëjë këtë. Skype mbështet pika të thjeshta menusë për t'u ofruar përdoruesve mundësi për vazhdimin e bisedave. Po ashtu, nëse kemi zhvilluar një bisedë, por papritur vendosim të bëjmë një pyetje jashtë temës, boti do ta kuptojë edhe këtë.
Boti ofron mundësinë e dërgimit të artefakteve të ndryshme për përdoruesin, në bazë të të dhënave të tij personale. Për shembull, në vendndodhjen e tij. Le të supozojmë se një person dëshiron të gjejë një tualet, atëherë do t'i tregohen një hartë e zyrës që e çon në tualet. Dhe harta do të zgjidhet në varësi të zyrës në të cilën 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ë që çdo person të ketë qasje në të dhënat konfidenciale që përpunon boti ynë. Nevoja për autorizim për një bot të tillë është një pjesë e pandashme e tij. Boti iu kërkon përdoruesit që të kalojë autorizimin përpara se të mund të zhvillojë ndonjë bisedë me të. Kjo ndodh në kontaktin e parë të punonjësit me botin. Vetë autorizimi e drejton përdoruesin në faqen përkatëse, ku ai merr një token që më pas e fusin në mesazhin në Skype. Nëse autorizimi përfundon me sukses, atëherë mund të fillohet biseda me botin.
Autorizimi kalon nëpër Skype - portalin e shërbimit të autorizimit, rrjetin korporativ dhe LDAP. Kështu, autorizimi varet nga të dhënat aktuale për përdoruesin në rrjetin korporativ.
Gjatë procesit të zhvillimit të botit, kuptuam se na duhej një sistem i caktuar, i integruar në funksionalitetin e portalit, që do të ndihmonte HR të kryejnë shpejt debug-in e 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ë zgjidhin ato me stërvitje të re ose t'i lënë për zhvilluesit.
Mundësia për të stërvitur botin drejtpërdrejt në portal nuk ishte parashikuar që në fillim. Gjatë zhvillimit, kuptuam se stërvitja e botit është detyra më e shpeshtë që do të kryejnë anëtarët e departamentit HR gjatë punës me të, dhe dërgimi i skedarëve me tekst tek zhvilluesit për stërvitje të mëtejshme të botit është krejtësisht i papranueshëm. Kjo i konsumon shumë më tepër kohë dhe krijon shumë gabime dhe probleme.
Ne shkruam UI në portal për një stërvitje miqësore për përdoruesin të botit. Ai u lejon HR-ve të shohin stërvitjen aktuale të botit, ta stërvisin atë dhe të bëjnë ndryshime të nevojshme në stërvitjen aktuale. Stërvitja paraqitet me një strukturë hipermote, ku nodet, dmth degët janë vazhdim i bisedës me botin. Mund të krijoni pyetje të thjeshta dhe përgjigje, ose biseda më të thella, gjithçka varet nga HR-të dhe nevojat e tyre.
Disa fjalë për arkitekturën e zgjidhjes.
Arkitektura e zgjidhjes është modulare. Ajo përfshin shërbime që përgjigjen për detyra të ndryshme, konkretisht:
• Shërbimi i botit Skype në Azure - pranon dhe përpunon kërkesat nga përdoruesit. Ky është një shërbim mjaft i thjeshtë, i cili pranon kërkesën e parë 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 drejtohet fillimisht portalit, dhe portali vendos se çfarë do të bëjë më tej me kërkesën.
• Shërbimi i autorizimit - ofron mekanizmat e autentifikimit për botin dhe për portalin admin. Autorizimi ndodh sipas protokollit Oauth2. Pas autorizimit pozitiv, shërbimi kryen autorizimin në rrjetin korporativ sipas të dhënave valide të përdoruesit, në mënyrë që sistemi të mund të kontrollojë gabimet që lidhen me çëshjet e sinkronizimit të të dhënave.
• Moduli AI për njohjen e tekstit, i shkruar në Python dhe duke përdorur kuadrin ParlAI për njohjen e vetë tekstit. Kjo është një rrjet nervor, të paktën në implementimin aktual. Ne përdorim algoritmin tfDiff për të kuptuar pyetjet. Moduli ofron një API për të komunikuar me të dhe për të mësuar.
Në përfundim, do të doja të thoja se kjo është përvoja jonë e parë në krijimin e një boti bisedor, dhe ne përpiqemi ta bëjmë sistemin sa më të thjeshtë, por njëkohësisht funksional, me investime minimale në të. Mendoj se kemi arritur të krijojmë një produkt shumë interesant. Me sistemin tonë të mësimit, regjistrimit të gabimeve, dërgimit të njoftimeve, gjithashtu mund të integrohet me çdo mesazher tjetër.
Burimi: habr.com
