Code ist verfügbar aufhttps://github.com/tinyclues/group-by-augmentations-model

Motivation

Im SaaS- Geschäftskontext von tinyclues möchten wir die Neigung eines Benutzers modellieren, ein bestimmtes Angebot in Gegenwart seiner mehreren Angebotsattribute zu kaufen. In unserem vorherigen Medium-Blog haben wir erklärt, dass eine Kernfunktion der tinyclues-Plattform darin besteht, Marketingfachleuten ein äußerst flexibles ML-Tool zur Erstellung gezielter Marketingkampagnen bereitzustellen.

Insbesondere ist die Definition eines „Angebots“ sehr weit gefasst und kann verschiedene Produktkategorien, Attribute und Transaktionskontexte umfassen. Es kann sogar in einem Fall funktionieren, in dem überhaupt kein Produktkatalog vorhanden ist.

Um diese Herausforderung zu lösen, haben wir mehrere maschinelle Lernansätze in Betracht gezogen. In diesem Blog tauchen wir tief in eine vollständige Implementierung eines der zuvor besprochenen ML-Designs ein. Hauptsächlich werden wir über die modellinterne Angebotsaggregationsstrategie sprechen. Wir werden auch einige Einblicke in die Modellarchitektur geben und verschiedene Ergebnisse diskutieren. So lass uns anfangen!

Hauptidee

Unsere leitende Intuition ist es, ein Angebot als eine Reihe von Funktionen darzustellen, aus denen es besteht. Was bedeutet das konkret? Nehmen Sie ein Angebot an, das als SQL-Filter über einer Transaktionstabelle (Benutzer-Angebot-Interaktion) definiert ist. Wenn wir also diesen Filter anwenden, erhalten wir alle entsprechenden Angebotszeilen (Instanzen). Als Nächstes erfassen wir für einen gegebenen Satz von Angebotsmerkmalen die Verteilung jedes Angebotsmerkmals (unabhängig von anderen).

In E-Commerce-Datensätzen sind Angebotsmerkmale in der Regel kategorisch und als 1-Hot-Labels codiert. Somit sind die resultierenden Beutel gewichtete Multi-Hot-Merkmale, die als spärliche Vektoren codiert sind. Beachten Sie, dass wir optional die relativen Zeilengewichtungen ändern können, indem wir den jüngsten Ereignissen mehr Bedeutung beimessen. Zur Inferenzzeit empfängt ein trainiertes Modell diese Multi-Hot-Bags-of-Attributes-Features als Eingabe (zusammen mit anderen Features), um eine Vorhersage für ein ausgewähltes Angebot zu generieren.

Es stellt sich jedoch heraus, dass das noch nicht genug ist! Wir müssen auch das Trainingsschema ändern, um genaue Vorhersagen zu erhalten, wenn Sie diese Angebotsaggregation verwenden (weil die Modellleistung sonst stark sinken kann). Jetzt erklären wir, wie genau das geht!

Zutaten für die Datenerweiterung

Unter Berücksichtigung der Hauptideen wird unsere Hauptlogik recht einfach: Wir möchten das Inferenzmuster der Merkmalstransformation auch während des Modelltrainings nachahmen. Hauptsächlich sollten wir ursprüngliche, nicht aggregierte Angebotsfunktionen durch ihre Taschen-aggregierten Analoga für alle Trainingschargen ersetzen. In der Machine-Learning-Literatur wird dieser Vorgang als Datenaugmentation bezeichnet , und wir werden ihn uns jetzt genauer ansehen.

Mini-Batch-Approximation der Angebotsaggregation

Beachten Sie, dass wir für die Schlussfolgerung auf Angebotstaschenstatistiken aus den vollständigen (oder ausreichend gut abgetasteten) Transaktionsdaten zugreifen können. Für das Training neuronaler Netze kann es jedoch praktisch sein, eine Mini-Batch-basierte Annäherung zu haben, um Erweiterungen im laufenden Betrieb zu erstellen.

Glücklicherweise haben wir für das Training unserer Modelle bereits eine ausreichend große Stapelgröße (~10k) verwendet, und wir haben keine größeren Nachteile bei der Verwendung der Ministapelstatistiken in unseren Experimenten festgestellt (auch wenn theoretisch z eine Annäherung fügt mehr Zufälligkeit hinzu und ist bei seltenen Angeboten möglicherweise nicht genau).

Ok, wie generiert man eine Mini-Batch-Erweiterung? Lassen Sie uns einige zufällige Angebotsattribute auswählen (es können eines oder mehrere sein), sagen wir Marke und Größe . Das erhaltene Tupel ( Marke, Größe ) wird als Schlüssel bezeichnet , und eine Komponente, die diese Auswahl durchführt, heißt KeyGenerator. Als Nächstes modifizieren wir für jede Zeile i ∈ MiniBatch den Wert eines Angebotsmerkmals F durch eine Menge von Werten, die aus allen Minibatch-Zeilen genommen werden, die denselben Schlüssel teilen. Das resultierende Merkmal Grp(F) hat eine variable Länge, wenn F kategorial ist. Da dies einer gewöhnlichen SQL-Operation ähnelt, taufen wir es auch group-by :

Für einen bestimmten Mini-Batch generieren wir nb_augmentations (typischerweise 5 … 10) gruppierte, erweiterte Batches.

# input: batch (dict: feature_name -> tensor)
# params: offer_features, average_key_length, nb_augmentations
# output: [batch_a1, batch_a2, ... , batch_an] (augmented batches)

def KeyGenerator(batch, offer_features, average_key_length):
    """
    Generate group-by key from offer attributes
    """
  ...

def GroupBy(feature_tensor, group_by_key):  # in TF 2.*
    unique_values, unique_idx = tf.unique(group_by_key)  # unique keys positions
    grouped_ragged = tf.ragged.stack_dynamic_partitions(feature_tensor, unique_idx, len(unique_values))
    return tf.gather(grouped_ragged, unique_idx)  # broadcast to batch size -> a ragged tensor of shape bs x None

output = []
for i in range(nb_augmentations):
    augmented_batch = batch.copy()
    group_key = KeyGenerator(batch, offer_features, average_key_length)  # shape bs x 1
    for feature in offer_features:  # we don't modify other features
        augmented_batch[f'{feature}_grp'] = GroupBy(batch[feature], group_key)
    output.append(augmented_batch)

Also, was ist mit dem Verhalten von KeyGenerator? Viele mögliche Schlüsselexplorationsstrategien könnten verwendet werden. Beispielsweise ist es sinnvoll, die Angebotsschlüssel auszuwählen, die von unseren Kunden auf der Plattform häufiger genutzt werden, mit einer höheren Wahrscheinlichkeit. Wir haben uns jedoch für einen sehr einfachen und nutzungsunabhängigen Ansatz entschieden: Jedes Angebotsmerkmal kann zufällig und unabhängig von anderen mit einer festen Wahrscheinlichkeit ausgewählt werden proba = average_key_length / number_of_offer_features, was eine Binomialverteilung ergibt. Wir setzen normalerweise average_key_length ~ 2. Sobald Schlüsselmerkmale ausgewählt sind, definieren wir eine „Schlüssel“-Spalte als ein Tupel von Schlüsselmerkmalswerten (oder indem wir sie hashen), und als nächstes führen wir darauf basierend eine Gruppierung von Angebotsmerkmalen durch. Wenn ein Angebotsfeature ein Multi-Hot-Feature ist, wenden wir MinHash darauf an (mit zufälligem Seeding für jeden Batch), um zum 1-Hot-Fall zurückzukehren.

Mischung anbieten

Ein grundlegendes KeyGeneratoroben entspricht der ANDVerbindung zwischen mehreren Attributen im Angebots-SQL-Filter. Um den ORDisjunktionsfall (wie pid=”942” OR pid=”661”im obigen Beispiel) zu unterstützen, müssen wir eine zusätzliche Angebotsmischung durchführen. Es gibt viele Möglichkeiten, dies zu tun, aber wir betrachten hier eine einfache Methode, die eine Mini-Batch-Logik beibehält. Insbesondere teilen wir die oben erhaltenen größten Gruppen in kleinere Untergruppen auf, die wir dann zufällig kollidieren, um eine neue Schlüsselspalte zu erstellen. Wir machen es so, dass kollidierte Gruppen 2 bis 6 „reine“ Untergruppen enthalten. Das simuliert die spärliche Mischung verschiedener Angebote mit zufälligen Gewichtungen. Dabei wenden wir diese Kollisionen nur auf einen zufälligen Bruchteil (etwa 50 %) der generierten Schlüssel an.

Beachten Sie, dass es dem Generieren einer zufälligen linearen Kombination von Beispieldarstellungen in klassischen halbüberwachten Methoden wie MixUp sehr ähnlich ist .

Multitasking

Nachdem wir nun herausgefunden haben, wie Batches geändert werden können, um ein beliebiges Angebot darzustellen, füttern wir diese Batches in das ursprüngliche Modell. Natürlich sollte man auch darauf achten, dass ein Modell mit unregelmäßigen Eingaben richtig umgeht. Ein Verlust pro Schritt kann lediglich als Summe der jeweiligen Verluste definiert werden. Und tatsächlich können wir darüber nachdenken, als wäre es nur ein Lernprozess mit mehreren Aufgaben, bei dem jede Auswahl von Gruppierungsschlüsseln einer anderen Aufgabe entspricht. Und das ist ein wichtiger Punkt, da es den Raum für verschiedene Multi-Task-Optimierungsmethoden öffnet.

loss = 0
for i in range(nb_augmentations)
  output_i = Model(augm_batch_i)
  loss += LossFn(output_i, response)

Group-by mit verschmolzener Aggregation

In der Praxis führen wir eine Group-by-Aggregation optimierter durch. Wir wenden zuerst eine Einbettungsschicht auf Angebotsfunktionseingaben an (nur einmal pro Stapel) und führen dann eine Datenaugmentation durch, die mit einer vektoriellen Aggregation (wie dem Mittelwert in der Spalte „Einbetten“ im obigen Beispiel) in einem einzigen Vorgang auf die Angebotseinbettungen verschmolzen wird. Auf diese Weise können wir die Berechnung von Angebotseinbettungen über verschiedene Stapelerweiterungen hinweg teilen und somit speichereffizienter sein.

Natürlich funktioniert dieser Trick möglicherweise nicht für komplexere Aggregationen. Technisch gesehen konnten wir dank On-the-Fly-Group-By mit verschmolzener Aggregation alles innerhalb des Modells selbst implementieren, ohne unsere Trainingsdatenlader überhaupt zu modifizieren. Sehen wir uns nun an, was mit dem Modell passiert!

Elemente des Modelldesigns

Group-by-Datenerweiterung kann mit vielen möglichen ML/DL-Modellen kombiniert werden . Und die auffälligste Leistungssteigerung kommt von der Gruppe allein. Aber auch die Wahl des richtigen Modells kann sehr wichtig sein. Wir möchten daher einige Prinzipien teilen, die wir für unsere Wahl der Modellarchitektur berücksichtigt haben. Nach unseren Erfahrungen ist letzteres typischerweise für etwa 2 % bis 6 % einer relativen metrischen Verbesserung im Vergleich zu einem einfachen Zwei-Türme-Modell verantwortlich (bei Notebooks werden wir einige Ablationstests bereitstellen ) .

Mittelwert- und Varianzextraktion für die Wichtigkeit interner Merkmale

Um die Semantik des Hauptangebots zu erfassen, ist es naheliegend, ein mittleres μ von Einbettungen innerhalb von Gruppen zu extrahieren. Doch neben μ extrahieren wir auch die gruppeninterne Varianz σ der Einbettungen . Bei vielen Datensätzen haben wir klare Vorteile bei der Verwendung von σ in unseren Modellen beobachtet, und die Intuition dahinter ist die folgende: Eine höhere Varianz σ weist auf das potenzielle Vorhandensein von verrauschten Komponenten bei Angebotseinbettungen hin.

Daher kann ein Modell dank σ ihre relative Bedeutung reduzieren (man könnte an eine Art Formel μ / √(1 + σ) Signal über Rauschen denken ), wohingegen ein Modell mit nur μ lernen sollte, nutzlose Angebotskomponenten zusammenzufassen Null (neutraler Vektor), was viel schwieriger wird, wodurch das Modell weniger robust gegenüber der Verallgemeinerung auf unsichtbare Angebote wird.

Um beispielsweise eine bestimmte Marke darzustellen , würde sich ein Modell eher auf die Einbettung von Markenmerkmalen verlassen (deren σ gleich null ist) und kann die Komponente der Größeneinbettung vollständig ignorieren (deren σ normalerweise hoch ist, weil es innerhalb jeder Marke eine Vielzahl von Größen gibt). ).

Anstatt eine genaue Formel für die Wirkung von σ auf μ zu verwenden , entschieden wir uns, sie zu lernen. Daher haben wir ein zusätzliches Subnetzwerk MaskNet eingeführt, das auf μ als punktweise Multiplikation wirkt:

Wir parametrisieren MaskNetals eine Folge von nichtlinearen dichten Schichten (DenseNetwork oder DN) mit einigen spärlichen ( k-WTA ) Verbindungen, die für Multitasking-Lernen geeignet sind.

Beachten Sie, dass man auch andere Statistiken aus Gruppeneinbettungen extrahieren kann, sobald sie konsistent sind, dh mit denen über den gesamten Datensatz konvergieren, wenn eine Stapelgröße wächst. Und um einer moderneren Idee zu folgen, könnte man anstelle von deterministisch extrahierten Statistiken ein Modell vom Typ Selbstaufmerksamkeit als Aggregator verwenden.

Komprimierte funktionsbezogene Interaktionen

Ein weiteres wichtiges Prinzip, das wir in unserer Arbeit identifiziert haben: Jedes Angebots- (und Benutzer-) Feature sollte seinen eigenen einzigen Einbettungsbereich besitzen. Dies ist wichtig, um die maximale Menge an Informationen zu teilen und gleichzeitig die Anzahl der Modellparameter zu reduzieren.

Dies wird jedoch mit einem komplexeren Interaktionsmodul erkauft. Beispielsweise kann es schädlich sein, sich für eine einfache Summe verschiedener eingebetteter Funktionen zu entscheiden (wie Größe und Marke ). Angenommen, das Größenmerkmal bietet eine sehr starke Wechselwirkung. In diesem Fall wird der gemischte Einbettungsraum vollständig von der Größensemantik bestimmt und kann für eine Markendarstellung zu einschränkend sein .

Diese Argumentation führt uns natürlich zu einem funktionsweisen bilinearen Interaktionsmodell , das alle individuellen Benutzer-Angebots-Funktionsinteraktionen erfasst und die Koexistenz verschiedener Einbettungsräume ermöglicht. Hauptsächlich extrahieren wir für alle Paare von Benutzer- u_i- und Angebots -o_j- Features eine skalare Interaktion.

wo die Kerne

Es ist eine angemessene Wahl, wenn es wenige Wechselwirkungen gibt. Aber es wird unpraktisch (aufgrund einer höheren Anzahl von Parametern und teurer Rechenzeit), wenn die Anzahl der Angebots- und Benutzerfunktionen wächst. Um dieses Problem zu lösen, schlagen wir den folgenden Kompromiss vor: Bevor wir die funktionsbezogenen Interaktionen berechnen, kombinieren wir einige Angebotsfunktionen zu einer „Meta“-Funktion.

Somit sieht dieses Stück des Modells (in Einsum- Tensor-Notationen) wie folgt aus:

Dabei steht b für Batch, o für Angebotsfunktionen, m für Meta-Angebotsfunktionen und d für Einbettungsdimensionen. Die Feature-Komprimierungsmatrix ℂ := ℂ(μ, σ) wird (instanzweise) durch einen DN parametrisiert, und MaskNet wirkt nun direkt auf die Meta-Features.

Wir führen eine ähnliche Meta-Komprimierung auch für Benutzerfunktionen durch.

Wir argumentieren, dass diese Merkmalskomprimierung eine gültige Wahl für die Gruppen von hierarchischen Merkmalen ist (wie für ' cat1 ', ' cat2 ', ' pid ', die eine kompatible Semantik teilen), und da eine übliche Anzahl von hierarchischen Gruppen innerhalb von Angebotsmerkmalen eher gering ist , halten wir die Anzahl der Metamerkmale eher niedriger (≤ 5). In einigen Situationen könnte es nützlich sein, eine dünnere Struktur von ℂ zu verlangen (für einen stärkeren Merkmalsauswahleffekt).

Schließlich wenden wir erneut einen DN (mit geluoder tanhnichtlinearer Aktivierung) auf extrahierte Meta-Feature-Interaktionen an, um eine skalare Ausgabe zu erhalten. Für weitere Details (technische Implementierungen, Auswahl von Modell-Hyperparametern, Bewertungen usw.) laden wir den Leser ein, sich diese Notebooks anzusehen , in denen wir unsere Modelle auf öffentlich zugänglichen Movielens- und Rees- Datensätzen reproduzieren.

Trainings zeit

Dank verschmolzener Aggregation und geeigneter Auswahl der Trainingsparameter (wir verdoppeln normalerweise die Anzahl der Epochen für das Group-by-Training) haben wir festgestellt, dass die Gesamttrainingszeiterhöhung aufgrund der Group-by-Augmentation ziemlich akzeptabel ist (im schlimmsten Fall ≤ x3). Im Vergleich zu einer großen Anzahl von Kombinationen von Angebotsattributen lernt das Modell.

Ergebnisse

Wir werden mehrere Ergebnisse unseres Modells mit Group-by-Datenaugmentation auf den intern verfügbaren Datensätzen präsentieren. Group-by-Modelle werden jetzt in der Produktion für die meisten unserer Datensätze verwendet (bei ≥ 100 davon), aber aus Platzgründen werden wir hier nur die typischsten und anschaulichsten Fälle berichten. Wir stellten auch die Notebooks zur Verfügung, die es uns ermöglichten, diese Ergebnisse auf zwei öffentlichen Datensätzen zu reproduzieren.

Auswertung

Unser Kreuzvalidierungsprotokoll besteht aus dem Modelltraining zu historischen Ereignissen (etwa ein Jahr Daten) und der Leistungsbewertung über zwei Wochen nach dem Training. Lassen Sie uns wissen, welche Metrik wir uns ansehen. Für einen gegebenen Gruppierungsschlüssel (sagen wir oben „ Marke “) konzentrieren wir uns zunächst auf die entsprechenden beliebtesten Angebote (dh Suchanfragen wie („Marke“ = X) ). Für ein solches Angebot bewerten wir die Modell- AUC für die binäre Angebotsklassifizierungsaufgabe ( 1 , wenn das Ereignis zu diesem Angebot gehört, andernfalls 0 ).

Schließlich mitteln wir die berechneten AUCs (mit Gewichtung = Angebotshäufigkeit), um wAUC zu erhalten – die Metrik, der wir folgen werden. Wir melden wAUC für eine Teilmenge verfügbarer Angebotsschlüssel. Während das Betrachten der Top-Angebote für den Group-by-Effekt besser geeignet ist (da alle Gruppen viele Elemente enthalten), nehmen wir für Kaltstart-Benchmarks weniger häufige Angebote, deren Anzahl im Bewertungsfenster ~ 20–200 beträgt .

Multi-Task-Modell vs. spezialisierte Mono-Task-Modelle

Um unseren Multi-Task-Ansatz herauszufordern, trainieren wir für jedes ausgewählte Angebotsattribut ein Mono-Task-Modell, das auf das entsprechende Angebotsmerkmal beschränkt ist. Diese spezialisierten Modelle werden ohne Augmentation trainiert, teilen aber die gleiche Architektur (mit Ausnahme der Verwendung von σ , das in diesem Fall Nullen ist).

Hier berichten wir Modelle der wAUC-Leistung für verschiedene Angebotsattribute (Annahme von Angeboten mit ≥ 200 Vorkommen):

Schauen wir uns die Ergebnisse genauer an. Wir stellen einige wichtige Beobachtungen fest:

• Zunächst einmal zeigen Monotask-Modelle erwartungsgemäß starke Ergebnisse bei der Bewertung ihrer entsprechenden Aufgabe, schneiden jedoch bei den anderen typischerweise schlechter ab.

• Das Modell, das Group-by nur in Inferenz mit nur klassischem Training ( ) anbietet, without augmentationshat bei den meisten Aufgaben einen erheblichen Leistungsabfall.

Wir sehen, dass Group-by-trainierte Modelle im Vergleich zu spezialisierten Modellen sehr gut abschneiden, und genau das ist der Haupteffekt, den wir erzielen wollten! Aber darüber hinaus zeigen wir Ihnen im Folgenden einige andere interessante Ergebnisse, die dabei entstanden sind.

Kaltstart-Szenario

Wenn wir uns die wAUC seltener Angebote ansehen (mit einer Anzahl von Vorkommen zwischen 20 und 200), sehen wir, dass unser Multi-Task-Group-by-Modell beginnt, sogar bessere Ergebnisse zu zeigen als spezialisierte Mono-Task-Modelle , was diese Group-by-Modelle beweist kann die Informationen aller verfügbaren Angebotsfunktionen im Kaltstartszenario effektiv nutzen. Beachten Sie auch, dass das Gruppieren-nach-Modell es viel besser nutzt als without augmentationsdas Modell, das auch Zugriff auf alle Angebotsfunktionen hat.

Mischungsexperimente anbieten

Um die Bedeutung der Angebotsmischung bei der Group-by-Datenaugmentation zu validieren, generieren wir künstliche „gemischte“ Themen, indem wir zufällig einen λ- Bruch von Zeilen aus einem Angebot und einen (1 – λ) -Bruch aus dem zweiten Angebot ( λ = 0,5 entspricht ODERAbfrage zwischen den beiden Angeboten).

Wir variieren λ ∈ [0, 1] und folgen der AUC auf dem λ -gemischten Angebot von zwei Modellen: eines trainiert nur mit reinen Gruppen und ein weiteres mit einer zusätzlichen Gruppenmischung. Wir stellen fest, dass beide Modelle für die extremen λ- Werte ähnlich abschneiden. Das kollisionsstimulierte Modell zeigt jedoch in der Mitte ein viel besseres Ergebnis; und wenn zwei Angebote „unähnlicher“ sind, sollte man mit einer größeren Lücke rechnen.

Auf dem Diagramm unten zeigen wir einige typische Verhaltensweisen:

Negative Übertragung

Wir sehen, dass das Lernen einiger Angebotsattribute manchmal zu einem Leistungsabfall für andere führen kann (daher sprechen wir über widersprüchliche Attribute wie shop_id und product_id in Datensatz B ). Dieses Phänomen, das als negativer Transfer bezeichnet wird, ist in der Multitasking-Welt bekannt und wird aktiv untersucht .

Um es zu mildern, können verschiedene Techniken angewendet werden. Hier ist eine Liste mit mehreren Ideen für zukünftige Arbeiten:

1. Eine geführte Schlüsselerkundung (auch bekannt als Curriculum-Lernen );
2. Exploration, die es vermeidet, dieselben oder ähnliche Schlüssel zu nehmen, sondern versucht, komplementäre Angebotsschlüssel (basierend auf ihren gegenseitigen Informationen) für jede Charge zu erstellen;
3. Fokusverlust (wir haben es erfolgreich auf Datensätze mit einer bedeutenden Ungleichheit der Interaktionsstärke von Angebotsmerkmalen angewendet);
4. Eine Gradientenchirurgie für widersprüchliche Aufgaben und eine multitaskingfreundlichere Modellarchitektur .

Qualität der Merkmalsdarstellung

Ein weiterer spürbarer Effekt des Group-by-Trainings ist die Verbesserung der Qualität sowohl der Benutzer- als auch der Angebotseinbettungen. Wir haben eine bessere Leistung von Benutzereinbettungen beobachtet, die auf andere nachgelagerte Aufgaben übertragen wurden. Somit kann die Group-by-Datenaugmentation als effiziente Strategie vor dem Training oder als Hilfsaufgabe für halbüberwachtes Training verwendet werden.

Gruppiert trainierte Angebotseinbettungen (genauer gesagt Angebotsmetamerkmale), die für die (Kos-)Ähnlichkeitssuche verwendet wurden, zeigten ebenfalls relevantere Ergebnisse. Darüber hinaus wurde auch die allgemeine Modellvielfalt (d. h. die Fähigkeit, unterschiedliche Zielgruppen für unterschiedliche Angebote auszuwählen und dabei die gleiche Vorhersagegenauigkeit beizubehalten) erhöht (insbesondere für Kategorien mit niedrigerer Entropie wie cat1 , cat2 oder brand ) .

Die Hauptintuition ist wie folgt: Das Group-by-Training zwingt ein Modell, alle Angebotseinbettungen einzeln und ihre Kombinationen zu verstehen, während ohne Datenaugmentation die Merkmale mit niedrigerer Entropie hauptsächlich als Kompensation für schlecht abgetastete Merkmale mit höherer Entropie dienen. Beachten Sie, dass bis zu einem gewissen Grad ein ähnlicher Effekt mit einem klassischen Maskierungs-/ Drop- Funktionstyp der Datenerweiterung erreicht wird (und das Group-By erfolgreich mit den letzteren Methoden kombiniert werden kann!).

Abschluss

Zum Abschluss haben wir eine neue Art von Datenerweiterungsstrategie namens group-by vorgeschlagen . Diese Strategie ermöglicht es uns, auf Multitasking-Weise Benutzerpräferenzen aus allen Kombinationen von Angebotsattributen zu lernen, wodurch Modelle mit hoher Kapazität erzeugt werden. Und das bei einem akzeptablen Negativtransfer und einer begrenzten Steigerung der Trainingszeit! Darüber hinaus erweisen sich Group-by- trainierte Modelle als leistungsfähig, um die Einbettungsqualität zu verbessern und das Kaltstartproblem anzugehen.

Nicht zuletzt glauben wir, dass die Group-by- Datenerweiterung andere Anwendungen für tabellarische Datensätze finden kann und nicht nur auf das Lernen von Angebot-Benutzer-Interaktionen beschränkt ist.