Inside ByteDance’s Monolith: Die Maschine, die intelligentere, schnellere Inhaltsfeeds 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 von zeitsensiblen Kundenrückmeldungen abhängige Unternehmen, wie z. B. das Ranking von Kurzvideos oder Online-Werbung, von entscheidender Bedeutung. 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 die Geschäftsanforderungen in Empfehlungsszenarien zu erfüllen: Einerseits ist die Anpassung 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 einer vollständig getrennten Stapel-Trainings- und Servingsphase 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 Abweichung 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 Echtzeit-Lernen geopfert werden kann. Monolith ist erfolgreich im Produkt BytePlus Recommend2 gelandet. Monolith 1 EINLEITUNG Das vergangene Jahrzehnt hat einen Boom von Unternehmen erlebt, die auf Empfehlungstechniken setzen. Um ein besseres Kundenerlebnis zu bieten, ist die Bereitstellung personalisierter Inhalte für jeden einzelnen Benutzer als Echtzeit-Antwort 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 sie das Benutzerprofil am besten abbilden und das Interesse und zukünftige Verhalten des Benutzers vorhersagen. Deep Learning hat Empfehlungsmodelle dominiert [ , , , , , ], 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 Nutzerverhalten stammen. Diese Daten unterscheiden sich in zweierlei Hinsicht drastisch von denen, die in konventionellen 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; (2) Die zugrunde liegende Verteilung der Trainingsdaten ist nicht-stationär, auch bekannt als Konzeptdrift [8]. Diese Unterschiede stellen Forscher und Ingenieure, die an Empfehlungssystemen arbeiten, vor einzigartige Herausforderungen. 1.1 Sparsity und Dynamik Die Daten für Empfehlungen enthalten hauptsächlich spärliche kategorische Merkmale, von denen einige mit geringer Häufigkeit auftreten. Die übliche Praxis, sie einem 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 Ranking-Elemente um Größenordnungen größer. Eine solch riesige Einbettungstabelle passt kaum in den Speicher eines einzelnen Hosts; • Noch schlimmer ist, dass die Größe der Einbettungstabelle im Laufe der Zeit voraussichtlich zunimmt, 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 die IDs in der Einbettungstabelle gleichmäßig verteilt sind und Kollisionen der Modellqualität nicht schaden. Leider ist dies in einem realen Empfehlungssystem, bei dem eine kleine Gruppe von Benutzern oder Elementen deutlich mehr Vorkommen aufweist, selten der Fall. Mit dem organischen Wachstum der Einbettungstabellengröße nehmen die Wahrscheinlichkeiten von Hash-Schlüsselkollisionen zu und führen zu einer Verschlechterung der Modellqualität 3 6 [3]. Daher ist es eine natürliche Anforderung für Produktions-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 in einer Zeitskala von Jahrhunderten, während derselbe Benutzer, der an einem Thema interessiert ist, 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. [8] Intuitiv können Informationen aus einer jüngeren Geschichte effektiver zur Vorhersage der Veränderung des Benutzerverhaltens beitragen. Um die Auswirkungen des Konzeptdrifts zu mildern, müssen Servicemodelle so schnell wie möglich mit neuem Nutzerfeedback aktualisiert werden, um das neueste Interesse eines Nutzers widerzuspiegeln. Angesichts dieser Unterschiede und der Beobachtung von Problemen, die sich aus unserer Produktion ergeben, haben wir entwickelt, ein groß angelegtes Empfehlungssystem, um diese Schwachstellen zu beheben. Wir haben umfangreiche Experimente durchgeführt, um unser Design in der Produktionsumgebung zu überprüfen und zu iterieren. Monolith ist in der Lage, Monolith (1) Vollständige Ausdruckskraft für spärliche Merkmale durch die Entwicklung einer kollisionsfreien Hash-Tabelle und eines dynamischen Merkmals-Evictions-Mechanismus zu bieten; (2) Feedback vom Serving zurück an das Training in Echtzeit mit Online-Training zu schleifen. Gestärkt durch diese architektonischen Fähigkeiten übertrifft Monolith durchweg Systeme, die Hash-Tricks mit Kollisionen verwenden, bei ungefähr gleichem 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. Zuerst erläutern 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 unterschiedliche Rollen zugewiesen; Worker-Maschinen sind für die Durchführung von Berechnungen verantwortlich, wie sie im Graphen definiert sind, und PS-Maschinen speichern Parameter und aktualisieren sie 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 den Variablen von TensorFlow 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 effizient von Training-PS zu Online-Serving-PS innerhalb kurzer Intervalle zu synchronisieren, wobei die Modellrobustheit durch einen Fehlertoleranzmechanismus gewährleistet wird. 2.1 Hash-Tabelle Ein erstes Prinzip bei unserem Design der spärlichen Parameterdarstellung ist es, die Informationen verschiedener IDs nicht in dieselbe Einbettung mit fester Größe zu zwängen. Das Simulieren einer Einbettungstabelle mit dynamischer Größe mit einer fertigen TensorFlow-Variable führt unweigerlich zu ID-Kollisionen, die sich verschlimmern, wenn neue IDs eintreffen und die Tabelle wächst. Daher haben wir anstelle einer Abhängigkeit von Variablen 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 Schlüsseln unterstützt. Cuckoo Hashing erreicht im schlimmsten Fall eine Zeitkomplexität von O(1) für Lookups und Löschungen und eine erwartete amortisierte Zeit von O(1) für Einfügungen. Wie in Abbildung dargestellt, werden zwei Tabellen T0, T1 mit unterschiedlichen Hash-Funktionen h0(x), h1(x) unterhalten, und ein Element wird in einer davon gespeichert. Beim Versuch, ein Element A in T0 einzufügen, wird zunächst versucht, A bei h0(A) zu platzieren; Wenn h0(A) von einem anderen Element B belegt ist, wird B aus T0 verdrängt und versucht, B mit derselben Logik in T1 einzufügen. Dieser Prozess wird wiederholt, bis alle Elemente stabil sind oder ein Rehash stattfindet, wenn die Einfügung in einen Zyklus gerät. 16 3 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 wenige Male vorkommen, tragen nur begrenzt zur Verbesserung der Modellqualität bei. Eine wichtige Beobachtung ist, dass IDs lang-schwanzverteilt sind, wobei beliebte IDs Millionen von Malen vorkommen können, während die unbeliebten nicht mehr als 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. Letztendlich werden diese IDs das Ergebnis wahrscheinlich nicht beeinflussen, so dass die Modellqualität nicht unter der Entfernung dieser IDs mit geringen Vorkommen leidet; (2) > Stale IDs aus einer fernen Vergangenheit tragen selten zum aktuellen Modell bei, da viele von ihnen nie besucht werden. Dies könnte auf einen nicht mehr aktiven Benutzer oder ein veraltetes Kurzvideo zurückzuführen sein. 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 Filter-Heuristiken für Merkmals-IDs für eine speichereffizientere Implementierung der HashTable entwickelt: (1) IDs werden gefiltert, bevor sie in Einbettungstabellen zugelassen werden. Wir haben zwei Filtermethoden: Zuerst filtern wir nach ihrer Häufigkeit, bevor sie als Schlüssel eingefügt werden, wobei die Schwelle der Häufigkeit 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 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 zeitgestempelt und laufen nach einer vordefinierten Inaktivitätszeit ab. 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 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 Stufen unterteilt (Abbildung 1): (1) Batch-Trainingsphase. Diese Phase funktioniert als normaler TensorFlow-Trainingsschleife: In jedem Trainingsschritt liest ein Trainings-Worker einen Mini-Batch von Trainingsbeispielen aus dem Speicher, fordert Parameter von 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 im Online-Betrieb bereitgestellt wurde, stoppt das Training nicht, sondern wechselt in die Online-Trainingsphase. Anstatt Mini-Batch-Beispiele aus dem Speicher zu lesen, verarbeitet ein Trainings-Worker Echtzeitdaten im laufenden Betrieb 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 an das Feedback eines Benutzers anzupassen. Monolith ist mit der Fähigkeit ausgestattet, nahtlos zwischen Batch-Training 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. Klicken auf ein Element oder Liken eines Elements 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 verkettet 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 speichert ein Daten-Dumping-Job zuerst Daten in HDFS [ ]; Nachdem sich Daten in HDFS angesammelt haben, ruft der Trainings-Worker Daten von HDFS ab und führt das Batch-Training durch. 18 Aktualisierte Parameter im Trainings-PS werden gemäß dem Parametersynchronisationsplan an den Serving-PS weitergeleitet. In realen Anwendungen werden Benutzeraktionsprotokolle und Merkmale ohne garantierte zeitliche Reihenfolge an den Online-Joiner (Abbildung gestreamt. Daher verwenden wir einen eindeutigen Schlüssel für jede Anfrage, damit Benutzeraktion und Merkmale korrekt zusammengefügt werden können. 2.2.2 Online-Joiner. 5) Die Verzögerung von Benutzeraktionen kann ebenfalls ein Problem sein. Zum Beispiel kann es einige Tage dauern, bis ein Benutzer einen Artikel kauft, den 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-Schlüssel-Wert-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 Schlüssel-Wert-Speicher, falls ein 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 der 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 es zu einer höheren Wahrscheinlichkeit, positive Vorhersagen zu treffen. 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, um dem Online-Serving-PS die Nutzung dieser neu trainierten Parameter zu ermöglichen, ist die Synchronisation der aktualisierten Modellparameter. In der Produktionsumgebung sehen wir uns mehreren Herausforderungen gegenüber: 2.2.3 Parametersynchronisation. Modelle auf dem Online-Serving-PS dürfen während der Aktualisierung nicht mit dem Serving aufhören. Unsere Modelle in der Produktion sind normalerweise mehrere Terabyte groß, und daher dauert der Austausch aller Parameter eine Weile. Es wäre unerträglich, einen Online-PS während des Austauschprozesses vom Modell-Serving abzuhalten, und Updates müssen im laufenden Betrieb erfolgen; Die Übertragung eines Multi-Terabyte-Modells in seiner Gesamtheit vom Trainings-PS zum Online-Serving-PS würde sowohl die Netzbandbreite als auch den Speicher auf dem PS enorm belasten, da sie doppelt so viel Modellspeicher benötigt, um das neu ankommende Modell aufzunehmen. Damit das Online-Training auf die Größe unseres Geschäftsszenarios skaliert, haben wir einen inkrementellen On-the-Fly-Mechanismus zur periodischen Parametersynchronisation 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 Akkumulation 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 einzigen 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 darstellen, 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, in einem minütlichen Zeitintervall vom Trainings-PS an den Online-Serving-PS. Dieses relativ kleine Paket inkrementeller Parameter-Updates ist leicht für die Netzwerkübertragung und verursacht keinen starken Speicheranstieg während der Synchronisation. Wir nutzen (3) auch, um den Netzwerk-E/A und den Speicherverbrauch weiter zu reduzieren, indem wir einen aggressiveren Sync-Zeitplan für spärliche Parameter festlegen, während dichte Parameter seltener aktualisiert werden. Dies kann zu einer Situation führen, in der die bereitgestellten dichten Parameter im Vergleich zum spärlichen Teil eine relativ veraltete Version sind. Diese Inkonsistenz kann jedoch toleriert werden, da aus dem in (3) genannten Grund kein auffälliger Verlust beobachtet wurde. 2.3 Fehlertoleranz Als Produktionssystem 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-Fehler erkannt wird. Die Wahl der Snapshot-Frequenz hat zwei wesentliche Auswirkungen: (1) > Modellqualität. Intuitiv leidet die Modellqualität mit zunehmender Snapshot-Frequenz weniger unter dem Verlust der jüngsten Historie. (2) > Rechenaufwand. Das Snapshotting eines Multi-Terabyte-Modells ist nicht kostenlos. Es verursacht große Teile von Speicher kopieren und Festplatten-E/A. Als Kompromiss zwischen Modellqualität und Rechenaufwand erstellt Monolith täglich einen Snapshot aller Trainings-PS. Obwohl ein PS im Falle eines Fehlers einen Tages Update verliert, stellen wir durch unsere Experimente fest, dass die Leistungsverschlechterung tolerierbar ist. Wir werden die Auswirkung 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 die folgenden 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 Parameter-Synchronisationsdesign von Monolith in einem groß angelegten Produktionsszenario robust genug? In diesem Abschnitt präsentieren wir zuerst unsere experimentellen Einstellungen und diskutieren dann detailliert Ergebnisse und unsere Erkenntnisse. 3.1 Experimentelle Einrichtung Wie in Abschnitt beschrieben, werden Einbettungstabellen in Monolith als kollisionsfreie HashTables implementiert. Um die Notwendigkeit zu beweisen, Kollisionen in Einbettungstabellen zu vermeiden, und um die Gewinne aus unserer kollisionsfreien Implementierung zu quantifizieren, führten wir zwei Experimentgruppen auf dem Movielens-Datensatz und auf unserem internen Produktionsdatensatz durch: 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 ungefähr 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 hauptsächlich darin bestehen, binäre Signale von Benutzern zu erhalten. Um unsere Produktionsmodelle besser zu simulieren, wandeln wir Skalenlabels in binäre Labels um, indem wir Bewertungen ≥ 3,5 als positive Stichproben und den Rest als negative Stichproben behandeln. • Modell und Metriken. Wir haben ein Standard-DeepFM-Modell [9] implementiert, eine häufig verwendete Modellarchitektur für Empfehlungsprobleme. Es besteht aus einer FM-Komponente und einer dichten Komponente (Abbildung 6). Vorhersagen werden durch AUC [2] bewertet, da dies die Hauptmessung für reale Modelle ist. • Einbettungskollisionen. Dieser Datensatz enthält ungefähr 160.000 Benutzer-IDs und 60.000 Film-IDs. Um mit der kollisionsfreien Version der Einbettungstabellen-Implementierung zu vergleichen, führten wir eine weitere Experimentgruppe durch, 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 von Benutzer- und Film-IDs vor und nach dem Hashing. Vorverarbeitung von Labels (2) . Interner Empfehlungsdatensatz Wir haben auch Experimente mit einem Empfehlungsmodell in der 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 ungefähr 1000 Einbettungstabellen, und die Verteilung der Größe von Einbettungstabellen ist sehr ungleichmäßig; Der ursprüngliche ID-Raum der Einbettungstabelle betrug 248. In unserer Baseline haben wir einen Hashing-Trick angewendet, indem wir ihn zerlegt haben, um die Größe der Einbettungstabelle zu begrenzen. Genauer gesagt, wir verwenden zwei kleinere Einbettungstabellen anstelle einer gigantischen, um für jede ID durch Vektorkombination eine eindeutige Einbettung zu erzeugen: wobei Er, Eq Einbettungen sind, die zu IDr, IDq gehören. Dies reduziert effektiv die Einbettungstabellengrößen von 248 auf 225; • Dieses Modell wird in der echten Produktion bereitgestellt, 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 Satz von Parametern in minütlichen Intervallen. Wir haben zwei Experimentgruppen entwickelt, um die Modellqualität und die Systemrobustheit zu überprüfen. 3.1.2 Online-Training. (1) . Um die Notwendigkeit einer minütlichen Update-Frequenz zu untersuchen, führten wir Experimente durch, bei denen Parameter mit unterschiedlichen Intervallen vom Trainingsmodell zum Vorhersagemodell synchronisiert werden. Update-Frequenz 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 N 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 N = 10, 50, 100 experimentiert, was ungefähr Update-Intervallen von 5h, 1h und 30min entspricht. (2) . Darüber hinaus führten wir ein Live-Experiment mit echtem Serving-Traffic durch, um die Bedeutung des Online-Trainings in der realen Anwendung weiter zu demonstrieren. Dieses A/B-Experiment vergleicht das Online-Training mit dem Batch-Training eines unserer Ads-Modelle in der Produktion. Live-Experiment 3.2 Ergebnisse und Analyse Die Ergebnisse sowohl des MovieLens-Datensatzes als auch des internen Empfehlungsdatensatzes zeigen, dass Einbettungskollisionen die Modellqualität beeinträchtigen. 3.2.1 Der Effekt der Einbettungskollision. (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 auf einem höheren Wert; 7 Veränderung der Verteilung im Laufe der Zeit aufgrund von Konzeptdrift. Wie in Abbildung gezeigt, ist das Modell mit kollisionsfreier Einbettungstabelle auch im Laufe der Zeit, wenn sich Kontext von Benutzern/Elementen ändert, robust. 8 (2) > Die durch die kollisionsfreie Einbettungstabelle verursachte Daten-Sparsity führt nicht zu einer Modell-Überanpassung. Wie in Abbildung gezeigt, über 7