För ett år sedan bad vår älskade HR-avdelning oss att skriva en chatbot som skulle hjälpa till med anpassningen av nyanlända till företaget.
Låt oss reservera att vi inte utvecklar våra egna produkter, utan vi tillhandahåller kunderna ett komplett utbud av utvecklingstjänster. Berättelsen kommer att handla om vårt interna projekt, där kunden inte är ett tredjepartsföretag, utan vår egen HR. Och huvuduppgiften, med tanke på den begränsade tillgängligheten av människor, resurser och tid, är att slutföra projektet i tid och släppa produkten.
Låt oss först beskriva de problem som måste lösas.
Utvecklare är mestadels introverta människor och gillar inte att prata; det är mycket lättare att skriva din fråga i en e-postchatt. Med en bot behöver du inte tänka på vem du ska fråga, vem du ska ringa, vart du ska gå och i allmänhet var du ska leta efter information och om den är relevant.
Det andra problemet är information - det finns mycket av det, det finns i olika källor, det är inte alltid tillgängligt och behöver konstant tillägg och uppdatering.
Företaget har nästan 500 anställda, de finns på olika kontor, tidszoner, städer i Ryssland och till och med utomlands, det finns vanligtvis många frågor, så en annan uppgift är att minska bördan på HR-personal i samband med de vanligaste frågorna av anställda.
Det var också nödvändigt att automatisera processerna för: nykomlingar som går med i företaget, skicka meddelanden till chefer och mentorer för nyanlända, skicka automatiska påminnelser om kurser och tester som en nykomling måste klara för att lyckas med anpassningen.
Tekniska krav utformades utifrån affärskrav.
Boten måste fungera på basis av Skype (historiskt sett använder de den i företaget), så tjänsten på Azura valdes.
För att begränsa åtkomsten till det började vi använda auktoriseringsmekanismen via Skype.
ParlAI-biblioteket användes för textigenkänning
En administrativ webbportal krävs också för konfiguration, utbildning, felsökning, uppsättning av utskick och andra uppgifter.
Under arbetet med projektet stötte vi på ett antal problem och svårigheter.
Till exempel fanns det tekniska problem med ett Azure-konto. Microsoft ville inte aktivera vårt abonnemang på grund av vissa tekniska problem inom deras tjänst. I nästan två månader kunde vi inte göra något åt det; Microsofts support gav så småningom upp händerna och skickade oss till partners, som framgångsrikt konfigurerade allt och gav oss ett konto.
Det svåraste steget var starten på projektet, när du behöver välja vad vi ska använda, vilken arkitektur som ska vara, hur och var data ska lagras och hur komponenterna och modulerna i systemet ska interagera med varandra.
I vårt fall komplicerades de i huvudsak vanliga problemen med att starta ett projekt ytterligare av bemanningen. Vår verksamhets särdrag är sådana att, till skillnad från kommersiella, interna projekt ofta bearbetas av utvecklare som inte har tillräckliga kunskaper inom de nödvändiga områdena - de helt enkelt, av ödets vilja, hamnade på bänken i väntan på nästa stort coolt kommersiellt projekt. Det är logiskt att det också var väldigt svårt med motivation i en sådan situation. Produktiviteten sjunker lågt, teamet är ofta sysslolöst, och som ett resultat måste man övertala (motivera) eller förändra personen. När du byter utvecklare måste du genomföra utbildning, överföra kunskap och i princip starta projektet igen. Varje ny utvecklare såg arkitekturen på sitt sätt och skällde ut de tidigare för de beslut de tog och andras kod. Omskrivningen började från början.
Detta pågick i ungefär sex månader. Vi markerade bara tid, refaktorerade koden och skrev inget nytt.
Dessutom finns det i regel nästan ingen dokumentation för interna projekt, och det var svårt att förstå vad som måste göras vid varje tidpunkt och vad de nuvarande prioriteringarna är. Det var nödvändigt att skapa ett permanent team, etablera processer och genomföra planering och utvärdering under minst tre månader. Men hur gör man när projektet inte är kommersiellt, vilket innebär att man behöver investera ett minimum av mantimmar, och samtidigt få resultatet inte sämre än för en extern kund?
Vi har identifierat en pool av resurser som deltagit i utvecklingen av projektet, är bekanta med det och vill arbeta med det. Vi gjorde upp ett schema för anställning av personer i projekt. Vi bedömde och koordinerade arbetet och passade in dessa arbeten i "hålen" mellan huvudprojekten. Efter 4 månader fick vi en fungerande prototyp av applikationen.
Låt oss nu prata mer i detalj om botens funktionalitet, arkitektur och tekniska lösningar.
Ett av huvudkraven för HR var att känna igen texten som skrivits av användaren för att svara på frågan korrekt. Du kan skriva till honom - jag vill åka på semester, jag vill åka på semester eller vill åka på semester, och han kommer att förstå och svara därefter. Eller plötsligt går en anställds stol sönder och han vill skriva "stolen är trasig" eller "Min stol är sprucken" eller "Bakryggen på stolen har ramlat av"; med rätt utbildning kommer boten att känna igen sådana förfrågningar. Kvaliteten på textigenkänningen i sig beror på botens träning, som vi kommer att prata om senare.
Nästa krav och del av funktionaliteten är botens dialogsystem. Ett system utvecklades där boten kan föra en dialog och förstå sammanhanget i den aktuella frågan. Som svar på din fråga kan han ställa alla klargörande frågor och fortsätta konversationen om vi har tränat boten att göra detta. Skype stöder enkla menyalternativ för att fråga användare om alternativ för att fortsätta konversationer. Dessutom, om vi förde en dialog, men plötsligt bestämde oss för att ställa en fråga utanför ämnet, kommer boten också att förstå detta.
Boten gör det möjligt att skicka olika artefakter till användaren baserat på dennes personliga data. Till exempel på hans plats. Anta att om en person ville hitta en toalett, skulle han få en kontorskarta som leder honom till toaletten. Och kortet kommer att väljas beroende på vilket företagskontor den anställde befinner sig.
En av de viktigaste uppgifterna är att skydda användarnas personuppgifter. Vi kan inte tillåta varje person att ha tillgång till den känsliga information som vår bot driver. Behovet av auktorisering för en sådan bot är en integrerad del av den. Boten ber användaren att autentisera innan han kan föra någon dialog med honom. Detta händer första gången en anställd kontaktar boten. Själva auktoriseringen omdirigerar användaren till lämplig sida, där användaren får en token, som han sedan infogar i ett Skype-meddelande. Om auktoriseringen lyckas kan du börja kommunicera med boten.
Auktorisering sker genom Skype - portalauktoriseringstjänst, företagsnätverk och LDAP. Behörighet beror alltså på aktuell användardata på företagsnätverket.
I processen med att utveckla boten insåg vi att vi behövde något slags system inbyggt i portalfunktionaliteten som kunde hjälpa HR att snabbt felsöka boten. Vi har lagt till en portalsida där HR kan se fel registrerade av användare när de arbetar med boten och lösa dem med hjälp av omskolning eller lämna dem till utvecklare.
Möjligheten att träna en bot direkt på portalen ingick inte från första början. Under utvecklingsprocessen insåg vi att träning av boten är den vanligaste uppgiften som anställda på HR-avdelningen kommer att utföra när de arbetar med den, och att skicka textfiler till utvecklare för ytterligare utbildning av boten är helt oacceptabelt. Detta äter upp för mycket tid och skapar för många fel och problem.
Vi skrev ett användargränssnitt på portalen för användarvänlig träning av boten. Det låter HR se botens aktuella träning, vidareutbilda den och göra justeringar av den aktuella träningen. Träning representeras av en trädstruktur där noder, det vill säga grenar, är en fortsättning på dialogen med boten. Du kan skapa enkla frågor och svar, eller så kan du skapa tunga dialoger, allt beror på HR och deras behov.
Några ord om lösningsarkitekturen.
Lösningsarkitekturen är modulär. Det inkluderar tjänster som ansvarar för olika uppgifter, nämligen:
• Skype bot-tjänst på Azure - accepterar och bearbetar användarförfrågningar. Detta är en ganska enkel tjänst som är den första som tar emot en förfrågan och utför sin första bearbetning.
• Admin portal - en tjänst som tillhandahåller ett webbgränssnitt för att sätta upp portalen och för själva boten. Boten kontaktar alltid portalen först, och portalen bestämmer vad den ska göra härnäst med begäran.
• Auktoriseringstjänst - tillhandahåller autentiseringsmekanismer för boten och för administratörsportalen. Auktorisering sker via Oauth2-protokollet. Med positiv auktorisering utför tjänsten auktorisering i företagsnätverket enligt giltig användardata, så att systemet kan kontrollera fel kopplade till data osynkroniserat.
• AI-textigenkänningsmodul, skriven i Python och använder ParlAI-ramverket för själva textigenkänningen. Detta är ett neuralt nätverk, åtminstone i dess nuvarande implementering. Vi använder tfDiff-algoritmen för att förstå frågorna. Modulen tillhandahåller ett API för att kommunicera med den och lära sig.
Sammanfattningsvis vill jag säga att detta är vår första erfarenhet av att skapa en chattbot, och vi försökte göra systemet så enkelt som möjligt, men samtidigt funktionellt, med minimala arbetskostnader på det. Jag tycker att vi har en väldigt intressant produkt. Med sitt eget träningssystem, felloggning, aviseringssändning kan den även integreras med vilken annan budbärare som helst.
Källa: will.com