Binnen ByteDance's Monolith: De Motor die Snellere, Slimmere Content Feeds Aandrijft

```html Auteurs : 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) SAMENVATTING Het bouwen van een schaalbaar en real-time aanbevelingssysteem is essentieel voor veel bedrijven die gedreven worden door tijdsgevoelige feedback van klanten, zoals het rangschikken van korte video's of online advertenties. Ondanks de alomtegenwoordige adoptie van productieschaal deep learning frameworks zoals TensorFlow of PyTorch, schieten deze algemene frameworks tekort in aanbevelingsscenario's om verschillende redenen: enerzijds is het aanpassen van systemen op basis van statische parameters en dichte berekeningen voor aanbevelingen met dynamische en schaarse kenmerken nadelig voor de modelkwaliteit; anderzijds zijn dergelijke frameworks ontworpen met een volledig gescheiden batchtrainingsfase en servingfase, waardoor het model niet in real-time kan interageren met klantfeedback. Deze problemen hebben ons ertoe aangezet om traditionele benaderingen opnieuw te onderzoeken en radicaal andere ontwerpkeuzes te verkennen. In dit artikel presenteren we 1, een systeem dat is afgestemd op online training. Ons ontwerp is gedreven door observaties van onze applicatieworkloads en productieomgeving die een duidelijke afwijking van andere aanbevelingssystemen weerspiegelen. Onze bijdragen zijn veelzijdig: ten eerste hebben we een botsingsvrije embeddingtabel gecreëerd met optimalisaties zoals vervalbare embeddings en frequentiefiltering om de geheugenvoetafdruk te verkleinen; ten tweede bieden we een productierijpe online trainingsarchitectuur met hoge fouttolerantie; ten slotte hebben we bewezen dat systeemprestaties kunnen worden ingewisseld voor real-time leren. Monolith is succesvol geïntegreerd in het BytePlus Recommend2 product. Monolith 1 INLEIDING Het afgelopen decennium zag een bloei van bedrijven aangedreven door aanbevelingstechnieken. In het streven naar een betere klantervaring is het leveren van gepersonaliseerde inhoud voor individuele gebruikers als real-time reactie een gemeenschappelijk doel van deze zakelijke toepassingen. Daartoe wordt informatie van de laatste interactie van een gebruiker vaak gebruikt als primaire input voor het trainen van een model, omdat deze het beste een gebruikersprofiel zou weergeven en de interesses en toekomstig gedrag van de gebruiker zou voorspellen. Deep learning domineert aanbevelingsmodellen [ , , , , , ], aangezien de gigantische hoeveelheid gebruikersgegevens uitstekend geschikt is voor massaal data-gedreven neurale modellen. Inspanningen om de kracht van deep learning te benutten in aanbevelingssystemen op industrieniveau worden echter voortdurend geconfronteerd met problemen die voortkomen uit de unieke kenmerken van gegevens afgeleid van gebruikersgedrag in de echte wereld. Deze gegevens verschillen drastisch van die welke worden gebruikt in conventionele deep learning problemen zoals taalmodellering of computervisie op twee aspecten: 5 6 10 12 20 21 (1) De kenmerken zijn grotendeels schaars, categorisch en dynamisch veranderend; (2) De onderliggende distributie van trainingsgegevens is niet-stationair, ook wel Concept Drift genoemd [8]. Dergelijke verschillen hebben unieke uitdagingen gesteld aan onderzoekers en ingenieurs die aan aanbevelingssystemen werken. 1.1 Schaarsheid en dynamiek De gegevens voor aanbevelingen bevatten voornamelijk schaarse categorische kenmerken, waarvan sommige met lage frequentie voorkomen. De gebruikelijke praktijk om ze toe te wijzen aan een hoog-dimensionale embeddingruimte zou een reeks problemen met zich meebrengen: • In tegenstelling tot taalmodellen waar het aantal woordstukken beperkt is, zijn het aantal gebruikers en rangschikkingsitems vele malen groter. Een dergelijke enorme embeddingtabel zou nauwelijks in het geheugen van één host passen; • Erger nog, de grootte van de embeddingtabel zal naar verwachting in de loop van de tijd toenemen naarmate er meer gebruikers en items worden toegevoegd, terwijl frameworks zoals [ , ] een vaste dichtheidsvariabelen gebruiken om de embeddingtabel weer te geven. 1 17 In de praktijk passen veel systemen low-collision hashing [ , ] toe om de geheugenvoetafdruk te verkleinen en groeiende ID's toe te staan. Dit is gebaseerd op een te idealistische aanname dat ID's in de embeddingtabel gelijkmatig verdeeld zijn in frequentie, en dat botsingen onschadelijk zijn voor de modelkwaliteit. Helaas is dit zelden waar voor een aanbevelingssysteem in de echte wereld, waar een kleine groep gebruikers of items significant meer voorkomens heeft. Met de organische groei van de grootte van de embeddingtabel nemen de kans op hash-botsingen toe en leiden tot verslechtering van de modelkwaliteit 3 6 [3]. Daarom is het een natuurlijke eis voor aanbevelingssystemen op productieschaal om de capaciteit te hebben om zoveel mogelijk kenmerken in zijn parameters vast te leggen, en ook de mogelijkheid te hebben om het aantal gebruikers en items dat het probeert bij te houden, elastisch aan te passen. 1.2 Niet-stationaire distributie Visuele en linguïstische patronen ontwikkelen zich nauwelijks op een tijdschaal van eeuwen, terwijl dezelfde gebruiker die geïnteresseerd is in een bepaald onderwerp zijn enthousiasme elke volgende minuut kan veranderen. Als gevolg hiervan is de onderliggende distributie van gebruikersgegevens niet-stationair, een fenomeen dat gewoonlijk Concept Drift wordt genoemd [8]. Intuïtief kan informatie uit een recentere geschiedenis effectiever bijdragen aan het voorspellen van de verandering in het gedrag van een gebruiker. Om het effect van Concept Drift te verminderen, moeten servingmodellen zo dicht mogelijk bij real-time worden bijgewerkt op basis van nieuwe gebruikersfeedback om de laatste interesse van een gebruiker te weerspiegelen. Met het oog op deze onderscheidingen en in observatie van problemen die voortkomen uit onze productie, hebben we ontworpen, een grootschalig aanbevelingssysteem om deze pijnpunten aan te pakken. We hebben uitgebreide experimenten uitgevoerd om ons ontwerp in de productieomgeving te verifiëren en te itereren. Monolith is in staat om Monolith (1) Volledige expressieve kracht te bieden voor schaarse kenmerken door een botsingsvrije hashtabel en een mechanisme voor dynamische kenmerkverwijdering te ontwerpen; (2) Servingfeedback in real-time terug te koppelen naar training met online training. Gesterkt door deze architecturale capaciteiten, presteert Monolith consequent beter dan systemen die hash-tricks met botsingen gebruiken met ongeveer vergelijkbaar geheugengebruik, en behaalt het state-of-the-art online serving AUC zonder onze servers' rekenkracht buitensporig te belasten. De rest van het artikel is als volgt georganiseerd. We beschrijven eerst de ontwerpdetails van hoe Monolith bestaande uitdagingen aanpakt met een botsingsvrije hashtabel en real-time training in Sectie 2. Experimenten en resultaten worden gepresenteerd in Sectie 3, samen met productie-geteste conclusies en enige discussie over afwegingen tussen tijdsgevoeligheid, betrouwbaarheid en modelkwaliteit. Sectie 4 vat gerelateerd werk samen en vergelijkt het met Monolith. Sectie 5 sluit dit werk af. 2 ONTWERP De algehele architectuur van Monolith volgt over het algemeen de gedistribueerde Worker- arameter erver instelling van TensorFlow (Figuur In een Worker-PS architectuur worden machines verschillende rollen toegewezen; Worker-machines zijn verantwoordelijk voor het uitvoeren van berekeningen zoals gedefinieerd door de grafiek, en PS-machines slaan parameters op en werken deze bij volgens de gradiënten berekend door Workers. P S 2). In aanbevelingsmodellen worden parameters in twee sets gecategoriseerd: dicht en schaars. Dichte parameters zijn gewichten/variabelen in een diep neuraal netwerk, en schaarse parameters verwijzen naar embeddingtabellen die overeenkomen met schaarse kenmerken. In ons ontwerp maken zowel dichte als schaarse parameters deel uit van de TensorFlow Graph en worden ze op parameter servers opgeslagen. Net als bij TensorFlow's Variable voor dichte parameters, hebben we een set hoog-efficiënte, botsingsvrije en flexibele HashTable-operaties ontworpen voor schaarse parameters. Als aanvulling op de beperking van TensorFlow die voortkomt uit de scheiding van training en inferentie, is de elastisch schaalbare online training van Monolith ontworpen om parameters efficiënt te synchroniseren van training-PS naar online serving-PS binnen korte intervallen, met modelrobuustheid gegarandeerd door een fouttolerantiemechanisme. 2.1 Hashtabel Een eerste principe in ons ontwerp van schaarse parameterrepresentatie is het vermijden van het samenvoegen van informatie van verschillende ID's in dezelfde vaste embedding. Het simuleren van een dynamische embeddingtabel met een out-of-the-box TensorFlow Variabele leidt onvermijdelijk tot ID-botsingen, die verergeren naarmate er nieuwe ID's arriveren en de tabel groeit. Daarom hebben we, in plaats van te bouwen op Variabele, een nieuwe key-value HashTable ontwikkeld voor onze schaarse parameters. Onze HashTable maakt gebruik van Cuckoo Hashmap [ ] onder de motorkap, die het invoegen van nieuwe sleutels ondersteunt zonder botsingen met bestaande sleutels. Cuckoo Hashing bereikt een worst-case 𝑂 (1) tijdcomplexiteit voor zoekopdrachten en verwijderingen, en een verwachte geamortiseerde 𝑂 (1) tijd voor invoegingen. Zoals geïllustreerd in Figuur , onderhoudt het twee tabellen 𝑇0, 𝑇1 met verschillende hashfuncties ℎ0 (𝑥), ℎ1 (𝑥), en een element wordt in een van beide opgeslagen. Bij het invoegen van een element 16 3 𝐴 in 𝑇0, probeert het eerst 𝐴 te plaatsen op ℎ0 (𝐴); Als ℎ0 (𝐴) bezet is door een ander element 𝐵, wordt 𝐵 uit 𝑇0 geëvacueerd en wordt geprobeerd 𝐵 in 𝑇1 in te voegen met dezelfde logica. Dit proces wordt herhaald totdat alle elementen stabiel zijn, of er een rehash plaatsvindt wanneer de invoeging in een cyclus terechtkomt. Vermindering van geheugenvoetafdruk is ook een belangrijke overweging in ons ontwerp. Een naïeve aanpak van het invoegen van elke nieuwe ID in de HashTable zal snel het geheugen uitputten. Observatie van echte productiemodellen leidt tot twee conclusies: (1) ID's die slechts een paar keer voorkomen, dragen beperkt bij aan het verbeteren van de modelkwaliteit. Een belangrijke observatie is dat ID's langstaart-gedistribueerd zijn, waarbij populaire ID's miljoenen keren kunnen voorkomen, terwijl de impopulaire ID's niet meer dan tien keer voorkomen. Embeddings die overeenkomen met deze infrequent ID's zijn onderfittend vanwege een gebrek aan trainingsgegevens en het model zal er geen goede schatting op kunnen maken. Uiteindelijk zullen deze ID's het resultaat waarschijnlijk niet beïnvloeden, dus de modelkwaliteit zal niet lijden onder het verwijderen van deze ID's met lage frequenties; (2) Verouderde ID's uit een ver verleden dragen zelden bij aan het huidige model, aangezien velen ervan nooit worden bezocht. Dit kan te wijten zijn aan een gebruiker die niet langer actief is, of een korte video die verouderd is. Het opslaan van embeddings voor deze ID's kan het model op geen enkele manier helpen, behalve het verspillen van ons PS-geheugen. Op basis van deze observaties hebben we verschillende filterheuristieken voor kenmerk-ID's ontworpen voor een geheugenefficiëntere implementatie van HashTable: (1) ID's worden gefilterd voordat ze worden toegelaten tot embeddingtabellen. We hebben twee filtermethoden: Eerst filteren we op hun frequentie voordat ze als sleutels worden ingevoegd, waarbij de drempel van frequentie een instelbare hyperparameter is die varieert voor elk model; Bovendien gebruiken we een probabilistisch filter dat helpt het geheugengebruik verder te verminderen; ![#Figure 4: Streaming Engine. De informatiefeedbacklus van [Gebruiker → Model Server → Training Worker → Model Server → Gebruiker] zou lange tijd duren bij het volgen van het Batch Training-pad, terwijl de Online Training de lus directer sluit.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID's worden getimed en ingesteld om te verlopen na een vooraf gedefinieerde periode van inactiviteit. De vervaltijd is ook instelbaar voor elke embeddingtabel om onderscheid te maken tussen kenmerken met verschillende gevoeligheid voor historische informatie. In onze implementatie is HashTable geïmplementeerd als een TensorFlow-resourceoperatie. Net als bij Variabele worden zoekopdrachten en updates ook geïmplementeerd als native TensorFlow-operaties voor eenvoudigere integratie en betere compatibiliteit. 2.2 Online Training In Monolith is training verdeeld in twee fasen (Figuur 1): (1) Batch training fase. Deze fase werkt als een normale TensorFlow-trainingslus: in elke trainingsstap leest een training worker een mini-batch trainingsvoorbeelden uit de opslag, vraagt parameters op van PS, berekent een voorwaartse en achterwaartse pass, en stuurt uiteindelijk bijgewerkte parameters naar de trainings-PS. Iets anders dan andere veelvoorkomende deep learning-taken, trainen we onze dataset slechts voor één pass. Batch training is nuttig voor het trainen van historische gegevens wanneer we onze modelarchitectuur wijzigen en het model opnieuw trainen; (2) Online training fase. Nadat een model is ingezet voor online serving, stopt de training niet maar gaat over naar de online trainingsfase. In plaats van mini-batch voorbeelden uit de opslag te lezen, consumeert een training worker real-time gegevens on-the-fly en werkt de trainings-PS bij. De trainings-PS synchroniseert periodiek zijn parameters met de serving-PS, wat onmiddellijk effect heeft aan de gebruikerszijde. Dit stelt ons model in staat om zichzelf interactief aan te passen aan de feedback van een gebruiker in real-time. Monolith is gebouwd met de mogelijkheid om naadloos te schakelen tussen batch training en online training. Dit wordt mogelijk gemaakt door ons ontwerp van een streaming engine zoals geïllustreerd in Figuur 2.2.1 Streaming Engine. 4. In ons ontwerp gebruiken we één Kafka [ ] wachtrij om gebruikersacties (bijv. klikken op een item of een item leuk vinden etc.) te loggen en een andere Kafka wachtrij voor kenmerken. De kern van de engine is een Flink [ ] streamingtaak voor online feature Joiner. De online joiner voegt kenmerken samen met labels uit gebruikersacties en produceert trainingsvoorbeelden, die vervolgens naar een Kafka-wachtrij worden geschreven. De wachtrij voor trainingsvoorbeelden wordt geconsumeerd door zowel online training als batch training: 13 4 Voor online training leest de training worker rechtstreeks gegevens uit de Kafka-wachtrij; Voor batch training zal een datadumpingtaak eerst gegevens dumpen naar HDFS [ ]; Nadat de gegevens in HDFS zich tot een bepaalde hoeveelheid hebben opgehoopt, zal de training worker gegevens uit HDFS ophalen en batch training uitvoeren. 18 Bijgewerkte parameters in de trainings-PS worden periodiek naar de serving-PS gepusht volgens het parametersynchronisatieschema. In toepassingen in de echte wereld worden gebruikersactielogboeken en kenmerken gestreamd naar de online joiner (Figuur zonder garantie van tijdsvolgorde. Daarom gebruiken we een unieke sleutel voor elke aanvraag, zodat gebruikersactie en kenmerken correct kunnen worden gekoppeld. 2.2.2 Online Joiner. 5) De vertraging van gebruikersacties kan ook een probleem zijn. Een gebruiker kan bijvoorbeeld een paar dagen nodig hebben voordat hij besluit een item te kopen dat dagen geleden werd gepresenteerd. Dit is een uitdaging voor de joiner, want als alle kenmerken in de cache worden bewaard, past het simpelweg niet in het geheugen. In ons systeem wordt een on-disk key-value opslag gebruikt om kenmerken op te slaan die langer dan een bepaalde periode wachten. Wanneer een gebruikersactielogboek arriveert, kijkt het eerst naar de in-memory cache en vervolgens naar de key-value opslag in geval van een ontbrekende cache. Een ander probleem dat zich voordoet in de praktijk is dat de distributie van negatieve en positieve voorbeelden zeer onevenwichtig is, waarbij het aantal van de eerste ordes van grootte hoger kan zijn dan het aantal van de laatste. Om te voorkomen dat positieve voorbeelden worden overweldigd door negatieve, is een gebruikelijke strategie om negatieve sampling te doen. Dit verandert zeker de onderliggende distributie van het getrainde model, waardoor het wordt aangepast naar een hogere waarschijnlijkheid van positieve voorspellingen. Als remedie passen we log odds correctie toe [ ] tijdens serving, om ervoor te zorgen dat het online model een onbevooroordeelde schatter is van de oorspronkelijke distributie. 19 Tijdens online training blijft het Mono-lith trainingscluster gegevens ontvangen van de online serving module en werkt het parameters op de trainings-PS bij. Een cruciale stap om de online serving-PS te laten profiteren van deze nieuw getrainde parameters is de synchronisatie van bijgewerkte modelparameters. In de productieomgeving worden we geconfronteerd met verschillende uitdagingen: 2.2.3 Parameter Synchronisatie. Modellen op de online serving-PS mogen niet stoppen met serveren tijdens het bijwerken. Onze modellen in productie zijn meestal enkele terabytes groot, en het vervangen van alle parameters duurt daardoor enige tijd. Het zou ondraaglijk zijn om een online PS te stoppen met het serveren van het model tijdens het vervangingsproces, en updates moeten on-the-fly worden uitgevoerd; Het overbrengen van een multi-terabyte model in zijn geheel van training-PS naar de online serving-PS zou enorme druk uitoefenen op zowel de netwerkbandbreedte als het geheugen op PS, omdat het een verdubbelde modelgrootte aan geheugen vereist om het nieuw arriverende model te accepteren. Om de online training te laten schalen naar de omvang van ons bedrijfsscenario, hebben we een incrementeel on-the-fly periodiek parametersynchronisatiemechanisme ontworpen in Monolith op basis van verschillende opmerkelijke kenmerken van onze modellen: (1) Schaarse parameters domineren de grootte van aanbevelingsmodellen; (2) Gegeven een kort tijdsvenster, wordt slechts een kleine subset van ID's getraind en worden hun embeddings bijgewerkt; (3) Dichte variabelen bewegen veel langzamer dan schaarse embeddings. Dit komt doordat in momentum-gebaseerde optimizers de accumulatie van momentum voor dichte variabelen wordt vergroot door de gigantische omvang van de aanbevelingstrainingsgegevens, terwijl slechts enkele schaarse embeddings updates ontvangen in een enkele gegevensbatch. (1) en (2) stellen ons in staat om de schaarse updates over alle kenmerk-ID's te benutten. In Monolith onderhouden we een hash set van aangeraakte sleutels, die ID's vertegenwoordigen waarvan de embeddings zijn getraind sinds de laatste parametersynchronisatie. We pushen de subset van schaarse parameters waarvan de sleutels zich in de aangeraakte sleutelset bevinden met een interval van enkele minuten van de training-PS naar de online serving-PS. Dit relatief kleine pakket incrementele parameterupdates is lichtgewicht voor netwerktransmissie en veroorzaakt geen scherpe geheugenpiek tijdens de synchronisatie. We maken ook gebruik van (3) om de netwerk I/O en het geheugengebruik verder te verminderen door een agressiever synchronisatieschema in te stellen voor schaarse parameters, terwijl dichte parameters minder frequent worden bijgewerkt. Dit kan ons in een situatie brengen waarin de geserveerde dichte parameters een relatief verouderde versie zijn in vergelijking met het schaarse deel. Dergelijke inconsistentie kan echter worden getolereerd vanwege de reden genoemd in (3), aangezien er geen opvallend verlies is waargenomen. 2.3 Fouttolerantie Als een systeem in productie is Monolith ontworpen met de mogelijkheid om een PS te herstellen in geval van storing. Een gebruikelijke keuze voor fouttolerantie is om de status van een model periodiek te snapshotten en te herstellen vanaf de laatste snapshot wanneer een PS-storing wordt gedetecteerd. De keuze van de snapshotfrequentie heeft twee belangrijke gevolgen: (1) Modelkwaliteit. Intuïtief lijdt de modelkwaliteit minder onder verlies van recente geschiedenis met een verhoogde snapshotfrequentie. (2) Reken overhead. Het snapshotten van een multi-terabyte model is niet gratis. Het brengt grote stukken geheugencopy en disk I/O met zich mee. Als afweging tussen modelkwaliteit en reken overhead, maakt Monolith dagelijks snapshots van alle trainings-PS's. Hoewel een PS één dag aan updates zal verliezen in geval van een storing, ontdekten we dat de prestatiedegradatie acceptabel is door onze experimenten. We zullen het effect van PS-betrouwbaarheid in de volgende sectie analyseren. 3 EVALUATIE Voor een beter begrip van de voordelen en afwegingen van ons voorgestelde ontwerp hebben we verschillende experimenten op productieschaal en A/B-tests met live serving traffic uitgevoerd om Monolith vanuit verschillende aspecten te evalueren en te verifiëren. We streven ernaar de volgende vragen te beantwoorden met onze experimenten: (1) Hoeveel kunnen we profiteren van een botsingsvrije HashTable? (2) Hoe belangrijk is real-time online training? (3) Is het ontwerp van parameter synchronisatie van Monolith robuust genoeg in een grootschalig productie scenario? In deze sectie presenteren we eerst onze experimentele instellingen en bespreken we vervolgens gedetailleerd de resultaten en onze bevindingen. 3.1 Experimentele Opzet Zoals beschreven in Sectie worden embeddingtabellen in Monolith geïmplementeerd als botsingsvrije HashTables. Om de noodzaak van het vermijden van botsingen in embeddingtabellen aan te tonen en de winst van onze botsingsvrije implementatie te kwantificeren, hebben we twee groepen experimenten uitgevoerd op de Movielens dataset en op onze interne productiedataset: 3.1.1 Embedding Tabel. 2.1, (1) ml-25m dataset [ ]. Dit is een standaard openbare dataset voor filmbeoordelingen, die 25 miljoen beoordelingen bevat die ongeveer 162000 gebruikers en 62000 films omvatten. MovieLens 11 • . De originele labels zijn beoordelingen van Voorverwerking van labels 0,5 tot 5,0, terwijl in productie onze taken voornamelijk binaire signalen van gebruikers ontvangen. Om onze productiemodellen beter te simuleren, zetten we schaal-labels om naar binaire labels door scores ≥ 3,5 als positieve samples te behandelen en de rest als negatieve samples. • Model en metrics. We hebben een standaard DeepFM [9] model geïmplementeerd, een veelgebruikt modelarchitectuur voor aanbevelingsproblemen. Het bestaat uit een FM-component en een dichte component (Figuur 6). Voorspellingen worden geëvalueerd met AUC [2], aangezien dit de belangrijkste meting is voor echte modellen. • Embedding botsingen. Deze dataset bevat ongeveer 160K gebruikers-ID's en 60K film-ID's. Om te vergelijken met de botsingsvrije versie van de embeddingtabelimplementatie, hebben we een andere groep experimenten uitgevoerd waarbij ID's zijn voorbewerkt met MD5 hashing en vervolgens zijn toegewezen aan een kleinere ID-ruimte. Als gevolg hiervan zullen sommige ID's hun embedding delen met anderen. Tabel 1 toont gedetailleerde statistieken van gebruikers- en film-ID's vóór en na hashing. (2) . Interne aanbevelingsdataset We hebben ook experimenten uitgevoerd op een aanbevelingsmodel in de productieomgeving. Dit model volgt over het algemeen een multi-tower architectuur, waarbij elke tower verantwoordelijk is voor het leren voorspellen van een gespecialiseerd type gebruikersgedrag. Elk model heeft ongeveer 1000 embeddingtabellen, en de distributie van de grootte van embeddingtabellen is zeer onevenwichtig; De originele ID-ruimte van de embeddingtabel was 248. In onze baseline hebben we een hashing-truc toegepast door te decomponeren om de grootte van de embeddingtabel te beperken. Om specifieker te zijn, gebruiken we twee kleinere embeddingtabellen in plaats van een gigantische om een unieke embedding voor elke ID te genereren door vectorcombinatie: waarbij 𝐸𝑟 , 𝐸𝑞 embeddings zijn die overeenkomen met 𝐼𝐷𝑟 , 𝐼𝐷𝑞. Dit verkleint effectief de groottes van de embeddingtabel van 248 naar 225; • Dit model wordt in de echte productie geleverd, en de prestaties van dit experiment worden gemeten met online AUC met echte serving traffic. Tijdens online training werken we onze on-line serving-PS bij met de nieuwste set parameters met intervallen van enkele minuten. We hebben twee groepen experimenten ontworpen om de modelkwaliteit en systeemrobuustheid te verifiëren. 3.1.2 Online Training. (1) . Om de noodzaak van een updatefrequentie van enkele minuten te onderzoeken, hebben we experimenten uitgevoerd die parameters synchroniseren van het trainingsmodel naar het voorspellingsmodel met verschillende intervallen. Update frequentie De dataset die we gebruiken is de Criteo Display Ads Challenge dataset3, een grootschalige standaard dataset voor het benchmarken van CTR-modellen. Het bevat 7 dagen aan chronologisch geordende gegevens die kenmerken en klikacties vastleggen. Voor dit experiment gebruiken we een standaard DeepFM [ ] model zoals beschreven in 9 6. Om online training te simuleren, hebben we de volgende voorverwerking voor de dataset uitgevoerd. We nemen 7 dagen gegevens uit de dataset en splitsen deze in twee delen: 5 dagen gegevens voor batch training, en 2 dagen voor online training. We splitsen de 2 dagen gegevens verder in 𝑁 shards chronologisch. Online training wordt gesimuleerd door algoritme 1. Als zodanig simuleren we het synchroniseren van getrainde parameters naar online serving-PS met een interval bepaald door het aantal datashards. We hebben geëxperimenteerd met 𝑁 = 10, 50, 100, wat ongeveer overeenkomt met update-intervallen van 5 uur, 1 uur en 30 minuten. (2) . Bovendien hebben we ook een live experiment uitgevoerd met echt serving traffic om het belang van online training in een real-world toepassing verder aan te tonen. Dit A/B-experiment vergelijkt online training met batch training op een van onze advertentiemodellen in productie. Live experiment 3.2 Resultaten en Analyse 3.2.1