Antaŭ unu jaro, nia amata HR-sekcio petis nin verki babilejon, kiu helpus kun la adapto de novuloj al la kompanio.
Ni faru rezervon, ke ni ne disvolvas niajn proprajn produktojn, sed ni provizas klientojn kun plena gamo de disvolvaj servoj. La rakonto estos pri nia interna projekto, por kiu la kliento ne estas tria kompanio, sed nia propra HR. Kaj la ĉefa tasko, pro la limigita havebleco de homoj, rimedoj kaj tempo, estas kompletigi la projekton ĝustatempe kaj liberigi la produkton.
Unue, ni priskribu la problemojn, kiujn oni devis solvi.
Programistoj estas plejparte introvertitaj homoj kaj ne ŝatas paroli; estas multe pli facile skribi vian demandon en retpoŝta babilejo. Kun bot, vi ne devas pensi pri kiu demandi, kiun voki, kien iri, kaj ĝenerale, kie serĉi informojn kaj ĉu ĝi estas grava.
La dua problemo estas informo - estas multe da ĝi, ĝi estas en diversaj fontoj, ĝi ne ĉiam haveblas kaj bezonas konstantan aldonon kaj ĝisdatigon.
La kompanio havas preskaŭ 500 dungitojn, ili situas en malsamaj oficejoj, horzonoj, urboj de Rusio kaj eĉ eksterlande, kutime estas multaj demandoj, do alia tasko estas redukti la ŝarĝon de HR-personaro asociita kun la plej oftaj demandoj. de dungitoj.
Necesis ankaŭ aŭtomatigi la procezojn de: novuloj aliĝantaj al la firmao, sendado de mesaĝoj al administrantoj kaj mentoroj de novuloj, sendado de aŭtomataj memorigiloj pri kursoj kaj testoj, kiujn novulo bezonas trapasi por sukcesa adaptiĝo.
Teknikaj postuloj estis formitaj surbaze de komercaj postuloj.
La bot devas funkcii surbaze de Skajpo (historie, ili uzas ĝin en la kompanio), do la servo sur Azura estis elektita.
Por limigi aliron al ĝi, ni komencis uzi la rajtigan mekanismon per Skajpo.
ParlAI-biblioteko estis uzita por tekstrekono
Administra retportalo ankaŭ estas bezonata por agordo, trejnado, senararigado, agordo de dissendoj kaj aliaj taskoj.
Laborante pri la projekto, ni renkontis kelkajn problemojn kaj malfacilaĵojn.
Ekzemple, estis teknikaj problemoj kun Azure-konto. Microsoft ne volis aktivigi nian abonon pro iuj teknikaj malfacilaĵoj ene de sia servo. Dum preskaŭ du monatoj ni nenion povis fari pri ĝi; Microsoft-subteno fine levis siajn manojn kaj sendis nin al partneroj, kiuj sukcese aranĝis ĉion kaj donis al ni konton.
La plej malfacila etapo estis la komenco de la projekto, kiam vi devas elekti kion ni uzos, kia estos la arkitekturo, kiel kaj kie stoki datumojn, kaj kiel la komponantoj kaj moduloj de la sistemo interagas inter si.
En nia kazo, la esence ordinaraj problemoj komenci ajnan projekton estis pli komplikitaj per dungitaro. La specifaĵoj de nia komerco estas tiaj, ke, male al komercaj, internaj projektoj ofte estas prilaboritaj de programistoj, kiuj ne havas sufiĉan scion en la postulataj areoj - ili simple, laŭ la volo de la sorto, finiĝis sur la benko atendante la sekvan. granda bonega komerca projekto. Estas logike, ke aferoj ankaŭ estis tre malfacilaj kun instigo en tia situacio. Produktiveco malaltiĝas, la teamo ofte estas neaktiva, kaj kiel rezulto vi devas persvadi (motivi) aŭ ŝanĝi la personon. Kiam vi ŝanĝas programistojn, vi devas fari trejnadon, transdoni scion kaj esence komenci la projekton denove. Ĉiu nova programisto vidis la arkitekturon laŭ sia maniero kaj riproĉis la antaŭajn pro la decidoj kiujn ili faris kaj la kodo de aliaj homoj. La reverkado komenciĝis de nulo.
Ĉi tio daŭris ĉirkaŭ ses monatojn. Ni nur markis tempon, refaktoris la kodon kaj ne skribis ion novan.
Ankaŭ pri internaj projektoj, kiel regulo, preskaŭ mankas dokumentaro, kaj estis malfacile kompreni, kion oni devas fari en ĉiu momento, kaj kiaj estas la nunaj prioritatoj. Necesis krei konstantan teamon, establi procezojn kaj fari planadon kaj taksadon dum almenaŭ tri monatoj. Sed kiel fari tion kiam la projekto ne estas komerca, kio signifas, ke vi devas investi minimumon da homhoroj, kaj samtempe akiri la rezulton ne pli malbona ol por ekstera kliento?
Ni identigis aron da rimedoj, kiuj partoprenis en la evoluo de la projekto, konas ĝin kaj volas labori pri ĝi. Ni ellaboris horaron por la dungado de homoj en projektoj. Ni taksis kaj kunordigis la laboron, kaj enmetis ĉi tiujn verkojn en la "truojn" inter la ĉefaj projektoj. Post 4 monatoj ni ricevis funkciantan prototipon de la aplikaĵo.
Nun ni parolu pli detale pri la funkcieco, arkitekturo kaj teknikaj solvoj de la bot.
Unu el la ĉefaj postuloj de HR estis rekoni la tekston skribitan de la uzanto por ĝuste respondi la demandon. Vi povas skribi al li - mi volas ferii, mi volas ferii aŭ ŝatus ferii, kaj li komprenos kaj respondos laŭe. Aŭ subite la seĝo de dungito rompas kaj li volas skribi "la seĝo estas rompita" aŭ "Mia seĝo estas fendita" aŭ "La dorso de la seĝo defalis"; kun taŭga trejnado, la bot rekonos tiajn petojn. La kvalito de teksto-rekono mem dependas de la trejnado de la bot, pri kiu ni parolos poste.
La sekva postulo kaj parto de la funkcieco estas la dialogsistemo de la bot. Sistemo estis evoluigita en kiu la bot povas fari dialogon kaj kompreni la kuntekston de la nuna afero. Responde al via demando, li povas fari ajnajn klarigantajn demandojn kaj daŭrigi la konversacion se ni trejnis la roboton por fari tion. Skype subtenas simplajn menuopciojn por instigi uzantojn pri ebloj por daŭrigi konversaciojn. Ankaŭ, se ni dialogus, sed subite decidis fari demandon ekster la temo, la bot ankaŭ komprenos ĉi tion.
La bot ebligas sendi diversajn artefaktojn al la uzanto surbaze de liaj personaj datumoj. Ekzemple, ĉe lia loko. Supozu, se iu volus trovi necesejon, tiam oni montrus al li oficejan mapon kondukantan lin al la necesejo. Kaj la karto estos elektita depende de kiu kompanio oficejo troviĝas en la dungito.
Unu el la plej gravaj taskoj estas protekti personajn informojn de uzantoj. Ni ne povas permesi al ĉiu persono havi aliron al la sentemaj datumoj, kiujn nia roboto funkcias. La bezono de rajtigo por tia bot estas integra parto de ĝi. La roboto petas al la uzanto aŭtentikigi antaŭ ol li povas fari ajnan dialogon kun li. Ĉi tio okazas la unuan fojon kiam dungito kontaktas la bot. La rajtigo mem redirektas la uzanton al la taŭga paĝo, kie la uzanto ricevas ĵetonon, kiun li poste enmetas en Skajpon-mesaĝon. Se rajtigo sukcesas, vi povas komenci komuniki kun la bot.
Rajtigo okazas per Skype - portalo-rajtigo servo, kompania reto kaj LDAP. Tiel, rajtigo dependas de la nunaj uzantdatenoj sur la kompania reto.
Dum la disvolvado de la bot, ni rimarkis, ke ni bezonas ian sistemon enkonstruitan en la portala funkcio, kiu povus helpi HR rapide sencimi la roboton. Ni aldonis portalan paĝon, kie HR povas vidi erarojn registritajn de uzantoj kiam ili laboras kun la bot kaj solvi ilin per retrejnado aŭ lasi ilin por programistoj.
La kapablo trejni bot rekte sur la portalo ne estis inkluzivita de la komenco mem. Dum la disvolva procezo, ni rimarkis, ke trejnado de la bot estas la plej ofta tasko, kiun dungitoj de HR-fako plenumos kiam ili laboras kun ĝi, kaj sendi tekstajn dosierojn al programistoj por plia trejnado de la bot estas tute neakceptebla. Ĉi tio manĝas tro da tempo kaj kreas tro da eraroj kaj problemoj.
Ni skribis UI sur la portalo por Uzantamika trejnado de la bot. Ĝi permesas al HR vidi la nunan trejnadon de la bot, plue trejni ĝin kaj fari alĝustigojn al la nuna trejnado. Trejnado estas reprezentita per arbstrukturo en kiu nodoj, tio estas branĉoj, estas daŭrigo de la dialogo kun la bot. Vi povas krei simplajn demandojn kaj respondojn, aŭ vi povas krei pezajn dialogojn, ĉio dependas de HR kaj iliaj bezonoj.
Kelkaj vortoj pri la solva arkitekturo.
La solva arkitekturo estas modula. Ĝi inkluzivas servojn respondecajn por diversaj taskoj, nome:
• Skype-botservo sur Azure - akceptas kaj prilaboras uzantpetojn. Ĉi tio estas sufiĉe simpla servo, kiu estas la unua, kiu ricevas peton kaj plenumi sian komencan prilaboradon.
• Admin portalo - servo kiu provizas retinterfacon por starigi la portalon kaj por la roboto mem. La bot ĉiam kontaktas la portalon unue, kaj la portalo decidas kion fari poste kun la peto.
• Servo de rajtigo - provizas aŭtentikajn mekanismojn por la bot kaj por la administra portalo. Rajtigo okazas per la protokolo Oauth2. Kun pozitiva rajtigo, la servo plenumas rajtigon en la kompania reto laŭ validaj uzantdatenoj, tiel ke la sistemo povas kontroli erarojn asociitajn kun datumoj nesinkronigitaj.
• Modulo pri rekono de teksto de AI, skribita en Python kaj uzante la kadron ParlAI por rekono de teksto mem. Ĉi tio estas neŭrala reto, almenaŭ en ĝia nuna efektivigo. Ni uzas la tfDiff-algoritmon por kompreni la demandojn. La modulo provizas API por komuniki kun ĝi kaj lerni.
Konklude, mi volas diri, ke ĉi tio estas nia unua sperto pri kreado de babilejo, kaj ni provis fari la sistemon kiel eble plej simpla, sed samtempe funkcia, kun minimumaj laborkostoj sur ĝi. Mi pensas, ke ni havas tre interesan produkton. Kun sia propra trejnadsistemo, erarregistrado, sciigo-sendo, ĝi ankaŭ povas esti integrita kun iu ajn alia mesaĝisto.
fonto: www.habr.com