Inden for ByteDance's Monolith: Motoren, der driver smartere, hurtigere indholdsfeeds

Forfattere: 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 Opbygning af et skalerbart og realtids anbefalingssystem er afgørende for mange virksomheder, der er drevet af tidssensitiv kundefeedback, såsom rangering af korte videoer eller online annoncer. På trods af den allestedsnærværende adoption af produktionsskala deep learning frameworks som TensorFlow eller PyTorch, lever disse generelle frameworks ikke op til forretningsmæssige krav i anbefalingsscenarier af forskellige årsager: på den ene side er tilpasning af systemer baseret på statiske parametre og tætte beregninger til anbefaling med dynamiske og sparsomme træk skadeligt for modellens kvalitet; på den anden side er sådanne frameworks designet med en fuldstændig adskillelse af batch-træningstrinnet og serveringstrinnet, hvilket forhindrer modellen i at interagere med kundefeedback i realtid. Disse problemer fik os til at genoverveje traditionelle metoder og udforske radikalt anderledes designvalg. I dette papir præsenterer vi 1, et system skræddersyet til onlinetræning. Vores design er drevet af observationer af vores applikationsarbejdsbelastninger og produktionsmiljø, der afspejler en markant afvigelse fra andre anbefalingssystemer. Vores bidrag er mangfoldige: for det første har vi skabt en kollisionsfri indlejringstabel med optimeringer såsom udløbende indlejringer og frekvensfiltrering for at reducere dens hukommelsesfodaftryk; for det andet leverer vi en produktionsklar onlinetræningsarkitektur med høj fejltolerance; endelig har vi bevist, at systemets pålidelighed kan handles for realtid læring. Monolith er med succes implementeret i BytePlus Recommend2-produktet. Monolith 1 INTRODUKTION Det seneste årti har vidnet om en boom i virksomheder drevet af anbefalingsteknikker. For at opnå en bedre kundeoplevelse er levering af personligt indhold til hver enkelt bruger som en reaktion i realtid et fælles mål for disse forretningsapplikationer. Til dette formål bruges information fra en brugers seneste interaktion ofte som den primære input til træning af en model, da den bedst afspejler en brugers profil og forudsiger brugerens interesse og fremtidige adfærd. Deep learning har domineret anbefalingsmodeller [ , , , , , ], da den gigantiske mængde brugerdata passer naturligt til massivt datadrevne neurale modeller. Anstrengelser for at udnytte deep learnings kraft i anbefalingssystemer på industriniveau støder dog konstant på problemer, der opstår fra de unikke karakteristika ved data afledt af reel brugeradfærd. Disse data adskiller sig drastisk fra dem, der bruges i konventionelle deep learning-problemer som sprogmodellering eller computer vision på to måder: 5 6 10 12 20 21 (1) Trækkene er for det meste sparsomme, kategoriske og dynamisk skiftende; (2) Den underliggende distribution af træningsdata er ikke-stationær, a.k.a. Concept Drift . Sådanne forskelle har udgjort unikke udfordringer for forskere og ingeniører, der arbejder med anbefalingssystemer. 1.1 Sparsomhed og dynamik Data til anbefaling indeholder for det meste sparsomme kategoriske træk, hvoraf nogle forekommer med lav frekvens. Den almindelige praksis med at mappe dem til et højdimensionelt indlejringsrum ville give anledning til en række problemer: • I modsætning til sprogmodeller, hvor antallet af ordstykker er begrænset, er antallet af brugere og rangeringsartikler mange størrelsesordener større. En sådan enorm indlejringstabel ville knap nok kunne passe ind i hukommelsen på en enkelt vært; • Endnu værre, størrelsen af indlejringstabellen forventes at vokse over tid, efterhånden som flere brugere og artikler tilføjes, mens frameworks som [ , ] bruger en fast størrelse tætte variable til at repræsentere indlejringstabellen. 1 17 I praksis anvender mange systemer lav-kollisions-hashing [ , ] som en måde at reducere hukommelsesfodaftrykket på og tillade ID-vækst. Dette er baseret på en overdreven idealistisk antagelse om, at ID'er i indlejringstabellen er jævnt fordelt i frekvens, og kollisioner er uskadelige for modellens kvalitet. Desværre er dette sjældent sandt for et anbefalingssystem i den virkelige verden, hvor en lille gruppe af brugere eller artikler har betydeligt flere forekomster. Med den organiske vækst af indlejringstabellens størrelse øges chancerne for hash-nøglekollision og fører til forringelse af modellens kvalitet 3 6 . Derfor er det et naturligt krav for anbefalingssystemer på produktionsskala at have kapaciteten til at indfange så mange træk som muligt i deres parametre og også have evnen til elastisk at justere antallet af brugere og artikler, de forsøger at bogføre. 1.2 Ikke-stationær distribution Visuelle og sproglige mønstre udvikler sig knap nok i en tidsskala på århundreder, mens den samme bruger, der er interesseret i et emne, kan skifte sin begejstring hvert øjeblik. Som et resultat er den underliggende distribution af brugerdata ikke-stationær, et fænomen, der almindeligvis refereres til som Concept Drift . Intuitivt kan information fra en mere nylig historie bidrage mere effektivt til at forudsige ændringen i en brugers adfærd. For at mindske effekten af Concept Drift skal serveringsmodeller opdateres fra ny kundefeedback så tæt på realtid som muligt for at afspejle en brugers seneste interesse. I lyset af disse forskelle og observationer af problemer, der opstår fra vores produktion, har vi designet , et storskala anbefalingssystem til at adressere disse smertepunkter. Vi har udført omfattende eksperimenter for at verificere og iterere vores design i produktionsmiljøet. Monolith er i stand til at Monolith (1) Give fuld udtrykskraft til sparsomme træk ved at designe en kollisionsfri hashtabel og en dynamisk træk-evikteringsmekanisme; (2) Loop serveringsfeedback tilbage til træning i realtid med onlinetræning. Styrket af disse arkitektoniske kapaciteter overgår Monolith konsekvent systemer, der anvender hash-tricks med kollisioner med omtrentlig samme hukommelsesbrug, og opnår state-of-the-art online servering AUC uden at overbelaste vores serveres beregningskraft. Resten af papiret er organiseret som følger. Vi beskriver først designdetaljer for, hvordan Monolith tackler eksisterende udfordringer med kollisionsfri hashtabel og realtidstræning i sektion 2. Eksperimenter og resultater vil blive præsenteret i sektion 3, sammen med produktionsafprøvede konklusioner og en diskussion af kompromiser mellem tidsfølsomhed, pålidelighed og modelkvalitet. Sektion 4 opsummerer relateret arbejde og sammenligner dem med Monolith. Sektion 5 konkluderer dette arbejde. 2 DESIGN I en Worker-PS-arkitektur tildeles maskiner forskellige roller; Worker-maskiner er ansvarlige for at udføre beregninger som defineret af grafen, og PS-maskiner gemmer parametre og opdaterer dem i henhold til gradienter beregnet af Workers. Monoliths overordnede arkitektur følger generelt TensorFlows distribuerede Worker- arameter erver-opsætning (Figur P S 2). I anbefalingsmodeller kategoriseres parametre i to sæt: tætte og sparsomme. Tætte parametre er vægte/variable i et dybt neuralt netværk, og sparsomme parametre refererer til indlejringstabeller, der svarer til sparsomme træk. I vores design er både tætte og sparsomme parametre en del af TensorFlow Graph og gemmes på parameter servere. Ligesom TensorFlows Variable for tætte parametre har vi designet et sæt højeffektive, kollisionsfri og fleksible HashTable-operationer til sparsomme parametre. Som et supplement til TensorFlows begrænsning, der opstår fra adskillelsen af træning og inferens, er Monoliths elastisk skalerbare onlinetræning designet til effektivt at synkronisere parametre fra trænings-PS til online serverings-PS inden for korte intervaller, med modelrobusthedsgaranti leveret af fejltolerancemekanismen. 2.1 Hash Table Et førsteprincipp i vores design af sparsom parameterrepræsentation er at undgå at klemme information fra forskellige ID'er ind i den samme indlejring af fast størrelse. Simulering af en indlejringstabel med dynamisk størrelse med en standard TensorFlow Variable fører uundgåeligt til ID-kollision, som forværres, når nye ID'er ankommer, og tabellen vokser. Derfor har vi, i stedet for at bygge oven på Variable, udviklet en ny nøgle-værdi HashTable til vores sparsomme parametre. Vores HashTable udnytter Cuckoo Hashmap [ ] internt, hvilket understøtter indsættelse af nye nøgler uden at kollidere med eksisterende. Cuckoo Hashing opnår worst-case 𝑂 (1) tidskompleksitet for opslag og sletninger, og en forventet amortiseret 𝑂 (1) tid for indsættelser. Som illustreret i Figur opretholder den to tabeller 𝑇0, 𝑇1 med forskellige hashfunktioner ℎ0 (𝑥), ℎ1 (𝑥), og et element vil blive gemt i en af dem. Når man forsøger at indsætte et element 16 3 𝐴 i 𝑇0, forsøger den først at placere 𝐴 ved ℎ0 (𝐴); Hvis ℎ0 (𝐴) er optaget af et andet element 𝐵, vil den evakuere 𝐵 fra 𝑇0 og forsøge at indsætte 𝐵 i 𝑇1 med samme logik. Denne proces vil blive gentaget, indtil alle elementer stabiliserer sig, eller en rehash finder sted, når indsættelsen løber ind i en cyklus. Reduktion af hukommelsesfodaftrykket er også en vigtig overvejelse i vores design. En naiv tilgang til at indsætte hvert nyt ID i HashTable vil hurtigt tømme hukommelsen. Observation af reelle produktionsmodeller fører til to konklusioner: (1) ID'er, der kun forekommer et par gange, har begrænset bidrag til at forbedre modellens kvalitet. En vigtig observation er, at ID'er er langhalefordelte, hvor populære ID'er kan forekomme millioner af gange, mens de upopulære kun forekommer højst ti gange. Indlejringer, der svarer til disse sjældne ID'er, er underfit på grund af mangel på træningsdata, og modellen vil ikke kunne foretage en god estimering baseret på dem. I sidste ende er det usandsynligt, at disse ID'er vil påvirke resultatet, så modelkvaliteten vil ikke lide under fjernelse af disse ID'er med lav forekomst; (2) Forældede ID'er fra en fjern fortid bidrager sjældent til den aktuelle model, da mange af dem aldrig besøges. Dette kan muligvis skyldes en bruger, der ikke længere er aktiv, eller en kort video, der er forældet. Opbevaring af indlejringer for disse ID'er kan ikke hjælpe modellen på nogen måde, udover at dræne vores PS-hukommelse forgæves. Baseret på disse observationer har vi designet flere heuristikker til filtrering af ID'er for en mere hukommelseseffektiv implementering af HashTable: (1) ID'er filtreres, før de optages i indlejringstabellerne. Vi har to filtreringsmetoder: Først filtrerer vi efter deres forekomster, før de indsættes som nøgler, hvor grænseværdien for forekomster er en justerbar hyperparameter, der varierer for hver model; Derudover anvender vi et sandsynlighedsbaseret filter, der hjælper med yderligere at reducere hukommelsesforbruget; ![#Figur 4: Streaming Engine. Informationsfeedback-sløjfen fra [Bruger → Model Server → Træningsarbejder → Model Server → Bruger] ville tage lang tid på Batch Træningsstien, mens Onlinetræning lukker sløjfen mere øjeblikkeligt.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID'er tidsstemples og sættes til at udløbe efter at have været inaktive i en foruddefineret periode. Udløbstiden kan også justeres for hver indlejringstabel for at tillade skelnen af træk med forskellig følsomhed over for historisk information. I vores implementering er HashTable implementeret som en TensorFlow-ressourceoperation. Ligesom Variable er opslag og opdateringer også implementeret som native TensorFlow-operationer for nemmere integration og bedre kompatibilitet. 2.2 Onlinetræning I Monolith er træning opdelt i to trin (Figur 1): (1) Batch træningstrin. Dette trin fungerer som en almindelig TensorFlow træningsløkke: I hvert træningstrin læser en træningsarbejder en mini-batch af træningseksempler fra lageret, anmoder om parametre fra PS, beregner en fremadgående og en bagudgående passage og sender endelig opdaterede parametre til trænings-PS. Lidt anderledes end andre almindelige deep learning-opgaver, træner vi kun vores datasæt i én passage. Batch træning er nyttig til træning af historiske data, når vi ændrer vores modelarkitektur og gen-træner modellen; (2) Online træningstrin. Efter at en model er implementeret til online servering, stopper træningen ikke, men går ind i online træningstrinnet. I stedet for at læse mini-batch eksempler fra lageret, forbruger en træningsarbejder realtidsdata on-the-fly og opdaterer trænings-PS. Trænings-PS synkroniserer periodisk sine parametre til serverings-PS, hvilket træder i kraft for brugeren med det samme. Dette gør det muligt for vores model at tilpasse sig interaktivt i henhold til en brugers feedback i realtid. Monolith er bygget med evnen til problemfrit at skifte mellem batchtræning og onlinetræning. Dette muliggøres af vores design af streaming engine, som illustreret i Figur 2.2.1 Streaming Engine. 4. I vores design bruger vi en Kafka [ ] kø til at logge brugeres handlinger (f.eks. Klik på en vare eller Liker en vare osv.) og en anden Kafka kø til træk. Kernen i engine er et Flink [ ] streamingjob til online feature joiner. Online joiner'en forbinder træk med labels fra brugerhandlinger og producerer træningseksempler, som derefter skrives til en Kafka kø. Køen til træningseksempler forbruges af både onlinetræning og batchtræning: 13 4 Til onlinetræning læser træningsarbejderen direkte data fra Kafka køen; Til batchtræning vil et data dump job først dumpe data til HDFS [ ]; Efter at data i HDFS er akkumuleret til en vis mængde, vil træningsarbejderen hente data fra HDFS og udføre batchtræning. 18 Opdaterede parametre i trænings-PS vil blive sendt til serverings-PS i henhold til parameter synkroniseringsplanen. I reelle applikationer strømmer brugerhandlingslogfiler og træk ind i online joiner'en (Figur uden garanti for tidsrækkefølge. Derfor bruger vi en unik nøgle for hver anmodning, så brugerhandlinger og træk kan parres korrekt. 2.2.2 Online Joiner. 5) Forsinkelsen af brugerhandlinger kan også være et problem. For eksempel kan en bruger tage et par dage, før de beslutter sig for at købe en vare, de blev præsenteret for for dage siden. Dette er en udfordring for joiner'en, fordi hvis alle træk holdes i cache, vil den simpelthen ikke passe ind i hukommelsen. I vores system bruges en on-disk nøgle-værdi-lager til at gemme træk, der venter i over en vis tidsperiode. Når en brugerhandlingslog ankommer, slår den først op i in-memory cachen og derefter i nøgle-værdi-lageret i tilfælde af en manglende cache. Et andet problem, der opstår i reelle applikationer, er, at fordelingen af negative og positive eksempler er meget ujævn, hvor antallet af førstnævnte kan være mange størrelsesordener højere end sidstnævnte. For at forhindre positive eksempler i at blive overvældet af negative, er en almindelig strategi at udføre negativ sampling. Dette vil helt sikkert ændre den underliggende distribution af den trænede model og finjustere den mod en højere sandsynlighed for at foretage positive forudsigelser. Som en afhjælpning anvender vi log odds-korrektion [ ] under servering, hvilket sikrer, at online-modellen er en upartisk estimator af den oprindelige distribution. 19 Under onlinetræning fortsætter Monolith træningsklyngen med at modtage data fra online serveringsmodulet og opdaterer parametre på trænings-PS. Et afgørende trin for at aktivere online serverings-PS til at drage fordel af disse nytrænede parametre er synkroniseringen af opdaterede modelparametre. I produktionsmiljøet står vi over for flere udfordringer: 2.2.3 Parameter Synkronisering. Modeller på online serverings-PS må ikke stoppe med at blive serveret under opdatering. Vores modeller i produktion er normalt flere terabytes i størrelse, og som følge heraf tager det et stykke tid at erstatte alle parametre. Det ville være utåleligt at stoppe en online PS med at servere modellen under udskiftningsprocessen, og opdateringer skal foretages on-the-fly; Overførsel af en multi-terabyte model i sin helhed fra trænings-PS til online serverings-PS ville lægge et enormt pres på både netværksbåndbredden og hukommelsen på PS, da det kræver dobbelt modelstørrelse af hukommelse for at acceptere den nyankomne model. For at onlinetræningen kan skaleres op til størrelsen af vores forretningsscenarie, har vi designet en inkrementel on-the-fly periodisk parametersynkroniseringsmekanisme i Monolith baseret på flere bemærkelsesværdige karakteristika ved vores modeller: (1) Sparsomme parametre dominerer størrelsen af anbefalingsmodeller; (2) I et kort tidsvindue er det kun en lille delmængde af ID'er, der trænes, og deres indlejringer opdateres; (3) Tætte variable bevæger sig meget langsommere end sparsomme indlejringer. Dette skyldes, at i momentum-baserede optimeringsalgoritmer forstørres akkumuleringen af momentum for tætte variable af den gigantiske størrelse af anbefalingstræningsdata, mens kun få sparsomme indlejringer modtager opdateringer i en enkelt data-batch. (1) og (2) giver os mulighed for at udnytte de sparsomme opdateringer på tværs af alle træk-ID'er. I Monolith vedligeholder vi et hash-sæt af berørte nøgler, der repræsenterer ID'er, hvis indlejringer blev trænet siden den sidste parametersynkronisering. Vi sender delmængden af sparsomme parametre, hvis nøgler er i det berørte nøglesæt, med et minut-niveau tidsinterval fra trænings-PS til online serverings-PS. Denne relativt lille pakke af inkrementel parameteropdatering er letvægtig for netværksoverførsel og vil ikke forårsage en skarp hukommelsestop under synkroniseringen. Vi udnytter også (3) til yderligere at reducere netværks-I/O og hukommelsesforbrug ved at indstille en mere aggressiv synkroniseringsplan for sparsomme parametre, mens tætte parametre opdateres sjældnere. Dette kan give os en situation, hvor de tætte parametre, vi serverer, er en relativt forældet version sammenlignet med den sparsomme del. Sådan uoverensstemmelse kan dog tolereres på grund af den grund, der er nævnt i (3), da intet åbenlyst tab er blevet observeret. 2.3 Fejltolerance Som et system i produktion er Monolith designet med evnen til at gendanne en PS i tilfælde af fejl. Et almindeligt valg for fejltolerance er at tage et snapshot af modellens tilstand periodisk og gendanne fra det seneste snapshot, når PS-fejl opdages. Valget af snapshot-frekvens har to store effekter: (1) Modelkvalitet. Intuitivt lider modelkvaliteten mindre af tab af nylig historie med øget snapshot-frekvens. (2) Beregningsomkostninger. At tage et snapshot af en multi-terabyte model er ikke gratis. Det medfører store dele af hukommelseskopiering og disk-I/O. Som et kompromis mellem modelkvalitet og beregningsomkostninger tager Monolith snapshots af alle trænings-PS hver dag. Selvom en PS vil miste en dags opdateringer i tilfælde af en fejl, opdager vi, at ydelsesnedgangen er tålelig gennem vores eksperimenter. Vi vil analysere effekten af PS-pålidelighed i den næste sektion. 3 EVALUERING For en bedre forståelse af fordele og kompromiser bragt af vores foreslåede design, har vi udført flere eksperimenter i produktionsskala og A/B-test med live serveringstrafik for at evaluere og verificere Monolith fra forskellige aspekter. Vi sigter mod at besvare følgende spørgsmål med vores eksperimenter: (1) Hvor meget kan vi drage fordel af en kollisionsfri HashTable? (2) Hvor vigtigt er realtids onlinetræning? (3) Er Monoliths design af parametersynkronisering robust nok i et produktionsscenarie i stor skala? I denne sektion præsenterer vi først vores eksperimentelle opsætning og diskuterer derefter resultater og vores fund i detaljer. 3.1 Eksperimentel opsætning Som beskrevet i Sektion er indlejringstabeller i Monolith implementeret som kollisionsfri HashTables. For at bevise nødvendigheden af at undgå kollisioner i indlejringstabeller og kvantificere gevinster fra vores kollisionsfri implementering, udførte vi to grupper af eksperimenter på Movielens datasættet og på vores interne produktionsdatasæt: 3.1.1 Embedding Table. 2.1 (1) ml-25m datasæt [ ]. Dette er et standard offentligt datasæt til filmanmeldelser, der indeholder 25 millioner anmeldelser, som involverer ca. 162.000 brugere og 62.000 film. MovieLens 11 • . De originale labels er anmeldelser fra Forbehandling af labels 0,5 til 5,0, mens vi i produktion for det meste modtager binære signaler fra brugere. For bedre at simulere vores produktionsmodeller konverterer vi skala-labels til binære labels ved at betragte scorer ≥ 3,5 som positive eksempler og resten som negative eksempler. • Model og metrikker. Vi implementerede en standard DeepFM model, en almindeligt anvendt modelarkitektur til anbefalingsproblemer. Den består af en FM-komponent og en tæt komponent (Figur 6). Forudsigelser evalueres ved AUC, da dette er den vigtigste måling for reelle modeller. • Embedding kollisioner. Dette datasæt indeholder ca. 160K bruger-ID'er og 60K film-ID'er. For at sammenligne med den kollisionsfrie version af indlejringstabelimplementeringen udførte vi en anden gruppe af eksperimenter, hvor ID'er forbehandles med MD5 hashing og derefter mappes til et mindre ID-rum. Som resultat vil nogle ID'er dele deres indlejring med andre. Tabel 1 viser detaljerede statistikker over bruger- og film-ID'er før og efter hashing. (2) . Internt anbefalingsdatasæt Vi udførte også eksperimenter på en anbefalingsmodel i produktionsmiljøet. Denne model følger generelt en multi-tårn arkitektur, hvor hvert tårn er ansvarligt for at lære at forudsige en specialiseret type brugeradfærd. Hver model har omkring 1000 indlejringstabeller, og fordelingen af størrelsen af indlejringstabeller er meget ujævn; Det originale ID-rum for indlejringstabellen var 248. I vores baseline anvendte vi en hashing-trick ved at dekomponere for at begrænse størrelsen af indlejringstabellen. For at være mere specifik, bruger vi to mindre indlejringstabeller i stedet for en gigantisk til at generere en unik indlejring for hvert ID ved vektor-kombination: hvor 𝐸𝑟 , 𝐸𝑞 er indlejringer, der svarer til 𝐼𝐷𝑟 , 𝐼𝐷𝑞. Dette reducerer effektivt indlejringstabellens størrelse fra 248 til 225; • Denne model serverer i reel produktion, og ydelsen af dette eksperiment måles ved online AUC med reel serveringstrafik. Under onlinetræning opdaterer vi vores online serverings-PS med det seneste sæt parametre med minut-niveau intervaller. Vi har designet to grupper af eksperimenter for at verificere modelkvalitet og systemrobusthed. 3.1.2 Onlinetræning. (1) . For at undersøge nødvendigheden af minut-niveau opdateringsfrekvens, udførte vi eksperimenter, der synkroniserer parametre fra træningsmodellen til forudsigelsesmodellen med forskellige intervaller. Opdateringsfrekvens Datasættet vi bruger er Criteo Display Ads Challenge dataset3, et standard datasæt i stor skala til benchmarking af CTR-modeller. Det indeholder 7 dages kronologisk ordnede data, der registrerer træk og klikhandlinger. Til dette eksperiment bruger vi en standard DeepFM model som