Uvnitř ByteDance Monolith: Engin pohánějící chytřejší, rychlejší informační kanály obsahu

```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 zásadní pro mnoho podniků řízených včasnou 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 Ten-sorFlow nebo PyTorch tyto obecné frameworky z různých důvodů nedostačují obchodním požadavkům v doporučovacích scénářích: na jedné straně je ladění systémů založených na statických parametrech a hustých výpočtech pro doporučování s dynamickými a řídkými prvky škodlivé pro kvalitu modelu; na druhé straně jsou tyto frameworky navrženy s odstupem mezi fází dávkového tréninku a fází obsluhy, což brání modelu v interakci se zpětnou vazbou zákazníků v reálném čase. Tyto problémy nás přiměly znovu přezkoumat tradiční přístupy a prozkoumat radikálně odlišné návrhy. V tomto článku představujeme 1, systém přizpůsobený pro online trénink. Náš návrh byl řízen pozorováním našich aplikačních zátěží a produkčního prostředí, které odrážejí zřetelný odklon od ostatních doporučovacích systémů. Naše příspěvky jsou mnohostranné: za prvé, vytvořili jsme bezkolizní tabulku vnoření s optimalizacemi, jako jsou expirovatelné vnoření a filtrování frekvencí, ke snížení její paměťové náročnosti; za druhé, poskytujeme produkčně připravenou online tréninkovou architekturu s vysokou odolností proti chybám; konečně jsme dokázali, že spolehlivost systému lze vyměnit za učení v reálném čase. Monolith byl úspěšně nasazen do produktu BytePlus Recommend2. Monolith 1 ÚVOD Poslední desetiletí zaznamenalo rozmach podniků poháněných doporučovacími technikami. Ve snaze o lepší zákaznickou zkušenost je personalizovaný obsah pro každého jednotlivého uživatele jako reakce 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énink modelu, protože nejlépe zobrazují profil uživatele a předpovídají zájmy a budoucí chování uživatele. Deep learning 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 deep learningu 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 chování uživatelů. Tato data se drasticky liší od dat používaných v konvenčních deep learningových problémech, jako je modelování jazyka nebo počítačové vidění, ve dvou aspektech: 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í, tzv. 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čování většinou obsahují řídké kategorické příznaky, z nichž některé se vyskytují s nízkou frekvencí. Běžná praxe jejich mapování do vysoko-dimenzionálního prostoru vnoření by vedla 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 několik řádů větší. Taková obrovská tabulka vnoření by se sotva vešla do paměti jednoho hostitele; • Co je horší, očekává se, že velikost tabulky vnoření bude časem narůstat, jak bude přibývat více uživatelů a položek, zatímco frameworky jako [ , ] používají pro reprezentaci tabulky vnoření pevně dané husté proměnné. 1 17 V praxi mnoho systémů používá hashová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 opírá o nadměrně idealistický předpoklad, že ID v tabulce vnoření jsou rovnoměrně distribuována podle frekvence a kolize jsou pro kvalitu modelu neškodné. Bohužel to je pro reálný doporučovací systém zřídka pravda, kde malá skupina uživatelů nebo položek má výrazně více výskytů. S organickým růstem velikosti tabulky vnoření se zvyšuje šance na kolizi hashovacího klíče a vede k poškození kvality modelu 3 6 [3]. Proto je pro produkční doporučovací systémy přirozenou poptávkou mít kapacitu zachytit co nejvíce příznaků ve svých parametrech a také schopnost elasticky upravovat počet uživatelů a položek, které si evidují. 1.2 Nestacionární distribuce Vizuální a lingvistické vzory se vyvíjejí stěží v časovém měřítku staletí, zatímco stejný uživatel, který se zajímá o jedno téma, může během minuty změnit svůj zájem. V důsledku toho je základní distribuce uživatelských dat nestacionární, což je jev běžně označovaný jako Concept Drift [8]. Intuitivně lze říci, že informace z nedávné historie mohou účinněji přispět k předpovědi změny chování uživatele. Ke zmírnění účinku Concept Drift je třeba modely obsluhy aktualizovat na základě nové zpětné vazby od uživatele co nejblíže k reálnému času, aby odrážely nejnovější zájmy uživatele. Na základě těchto rozdílů a v návaznosti na problémy, které vznikají v naší produkci, jsme navrhli , velký doporučovací systém, který řeší tyto nedostatky. 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) Poskytnout plnou expresivní sílu pro řídké příznaky návrhem bezkolizní hashovací tabulky a mechanismu pro dynamické vyřazování příznaků; (2) Smyčku zpětné vazby z obsluhy do tréninku v reálném čase pomocí online tréninku. Díky těmto architektonickým schopnostem Monolith konzistentně překonává systémy, které používají hashovací triky s kolizemi s přibližně podobným využitím paměti, a dosahuje nejmodernějšího online AUC obsluhy, aniž by nadměrně zatěžoval výpočetní výkon našich serverů. Zbytek článku je organizován takto. Nejprve podrobně popíšeme návrhové detaily, jak Monolith řeší existující problémy pomocí bezkolizní hashovací tabulky a tréninku v reálném čase v sekci 2. Experimenty a výsledky budou prezentovány v sekci 3 spolu se závěry testovanými v produkci a některými diskuzemi o kompromisech mezi včasností, 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 nastavení distribuovaného Worker- arameter erveru TensorFlow (Obrázek V architektuře Worker-PS jsou stroje přiřazeny k různým rolím; pracovní 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 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 tabulky vnoření, které odpovídají řídkým příznakům. V našem návrhu jsou oba husté a ří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í TensorFlow, které vyplývá z oddělení tréninku a inference, je elasticky škálovatelný online trénink Monolith navržen tak, aby efektivně synchronizoval parametry z tréninkového PS do online obslužného PS v krátkých intervalech, přičemž robustnost modelu je zaručena mechanismem odolnosti proti chybám. 2.1 Hashovací tabulka Prvním principem v našem návrhu reprezentace řídkých parametrů je vyhnout se přecpávání informací z různých ID do stejného pevně daného vnoření. Simulace dynamické velikosti tabulky vnoření pomocí standardní proměnné TensorFlow nevyhnutelně vede ke kolizi ID, která se zhoršuje, jak přibývají nová ID a tabulka roste. Proto jsme namísto budování 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 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) č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 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 𝐴 do ℎ0 (𝐴); Pokud je ℎ0 (𝐴) obsazeno jiným prvkem 𝐵, 𝐵 se z 𝑇0 vyhodí a pokusí se vložit 𝐵 do 𝑇1 se stejnou logikou. Tento proces se opakuje, dokud se všechny prvky stabilizují, nebo dojde k pře-hashování, když vkládání narazí na cyklus. Snížení paměťové náročnosti je také důležitým hlediskem 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 objeví jen párkrát, mají omezený příspěvek ke zlepšení kvality modelu. Důležité pozorování je, že ID jsou distribuována dlouhým ocasem, kde populární ID se mohou vyskytnout milionkrát, zatímco nepopulární se vyskytnou maximálně desetkrát. Vnoření odpovídající těmto neobvyklým ID jsou podtrénovaná kvůli nedostatku tréninkových dat a model z nich nebude schopen provést dobrý odhad. Nakonec tato ID pravděpodobně neovlivní výsledek, takže kvalita modelu neutrpí odstraněním těchto ID s nízkými výskyty; (2) Zastaralá ID ze vzdálené 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í vnoření pro tato ID nemůže modelu nijak pomoci, kromě zbytečné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 příznaků pro paměťově efektivnější implementaci HashTable: (1) ID jsou filtrována předtím, než jsou přijata do tabulek vnoření. Máme dvě metody filtrování: nejprve filtrujeme podle jejich výskytů předtím, než jsou vložena jako klíče, kde práh výskytů je laditelný hyperparametr, který se liší pro každý model; navíc používáme pravděpodobnostní filtr, který pomáhá dále 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 strávila dlouhou dobu na cestě Dávkového Tréninku, zatímco Online Trénink uzavře smyčku okamžitěji.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID jsou časově označena a nastavena tak, aby vypršela po uplynutí předem definované doby neaktivity. Čas vypršení platnosti je také laditelný pro každou tabulku vnoření, aby bylo možné rozlišovat příznaky s různou citlivostí na historické informace. V naší implementaci je HashTable implementována jako zdrojová operace TensorFlow. Podobně jako 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á tréninková smyčka TensorFlow: V každém tréninkovém kroku tréninkový worker přečte jednu mini-dávku tréninkových příkladů z úložiště, vyžádá si parametry z PS, provede dopředný a zpětný průchod a nakonec odešle aktualizované parametry do tréninkového PS. Mírně odlišně od jiných běžných deep learning úloh trénujeme náš dataset pouze pro jeden průchod. Dávkový trénink je užitečný pro trénování historických dat, když upravujeme architekturu našeho modelu a přetrénováváme model; (2) Fáze online tréninku. Poté, co je model nasazen do online obsluhy, trénink nekončí, ale přechází do fáze online tréninku. Místo čtení mini-dávek příkladů z úložiště, tréninkový worker spotřebovává data v reálném čase za běhu a aktualizuje tréninkový PS. Tréninkový PS periodicky synchronizuje své parametry s obslužným PS, což se projeví na straně uživatele okamžitě. To umožňuje našemu modelu interaktivně se přizpůsobovat zpětné vazbě uživatele v reálném čase. Monolith je postaven s možností bezproblémového přepínání mezi dávkovým a online tréninkem. 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 logová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í úloha pro online spojování příznaků. Online spojovač spojuje příznaky se štítky z uživatelských akcí a vytváří tréninkové příklady, které jsou následně 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 přímo čte data z fronty Kafka; Pro dávkový trénink úloha pro shromažďování dat nejprve shromáždí data do HDFS [ ]; Poté, co se data v HDFS nashromáždí v určitém množství, tréninkový worker získá data z HDFS a provede dávkový trénink. 18 Aktualizované parametry v tréninkovém PS budou odeslány do obslužného PS podle plánu synchronizace parametrů. V reálných aplikacích se logy uživatelských akcí a příznaky streamují do online spojovače (Obrázek bez záruky časového pořadí. Proto používáme jedinečný klíč pro každý požadavek, aby bylo možné správně spárovat uživatelskou akci a příznaky. 2.2.2 Online Joiner. 5) Zpoždění uživatelské akce může být také problémem. Například uživatel může před nákupem položky, kterou mu bylo představeno před několika dny, trvat několik dní. To je pro spojovač výzva, protože pokud jsou všechny příznaky drženy v cache, jednoduše se nevejdou do paměti. V našem systému se pro ukládání příznaků, které čekají déle než určitou dobu, používá úložiště klíč-hodnota na disku. Když dorazí log uživatelské akce, nejprve se podívá do paměťové cache a poté, v případě chybějící cache, se podívá do úložiště klíč-hodnota. Dalším problémem, který vzniká v reálných aplikacích, je vysoce nerovnoměrná distribuce negativních a pozitivních příkladů, kde počet prvních může být o několik řádů vyšší než počet druhých. Aby se zabránilo přebití 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 posunulo ho směrem k vyšší pravděpodobnosti pozitivních předpovědí. Jako nápravu používáme korekci log-odds [ ] během obsluhy, abychom zajistili, že online model je nezaujatý odhad původní distribuce. 19 Během online tréninku tréninkový cluster Monolith nepřetržitě přijímá data z online obslužného modulu a aktualizuje parametry na tréninkovém PS. Klíčovým krokem k tomu, aby mohl online obslužný PS 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 obslužném PS nesmí během aktualizace přestat obsluhovat. Naše modely v produkci mají obvykle několik terabajtů, a proto nahrazení všech parametrů chvíli trvá. Bylo by nepřijatelné zastavit online PS od obsluhy modelu během procesu nahrazování 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 obslužného PS by představoval obrovský tlak na síťovou šířku pásma i paměť na PS, protože by vyžadoval dvojnásobnou velikost paměti modelu pro přijetí nově příchozího modelu. Aby online trénink mohl škálovat na velikost naší obchodní scénáře, navrhli jsme v Monolithu inkrementální mechanismus periodické synchronizace parametrů za běhu, založený na několika znatelných charakteristikách našich modelů: (1) Řídké parametry dominují velikosti doporučovacích modelů; (2) Při krátkém časovém okně je pouze malá podmnožina ID trénována a jejich vnoření aktualizována; (3) Husté proměnné se pohybují mnohem pomaleji než řídká vnoření. Je to proto, že v optimalizátorech založených na momentu se akumulace momentu pro husté proměnné zesiluje obrovským množstvím tréninkových dat pro doporučení, zatímco v jedné datové dávce je aktualizováno pouze několik řídkých vnoření. (1) a (2) nám umožňují využít řídké aktualizace napříč všemi ID příznaků. V Monolithu udržujeme hashovou sadu dotčených klíčů, reprezentující ID, jejichž vnoření byla trénována 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 obslužného PS. Tato relativně malá sada inkrementálních aktualizací parametrů je nenáročná na přenos sítě a nezpůsobí ostré zvýšení paměti během synchronizace. Využíváme také (3) ke 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 nám může přinést situaci, kdy husté parametry, které obsluhujeme, jsou relativně zastaralá verze 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 s možností 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čtu. Snímkování multi-terabajtového modelu není zdarma. Vyžaduje velké množství kopírování paměti a I/O disku. Jako kompromis mezi kvalitou modelu a režií výpočtu Monolith každý den snímkuje všechny tréninkové PS. Ačkoli PS ztratí jeden den aktualizací v případě selhání, zjistili jsme, že snížení výkonu je v rámci našich experimentů snesitelné. Efekt spolehlivosti PS analyzujeme v následující sekci. 3 HODNOCENÍ Pro lepší pochopení výhod a kompromisů, které přináší náš navrhovaný design, jsme provedli několik experimentů v produkčním měřítku a A/B testy se živým obslužným provozem, abychom Monolith zhodnotili a ověřili z různých aspektů. Našími experimenty chceme odpovědět na následující otázky: (1) Jak moc můžeme profitovat z bezkolizní HashTable? (2) Jak důležitý je real-time online trénink? (3) Je návrh synchronizace parametrů Monolithu 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 tabulky vnoření v Monolithu jsou implementovány jako bezkolizní HashTables. Abychom dokázali nutnost vyhýbání se kolizím v tabulkách vnoření a kvantifikovali zisky 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 Tabulka vnoření. 2.1, (1) ml-25m dataset [ ]. Toto je standardní veřejný dataset pro hodnocení filmů, obsahující 25 milionů hodnocení, které zahrnuje 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 úkoly spočívají převážně v přijímání binárních signálů od uživatelů. Abychom lépe simulovali naše produkční modely, převádíme š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], běžně používaný model pro doporučovací problémy. Skládá se z komponenty FM a husté komponenty (Obrázek 6). Predikce jsou hodnoceny pomocí AUC [2], protože to je hlavní metrika pro reálné modely. • Kolize vnoření. Tento dataset obsahuje přibližně 160 tisíc ID uživatelů a 60 tisíc ID filmů. Pro srovnání s bezkolizní verzí implementace tabulky vnoření jsme provedli další skupinu experimentů, kde ID jsou 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é vnoření 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 multi-tower architekturu, kde každý tower je zodpovědný za učení se předpovídat specifický druh uživatelského chování. Každý model má kolem 1000 tabulek vnoření a distribuce velikosti tabulek vnoření je velmi nerovnoměrná; Původní ID prostor tabulky vnoření byl 248. V naší základní linii jsme použili hashovací trik rozkladem k omezení velikosti tabulky vnoření. Konkrétněji, používáme dvě menší tabulky vnoření místo jedné obrovské k vygenerování jedinečného vnoření pro každé ID pomocí vektorové kombinace: kde 𝐸𝑟 , 𝐸𝑞 jsou vnoření odpovídající 𝐼𝐷𝑟 , 𝐼𝐷𝑞. To efektivně snižuje velikosti tabulek vnoření 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éninku 3.1.2 Online trénink.