Meglévő javaslati rendszer optimalizálása és újrafelhasználása

Ez a dokumentum egy R nyelven írt meglévő javaslati rendszer sikeres újrafelhasználásának és fejlesztésének folyamatát ismerteti. Ennek kulcsa a Microsoft Machine Learning Server beépített MicrosoftML- és RevoScaleR-kódtárak párhuzamossága volt.

Javaslati rendszerek és R

A kiskereskedők számára a fogyasztói preferenciák és a vásárlási előzmények megismerése versenyelőnyt jelent. A kiskereskedők a gépi tanulással együtt évek óta használják ezeket az adatokat a fogyasztó szempontjából releváns termékek azonosítására és a személyre szabott vásárlási élmény biztosítására. Ezt a megközelítést termékajánlásnak nevezik, és jelentős bevételi forrást hoz létre a kiskereskedők számára. A javaslati rendszerek segítenek megválaszolni a következőhöz hasonló kérdéseket: Melyik filmet nézi meg ez a személy? Milyen további szolgáltatások érdeklik ezt az ügyfelet? Hol szeretne nyaralni az ügyfél? Egy közelmúltbeli ügyfél tudni akarta: Megújítják-e a fogyasztók (előfizetők) a szerződéseiket? Az ügyfél rendelkezik egy meglévő javaslati modellel, amely előrejelezheti, hogy egy előfizető megújít-e egy szerződést. Az előrejelzés létrehozása után további feldolgozást alkalmaztak a válasz igen, nem vagy talán besorolására. A modell válasza ezután egy callcenter üzleti folyamatba lett integrálva. Ez a folyamat lehetővé tette, hogy a szolgáltatásügynök személyre szabott javaslatokat nyújtson a fogyasztónak.
Az ügyfél korai elemzési termékeinek nagy része az R programozási nyelvbe épült, beleértve a gépi tanulási modellt is a javaslati rendszer középpontjában. Az előfizetői bázis növekedésével az adatokra és a számítási követelményekre is szükség van. Annyira, hogy az ajánlás számítási feladat most fájdalmasan lassú és nehézkes feldolgozni. A Python most már egyre inkább része az analitikus termékstratégiának. Rövid távon azonban meg kell őrizniük az R-befektetéseiket, és hatékonyabb fejlesztési és üzembehelyezési folyamatot kell találniuk. A kihívás a meglévő megközelítés optimalizálása volt az Azure képességeivel. Elkezdtünk egy feladatot, amely egy megvalósíthatósági technológiai vermet biztosít és ellenőriz a javaslati számítási feladathoz. Itt összefoglalunk egy általános megközelítést, amely hasonló projektekhez használható.

Tervezési célok

A legfontosabb prioritás a modell munkafolyamatának újratervezése és automatizálása volt, amely számos előnnyel jár:

• Gyorsabb modellfejlesztési ciklusok és gyorsabb innováció. Ha az adat-előkészítési és a modellfejlesztési ciklusok hatékonyak, a kísérletek mennyisége nőhet.
• Pontosabb modelleredmények és jobb javaslatok a friss adatokra vonatkozó gyakoribb újratanítási ciklusok révén.
• Egy méretezhető megvalósíthatósági igazolási (POC) implementáció, amely teljes éles környezetben működne.
• Gyorsabb üzembe helyezési idő a fejlesztés, tesztelés és üzembe helyezés közötti folyamatok automatizálásával. Az Automatizálás emellett csökkenti az üzemeltetési hibákat és az késési időket.

Követelmények

A munkafolyamat újratervezése a következő követelményekkel rendelkezett:

• Használja ki a csapat meglévő R-készségeit és szakértelmét.
• Használja újra a kódot, ahol értelme volt.
• Tárolja az előfizetői adatokat egy adatbázisban, hogy könnyen és gyorsan integrálható legyen a modell betanítási és újratanítási folyamatába.
• Modell újratanításának és pontozásának meghívása webalkalmazás-felületen keresztül.
• A Azure Active Directory használata a webes előtéren történő hitelesítéshez.

Technológiai eszközkészlet

A projekt folyamata több technológiát és eszközt igényelt, és négy terület köré összpontosult:

1. Az előfizetői adatok megőrzése és hozzáférhetősége.
2. Modellek fejlesztése, betanítása és kiválasztása.
3. Modell üzembe helyezése és üzembe helyezése.
4. Webalkalmazás használata pontozás és modell újratanításának meghívásához.

A folyamatábra technológiai összetevőit a következő szakasz ismerteti részletesebben.

Microsoft Machine Learning-kiszolgáló

Az R számítási feladatok kiválasztásának elsődleges oka: RevoScaleR és Microsoft ML. A csomagokban szereplő függvényeket a kódban széles körben használták az adatok importálásához, a besorolási modellek létrehozásához és éles környezetben való üzembe helyezéséhez. Machine Learning Studio (MLS) két Linux rendszerű virtuális gépen (VM) lett üzembe helyezve az Azure-ban. Egy virtuális gép konfigurálva van a "fejlesztéshez", egy pedig a "műveletekhez" lett konfigurálva. A több száz modell betanítását és tesztelését megkönnyítő, jelentős mennyiségű memóriával és feldolgozási teljesítménnyel kiépített fejlesztési virtuális gép. Az RStudio Servert is üzemeltette, hogy egyszerű hozzáférést biztosítson az RStudio IDE-hez a távoli felhasználók számára. Az operatív kiszolgáló egy kisebb virtuális gépen lett konfigurálva, a rest API-kon keresztül egy webalkalmazásból hívható R-modellek üzemeltetéséhez szükséges további bővítményekkel.

RStudio Server

Az RStudio Server egy Linux-alkalmazás, amely böngészőalapú felületet biztosít a távoli vagy laptopos ügyfelek számára. A 8787-es porton fut, és a távoli kapcsolatok számára is elérhető, miután létrehozott egy hálózati biztonsági szabályt az Azure-beli virtuális gépen. Az RStudio IDE-t előnyben részesítő elemzők és adattudósok számára hatékony megoldás lehet a nagy számítási és memóriakapacitással rendelkező virtuális gépekhez való hozzáférés biztosítására. Forrás- és kereskedelmi kiadásokban is letölthető.

Azure SQL Database

Az előfizetői adatokat eredetileg egy nagyon nagy .csv fájlban tárolták 6 millió sornyi vásárlási és preferenciális információval 500 egyedi előfizető számára. Az adatok adatbázisba való tárolása gyorsabb adathozzáférést jelentett az R-ből, és lehetővé tenné a szűrt olvasásokat. A betanításhoz vagy az újratanításhoz már nem kell importálni a teljes adatkészletet: az adatokat az adatbázis-forrás előfizetője szűrné, ami jelentősen csökkenti az adatok importálásához és feldolgozásához szükséges erőforrásokat.
Az Azure-ban számos felügyelt felhőalapú adatbázis-beállítás érhető el. Azure SQL Database az ügyfél SQL Server ismerete, és ami még fontosabb, a jövőbeli tervek miatt lett kiválasztva, hogy SQL Server Machine Learning szolgáltatásokat szélesebb körben vezesse be a Azure SQL Database. SQL Server Machine Learning Services adatbázison belüli képességekkel rendelkezik az R- és Python-számítási feladatok tárolt eljárásokon keresztüli végrehajtásához.

Node.js és React.js

Létre lett hozva egy webes felület az R-szkriptek meghívásához és a webhely biztonságossá tételéhez. Node.js webkiszolgáló-keretrendszerként lett kiválasztva, mert egyszerű és hatékony futtatókörnyezetet tesz lehetővé az elosztott környezetben lévő webalkalmazások számára. React felhasználói felületek létrehozására szolgál, és az előtérben helyezkedik el, és meghívja a webkiszolgálón üzemeltetett webszolgáltatásokat. Úgy vélték, hogy a Node + React biztosítja a leggyorsabb útvonalat a modellfolyamat proto-gépelési webszolgáltatásaihoz.

Infrastruktúra megvalósítása

Az alábbi szakaszok ismertetik, hogyan lett üzembe helyezve a kiszolgálói infrastruktúra ehhez a projekthez. A megfelelő fejlesztési és üzembehelyezési infrastruktúra kialakítása ugyanolyan fontos lehet, mint a modellezési megközelítés és az alkalmazott technikák meghatározása.

Kezdeti adatbázisbetöltés

Az első lépés az előfizetői adatok importálása egy nagyon nagy .csv fájlból Azure SQL Database. Az adatok Azure SQL Database való importálására több lehetőség is van, amelyeket ebben a hivatkozásban ismertetünk. A következőképpen csináltuk:

1. Az adatbázist Azure Portal következő lépésekkel hozta létre.
2. Letöltötte és felhasználta SQL Server Management Studio az adatbázishoz való csatlakozáshoz a virtuális gépről.
3. A SQL Import/Export varázslót jelölte ki (ha időkorlátos, akkor több teljesítményalapú adatimportálási lehetőség érhető el). Ne feledje, hogy az importálási/exportálási varázsló adattípusokat képez le az adatforrásból a célhelyre; és a mi esetünkben az összes adatelemet varchar(max) adattípusra képeztük le, amely elfogadható volt. Ha a forgatókönyv különböző leképezéseket igényel, módosíthatja az adattípusokat a varázslóban (hivatkozás).
4. Mivel az adatbázisba küldött legtöbb lekérdezés a subscriber_id mezőre szűrne, létrehoztunk egy indexet az adott mezőben.

Webalkalmazás

A webalkalmazás három függvényért felelős:

• Hitelesítés: A webfelhasználók az React előtéren keresztül hitelesítik magukat Azure Active Directory.
• Modell pontozása: Elfogadja a felhasználótól egy adott előfizető bemeneti adatait, elküldi az előfizetői adatokat a webszolgáltatásnak a REST API használatával, amely előrejelzési választ ad vissza.
• Modell újratanítása: Fogadja el az előfizetői azonosítót bemenetként, és meghív egy R-szkriptet a fejlesztői kiszolgálón a modell újratanításához az előfizető számára.

Az egyszeri bejelentkezés (SSO) megvalósítása Azure Active Directory a vártnál nagyobb kihívásnak bizonyult. Ennek oka az egyoldalas alkalmazás (SPA) keretrendszer volt. Egy adott Azure Active Directory könyvtár volt a siker kulcsa: react-adal. Az alábbi hivatkozások hasznos útmutatást nyújtottak a hitelesítés implementálásakor:

• Hitelesítési forgatókönyvek az Azure AD-hez
• Egyoldalas alkalmazás

Fejlesztői virtuális gép (MLS 9.3.0)

A fejlesztési virtuális gép modellfejlesztést, betanítást és újratanítást, valamint a besorolási modell üzembe helyezését üzemeltette. Az Azure-beli virtuális gép (DS13 V2) Linux/Ubuntu 16.10 rendszerrel lett üzembe helyezve, és a következők lettek telepítve az alapszintű virtuális gépre:

• Machine Learning Server 9.3.0-t az itt elérhető utasítások használatával. A telepítés megerősítéséhez mindenképpen futtassa végig a telepítés ellenőrzési lépéseit. Mivel ez volt a fejlesztési virtuális gép, a "Webszolgáltatás üzembe helyezésének és távoli kapcsolatainak engedélyezése" szakasz figyelmen kívül lett hagyva.
• RStudio Server (nyílt forráskódú verzió). Ügyeljen arra, hogy ne telepítse újra az R/r-base rendszert (korábban az MLS 9.3.0-val volt telepítve).
• Adjon hozzá egy hálózati biztonsági csoportot a virtuális géphez, hogy engedélyezze a bejövő kapcsolatokat az RStudio Server 8787-ös porton keresztül.
• Nyissa meg az ODBC-illesztőket a fejlesztési virtuális gép és a Azure SQL Database közötti kommunikáció kezeléséhez. A következő ODBC-illesztőprogramok lettek telepítve a virtuális gépen:
• A SQL Server 17-hez készült ODBC-illesztő kompatibilis a Linux/ubuntu 16.10 rendszerrel
• Egy unixodbc nyílt forráskódú ODBC-illesztő, amely telepítési utasításokat tartalmaz a relációs adatok ODBC használatával történő importálásához. Megjegyzés: ez a cikk két elírást tartalmaz az Ubuntu-utasításokhoz.
• Annak ellenőrzése, hogy telepítve van-e a unixodbc:Apt list –installed | grep unixODBC (should be unixodbc) - És az illesztőprogram telepítése: sudo apt-get install unixodbc-devel unixodbc-bin unixodbc (should be unixodbc-dev)

Operatív virtuális gép (MLS 9.3.0)

Az üzemeltetési virtuális gép üzemeltette a modell webszolgáltatásait és végpontjait, tárolta a Swagger-fájlokat és a besorolási modellek szerializált verzióit. A konfiguráció nagyon hasonló az MLS fejlesztési kiszolgálóhoz. Azonban az üzembehelyezéshez van konfigurálva, ami azt jelenti, hogy a REST-végpontok kiszolgálásához szükséges webszolgáltatások telepítve vannak. Az üzemeltetési virtuális gép üzembe helyezéséhez arm-sablonok teszik gyorssá az üzembe helyezést. Lásd: A Microsoft Machine Learning Server 9.3 konfigurálása az Elemzés üzembe helyezéséhez ARM-sablonokkal. Projektünkben ezzel az ARM-sablonnal üzembe helyeztük a One-Box-konfigurációt.
Ezzel a modellfolyamatot támogató kiszolgáló-összetevők működtek.

Modell implementálása

Az egyik kulcsfontosságú döntés befolyásolta a projekt végső modelltervét, és az volt, hogy egyetlen monolitikus modell helyett "több modell" kialakítására váltott. A különbség: minden előfizető saját besorolási modellel rendelkezik, nem pedig egy nagy besorolási modellel, amely az összes előfizetőt kiszolgálja. Ennél az ügyfélnél a megközelítés volt előnyben részesítve, mert egy kisebb modell memóriaigénye kisebb volt, és egyszerűbb volt horizontálisan skálázni éles környezetben.

Adatok importálása

A modellfejlesztéshez szükséges összes adat egy Azure SQL Database található. A modellek betanításához és újratanításához az adatok importálása két lépésben történt:

1. Egy lekérdezés lett elküldve az adatbázisba egy adott subscriber_id adatainak lekéréséhez és egy eredményhalmaz visszaadásához. Két lehetőség lett figyelembe véve az adatbázishoz való lekérdezési hozzáféréshez:

• RxSQLServerData nevű RevoScaleR függvény
• Az R odbc-csomag

Úgy döntöttek, hogy az R "odbc" kódtárat használják, amely lehetővé teszi az adatok szűrését az adatbázis szintjén. Az adatbázistábla szűrése az adott előfizetői modellhez szükséges sorokra minimálisra csökkentette az R-be beolvasandó és feldolgozott sorok számát. Ez csökkentette az egyes modellek betanításához vagy újratanításához szükséges memóriát, számítást és teljes időt.

1. Az eredményhalmaz R-adatkeretté lett konvertálva, és néhány adattípust explicit módon varcharsból egész számmá vagy számmá alakítottak a besorolási algoritmusok által megkövetelt módon. Ehhez a funkcióhoz az rxImport RevoScaleR függvényt használtuk. Az rxImport függvény a RevoScaleR és a MicrosoftML csomagban található, és többszálasra van tervezve. Íme egy példa a használatukra:

# Populate the data frame and modify column types as needed
input_data <- rxImport(sqlServerDataDS, colClasses = c(  
Approved="integer",
      OnTimeArrivalRate="numeric",
      Amount="numeric",
      IsInformed="numeric",
      <continue with list of columns> )
# View the characteristics of the variables in the data source
rxGetInfo (input_data, getVarInfo = TRUE)

Kiegyensúlyozatlan adatok

Mivel a javaslati modell célja annak előrejelzése volt, hogy az ügyfél milyen valószínűséggel újítana meg egy szerződést, és annak valószínűségét "igen", "nem" vagy "talán" kategóriába sorolná, egy besorolási algoritmust használtunk. A besorolási algoritmusok pontosságát és teljesítményét súlyosan befolyásoló problémák egyike a kiegyensúlyozatlan adathalmaz.
Az adathalmazok kiegyensúlyozatlanok, ha egy "osztályhoz" sokkal több mintára van szükség, mint egy másik "osztályra". Ebben az esetben az egyes előfizetők számára elérhető sorok száma kiegyensúlyozatlan volt: a felső sorban az egyik előfizetőnek több mint 1 millió sora volt; 330 ügyfélnek kevesebb mint 100 adatsora volt. Az alábbi grafikon az előfizetőnkénti sorok (minták) számával kapcsolatos egyensúlyhiányt mutatja:

A kiegyensúlyozatlan adathalmazok kezelésének egyik technikája az adathalmaz módosítása, és az alulreprezentált osztály mintája vagy a túlreprezentált osztály alulreprezentált mintája. Egy másik technika, hogy szintetikusan generáljon további adatokat az adattulajdonos pontos ismeretével az adatokról és azok attribútumairól. Az ügyfél meghatározta az előfizető minimális mintaméretére vonatkozó küszöbértéket. A küszöbérték alatti előfizetők esetében az adatokat kezelni kell. Ebben a projektben mindkét módszert megvizsgáltuk.

Algoritmus kiválasztása

Három különböző besorolási algoritmus implementációt értékeltünk ki: rxDForest, rxFastTrees és rxFastForest. Mindhárom algoritmus kihasználja a többszálasságot és a párhuzamosságot. A Microsoft ML pedig több CPU-t vagy GPU-t fog használni, ha elérhető. A modellek értékelésének kritériumai:

• Pontosabbak voltak az új modellek, mint az eredeti modell?
• Mennyi volt az éles környezetben futó modellek memóriaigénye? A pontosság veszélyeztetése nélkül támogathatná az operatív környezet számos modell egyidejű végrehajtását közel valós idejű előrejelzési válaszokkal?
• Mennyire kezelte jól az algoritmus a kiegyensúlyozatlan adatkészletet? Elő kell-e kezelni az egyensúlyhiányt szintetikus adatok generálásával?

Az alábbi táblázat összefoglalja az eredményeket:

Végül az ügyfél kiválasztotta az rxFastForest algoritmust, és úgy döntött, hogy a vtreat kódtár használatával kezeli a kiegyensúlyozatlan adatokat, és hozzáad egy testre szabott előfeldolgozási lépést, amely szintetikusan generál adatokat az alulreprezentált előfizetők számára.

Modell üzembe helyezése és webszolgáltatások

Az üzembe helyezési modellnek az üzemeltetési virtuális gépen való közzététele egyszerű, és ebben a rövid útmutatóban dokumentált dokumentációban üzembe helyez egy R-modellt webszolgáltatásként az mrsdeploy használatával. A mi esetünkben, miután a modellek létrejöttek a fejlesztési virtuális gépen, az alábbi lépésekkel lettek közzétéve az üzemeltetési virtuális gépen:

1. Hozzon létre egy távoli bejelentkezést a fejlesztői virtuális gépről az operatív virtuális gépre az mrsdeploy csomagban elérhető két funkció egyikével a hitelesítéshez; remoteLogin() helyi rendszergazdai névvel és jelszóval, vagy remoteLoginAAD() a Azure Active Directory használatával. Mindkét lehetőséget ebben a hivatkozásban ismertetjük. Jelentkezzen be Machine Learning Server vagy R Server az mrsdeploy használatával, és nyisson meg egy távoli munkamenetet.
2. Miután betanított egy modellt, tegye közzé az operatív virtuális gépen az mrsdeploy csomag publishService vagy updateService függvényeivel. Ebben a projektben több üzembe helyezési módszert használtunk, és – a megközelítéstől függően – közzétettünk egy új modellt, vagy frissítettünk egy meglévő modellt. Az alábbi kód mindkét eset kezelésére lett implementálva:

# If the service does not exist, publish it and if it does exist, update it.  
# No service by this name so publish one
 api <- publishService(serviceName, code =sc_predict, model = model,  
      inputs = list(prop_data="data.frame"),  
      outputs = list(answer = "numeric"), v = "v1.0.0" )
 print("=========== Model Created =============")
} else {
# A service by this name already exists, update it  
 api <- updateService(serviceName, model = model,
     inputs = list(prop_data="data.frame"), v = "v1.0.0" )
 print("=========== Model Updated =============")
}

Az üzembe helyezéskor a modellek szerializálva lesznek és az operatív kiszolgálón vannak tárolva, és webszolgáltatásokon keresztül használhatók standard vagy valós idejű módban. Minden alkalommal, amikor egy webszolgáltatást standard módban hívnak meg, az R és a szükséges kódtárak minden hívással betölthetők és eltávolíthatók. Ezzel szemben a valós idejű módban az R és a kódtárak csak egyszer töltődnek be, és újra felhasználhatók a későbbi webszolgáltatás-hívásokhoz. Mivel a webszolgáltatás-hívásokkal járó többletterhelés nagy része az R és a kódtárak betöltése, a valós idejű mód sokkal alacsonyabb késést biztosít a modell pontozásához, és a válaszidők 10 ezredm alatt is lehetnek. A standard és a valós idejű lehetőségekről itt talál dokumentációt és referencia-példákat. A valós idő jól használható egyetlen előrejelzéshez, de a pontozáshoz bemeneti adatkeretet is megadhat. Ezt a referenciaanyagban ismertetjük: Aszinkron webszolgáltatás-felhasználás kötegelt feldolgozással mrsdeploy használatával.

Összegzés

A MicrosoftML- és RevoScaleR-kódtárak párhuzamosságát kihasználva Microsoft Machine Learning Server előfizetők százai számára felgyorsította az egyéni besorolási modellek fejlesztését, üzembe helyezését és pontozását. A modell pontossága javult, a betanítási és újratanítási idők pedig tömörítve lettek – mindezt a meglévő R-kódbázis minimális módosításával. Az infrastruktúra implementálása a modellfolyamatok támogatásához és a technológiai összetevők megfelelő, végpontok közötti konfigurálásához összetett lehet. Az alábbiakban néhány hivatkozást talál a saját megközelítésének első lépéseihez:

• Machine Learning Server dokumentációja
• R-oktatóanyagok Machine Learning Server
• R-minták Machine Learning Server
• R függvénytár referenciája

Következő lépések

Ha más prediktív megoldásokat szeretne létrehozni a kiskereskedelmi vállalkozása számára, látogasson el az Azure AI-katalóguskiskereskedelmi szakaszába.