Inside ByteDances Monolith: Die Technologie hinter intelligenteren, schnelleren 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) ABSTRACT Der Aufbau eines skalierbaren Echtzeit-Empfehlungssystems ist für viele Unternehmen, die auf zeitkritischem Kundenfeedback basieren, wie z. B. 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 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 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 geleitet, die eine deutliche Abkehr von anderen Empfehlungssystemen widerspiegeln. Unsere Beiträge sind vielfältig: Erstens haben wir eine kollisionsfreie Embedding-Tabelle mit Optimierungen wie ablaufenden Embeddings und Frequenzfilterung zur Reduzierung des Speicher-Footprints erstellt; zweitens bieten wir eine produktionsfertige Online-Trainingsarchitektur mit hoher Fehlertoleranz; schließlich haben wir bewiesen, dass die Systemzuverlässigkeit für das Echtzeit-Lernen kompromittiert werden kann. Monolith wurde erfolgreich in das BytePlus Recommend2-Produkt integriert. Monolith 1 EINLEITUNG Das letzte Jahrzehnt hat einen Boom von datengetriebenen Empfehlungstechniken erlebt. Im Streben nach einer besseren Kundenerfahrung ist die Bereitstellung personalisierter Inhalte für jeden einzelnen Benutzer als Echtzeit-Reaktion 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 dies das beste Benutzerprofil darstellt und Vorhersagen über das Interesse und zukünftige Verhalten des Benutzers ermöglicht. Deep Learning dominiert Empfehlungsmodelle [ , , , , , ], da die riesigen Datenmengen der Benutzer gut zu massiv datengesteuerten neuronalen Modellen passen. Die Bemühungen, die Leistungsfähigkeit von Deep Learning in Empfehlungssystemen auf Industriestandard-Niveau 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 stark von denen, die in herkömmlichen Deep-Learning-Problemen wie Sprachmodellierung oder Computer Vision verwendet werden, in zwei Aspekten: 5 6 10 12 20 21 (1) Die Merkmale sind größtenteils spärlich, kategorisch und ändern sich dynamisch; (2) Die zugrunde liegende Verteilung der Trainingsdaten ist nicht-stationär, auch bekannt als Concept Drift . 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 hauptsächlich spärliche kategoriale Merkmale, von denen einige mit geringer Häufigkeit vorkommen. Die übliche Praxis, diese in einen hochdimensionalen Embedding-Raum abzubilden, würde zu einer Reihe von Problemen führen: • 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 solche riesige Embedding-Tabelle passt kaum in den Speicher eines einzelnen Hosts; • Schlimmer noch, die Größe der Embedding-Tabelle wird voraussichtlich im Laufe der Zeit zunehmen, da mehr Benutzer und Elemente aufgenommen werden, während Frameworks wie [ , ] eine feste Anzahl dichter Variablen zur Darstellung der Embedding-Tabelle verwenden. 1 17 In der Praxis verwenden viele Systeme Low-Collision-Hashing [ , ], 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 Embedding-Tabelle gleichmäßig nach Häufigkeit verteilt sind und Kollisionen die Modellqualität nicht beeinträchtigen. Leider ist dies bei einem realen Empfehlungssystem, bei dem eine kleine Gruppe von Benutzern oder Elementen deutlich mehr Vorkommen aufweist, selten der Fall. Mit dem organischen Wachstum der Größe der Embedding-Tabelle nehmen die Chancen auf Hash-Kollisionen zu und führen zu einer Verschlechterung der Modellqualität 3 6 . Daher ist es eine natürliche Anforderung für produktionsskalierte 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 verwalten versuchen, 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 der Benutzerdaten nicht-stationär, ein Phänomen, das allgemein als Concept Drift bezeichnet wird. Intuitiv können Informationen aus einer neueren Geschichte effektiver zur Vorhersage der Änderung des Benutzerverhaltens beitragen. Um die Auswirkungen des Concept Drift zu mildern, müssen Serving-Modelle so nah wie möglich am Echtzeit-Prinzip mit neuem Benutzerfeedback aktualisiert werden, um das neueste Interesse eines Benutzers widerzuspiegeln. Angesichts dieser Unterschiede und der Beobachtung von Problemen, die sich aus unserer Produktion ergeben, haben wir entwickelt, ein großskaliges Empfehlungssystem, um diese Probleme 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) Die volle Ausdruckskraft für spärliche Merkmale durch die Entwicklung einer kollisionsfreien Hash-Tabelle und eines dynamischen Merkmals-Evictions-Mechanismus zu bieten; (2) Das Serving-Feedback in Echtzeit mit Online-Training zurück zum Training zu schleifen. Durch diese architektonischen Fähigkeiten übertrifft Monolith durchweg Systeme, die Hash-Tricks mit Kollisionen verwenden, bei ungefähr ähnlicher Speichernutzung und erzielt eine branchenführende Online-Serving-AUC, ohne die Rechenleistung unserer Server übermäßig zu belasten. Der Rest des Papiers ist wie folgt organisiert. 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 produktionsgetesteten Schlussfolgerungen und einigen Diskussionen über Kompromisse zwischen Zeitempfindlichkeit, 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-Setup von TensorFlow (Abbildung In einer Worker-PS-Architektur werden Maschinen unterschiedlichen Rollen zugewiesen; Worker-Maschinen sind für die Ausführung von Berechnungen gemäß dem 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: dichte und spärliche. Dichte Parameter sind Gewichte/Variablen in einem tiefen neuronalen Netz, und spärliche Parameter beziehen sich auf Embedding-Tabellen, 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 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 wird. 2.1 HASH-TABELLE Ein Grundprinzip unseres Designs für die Darstellung spärlicher Parameter ist es, Informationen von verschiedenen IDs nicht in dasselbe Embedding fester Größe zu zwängen. Die Simulation einer dynamischen Embedding-Tabellengröß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 Variablen eine neue Schlüssel-Wert-HashTable für unsere spärlichen Parameter entwickelt. Unsere HashTable verwendet intern Cuckoo Hashmap [ ], die eine Worst-Case-Zeitkomplexität von 𝑂 (1) für Lookups und Löschungen und eine erwartete amortisierte Zeit von 𝑂 (1) für Einfügungen unterstützt. Wie in Abbildung dargestellt, verwaltet sie zwei Tabellen 𝑇0, 𝑇1 mit unterschiedlichen Hash-Funktionen ℎ0 (𝑥), ℎ1 (𝑥), und ein Element wird in einer von ihnen gespeichert. Beim Versuch, ein Element 16 3 𝐴 in 𝑇0 einzufügen, wird zuerst versucht, 𝐴 an ℎ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 sich alle Elemente stabilisiert haben oder ein Rehash stattfindet, wenn die Einfügung in einen Zyklus gerät. Die Reduzierung des Speicher-Footprints 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 geringfügig zur Verbesserung der Modellqualität bei. Eine wichtige Beobachtung ist, dass IDs langschwänzig verteilt sind, wobei beliebte IDs Millionen von Malen vorkommen können, während die unpopulären höchstens zehnmal vorkommen. Embeddings, die diesen seltenen IDs entsprechen, sind aufgrund von mangelnden Trainingsdaten untertrainiert, und das Modell kann keine gute Schätzung auf ihrer Grundlage vornehmen. Letztendlich ist es unwahrscheinlich, dass diese IDs das Ergebnis beeinflussen, so dass die Modellqualität nicht durch die Entfernung dieser IDs mit geringen Vorkommen beeinträchtigt wird; (2) > Veraltete IDs aus einer entfernten Historie tragen selten zum aktuellen Modell bei, da viele von ihnen nie besucht werden. Dies kann auf einen Benutzer zurückzuführen sein, der nicht mehr aktiv ist, oder auf ein Kurzvideo, das veraltet ist. Das Speichern von Embeddings für diese IDs kann dem Modell in keiner Weise helfen, außer unsere PS-Speicher vergeblich zu belasten. Basierend auf diesen Beobachtungen haben wir mehrere Heuristiken zur Filterung von Merkmalen-IDs für eine speichereffizientere Implementierung der HashTable entwickelt: (1) IDs werden gefiltert, bevor sie in Embedding-Tabellen 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 einstellbarer Hyperparameter ist, der für jedes Modell variiert; Zusätzlich verwenden wir einen probabilistischen Filter, der zur weiteren Reduzierung des Speicherverbrauchs beiträgt; ![#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 schneller schließt.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) IDs werden mit einem Zeitstempel versehen und verfallen nach einer vordefinierten Zeitspanne der Inaktivität. Die Ablaufzeit ist ebenfalls für jede Embedding-Tabelle einstellbar, um eine 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 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 wie eine 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 Rückwärtsdurchlauf und sendet schließlich die aktualisierten 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 von historischen 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 wechselt in die Online-Trainingsphase. 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-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 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 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 die Daten direkt aus der Kafka-Warteschlange; Für das Batch-Training wird ein Daten-Dumping-Job zuerst Daten nach HDFS [ ] entladen; Nachdem sich die Daten in HDFS bis zu einem bestimmten Betrag 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 ohne Garantie in zeitlicher Reihenfolge in den Online-Joiner (Abbildung gestreamt. 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 der Benutzeraktion kann ebenfalls ein Problem sein. Zum Beispiel kann ein Benutzer einige Tage brauchen, bevor er sich entscheidet, einen Artikel zu kaufen, dem er vor Tagen präsentiert wurde. Dies ist eine Herausforderung für den Joiner, denn wenn alle Merkmale im Cache aufbewahrt werden, würde er einfach nicht in den Speicher passen. 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 nach, falls der Cache fehlt. Ein weiteres Problem, das in realen Anwendungen auftritt, ist, dass die Verteilung von negativen und positiven Beispielen sehr unausgewogen 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 sicherlich die zugrunde liegende Verteilung des trainierten Modells ändern und es zu einer höheren Wahrscheinlichkeit positiver Vorhersagen neigen lassen. 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 profitiert, 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 servieren. 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 Servieren 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 das Netzwerkbandbreite als auch den Speicher auf dem PS stark belasten, da der Speicher für die Aufnahme des neu ankommenden Modells die doppelte Modellgröße erfordert. Damit das Online-Training bis zur Größe unseres Geschäftsszenarios skaliert, haben wir in Monolith einen inkrementellen, "on-the-fly" 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 Embeddings aktualisiert; (3) Dichte Variablen bewegen sich viel langsamer als spärliche Embeddings. Dies liegt daran, dass bei momentum-basierten Optimierern die Akkumulation von Momentum für dichte Variablen durch die riesige Größe der Empfehlungs-Trainingsdaten verstärkt wird, während nur wenige spärliche Embeddings in einem einzelnen Datenbatch 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 Embeddings seit der letzten Parametersynchronisation trainiert wurden. Wir senden die Teilmenge spärlicher Parameter, deren Schlüssel sich in der Menge der berührten Schlüssel befinden, in einem Zeitintervall von einer Minute vom Trainings-PS zum Online-Serving-PS. Dieses relativ kleine Paket inkrementeller Parameteraktualisierungen ist für die Netzwerkübertragung leicht und verursacht während der Synchronisation keine starken Speicher-Spitzen. 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 seltener aktualisiert werden. Dies kann zu einer Situation führen, in der die von uns bereitgestellten dichten Parameter eine relativ veraltete Version im Vergleich zum spärlichen Teil darstellen. Solche 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 mit der Fähigkeit konzipiert, einen PS im Falle eines Ausfalls wiederherzustellen. Eine gängige Wahl für die Fehlertoleranz ist es, den Zustand eines Modells periodisch zu snappen und aus dem neuesten Snapshot wiederherzustellen, wenn ein PS-Ausfall erkannt wird. Die Wahl der Snapshot-Frequenz hat zwei wesentliche Auswirkungen: (1) Modellqualität. Intuitiv leidet die Modellqualität bei erhöhter Snapshot-Frequenz weniger unter dem Verlust der jüngsten Historie. (2) Rechen-Overhead. Das Snappen eines Multi-Terabyte-Modells ist nicht kostenlos. Es verursacht große Speicher kopien und Festplatten-I/O. Als Kompromiss zwischen Modellqualität und Rechen-Overhead snappt Monolith alle Training-PS täglich. Obwohl ein PS bei einem Ausfall einen Tag an Updates verlieren wird, stellen wir durch unsere Experimente fest, dass die Leistungsdegradation tolerierbar ist. Wir werden die Auswirkungen der PS-Zuverlässigkeit im nächsten Abschnitt analysieren. 3 BEWERTUNG Um die Vorteile und Kompromisse, die sich aus unserem vorgeschlagenen Design ergeben, 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 stark 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ßskaligen Produktionsszenario robust genug? In diesem Abschnitt präsentieren wir zuerst unsere experimentellen Einstellungen und diskutieren dann detailliert die Ergebnisse und unsere Erkenntnisse. 3.1 EXPERIMENTELLE EINRICHTUNG Wie in Abschnitt beschrieben, werden Embedding-Tabellen in Monolith als kollisionsfreie HashTables implementiert. Um die Notwendigkeit der Vermeidung von Kollisionen in Embedding-Tabellen zu beweisen und die Gewinne unserer kollisionsfreien Implementierung zu quantifizieren, führten wir zwei Experimentgruppen auf dem Movielens-Datensatz und auf unserem internen Produktionsdatensatz durch: 3.1.1 Embedding-Tabelle. 2.1 (1) ml-25m Datensatz [ ]. Dies ist ein Standard-öffentlicher Datensatz für Filmbewertungen, der 25 Millionen Bewertungen enthält, die sich auf etwa 162.000 Benutzer und 62.000 Filme beziehen. MovieLens 11 • . Die ursprünglichen Labels reichen 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 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 nach AUC bewertet, da dies die Hauptmessung für reale Modelle ist. • Embedding-Kollisionen. Dieser Datensatz enthält ungefähr 160.000 Benutzer-IDs und 60.000 Film-IDs. Um mit der kollisionsfreien Version der Embedding-Tabellenimplementierung 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 ihr Embedding mit anderen. Tabelle 1 zeigt detaillierte Statistiken der Benutzer- und Film-IDs vor und nach dem Hashing. (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 dafür verantwortlich ist, das Vorhersagen eines spezialisierten Benutzerverhaltens zu lernen. Jedes Modell hat ungefähr 1000 Embedding-Tabellen, und die Verteilung der Größe der Embedding-Tabellen ist sehr unausgewogen; Der ursprüngliche ID-Raum der Embedding-Tabelle betrug 248. In unserer Baseline wandten wir einen Hashing-Trick an, indem wir die Größe der Embedding-Tabelle durch Zerlegung reduzierten. Genauer gesagt verwenden wir zwei kleinere Embedding-Tabellen anstelle einer gigantischen, um eine eindeutige Einbettung für jede ID durch Vektorkombination zu erzeugen: wobei 𝐸𝑟 , 𝐸𝑞 Embeddings sind, die 𝐼𝐷𝑟 , 𝐼𝐷𝑞 entsprechen. Dies reduziert effektiv die Größe der Embedding-Tabellen von 248 auf 225; • Dieses Modell wird in der realen 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 Intervallen von wenigen Minuten. Wir haben zwei Experimentgruppen entwickelt, um die Modellqualität und Systemrobustheit zu überprüfen. 3.1.2 Online-Training. (1) . Um die Notwendigkeit einer Update-Frequenz von wenigen Minuten 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ßskaliger 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. 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 Auf diese Weise 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 einem Update-Intervall von 5 Stunden, 1 Stunde und 30 Minuten entspricht. (2) . Darüber hinaus führten wir ein Live-Experiment mit echtem Serving-Traffic durch, 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 Ergebnisse sowohl vom MovieLens-Datensatz als auch vom internen Empfehlungsdatensatz zeigen, dass Embedding-Kollisionen die Modellqualität beeinträchtigen. 3.2.1 Die Auswirkung von Embedding-Kollisionen. (1) Modelle mit kollisionsfreier HashTable übertreffen durchweg diejenigen mit Kollisionen. Diese Schlussfolgerung gilt unabhängig von Der Erhöhung der Anzahl der Trainingsepochen. Wie in Abbildung gezeigt, hat das Modell mit kollisionsfreier Embedding-Tabelle von der ersten Epoche an eine höhere AUC und konvergiert bei einem höheren Wert; 7 Der Veränderung der Verteilung im Laufe der Zeit aufgrund von Concept Drift. Wie in Abbildung gezeigt, ist das Modell mit kollisionsfreier Embedding-Tabelle auch über die Zeit stabil und passt sich an ver 8