Innerhalb von ByteDance's Monolith: Die Engine für intelligentere, schnellere Content-Feeds

Autoren: 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) ZUSAMMENFASSUNG Der Aufbau eines skalierbaren Echtzeit-Empfehlungssystems ist für viele von zeitkritischem Kundenfeedback getriebene Unternehmen, wie z. B. Short-Video-Ranking oder Online-Werbung, von entscheidender Bedeutung. Trotz der allgegenwärtigen Einführung von Produktionsmaßstäblichen Deep-Learning-Frameworks wie TensorFlow oder PyTorch reichen diese Allzweck-Frameworks aus verschiedenen Gründen nicht aus, um die Geschäftsanforderungen in Empfehlungsszenarien zu erfüllen: Einerseits ist das Anpassen von Systemen auf der Grundlage statischer Parameter und dichter Berechnungen für Empfehlungen mit dynamischen und spärlichen Merkmalen nachteilig für die Modellqualität; Andererseits sind solche Frameworks mit vollständig getrennten Phasen für das Batch-Training und das Serving konzipiert, was verhindert, dass das Modell in Echtzeit mit Kundenfeedback interagiert. Diese Probleme veranlassten uns, traditionelle Ansätze zu überdenken und radikal andere Designentscheidungen zu treffen. In diesem Papier stellen wir 1 vor, ein System, das für das Online-Training maßgeschneidert ist. Unser Design wurde von Beobachtungen unserer Anwendungsworkloads und Produktionsumgebung geleitet, die eine deutliche Abkehr von anderen Empfehlungssystemen widerspiegeln. Unsere Beiträge sind vielfältig: Erstens haben wir eine kollisionsfreie Einbettungstabelle mit Optimierungen wie ablaufenden Einbettungen und Frequenzfilterung zur Reduzierung ihres Speicherfußabdrucks erstellt; Zweitens bieten wir eine produktionsreife Online-Trainingsarchitektur mit hoher Fehlertoleranz; Schließlich haben wir bewiesen, dass die Zuverlässigkeit des Systems für das Echtzeitlernen geopfert werden kann. Monolith wurde erfolgreich in das BytePlus Recommend2-Produkt integriert. Monolith 1 EINLEITUNG Das letzte Jahrzehnt hat einen Boom von Empfehlungstechniken getriebenen Unternehmen erlebt. Im Streben nach einer besseren Kundenerfahrung ist die Bereitstellung personalisierter Inhalte für jeden einzelnen Benutzer als Echtzeitantwort ein gemeinsames Ziel dieser Geschäftsanwendungen. Zu diesem Zweck werden Informationen aus der letzten Interaktion eines Benutzers oft als primärer Input für das Training eines Modells verwendet, da dies am besten ein Benutzerporträt darstellt und Vorhersagen über das Interesse und zukünftige Verhalten des Benutzers ermöglicht. Deep Learning hat Empfehlungsmodelle dominiert [ , , , , , ], da die riesige Menge an Benutzerdaten gut zu datengetriebenen neuronalen Modellen passt. Bemühungen, die Leistung von Deep Learning in Empfehlungssystemen auf Unternehmensebene zu nutzen, stoßen jedoch ständig auf Probleme, die sich aus den einzigartigen Merkmalen von Daten ergeben, die aus realem Benutzerverhalten stammen. Diese Daten unterscheiden sich in zweierlei Hinsicht drastisch von denen, die in herkömmlichen Deep-Learning-Problemen wie Sprachmodellierung oder Computer Vision verwendet werden: 5 6 10 12 20 21 (1) Die Merkmale sind meist spärlich, kategorisch und dynamisch veränderlich; (2) Die zugrunde liegende Verteilung der Trainingsdaten ist nicht-stationär, auch bekannt als Konzeptdrift . Solche Unterschiede stellen Forscher und Ingenieure, die an Empfehlungssystemen arbeiten, vor einzigartige Herausforderungen. 1.1 Spärlichkeit und Dynamik Die Daten für Empfehlungen enthalten meist spärliche kategoriale Merkmale, von denen einige mit geringer Häufigkeit vorkommen. Die übliche Praxis, diese in einen hochdimensionalen Einbettungsraum abzubilden, würde eine Reihe von Problemen mit sich bringen: • Im Gegensatz zu Sprachmodellen, bei denen die Anzahl der Wortstücke begrenzt ist, sind die Anzahl der Benutzer und Ranking-Elemente um Größenordnungen größer. Eine derart riesige Einbettungstabelle passt kaum in den Speicher eines einzelnen Hosts; • Noch schlimmer ist, dass die Größe der Einbettungstabelle im Laufe der Zeit voraussichtlich zunehmen wird, wenn mehr Benutzer und Elemente aufgenommen werden, während Frameworks wie [ , ] feste dichte Variablen zur Darstellung der Einbettungstabelle verwenden. 1 17 In der Praxis verwenden viele Systeme Hash-Verfahren mit geringen Kollisionen [ , ], um den Speicherbedarf zu reduzieren und das Wachstum von IDs zu ermöglichen. Dies beruht auf der übermäßig idealistischen Annahme, dass IDs in der Einbettungstabelle gleichmäßig nach Häufigkeit verteilt sind und Kollisionen der Modellqualität nicht schaden. Leider trifft dies für ein reales Empfehlungssystem selten zu, bei dem eine kleine Gruppe von Benutzern oder Elementen eine signifikant höhere Anzahl von Vorkommen hat. Mit dem organischen Wachstum der Einbettungstabellengröße steigt die Wahrscheinlichkeit von Hash-Kollisionen und führt zu einer Verschlechterung der Modellqualität 3 6 . Daher ist es eine natürliche Anforderung für Produktionsmaßstäbliche Empfehlungssysteme, die Kapazität zu haben, so viele Merkmale wie möglich in ihren Parametern zu erfassen, und auch die Fähigkeit zu haben, die Anzahl der Benutzer und Elemente, die sie zu verfolgen versucht, elastisch anzupassen. 1.2 Nicht-stationäre Verteilung Visuelle und sprachliche Muster entwickeln sich kaum über Jahrhunderte, während derselbe Benutzer, der sich für ein Thema interessiert, seine Begeisterung im nächsten Moment ändern kann. Infolgedessen ist die zugrunde liegende Verteilung von Benutzerdaten nicht-stationär, ein Phänomen, das üblicherweise als Konzeptdrift bezeichnet wird. Intuitiv können Informationen aus einer jüngeren Vergangenheit effektiver zur Vorhersage der Änderung des Benutzerverhaltens beitragen. Um die Auswirkungen von Konzeptdrift zu mildern, müssen Serving-Modelle so nah wie möglich am Echtzeitpunkt aus neuem Benutzerfeedback aktualisiert werden, um das neueste Interesse eines Benutzers widerzuspiegeln. Angesichts dieser Unterschiede und in Beobachtung von Problemen, die sich aus unserer Produktion ergeben, haben wir entwickelt, ein großes Empfehlungssystem, um diese Probleme anzugehen. Wir haben umfangreiche Experimente durchgeführt, um unser Design in der Produktionsumgebung zu verifizieren und zu iterieren. Monolith kann Monolith (1) Die volle Ausdruckskraft für spärliche Merkmale durch die Entwicklung einer kollisionsfreien Hash-Tabelle und eines dynamischen Merkmals-Eviction-Mechanismus bereitstellen; (2) Feedback vom Serving zurück an das Training in Echtzeit mit Online-Training schleifen. Gestärkt durch diese architektonischen Kapazitäten übertrifft Monolith durchweg Systeme, die Hash-Tricks mit Kollisionen verwenden, bei ungefähr ähnlichem Speicherverbrauch und erzielt eine branchenführende Online-Serving-AUC, ohne die Rechenleistung unserer Server übermäßig zu belasten. Der Rest des Papiers ist wie folgt gegliedert. Wir erläutern zunächst die Design-Details, wie Monolith bestehende Herausforderungen mit einer kollisionsfreien Hash-Tabelle und Echtzeit-Training in Abschnitt 2 bewältigt. Experimente und Ergebnisse werden in Abschnitt 3 vorgestellt, zusammen mit produktionserprobten Schlussfolgerungen und einigen Diskussionen über Kompromisse zwischen Zeitempfindlichkeit, Zuverlässigkeit und Modellqualität. Abschnitt 4 fasst verwandte Arbeiten zusammen und vergleicht sie mit Monolith. Abschnitt 5 schließt diese Arbeit ab. 2 DESIGN Die Gesamtarchitektur von Monolith folgt im Allgemeinen dem verteilten Worker- arameter erver-Setting von TensorFlow (Abbildung In einer Worker-PS-Architektur werden Maschinen unterschiedliche Rollen zugewiesen; Worker-Maschinen sind für die Durchführung von Berechnungen gemäß dem Graphen verantwortlich, und PS-Maschinen speichern Parameter und aktualisieren diese gemäß den von den Workern berechneten Gradienten. P S 2). Bei Empfehlungsmodellen werden Parameter in zwei Sätze kategorisiert: dicht und spärlich. Dichte Parameter sind Gewichte/Variablen in einem tiefen neuronalen Netz, und spärliche Parameter beziehen sich auf Einbettungstabellen, die spärlichen Merkmalen entsprechen. In unserem Design sind sowohl dichte als auch spärliche Parameter Teil des TensorFlow-Graphen und werden auf den Parameter-Servern gespeichert. Ähnlich wie bei TensorFlows Variable für dichte Parameter haben wir eine Reihe hocheffizienter, kollisionsfreier und flexibler HashTable-Operationen für spärliche Parameter entwickelt. Als Ergänzung zu TensorFlows Einschränkungen, die sich aus der Trennung von Training und Inferenz ergeben, ist das elastisch skalierbare Online-Training von Monolith darauf ausgelegt, Parameter vom Training-PS zum Online-Serving-PS innerhalb kurzer Intervalle effizient zu synchronisieren, wobei die Modellrobustheit durch einen Fehlertoleranzmechanismus gewährleistet wird. 2.1 Hash-Tabelle Ein erstes Prinzip in unserem Design der spärlichen Parameterdarstellung ist es, die Informationen verschiedener IDs nicht in dieselbe feste Einbettung zu quetschen. Die Simulation einer Einbettungstabelle mit dynamischer Größe mit einer Out-of-the-Box TensorFlow-Variable führt unweigerlich zu ID-Kollisionen, die sich verschlimmern, wenn neue IDs eintreffen und die Tabelle wächst. Daher haben wir anstelle des Aufbaus auf Variable eine neue Schlüssel-Wert-HashTable für unsere spärlichen Parameter entwickelt. Unsere HashTable verwendet intern Cuckoo Hashmap [ ], die Einfügeoperationen für neue Schlüssel ohne Kollisionen mit vorhandenen unterstützt. Cuckoo Hashing erzielt im Worst-Case eine Zeitkomplexität von 𝑂 (1) für Lookups und Löschungen und im erwarteten amortisierten Fall eine Zeitkomplexität von 𝑂 (1) für Einfügungen. Wie in Abbildung dargestellt, unterhält sie zwei Tabellen 𝑇0, 𝑇1 mit unterschiedlichen Hash-Funktionen ℎ0 (𝑥), ℎ1 (𝑥), und ein Element wird in einer von beiden gespeichert. Beim Versuch, ein Element 𝐴 in 𝑇0 einzufügen, wird zunächst versucht, 𝐴 bei ℎ0 (𝐴) zu platzieren; Wenn ℎ0 (𝐴) von einem anderen Element 𝐵 belegt ist, wird 𝐵 aus 𝑇0 verdrängt und versucht, 𝐵 in 𝑇1 mit der gleichen Logik einzufügen. Dieser Prozess wird wiederholt, bis sich alle Elemente stabilisiert haben oder ein Rehash stattfindet, wenn die Einfügung in einen Zyklus gerät. 16 3 Die Reduzierung des Speicherfußabdrucks ist ebenfalls ein wichtiger Aspekt unseres Designs. Ein naiver Ansatz, jede neue ID in die HashTable einzufügen, wird den Speicher schnell erschöpfen. Beobachtungen realer Produktionsmodelle führen zu zwei Schlussfolgerungen: (1) IDs, die nur ein paar Mal vorkommen, tragen nur wenig zur Verbesserung der Modellqualität bei. Eine wichtige Beobachtung ist, dass IDs langschwänzig verteilt sind, wobei beliebte IDs Millionen von Malen auftreten können, während die unbeliebten höchstens zehnmal vorkommen. Einbettungen, die diesen seltenen IDs entsprechen, sind aufgrund fehlender Trainingsdaten unterfit, und das Modell kann keine gute Schätzung auf ihrer Grundlage vornehmen. Letztendlich beeinflussen diese IDs das Ergebnis wahrscheinlich nicht, sodass die Modellqualität nicht durch die Entfernung dieser IDs mit geringen Vorkommen beeinträchtigt wird; (2) > Veraltete IDs aus einer fernen Geschichte tragen selten zum aktuellen Modell bei, da viele von ihnen nie besucht werden. Dies kann daran liegen, dass ein Benutzer nicht mehr aktiv ist oder ein Kurzvideo veraltet ist. Das Speichern von Einbettungen für diese IDs kann dem Modell in keiner Weise helfen, außer unseren PS-Speicher vergeblich zu belasten. Basierend auf diesen Beobachtungen haben wir mehrere Heuristiken für die Filterung von Merkmalen-IDs für eine speichereffizientere Implementierung der HashTable entwickelt: (1) IDs werden gefiltert, bevor sie in Einbettungstabellen aufgenommen werden. Wir haben zwei Filtermethoden: Zuerst filtern wir nach ihren Vorkommen, bevor sie als Schlüssel eingefügt werden, wobei der Schwellenwert für Vorkommen ein einstellbarer Hyperparameter ist, der für jedes Modell variiert; Zusätzlich verwenden wir einen probabilistischen Filter, der zur weiteren Reduzierung der Speichernutzung beiträgt; ![#Abbildung 4: Streaming-Engine. Die Informationsrückkopplungsschleife von [Benutzer → Modell-Server → Trainings-Worker → Modell-Server → Benutzer] würde lange dauern, wenn sie den Batch-Trainingspfad nimmt, während das Online-Training die Schleife sofort schließt.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) IDs werden zeitgesteuert und laufen nach einer vordefinierten Inaktivitätsperiode ab. Die Ablaufzeit ist auch für jede Einbettungstabelle einstellbar, um eine Unterscheidung von Merkmalen mit unterschiedlicher Empfindlichkeit gegenüber historischen Informationen zu ermöglichen. In unserer Implementierung ist HashTable als TensorFlow-Ressourcenoperation implementiert. Ähnlich wie bei Variable sind Lookups und Updates auch als native TensorFlow-Operationen implementiert, um die Integration zu erleichtern und die Kompatibilität zu verbessern. 2.2 Online-Training In Monolith ist das Training in zwei Phasen unterteilt (Abbildung 1): (1) Batch-Trainingsphase. Diese Phase funktioniert als gewöhnliche TensorFlow-Trainingsschleife: In jedem Trainingsschritt liest ein Trainings-Worker einen Mini-Batch von Trainingsbeispielen aus dem Speicher, fordert Parameter vom PS an, berechnet einen Vorwärts- und Rückwärtsdurchlauf und sendet schließlich aktualisierte Parameter an das Trainings-PS. Etwas anders als bei anderen gängigen Deep-Learning-Aufgaben trainieren wir unseren Datensatz nur für einen Durchlauf. Batch-Training ist nützlich für das Training historischer Daten, wenn wir unsere Modellarchitektur ändern und das Modell neu trainieren; (2) Online-Trainingsphase. Nachdem ein Modell für das Online-Serving bereitgestellt wurde, stoppt das Training nicht, sondern geht in die Online-Trainingsphase über. Anstatt Mini-Batch-Beispiele aus dem Speicher zu lesen, verarbeitet ein Trainings-Worker Echtzeitdaten "on the fly" und aktualisiert das Trainings-PS. Das Trainings-PS synchronisiert seine Parameter periodisch mit dem Serving-PS, was sich sofort auf der Benutzerseite auswirkt. Dies ermöglicht es unserem Modell, in Echtzeit interaktiv auf das Feedback eines Benutzers zu reagieren. Monolith ist mit der Fähigkeit ausgestattet, nahtlos zwischen Batch- und Online-Training zu wechseln. Dies wird durch unser Design der Streaming-Engine ermöglicht, wie in Abbildung dargestellt. 2.2.1 Streaming-Engine. 4 In unserem Design verwenden wir eine Kafka [ ] Warteschlange, um Benutzeraktionen (z. B. Klick auf ein Element oder Gefällt mir für ein Element usw.) zu protokollieren, und eine weitere Kafka-Warteschlange für Merkmale. Im Kern der Engine steht ein Flink [ ] Streaming-Job für den Online-Feature-Joiner. Der Online-Joiner verknüpft Merkmale mit Labels aus Benutzeraktionen und erstellt Trainingsbeispiele, die dann in eine Kafka-Warteschlange geschrieben werden. Die Warteschlange für Trainingsbeispiele wird sowohl vom Online- als auch vom Batch-Training konsumiert: 13 4 Für das Online-Training liest der Trainings-Worker Daten direkt aus der Kafka-Warteschlange; Für das Batch-Training speichert ein Daten-Dumping-Job zuerst Daten in HDFS [ ]; Nachdem sich die Daten in HDFS bis zu einem bestimmten Betrag angesammelt haben, holt der Trainings-Worker die Daten aus HDFS und führt das Batch-Training durch. 18 Aktualisierte Parameter im Trainings-PS werden gemäß dem Parametersynchronisationsplan an den Serving-PS gesendet. In realen Anwendungen werden Benutzeraktionsprotokolle und Merkmale in den Online-Joiner gestreamt (Abbildung ohne Garantie für die zeitliche Reihenfolge. Daher verwenden wir einen eindeutigen Schlüssel für jede Anfrage, damit Benutzeraktion und Merkmale korrekt zusammengepaart werden können. 2.2.2 Online-Joiner. 5) Die Verzögerung von Benutzeraktionen kann ebenfalls ein Problem darstellen. Zum Beispiel kann es einige Tage dauern, bis ein Benutzer ein Element kauft, das ihm vor Tagen präsentiert wurde. Dies ist eine Herausforderung für den Joiner, denn wenn alle Merkmale im Cache aufbewahrt werden, passt er einfach nicht in den Speicher. In unserem System wird ein On-Disk-Schlüssel-Wert-Speicher verwendet, um Merkmale zu speichern, die über einen bestimmten Zeitraum hinaus warten. Wenn ein Benutzeraktionsprotokoll eintrifft, durchsucht es zuerst den In-Memory-Cache und dann den Schlüssel-Wert-Speicher, falls der Cache fehlt. Ein weiteres Problem, das in realen Anwendungen auftritt, ist, dass die Verteilung von negativen und positiven Beispielen sehr ungleichmäßig ist, wobei die Anzahl der ersteren um Größenordnungen höher sein kann als die letzteren. Um zu verhindern, dass positive Beispiele von negativen überwältigt werden, ist eine gängige Strategie das Negative Sampling. Dies verändert sicherlich die zugrunde liegende Verteilung des trainierten Modells und neigt zu einer höheren Wahrscheinlichkeit positiver Vorhersagen. Als Abhilfe wenden wir während des Servings eine Log-Odds-Korrektur [ ] an, um sicherzustellen, dass das Online-Modell ein unverzerrter Schätzer der ursprünglichen Verteilung ist. 19 Während des Online-Trainings empfängt der Monolith-Trainingscluster kontinuierlich Daten vom Online-Serving-Modul und aktualisiert Parameter auf dem Trainings-PS. Ein entscheidender Schritt, damit der Online-Serving-PS von diesen neu trainierten Parametern profitieren kann, ist die Synchronisation der aktualisierten Modellparameter. In der Produktionsumgebung stehen wir vor mehreren Herausforderungen: 2.2.3 Parametersynchronisation. Modelle auf dem Online-Serving-PS dürfen beim Aktualisieren nicht aufhören zu serven. Unsere Modelle in der Produktion sind normalerweise mehrere Terabyte groß, und infolgedessen dauert der Austausch aller Parameter eine Weile. Es wäre unerträglich, einen Online-PS während des Austauschprozesses vom Serven des Modells zu stoppen, und Updates müssen "on the fly" erfolgen; Die Übertragung eines Multi-Terabyte-Modells in seiner Gesamtheit vom Trainings-PS zum Online-Serving-PS würde sowohl die Netzwerkauslastung als auch den Speicher auf dem PS stark belasten, da sie doppelt so viel Speichermodellgröße erfordert, um das neu ankommende Modell aufzunehmen. Damit das Online-Training an die Größe unseres Geschäftsszenarios angepasst werden kann, haben wir einen inkrementellen, "on-the-fly" durchgeführten, periodischen Parametersynchronisationsmechanismus in Monolith entwickelt, der auf mehreren bemerkenswerten Merkmalen unserer Modelle basiert: (1) Spärliche Parameter dominieren die Größe von Empfehlungsmodellen; (2) Innerhalb eines kurzen Zeitfensters werden nur wenige IDs trainiert und ihre Einbettungen aktualisiert; (3) Dichte Variablen bewegen sich viel langsamer als spärliche Einbettungen. Dies liegt daran, dass bei momentum-basierten Optimierern die Anhäufung von Momentum für dichte Variablen durch die riesige Größe der Empfehlungstrainingsdaten verstärkt wird, während nur wenige spärliche Einbettungen in einem einzelnen Datenbatch aktualisiert werden. (1) und (2) ermöglichen es uns, die spärlichen Aktualisierungen über alle Feature-IDs hinweg zu nutzen. In Monolith pflegen wir eine Hash-Menge berührter Schlüssel, die IDs repräsentiert, deren Einbettungen seit der letzten Parametersynchronisation trainiert wurden. Wir senden die Teilmenge der spärlichen Parameter, deren Schlüssel im "touched-keys"-Set enthalten sind, in einem minutengenauen Zeitintervall vom Trainings-PS an den Online-Serving-PS. Dieses relativ kleine Paket inkrementeller Parameteraktualisierungen ist leicht für die Netzwerkübertragung und verursacht während der Synchronisation keinen starken Speicheranstieg. Wir nutzen auch (3) aus, um die Netzwerk-I/O und den Speicherverbrauch weiter zu reduzieren, indem wir einen aggressiveren Synchronisationsplan für spärliche Parameter festlegen, während dichte Parameter seltener aktualisiert werden. Dies kann uns in eine Situation bringen, in der die von uns servierten dichten Parameter im Vergleich zum spärlichen Teil eine relativ veraltete Version darstellen. Diese Inkonsistenz kann jedoch toleriert werden, da aus dem in (3) genannten Grund kein auffälliger Verlust beobachtet wurde. 2.3 Fehlertoleranz Als System in der Produktion ist Monolith so konzipiert, dass es einen PS im Falle eines Ausfalls wiederherstellen kann. Eine gängige Wahl für Fehlertoleranz ist das periodische Schnappschussieren des Zustands eines Modells und die Wiederherstellung aus dem neuesten Schnappschuss, wenn ein PS-Ausfall erkannt wird. Die Wahl der Schnappschussfrequenz hat zwei Hauptauswirkungen: (1) Modellqualität. Intuitiv leidet die Modellqualität weniger unter dem Verlust der jüngsten Geschichte bei erhöhter Schnappschussfrequenz. (2) Rechenaufwand. Das Schnappschussieren eines Multi-Terabyte-Modells ist nicht kostenlos. Es verursacht große Kopiervorgänge im Speicher und Festplatten-I/O. Als Kompromiss zwischen Modellqualität und Rechenaufwand macht Monolith täglich Schnappschüsse aller Trainings-PS. Obwohl ein PS im Falle eines Ausfalls einen Tag an Updates verliert, stellen wir durch unsere Experimente fest, dass der Leistungsabfall tolerierbar ist. Wir werden die Auswirkungen der PS-Zuverlässigkeit im nächsten Abschnitt analysieren. 3 BEWERTUNG Um die Vorteile und Kompromisse unseres vorgeschlagenen Designs besser zu verstehen, haben wir mehrere Experimente im Produktionsmaßstab und A/B-Tests mit Live-Serving-Traffic durchgeführt, um Monolith aus verschiedenen Blickwinkeln zu bewerten und zu verifizieren. Wir wollen folgende Fragen mit unseren Experimenten beantworten: (1) Wie sehr können wir von einer kollisionsfreien HashTable profitieren? (2) Wie wichtig ist Echtzeit-Online-Training? (3) Ist das Design der Parametersynchronisation von Monolith in einem großen Produktionsszenario robust genug? In diesem Abschnitt präsentieren wir zunächst unsere experimentellen Einstellungen und diskutieren anschließend detailliert die Ergebnisse und unsere Erkenntnisse. 3.1 Experimentelle Einrichtung Wie in Abschnitt beschrieben, sind Einbettungstabellen in Monolith als kollisionsfreie HashTables implementiert. Um die Notwendigkeit der Vermeidung von Kollisionen in Einbettungstabellen zu beweisen und die Gewinne unserer kollisionsfreien Implementierung zu quantifizieren, haben wir zwei Experimentengruppen auf dem Movielens-Datensatz und auf unserem internen Produktionsdatensatz durchgeführt: 3.1.1 Einbettungstabelle. 2.1 (1) ml-25m-Datensatz [ ]. Dies ist ein Standard-öffentlicher Datensatz für Filmbewertungen, der 25 Millionen Bewertungen von etwa 162.000 Benutzern und 62.000 Filmen enthält. MovieLens 11 • . Die ursprünglichen Labels sind Bewertungen von 0,5 bis 5,0, während in der Produktion unsere Aufgaben meist binäre Signale von Benutzern erhalten. Um unsere Produktionsmodelle besser zu simulieren, wandeln wir Skalen-Labels in binäre Labels um, indem wir Bewertungen ≥ 3,5 als positive Beispiele und den Rest als negative Beispiele behandeln. • Modell und Metriken. Wir implementierten ein Standard-DeepFM-Modell, eine häufig verwendete Modellarchitektur für Empfehlungsprobleme. Es besteht aus einer FM-Komponente und einer dichten Komponente (Abbildung 6). Vorhersagen werden von AUC bewertet, da dies die Hauptmessung für reale Modelle ist. • Einbettungskollisionen. Dieser Datensatz enthält etwa 160.000 Benutzer-IDs und 60.000 Film-IDs. Um mit der kollisionsfreien Version der Einbettungstabellenimplementierung zu vergleichen, führten wir eine weitere Experimentengruppe durch, bei der IDs mit MD5-Hashing vorverarbeitet und dann auf einen kleineren ID-Raum abgebildet wurden. Als Ergebnis teilen sich einige IDs ihre Einbettung mit anderen. Tabelle 1 zeigt detaillierte Statistiken der Benutzer- und Film-IDs vor und nach dem Hashing. Vorverarbeitung der Labels (2) . Interner Empfehlungsdatensatz Wir führten auch Experimente mit einem Empfehlungsmodell in einer Produktionsumgebung durch. Dieses Modell folgt im Allgemeinen einer Multi-Tower-Architektur, wobei jeder Tower für das Erlernen der Vorhersage einer spezialisierten Art von Benutzerverhalten verantwortlich ist. Jedes Modell hat etwa 1000 Einbettungstabellen, und die Verteilung der Einbettungstabellengrößen ist sehr ungleichmäßig; Der ursprüngliche ID-Raum der Einbettungstabelle betrug 248. In unserer Baseline wandten wir einen Hashing-Trick an, indem wir ihn zerlegten, um die Größe der Einbettungstabelle zu begrenzen. Um genauer zu sein, verwenden wir zwei kleinere Einbettungstabellen anstelle einer gigantischen, um eine eindeutige Einbettung für jede ID durch Vektorkombination zu erzeugen: wobei 𝐸𝑟 , 𝐸𝑞 Einbettungen sind, die 𝐼𝐷𝑟 , 𝐼𝐷𝑞 entsprechen. Dies reduziert effektiv die Einbettungstabellengrößen von 248 auf 225; • Dieses Modell wird in der realen Produktion eingesetzt, und die Leistung dieses Experiments wird anhand der Online-AUC mit echtem Serving-Traffic gemessen. Beim Online-Training aktualisieren wir unsere Online-Serving-PS mit dem neuesten Satz von Parametern in minutengenauen Intervallen. Wir haben zwei Experimentengruppen entworfen, um die Modellqualität und die Systemrobustheit zu überprüfen. 3.1.2 Online-Training. (1) . Um die Notwendigkeit einer minutengenauen Aktualisierungsfrequenz zu untersuchen, haben wir Experimente durchgeführt, bei denen Parameter vom Trainingsmodell zum Vorhersagemodell mit unterschiedlichen Intervallen synchronisiert werden. Aktualisierungsfrequenz Der von uns verwendete Datensatz ist der Criteo Display Ads Challenge-Datensatz3, ein groß angelegter Standarddatensatz für das Benchmarking von CTR-Modellen. Er enthält 7 Tage chronologisch geordneter Daten, die Merkmale und Klickaktionen aufzeichnen. Für dieses Experiment verwenden wir ein Standard-DeepFM-Modell , wie in beschrieben. 6 Um das Online-Training zu simulieren, haben wir die folgenden Vorverarbeitungen für den Datensatz vorgenommen. Wir nehmen 7 Tage Daten aus dem Datensatz und teilen sie in zwei Teile: 5 Tage Daten für das Batch-Training und 2 Tage für das Online-Training. Wir teilen die 2 Tage Daten weiter in 𝑁 Shards chronologisch auf. Das Online-Training wird durch Algorithmus simuliert. 1 Somit simulieren wir die Synchronisation trainierter Parameter mit dem Online-Serving-PS mit einem Intervall, das durch die Anzahl der Daten-Shards bestimmt wird. Wir haben mit 𝑁 = 10, 50, 100 experimentiert, was ungefähr Aktualisierungsintervallen von 5 Stunden, 1 Stunde und 30 Minuten entspricht. (2) . Darüber hinaus haben wir ein Live-Experiment mit echtem Serving-Traffic durchgeführt, um die Bedeutung des Online-Trainings in realen Anwendungen weiter zu demonstrieren. Dieses A/B-Experiment vergleicht das Online-Training mit dem Batch-Training eines unserer Anzeigenmodelle in der Produktion. Live-Experiment 3.2 Ergebnisse und Analyse Die Ergebnisse sowohl vom MovieLens-Datensatz als auch vom internen Empfehlungsdatensatz zeigen, dass Einbettungskollisionen die Modellqualität beeinträchtigen. 3.2.1 Die Auswirkung von Einbettungskollisionen. (1) Modelle mit kollisionsfreier HashTable übertreffen durchweg diejenigen mit Kollisionen. Diese Schlussfolgerung gilt unabhängig davon, Erhöhung der Anzahl der Trainingsepochen. Wie in Abbildung gezeigt, hat das Modell mit kollisionsfreier Einbettungstabelle von der ersten Epoche an eine höhere AUC und konvergiert zu einem höheren Wert; 7 Änderung der Verteilung im Laufe der Zeit aufgrund von Konzeptdrift. Wie in Abbildung gezeigt, ist das Modell mit kollisionsfreier Einbettungstabelle 8