Uvnitř ByteDance’s Monolith: Motor pohánějící chytřejší a rychlejší obsahové kanály

```html < Autoři: 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 University Yijie Zhu, Bytedance Inc. Peng Wu, Bytedance Inc. Ke Wang, Bytedance Inc. Youlong Cheng†, Bytedance Inc. (youlong.cheng@bytedance.com) ABSTRAKT Budování škálovatelného a real-time doporučovacího systému je klíčové pro mnoho podniků poháněných časově citlivou zpětnou vazbou od zákazníků, jako je hodnocení krátkých videí nebo online reklamy. Navzdory všudypřítomnému přijetí produkčních deep learningových frameworků jako TensorFlow nebo PyTorch tyto obecně použitelné frameworky nesplňují obchodní požadavky v doporučovacích scénářích z různých důvodů: na jedné straně je ladění systémů na základě statických parametrů a hustých výpočtů pro doporučování s dynamickými a řídkými funkcemi škodlivé pro kvalitu modelu; na druhé straně jsou tyto frameworky navrženy s kompletně oddělenou fází dávkového trénování a fází obsluhy, což brání modelu v interakci se zpětnou vazbou od zákazníků v reálném čase. Tyto problémy nás vedly k přezkoumání tradičních přístupů a k prozkoumání radikálně odlišných návrhových voleb. V tomto článku představujeme 1, systém přizpůsobený pro online trénování. Náš návrh byl veden pozorováními našich aplikačních pracovních zátěží a produkčního prostředí, které odrážejí znatelný odklon od ostatních doporučovacích systémů. Naše příspěvky jsou mnohostranné: zaprvé jsme vytvořili kolizní embeddingovou tabulku s optimalizacemi, jako jsou expirační embeddingy a filtrování frekvence, abychom snížili její paměťovou náročnost; zadruhé poskytujeme produkčně připravenou online trénovací architekturu s vysokou odolností proti chybám; konečně jsme dokázali, že spolehlivost systému lze vyměnit za real-time učení. Monolith byl úspěšně implementován do produktu BytePlus Recommend2. Monolith 1 ÚVOD Minulé desetiletí bylo svědkem boomu podnikání poháněného doporučovacími technikami. Ve snaze o lepší zákaznickou zkušenost je personalizovaný obsah pro každého jednotlivého uživatele dodávaný v reálném čase běžným cílem těchto obchodních aplikací. K tomuto účelu jsou informace z poslední interakce uživatele často používány jako primární vstup pro trénování modelu, protože by nejlépe zobrazovaly profil uživatele a předpovídaly zájem a budoucí chování uživatele. Deep learning dominuje v doporučovacích modelech [ , , , , , ], protože obrovské množství uživatelských dat je přirozeně vhodné pro masivně datově řízené neuronové modely. Úsilí o využití síly deep learningu v doporučovacích systémech na průmyslové úrovni se však neustále setkává s problémy vyplývajícími z jedinečných charakteristik dat odvozených z reálného chování uživatelů. Tato data se drasticky liší od dat používaných v konvenčních problémech deep learningu, jako je jazykové modelování nebo počítačové vidění, ve dvou aspektech: 5 6 10 12 20 21 (1) Vlastnosti jsou většinou řídké, kategorické a dynamicky se měnící; (2) Základní distribuce trénovacích dat je nestacionární, neboli Concept Drift [8]. Tyto rozdíly představují jedinečné výzvy pro výzkumníky a inženýry pracující na doporučovacích systémech. 1.1 Řídkost a dynamičnost Data pro doporučování většinou obsahují řídké kategorické vlastnosti, z nichž některé se vyskytují s nízkou frekvencí. Běžná praxe mapování těchto vlastností do vysokorozměrného embeddingového prostoru vede k řadě problémů: • Na rozdíl od jazykových modelů, kde je počet slovních dílů omezen, počet uživatelů a hodnocených položek je o řády větší. Takto obrovská embeddingová tabulka by se stěží vešla do paměti jednoho hostitele; • Co je horší, velikost embeddingové tabulky se očekává, že poroste s časem, jak přibývá více uživatelů a položek, zatímco frameworky jako [ , ] používají husté proměnné pevné velikosti k reprezentaci embeddingové tabulky. 1 17 V praxi mnoho systémů používá hašování s nízkým počtem kolizí [ , ] jako způsob, jak snížit paměťovou náročnost a umožnit růst ID. To se spoléhá na příliš idealistický předpoklad, že ID v embeddingové tabulce jsou rovnoměrně rozložena podle frekvence a kolize nepoškozují kvalitu modelu. Bohužel, to je ve skutečném doporučovacím systému, kde malá skupina uživatelů nebo položek má výrazně více výskytů, zřídkakdy pravda. S organickým růstem velikosti embeddingové tabulky se zvyšuje pravděpodobnost kolize hash klíčů a vede ke zhoršení kvality modelu 3 6 [3]. Proto je přirozeným požadavkem pro produkční doporučovací systémy mít kapacitu zachytit co nejvíce vlastností ve svých parametrech a také schopnost elasticky upravovat počet uživatelů a položek, které si snaží vést. 1.2 Nestacionární distribuce Vizuální a lingvistické vzorce se sotva vyvíjejí v časovém měřítku staletí, zatímco stejný uživatel, který se zajímá o jedno téma, může změnit své nadšení každou další minutu. V důsledku toho je základní distribuce uživatelských dat nestacionární, jev běžně označovaný jako Concept Drift [8]. Intuitivně, informace z nedávnější historie mohou efektivněji přispět k předpovídání změn v chování uživatele. Aby se zmírnil účinek Concept Drift, musí být obslužné modely aktualizovány z nové zpětné vazby uživatele co nejblíže k reálnému času, aby odrážely nejnovější zájem uživatele. Vzhledem k těmto rozdílům a s ohledem na problémy, které vznikají v naší produkci, jsme navrhli , rozsáhlý doporučovací systém, který řeší tyto bolestivé body. Provedli jsme rozsáhlé experimenty k ověření a iteraci našeho návrhu v produkčním prostředí. Monolith je schopen Monolith (1) Poskytovat plnou expresivní sílu pro řídké vlastnosti návrhem nekolizní hashovací tabulky a mechanismu pro dynamické vyřazování vlastností; (2) Vracet zpětnou vazbu z obsluhy do trénování v reálném čase s online trénováním. Díky těmto architektonickým kapacitám Monolith konzistentně překonává systémy, které používají hash-tricks s kolizemi, s přibližně podobným využitím paměti a dosahuje špičkového online AUC bez nadměrného zatížení výpočetního výkonu našich serverů. Zbytek článku je strukturován následovně. Nejprve podrobně rozebíráme návrhové detaily toho, jak Monolith řeší existující výzvy s nekolizní hashovací tabulkou a real-time trénováním v sekci 2. Experimenty a výsledky budou prezentovány v sekci 3 spolu s produkčně testovanými závěry a diskusí o kompromisech mezi časovou citlivostí, spolehlivostí a kvalitou modelu. Sekce 4 shrnuje související práce a porovnává je s Monolithem. Sekce 5 uzavírá tuto práci. 2 NÁVRH Celková architektura Monolith obecně následuje rozdělení Worker-ParameterServer (PS) od TensorFlow (Obrázek V architektuře Worker-PS jsou strojům přiděleny různé role; Worker stroje jsou zodpovědné za provádění výpočtů definovaných grafem a PS stroje ukládají parametry a aktualizují je podle gradientů vypočítaných Workery. 2). V doporučovacích modelech jsou parametry rozděleny do dvou sad: husté a řídké. Husté parametry jsou váhy/proměnné v hluboké neuronové síti a řídké parametry odkazují na embeddingové tabulky, které odpovídají řídkým vlastnostem. V našem návrhu jsou oba, husté i řídké parametry, součástí grafu TensorFlow a jsou uloženy na parametrových serverech. Podobně jako proměnná TensorFlow pro husté parametry jsme navrhli sadu vysoce efektivních, nekolizních a flexibilních operací HashTable pro řídké parametry. Jako doplněk k omezením TensorFlow vyplývajícím z oddělení trénování a inference je online trénování Monolith s elastickou škálovatelností navrženo tak, aby efektivně synchronizovalo parametry z trénovacího PS na online obslužný PS v krátkých intervalech, s garancí robustnosti modelu poskytovanou mechanismem odolnosti proti chybám. 2.1 Hashovací tabulka Prvním principem našeho návrhu reprezentace řídkých parametrů je vyhnout se vmáčknutí informací z různých ID do stejného embeddingu pevné velikosti. Simulace dynamické velikosti embeddingové tabulky s hotovou proměnnou TensorFlow nevyhnutelně vede ke kolizi ID, která se zhoršuje s příchodem nových ID a růstem tabulky. Proto jsme namísto stavění na proměnných vyvinuli novou HashTable klíč-hodnota pro naše řídké parametry. Naše HashTable využívá Cuckoo Hashmap [ ] pod kapotou, která podporuje vkládání nových klíčů bez kolizí s existujícími. Cuckoo Hashing dosahuje nejhoršího případu 𝑂 (1) časové složitosti pro vyhledávání a mazání a očekávané amortizované 𝑂 (1) času pro vkládání. Jak je znázorněno na Obrázku udržuje dvě tabulky 𝑇0, 𝑇1 s různými hashovacími funkcemi ℎ0 (𝑥), ℎ1 (𝑥) a prvek by byl uložen v jedné z nich. Při pokusu o vložení prvku 16 3, 𝐴 do 𝑇0 se nejprve pokusí umístit 𝐴 na ℎ0 (𝐴); pokud je ℎ0 (𝐴) obsazeno jiným prvkem 𝐵, 𝐵 se z 𝑇0 odstraní a pokusí se vložit 𝐵 do 𝑇1 se stejnou logikou. Tento proces se bude opakovat, dokud se všechny prvky stabilizují, nebo dojde k přehašování, pokud vkládání narazí na cyklus. Snížení paměťové náročnosti je také důležitým faktorem našeho návrhu. Naivní přístup k vkládání každého nového ID do HashTable rychle vyčerpá paměť. Pozorování reálných produkčních modelů vedlo ke dvěma závěrům: (1) ID, která se vyskytují pouze několikrát, mají omezený přínos ke zlepšení kvality modelu. Důležité pozorování je, že ID jsou distribuována podle dlouhého ocasu, kde populární ID se mohou vyskytovat miliony krát, zatímco nepopulární se vyskytují nejvýše desetkrát. Embeddingy odpovídající těmto málo častým ID jsou nedostatečně trénované kvůli nedostatku trénovacích dat a model nebude schopen na nich učinit dobrý odhad. Ve výsledku tato ID pravděpodobně neovlivní výsledek, takže kvalita modelu neutrpí odstraněním těchto ID s nízkým výskytem; (2) Zastaralá ID ze vzdálené historie zřídka přispívají k aktuálnímu modelu, protože mnoho z nich není nikdy navštíveno. To může být způsobeno uživatelem, který již není aktivní, nebo krátkým videem, které je zastaralé. Ukládání embeddingů pro tato ID nemůže modelu nijak pomoci, kromě marného vyčerpávání naší PS paměti. Na základě těchto pozorování jsme navrhli několik heuristik pro filtrování ID vlastností pro efektivnější implementaci HashTable z hlediska paměti: (1) ID jsou filtrovány před jejich přijetím do embeddingových tabulek. Máme dvě metody filtrování: nejprve filtrujeme podle jejich výskytů před jejich vložením jako klíčů, kde prahová hodnota výskytů je laditelný hyperparametr, který se liší pro každý model; navíc využíváme pravděpodobnostní filtr, který pomáhá dále snižovat využití paměti; ![#Figure 4: Streaming Engine. Informační zpětnovazební smyčka od [Uživatel → Model Server → Trénovací Worker → Model Server → Uživatel] by trvala dlouho na cestě Dávkového Trénování, zatímco Online Trénování by uzavřelo smyčku okamžitěji.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID jsou časována a nastavena na expiraci po neaktivitě po předem definovanou dobu. Doba expirace je také laditelná pro každou embeddingovou tabulku, aby bylo možné rozlišovat vlastnosti s různou citlivostí na historické informace. V naší implementaci je HashTable implementována jako operace zdroje TensorFlow. Podobně jako u Variable jsou vyhledávání a aktualizace také implementovány jako nativní operace TensorFlow pro snadnější integraci a lepší kompatibilitu. 2.2 Online trénování V Monolith je trénování rozděleno do dvou fází (Obrázek 1): (1) Fáze dávkového trénování. Tato fáze funguje jako běžná trénovací smyčka TensorFlow: V každém trénovacím kroku trénovací worker čte jednu mini-dávku trénovacích příkladů ze úložiště, požaduje parametry od PS, provede dopředný a zpětný průchod a nakonec nahraje aktualizované parametry do trénovacího PS. Mírně odlišně od jiných běžných úloh deep learningu trénujeme náš dataset pouze pro jeden průchod. Dávkové trénování je užitečné pro trénování historických dat, když upravujeme architekturu našeho modelu a znovu trénujeme model; (2) Fáze online trénování. Po nasazení modelu do online obsluhy trénování nekončí, ale vstupuje do fáze online trénování. Místo čtení mini-dávek příkladů z úložiště trénovací worker konzumuje data v reálném čase za běhu a aktualizuje trénovací PS. Trénovací PS periodicky synchronizuje své parametry s obslužným PS, což se okamžitě projeví na straně uživatele. To umožňuje našemu modelu interaktivně se přizpůsobovat zpětné vazbě uživatele v reálném čase. Monolith je postaven se schopností plynule přepínat mezi dávkovým a online trénováním. To je umožněno naším návrhem streamovacího enginu, jak je znázorněno na Obrázku 2.2.1 Streaming Engine. 4. V našem návrhu používáme jednu frontu Kafka [ ] k zaznamenávání akcí uživatelů (např. kliknutí na položku nebo označení položky jako oblíbené atd.) a druhou frontu Kafka pro vlastnosti. Jádrem enginu je Flink [ ] streamovací úloha pro online joiner vlastností. Online joiner spojuje vlastnosti se štítky z akcí uživatelů a vytváří trénovací příklady, které jsou následně zapsány do fronty Kafka. Fronta pro trénovací příklady je konzumována jak online trénováním, tak dávkovým trénováním: 13 4 Pro online trénování trénovací worker přímo čte data z fronty Kafka; Pro dávkové trénování úloha pro výpis dat nejprve vypíše data do HDFS [ ]; Poté, co se data v HDFS nashromáždí do určitého množství, trénovací worker načte data z HDFS a provede dávkové trénování. 18 Aktualizované parametry v trénovacím PS budou nahrány do obslužného PS podle plánu synchronizace parametrů. V reálných aplikacích jsou logy akcí uživatelů a vlastnosti streamovány do online joineru (Obrázek bez záruky pořadí. Proto používáme jedinečný klíč pro každý požadavek, aby bylo možné správně spárovat akci uživatele a vlastnosti. 2.2.2 Online Joiner. 5) Zpoždění akce uživatele může být také problémem. Například uživatel může předtím, než se rozhodne koupit položku, kterou mu byl prezentován před dny, trvat několik dní. To je výzva pro joiner, protože pokud by všechny vlastnosti zůstaly v cache, jednoduše by se nevešly do paměti. V našem systému se používá on-disk key-value úložiště pro ukládání vlastností, které čekají po určitou dobu. Když dorazí log akce uživatele, nejprve vyhledá v paměťové cache a poté v případě chybějící cache vyhledá key-value úložiště. Dalším problémem, který vzniká v reálných aplikacích, je, že distribuce negativních a pozitivních příkladů je vysoce nerovnoměrná, přičemž počet prvních může být o řády vyšší než počet druhých. Aby se zabránilo přehlcení pozitivních příkladů negativními, běžnou strategií je negativní vzorkování. To by jistě změnilo základní distribuci trénovaného modelu a upravilo by ho směrem k vyšší pravděpodobnosti pozitivních predikcí. Jako nápravu používáme korekci log-odds [ ] během obsluhy, čímž zajišťujeme, že online model je nezaujatý odhad původní distribuce. 19 Během online trénování trénovací cluster Monolith nepřetržitě přijímá data z online obslužného modulu a aktualizuje parametry na trénovacím PS. Klíčovým krokem, který umožňuje obslužnému PS Monolithu těžit z těchto nově natrénovaných parametrů, je synchronizace aktualizovaných parametrů modelu. V produkčním prostředí se setkáváme s několika problémy: 2.2.3 Synchronizace parametrů. Modely na online obslužném PS nesmí přestat obsluhovat během aktualizace. Naše modely v produkci mají obvykle velikost několik terabytů a nahrazení všech parametrů tedy trvá. Zastavení online PS v obsluze modelu během procesu nahrazování by bylo netolerovatelné a aktualizace musí být prováděny za běhu; Přenos celého multi-terabytového modelu z trénovacího PS na online obslužný PS by představoval obrovský tlak jak na šířku pásma sítě, tak na paměť PS, protože vyžaduje dvojnásobnou velikost paměti modelu pro přijetí nově příchozího modelu. Aby se online trénování mohlo škálovat na velikost našeho obchodního scénáře, navrhli jsme inkrementální periodickou synchronizační mechanismus parametrů za běhu v Monolith na základě několika znatelných charakteristik našich modelů: (1) Řídké parametry dominují velikosti doporučovacích modelů; (2) V daném krátkém časovém okně se trénuje a aktualizují se pouze malé podmnožiny ID jejich embeddingů; (3) Husté proměnné se pohybují mnohem pomaleji než řídké embeddingy. Je to proto, že v optimalizačních algoritmech založených na momentu se akumulace momentu pro husté proměnné zvětšuje obrovskou velikostí trénovacích dat pro doporučování, zatímco pouze několik řídkých embeddingů přijímá aktualizace v jedné datové dávce. (1) a (2) nám umožňují využít řídké aktualizace napříč všemi ID vlastností. V Monolith udržujeme hash set dotčených klíčů, reprezentujících ID, jejichž embeddingy byly trénovány od poslední synchronizace parametrů. Tuto podmnožinu řídkých parametrů, jejichž klíče jsou v sadě dotčených klíčů, pushujeme s minutovým časovým intervalem z trénovacího PS na online obslužný PS. Tato relativně malá sada inkrementálních aktualizací parametrů je lehká pro přenos přes síť a nezpůsobí prudký nárůst paměti během synchronizace. Využíváme také (3) k dalšímu snížení I/O sítě a využití paměti nastavením agresivnějšího sync harmonogramu pro řídké parametry, zatímco husté parametry aktualizujeme méně často. To nám může poskytnout situaci, kdy husté parametry, které obsluhujeme, jsou relativně zastaralou verzí ve srovnání s řídkou částí. Nicméně taková nekonzistence může být tolerována z důvodů uvedených v (3), protože nebyly pozorovány žádné zjevné ztráty. 2.3 Odolnost proti chybám Jako systém v produkci je Monolith navržen se schopností obnovit PS v případě jeho selhání. Běžnou volbou pro odolnost proti chybám je periodické snímkování stavu modelu a obnova z nejnovějšího snímku při detekci selhání PS. Volba frekvence snímkování má dva hlavní dopady: (1) Kvalita modelu. Intuitivně, kvalita modelu trpí méně ztrátou nedávné historie s vyšší frekvencí snímkování. (2) Výpočetní režie. Snímkování multi-terabytového modelu není zdarma. Způsobuje velké kopie paměti a I/O disků. Jako kompromis mezi kvalitou modelu a výpočetní režií Monolith snímkuje všechny trénovací PS každý den. Ačkoli PS ztratí jeden den aktualizací v případě selhání, zjistili jsme, že zhoršení výkonu je tolerovatelné prostřednictvím našich experimentů. Efekt spolehlivosti PS analyzujeme v následující sekci. 3 HODNOCENÍ Pro lepší pochopení přínosů a kompromisů přinesených naším navrhovaným designem jsme provedli několik experimentů v produkčním měřítku a A/B testy s živým obslužným provozem k vyhodnocení a ověření Monolith z různých aspektů. Naším cílem je odpovědět na následující otázky prostřednictvím našich experimentů: (1) Jak moc můžeme těžit z nekolizní HashTable? (2) Jak důležité je realtime online trénování? (3) Je design synchronizace parametrů Monolith dostatečně robustní ve velkém produkčním scénáři? V této sekci nejprve představíme naše experimentální nastavení a poté podrobně probereme výsledky a naše zjištění. 3.1 Experimentální nastavení Jak je popsáno v sekci embeddingové tabulky v Monolith jsou implementovány jako nekolizní HashTables. Abychom prokázali nutnost vyhýbat se kolizím v embeddingových tabulkách a kvantifikovali zisky z naší nekolizní implementace, provedli jsme dvě skupiny experimentů na datasetu Movielens a na našem interním produkčním datasetu: 3.1.1 Embeddingová tabulka. 2.1, (1) Dataset ml-25m [ ]. Toto je standardní veřejný dataset pro hodnocení filmů, obsahující 25 milionů hodnocení, které zahrnují přibližně 162 000 uživatelů a 62 000 filmů. MovieLens 11 • . Původní štítky jsou hodnocení od Předzpracování štítků 0.5 do 5.0, zatímco v produkci naše úlohy většinou přijímají binární signály od uživatelů. Abychom lépe simulovali naše produkční modely, konvertujeme škálové štítky na binární štítky tím, že považujeme skóre ≥ 3.5 za pozitivní vzorky a zbytek za negativní vzorky. • Model a metriky. Implementovali jsme standardní model DeepFM [9], což je běžně používaná architektura modelu pro doporučovací problémy. Skládá se z FM komponenty a husté komponenty (Obrázek 6). Predikce jsou hodnoceny pomocí AUC [2], protože to je hlavní měřítko pro reálné modely. • Kolize embeddingů. Tento dataset obsahuje přibližně 160 tisíc ID uživatelů a 60 tisíc ID filmů. Pro srovnání s nekolizní verzí implementace embeddingové tabulky jsme provedli další skupinu experimentů, kde jsou ID předzpracována pomocí MD5 hashování a poté mapována na menší ID prostor. V důsledku toho budou některá ID sdílet svůj embedding s ostatními. Tabulka 1 ukazuje podrobné statistiky ID uživatelů a filmů před a po hashování. (2) . Interní doporučovací dataset Provedli jsme také experimenty na doporučovacím modelu v produkčním prostředí. Tento model obecně následuje vícevětvovou architekturu, přičemž každá větev je zodpovědná za učení se předpovídat specializovaný druh chování uživatele. Každý model má kolem 1000 embeddingových tabulek a distribuce velikosti embeddingových tabulek je velmi nerovnoměrná; Původní ID prostor embeddingové tabulky byl 248. V naší základní variantě jsme aplikovali hashovací trik rozkladem, abychom omezili velikost embeddingové tabulky. Konkrétněji, používáme dvě menší embeddingové tabulky namísto jedné obrovské k vygenerování jedinečného embeddingu pro každé ID pomocí vektorové kombinace: kde 𝐸𝑟 , 𝐸𝑞 jsou embeddingy odpovídající 𝐼𝐷𝑟 , 𝐼𝐷𝑞. Toto efektivně snižuje velikosti embeddingových tabulek z 248 na 225; • Tento model je obsluhován v reálné produkci a výkon tohoto experimentu je měřen online AUC s reálným obslužným provozem. Během online trénování aktualizujeme naše online obslužné PS nejnovější sadou parametrů s minutovými intervaly. Navrhli jsme dvě skupiny experimentů k ověření kvality modelu a robustnosti systému. 3.1.2 Online trénování. (1) . Abychom prozkoumali nutnost minutové frekvence aktualizací, provedli jsme experimenty, které synchronizují parametry z trénovacího modelu do predikčního modelu s různými intervaly. Frekvence aktualizací