A ByteDance monolitusa belsejében: Az intelligensebb, gyorsabb tartalomhírcsatornákat működtető motor

Szerzők: Zhuoran Liu, Bytedance Inc. Leqi Zou, Bytedance Inc. Xuan Zou, Bytedance Inc. Caihua Wang, Bytedance Inc. Biao Zhang, Bytedance Inc. Da Tang, Bytedance Inc. Bolin Zhu∗, Fudan Egyetem Yijie Zhu, Bytedance Inc. Peng Wu, Bytedance Inc. Ke Wang, Bytedance Inc. Youlong Cheng†, Bytedance Inc. (youlong.cheng@bytedance.com) ÖSSZEFOGLALÁS A skálázható és valós idejű ajánlórendszer kiépítése létfontosságú számos, az időérzékeny ügyfélvisszajelzésektől függő üzletág számára, mint például a rövid videók rangsorolása vagy az online hirdetések. Annak ellenére, hogy olyan nagyszabású mélytanulási keretrendszereket használnak általánosan, mint a Ten-sorFlow vagy a PyTorch, ezek az általános célú keretrendszerek különböző okok miatt nem felelnek meg az ajánlási forgatókönyvek üzleti igényeinek: egyrészt a statikus paraméterekkel és a dinamikus és ritka funkciókkal való sűrű számításokon alapuló rendszerek finomhangolása káros a modell minőségére; másrészt az ilyen keretrendszereket a kötegelt képzési és a kiszolgálási szakasz teljes szétválasztásával tervezték, ami megakadályozza a modell valós idejű interakcióját az ügyfélvisszajelzésekkel. Ezek a problémák arra késztettek bennünket, hogy újraexamineáljuk a hagyományos megközelítéseket és radikálisan eltérő tervezési döntéseket vizsgáljunk meg. Ebben a cikkben bemutatjuk a 1 rendszert, amelyet online képzésre szabtunk. Tervezésünket az alkalmazási munkaterheléseink és a termelési környezetünk megfigyelései vezérelték, amelyek jelentős eltérést mutatnak más ajánlórendszerektől. Hozzájárulásaink sokrétűek: először is, egy ütközésmentes beágyazási táblát hoztunk létre olyan optimalizálásokkal, mint az expirable beágyazások és a frekvencia szűrés a memóriahasználat csökkentése érdekében; másodszor, egy éles környezetben használható online képzési architektúrát biztosítunk magas hibatűréssel; végül pedig bebizonyítottuk, hogy a rendszer megbízhatósága feláldozható a valós idejű tanulásért. A Monolith sikeresen bekerült a BytePlus Recommend2 termékbe. Monolith 1 BEVEZETÉS Az elmúlt évtizedben tanúi voltunk az ajánlási technikák által támogatott üzleti vállalkozások fellendülésének. A jobb ügyfélélmény érdekében a személyre szabott tartalom valós idejű, egyénenkénti kiszolgálása gyakori célja ezeknek az üzleti alkalmazásoknak. Ennek érdekében a felhasználó legutóbbi interakciójából származó információkat gyakran használják fel a modell képzésének elsődleges bemeneteként, mivel ezek a legjobban ábrázolják a felhasználó portréját, és előrejelzéseket tesznek a felhasználó érdeklődéséről és jövőbeli viselkedéséről. A mélytanulás dominálja az ajánlási modelleket [ , , , , , ], mivel a hatalmas mennyiségű felhasználói adat természetesen illeszkedik a nagymértékben adatvezérelt neurális modellekhez. Azonban az ipari szintű ajánlórendszerekben a mélytanulás erejének kiaknázására irányuló erőfeszítések folyamatosan problémákba ütköznek a valós felhasználói viselkedésből származó adatok egyedi jellemzőiből adódóan. Ezek az adatok két szempontból drasztikusan eltérnek a konvencionális mélytanulási problémákban, mint például a nyelvmodellezés vagy a számítógépes látás, használt adatoktól: 5 6 10 12 20 21 (1) A jellemzők többnyire ritkák, kategorikusak és dinamikusan változnak; (2) A képzési adatok mögöttes eloszlása nem állandó, más néven koncepció sodródás . Ezek a különbségek egyedi kihívásokat jelentenek az ajánlórendszerekkel foglalkozó kutatók és mérnökök számára. 1.1 Ritkaság és dinamizmus Az ajánlási adatok többnyire ritka kategorikus jellemzőket tartalmaznak, amelyek közül néhány alacsony gyakorisággal jelenik meg. A szokásos eljárás, amely ezeket nagy dimenziós beágyazási térbe képezi le, számos problémát vet fel: • Ellentétben a nyelvmodellekkel, ahol a szótöredékek száma korlátozott, a felhasználók és a rangsorolt elemek száma nagyságrendekkel nagyobb. Egy ilyen hatalmas beágyazási tábla aligha fér bele egyetlen gazdagép memóriájába; • Még rosszabb a helyzet, várhatóan a beágyazási tábla mérete idővel növekedni fog, ahogy több felhasználót és elemet vesznek fel, míg az olyan keretrendszerek, mint a [ , ], fix méretű sűrű változókat használnak a beágyazási tábla reprezentálására. 1 17 A gyakorlatban sok rendszer alacsony ütközési arányú hashing [ , ] alkalmaz, hogy csökkentse a memóriahasználatot és lehetővé tegye az azonosítók növekedését. Ez egy túlságosan idealista feltételezésen alapul, miszerint a beágyazási táblában lévő azonosítók egyenletesen oszlanak el a gyakoriság szerint, és az ütközések ártalmatlanok a modell minőségére nézve. Sajnos ez ritkán igaz egy valós ajánlórendszer esetében, ahol egy kis csoport felhasználó vagy elem jelentősen több előfordulással bír. A beágyazási tábla méretének organikus növekedésével nő az ütközés esélye, ami a modell minőségének romlásához vezet 3 6 . Ezért természetes igény a nagyszabású ajánlórendszerek számára, hogy képesek legyenek paramétereikben minél több jellemzőt rögzíteni, valamint hogy rugalmasan képesek legyenek kiigazítani a kezelni kívánt felhasználók és elemek számát. 1.2 Nem állandó eloszlás A vizuális és nyelvi minták alig fejlődnek évszázados időskálán, míg ugyanaz a felhasználó, aki egyik témában érdekelt, a következő percben megváltoztathatja lelkesedését. Ebből adódóan a felhasználói adatok mögöttes eloszlása nem állandó, ez a jelenség gyakran utal koncepció sodródásra . Intuitívan, a közelebbi múltból származó információk hatékonyabban járulhatnak hozzá egy felhasználó viselkedésének változásának előrejelzéséhez. A koncepció sodródás hatásának enyhítése érdekében a kiszolgáló modelleket a lehető legvalószerűbben kell frissíteni az új felhasználói visszajelzések alapján, hogy tükrözzék a felhasználó legújabb érdeklődését. Ezeket a különbségeket és a termelésünkben felmerülő problémákat megfigyelve terveztük meg a rendszert, egy nagyszabású ajánlórendszert, amely ezeket a problémákat hivatott megoldani. Kiterjedt kísérleteket végeztünk a tervezés igazolására és iterálására a termelési környezetben. A Monolith képes Monolith (1) A ritka jellemzők teljes kifejező erejének biztosítására egy ütközésmentes hash tábla és egy dinamikus jellemző eltávolítási mechanizmus tervezésével; (2) A kiszolgálási visszajelzések valós időben történő visszacsatolása az online képzéshez. Ezen építészeti képességek által felruházva a Monolith következetesen felülmúlja az ütközéseket alkalmazó hash-trükk rendszereket hasonló memóriahasználat mellett, és állandóan a legjobb online kiszolgálási AUC-t éri el anélkül, hogy túlzottan megterhelné szervereink számítási teljesítményét. A cikk további része a következőképpen szerveződik. Először ismertetjük a Monolith tervezési részleteit, hogy hogyan kezeli a meglévő kihívásokat az ütközésmentes hash táblával és a valós idejű képzéssel a 2. szakaszban. A kísérleteket és az eredményeket a 3. szakaszban mutatjuk be, a termelésben tesztelt következtetésekkel és néhány megjegyzéssel az időérzékenység, a megbízhatóság és a modell minőség közötti kompromisszumokról. A 4. szakasz összefoglalja a kapcsolódó munkákat és összehasonlítja őket a Monolith-tal. Az 5. szakasz zárja ezt a munkát. 2 TERVEZÉS A Monolith általános architektúrája általában a TensorFlow elosztott Worker- arameter erver beállítását követi (2. ábra). Egy Worker-PS architektúrában a gépek eltérő szerepeket kapnak; a Worker gépek felelősek a grafikon által definiált számítások elvégzéséért, a PS gépek pedig tárolják a paramétereket és frissítik azokat a Workerek által számított gradiens-ek alapján. P S Az ajánlási modellekben a paraméterek két csoportra oszthatók: sűrű és ritka. A sűrű paraméterek a mély neurális hálózat súlyai/változói, a ritka paraméterek pedig a ritka jellemzőknek megfelelő beágyazási táblák. Tervezésünkben mind a sűrű, mind a ritka paraméterek a TensorFlow grafikon részét képezik, és a paraméterkiszolgálókon tárolódnak. Hasonlóan a sűrű paraméterek TensorFlow Változójához, rendkívül hatékony, ütközésmentes és rugalmas HashTable műveleteket terveztünk a ritka paraméterekhez. A TensorFlow korlátainak kiegészítéseként, amelyek a képzés és az következtetés szétválasztásából adódnak, a Monolith rugalmasan skálázható online képzése hatékonyan szinkronizálja a paramétereket a képzési PS-től az online kiszolgáló PS-ig rövid időközönként, a hibatűrési mechanizmus által biztosított modellrobosztusság garanciájával. 2.1 Hash tábla A ritka paraméterek reprezentációjának tervezésében az elsődleges elvünk az, hogy elkerüljük az információk zsúfolását különböző azonosítók között ugyanabban a fix méretű beágyazásban. Egy dinamikus méretű beágyazási tábla szimulálása egy azonnal elérhető TensorFlow Változóval elkerülhetetlenül azonosító ütközéshez vezet, amely új azonosítók érkezésével és a tábla növekedésével súlyosbodik. Ezért a Változóra építés helyett egy új kulcs-érték HashTable-t fejlesztettünk ki a ritka paramétereinkhez. ] -et használja a háttérben, amely támogatja az új kulcsok beszúrását anélkül, hogy ütköznének a meglévőkkel. A Cuckoo Hashing a legrosszabb esetben 𝑂 (1) időkomplexitást ér el a lekérdezéseknél és törléseknél, és várhatóan amortizált 𝑂 (1) időt a beszúrásoknál. Ahogy a 3. ábra illusztrálja, két táblát 𝑇0, 𝑇1 tart fenn különböző hash funkciókkal ℎ0 (𝑥), ℎ1 (𝑥), és egy elem bekerül egyikükbe. Amikor megpróbálunk beszúrni egy elemet A HashTable a Cuckoo Hashmap [ 16 𝐴 a 𝑇0-ba, először megpróbálja elhelyezni az 𝐴-t a ℎ0 (𝐴) pozícióban; Ha a ℎ0 (𝐴) foglalt egy másik elemmel, 𝐵-vel, akkor kiűzi 𝐵-t a 𝑇0-ból, és megpróbálja beszúrni 𝐵-t a 𝑇1-be ugyanezzel a logikával. Ez a folyamat addig ismétlődik, amíg minden elem stabilizálódik, vagy újrahasíbolás történik, amikor a beszúrás ciklusba ütközik. A memóriahasználat csökkentése is fontos szempont a tervezésünkben. A naiv megközelítés, amely minden új azonosítót beszúr a HashTable-ba, gyorsan kimeríti a memóriát. A valós termelési modellek megfigyelése két következtetésre vezet: (1) Azok az azonosítók, amelyek csak néhány alkalommal jelennek meg, korlátozottan járulnak hozzá a modell minőségének javításához. Fontos megfigyelés, hogy az azonosítók hosszú farkú eloszlást mutatnak, ahol a népszerű azonosítók millió alkalommal fordulhatnak elő, míg a népszerűtlenek legfeljebb tízszer. Az ezekhez az alacsony előfordulású azonosítókhoz tartozó beágyazások alul vannak képzve a hiányzó képzési adatok miatt, és a modell nem tud jó becslést tenni alapjánuk. Végül is, ezek az azonosítók valószínűleg nem befolyásolják az eredményt, így a modell minősége nem fog szenvedni az alacsony előfordulások eltávolításától; (2) A távoli múltból származó elavult azonosítók ritkán járulnak hozzá a jelenlegi modellhez, mivel sokukat soha nem látogatnak meg. Ez valószínűleg annak tudható be, hogy egy felhasználó már nem aktív, vagy egy rövid videó elavult. Ezeknek az azonosítóknak a beágyazásainak tárolása semmiben sem segít a modellnek, csak hiába meríti ki a PS memóriánkat. Ezen megfigyelések alapján több jellemző azonosító szűrési heuristikát terveztünk a HashTable memóriahatékonyabb megvalósításához: (1) Az azonosítók szűrésre kerülnek, mielőtt bekerülnének a beágyazási táblákba. Két szűrési módszerünk van: Először az előfordulásuk alapján szűrjük őket, mielőtt kulcsként beszúrnánk őket, ahol az előfordulások küszöbe egy állítható hiperparaméter, amely minden modellnél eltérő; Ezenkívül egy valószínűségi szűrőt használunk, amely tovább csökkenti a memóriahasználatot; ![#4. ábra: Streaming Engine. Az információ-visszajelzési hurok a [Felhasználó → Modell Kiszolgáló → Képzési Worker → Modell Kiszolgáló → Felhasználó] útvonalon sok időt vesz igénybe a Kötegelt Képzés útvonalon, míg az Online Képzés azonnal lezárja a hurkot.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) Az azonosítók időzítettek és lejárnak egy előre meghatározott időszak inaktivitás után. A lejárati idő minden beágyazási táblánál állítható, hogy lehetővé tegye a különböző érzékenységű jellemzők megkülönböztetését a történelmi információkra nézve. A megvalósításunkban a HashTable egy Tensor-Flow erőforrás műveletként van implementálva. Hasonlóan a Változóhoz, a lekérdezések és frissítések is natív TensorFlow műveletekként vannak implementálva az egyszerűbb integráció és a jobb kompatibilitás érdekében. 2.2 Online képzés A Monolithban a képzés két szakaszra oszlik (1. ábra): (1) Kötegelt képzési szakasz. Ez a szakasz egy szokásos Tensor-Flow képzési ciklusban működik: minden képzési lépésben egy képzési worker elolvas egy minicsomagot a képzési példányokból a tárolóból, lekérdezi a paramétereket a PS-től, végrehajt egy előre- és egy visszamenőleges passzust, és végül feltölti a frissített paramétereket a képzési PS-re. A többi szokásos mélytanulási feladathoz képest kissé eltérően, az adatkészletünket csak egy passzban képezzük. A kötegelt képzés hasznos a történelmi adatok képzéséhez, amikor módosítjuk a modell architektúráját és újra képezzük a modellt; (2) Online képzési szakasz. Miután egy modellt üzembe helyeztek az online kiszolgáláshoz, a képzés nem áll le, hanem belép az online képzési szakaszba. Ahelyett, hogy minicsomag példányokat olvasna a tárolóból, egy képzési worker valós idejű adatokat fogyaszt útközben, és frissíti a képzési PS-t. A képzési PS időszakosan szinkronizálja a paramétereit a kiszolgáló PS-hez, amely azonnal hatályba lép a felhasználói oldalon. Ez lehetővé teszi, hogy a modellünk valós időben interaktívan alkalmazkodjon a felhasználó visszajelzéseihez. A Monolith képes zökkenőmentesen váltani a kötegelt és az online képzés között. Ezt a 4. ábrán illusztrált streaming motorunk kialakítása teszi lehetővé. 2.2.1 Streaming Engine. Tervezésünkben egy Kafka [ ] várólistát használunk a felhasználói műveletek (pl. elemre kattintás vagy kedvelés stb.) naplózására, és egy másik Kafka várólistát a jellemzők számára. A motor magja egy Flink [ ] streaming feladat az online jellemzőösszekötőhöz. Az online összekötő összeilleszti a jellemzőket a felhasználói műveletek címkéivel, és képzési példányokat állít elő, amelyeket aztán egy Kafka várólistába írnak. A képzési példányok várólistáját mind az online, mind a kötegelt képzés fogyasztja: 13 4 Online képzéshez a képzési worker közvetlenül olvassa az adatokat a Kafka várólistából; Kötegelt képzéshez egy adatmentő feladat először HDFS-re [ ] menti az adatokat; Miután az adatok HDFS-ben bizonyos mennyiségűre felhalmozódtak, a képzési worker lekéri az adatokat HDFS-ből, és kötegelt képzést végez. 18 A képzési PS-ben lévő frissített paramétereket a paraméterszinkronizálási ütemezésnek megfelelően a kiszolgáló PS-re küldjük. A valós alkalmazásokban a felhasználói műveletek naplója és a jellemzők az online joinerbe (5. ábra) kerülnek streamelve, időrendi sorrendi garancia nélkül. Ezért minden kéréshez egyedi kulcsot használunk, hogy a felhasználói művelet és a jellemzők helyesen párosíthatók legyenek. 2.2.2 Online Joiner. A felhasználói művelet késése is problémát jelenthet. Például egy felhasználó napokig is eltarthat, mire eldönti, hogy megvásárol egy elemet, amelyet napokkal ezelőtt mutattak be neki. Ez kihívást jelent az összekötő számára, mert ha minden jellemzőt a gyorsítótárban tartanak, akkor az egyszerűen nem fér el a memóriában. Rendszerünkben egy lemezre író kulcs-érték tárolót használunk a gyorsítótárban túlzottan sokáig várakozó jellemzők tárolására. Amikor egy felhasználói művelet naplója megérkezik, először a memórián belüli gyorsítótárat keresi, majd a kulcs-érték tárolót keresi, ha a gyorsítótárban nincs meg. Egy másik probléma, amely a valós alkalmazásokban felmerül, hogy a negatív és pozitív példányok eloszlása rendkívül egyenlőtlen, ahol az előbbiek száma nagyságrendekkel magasabb lehet, mint az utóbbiaké. Annak megakadályozására, hogy a pozitív példányokat elnyomják a negatívok, egy gyakori stratégia a negatív mintavétel. Ez minden bizonnyan megváltoztatja a képzett modell mögöttes eloszlását, finomítva azt a pozitív predikciók magasabb valószínűsége felé. Gyógyírként a kiszolgálás során log odds korrekciót [ ] alkalmazunk, biztosítva, hogy az online modell az eredeti eloszlás elfogulatlan becslője legyen. 19 Az online képzés során a Mono-lith képzési klaszter folyamatosan adatokat fogad az online kiszolgáló modulból, és frissíti a paramétereket a képzési PS-en. A legfontosabb lépés az online kiszolgáló PS számára, hogy profitáljon ezekből az újonnan képzett paraméterekből, a frissített modellparaméterek szinkronizálása. A termelési környezetben több kihívással szembesülünk: 2.2.3 Paraméterszinkronizálás. Az online kiszolgáló PS-en lévő modellek nem állhatnak le a kiszolgálásról frissítés közben. A termelésben lévő modelljeink általában több terabájtosak, és ennek eredményeképpen az összes paraméter cseréje időbe telik. Elfogadhatatlan lenne az online PS leállítása a modell kiszolgálása közben a csere folyamat során, és a frissítéseket menet közben kell elvégezni; Egy több terabájtos modell teljes egészének átvitele a képzési PS-ről az online kiszolgáló PS-re óriási terhet róna mind a hálózati sávszélességre, mind a PS memóriájára, mivel megduplázott modellméretű memóriát igényel az újonnan érkező modell befogadásához. Ahhoz, hogy az online képzés skálázódjon az üzleti forgatókönyvünk méretéig, inkrementális, menet közbeni, periodikus paraméterszinkronizálási mechanizmust terveztünk a Monolithban, több figyelemre méltó modelljellemzőnk alapján: (1) A ritka paraméterek dominálják az ajánlómodellek méretét; (2) Rövid időablakot figyelembe véve csak kevés azonosító kerül képzésre, és a beágyazásaik frissülnek; (3) A sűrű változók sokkal lassabban mozognak, mint a ritka beágyazások. Ennek oka, hogy az impulzus-alapú optimalizálókban a sűrű változók impulzus-felhalmozódását megnöveli az ajánlási képzési adatok hatalmas mérete, míg csak kevés ritka beágyazás kap frissítést egyetlen adatcsomagban. (1) és (2) lehetővé teszi számunkra, hogy kihasználjuk a ritka frissítéseket az összes jellemzőazonosító között. A Monolithban fenntartunk egy érintett kulcsokból álló hash halmazt, amely azokat az azonosítókat jelöli, amelyek beágyazásai az utolsó paraméterszinkronizálás óta képzésre kerültek. A ritka paraméterek azon részhalmazát küldjük el, amelyek kulcsai az érintett kulcsok halmazában vannak, perc szintű időközönként a képzési PS-ről az online kiszolgáló PS-re. Ez a viszonylag kis csomag inkrementális paraméterfrissítés könnyű a hálózati átvitelhez, és nem okoz éles memóriapihenést a szinkronizálás során. A (3) -at is kihasználjuk a hálózati I/O és a memóriahasználat további csökkentésére azáltal, hogy agresszívebb szinkronizálási ütemtervet állítunk be a ritka paraméterekhez, miközben a sűrű paramétereket ritkábban frissítjük. Ez olyan helyzethez vezethet, ahol a kiszolgált sűrű paraméterek viszonylag elavult verzióját képezik a ritka részhez képest. Azonban az ilyen következetlenség elfogadható a (3) -ban említett ok miatt, mivel nem figyeltek meg nyilvánvaló veszteséget. 2.3 Hibatűrés Mivel egy termelési rendszerről van szó, a Monolithot úgy tervezték, hogy képes legyen egy PS helyreállítására meghibásodás esetén. A hibatűrés gyakori választása a modell állapotának időszakos pillanatképének készítése, és a legújabb pillanatképből való helyreállítás, amikor PS hibát észlelnek. A pillanatkép gyakoriságának megválasztása két fő hatással van: (1) Modell minőség. Intuitívan, a modell minősége kevésbé szenved a nemrégiben elvesztett történelem miatt a pillanatkép gyakoriságának növelésével. (2) Számítási többletköltség. Egy több terabájtos modell pillanatképének elkészítése nem ingyenes. Nagy mennyiségű memóriakópiát és lemez I/O-t eredményez. A modell minőség és a számítási többletköltség közötti kompromisszumként a Monolith minden nap pillanatképet készít minden képzési PS-ről. Bár egy PS naponta egy napnyi frissítést veszít el meghibásodás esetén, a kísérleteink során azt tapasztaltuk, hogy a teljesítményromlás elfogadható. A következő szakaszban elemezzük a PS megbízhatóságának hatását. 3 ÉRTÉKELÉS A javasolt tervezés előnyeinek és kompromisszumainak jobb megértése érdekében több kísérletet végeztünk nagyszabású gyártási környezetben, és A/B teszteket élő kiszolgálási forgalommal, hogy különböző szempontokból értékeljük és igazoljuk a Monolithot. Kísérleteinkkel a következő kérdésekre kívánunk válaszolni: (1) Mennyit nyerhetünk egy ütközésmentes HashTable használatával? (2) Mennyire fontos a valós idejű online képzés? (3) Elég robusztus a Monolith paraméterszinkronizálási tervezése egy nagyszabású gyártási forgatókönyvben? Ebben a szakaszban először bemutatjuk a kísérleti beállításainkat, majd részletesen megvitatjuk az eredményeket és a megállapításainkat. 3.1 Kísérleti beállítás A 2.1. szakaszban leírtak szerint, a Monolithban az beágyazási táblákat ütközésmentes HashTablesként implementáltuk. Annak bizonyítására, hogy elkerülhetetlenek az ütközések az beágyazási táblákban, és hogy kvantifikáljuk az ütközésmentes megvalósításunkból származó nyereséget, két kísérletcsoportot végeztünk a Movielens adatkészleten és a belső termelési adatkészletünkön: 3.1.1 Embedding Table. (1) ml-25m adatkészlet [ ]. Ez egy standard nyilvános adatkészlet filmértékelésekhez, 25 millió értékelést tartalmaz, amelyek körülbelül 162000 felhasználót és 62000 filmet érintenek. MovieLens 11 • . Az eredeti címkék 0,5 és 5,0 közötti értékelések voltak, míg a termelésben a feladataink többnyire bináris jeleket fogadnak el a felhasználóktól. A termelési modelljeink jobb szimulálása érdekében a skálázott címkéket bináris címkékké alakítottuk át, a 3,5-ös vagy annál magasabb pontszámokat pozitív mintákként, a többit pedig negatív mintákként kezelve. • Modell és mérőszámok. Egy standard DeepFM modellt implementáltunk, amely egy gyakran használt modell architektúra az ajánlási problémákhoz. Egy FM komponensből és egy sűrű komponensből áll (6. ábra). Az előrejelzéseket az AUC értékeli, mivel ez a fő mérőszám a valós modellek esetében. • Embedding ütközések. Ez az adatkészlet körülbelül 160K felhasználói azonosítót és 60K filmazonosítót tartalmaz. Az beágyazási tábla ütközésmentes verziójának megvalósításával való összehasonlításhoz egy másik kísérletcsoportot végeztünk, ahol az azonosítókat MD5 hashinggal dolgoztuk fel, majd egy kisebb azonosítótérbe képeztük le. Ennek eredményeképpen egyes azonosítók megosztják beágyazásukat másokkal. Az 1. táblázat részletes statisztikákat mutat a felhasználói és filmazonosítókról a hashing előtt és után. Címkék előfeldolgozása (2) . Belső ajánló adatkészlet Kísérleteket végeztünk egy termelési környezetben lévő ajánlómodellel is. Ez a modell általában egy több torony architektúrát követ, ahol minden torony felelős egy speciális típusú felhasználói viselkedés előrejelzésének megtanulásáért. Minden modellnek körülbelül 1000 beágyazási táblája van, és a beágyazási táblák méretének eloszlása nagyon egyenlőtlen; Az beágyazási tábla eredeti azonosítótere 248 volt. Az alapmodellünkben egy hashing trükköt alkalmaztunk a beágyazási tábla méretének csökkentésére. Pontosabban, két kisebb beágyazási táblát használunk egyetlen hatalmas helyett, hogy egyedi beágyazást hozzunk létre minden azonosítóhoz vektor kombinációval: ahol 𝐸𝑟 , 𝐸𝑞 az 𝐼𝐷𝑟 , 𝐼𝐷𝑞 -nak megfelelő beágyazások. Ez hatékonyan csökkenti az beágyazási táblák méretét 248-ról 225-re; • Ez a modell valós termelésben van, és ennek a kísérletnek a teljesítményét online AUC méri valós kiszolgálási forgalommal. Az online képzés során az online kiszolgáló PS-t frissítjük a legfrissebb paraméterkészlettel percenkénti időközönként. Két kísérletcsoportot terveztünk a modell minőségének és a rendszer robusztusságának igazolására. 3.1.2 Online képzés. (1) . A percenkénti frissítési gyakoriság szükségességének vizsgálatához kísérleteket végeztünk, amelyek különböző időközönként szinkronizálják a paramétereket a képzési modellről a predikciós modellre. Frissítési gyakoriság Az általunk használt adatkészlet a Criteo Display Ads Challenge dataset3, egy nagyszabású standard adatkészlet CTR modellek összehasonlítására. 7 napnyi kronológiailag rendezett adatot tartalmaz a jellemzők és kattintási műveletek rögzítésével. Ehhez a kísérlethez egy standard DeepFM modellt használunk, amelyet a ismertet. 6 Az online képzés szimulálásához a következő előfeldolgozást végeztük az adatkészleten. Az adatkészletből 7 napnyi adatot veszünk, és két részre osztjuk: 5 nap adat kötegelt képzéshez, és 2 nap online képzéshez. A 2 napos adatot tovább osztjuk 𝑁 shard-ra kronológiailag. Az online képzés a algoritmus segítségével szimulálható. 1 Így szimuláljuk a képzett paraméterek szinkronizálását az online kiszolgáló PS-hez az adatszakaszok számától függő időközönként. Kísérleteztünk 𝑁 = 10, 50, 100 értékekkel, amelyek nagyjából 5 órás, 1 órás és 30 perces frissítési időközöknek felelnek meg. (2) . Ezenkívül végeztünk egy élő kísérletet is valós kiszolgálási forgalommal, hogy tovább demonstráljuk az online képzés fontosságát a valós alkalmazásban. Ez az A/B kísérlet összehasonlítja az online képzést a kötegelt képzéssel az egyik hirdetési modellünkön a termelésben. Élő kísérlet 3.2 Eredmények és elemzés A MovieLens adatkészletből és a belső ajánló adatkészletből származó eredmények is azt mutatják, hogy az beágyazási ütközések veszélyeztetik a modell minőségét. 3.2.1 Az Embedding ütközés hatása. (1) Az ütközésmentes HashTable-lal rendelkező modellek következetesen felülmúlják az ütközőket. Ez a következtetés igaz, függetlenül attól: A képzési epochok számának növekedése. Ahogy a 7. ábra mutatja, az ütközésmentes beágyazási táblával rendelkező modell az első epoktól kezdve magasabb AUC-val rendelkezik és magasabb értéken konvergál; Az eloszlás megváltozása az idő múlásával a koncepció sodródás miatt. Ahogy a 8. ábra mutatja, az ütközésmentes beágyazási táblával rendelkező modellek is robusztusak az idő múlásával, és a felhasználók/elemek kontextusa változik. (2) Az ütközésmentes beágyazási tábla által okozott adatritkaság nem vezet túlzott illeszkedéshez. Ahogy a 7. ábra mutatja, az ütközésmentes beágyazási táblával rendelkező modell nem illeszkedik túlzottan konvergencia után. ![#8. ábra: Az Embedding ütközés hatása egy ajánló modellre a termelésben A modell teljesítményét online kiszolgálási AUC-val mérjük, amely a koncepció sodródása miatt naponta ingadozik.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-d9i3eb9.jpeg) ![#9. ábra: Online képzés vs. Kötegelt képzés a Criteo adatkészleten. Kék vonalak: Online képzésű modellek AUC-ja; Sárga vonalak: Kötegelt képzésű modellek AUC-ja a streamelt adatokon értékelve.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-o0j3ej8.jpeg) Felfedeztük, hogy a magasabb paraméterszinkronizálási gyakoriság mindig kedvez az online kiszolgálási AUC javításának, és hogy az online kiszolgáló modellek jobban tolerálják a néhány PS shard elvesztését, mint vártuk. 3.2.2 Online képzés: Megbízhatóság feláldozása a valós idejűségért. (1) . A Criteo Display Ads Challenge adatkészleten végzett online streamelt képzési kísérletünkben a modell minősége következetesen javul a paraméterszinkronizálási gyakoriság növekedésével, amint az két szempontból látható: A Paraméterszinkronizálási Frekvencia Hatása (1) • Az online képzéssel rendelkező modellek jobban teljesítenek, mint a nélküliek. A 9a., 9b., 9c. ábra az online képzési modellek AUC-ját hasonlítja össze, amelyeket az adatok következő shard-jával értékelünk, szemben a kötegelt képzési modellekkel, amelyeket minden shard adatával értékelünk; • A kisebb paraméterszinkronizálási intervallummal rendelkező modellek jobban teljesítenek, mint a nagyobb intervallummal rendelkezők. A 10. ábra és a 2. táblázat az online kiszolgálási AUC-t hasonlítja össze az 5 órás, 1 órás és 30 perces szinkronizálási intervallummal rendelkező modellek esetében. Az élő A/B kísérlet az online képzés és a kötegelt képzés között egy hirdetési modellen a termelésben szintén jelentős emelkedést mutat az online kiszolgálási AUC-ban (3. táblázat). Ezen megfigyelés alapján a termelési modelljeink ritka paramétereit a lehető leggyakrabban (jelenleg percenként) szinkronizáljuk a kiszolgáló PS-re, a számítási többletköltség és a rendszer megbízhatósága által megengedett mértékig. Emlékeztetve arra, hogy a sűrű változók ritkább frissítést igényelnek a 2.2.3. szakaszban tárgyaltak szerint, ezeket napi szinten frissítjük. Ezzel a számítási többletköltséget nagyon alacsony szintre csökkenthetjük. Tegyük fel, hogy 100 000 azonosítót frissítenek egy perc alatt, és a beágyazás dimenziója 1024, az átvitelre kerülő adatok teljes mérete 4KB × 100 000 ≈ 400MB percenként. A sűrű paraméterek esetében, mivel naponta szinkronizálódnak, úgy ütemezzük a szinkronizálást, amikor a forgalom a legalacsonyabb (pl. éjfélkor). (2) A PS megbízhatóságának hatása. Percenkénti paraméterszinkronizálással kezdetben a képzési PS gyakoribb pillanatképét vártuk, hogy illeszkedjen a valós idejű frissítéshez. Meglepő módon megnöveltük a pillanatkép intervallumot 1 napra, és továbbra is szinte semmilyen minőségveszteséget nem tapasztaltunk. A modell minőség és a számítási többletköltség közötti megfelelő kompromisszum megtalálása nehéz a személyre szabott rangsoroló rendszerek esetében, mivel a felhasználók rendkívül érzékenyek a rangsorolási minőségre. Hagyományosan a nagyszabású rendszerek gyakori pillanatkép ütemtervet állítanak be modelljeikhez, ami számítási erőforrásokat áldoz fel a modellminőség minimalizált veszteségéért cserébe. Mi is végeztünk némi kutatást ebben a tekintetben, és meglepetésünkre a modell minősége a vártnál robusztusabb. Napi 0,01%-os PS gép meghibásodási arány mellett azt találtuk, hogy egy előző napi modell elfogadhatatlanul jól teljesít. Ez a következő számítással magyarázható: Tegyük fel, hogy egy modell paraméterei 1000 PS-en vannak felosztva, és naponta készítenek róluk pillanatképet. 0,01%-os meghibásodási arány mellett minden 10. napon az egyik meghibásodik, és elveszítjük az ezen a PS-en végzett összes frissítést 1 napra. Feltételezve 15 milliós napi aktív felhasználót (DAU) és a felhasználói azonosítók egyenletes eloszlását minden PS-en, 10 naponta 15000 felhasználó 1 napos visszajelzését veszítjük el. Ez elfogadható, mert (a) A ritka jellemzők esetében, amelyek felhasználóspecifikusak, ez megegyezik a napi aktív felhasználók 0,01%-ának kis töredékének elvesztésével; (b) A sűrű változók esetében, mivel ezek lassan frissülnek, ahogy a 2.2.3. szakaszban tárgyaltuk, 1000 PS 1 napos frissítésének elvesztése elhanyagolható. A fenti megfigyelés és számítás alapján radikálisan csökkentettük a pillanatkép gyakoriságát, és ezáltal jelentős megtakarítást értünk el a számítási többletköltségekben. 4 KAPCSOLÓDÓ MUNKÁK Mióta az ipari szintű ajánlórendszerekben az első sikeres mélytanulási alkalmazások [ , ] megjelentek, a kutatók és mérnökök különféle technikákat alkalmaztak az 1. szakaszban említett problémák enyhítésére. 6 10 A ritka jellemzők reprezentációjának problémájának megoldására [ , ] fix méretű beágyazási táblát használ hash-trükkel. Vannak kísérletek a hashing javítására az ütközés csökkentése érdekében [ , ]. Más munkák natív kulcs-érték hash táblákat használnak a táblaméret dinamikus növekedésének lehetővé tétele érdekében [ , , , ]. Ezek a megvalósítások a TensorFlow-ra épülnek, de vagy speciálisan tervezett szoftvermechanizmusokra [ , , ], vagy hardverre [ ] támaszkodnak a hash-táblákhoz való hozzáféréshez és kezelésükhöz. Ezekhez a megoldásokhoz képest a Monolith hash-táblája egy újabb natív TensorFlow művelet. Fejlesztőbarát és magasabb platformfüggetlen interoperabilitással rendelkezik, ami alkalmas a ToB forgatókönyvekre. A TensorFlow szerves és szoros integrációja megkönnyíti a számítási teljesítmény optimalizálását is. 3 6 3 7 12 15 20 21 14 15 20 21 A képzés és a kiszolgálás közötti szakadék áthidalása és a koncepció sodródás [ ] enyhítése szintén érdeklődésre tart számot. Az online frissítés támogatása és a memóriaproblémák elkerülése érdekében mind [ ], mind [ ] jellemző eltávolítási mechanizmusokat terveztek a beágyazási táblák méretének rugalmas beállításához. Mind [ ], mind [ ] támogatja az online képzés valamilyen formáját, ahol a megtanult paramétereket viszonylag rövid időközönként szinkronizálják a kiszolgáláshoz a hagyományos kötegelt képzéshez képest, hibatűrési mechanizmusokkal. A Monolith hasonló megközelítést alkalmazott a jellemzők rugalmas befogadására és eltávolítására, míg könnyebb paraméterszinkronizálási mechanizmusa garantálja a modell minőségét. 8 12 20 12 14 5 KÖVETKEZTETÉS Ebben a munkában áttekintettük az ipari szintű ajánlórendszerek néhány legfontosabb kihívását, és bemutattuk a termelésben lévő Monolith rendszerünket, hogy megoldjuk őket, és a legjobb teljesítményt érjük el a meglévő megoldásokhoz képest. Bizonyítottuk, hogy az ütközésmentes beágyazási tábla elengedhetetlen a modell minőségéhez, és bemutattuk, hogy a Cuckoo HashMap alapú beágyazási táblánk megvalósítása memóriahatékony és hasznos az online kiszolgálási metrikák javításában. Azt is bizonyítottuk, hogy a valós idejű kiszolgálás kulcsfontosságú az ajánlórendszerekben, és hogy a paraméterszinkronizálási intervallumnak a lehető legrövidebbnek kell lennie a végső modellteljesítmény érdekében. Online valós idejű kiszolgálási megoldásunk a Monolithban gondosan megtervezett paraméterszinkronizálással és hibatűrési mechanizmussal rendelkezik: Paraméterszinkronizálási algoritmusunkban kimutattuk, hogy a paraméterek különböző részei közötti verziókonzisztencia feláldozható a hálózati sávszélesség-fogyasztás csökkentése érdekében; A hibatűrési tervezésben bemutattuk, hogy a PS megbízhatóságának valós idejűségért cserébe történő feláldozására irányuló stratégiánk robusztus megoldás. Összefoglalva, a Monolith sikeresen általános megoldást nyújtott a termelési szintű ajánlórendszerekhez. ELISMERÉSEK Hanzhi Zhou hasznos javaslatokat tett e cikk átdolgozásához. REFERENCIÁK Martín Abadi, Paul Barham, Jianmin Chen, Z. Chen, Andy Davis, Jeffrey Dean, Matthieu Devin, Sanjay Ghemawat, Geoffrey Irving, Michael Isard, Manjunath Kudlur, Josh Levenberg, Rajat Monga, Sherry Moore, Derek Gordon Murray, Benoit Steiner, Paul A. Tucker, Vijay Vasudevan, Pete Warden, Martin Wicke, Yuan Yu, és Xiaoqiang Zhang. 2016. TensorFlow: A system for large-scale machine learning. abs/1605.08695 (2016). ArXiv Andrew P. Bradley. 1997. The use of the area under the ROC curve in the evaluation of machine learning algorithms. 30 (1997), 1145–1159. Pattern Recognit. Thomas Bredillet. 2019. Core modeling at Instagram. https://instagram-engineering.com/core-modeling-at-instagram-a51e0158aa48 Paris Carbone, Asterios Katsifodimos, Stephan Ewen, Volker Markl, Seif Haridi, és Kostas Tzoumas. 2015. Apache Flink™: Stream and Batch Processing in a Single Engine. 38 (2015), 28–38. IEEE Data Eng. Bull. Heng-Tze Cheng, Levent Koc, Jeremiah Harmsen, Tal Shaked, Tushar Chandra, Hrishikesh B. Aradhye, Glen Anderson, Gregory S. Corrado, Wei Chai, Mustafa Ispir, Rohan Anil, Zakaria Haque, Lichan Hong, Vihan Jain, Xiaobing Liu, és Hemal Shah. 2016. Wide & Deep Learning for Recommender Systems. (2016). Proceedings of the 1st Workshop on Deep Learning for Recommender Systems Paul Covington, Jay K. Adams, és Emre Sargin. 2016. Deep Neural Networks for YouTube Recommendations. (2016). Proceedings of the 10th ACM Conference on Recommender Systems Alexandra Egg. 2021. Online Learning for Recommendations at Grubhub. (2021). Fifteenth ACM Conference on Recommender Systems João Gama, Indre˙ Žliobaite˙, Albert Bifet, Mykola Pechenizkiy, és A. Bouchachia. 2014. A survey on concept drift adaptation. 46 (2014), 1 – 37. ACM Computing Surveys (CSUR) Huifeng Guo, Ruiming Tang, Yunming Ye, Zhenguo Li, és Xiuqiang He. 2017. DeepFM: A Factorization-Machine based Neural Network for CTR Prediction. In . IJCAI Udit Gupta, Xiaodong Wang, Maxim Naumov, Carole-Jean Wu, Brandon Reagen, David M. Brooks, Bradford Cottel, Kim M. Hazelwood, Bill Jia, Hsien-Hsin S. Lee, Andrey Malevich, Dheevatsa Mudigere, Mikhail Smelyanskiy, Liang Xiong, és Xuan Zhang. 2020. The Architectural Implications of Facebook’s DNN-Based Personalized Recommendation. (2020), 488–501. 2020 IEEE International Symposium on High Performance Computer Architecture (HPCA) F. Maxwell Harper és Joseph A. Konstan. 2015. The MovieLens Datasets: History and Context. 5 (2015), 19:1–19:19. ACM Trans. Interact. Intell. Syst. Biye Jiang, Chao Deng, Huimin Yi, Zelin Hu, Guorui Zhou, Yang Zheng, Sui Huang, Xinyang Guo, Dongyue Wang, Yue Song, Liqin Zhao, Zhi Wang, Peng Sun, Yu Zhang, Di Zhang, Jinhui Li, Jian Xu, Xiaoqiang Zhu, és Kun Gai. 2019. XDL: an industrial deep learning framework for high-dimensional sparse data. (2019). Proceedings of the 1st International Workshop on Deep Learning Practice for High-Dimensional Sparse Data Jay Kreps. 2011. Kafka : a Distributed Messaging System for Log Processing. Xiangru Lian, Binhang Yuan, Xuefeng Zhu, Yulong Wang, Yongjun He, Honghuan Wu, Lei Sun, Haodong Lyu, Chengjun Liu, Xing Dong, Yiqiao Liao, Mingnan Luo, Congfei Zhang, Jingru Xie, Haonan Li, Lei Chen, Renjie Huang, Jianying Lin, Chengchun Shu, Xue-Bo Qiu, Zhishan Liu, Dongying Kong, Lei Yuan, Hai bo Yu, Sen Yang, Ce Zhang, és Ji Liu. 2021. Persia: An Open, Hybrid System Scaling Deep Learning-based Recommenders up to 100 Trillion Parameters. abs/2111.05897 (2021). ArXiv Meituan. 2021. Distributed Training Optimization for TensorFlow in Recom-mender Systems (kínaiul). https://tech.meituan.com/2021/12/09/meituan-tensorflow-in-recommender-systems.html R. Pagh és Flemming Friche Rodler. 2001. Cuckoo Hashing. In . ESA Adam Paszke, Sam Gross, Francisco Massa, Adam Lerer, James Bradbury, Gregory Chanan, Trevor Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga, Alban Desmaison, Andreas Köpf, Edward Yang, Zach DeVito, Martin Raison, Alykhan Tejani, Sasank Chilamkurthy, Benoit Steiner, Lu Fang, Junjie Bai, és Soumith Chintala. 2019. PyTorch: An Imperative Style, High-Performance Deep Learning Library. In . NeurIPS Konstantin V. Shvachko, Hairong Kuang, Sanjay R. Radia, és Robert J. Chansler. 2010. The Hadoop Distributed File System. (2010), 1–10. 2010 IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST) HaiYing Wang, Aonan Zhang, és Chong Wang. 2021. Nonuniform Negative Sampling and Log Odds Correction with Rare Events Data. In . Advances in Neural Information Processing Systems Minhui Xie, Kai Ren, Youyou Lu, Guangxu Yang, Qingxing Xu, Bihai Wu, Jiazhen Lin, Hongbo Ao, Wanhong Xu, és Jiwu Shu. 2020. Kraken: Memory-Efficient Continual Learning for Large-Scale Real-Time Recommendations. (2020), 1–17. SC20: Inter-national Conference for High Performance Computing, Networking, Storage and Analysis Weijie Zhao, Jingyuan Zhang, Deping Xie, Yulei Qian, Ronglai Jia, és Ping Li. 2019. AIBox: CTR Prediction Model Training on a Single Node. (2019). Proceedings of the 28th ACM International Conference on Information and Knowledge Management Ez a cikk CC by 4.0 Deed (Attribution 4.0 International) licenc alatt. elérhető az arxiv-on