Wnętrze Monolitu ByteDance: Silnik napędzający mądrzejsze, szybsze kanały treści

Autorzy: 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∗, Uniwersytet Fudan Yijie Zhu, Bytedance Inc. Peng Wu, Bytedance Inc. Ke Wang, Bytedance Inc. Youlong Cheng†, Bytedance Inc. (youlong.cheng@bytedance.com) ABSTRAKT Budowanie skalowalnego systemu rekomendacji w czasie rzeczywistym jest kluczowe dla wielu firm opartych na informacji zwrotnej od klientów, która ma znaczenie w czasie, takich jak ranking krótkich filmów lub reklamy online. Pomimo powszechnego wdrażania produkcyjnych frameworków do głębokiego uczenia, takich jak TensorFlow czy PyTorch, te ogólne frameworki nie spełniają wymagań biznesowych w scenariuszach rekomendacji z różnych powodów: z jednej strony, dostrajanie systemów na podstawie statycznych parametrów i gęstych obliczeń dla rekomendacji z dynamicznymi i rzadkimi cechami jest szkodliwe dla jakości modelu; z drugiej strony, takie frameworki są zaprojektowane z całkowicie oddzielnym etapem trenowania wsadowego i etapem serwowania, co uniemożliwia modelowi interakcję z informacją zwrotną od klienta w czasie rzeczywistym. Te problemy skłoniły nas do ponownego zbadania tradycyjnych podejść i eksploracji radykalnie odmiennych wyborów projektowych. W tym artykule prezentujemy 1, system dostosowany do trenowania online. Nasz projekt został oparty na obserwacjach naszych obciążeń aplikacyjnych i środowiska produkcyjnego, które odzwierciedlają wyraźne odejście od innych systemów rekomendacji. Nasze wkłady są wielorakie: po pierwsze, stworzyliśmy niekolizyjne tabele osadzeń z optymalizacjami, takimi jak wygasające osadzenia i filtrowanie częstotliwości, aby zmniejszyć ich zużycie pamięci; po drugie, zapewniamy gotową do produkcji architekturę trenowania online z wysoką odpornością na błędy; wreszcie, udowodniliśmy, że niezawodność systemu może być poświęcona na rzecz uczenia w czasie rzeczywistym. Monolith został pomyślnie wdrożony w produkcie BytePlus Recommend2. Monolith 1 WSTĘP Ostatnia dekada była świadkiem boomu firm opartych na technikach rekomendacji. W pogoni za lepszym doświadczeniem klienta, dostarczanie spersonalizowanych treści dla każdego indywidualnego użytkownika jako reakcja w czasie rzeczywistym jest wspólnym celem tych aplikacji biznesowych. W tym celu informacje z ostatniej interakcji użytkownika są często wykorzystywane jako główne dane wejściowe do trenowania modelu, ponieważ najlepiej odzwierciedlają portret użytkownika i pozwalają przewidywać jego zainteresowania i przyszłe zachowania. Głębokie uczenie zdominowało modele rekomendacji [ , , , , , ], ponieważ ogromna ilość danych użytkowników doskonale nadaje się do masowo opartych na danych modeli neuronowych. Jednak wysiłki mające na celu wykorzystanie mocy głębokiego uczenia w systemach rekomendacji na poziomie przemysłowym stale napotykają problemy wynikające z unikalnych cech danych pochodzących z zachowań użytkowników w świecie rzeczywistym. Dane te drastycznie różnią się od danych używanych w konwencjonalnych problemach głębokiego uczenia, takich jak modelowanie języka czy wizja komputerowa, pod dwoma względami: 5 6 10 12 20 21 (1) Cechy są w większości rzadkie, kategoryczne i dynamicznie się zmieniają; (2) Podstawowy rozkład danych treningowych jest niestacjonarny, znany również jako dryf koncepcji . Takie różnice stanowią unikalne wyzwania dla badaczy i inżynierów pracujących nad systemami rekomendacji. 1.1 Rzadkość i dynamika Dane do rekomendacji zawierają głównie rzadkie cechy kategoryczne, z których niektóre pojawiają się z niską częstotliwością. Powszechna praktyka mapowania ich do przestrzeni osadzeń o wysokiej wymiarowości prowadzi do szeregu problemów: • W przeciwieństwie do modeli językowych, gdzie liczba fragmentów słów jest ograniczona, liczba użytkowników i elementów do rankingu jest rzędy wielkości większa. Taka ogromna tabela osadzeń z trudem zmieści się w pamięci jednego hosta; • Co gorsza, rozmiar tabeli osadzeń ma tendencję do wzrostu w czasie, gdy przybywa więcej użytkowników i elementów, podczas gdy frameworki takie jak [ , ] używają gęstych zmiennych o stałym rozmiarze do reprezentowania tabeli osadzeń. 1 17 W praktyce wiele systemów stosuje haszowanie o niskiej liczbie kolizji [ , ] jako sposób na zmniejszenie zużycia pamięci i umożliwienie wzrostu identyfikatorów. Opiera się to na zbyt idealistycznym założeniu, że identyfikatory w tabeli osadzeń są równomiernie rozłożone pod względem częstotliwości, a kolizje nie mają wpływu na jakość modelu. Niestety, jest to rzadko prawdziwe w przypadku rzeczywistego systemu rekomendacji, gdzie niewielka grupa użytkowników lub elementów ma znacznie więcej wystąpień. Wraz z naturalnym wzrostem rozmiaru tabeli osadzeń, zwiększa się prawdopodobieństwo kolizji kluczy haszujących, co prowadzi do pogorszenia jakości modelu 3 6 . Dlatego też naturalnym wymogiem dla produkcyjnych systemów rekomendacji jest posiadanie możliwości uchwycenia jak największej liczby cech w swoich parametrach, a także zdolność do elastycznego dostosowywania liczby użytkowników i elementów, które starają się śledzić. 1.2 Niestacjonarny rozkład Wzorce wizualne i językowe ledwo rozwijają się w skali stuleci, podczas gdy ten sam użytkownik zainteresowany jednym tematem może zmienić swoje upodobania w każdej chwili. W rezultacie podstawowy rozkład danych użytkowników jest niestacjonarny, co jest zjawiskiem powszechnie określonym jako dryf koncepcji . Intuicyjnie, informacje z niedawnej przeszłości mogą skuteczniej przyczynić się do przewidywania zmian w zachowaniu użytkownika. Aby zminimalizować wpływ dryfu koncepcji, modele serwujące muszą być aktualizowane na podstawie nowych informacji zwrotnych od użytkowników tak szybko, jak to możliwe, aby odzwierciedlić najnowsze zainteresowania użytkownika. Biorąc pod uwagę te rozróżnienia i obserwując problemy wynikające z naszej produkcji, zaprojektowaliśmy , system rekomendacji na dużą skalę, który ma rozwiązać te problemy. Przeprowadziliśmy obszerne eksperymenty weryfikujące i udoskonalające nasz projekt w środowisku produkcyjnym. Monolith jest w stanie: Monolith (1) Zapewnić pełną moc ekspresji dla rzadkich cech poprzez zaprojektowanie niekolizyjnej tablicy haszującej i mechanizmu dynamicznego usuwania cech; (2) Przekazać informacje zwrotne z serwowania do trenowania w czasie rzeczywistym za pomocą trenowania online. Dzięki tym możliwościom architektonicznym, Monolith konsekwentnie przewyższa systemy stosujące sztuczki haszujące z kolizjami przy podobnym zużyciu pamięci i osiąga najnowocześniejsze parametry AUC serwowania online, nie nadwyrężając nadmiernie mocy obliczeniowej naszych serwerów. Dalsza część artykułu jest zorganizowana w następujący sposób. Najpierw szczegółowo omawiamy szczegóły projektu, w jaki sposób Monolith radzi sobie z istniejącymi wyzwaniami za pomocą niekolizyjnej tablicy haszującej i trenowania w czasie rzeczywistym w Sekcji 2. Eksperymenty i wyniki zostaną przedstawione w Sekcji 3, wraz z wnioskami przetestowanymi w produkcji i niektórymi dyskusjami na temat kompromisów między wrażliwością czasową, niezawodnością a jakością modelu. Sekcja 4 podsumowuje powiązaną pracę i porównuje ją z Monolithem. Sekcja 5 podsumowuje tę pracę. 2 PROJEKT Ogólna architektura Monolith generalnie podąża za rozproszonym ustawieniem Worker- arameter erver firmy TensorFlow (Rysunek W architekturze Worker-PS maszyny mają przypisane różne role; maszyny Worker są odpowiedzialne za wykonywanie obliczeń zdefiniowanych przez graf, a maszyny PS przechowują parametry i aktualizują je zgodnie z gradientami obliczonymi przez Workery. P S 2). W modelach rekomendacji parametry są kategoryzowane na dwa zbiory: gęste i rzadkie. Parametry gęste to wagi/zmienne w głębokiej sieci neuronowej, a parametry rzadkie odnoszą się do tabel osadzeń, które odpowiadają rzadkim cechom. W naszym projekcie zarówno parametry gęste, jak i rzadkie są częścią grafu TensorFlow i są przechowywane na serwerach parametrów. Podobnie jak w przypadku zmiennej TensorFlow dla parametrów gęstych, zaprojektowaliśmy zestaw wysoce wydajnych, niekolizyjnych i elastycznych operacji HashTable dla parametrów rzadkich. Jako uzupełnienie ograniczeń TensorFlow wynikających z rozdzielenia trenowania i wnioskowania, elastycznie skalowalne trenowanie online w Monolith zostało zaprojektowane do efektywnej synchronizacji parametrów z trenującego PS do serwującego PS w krótkich odstępach czasu, z gwarancją solidności modelu zapewnianą przez mechanizm odporności na błędy. 2.1 Tablica haszująca Pierwszą zasadą naszego projektu reprezentacji parametrów rzadkich jest unikanie wtłaczania informacji z różnych identyfikatorów do tego samego osadzenia o stałym rozmiarze. Symulacja dynamicznie rozmiarowanej tablicy osadzeń za pomocą standardowej zmiennej TensorFlow nieuchronnie prowadzi do kolizji identyfikatorów, która nasila się wraz z pojawianiem się nowych identyfikatorów i wzrostem tabeli. Dlatego zamiast opierać się na Zmiennej, opracowaliśmy nową tablicę haszującą klucz-wartość dla naszych parametrów rzadkich. Nasza Tablica Haszująca wykorzystuje w tle Cuckoo Hashmap [ ], która obsługuje wstawianie nowych kluczy bez kolidowania z istniejącymi. Haszowanie kukułkowe osiąga złożoność czasową 𝑂 (1) w najgorszym przypadku dla wyszukiwań i usuwania oraz oczekiwaną amortyzowaną złożoność czasową 𝑂 (1) dla wstawień. Jak pokazano na Rysunku , przechowuje dwie tablice 𝑇0, 𝑇1 z różnymi funkcjami haszującymi ℎ0 (𝑥), ℎ1 (𝑥), a element jest przechowywany w jednej z nich. Próbując wstawić element 16 3 𝐴 do 𝑇0, najpierw próbuje umieścić 𝐴 pod adresem ℎ0 (𝐴); Jeśli ℎ0 (𝐴) jest zajęte przez inny element 𝐵, usuwa 𝐵 z 𝑇0 i próbuje wstawić 𝐵 do 𝑇1 z tą samą logiką. Proces ten jest powtarzany, dopóki wszystkie elementy się nie ustabilizują, lub następuje rehash, gdy wstawienie wpada w cykl. Zmniejszenie zużycia pamięci jest również ważnym czynnikiem w naszym projekcie. Naiwne podejście polegające na wstawianiu każdego nowego identyfikatora do Tablicy Haszującej szybko wyczerpie pamięć. Obserwacje rzeczywistych modeli produkcyjnych prowadzą do dwóch wniosków: (1) Identyfikatory, które pojawiają się tylko kilka razy, mają ograniczone znaczenie dla poprawy jakości modelu. Ważną obserwacją jest to, że identyfikatory mają rozkład długiego ogona, gdzie popularne identyfikatory mogą pojawiać się miliony razy, podczas gdy niepopularne pojawiają się nie więcej niż dziesięć razy. Osadzenia odpowiadające tym rzadkim identyfikatorom są niedotrenowane z powodu braku danych treningowych, a model nie będzie w stanie dokonać dobrej estymacji na ich podstawie. Koniec końców, te identyfikatory prawdopodobnie nie wpłyną na wynik, więc jakość modelu nie ucierpi na usunięciu tych identyfikatorów o niskiej liczbie wystąpień; (2) Nieaktualne identyfikatory z dalekiej przeszłości rzadko przyczyniają się do obecnego modelu, ponieważ wiele z nich nigdy nie jest odwiedzanych. Może się tak zdarzyć z powodu użytkownika, który nie jest już aktywny, lub krótkiego filmu, który jest nieaktualny. Przechowywanie osadzeń dla tych identyfikatorów nie pomoże modelowi w żaden sposób, poza daremnym opróżnianiem naszej pamięci PS. Na podstawie tych obserwacji zaprojektowaliśmy kilka heurystyk filtrowania identyfikatorów cech dla bardziej efektywnej implementacji Tablicy Haszującej pod względem pamięci: (1) Identyfikatory są filtrowane przed dopuszczeniem do tabel osadzeń. Mamy dwie metody filtrowania: Najpierw filtrujemy na podstawie ich wystąpień przed ich wstawieniem jako kluczy, gdzie próg wystąpień jest regulowanym hiperparametrem, który różni się dla każdego modelu; Dodatkowo wykorzystujemy filtr probabilistyczny, który pomaga dalej zmniejszyć zużycie pamięci; ![#Rysunek 4: Silnik strumieniowania. Pętla informacji zwrotnej od [Użytkownik → Serwer modelu → Pracownik treningowy → Serwer modelu → Użytkownik] zajęłaby dużo czasu podczas ścieżki trenowania wsadowego, podczas gdy trenowanie online zamyka pętlę natychmiast.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) Identyfikatory są oznaczone czasem i ustawione tak, aby wygasły po okresie nieaktywności przez z góry określony czas. Czas wygaśnięcia jest również regulowany dla każdej tabeli osadzeń, aby umożliwić rozróżnienie cech o różnej wrażliwości na informacje historyczne. W naszej implementacji Tablica Haszująca jest implementowana jako operacja zasobu TensorFlow. Podobnie jak w przypadku Zmiennej, wyszukiwania i aktualizacje są również implementowane jako natywne operacje TensorFlow dla łatwiejszej integracji i lepszej kompatybilności. 2.2 Trenowanie online W Monolith trenowanie jest podzielone na dwa etapy (Rysunek 1): (1) Etap trenowania wsadowego. Ten etap działa jak zwykła pętla trenowania TensorFlow: W każdym kroku trenowania, pracownik trenujący odczytuje jedną mini-partię przykładów treningowych z pamięci masowej, żąda parametrów od PS, wykonuje przejście w przód i w tył, a na końcu wysyła zaktualizowane parametry do trenującego PS. Nieznacznie różniąc się od innych typowych zadań głębokiego uczenia, trenujemy nasz zbiór danych tylko przez jedną przejście. Trenowanie wsadowe jest przydatne do trenowania danych historycznych, gdy modyfikujemy architekturę naszego modelu i ponownie trenujemy model; (2) Etap trenowania online. Po wdrożeniu modelu do serwowania online, trenowanie nie kończy się, ale przechodzi do etapu trenowania online. Zamiast odczytywać przykłady mini-partii z pamięci masowej, pracownik trenujący przetwarza dane w czasie rzeczywistym na bieżąco i aktualizuje trenujący PS. Trenujący PS okresowo synchronizuje swoje parametry z serwującym PS, co natychmiast wpływa na użytkownika. Umożliwia to naszemu modelowi interaktywne dostosowywanie się do informacji zwrotnej od użytkownika w czasie rzeczywistym. Monolith jest zbudowany z możliwością płynnego przełączania się między trenowaniem wsadowym a trenowaniem online. Jest to możliwe dzięki naszemu projektowi silnika strumieniowania, jak pokazano na Rysunku 2.2.1 Silnik strumieniowania. 4. W naszym projekcie używamy jednej kolejki Kafka [ ] do logowania działań użytkowników (np. kliknięcie elementu lub polubienie elementu itp.), a drugiej kolejki Kafka dla cech. Rdzeniem silnika jest zadanie strumieniowania Flink [ ] do łączenia cech online. Łącznik online łączy cechy z etykietami z działań użytkowników i generuje przykłady treningowe, które następnie są zapisywane w kolejce Kafka. Kolejka przykładów treningowych jest konsumowana zarówno przez trenowanie online, jak i trenowanie wsadowe: 13 4 Dla trenowania online, pracownik trenujący bezpośrednio odczytuje dane z kolejki Kafka; Dla trenowania wsadowego, zadanie zrzucania danych najpierw zrzuca dane do HDFS [ ]; Po zgromadzeniu się danych w HDFS w określonej ilości, pracownik trenujący pobiera dane z HDFS i wykonuje trenowanie wsadowe. 18 Zaktualizowane parametry w trenującym PS są przesyłane do serwującego PS zgodnie z harmonogramem synchronizacji parametrów. W rzeczywistych zastosowaniach logi działań użytkowników i cechy są strumieniowane do łącznika online (Rysunek bez gwarancji kolejności czasowej. Dlatego używamy unikalnego klucza dla każdego żądania, aby działanie użytkownika i cechy mogły być poprawnie sparowane. 2.2.2 Łącznik online. 5) Opóźnienie działania użytkownika również może stanowić problem. Na przykład użytkownik może potrzebować kilku dni, zanim zdecyduje się kupić przedmiot, który był mu prezentowany kilka dni wcześniej. Jest to wyzwanie dla łącznika, ponieważ jeśli wszystkie cechy pozostaną w pamięci podręcznej, po prostu nie zmieszczą się w pamięci. W naszym systemie wykorzystujemy pamięć masową klucz-wartość na dysku do przechowywania cech, które oczekują przez pewien okres czasu. Gdy pojawi się log działania użytkownika, najpierw przeszukuje pamięć podręczną w pamięci, a następnie przeszukuje pamięć masową klucz-wartość w przypadku braku w pamięci podręcznej. Innym problemem występującym w rzeczywistych zastosowaniach jest to, że rozkład przykładów negatywnych i pozytywnych jest bardzo nierówny, gdzie liczba pierwszych może być rzędy wielkości wyższa niż liczba drugich. Aby zapobiec przytłoczeniu przykładów pozytywnych przez negatywne, powszechną strategią jest próbkowanie negatywne. To niewątpliwie zmieni podstawowy rozkład trenowanego modelu, dostrajając go w kierunku wyższego prawdopodobieństwa generowania pozytywnych predykcji. Jako lekarstwo stosujemy korektę logarytmu szans [ ] podczas serwowania, upewniając się, że model online jest nieobciążonym estymatorem oryginalnego rozkładu. 19 Podczas trenowania online, klaster trenujący Monolith stale otrzymuje dane z modułu serwowania online i aktualizuje parametry na trenującym PS. Kluczowym krokiem umożliwiającym serwującemu PS korzystanie z tych nowo wytrenowanych parametrów jest synchronizacja zaktualizowanych parametrów modelu. W środowisku produkcyjnym napotykamy kilka wyzwań: 2.2.3 Synchronizacja parametrów. Modele na serwującym PS nie mogą przestać serwować podczas aktualizacji. Nasze modele w produkcji zazwyczaj mają rozmiar kilku terabajtów, a w rezultacie zastąpienie wszystkich parametrów zajmuje trochę czasu. Nieznośne byłoby zatrzymanie serwującego PS w serwowaniu modelu podczas procesu wymiany, a aktualizacje muszą być dokonywane na bieżąco; Przesyłanie modelu o rozmiarze wielu terabajtów w całości z trenującego PS do serwującego PS stanowiłoby ogromną presję zarówno na przepustowość sieci, jak i pamięć na PS, ponieważ wymaga podwojenia rozmiaru pamięci modelu, aby zaakceptować nowo przybyły model. Aby trenowanie online skalowało się do rozmiaru naszego scenariusza biznesowego, zaprojektowaliśmy przyrostowy, periodyczny mechanizm synchronizacji parametrów na bieżąco w Monolith, oparty na kilku zauważalnych cechach naszych modeli: (1) Parametry rzadkie dominują w rozmiarze modeli rekomendacji; (2) Biorąc pod uwagę krótki przedział czasowy, tylko niewielka podgrupa identyfikatorów jest trenowana, a ich osadzenia są aktualizowane; (3) Gęste zmienne poruszają się znacznie wolniej niż rzadkie osadzenia. Dzieje się tak dlatego, że w optymalizatorach opartych na pędzie, akumulacja pędu dla gęstych zmiennych jest powiększana przez gigantyczny rozmiar danych treningowych rekomendacji, podczas gdy tylko kilka rzadkich osadzeń otrzymuje aktualizacje w jednej partii danych. (1) i (2) pozwalają nam wykorzystać rzadkie aktualizacje we wszystkich identyfikatorach cech. W Monolith utrzymujemy zbiór haszujący dotkniętych kluczy, reprezentujący identyfikatory, których osadzenia zostały wytrenowane od ostatniej synchronizacji parametrów. Przesyłamy podzbiór rzadkich parametrów, których klucze znajdują się w zestawie dotkniętych kluczy, z minutowym interwałem czasowym z trenującego PS do serwującego PS. Ta stosunkowo mała paczka przyrostowej aktualizacji parametrów jest lekka pod względem transmisji sieciowej i nie powoduje gwałtownego wzrostu pamięci podczas synchronizacji. Wykorzystujemy również (3) do dalszego zmniejszenia ilości ruchu sieciowego i zużycia pamięci poprzez ustawienie bardziej agresywnego harmonogramu synchronizacji dla rzadkich parametrów, podczas gdy gęste parametry są aktualizowane rzadziej. Może to doprowadzić do sytuacji, w której gęste parametry, które serwujemy, są stosunkowo nieaktualną wersją w porównaniu do części rzadkiej. Jednak taka niespójność może być tolerowana z powodu przyczyny wspomnianej w (3), ponieważ nie zaobserwowano żadnej zauważalnej straty. 2.3 Odporność na błędy Jako system w produkcji, Monolith został zaprojektowany z możliwością odzyskania PS w przypadku jego awarii. Powszechnym wyborem dla odporności na błędy jest okresowe tworzenie migawek stanu modelu i odzyskiwanie z najnowszej migawki po wykryciu awarii PS. Wybór częstotliwości tworzenia migawek ma dwa główne wpływy: (1) Jakość modelu. Intuicyjnie, jakość modelu mniej cierpi na utratę niedawnej historii wraz ze zwiększoną częstotliwością tworzenia migawek. (2) Narzut obliczeniowy. Tworzenie migawek modelu o rozmiarze wielu terabajtów nie jest darmowe. Wiąże się z dużymi ilościami kopiowania pamięci i operacji I/O na dysku. Jako kompromis między jakością modelu a narzutem obliczeniowym, Monolith codziennie tworzy migawki wszystkich trenujących PS. Chociaż PS straci jeden dzień aktualizacji w przypadku awarii, odkryliśmy, że spadek wydajności jest znośny dzięki naszym eksperymentom. Analizę wpływu niezawodności PS przeprowadzimy w następnej sekcji. 3 OCENA Aby lepiej zrozumieć korzyści i kompromisy wynikające z naszego proponowanego projektu, przeprowadziliśmy kilka eksperymentów na skalę produkcyjną i testy A/B z ruchem serwowania na żywo, aby ocenić i zweryfikować Monolith pod różnymi względami. Naszym celem jest odpowiedzenie na następujące pytania za pomocą naszych eksperymentów: (1) Jak bardzo możemy skorzystać z niekolizyjnej Tablicy Haszującej? (2) Jak ważne jest trenowanie online w czasie rzeczywistym? (3) Czy projekt synchronizacji parametrów Monolith jest wystarczająco solidny w scenariuszu produkcyjnym na dużą skalę? W tej sekcji najpierw przedstawiamy nasze ustawienia eksperymentalne, a następnie szczegółowo omawiamy wyniki i nasze wnioski. 3.1 Ustawienia eksperymentalne Jak opisano w Sekcji tabele osadzeń w Monolith są implementowane jako niekolizyjne Tablice Haszujące. Aby udowodnić konieczność unikania kolizji w tabelach osadzeń i skwantyfikować zyski z naszej niekolizyjnej implementacji, przeprowadziliśmy dwie grupy eksperymentów na zbiorze danych Movielens i na naszym wewnętrznym zbiorze danych produkcyjnych: 3.1.1 Tabela osadzeń. 2.1, (1) Zbiór danych ml-25m [ ]. Jest to standardowy publiczny zbiór danych ocen filmów, zawierający 25 milionów ocen obejmujących około 162 000 użytkowników i 62 000 filmów. MovieLens 11 • . Oryginalne etykiety to oceny od Przetwarzanie wstępne etykiet 0,5 do 5,0, podczas gdy w produkcji nasze zadania polegają głównie na otrzymywaniu binarnych sygnałów od użytkowników. Aby lepiej symulować nasze modele produkcyjne, przekształciliśmy skale ocen na etykiety binarne, traktując oceny ≥ 3,5 jako próbki pozytywne, a resztę jako próbki negatywne. • Model i metryki. Zaimplementowaliśmy standardowy model DeepFM, powszechnie używaną architekturę modelu do problemów rekomendacji. Składa się on z komponentu FM i komponentu gęstego (Rysunek 6). Predykcje są oceniane za pomocą AUC, ponieważ jest to główna miara dla rzeczywistych modeli. • Kolizje osadzeń. Ten zbiór danych zawiera około 160 tysięcy identyfikatorów użytkowników i 60 tysięcy identyfikatorów filmów. Aby porównać z niekolizyjną wersją implementacji tabeli osadzeń, przeprowadziliśmy kolejną grupę eksperymentów, w której identyfikatory były przetwarzane wstępnie za pomocą haszowania MD5, a następnie mapowane na mniejszą przestrzeń identyfikatorów. W rezultacie niektóre identyfikatory będą współdzielić swoje osadzenie z innymi. Tabela 1 pokazuje szczegółowe statystyki identyfikatorów użytkowników i filmów przed i po haszowaniu. (2) . Wewnętrzny zbiór danych rekomendacji Przeprowadziliśmy również eksperymenty na modelu rekomendacji w środowisku produkcyjnym. Ten model zazwyczaj podąża za architekturą wielowieżową, gdzie każda wieża odpowiada za naukę przewidywania specjalistycznego rodzaju zachowania użytkownika. Każdy model ma około 1000 tabel osadzeń, a rozkład rozmiarów tabel osadzeń jest bardzo nierówny; Oryginalna przestrzeń identyfikatorów tabeli osadzeń wynosiła 248. W naszej wersji bazowej zastosowaliśmy sztuczkę haszującą poprzez dekompozycję, aby ograniczyć rozmiar tabeli osadzeń. Mówiąc bardziej szczegółowo, używamy dwóch mniejszych tabel osadzeń zamiast jednej gigantycznej, aby wygenerować unikalne osadzenie dla każdego identyfikatora poprzez kombinację wektorową: gdzie 𝐸𝑟 , 𝐸𝑞 to osadzenia odpowiadające 𝐼𝐷𝑟 , 𝐼𝐷𝑞. Skutecznie zmniejsza to rozmiary tabel osadzeń z 248 do 225; • Ten model jest serwowany w rzeczywistej produkcji, a wydajność tego eksperymentu jest mierzona za pomocą AUC online z rzeczywistym ruchem serwowania. 3