Uvnitř monolitů ByteDance: Motory 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∗, Univerzita Fudan 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 zpětnou vazbou zákazníků v reálném čase, jako je hodnocení krátkých videí nebo online reklamy. Navzdory všudypřítomnému přijetí produkčních frameworků pro hluboké učení, jako je TensorFlow nebo PyTorch, tyto obecné frameworky z různých důvodů nedokážou uspokojit obchodní požadavky v doporučovacích scénářích: na jedné straně je ladění systémů založené na statických parametrech a hustých výpočtech pro doporučení s dynamickými a řídkými příznaky škodlivé pro kvalitu modelu; na druhé straně jsou tyto frameworky navrženy s oddělenými fázemi dávkového tréninku a obsluhy, což brání modelu v interakci se zpětnou vazbou zákazníka 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ávrhů. V tomto článku představujeme 1, systém přizpůsobený pro online trénink. 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 jiných doporučovacích systémů. Naše příspěvky jsou mnohostranné: zaprvé jsme vytvořili kolizní embeddingovou tabulku s optimalizacemi, jako jsou vypršitelné embeddingy a filtrování frekvencí, abychom snížili její paměťovou stopu; za druhé poskytujeme produkčně připravenou architekturu online tréninku s vysokou odolností proti chybám; konečně jsme prokázali, že spolehlivost systému může být vyměněna za učení v reálném čase. Monolith byl úspěšně integrován do produktu BytePlus Recommend2. Monolith 1 ÚVOD Poslední desetiletí bylo svědkem boomu podnikání poháněného doporučovacími technikami. Ve snaze o lepší zákaznickou zkušenost je běžným cílem těchto obchodních aplikací poskytování personalizovaného obsahu pro každého jednotlivého uživatele jako reakce v reálném čase. K tomuto účelu se informace z poslední interakce uživatele často používají jako primární vstup pro trénink modelu, protože nejlépe zobrazí profil uživatele a předpoví jeho zájmy a budoucí chování. Hluboké učení dominuje doporučovacím modelům [ , , , , , ], protože obrovské množství uživatelských dat je přirozeně vhodné pro masivně daty řízené neuronové modely. Úsilí o využití síly hlubokého učení v průmyslových doporučovacích systémech 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 uživatelského chování. Tato data se ve dvou aspektech dramaticky liší od dat používaných v konvenčních úlohách hlubokého učení, jako je jazykové modelování nebo počítačové vidění: 5 6 10 12 20 21 (1) Příznaky jsou většinou řídké, kategorické a dynamicky se měnící; (2) Základní distribuce tréninkových dat je nestacionární, tj. 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 dynamika Data pro doporučení většinou obsahují řídké kategorické příznaky, z nichž některé se vyskytují s nízkou frekvencí. Běžná praxe mapování na vysokorozměrný embeddingový prostor vede k řadě problémů: • Na rozdíl od jazykových modelů, kde je počet slovních částí omezený, počet uživatelů a hodnocených položek je o řády větší. Taková obrovská embeddingová tabulka by se těžko vešla do paměti jednoho hostitele; • Co je horší, velikost embeddingové tabulky se očekává, že poroste v průběhu času, jakmile bude přijato 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á nízko-kolizní hashování [ , ] jako způsob, jak snížit paměťovou stopu a umožnit růst ID. To se spoléhá na příliš idealistický předpoklad, že ID v embeddingové tabulce jsou rovnoměrně distribuována ve frekvenci a kolize jsou neškodné pro kvalitu modelu. Bohužel to je ve skutečnosti zřídka pravda pro reálný doporučovací systém, kde malá skupina uživatelů nebo položek má výrazně více výskytů. 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 pro produkční doporučovací systémy přirozeným požadavkem mít schopnost zachytit co nejvíce příznaků ve svých parametrech a také mít schopnost elasticky upravovat počet uživatelů a položek, které se snaží sledovat. 1.2 Nestacionární distribuce Vizuální a lingvistické vzorce se sotva vyvíjejí v časovém měřítku staletí, zatímco uživatel, který se zajímá o jedno téma, může svůj zápal změnit v následující minutě. 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 predikci změny v chování uživatele. K zmírnění účinku Concept Drift je třeba modely obsluhy aktualizovat z nových zpětných vazeb uživatelů co nejblíže v reálném čase, aby odrážely nejnovější zájem uživatele. Vzhledem k těmto rozdílům a pozorování problémů, které vznikají v naší produkci, jsme navrhli , rozsáhlý doporučovací systém, který řeší tyto problémy. 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é příznaky návrhem bezkolizní hashovací tabulky a mechanismu pro dynamické vyřazování příznaků; (2) Zpětně smyčkovat zpětnou vazbu obsluhy do tréninku v reálném čase s online tréninkem. Díky těmto architektonickým schopnostem 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 nejmodernějšího online obsluhovacího AUC, aniž by nadměrně zatěžoval výpočetní výkon našich serverů. Zbytek článku je organizován následovně. Nejprve podrobně popíšeme návrhové detaily, jak Monolith řeší stávající výzvy pomocí bezkolizní hashovací tabulky a real-time tréninku v sekci 2. Experimenty a výsledky budou prezentovány v sekci 3, spolu s produkčně otestovaný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 Monolith. Sekce 5 uzavírá tuto práci. 2 NÁVRH Celková architektura Monolith obecně následuje nastavení distribuovaného Worker- arameter erver společnosti TensorFlow (Obrázek V architektuře Worker-PS jsou servery přiřazeny k různým rolím; pracovní stroje (Worker) 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 pracovníky. P S 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 příznakům. V našem návrhu jsou oba, husté i řídké parametry, součástí grafu TensorFlow a jsou uloženy na serverech parametrů. Podobně jako proměnná TensorFlow pro husté parametry jsme navrhli sadu vysoce efektivních, bezkolizních a flexibilních operací HashTable pro řídké parametry. Jako doplněk k omezením TensorFlow vyplývajícím z oddělení tréninku a inference je online trénink Monolith s elastickou škálovatelností navržen pro efektivní synchronizaci parametrů z tréninkového PS do online obsluhovacího PS v krátkých intervalech, s mechanismem pro zajištění odolnosti modelu proti chybám. 2.1 Hashovací tabulka Prvním principem v našem návrhu reprezentace řídkých parametrů je vyhnout se zmačkání informací z různých ID do stejného embeddingu pevné velikosti. Simulace dynamicky veliké embeddingové tabulky pomocí standardní proměnné TensorFlow nevyhnutelně vede ke kolizi ID, která se zhoršuje, jak přicházejí nová ID a tabulka roste. Proto jsme místo toho, abychom stavěli na proměnné, 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 kolize s existujícími. Cuckoo Hashing dosahuje v nejhorším případě časové složitosti 𝑂 (1) pro vyhledávání a mazání a očekávané amortizované 𝑂 (1) časové složitosti pro vkládání. Jak je znázorněno na obrázku , udržuje dvě tabulky 𝑇0, 𝑇1 s různými hašovací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 𝐵, pak 𝐵 z 𝑇0 vypudí a pokusí se vložit 𝐵 do 𝑇1 se stejnou logikou. Tento proces se bude opakovat, dokud se všechny prvky nestabilizují, nebo dojde k přehašování, když vkládání narazí na cyklus. Snížení paměťové stopy je také důležitým faktorem v našem návrhu. Naivní přístup k vložení každého nového ID do HashTable rychle vyčerpá paměť. Pozorování reálných produkčních modelů vede ke dvěma závěrům: (1) ID, která se vyskytují pouze několikrát, mají omezený příspěvek ke zlepšení kvality modelu. Důležité pozorování je, že ID jsou distribuována po dlouhém ocasu, kde populární ID se mohou vyskytovat milionkrát, zatímco nepopulární se vyskytují ne více než desetkrát. Embeddingy odpovídající těmto méně častým ID jsou nedostatečně trénované kvůli nedostatku tréninkových dat a model nebude schopen na jejich základě učinit dobrý odhad. Nakonec tato ID pravděpodobně neovlivní výsledek, takže kvalita modelu nebude trpět odstraněním ID s nízkými výskyty; (2) Zastaralá ID z daleké historie zřídka přispívají k aktuálnímu modelu, protože mnohá z nich nejsou nikdy navštívena. To může být způsobeno neaktivním uživatelem nebo krátkým videem, které je zastaralé. Ukládání embeddingů pro tato ID nemůže modelu nijak pomoci, kromě marného vyprazdňování naší PS paměti. Na základě těchto pozorování jsme navrhli několik heuristik pro filtrování ID příznaků pro paměťově efektivnější implementaci HashTable: (1) ID jsou filtrovány před 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 pro každý model liší; navíc používáme pravděpodobnostní filtr, který dále pomáhá snižovat využití paměti; ![#Obrázek 4: Streaming Engine. Informační zpětnovazební smyčka [Uživatel → Model Server → Tréninkový Worker → Model Server → Uživatel] by trvala dlouho při dávkovém tréninku, zatímco online trénink by smyčku uzavřel okamžitěji.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID jsou časována a nastavena tak, aby vypršela po neaktivitě po předem definovanou dobu. Doba vypršení platnosti je také laditelná pro každou embeddingovou tabulku, aby bylo možné rozlišovat příznaky s různou citlivostí na historické informace. V naší implementaci je HashTable implementována jako operace prostředku TensorFlow. Podobně jako u proměnné jsou vyhledávání a aktualizace také implementovány jako nativní operace TensorFlow pro snadnější integraci a lepší kompatibilitu. 2.2 Online trénink V Monolithu je trénink rozdělen do dvou fází (Obrázek 1): (1) Fáze dávkového tréninku. Tato fáze funguje jako běžná smyčka tréninku TensorFlow: V každém tréninkovém kroku tréninkový worker načte jednu mini-dávku tréninkových příkladů z úložiště, požádá o parametry z PS, provede dopředný a zpětný průchod a nakonec odešle aktualizované parametry do tréninkového PS. Mírně se liší od jiných běžných úloh hlubokého učení, náš dataset trénujeme pouze jedním průchodem. Dávkový trénink je užitečný pro trénink historických dat, když upravujeme architekturu modelu a model znovu trénujeme; (2) Fáze online tréninku. Po nasazení modelu do online obsluhy trénink nekončí, ale vstupuje do fáze online tréninku. Namísto čtení mini-dávkových příkladů z úložiště, tréninkový worker zpracovává data v reálném čase a aktualizuje tréninkový PS. Tréninkový PS periodicky synchronizuje své parametry s obsluhovacím PS, což se projeví okamžitě 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éninkem. To je umožněno naším návrhem streamingového enginu, jak ilustruje obrázek 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 lajkování položky atd.) a druhou frontu Kafka pro příznaky. Jádrem enginu je Flink [ ] streamovací job pro online spojovač příznaků (Online Feature Joiner). Online spojovač spojuje příznaky se štítky z uživatelských akcí a vytváří tréninkové příklady, které jsou poté zapsány do fronty Kafka. Fronta pro tréninkové příklady je spotřebovávána jak online tréninkem, tak dávkovým tréninkem: 13 4 Pro online trénink tréninkový worker čte data přímo z fronty Kafka; Pro dávkový trénink datový dumping job nejprve nahraje data do HDFS [ ]; Poté, co se data v HDFS nahromadí v určitém množství, tréninkový worker načte data z HDFS a provede dávkový trénink. 18 Aktualizované parametry v tréninkovém PS jsou odesílány do obsluhovacího PS podle plánu synchronizace parametrů. V reálných aplikacích jsou záznamy uživatelských akcí a příznaky streamovány do online joineru (Obrázek bez záruky pořadí. Proto používáme unikátní klíč pro každý požadavek, aby se uživatelská akce a příznaky mohly správně spárovat. 2.2.2 Online Joiner. 5) Zpoždění uživatelské akce může být také problém. Například uživatel může trvat několik dní, než se rozhodne koupit položku, která mu byla představena před několika dny. To je výzva pro joiner, protože pokud by všechny příznaky 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í příznaků, které čekají po určitou dobu. Když dorazí záznam uživatelské akce, nejprve vyhledá v paměťové cache a poté vyhledá key-value úložiště v případě chybějící cache. Dalším problémem, který vzniká v reálných aplikacích, je, že distribuce negativních a pozitivních příkladů je velmi 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 tomu, aby pozitivní příklady byly přehlceni negativními, běžnou strategií je negativní vzorkování. To by jistě změnilo základní distribuci trénovaného modelu, upravilo by ho směrem k vyšší pravděpodobnosti pozitivních predikcí. Jako nápravu aplikujeme korekci log-odds [ ] během obsluhy, abychom zajistili, že online model je nestranný odhad původní distribuce. 19 Během online tréninku tréninkový cluster Monolith nepřetržitě přijímá data z modulu pro online obsluhu a aktualizuje parametry na tréninkovém PS. Klíčovým krokem k tomu, aby online obsluhovací PS mohl 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 výzvami: 2.2.3 Synchronizace parametrů. Modely na online obsluhovacím PS se nesmí zastavit během aktualizace. Naše modely v produkci mají obvykle několik terabajtů a v důsledku toho výměna všech parametrů trvá nějakou dobu. Bylo by nepřijatelné zastavit online PS během procesu výměny a aktualizace musí být prováděny za běhu; Přenos celého multi-terabajtového modelu z tréninkového PS do online obsluhovacího PS by představoval obrovský tlak na šířku pásma sítě i paměť na PS, protože vyžaduje dvojnásobnou velikost paměti pro přijetí nově příchozího modelu. Aby se online trénink mohl škálovat na velikost našeho obchodního scénáře, navrhli jsme inkrementální mechanismus pro periodickou synchronizaci parametrů za běhu v Monolithu založený na několika pozoruhodných charakteristikách našich modelů: (1) Řídké parametry dominují velikosti doporučovacích modelů; (2) V daném krátkém časovém okně je trénována pouze malá podmnožina ID a jejich embeddingy aktualizovány; (3) Husté proměnné se pohybují mnohem pomaleji než řídké embeddingy. To je proto, že v optimalizátorech založených na hybnosti je akumulace hybnosti pro husté proměnné zvětšena obrovskou velikostí tréninkových dat doporučení, zatímco pouze několik řídkých embeddingů obdrží aktualizace v jedné datové dávce. (1) a (2) nám umožňují využít řídké aktualizace napříč všemi ID příznaků. V Monolithu udržujeme hash set dotčených klíčů, reprezentujících ID, jejichž embeddingy byly trénovány od poslední synchronizace parametrů. Odesíláme podmnožinu řídkých parametrů, jejichž klíče jsou v sadě dotčených klíčů, s minutovým časovým intervalem z tréninkového PS do online obsluhovacího PS. Toto relativně malý balík inkrementální aktualizace parametrů je nenáročný na přenos sítě a nezpůsobí ostrý 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 plánu synchronizace pro řídké parametry, zatímco husté parametry aktualizujeme méně často. To by nás mohlo dostat do situace, kdy obsluhované husté parametry jsou relativně zastaralá verze ve srovnání s řídkou částí. Tato nekonzistence je však tolerovatelná 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 méně trpí ztrátou nedávné historie se zvýšenou frekvencí snímkování. (2) Režie výpočtů. Snímkování multi-terabajtového modelu není zdarma. Způsobuje velké kopírování paměti a I/O disku. Jako kompromis mezi kvalitou modelu a režií výpočtů Monolith snímkuje všechny tréninkové PS každý den. Ačkoli PS ztratí jeden den aktualizací v případě selhání, zjistili jsme, že snížení výkonu je snesitelné prostřednictvím našich experimentů. Efekt spolehlivosti PS analyzujeme v další 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 obsluhovacím provozem k hodnocení a ověření Monolith z různých aspektů. Naším cílem je odpovědět na následující otázky pomocí našich experimentů: (1) Jak moc můžeme profitovat z bezkolizní HashTable? (2) Jak důležitý je realtime online trénink? (3) Je návrh synchronizace parametrů Monolith dostatečně robustní v rozsáhlém produkčním scénáři? V této sekci nejprve představíme naše experimentální nastavení a poté podrobně prodiskutujeme výsledky a naše zjištění. 3.1 Experimentální nastavení Jak je popsáno v sekci embeddingové tabulky v Monolithu jsou implementovány jako bezkolizní HashTables. Abychom dokázali nutnost vyhýbat se kolizím v embeddingových tabulkách a kvantifikovali zisk z naší bezkolizní implementace, provedli jsme dvě skupiny experimentů na datasetu Movielens a na našem interním produkčním datasetu: 3.1.1 Embedding Table. 2.1, (1) ml-25m dataset [ ]. Jedná se o standardní veřejný dataset pro hodnocení filmů, obsahující 25 milionů hodnocení 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, převádíme stupňovitá hodnocení na binární tím, že skóre ≥ 3,5 považujeme za pozitivní příklady a zbytek za negativní. • Model a metriky. Implementovali jsme standardní model DeepFM [9], běžně používaný architektonický model 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ů. Abychom mohli porovnat s bezkolizní verzí implementace embeddingové tabulky, provedli jsme další skupinu experimentů, kde jsou ID předzpracována pomocí MD5 hashování a poté mapována na menší ID prostor. Výsledkem je, že některá ID budou 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 s doporučovacím modelem v produkčním prostředí. Tento model obecně následuje vícevěžovou architekturu, přičemž každá věž je zodpovědná za učení predikce specializovaného druhu 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í linii jsme použili hashing trick rozkladem, abychom omezili velikost embeddingové tabulky. Konkrétněji, používáme dvě menší embeddingové tabulky namísto jedné gigantické k vygenerování unikátního embeddingu pro každé ID pomocí vektorové kombinace: kde 𝐸𝑟 , 𝐸𝑞 jsou embeddingy odpovídající 𝐼𝐷𝑟 , 𝐼𝐷𝑞. To 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 obsluhovacím provozem. Během online tréninku aktualizujeme náš online obsluhovací 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énink.