Egy évvel ezelőtt szeretett HR-osztályunk segítséget kért: írjunk egy csevegőrobotot, amely segít az új munkatársak beilleszkedésében a cégbe.
Azt megjegyeznénk, hogy nem fejlesztünk saját termékeket, de ügyfeleinknek teljes körű fejlesztési szolgáltatásokat nyújtunk. A történet a belső projektünkről szól, amelynek megrendelője nem egy külső cég, hanem a saját HR-osztályunk. A legfontosabb feladat a rendelkezésre álló emberek, erőforrások és idő korlátozottsága mellett a projekt határidőre történő teljesítése és a termék kiadása volt.
Először is ismertessük azokat a feladatokat, amelyeket meg kellett oldani.
A fejlesztők - többnyire introvertált emberek - nem szeretnek beszélgetni, sokkal egyszerűbb írni a kérdéseiket egy elektronikus csevegésben. A robottal nem kell azon gondolkodni, kit kérdezzünk, kinek hívjunk, hová menjünk és egyáltalán, hol keressük az információkat, és hogy aktuálisak-e.
A második probléma magának az információnak a bősége - sok van belőle, különböző forrásokban, nem mindig elérhető, és folyamatos kiegészítést és frissítést igényel.
A cégben közel 500 alkalmazott dolgozik, különböző irodákban, időzónákban, Oroszország különböző városaiban és külföldön, általában nagyon sok kérdés merül fel, ezért egy másik feladat a HR személyzet terhelésének csökkentése a munkavállalók által leggyakrabban feltett kérdések terén.
Automatizálni kellett a folyamatokat is: az új munkatársak belépését a cégbe, üzenetek küldését a menedzsereknek és az új munkatársak mentorainak, valamint automatikus emlékeztetők küldését a tanfolyamok és tesztek előtt, amelyeket az új munkatársnak el kell végeznie a sikeres beilleszkedés érdekében.
Az üzleti követelményeken alapuló technikai követelmények kerültek kialakításra.
A robotnak Skype-on kell működnie (történeti okokból a cégben ezt használják), ezért az Azure-t választottuk.
A hozzáférés korlátozása érdekében Skype-on keresztüli hitelesítési mechanizmust alkalmaztunk.
A szöveg felismeréséhez a ParlAI könyvtárat használtuk.
Szükség volt egy adminisztratív webportálra a beállításokhoz, a tanításhoz, a hibakereséshez, a levelek beállításához és más feladatokhoz.
A projekt munka során számos problémával és nehézséggel szembesültünk.
Például technikai problémák merültek fel az Azure fiókkal. A Microsoft semmiképpen sem akarta aktiválni a feliratkozásunkat valamilyen technikai nehézség miatt az ő szolgáltatásukon belül. Majdnem két hónapig semmit sem tudtunk tenni ezzel kapcsolatban, a Microsoft támogatása végül csak vállat vont, és a partnereinkhez irányított minket, akik sikeresen mindent beállítottak és átadták nekünk a fiókot.
A legnehezebb szakasz a projekt indulása volt, amikor ki kellett választani, mit használunk, milyen lesz az architektúra, hogyan és hol tároljuk az adatokat, valamint hogyan fognak kölcsönhatásba lépni a rendszer komponensei és moduljai.
A mi esetünkben gyakorlatilag a bármely projekt indulásával kapcsolatos általános problémák további nehézséget jelentettek a személyzeti állomány miatt. A vállalkozásunk sajátossága, hogy ellentétben a kereskedelmi projektekkel, a belső projekteken gyakran olyan fejlesztők dolgoznak, akiknek nincs elegendő tudásuk a szükséges területeken – csak a sors úgy hozta, hogy egy padon ülnek, és várják a következő nagy kereskedelmi projektet. Logikus, hogy a motiváció ilyen helyzetben is meglehetősen nehezen állt. A teljesítmény alacsonyra esett, a csapatban gyakran volt üresjárat, végül meg kellett győzni (motiválni) vagy kicserélni az embert. Fejlesztő csere esetén ki kellett képezni őket, átadni a tudást, és megint gyakorlatilag újra kellett kezdeni a projektet. Minden új fejlesztő másképp látta az architektúrát, és kritizálta az előzőek által hozott döntéseket és a mások által írt kódot. Újra kellett kezdeni az újraírást.
Ez körülbelül fél évig tartott. Egyszerűen megálltunk a helyben, refaktoráltuk a kódot, és egy új sort sem írtunk.
A belső projekteken általában szinte semmilyen dokumentáció sincs, és nehéz volt megérteni, hogy mit kellene tenni minden egyes pillanatban, és melyek az aktuális prioritások. Szükség volt egy állandó csapat kialakítására, a folyamatok beállítására, és a tervezés és értékelés legalább három hónapra. De hogyan tehettük ezt, amikor a projekt nem kereskedelmi, és ez azt jelenti, hogy a munkaórákat minimálisra kell csökkenteni, egyúttal pedig olyan eredményt kell elérni, mint egy külső megrendelő esetében?
Megállapítottuk az erőforrások körét, akik részt vettek a projekt fejlesztésében, ismerik azt, és szeretnének rajta dolgozni. Összeállítottuk az emberek projektben való elfoglaltságának ütemezését. Elvégeztük az értékelést és a feladatok egyeztetését, és beillesztettük ezeket a feladatokat a fő projektek közötti "lyukakba". Négy hónap elteltével munkaképes prototípust kaptunk az alkalmazásból.
Most beszéljünk részletesebben a bot funkcióiról, az architektúráról és a technikai megoldásokról.
Az egyik legfontosabb HR követelmény a felhasználó által írt szöveg felismerése volt, hogy helyes választ adhasson a kérdésre. Írhatja, hogy — szeretnék szabadságra menni, szabira mennék vagy szeretnék szabadságra menni, és ő megérti és megfelelően válaszol. Vagy ha a munkavállalónak elromlott a széke, és azt akarja mondani — „a szék elromlott” vagy „törött a székem” vagy „a szék háttámlája leesett”, a megfelelő képzés mellett a bot felismeri az ilyen kérdéseket. A szövegfelismerés minősége természetesen a bot képzésétől függ, amiről később beszélünk.
A következő követelmény és funkció egy beszélgetési rendszer a bot számára. Kifejlesztésre került egy rendszer, amelyben a bot képes párbeszédet folytatni és megérteni a jelenlegi kérdés kontextusát. Válaszul a kérdésére további pontosító kérdéseket tehet fel, és folytathatja a beszélgetést, ha megtanítottuk a botot erre. A Skype egyszerű menüpontokat tartalmaz, amelyek segítik a felhasználókat a párbeszédek lehetséges folytatásával kapcsolatban. Továbbá, ha párbeszédet folytattunk, de hirtelen témán kívüli kérdést akarunk feltenni, a bot azt is megérti.
A bot lehetővé teszi, hogy különböző artefaktumokat küldjön a felhasználónak, a személyes adatai alapján. Például, a tartózkodási helye alapján. Tegyük fel, hogy ha valaki vécét keres, akkor megmutatja neki az iroda térképét, ami a vécéhez vezeti. A térkép az alapján lesz kiválasztva, hogy a cég melyik irodájában tartózkodik az alkalmazott.
Az egyik legfontosabb feladat a felhasználók személyes adatainak védelme. Nem engedhetjük, hogy bárki hozzáférjen a botunk által kezelt bizalmas információkhoz. Az ilyen bot esetében az autentikáció szükségszerű része. A bot arra kéri a felhasználót, hogy végezzen el egy autenticációs folyamatot, mielőtt bármilyen párbeszédet folytathatna vele. Ez az első alkalommal történik, amikor egy alkalmazott megkeresi a botot. Maga az autentikáció átirányítja a felhasználót a megfelelő oldalra, ahol a felhasználó kap egy tokent, amelyet aztán beilleszt a Skype üzenetbe. Ha az autentikáció sikeres, megkezdődhet a beszélgetés a bottal.
Az autentikáció a Skype-on keresztül történik - egy portálon keresztül történő autentikációs szolgáltatáson, a vállalati hálózaton és az LDAP-on. Így az autentikáció a vállalati hálózaton lévő felhasználói adatoktól függ.
A bot fejlesztése során rájöttünk, hogy szükség van egy olyan rendszerre, amely be van építve a portál funkciójába, és segíti a HR-t a bot gyors hibakeresésében. Hozzáadtunk egy olyan oldalt a portálhoz, ahol a HR-esek láthatják a felhasználók által a bot használata során rögzített hibákat, és megoldhatják azokat az újraképzéssel, vagy a fejlesztőknek hagyhatják.
A bot portálon történő tanításának lehetőségét nem tervezték meg az elején. A fejlesztés során rájöttünk, hogy a bot tanítása a leggyakoribb feladat, amelyet a HR osztály alkalmazottai végeznek, és a kézi fájlok küldése a fejlesztőknek a bot kiegészítő tanításához teljesen elfogadhatatlan. Ez túl sok időt vesz el, és túl sok hibát és problémát okoz.
Írtunk egy felhasználóbarát felületet a bot tanítására a portálon. Ez lehetővé teszi a HR számára, hogy láthassa a bot aktuális tanítását, továbbképezhesse azt, és módosításokat végezhessen a jelenlegi tanításban. A tanítás fastruktúrában van bemutatva, ahol a csomópontok, vagyis az ágak a bot párbeszédének folytatásai. Egyszerű kérdések-válaszok létrehozása mellett összetett párbeszédeket is alkothatunk, minden a HR-től és az ő szükségleteiktől függ.
Néhány szó a megoldás architektúrájáról.
A megoldás architektúrája moduláris. Beleértve a különböző feladatokért felelős szolgáltatásokat, nevezetesen:
• Azure alapú Skype bot szolgáltatás – fogadja és feldolgozza a felhasználói kéréseket. Ez egy viszonylag egyszerű szolgáltatás, amely elsőként fogadja a kéréseket, és elvégzi azok kezdeti feldolgozását.
• Adminisztrációs portál – olyan szolgáltatás, amely webes felületet biztosít a portál és a bot beállításához. A bot mindig először a portálhoz fordul, a portál pedig dönt arról, hogy mi legyen a következő lépés a kérés kezelésében.
• Hitelesítési szolgáltatás – biztosítja a bot és az adminisztrációs portál számára a hitelesítési mechanizmusokat. A hitelesítés Oauth2 protokoll szerint történik. Sikeres hitelesítés esetén a szolgáltatás elvégzi a belépést a vállalati hálózatba a felhasználó érvényes adatai alapján, így a rendszer képes ellenőrizni az adatokkal kapcsolatos szinkronizálási hibákat.
• AI szövegfelismerő modul, amely Python nyelven íródott, és a ParlAI keretrendszert használja a szövegfelismeréshez. Ez egy neurális hálózat, legalábbis a jelenlegi megvalósításban. A tfDiff algoritmust használjuk a kérdések megértésére. A modul API-t biztosít a kommunikációhoz és a tanításhoz.
Összességében elmondhatom, hogy ez az első tapasztalatunk a chat bot készítésében, és arra törekedtünk, hogy a rendszert a lehető legegyszerűbbé, de mégis funkcionálissá tegyük, minimális munkaerő-igénnyel. Azt hiszem, egy igazán érdekes terméket hoztunk létre, saját oktatási rendszerével, hibák naplózásával, értesítések küldésével, és könnyen integrálható más üzenetküldőkkel is.
Forrás: habr.com
