Wewnątrz 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 Zbudowanie skalowalnego i działającego w czasie rzeczywistym systemu rekomendacji jest kluczowe dla wielu firm opartych na wrażliwych na czas opiniach klientów, takich jak rankingi krótkich filmów lub reklamy online. Pomimo powszechnego stosowania produkcyjnych frameworków uczenia głębokiego, takich jak TensorFlow czy PyTorch, te ogólnego przeznaczenia frameworki nie spełniają wymagań biznesowych w scenariuszach rekomendacji z różnych powodów: z jednej strony, dostosowywanie systemów w oparciu o statyczne parametry i gęste obliczenia do 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, uniemożliwiając modelowi interakcję z opiniami klientów w czasie rzeczywistym. Problemy te skłoniły nas do ponownego przeanalizowania 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ą znaczące odejście od innych systemów rekomendacji. Nasze wkłady są wielorakie: po pierwsze, stworzyliśmy tabelę osadzeń bez kolizji z optymalizacjami, takimi jak wygasające osadzenia i filtrowanie częstotliwości, aby zmniejszyć jej zapotrzebowanie na pamięć; po drugie, zapewniamy gotową do produkcji architekturę trenowania online o wysokiej odporności na błędy; wreszcie, udowodniliśmy, że niezawodność systemu można zamienić na uczenie w czasie rzeczywistym. Monolith został pomyślnie wdrożony w produkcie BytePlus Recommend2. Monolith 1 WPROWADZENIE Ostatnia dekada była świadkiem boomu biznesów opartych na technikach rekomendacji. W dążeniu do lepszego doświadczenia klienta, dostarczanie spersonalizowanych treści dla każdego indywidualnego użytkownika jako odpowiedzi w czasie rzeczywistym jest wspólnym celem tych aplikacji biznesowych. W tym celu informacje z najnowszej interakcji użytkownika są często wykorzystywane jako główne wejście do trenowania modelu, ponieważ najlepiej odzwierciedlają one profil użytkownika i pozwalają przewidzieć jego zainteresowania i przyszłe zachowania. Uczenie głębokie zdominowało modele rekomendacji [ , , , , , ], ponieważ gigantyczna ilość danych użytkowników naturalnie pasuje do masowo napędzanych danymi modeli neuronowych. Jednak wysiłki na rzecz wykorzystania mocy uczenia głębokiego w systemach rekomendacji na poziomie przemysłowym stale napotykają problemy wynikające z unikalnych cech danych pochodzących z rzeczywistych zachowań użytkowników. Dane te drastycznie różnią się od tych używanych w konwencjonalnych problemach uczenia głębokiego, 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 jako dryf koncepcji (Concept Drift) . Takie różnice stwarzają unikalne wyzwania dla badaczy i inżynierów pracujących nad systemami rekomendacji. 1.1 Rzadkość i dynamizm 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 wysokowymiarowej przestrzeni osadzeń 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 o rzędy wielkości większa. Taka ogromna tabela osadzeń z trudem zmieści się w pamięci jednego hosta; • Co gorsza, oczekuje się, że rozmiar tabeli osadzeń będzie rósł w czasie wraz z dodawaniem kolejnych użytkowników i elementów, podczas gdy frameworki takie jak [ , ] używają stałowymiarowych zmiennych gęstych do reprezentowania tabeli osadzeń. 1 17 W praktyce wiele systemów stosuje haszowanie o niskiej liczbie kolizji [ , ] jako sposób na zmniejszenie zapotrzebowania na pamięć i umożliwienie wzrostu liczby 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 wpływają negatywnie na jakość modelu. Niestety, rzadko ma to miejsce w rzeczywistym systemie rekomendacji, gdzie niewielka grupa użytkowników lub elementów ma znacznie więcej wystąpień. Wraz z organicznym wzrostem rozmiaru tabeli osadzeń, zwiększa się prawdopodobieństwo kolizji kluczy haszujących i prowadzi to do pogorszenia jakości modelu 3 6 . Dlatego naturalnym zapotrzebowaniem systemów rekomendacji na skalę produkcyjną jest zdolność do uchwycenia jak największej liczby cech w ich parametrach, a także możliwość elastycznego dostosowywania liczby użytkowników i elementów, które próbują śledzić. 1.2 Niestacjonarny rozkład Wzorce wizualne i językowe ledwo rozwijają się w skali czasowej stuleci, podczas gdy ten sam użytkownik zainteresowany jednym tematem może zmienić swoje zainteresowanie w następnej minucie. W rezultacie podstawowy rozkład danych użytkowników jest niestacjonarny, zjawisko powszechnie określane jako dryf koncepcji (Concept Drift) . Intuicyjnie, informacje z bliższej historii mogą skuteczniej przyczyniać się do przewidywania zmian w zachowaniu użytkownika. Aby złagodzić wpływ dryfu koncepcji, modele serwujące muszą być aktualizowane na podstawie nowych opinii 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, które pojawiają się w naszej produkcji, zaprojektowaliśmy , system rekomendacji na dużą skalę, aby rozwiązać te problemy. Przeprowadziliśmy obszerne eksperymenty w celu weryfikacji i iteracji naszego projektu w środowisku produkcyjnym. Monolith jest w stanie: Monolith (1) Zapewnić pełną moc wyrazu dla rzadkich cech poprzez zaprojektowanie bezkolizyjnej tablicy haszującej i mechanizmu usuwania dynamicznych cech; (2) Zwrócić pętlę opinii z serwowania do trenowania w czasie rzeczywistym dzięki trenowaniu 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 wartości AUC serwowania online, nie obciążając nadmiernie mocy obliczeniowej naszych serwerów. Reszta artykułu jest zorganizowana w następujący sposób. Najpierw szczegółowo opisujemy projekt, w jaki sposób Monolith radzi sobie z istniejącymi wyzwaniami za pomocą bezkolizyjnej 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ą na czas, niezawodnością a jakością modelu. Sekcja 4 podsumowuje pokrewne prace i porównuje je z Monolithem. Sekcja 5 kończy niniejszą pracę. 2 PROJEKT Ogólna architektura Monolith generalnie podąża za rozproszonym modelem Worker- arameter erver TensorFlow (Figura 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 zestawy: 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 zmiennych TensorFlow dla parametrów gęstych, zaprojektowaliśmy zestaw wysoce wydajnych, bezkolizyjnych i elastycznych operacji HashTable dla parametrów rzadkich. Jako uzupełnienie ograniczeń TensorFlow wynikających z separacji trenowania i wnioskowania, elastycznie skalowalne trenowanie online Monolith zostało zaprojektowane w celu efektywnej synchronizacji parametrów z trenowania PS do serwowania online PS w krótkich interwałach, z gwarancją solidności modelu zapewnianą przez mechanizm odporności na błędy. 2.1 Tabela haszująca Pierwszą zasadą naszego projektu reprezentacji parametrów rzadkich jest unikanie zagęszczania informacji z różnych identyfikatorów w tym samym osadzeniu o stałym rozmiarze. Symulowanie dynamicznej wielkości tabeli osadzeń za pomocą gotowej zmiennej TensorFlow nieuchronnie prowadzi do kolizji identyfikatorów, która nasila się wraz z pojawianiem się nowych identyfikatorów i wzrostem tabeli. Dlatego zamiast bazować na zmiennych, opracowaliśmy nową tablicę haszującą klucz-wartość dla naszych parametrów rzadkich. Nasza HashTable wykorzystuje pod spodem Cuckoo Hashmap [ ], która obsługuje wstawianie nowych kluczy bez kolidowania z istniejącymi. Cuckoo Hashing osiąga złożoność czasową 𝑂 (1) w najgorszym przypadku dla wyszukiwań i usunięć, oraz oczekiwaną amortyzowaną złożoność czasową 𝑂 (1) dla wstawień. Jak pokazano na Figurze , utrzymuje ona dwie tablice 𝑇0, 𝑇1 z różnymi funkcjami haszującymi ℎ0 (𝑥), ℎ1 (𝑥), a element zostanie przechowywany w jednej z nich. Podczas próby wstawienia elementu 16 3 𝐴 do 𝑇0, najpierw próbuje umieścić 𝐴 w ℎ0 (𝐴); Jeśli ℎ0 (𝐴) jest zajęte przez inny element 𝐵, usuwa on 𝐵 z 𝑇0 i próbuje wstawić 𝐵 do 𝑇1 z tą samą logiką. Proces ten będzie powtarzany, aż wszystkie elementy się ustabilizują, lub nastąpi ponowne haszowanie, gdy wstawienie wpadnie w cykl. Zmniejszenie zużycia pamięci jest również ważnym czynnikiem w naszym projekcie. Proste podejście polegające na wstawianiu każdego nowego identyfikatora do HashTable szybko wyczerpie pamięć. Obserwacje rzeczywistych modeli produkcyjnych doprowadziły do dwóch wniosków: (1) Identyfikatory pojawiające się tylko kilka razy mają ograniczony wkład w poprawę jakości modelu. Ważną obserwacją jest to, że identyfikatory są rozłożone w długim ogonie, gdzie popularne identyfikatory mogą występować 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. Ostatecznie identyfikatory te prawdopodobnie nie wpłyną na wynik, więc jakość modelu nie ucierpi z powodu usunięcia tych identyfikatorów z niską liczbą wystąpień; (2) Nieaktualne identyfikatory z odległej historii rzadko przyczyniają się do obecnego modelu, ponieważ wiele z nich nigdy nie jest odwiedzanych. Może się to zdarzyć z powodu użytkownika, który już nie jest 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 wyczerpywaniem pamięci PS. Na podstawie tych obserwacji zaprojektowaliśmy kilka heurystyk filtrowania identyfikatorów cech dla bardziej wydajnego pamięciowo wdrożenia HashTable: (1) Identyfikatory są filtrowane przed dopuszczeniem do tabel osadzeń. Mamy dwie metody filtrowania: najpierw filtrujemy według liczby wystąpień przed ich wstawieniem jako kluczy, gdzie próg wystąpień jest konfigurowalnym hiperparametrem, który różni się dla każdego modelu; Dodatkowo wykorzystujemy probabilistyczny filtr, który pomaga dalej zmniejszyć zużycie pamięci; ![#Figura 4: Silnik strumieniowy. Pętla informacji zwrotnej z [Użytkownik → Serwer modelu → Robot treningowy → Serwer modelu → Użytkownik] zajęłaby dużo czasu, przechodząc przez ścieżkę trenowania wsadowego, podczas gdy trenowanie online zamyka pętlę natychmiast.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) Identyfikatory są czasowo oznaczone i ustawione tak, aby wygasały po okresie braku aktywności. Czas wygaśnięcia jest również konfigurowalny dla każdej tabeli osadzeń, aby umożliwić rozróżnienie cech o różnej wrażliwości na informacje historyczne. W naszej implementacji HashTable jest zaimplementowana jako operacja zasobu TensorFlow. Podobnie jak w przypadku zmiennych, wyszukiwania i aktualizacje są również zaimplementowane jako natywne operacje TensorFlow dla łatwiejszej integracji i lepszej kompatybilności. 2.2 Trenowanie online W Monolith trenowanie jest podzielone na dwa etapy (Figura 1): (1) Etap trenowania wsadowego. Ten etap działa jak zwykła pętla trenowania TensorFlow: w każdym kroku trenowania, robot treningowy odczytuje jedną mini-partię przykładów treningowych z magazynu, żąda parametrów z PS, oblicza przejście w przód i w tył, a na końcu wysyła zaktualizowane parametry do trenującego PS. Nieznacznie różni się od innych powszechnych zadań uczenia głębokiego, trenujemy nasz zbiór danych tylko przez jedną iterację. 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ć mini-partie przykładów z magazynu, robot treningowy 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 staje się skuteczne po stronie użytkownika. Umożliwia to naszemu modelowi interaktywne dostosowywanie się do opinii 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 strumieniowego, zilustrowanemu na Figurze 2.2.1 Silnik strumieniowy. 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. W rdzeniu silnika znajduje się zadanie strumieniowania Flink [ ] dla modułu łączącego cechy online. Łącznik online łączy cechy z etykietami z działań użytkowników i generuje przykłady treningowe, które są następnie zapisywane w kolejce Kafka. Kolejka przykładów treningowych jest konsumowana zarówno przez trenowanie online, jak i trenowanie wsadowe: 13 4 W przypadku trenowania online, robot treningowy bezpośrednio odczytuje dane z kolejki Kafka; W przypadku trenowania wsadowego, zadanie zrzucania danych najpierw zrzuca dane do HDFS [ ]; Po zgromadzeniu się danych w HDFS w określonej ilości, robot treningowy pobiera dane z HDFS i przeprowadza trenowanie wsadowe. 18 Zaktualizowane parametry w trenującym PS są wysyłane do serwującego PS zgodnie z harmonogramem synchronizacji parametrów. W aplikacjach rzeczywistych logi działań użytkowników i cechy są przesyłane strumieniowo do łącznika online (Figura bez gwarancji kolejności czasowej. Dlatego używamy unikalnego klucza dla każdego żądania, aby działania użytkownika i cechy mogły być poprawnie sparowane. 2.2.2 Łącznik online. 5) Opóźnienie działań użytkownika może być również problemem. Na przykład użytkownik może potrzebować kilku dni, zanim zdecyduje się kupić przedmiot, który został mu przedstawiony kilka dni temu. Jest to wyzwanie dla łącznika, ponieważ jeśli wszystkie cechy zostaną zachowane w pamięci podręcznej, po prostu się ona nie zmieści w pamięci. W naszym systemie wykorzystywane jest pamięciowe magazynowanie klucz-wartość do przechowywania cech, które oczekują na zbyt długi okres. Gdy dociera log działania użytkownika, najpierw przeszukuje pamięć podręczną w pamięci, a następnie przeszukuje magazyn klucz-wartość w przypadku braku w pamięci podręcznej. Innym problemem pojawiającym się w rzeczywistych zastosowaniach jest bardzo nierówny rozkład przykładów negatywnych i pozytywnych, gdzie liczba tych pierwszych może być o rzędy wielkości wyższa niż tych drugich. Aby zapobiec przytłoczeniu przykładów pozytywnych przez negatywne, powszechną strategią jest próbkowanie negatywne. To z pewnością zmieni podstawowy rozkład wytrenowanego modelu, dostosowując go w kierunku wyższego prawdopodobieństwa generowania pozytywnych predykcji. Jako środek zaradczy stosujemy korektę logarytmu szans (log odds correction) [ ] podczas serwowania, zapewniając, że model online jest nieobciążonym estymatorem oryginalnego rozkładu. 19 Podczas trenowania online, klaster trenujący Monolith stale odbiera dane z modułu serwowania online i aktualizuje parametry na trenującym PS. Kluczowym krokiem, aby serwujący PS mógł skorzystać 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 online nie mogą przestać być serwowane podczas aktualizacji. Nasze modele w produkcji są zazwyczaj wielkości kilku terabajtów, a co za tym idzie, zastąpienie wszystkich parametrów zajmuje trochę czasu. Zatrzymanie serwującego PS od serwowania modelu podczas procesu wymiany byłoby niedopuszczalne, a aktualizacje muszą być dokonywane na bieżąco; Transfer modelu wielkości kilku terabajtów w całości z trenującego PS do serwującego PS online stanowiłby ogromną presję zarówno na przepustowość sieci, jak i pamięć na PS, ponieważ wymaga podwojenia rozmiaru pamięci, aby zaakceptować nowo przybyły model. Aby trenowanie online mogło skalować się do rozmiaru naszego scenariusza biznesowego, zaprojektowaliśmy przyrostkowy mechanizm okresowej 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) W krótkim oknie czasowym tylko niewielki podzbiór identyfikatorów jest trenowany, a ich osadzenia 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 pojedynczej 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ących identyfikatory, których osadzenia zostały wytrenowane od ostatniej synchronizacji parametrów. Wypychamy podzbiór rzadkich parametrów, których klucze znajdują się w zestawie dotkniętych kluczy, z interwałem czasowym na poziomie minut z trenującego PS do serwującego PS online. Ta stosunkowo mała paczka przyrostkowej aktualizacji parametrów jest lekka dla transmisji sieciowej i nie powoduje gwałtownego wzrostu pamięci podczas synchronizacji. Wykorzystujemy również (3) do dalszego zmniejszenia ruchu sieciowego i zużycia pamięci, ustawiając bardziej agresywny harmonogram synchronizacji dla rzadkich parametrów, podczas gdy gęste parametry są aktualizowane rzadziej. Może to doprowadzić do sytuacji, w której serwowane gęste parametry są stosunkowo przestarzałą wersją w porównaniu do części rzadkiej. Jednak taka niespójność może być tolerowana z powodu wspomnianego w (3) powodu, ponieważ nie zaobserwowano żadnych wyraźnych strat. 2.3 Odporność na błędy Jako system w produkcji, Monolith jest zaprojektowany z możliwością odzyskania PS w przypadku jego awarii. Powszechnym wyborem dla odporności na błędy jest okresowe tworzenie migawki stanu modelu i odzyskiwanie z ostatniej migawki po wykryciu awarii PS. Wybór częstotliwości migawek ma dwa główne wpływy: (1) Jakość modelu. Intuicyjnie, jakość modelu mniej cierpi z powodu utraty ostatnich historii wraz ze zwiększoną częstotliwością migawek. (2) Narzut obliczeniowy. Tworzenie migawki modelu o wielkości kilku terabajtów nie jest darmowe. Powoduje to duże kopiowanie pamięci i operacje wejścia/wyjścia na dysku. Jako kompromis między jakością modelu a narzutem obliczeniowym, Monolith tworzy migawki wszystkich trenujących PS codziennie. Chociaż PS straci jeden dzień aktualizacji w przypadku awarii, odkryliśmy, że spadek wydajności jest dopuszczalny dzięki naszym eksperymentom. 3 EWALUACJA 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 z różnych perspektyw. Naszym celem jest odpowiedzenie na następujące pytania w naszych eksperymentach: (1) Jak bardzo możemy skorzystać z bezkolizyjnej 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 produkcji 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ą zaimplementowane jako bezkolizyjne tablice haszujące. Aby udowodnić konieczność unikania kolizji w tabelach osadzeń i skwantyfikować zyski z naszej bezkolizyjnej implementacji, przeprowadziliśmy dwie grupy eksperymentów odpowiednio 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 dotyczący ocen filmów, zawierający 25 milionów ocen, obejmujący 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 sygnałów binarnych od użytkowników. Aby lepiej symulować nasze modele produkcyjne, przekształcamy etykiety skalowane 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, często używaną architekturę modelu do problemów rekomendacji. Składa się on z komponentu FM i komponentu gęstego (Figura 6). Predykcje są oceniane przez AUC, ponieważ jest to główny pomiar dla rzeczywistych modeli. • Kolizje osadzeń. Ten zbiór danych zawiera około 160 tys. identyfikatorów użytkowników i 60 tys. identyfikatorów filmów. Aby porównać z bezkolizyjną wersją implementacji tabeli osadzeń, przeprowadziliśmy kolejną grupę eksperymentów, w której identyfikatory są wstępnie przetwarzane za pomocą haszowania MD5, a następnie mapowane na mniejszą przestrzeń identyfikatorów. W rezultacie niektóre identyfikatory będą 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. Model ten ogólnie podąża za architekturą wielowieżową, gdzie każda wieża odpowiada za uczenie się 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ń ID tabeli osadzeń wynosiła 248. W naszej wersji bazowej zastosowaliśmy sztuczkę haszowania poprzez dekompozycję w celu ograniczenia rozmiaru tabeli osadzeń. Mówiąc dokładniej, używamy dwóch mniejszych tabel osadzeń zamiast jednego gigantycznego, aby wygenerować unikalne osadzenie dla każdego ID poprzez kombinację wektorową: gdzie 𝐸𝑟 , 𝐸𝑞 są osadzeniami odpowiadającymi 𝐼𝐷𝑟 , 𝐼𝐷𝑞. Efektywnie 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. Podczas trenowania online aktualizujemy nasze serwujące PS online najnowszym zestawem parametrów z interwałami minutowymi. Zaprojektowaliśmy dwie grupy eksperymentów w celu weryfikacji jakości modelu i solidności systemu. 3.1.2 Trenowanie online.