Indenfor ByteDances monolit: 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) RESUMÉ Opbygningen af et skalerbart og real-time anbefalingssystem er afgørende for mange virksomheder, der drives af tidssensitiv kundefeedback, såsom rangering af kortvideoer eller onlineannoncer. På trods af den allestedsnærværende anvendelse af produktionsskala deep learning-frameworks som Ten-sorFlow eller PyTorch, lever disse generelle frameworks op til forretningsmæssige krav i anbefalingsscenarier af forskellige årsager: på den ene side er finjustering af systemer baseret på statiske parametre og tætte beregninger til anbefaling med dynamiske og sparse features skadeligt for modelkvaliteten; på den anden side er sådanne frameworks designet med helt adskilte batch-trænings- og serveringsstadier, hvilket forhindrer modellen i at interagere med kundefeedback i realtid. Disse problemer førte os til at genoverveje traditionelle metoder og udforske radikalt anderledes designvalg. I dette papir præsenterer vi 1, et system, der er skræddersyet til onlinetræning. Vores design er drevet af observationer af vores applikationsarbejdsbyrder og produktionsmiljø, som afspejler en markant afvigelse fra andre anbefalingssystemer. Vores bidrag er mangefacetterede: for det første har vi skabt et kollisionsfrit embedding-tabel med optimeringer som udløbende embeddings og frekvensfiltrering for at reducere dets hukommelsesfodaftryk; for det andet leverer vi en produktionsklar online træningsarkitektur med høj fejltolerance; endelig beviste vi, at systemets pålidelighed kan handles med henblik på real-time læring. Monolith er blevet succesfuldt implementeret i BytePlus Recommend2-produktet. Monolith 1 INTRODUKTION Det seneste årti har været vidne til en boom af forretninger drevet af anbefalingsteknikker. I jagten på en bedre kundeoplevelse er levering af personligt indhold til hver enkelt bruger som en real-time respons et fælles mål for disse forretningsapplikationer. Til dette formål bruges information fra en brugers seneste interaktion ofte som primær input til træning af en model, da den bedst afspejler en brugers portræt og kan forudsige brugerens interesse og fremtidige adfærd. Deep learning har domineret anbefalingsmodeller [ , , , , , ], da den gigantiske mængde brugerdata passer naturligt til massivt datadrevne neurale modeller. Bestræbelser på 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 brugeradfærd i den virkelige verden. Disse data adskiller sig markant fra dem, der bruges i konventionelle deep learning-problemer som sprogmodellering eller computervision på to måder: 5 6 10 12 20 21 (1) Funktionerne er for det meste sparse, kategoriske og dynamisk skiftende; (2) Den underliggende distribution af træningsdata er ikke-stationær, også kendt som konceptdrift . Sådanne forskelle har udgjort unikke udfordringer for forskere og ingeniører, der arbejder med anbefalingssystemer. 1.1 Sparsitet og Dynamik Data til anbefaling indeholder for det meste sparse kategoriske features, hvoraf nogle forekommer med lav frekvens. Den almindelige praksis med at mappe dem til et højdimensionelt embedding-rum 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 rangerede elementer mange størrelsesordener større. Et sådant enormt embedding-tabel ville knap nok passe ind i en enkelt hosts hukommelse; • Endnu værre er det, at størrelsen af embedding-tabellen forventes at vokse over tid, efterhånden som flere brugere og elementer tilføjes, mens frameworks som [ , ] bruger et fast antal tætte variabler til at repræsentere embedding-tabellen. 1 17 I praksis adopterer mange systemer low-collision hashing [ , ] som en måde at reducere hukommelsesfodaftrykket på og tillade vækst af ID'er. Dette bygger på en over-idealistisk antagelse om, at ID'er i embedding-tabellen er jævnt fordelt i frekvens, og kollisioner er uskadelige for modelkvaliteten. Desværre er dette sjældent sandt for et anbefalingssystem i den virkelige verden, hvor en lille gruppe af brugere eller elementer har signifikant flere forekomster. Med den organiske vækst af embedding-tabellens størrelse øges chancerne for hash-kollision og fører til forringelse af modelkvaliteten 3 6 . Derfor er det et naturligt krav for produktionsskala anbefalingssystemer at have kapacitet til at fange så mange features i dets parametre, og også have evnen til elastisk at justere antallet af brugere og elementer, det forsøger at holde styr på. 1.2 Ikke-stationær Distribution Visuelle og sproglige mønstre udvikler sig knap nok på en tidsskala på århundreder, mens den samme bruger, der er interesseret i et emne, kan ændre sin iver hvert minut. Som et resultat er den underliggende distribution af brugerdata ikke-stationær, et fænomen, der almindeligvis refereres til som konceptdrift . 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 konceptdrift skal serveringsmodeller opdateres fra ny brugerfeedback så tæt på realtid som muligt for at afspejle brugerens seneste interesse. I lyset af disse forskelle og i observation af problemer, der opstår fra vores produktion, designede vi , et storskala anbefalingssystem til at løse disse smertepunkter. Vi udførte omfattende eksperimenter for at verificere og iterere vores design i produktionsmiljøet. Monolith er i stand til at Monolith (1) Give fuld udtrykskraft for sparse features ved at designe et kollisionsfrit hash-tabel og en dynamisk feature-udstødningsmekanisme; (2) Tilbageføre serveringsfeedback 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 nogenlunde tilsvarende hukommelsesforbrug og opnår state-of-the-art online serving AUC uden at overbelaste vores serveres beregningskraft. Resten af papiret er organiseret som følger. Vi uddyber først design-detaljer om, hvordan Monolith tackler eksisterende udfordringer med kollisionsfrit hash-tabel og real-time træning i afsnit 2. Eksperimenter og resultater vil blive præsenteret i afsnit 3, sammen med produktionsprøvede konklusioner og en diskussion af kompromiser mellem tidssensitivitet, pålidelighed og modelkvalitet. Afsnit 4 opsummerer relateret arbejde og sammenligner det med Monolith. Afsnit 5 afslutter 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 er parametre kategoriseret i to sæt: tætte og sparse. Tætte parametre er vægte/variable i et dybt neuralt netværk, og sparse parametre henviser til embedding-tabeller, der svarer til sparse features. I vores design er både tætte og sparse 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, kollisionsfrie og fleksible HashTable-operationer til sparse parametre. Som et supplement til Tensor-Flows 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 serving-PS inden for korte intervaller, med modelrobusthedsgaranti leveret af fejltolerance-mekanismen. 2.1 Hash Tabel Et førsteprincip i vores design af sparse parameterrepræsentation er at undgå at proppe information fra forskellige ID'er ind i den samme fast-størrelse embedding. Simulering af en dynamisk størrelses embedding-tabel med en out-of-the-box TensorFlow Variable vil uundgåeligt føre til ID-kollision, som forværres, når nye ID'er ankommer, og tabellen vokser. Derfor, i stedet for at bygge oven på Variable, udviklede vi en ny key-value HashTable til vores sparse parametre. Vores HashTable bruger Cuckoo Hashmap [ ] internt, som 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 udstøde 𝐵 fra 𝑇0 og forsøge at indsætte 𝐵 i 𝑇1 med samme logik. Denne proces vil blive gentaget, indtil alle elementer stabiliserer sig, eller rehash sker, når indsættelsen løber ind i en cyklus. Reduktion af hukommelsesfodaftrykket er også en vigtig overvejelse i vores design. En naiv tilgang med at indsætte hvert nyt ID i HashTable vil hurtigt tømme hukommelsen. Observationer af reelle produktionsmodeller fører til to konklusioner: (1) ID'er, der kun forekommer et par gange, har begrænset bidrag til at forbedre modelkvaliteten. 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. Embeddings, der svarer til disse sjældne ID'er, er underfit på grund af mangel på træningsdata, og modellen vil ikke være i stand til at foretage en god vurdering baseret på dem. I sidste ende vil disse ID'er sandsynligvis ikke påvirke resultatet, så modelkvaliteten vil ikke lide under fjernelse af disse ID'er med lav forekomst; (2) Stale ID'er fra en fjern fortid bidrager sjældent til den aktuelle model, da mange af dem aldrig besøges. Dette kan skyldes en bruger, der ikke længere er aktiv, eller en kortvideo, der er forældet. Lagring af embeddings for disse ID'er kan ikke hjælpe modellen på nogen måde, men dræner vores PS-hukommelse forgæves. Baseret på disse observationer har vi designet flere heuristikker til filtrering af feature ID'er for en mere hukommelseseffektiv implementering af HashTable: (1) ID'er filtreres, før de accepteres i embedding-tabeller. Vi har to filtreringsmetoder: Først filtrerer vi efter deres forekomster, før de indsættes som nøgler, hvor tærsklen for forekomster er en justerbar hyperparameter, der varierer for hver model; Derudover bruger vi et probabilistisk filter, der hjælper med yderligere at reducere hukommelsesforbruget; ![#Figur 4: Streaming Engine. Informationsfeedback-løkken fra [Bruger → Model Server → Træningsworker → Model Server → Bruger] ville tage lang tid, når den følger Batch Træningsstien, mens Online Træning vil lukke løkken 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 er også justerbar for hver embedding-tabel for at tillade differentiering af features med forskellig følsomhed over for historisk information. I vores implementering er HashTable implementeret som en TensorFlow resource-operation. Ligesom Variable er opslag og opdateringer også implementeret som native TensorFlow-operationer for lettere integration og bedre kompatibilitet. 2.2 Onlinetræning I Monolith er træningen opdelt i to faser (Figur 1): (1) Batch træningsfase. Denne fase fungerer som en almindelig TensorFlow træningsloop: I hvert træningstrin læser en træningsworker en mini-batch af træningseksempler fra lageret, anmoder om parametre fra PS, beregner en fremadgående og en bagudgående pass, og sender til sidst opdaterede parametre til trænings-PS. Lidt anderledes end andre almindelige deep learning-opgaver træner vi kun vores datasæt i én passage. Batchtræning er nyttig til træning af historiske data, når vi ændrer vores modelarkitektur og gen-træner modellen; (2) Online træningsfase. Efter at en model er implementeret til online-servering, stopper træningen ikke, men går ind i online-træningsfasen. I stedet for at læse mini-batch eksempler fra lageret, forbruger en træningsworker real-tidsdata "on-the-fly" og opdaterer trænings-PS. Trænings-PS synkroniserer periodisk sine parametre til serving-PS, som vil træde i kraft på brugersiden med det samme. Dette gør det muligt for vores model at interagere og tilpasse sig 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 brugerhandlinger (f.eks. klik på et element eller like et element osv.) og en anden Kafka kø til features. Kernen i motoren er et Flink [ ] streamingjob til online feature joiner. Online joineren samler features med labels fra brugerhandlinger og producerer træningseksempler, som derefter skrives til en Kafka kø. Køen til træningseksempler forbruges af både online og batch træning: 13 4 Til onlinetræning læser træningsworkeren direkte data fra Kafka køen; Til batchtræning vil et data dumping job først dumpe data til HDFS [ ]; Efter at data i HDFS er akkumuleret til en vis mængde, vil træningsworkeren hente data fra HDFS og udføre batchtræning. 18 Opdaterede parametre i trænings-PS vil blive sendt til serving-PS i henhold til parameter-synkroniseringsplanen. (2) I anvendelser i den virkelige verden strømmer brugerhandlingslogs og features ind i online joineren (Figur uden garanti for tidsrækkefølge. Derfor bruger vi en unik nøgle for hver anmodning, så brugerhandling og features kan parres korrekt. Online Joiner. 5) Forsinkelsen af brugerhandlinger kan også være et problem. For eksempel kan en bruger bruge et par dage, før de beslutter sig for at købe et element, de blev præsenteret for for dage siden. Dette er en udfordring for joineren, for hvis alle features holdes i cache, ville den simpelthen ikke passe ind i hukommelsen. I vores system anvendes et on-disk key-value storage til at gemme features, der venter i en vis tidsperiode. Når en brugerhandlingslog ankommer, slår den først i hukommelses-cachen og slår derefter op i key-value-lageret i tilfælde af en manglende cache. Et andet problem, der opstår i anvendelser i den virkelige verden, er, at distributionen af negative og positive eksempler er meget ujævn, hvor antallet af de førstnævnte kan være mange størrelsesordener højere end de sidstnævnte. For at forhindre positive eksempler i at blive overvældet af negative, er en almindelig strategi at foretage negativ sampling. Dette vil bestemt ændre den underliggende distribution af den trænede model og finjustere den mod en højere sandsynlighed for at lave positive forudsigelser. Som 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 modtager Monolith træningsklyngen konstant data fra online serving-modulet og opdaterer parametre på trænings-PS. Et afgørende trin for at give online serving-PS mulighed for at drage fordel af disse nytrænede parametre er synkronisering af opdaterede modelparametre. I produktionsmiljøet står vi over for flere udfordringer: 2.2.3 Parameter Synkronisering. Modeller på online serving-PS må ikke stoppe med at servicere under opdatering. Vores modeller i produktion er normalt flere terabytes store, og derfor tager det et stykke tid at erstatte alle parametre. Det ville være utåleligt at stoppe en online PS fra at servicere 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 serving-PS vil 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æning kan skaleres op til størrelsen af vores forretningsscenario, har vi designet en inkrementel on-the-fly periodisk parameter synkroniseringsmekanisme i Monolith baseret på flere bemærkelsesværdige karakteristika ved vores modeller: (1) Sparse parametre dominerer størrelsen af anbefalingsmodeller; (2) Givet et kort tidsvindue trænes kun en lille delmængde af ID'er, og deres embeddings opdateres; (3) Tætte variabler bevæger sig meget langsommere end sparse embeddings. Dette skyldes, at i moment-baserede optimerere akkumuleres momentet for tætte variabler forstærket af den gigantiske størrelse af anbefalingstræningsdata, mens kun få sparse embeddings modtager opdateringer i en enkelt data-batch. (1) og (2) giver os mulighed for at udnytte de sparse opdateringer på tværs af alle feature ID'er. I Monolith vedligeholder vi et hash-sæt af berørte nøgler, der repræsenterer ID'er, hvis embeddings blev trænet siden den sidste parameter synkronisering. Vi sender delmængden af sparse parametre, hvis nøgler er i "touched-keys"-sættet med et interval på et minut fra trænings-PS til online serving-PS. Denne relativt lille pakke af inkrementelle parameteropdateringer er letvægts for netværksoverførsel og vil ikke forårsage en skarp hukommelsesstigning under synkroniseringen. Vi udnytter også (3) til yderligere at reducere netværks I/O og hukommelsesforbrug ved at sætte en mere aggressiv synkroniseringsplan for sparse parametre, mens tætte parametre opdateres mindre hyppigt. Dette kunne give os en situation, hvor de tætte parametre, vi serverer, er en relativt forældet version sammenlignet med den sparse del. En sådan uoverensstemmelse kan dog tolereres på grund af årsagen nævnt i (3), da intet tydeligt tab er 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 periodisk at tage et snapshot af en models tilstand og gendanne fra det seneste snapshot, når en PS-fejl detekteres. Valget af snapshot-frekvens har to store indvirkninger: (1) Modelkvalitet. Intuitivt lider modelkvaliteten mindre af tab af nylig historie med øget snapshot-frekvens. (2) Beregningsmæssig overhead. 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 beregningsmæssig overhead tager Monolith et snapshot af alle trænings-PS hver dag. Selvom en PS vil miste en dags opdateringer i tilfælde af en fejl, opdagede vi, at degraderingen af ydeevnen er acceptabel gennem vores eksperimenter. Vi vil analysere effekten af PS-pålidelighed i næste afsnit. 3 EVALUERING For en bedre forståelse af fordele og kompromiser, der opnås ved vores foreslåede design, udførte vi flere eksperimenter i produktionsskala og A/B-test med live serving-trafik 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 vigtig er real-time onlinetræning? (3) Er Monoliths design af parameter synkronisering robust nok i et storskala produktionsscenarie? I dette afsnit 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 afsnit er embedding-tabeller i Monolith implementeret som kollisionsfrie HashTables. For at bevise nødvendigheden af at undgå kollisioner i embedding-tabeller og kvantificere gevinster fra vores kollisionsfrie implementering, udførte vi to grupper af eksperimenter på Movielens-datasættet og på vores interne produktionsdatasæt: 3.1.1 Embedding Tabel. 2.1 (1) ml-25m datasæt [ ]. Dette er et standard offentligt datasæt til filmvurderinger, der indeholder 25 millioner vurderinger, som involverer ca. 162.000 brugere og 62.000 film. MovieLens 11 • . De oprindelige labels er vurderinger fra Forbehandling af labels 0,5 til 5,0, mens vi i produktion primært 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 samples og resten som negative samples. • 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 primære måling for reelle modeller. • Embedding-kollisioner. Dette datasæt indeholder ca. 160K bruger-ID'er og 60K filmin-ID'er. For at sammenligne med den kollisionsfrie version af embedding-tabelimplementeringen udførte vi en anden gruppe af eksperimenter, hvor ID'erne blev forbehandlet med MD5-hashing og derefter mappet til et mindre ID-rum. Som følge heraf vil nogle ID'er dele deres embedding med andre. Tabel 1 viser detaljerede statistikker over bruger- og filmin-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-tower arkitektur, hvor hvert tårn er ansvarligt for at lære at forudsige en specialiseret type brugeradfærd. Hver model har omkring 1000 embedding-tabeller, og fordelingen af størrelsen af embedding-tabeller er meget ujævn; Det oprindelige ID-rum for embedding-tabellen var 248. I vores baseline anvendte vi en hashing-trick ved at nedbryde for at begrænse størrelsen af embedding-tabellen. For at være mere specifik bruger vi to mindre embedding-tabeller i stedet for en gigantisk til at generere et unikt embedding for hvert ID ved vektor-kombination: hvor 𝐸𝑟 , 𝐸𝑞 er embeddings, der svarer til 𝐼𝐷𝑟 , 𝐼𝐷𝑞. Dette reducerer effektivt embedding-tabelstørrelserne fra 248 til 225; • Denne model serviceres i reel produktion, og ydeevnen af dette eksperiment måles ved online AUC med reel serving-trafik. Under onlinetræning opdaterer vi vores onlinelserving-PS med det seneste sæt af parametre med minut-niveau intervaller. Vi designede 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 datasæt3, et storskala standarddatasæt til benchmarking af CTR-modeller. Det indeholder 7 dages kronologisk ordnede data, der registrerer features og klikhandlinger. Til dette eksperiment bruger vi en standard DeepFM-model som beskrevet i 6. For at simulere onlinetræning udførte vi følgende forbehandling af datasættet. Vi tager 7 dages data fra datasættet og opdeler det i to dele: 5 dages data til batchtræning og 2 dages data til onlinetræning. Vi