Innerhalb von ByteDances Monolith: Die Engine, die intelligentere, schnellere Content-Feeds antreibt

```html 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 Unternehmen, die auf zeitkritischem Kundenfeedback basieren, wie z. B. die Rangfolge von Kurzvideos oder Online-Werbung, unerlässlich. Trotz der allgegenwärtigen Einführung von Produktions-Deep-Learning-Frameworks wie TensorFlow oder PyTorch reichen diese Allzweck-Frameworks aus verschiedenen Gründen nicht aus, um den Geschäftsanforderungen in Empfehlungsszenarien gerecht zu werden: Einerseits ist das Tweakieren von Systemen auf Basis 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 führten uns dazu, 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 Anwendungs-Workloads 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 entwickelt, um ihren Speicherbedarf zu reduzieren; zweitens bieten wir eine produktionsreife Online-Trainingsarchitektur mit hoher Fehlertoleranz; schließlich haben wir bewiesen, dass die Systemzuverlässigkeit für das Echtzeit-Lernen eingetauscht werden kann. Monolith wurde erfolgreich in das Produkt BytePlus Recommend2 integriert. Monolith 1 EINLEITUNG Das letzte Jahrzehnt war Zeuge eines Booms von Unternehmen, die auf Empfehlungstechniken setzen. Um ein besseres Kundenerlebnis zu erzielen, 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 neuesten Interaktion eines Benutzers oft als primäre Eingabe für das Training eines Modells verwendet, da sie das Porträt eines Benutzers am besten abbilden und Benutzerinteressen und zukünftiges Verhalten vorhersagen können. Deep Learning dominiert Empfehlungsmodelle [ , , , , , ], da die gigantische Menge an Benutzerdaten gut zu massiv datengesteuerten neuronalen Modellen passt. Bemühungen, die Leistungsfähigkeit von Deep Learning in industriellen Empfehlungssystemen zu nutzen, stoßen jedoch ständig auf Probleme, die sich aus den einzigartigen Merkmalen von Daten ergeben, die aus dem realen 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 überwiegend spärlich, kategorisch und dynamisch; (2) Die zugrunde liegende Verteilung der Trainingsdaten ist nicht-stationär, auch bekannt als Concept Drift [8]. Solche Unterschiede stellen Forscher und Ingenieure, die an Empfehlungssystemen arbeiten, vor einzigartige Herausforderungen. 1.1 SPARSITY UND DYNAMIK Die Daten für Empfehlungen enthalten meist spärliche kategorische Merkmale, von denen einige mit geringer Häufigkeit vorkommen. Die übliche Praxis, sie einer hochdimensionalen Einbettungsraum zuzuordnen, führt zu einer Reihe von Problemen: • Im Gegensatz zu Sprachmodellen, bei denen die Anzahl der Wortteile begrenzt ist, sind die Anzahl der Benutzer und Ranglisten-Elemente um Größenordnungen größer. Eine solch riesige Einbettungstabelle passt kaum in den Speicher eines einzelnen Hosts; • Schlimmer noch, die Größe der Einbettungstabelle wird voraussichtlich im Laufe der Zeit wachsen, da 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 geringer Kollision [ , ], 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 in der Häufigkeit verteilt sind und Kollisionen dem Modell nicht schaden. Leider ist dies in realen Empfehlungssystemen, in denen eine kleine Gruppe von Benutzern oder Elementen signifikant mehr Vorkommen aufweist, selten der Fall. Mit dem organischen Wachstum der Einbettungstabellengröße nehmen die Wahrscheinlichkeiten für Hash-Kollisionen zu und führen zu einer Verschlechterung der Modellqualität 3 6 [3]. Daher ist es eine natürliche Anforderung für produktionsreife 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 zu verwaltenden Benutzer und Elemente elastisch anzupassen. 1.2 NICHT-STATIONÄRE VERTEILUNG Visuelle und sprachliche Muster entwickeln sich kaum über Jahrhunderte, während derselbe Benutzer, der an einem Thema interessiert ist, seine Begeisterung im nächsten Moment ändern könnte. Infolgedessen ist die zugrunde liegende Verteilung von Benutzerdaten nicht-stationär, ein Phänomen, das üblicherweise als Concept Drift bezeichnet wird. [8] Intuitiv kann die Information aus einer jüngeren Vergangenheit effektiver zur Vorhersage der Verhaltensänderung eines Benutzers beitragen. Um die Auswirkungen des Concept Drift zu mildern, müssen Serving-Modelle so nah wie möglich an Echtzeit aus neuem Benutzerfeedback aktualisiert werden, um das neueste Interesse eines Benutzers widerzuspiegeln. Angesichts dieser Unterschiede und unter Berücksichtigung der Probleme, die sich aus unserer Produktion ergeben, haben wir entwickelt, ein groß angelegtes Empfehlungssystem, um diese Schmerzpunkte anzugehen. Wir haben umfangreiche Experimente durchgeführt, um unser Design in der Produktionsumgebung zu verifizieren und zu iterieren. Monolith ist in der Lage Monolith (1) Vollständige Ausdruckskraft für spärliche Merkmale durch Design einer kollisionsfreien Hash-Tabelle und eines dynamischen Feature-Evictions-Mechanismus bereitzustellen; (2) Das Feedback des Servings in Echtzeit mit Online-Training zurück in das Training zu schleifen. Gestärkt durch diese architektonischen Kapazitäten übertrifft Monolith durchweg Systeme, die Hash-Tricks mit Kollisionen verwenden, bei annähernd gleichem Speicherverbrauch und erzielt State-of-the-Art Online-Serving-AUC, ohne die Rechenleistung unserer Server übermäßig zu belasten. Der Rest des Papiers ist wie folgt organisiert. Zuerst elaborieren wir 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 zusammen mit produktionserprobten Schlussfolgerungen und einigen Diskussionen über Kompromisse zwischen Zeitabhängigkeit, Zuverlässigkeit und Modellqualität präsentiert. 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 unterschiedlichen Rollen zugewiesen; Worker-Maschinen sind für die Durchführung von Berechnungen gemäß der Definition des Graphen verantwortlich, und PS-Maschinen speichern Parameter und aktualisieren diese gemäß den von den Workern berechneten Gradienten. P S 2). In 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 den TensorFlow-Variablen für dichte Parameter haben wir eine Reihe von hocheffizienten, kollisionsfreien und flexiblen HashTable-Operationen für spärliche Parameter entwickelt. Als Ergänzung zu den Einschränkungen von TensorFlow, die sich aus der Trennung von Training und Inferenz ergeben, ist das elastisch skalierbare Online-Training von Monolith darauf ausgelegt, Parameter von Training-PS zu Online-Serving-PS innerhalb kurzer Intervalle effizient zu synchronisieren, wobei die Modellrobustheit durch einen Fehlertoleranzmechanismus gewährleistet ist. 2.1 HASH-TABELLE Ein Grundprinzip unseres Designs für die Darstellung spärlicher Parameter ist es, die Informationen verschiedener IDs nicht in dieselbe feste Einbettung zu quetschen. Die Simulation einer dynamisch großen Einbettungstabelle mit einer sofort einsatzbereiten TensorFlow-Variable führt unweigerlich zu ID-Kollisionen, die zunehmen, wenn neue IDs eintreffen und die Tabelle wächst. Daher haben wir statt auf Variablen aufzubauen eine neue Schlüssel-Wert-HashTable für unsere spärlichen Parameter entwickelt. Unsere HashTable verwendet intern Cuckoo Hashmap [ ], die das Einfügen neuer Schlüssel ohne Kollision mit vorhandenen unterstützt. Cuckoo Hashing erreicht eine Worst-Case-Zeitkomplexität von 𝑂 (1) für Lookups und Löschungen und eine erwartete amortisierte Zeit von 𝑂 (1) für Einfügungen. Wie in Abbildung gezeigt, unterhält sie zwei Tabellen 𝑇0, 𝑇1 mit unterschiedlichen Hash-Funktionen ℎ0 (𝑥), ℎ1 (𝑥), und ein Element wird in einer davon gespeichert. Beim Versuch, ein Element 16 3 𝐴 in 𝑇0 einzufügen, wird zuerst versucht, 𝐴 bei ℎ0 (𝐴) zu platzieren; Wenn ℎ0 (𝐴) von einem anderen Element 𝐵 belegt ist, wird 𝐵 aus 𝑇0 verdrängt und versucht, 𝐵 mit derselben Logik in 𝑇1 einzufügen. Dieser Prozess wird wiederholt, bis alle Elemente stabil sind oder ein Rehashing stattfindet, wenn die Einfügung in einem Zyklus endet. Die Reduzierung des Speicherbedarfs 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, haben einen begrenzten Beitrag zur Verbesserung der Modellqualität. Eine wichtige Beobachtung ist, dass IDs langschwänzig verteilt sind, wobei populäre IDs millionenfach vorkommen können, während die unbeliebten höchstens zehnmal vorkommen. Einbettungen, die diesen seltenen IDs entsprechen, sind aufgrund mangelnder Trainingsdaten unterangepasst, und das Modell kann keine gute Schätzung auf ihrer Grundlage vornehmen. Am Ende des Tages beeinflussen diese IDs das Ergebnis wahrscheinlich nicht, so dass die Modellqualität nicht unter der Entfernung dieser IDs mit geringen Vorkommen leidet; (2) Veraltete IDs aus ferner Vergangenheit tragen selten zum aktuellen Modell bei, da sie oft nicht besucht werden. Dies könnte möglicherweise auf einen nicht mehr aktiven Benutzer oder ein Kurzvideo zurückzuführen sein, das veraltet ist. Das Speichern von Einbettungen für diese IDs kann dem Modell in keiner Weise helfen, außer den PS-Speicher vergeblich zu erschöpfen. Basierend auf diesen Beobachtungen haben wir mehrere heuristische Filter für Feature-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 die Schwelle der Vorkommen ein abstimmbarer Hyperparameter ist, der für jedes Modell variiert; Zusätzlich verwenden wir einen probabilistischen Filter, der hilft, den Speicherverbrauch weiter zu reduzieren; ![#Abbildung 4: Streaming Engine. Die Informationsfeedback-Schleife von [Benutzer → Model Server → Training Worker → Model 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 zeitgestempelt und verfallen nach einer vordefinierten Inaktivitätszeit. Die Ablaufzeit ist ebenfalls für jede Einbettungstabelle abstimmbar, um Merkmale mit unterschiedlicher Empfindlichkeit gegenüber historischen Informationen unterscheiden zu können. In unserer Implementierung ist die HashTable als TensorFlow-Ressourcenoperation implementiert. Ähnlich wie bei Variablen werden Lookups und Updates ebenfalls 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 normale 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 einen Rückwärtsdurchlauf und sendet schließlich aktualisierte Parameter an den Trainings-PS. Etwas anders als bei anderen gängigen Deep-Learning-Aufgaben trainieren wir unseren Datensatz nur für einen Durchlauf. Das 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, endet 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 den Trainings-PS. Der Trainings-PS synchronisiert seine Parameter periodisch mit dem Serving-PS, was sich sofort auf der Benutzerseite auswirkt. Dies ermöglicht es unserem Modell, sich in Echtzeit interaktiv an das Feedback eines Benutzers anzupassen. 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-Angabe für ein Element usw.) zu protokollieren, und eine weitere Kafka-Warteschlange für Merkmale. Im Kern der Engine befindet sich ein Flink [ ]-Streaming-Job für den Online-Feature-Joiner. Der Online-Joiner verknüpft Merkmale mit Labels aus Benutzeraktionen und erzeugt 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 direkt Daten aus der Kafka-Warteschlange; Für das Batch-Training wird ein Daten-Dumping-Job zuerst Daten nach HDFS [ ] schreiben; Nachdem sich Daten in HDFS in einer bestimmten Menge angesammelt haben, ruft der Trainings-Worker Daten aus HDFS ab 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 (Abbildung ohne Garantie der zeitlichen Reihenfolge gestreamt. Daher verwenden wir einen eindeutigen Schlüssel für jede Anfrage, damit Benutzeraktionen und Merkmale korrekt zugeordnet werden können. 2.2.2 Online-Joiner. 5) Die Verzögerung von Benutzeraktionen kann ebenfalls ein Problem darstellen. Zum Beispiel kann ein Benutzer einige Tage brauchen, bevor er sich entscheidet, einen Artikel zu kaufen, der ihm vor Tagen präsentiert wurde. Dies ist eine Herausforderung für den Joiner, denn wenn alle Merkmale im Cache gespeichert werden, passt er einfach nicht in den Speicher. In unserem System wird ein On-Disk Key-Value-Speicher verwendet, um Merkmale zu speichern, die über einen bestimmten Zeitraum hinaus warten. Wenn ein Benutzeraktionsprotokoll ankommt, sucht es zuerst im In-Memory-Cache und dann im Key-Value-Speicher, falls der Cache fehlt. Ein weiteres Problem, das in der Praxis auftritt, ist, dass die Verteilung von negativen und positiven Beispielen sehr unausgeglichen ist, wobei die Anzahl der ersteren um Größenordnungen höher sein kann als die der letzteren. Um zu verhindern, dass positive Beispiele von negativen überwältigt werden, ist eine übliche Strategie das negative Sampling. Dies würde die zugrunde liegende Verteilung des trainierten Modells sicherlich verändern und es auf eine höhere Wahrscheinlichkeit positiver Vorhersagen ausrichten. 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 weiterhin Daten vom Online-Serving-Modul und aktualisiert Parameter auf dem Trainings-PS. Ein entscheidender Schritt, um dem Online-Serving-PS von diesen neu trainierten Parametern profitieren zu lassen, ist die Synchronisation der aktualisierten Modellparameter. In der Produktionsumgebung sind wir mit mehreren Herausforderungen konfrontiert: 2.2.3 Parametersynchronisation. Modelle auf dem Online-Serving-PS dürfen beim Aktualisieren nicht aufhören zu servieren. Unsere Modelle in der Produktion sind normalerweise mehrere Terabyte groß, und folglich dauert der Austausch aller Parameter eine Weile. Es wäre unerträglich, einen Online-PS während des Austauschvorgangs vom Modell-Serving abzuhalten, 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 Netzwerkbandbreite als auch den Speicher auf dem PS stark beanspruchen, da für die Aufnahme des neu ankommenden Modells die doppelte Modellgröße an Speicher benötigt wird. Damit das Online-Training für die Größe unseres Geschäftsszenarios skaliert, haben wir einen inkrementellen "on-the-fly" 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 gigantische Größe der Empfehlungs-Trainingsdaten verstärkt wird, während nur wenige spärliche Einbettungen in einem einzelnen Daten-Batch aktualisiert werden. (1) und (2) ermöglichen es uns, die spärlichen Updates über alle Feature-IDs hinweg zu nutzen. In Monolith pflegen wir eine Hash-Menge berührter Schlüssel, die IDs repräsentieren, deren Einbettungen seit der letzten Parametersynchronisation trainiert wurden. Wir senden die Teilmenge der spärlichen Parameter, deren Schlüssel sich in der Menge der berührten Schlüssel befinden, mit einem Zeitintervall von Minuten vom Trainings-PS zum Online-Serving-PS. Dieses relativ kleine Paket inkrementeller Parameter-Updates ist leicht für die Netzwerkübertragung und verursacht beim Synchronisieren keinen starken Speicheranstieg. Wir nutzen auch (3), 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 weniger häufig aktualisiert werden. Dies kann zu einer Situation führen, in der die von uns ausgelieferten dichten Parameter eine relativ veraltete Version im Vergleich zum spärlichen Teil sind. Diese Inkonsistenz kann jedoch toleriert werden, aus dem in (3) genannten Grund, da 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 die Fehlertoleranz ist das periodische Snapshotting des Zustands eines Modells und die Wiederherstellung aus dem neuesten Snapshot, wenn ein PS-Ausfall erkannt wird. Die Wahl der Snapshot-Häufigkeit hat zwei wesentliche Auswirkungen: (1) Modellqualität. Intuitiv leidet die Modellqualität mit zunehmender Snapshot-Häufigkeit weniger unter dem Verlust der jüngsten Historie. (2) Rechenaufwand. Das Snapshotting eines Multi-Terabyte-Modells ist nicht kostenlos. Es verursacht große Datenkopien und Festplatten-I/O. Als Kompromiss zwischen Modellqualität und Rechenaufwand erstellt Monolith täglich Snapshots aller Trainings-PS. Obwohl ein PS im Falle eines Ausfalls einen Tag an Updates verliert, stellen wir durch unsere Experimente fest, dass die Leistungsverschlechterung 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 durchgeführt und A/B-Tests mit Live-Serving-Traffic durchgeführt, um Monolith aus verschiedenen Blickwinkeln zu bewerten und zu verifizieren. Wir wollen mit unseren Experimenten die folgenden Fragen 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ß angelegten Produktionsszenario robust genug? In diesem Abschnitt präsentieren wir zunächst unsere experimentellen Einstellungen und diskutieren anschließend die Ergebnisse und unsere Erkenntnisse im Detail. 3.1 EXPERIMENTELLER AUFBAU 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 Experimentalgruppen auf dem Movielens-Datensatz und auf unserem internen Produktionsdatensatz durchgeführt: 3.1.1 Einbettungstabelle. 2.1 (1) ml-25m Datensatz [ ]. Dies ist ein standardmäßiger öffentlicher Datensatz für Filmbewertungen, der 25 Millionen Bewertungen mit etwa 162.000 Benutzern und 62.000 Filmen enthält. MovieLens 11 • . Die ursprünglichen Labels sind Bewertungen von Vorverarbeitung von Labels 0,5 bis 5,0, während wir in der Produktion hauptsächlich binäre Signale von Benutzern erhalten. Um unsere Produktionsmodelle besser zu simulieren, konvertieren wir skalierte Labels in binäre Labels, indem wir Bewertungen ≥ 3,5 als positive Stichproben und den Rest als negative Stichproben behandeln. • Modell und Metriken. Wir haben ein Standard-DeepFM-Modell [ ] implementiert, ein häufig verwendetes Modellarchitektur für Empfehlungsprobleme. Es besteht aus einer FM-Komponente und einer dichten Komponente (Abbildung 6). Vorhersagen werden mit AUC [2] bewertet, da dies die wichtigste Messung für reale Modelle ist. • Einbettungskollisionen. Dieser Datensatz enthält etwa 160.000 Benutzer-IDs und 60.000 Film-IDs. Um die kollisionsfreie Version der Einbettungstabellen-Implementierung zu vergleichen, haben wir eine weitere Experimentalgruppe durchgeführt, bei der IDs mit MD5-Hashing vorverarbeitet und dann auf einen kleineren ID-Raum abgebildet wurden. Infolgedessen teilen sich einige IDs ihre Einbettung mit anderen. Tabelle 1 zeigt detaillierte Statistiken der Benutzer- und Film-IDs vor und nach dem Hashing. 9 (2) . Interner Empfehlungsdatensatz Wir haben auch Experimente mit einem Empfehlungsmodell in einer Produktionsumgebung durchgeführt. 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 unausgeglichen; Der ursprüngliche ID-Raum der Einbettungstabelle betrug 248. In unserer Basisversion haben wir einen Hashing-Trick angewendet, indem wir zerlegt haben, um die Größe der Einbettungstabelle zu begrenzen. Genauer gesagt, 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 durch die Online-AUC mit echtem Serving-Traffic gemessen. Während des Online-Trainings aktualisieren wir unsere Online-Serving-PS mit dem neuesten Parametersatz in Intervallen von Minuten. Wir haben zwei Experimentalgruppen entwickelt, um die Modellqualität und die Systemrobustheit zu überprüfen. 3.1.2 Online-Training. (1) . Um die Notwendigkeit der Aktualisierungshäufigkeit im Minutenbereich zu untersuchen, haben wir Experimente durchgeführt, bei denen Parameter mit unterschiedlichen Intervallen vom Trainingsmodell zum Vorhersagemodell synchronisiert werden. Aktualisierungshäufigkeit 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. 9 6 Um das Online-Training zu simulieren, haben wir die folgende Vorverarbeitung für den Datensatz durchgeführt. 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 experimentierten mit 𝑁 = 10, 50, 100, was ungefähr Update-Intervallen von 5 Stunden, 1 Stunde und 30 Minuten entspricht. (2) . Zusätzlich 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 Online-Training mit Batch-Training für eines unserer Anzeigenmodelle in der Produktion. Live-Experiment 3.2 ERGEBNISSE UND ANALYSE Ergebnisse sowohl vom MovieLens-Datensatz als auch vom internen Empfehlungsdatensatz zeigen, dass Einbettungskollisionen die Modellqualität beeinträchtigen. 3.2.1 Der Effekt von Einbettungskollisionen. (1) Modelle mit kollisionsfreier HashTable übertreffen durchweg die 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 einen höheren AUC und konvergiert bei einem höheren Wert; 7 Änderung der Verteilung im Laufe der Zeit aufgrund von Concept Drift. Wie in Abbildung gezeigt, ist das Modell mit kollisionsfreier Einbettungstabelle auch über die Zeit stabil 8