Innerhalb von ByteDance's Monolith: Die Engine für intelligentere, schnellere Inhaltsfeeds

```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 von zeitkritischem Kundenfeedback angetrieben werden, wie z. B. die Rangfolge von Kurzvideos oder Online-Werbung, von entscheidender Bedeutung. Trotz der allgegenwärtigen Einführung von Produktions-Deep-Learning-Frameworks wie TensorFlow oder PyTorch erfüllen diese Allzweck-Frameworks aus verschiedenen Gründen nicht die Geschäftsanforderungen in Empfehlungsszenarien: Einerseits ist das Anpassen von Systemen anhand 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 Stufen für das Batch-Training und die Bereitstellung konzipiert, was verhindert, dass das Modell in Echtzeit mit Kundenfeedback interagiert. Diese Probleme führten uns dazu, traditionelle Ansätze neu 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 durch Beobachtungen unserer Anwendungs-Workloads und Produktionsumgebung vorangetrieben, 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; Drittens haben wir bewiesen, dass die Systemzuverlässigkeit für Echtzeit-Lernen eingetauscht werden kann. Monolith wurde erfolgreich in das BytePlus Recommend2-Produkt integriert. Monolith 1 EINLEITUNG Das letzte Jahrzehnt war Zeuge eines Booms von Unternehmen, die auf Empfehlungstechniken basieren. 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 neuesten Interaktion eines Benutzers oft als primäre Eingabe für das Training eines Modells verwendet, da sie ein Benutzerprofil am besten abbilden und Vorhersagen über die Interessen und zukünftigen Verhaltensweisen des Benutzers treffen. Deep Learning hat Empfehlungsmodelle dominiert [ , , , , , ], da die riesige Menge an Benutzerdaten gut zu massiv datengesteuerten neuronalen Modellen passt. Die 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 drastisch von denen, die in herkömmlichen Deep-Learning-Problemen wie Sprachmodellierung oder Computer Vision verwendet werden, in zweierlei Hinsicht: 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 Concept Drift [8]. Solche Unterschiede stellen einzigartige Herausforderungen für Forscher und Ingenieure dar, die an Empfehlungssystemen arbeiten. 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 einem hochdimensionalen Einbettungsraum zuzuordnen, würde eine Reihe von Problemen aufwerfen: • Im Gegensatz zu Sprachmodellen, bei denen die Anzahl der Wortteile begrenzt ist, ist die Anzahl der Benutzer und Ranglistenartikel um Größenordnungen größer. Eine solch riesige Einbettungstabelle würde kaum in den Speicher eines einzelnen Hosts passen; • Schlimmer noch, die Größe der Einbettungstabelle wird voraussichtlich im Laufe der Zeit zunehmen, wenn mehr Benutzer und Artikel 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 in der Häufigkeit verteilt sind und Kollisionen der Modellqualität nicht schaden. Leider ist dies bei realen Empfehlungssystemen, bei denen eine kleine Gruppe von Benutzern oder Artikeln deutlich mehr Vorkommen hat, selten der Fall. Mit dem organischen Wachstum der Einbettungstabellengröße nimmt die Wahrscheinlichkeit von Hash-Kollisionen zu und führt 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 Benutzer und Artikel, die sie buchen wollen, elastisch anzupassen. 1.2 NICHT-STATIONÄRE VERTEILUNG Visuelle und sprachliche Muster entwickeln sich kaum im Zeitmaßstab von Jahrhunderten, während derselbe Benutzer, der an einem Thema interessiert ist, seine Begeisterung in der nächsten Minute ändern könnte. Infolgedessen ist die zugrunde liegende Verteilung der Benutzerdaten nicht-stationär, ein Phänomen, das allgemein als Concept Drift bezeichnet wird. [8] Intuitiv können Informationen aus einer jüngeren Vergangenheit effektiver zur Vorhersage des Wandels im Verhalten eines Benutzers beitragen. Um die Auswirkungen von Concept Drift abzumildern, müssen Bereitstellungsmodelle so nah wie möglich am Echtzeit-Zeitpunkt anhand neuer Benutzerfeedbacks aktualisiert werden, um das neueste Interesse eines Benutzers widerzuspiegeln. Angesichts dieser Unterschiede und angesichts der Probleme, die sich aus unserer Produktion ergeben, haben wir entwickelt, ein groß angelegtes Empfehlungssystem, um diese Schwachstellen anzugehen. 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 von der Bereitstellung zurück ins Training in Echtzeit mit Online-Training zu schleifen. Gestärkt durch diese architektonischen Kapazitäten übertrifft Monolith durchweg Systeme, die Hash-Tricks mit Kollisionen verwenden, bei annähernd gleichem Speicherbedarf und erreicht eine hochmoderne Online-Serving-AUC, ohne die Rechenleistung unserer Server übermäßig zu belasten. Der Rest des Papiers ist wie folgt organisiert. Zunächst erläutern wir die Design-Details, wie Monolith bestehende Herausforderungen mit kollisionsfreien Hash-Tabellen 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 Ausführung von Berechnungen gemäß der Definition des Graphen verantwortlich, 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 TensorFlows Variable 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 Trainings-PS auf Online-Serving-PS in kurzen Intervallen effizient zu synchronisieren, wobei die Modellrobustheit durch einen Fehlertoleranzmechanismus gewährleistet wird. 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 Einbettungstabelle dynamischer Größe mit einer Out-of-the-Box TensorFlow-Variable führt unweigerlich zu ID-Kollisionen, die zunehmen, wenn neue IDs ankommen und die Tabelle wächst. Daher haben wir anstatt auf Variable aufzubauen, eine neue Schlüssel-Wert-HashTable für unsere spärlichen Parameter entwickelt. Unsere HashTable verwendet intern Cuckoo Hashmap [ ], die eine 𝑂 (1)-Zeitkomplexität für Lookups und Löschungen im Worst-Case und eine erwartete amortisierte 𝑂 (1)-Zeit für Einfügungen unterstützt. Wie in Abbildung dargestellt, werden zwei Tabellen 𝑇0, 𝑇1 mit unterschiedlichen Hash-Funktionen ℎ0 (𝑥), ℎ1 (𝑥) beibehalten, und ein Element wird in einer von beiden gespeichert. Beim Versuch, ein Element 16 3 𝐴 in 𝑇0 einzufügen, wird zunächst versucht, 𝐴 an ℎ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 Vorgang wird wiederholt, bis sich alle Elemente stabilisiert haben oder ein Rehash erfolgt, wenn die Einfügung in einem Zyklus endet. Die Reduzierung des Speicherbedarfs ist ebenfalls ein wichtiger Gesichtspunkt in unserem Design. Ein naiver Ansatz, jede neue ID in die HashTable einzufügen, wird den Speicher schnell aufbrauchen. Die Beobachtung realer Produktionsmodelle führte zu zwei Schlussfolgerungen: (1) IDs, die nur wenige Male vorkommen, tragen nur wenig zur Verbesserung der Modellqualität bei. Eine wichtige Beobachtung ist, dass IDs lang-schwänzig verteilt sind, wobei beliebte IDs Millionen Mal vorkommen können, während die unpopulären nicht mehr als zehn Mal vorkommen. Einbettungen, die diesen seltenen IDs entsprechen, sind aufgrund mangelnder Trainingsdaten unterangepasst, und das Modell kann auf ihrer Grundlage keine gute Schätzung vornehmen. Letztendlich ist es unwahrscheinlich, dass sich diese IDs auf das Ergebnis auswirken, sodass die Modellqualität durch die Entfernung dieser IDs mit geringen Vorkommen nicht beeinträchtigt wird; (2) Veraltete IDs aus einer fernen Vergangenheit tragen selten zum aktuellen Modell bei, da viele von ihnen nie besucht werden. Dies könnte 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 heuristische Filter für Merkmals-IDs für eine speichereffizientere Implementierung der HashTable entwickelt: (1) IDs werden gefiltert, bevor sie in Einbettungstabellen aufgenommen werden. Wir haben zwei Filtermethoden: Erstens filtern wir nach ihrer Häufigkeit, bevor sie als Schlüssel eingefügt werden, wobei der Schwellenwert für die Häufigkeiten ein einstellbarer 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 → Modellserver → Trainings-Worker → Modellserver → 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 zeitlich markiert und nach einer vordefinierten Zeit der Inaktivität zum Ablaufen gebracht. Die Ablaufzeit ist ebenfalls für jede Einbettungstabelle einstellbar, um die Unterscheidung von Merkmalen mit unterschiedlicher Sensibilität gegenüber historischen Informationen zu ermöglichen. In unserer Implementierung ist die HashTable als TensorFlow-Ressourcenoperation implementiert. Ähnlich wie bei Variable werden 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 wie eine gewöhnliche 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ärtspass 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. Das Batch-Training ist nützlich für das Training von historischen Daten, wenn wir unsere Modellarchitektur ändern und das Modell neu trainieren; (2) Online-Trainingsphase. Nachdem ein Modell für die Online-Bereitstellung eingesetzt 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 im laufenden Betrieb und aktualisiert das Trainings-PS. Das Trainings-PS synchronisiert seine Parameter periodisch mit dem Bereitstellungs-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. Klick auf einen Artikel oder Like eines Artikels 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-Training 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 [ ] dumpen; Nachdem sich Daten in HDFS in gewissem Umfang 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 Bereitstellungs-PS gesendet. In realen Anwendungen werden Benutzeraktionsprotokolle und Merkmale ohne Garantie der zeitlichen Reihenfolge in den Online-Joiner (Abbildung gestreamt. Daher verwenden wir einen eindeutigen Schlüssel für jede Anfrage, damit Benutzeraktion und Merkmale korrekt zugeordnet werden können. 2.2.2 Online Joiner. 5) Die Verzögerung von Benutzeraktionen kann ebenfalls ein Problem sein. Beispielsweise 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 Festplatten-Schlüssel-Wert-Speicher verwendet, um Merkmale zu speichern, die über einen bestimmten Zeitraum warten. Wenn ein Benutzeraktionsprotokoll ankommt, sucht es zuerst im In-Memory-Cache und dann im Schlüssel-Wert-Speicher, falls im Cache etwas fehlt. Ein weiteres Problem, das in der Praxis 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 übliche Strategie das negative Sampling. Dies verändert zweifellos 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 der Bereitstellung 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-Bereitstellungsmodul und aktualisiert Parameter auf dem Trainings-PS. Ein entscheidender Schritt, um dem Online-Bereitstellungs-PS die Nutzung dieser neu trainierten Parameter zu ermöglichen, ist die Synchronisation aktualisierter Modellparameter. In einer Produktionsumgebung stehen wir vor mehreren Herausforderungen: 2.2.3 Parametersynchronisation. Modelle auf dem Online-Bereitstellungs-PS dürfen beim Aktualisieren nicht aufhören zu bedienen. Unsere Modelle in der Produktion sind normalerweise mehrere Terabyte groß, und dementsprechend dauert das Ersetzen aller Parameter eine Weile. Es wäre inakzeptabel, einen Online-PS vom Modell-Serving während des Austauschprozesses zu stoppen, und Updates müssen im laufenden Betrieb erfolgen; Das Übertragen eines Multi-Terabyte-Modells in seiner Gesamtheit vom Trainings-PS zum Online-Bereitstellungs-PS würde sowohl die Netzwerkbandbreite als auch den Speicher auf dem PS enorm belasten, da dies doppelte Modellgröße an Speicher erfordert, um das neu ankommende Modell zu akzeptieren. Damit das Online-Training an die Größe unseres Geschäftsszenarios angepasst werden kann, haben wir in Monolith einen inkrementellen, laufenden, periodischen Parametersynchronisationsmechanismus 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 Aktualisierungen über alle Merkmals-IDs hinweg zu nutzen. In Monolith pflegen wir eine Hash-Menge von berührten Schlüsseln, die IDs repräsentiert, deren Einbettungen seit der letzten Parametersynchronisation trainiert wurden. Wir senden die Teilmenge spärlicher Parameter, deren Schlüssel im Set der berührten Schlüssel enthalten sind, in einem Zeitintervall von Minuten vom Trainings-PS an den Online-Bereitstellungs-PS. Dieses relativ kleine Paket inkrementeller Parameteraktualisierungen ist leicht für die Netzwerkübertragung und verursacht keinen starken Speicheranstieg während der Synchronisation. Wir nutzen auch (3), um den 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 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 aufgrund des in (3) genannten Grundes toleriert werden, da keine auffälligen Verluste beobachtet wurden. 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 die periodische Erstellung von Snapshots des Modellzustands und die Wiederherstellung aus dem letzten Snapshot, wenn ein PS-Ausfall 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 jüngster Verläufe; (2) Rechenaufwand. Das Erstellen eines Snapshots eines Multi-Terabyte-Modells ist nicht kostenlos. Es verursacht große Speicher-Kopien 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 der Aktualisierungen verliert, stellen wir durch unsere Experimente fest, dass die Leistungsverschlechterung tolerierbar ist. 3 BEWERTUNG Um die Vorteile und Kompromisse unseres Designvorschlags 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 die folgenden Fragen mit unseren Experimenten beantworten: (1) Wie viel können wir von einer kollisionsfreien HashTable profitieren? (2) Wie wichtig ist Echtzeit-Online-Training? (3) Ist das Design der Parametersynchronisation von Monolith in einer groß angelegten Produktionsumgebung robust genug? In diesem Abschnitt präsentieren wir zunächst unsere experimentellen Einstellungen und diskutieren dann detailliert die Ergebnisse und unsere Erkenntnisse. 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 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 mit ungefähr 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 in der Produktion unsere Aufgaben hauptsächlich darin bestehen, binäre Signale von Benutzern zu 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 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 anhand von 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 Einbettungstabellenimplementierung zu vergleichen, haben wir eine weitere Experimentengruppe durchgeführt, bei der IDs mit MD5-Hashing vorverarbeitet und dann auf einen kleineren ID-Raum abgebildet wurden. Infolgedessen werden einige IDs ihre Einbettung mit anderen teilen. Tabelle 1 zeigt detaillierte Statistiken von Benutzer- und Film-IDs vor und nach dem Hashing. (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 eines spezialisierten Benutzertyps verantwortlich ist. Jedes Modell hat ungefähr 1000 Einbettungstabellen, und die Verteilung der Einbettungstabellengrößen ist sehr unausgewogen; 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 reduzieren. Genauer gesagt verwenden wir zwei kleinere Einbettungstabellen anstelle einer riesigen, 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 echten 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 Satz von Parametern in Intervallen von Minuten. Wir haben zwei Experimentengruppen entwickelt, um die Modellqualität und Systemrobustheit zu überprüfen. 3.1.2 Online-Training. (1) . Um die Notwendigkeit einer Update-Frequenz im Minutenbereich zu untersuchen, haben wir Experimente durchgeführt, bei denen Parameter vom Trainingsmodell zum Vorhersagemodell mit unterschiedlichen Intervallen 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 geordnete 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 auf: 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 Update-Intervallen 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 für eines unserer Werbemodelle in der Produktion. Live-Experiment 3.2 ERGEBNISSE UND ANALYSE Die Ergebnisse des MovieLens-Datensatzes und des internen Empfehlungsdatensatzes zeigen beide, 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 Concept Drift. Wie in Abbildung gezeigt, ist das Modell mit kollisionsfreier Einbettung 8