Di Dalam Monolith ByteDance: Mesin yang Memberdayakan Umpan Konten yang Lebih Cerdas dan Lebih Cepat

Penulis: 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∗, Universitas Fudan Yijie Zhu, Bytedance Inc. Peng Wu, Bytedance Inc. Ke Wang, Bytedance Inc. Youlong Cheng†, Bytedance Inc. (youlong.cheng@bytedance.com) ABSTRAK Membangun sistem rekomendasi yang skalabel dan real-time sangat penting bagi banyak bisnis yang didorong oleh umpan balik pelanggan yang peka terhadap waktu, seperti pemeringkatan video pendek atau iklan online. Meskipun kerangka kerja pembelajaran mendalam skala produksi seperti Ten-sorFlow atau PyTorch diadopsi secara universal, kerangka kerja serbaguna ini tidak memenuhi tuntutan bisnis dalam skenario rekomendasi karena berbagai alasan: di satu sisi, penyesuaian sistem berdasarkan parameter statis dan komputasi padat untuk rekomendasi dengan fitur dinamis dan jarang merusak kualitas model; di sisi lain, kerangka kerja semacam itu dirancang dengan tahap pelatihan batch dan tahap penyajian yang sepenuhnya terpisah, mencegah model berinteraksi dengan umpan balik pelanggan secara real-time. Masalah-masalah ini mendorong kami untuk meninjau kembali pendekatan tradisional dan mengeksplorasi pilihan desain yang berbeda secara radikal. Dalam makalah ini, kami menyajikan 1, sebuah sistem yang disesuaikan untuk pelatihan online. Desain kami didorong oleh pengamatan beban kerja aplikasi dan lingkungan produksi kami yang mencerminkan penyimpangan yang jelas dari sistem rekomendasi lainnya. Kontribusi kami bersifat multifaset: pertama, kami membuat tabel embedding tanpa tabrakan dengan optimasi seperti embedding yang dapat kedaluwarsa dan pemfilteran frekuensi untuk mengurangi jejak memorinya; kedua, kami menyediakan arsitektur pelatihan online yang siap produksi dengan toleransi kesalahan tinggi; akhirnya, kami membuktikan bahwa keandalan sistem dapat ditukar dengan pembelajaran real-time. Monolith telah berhasil diterapkan pada produk BytePlus Recommend2. Monolith 1 PENDAHULUAN Satu dekade terakhir menyaksikan ledakan bisnis yang didukung oleh teknik rekomendasi. Dalam upaya untuk pengalaman pelanggan yang lebih baik, memberikan konten yang dipersonalisasi untuk setiap pengguna secara individual sebagai respons real-time adalah tujuan umum dari aplikasi bisnis ini. Untuk tujuan ini, informasi dari interaksi terbaru pengguna sering digunakan sebagai masukan utama untuk melatih model, karena paling baik menggambarkan potret pengguna dan membuat prediksi tentang minat dan perilaku masa depan pengguna. Pembelajaran mendalam telah mendominasi model rekomendasi [ , , , , , ] karena sejumlah besar data pengguna sangat cocok untuk model neural yang didorong oleh data secara masif. Namun, upaya untuk memanfaatkan kekuatan pembelajaran mendalam dalam sistem rekomendasi tingkat industri terus-menerus menghadapi masalah yang timbul dari karakteristik unik data yang berasal dari perilaku pengguna di dunia nyata. Data ini sangat berbeda dari data yang digunakan dalam masalah pembelajaran mendalam konvensional seperti pemodelan bahasa atau visi komputer dalam dua aspek: 5 6 10 12 20 21 (1) Fitur sebagian besar jarang, kategorikal, dan berubah secara dinamis; (2) Distribusi data pelatihan yang mendasarinya tidak stasioner, alias Concept Drift . Perbedaan seperti itu telah menimbulkan tantangan unik bagi para peneliti dan insinyur yang bekerja pada sistem rekomendasi. 1.1 Kelangkaan dan Dinamisme Data untuk rekomendasi sebagian besar berisi fitur kategorikal yang jarang, beberapa di antaranya muncul dengan frekuensi rendah. Praktik umum memetakannya ke ruang penyematan berdimensi tinggi akan menimbulkan serangkaian masalah: • Berbeda dengan model bahasa di mana jumlah potongan kata terbatas, jumlah pengguna dan item peringkat adalah beberapa kali lebih besar. Tabel penyematan yang sangat besar ini hampir tidak muat ke dalam memori satu host; • Lebih buruk lagi, ukuran tabel penyematan diharapkan tumbuh seiring waktu karena lebih banyak pengguna dan item yang dimasukkan, sementara kerangka kerja seperti [ , ] menggunakan variabel padat berukuran tetap untuk mewakili tabel penyematan. 1 17 Dalam praktiknya, banyak sistem mengadopsi hashing dengan tabrakan rendah [ , ] sebagai cara untuk mengurangi jejak memori dan memungkinkan pertumbuhan ID. Ini bergantung pada asumsi yang terlalu idealis bahwa ID dalam tabel penyematan didistribusikan secara merata dalam frekuensi, dan tabrakan tidak berbahaya bagi kualitas model. Sayangnya, ini jarang benar untuk sistem rekomendasi dunia nyata, di mana sejumlah kecil pengguna atau item memiliki kejadian yang jauh lebih signifikan. Dengan pertumbuhan organik ukuran tabel penyematan, kemungkinan tabrakan kunci hash meningkat dan menyebabkan penurunan kualitas model 3 6 . Oleh karena itu, ini adalah permintaan alami untuk sistem rekomendasi skala produksi untuk memiliki kapasitas menangkap sebanyak mungkin fitur dalam parameternya, dan juga memiliki kemampuan untuk secara elastis menyesuaikan jumlah pengguna dan item yang coba dicatatnya. 1.2 Distribusi Non-Stasioner Pola visual dan linguistik hampir tidak berkembang dalam skala waktu berabad-abad, sementara pengguna yang sama yang tertarik pada satu topik dapat mengalihkan semangat mereka setiap menit berikutnya. Akibatnya, distribusi data pengguna yang mendasarinya tidak stasioner, sebuah fenomena yang biasa disebut sebagai Concept Drift . Secara intuitif, informasi dari riwayat yang lebih baru dapat berkontribusi lebih efektif untuk memprediksi perubahan perilaku pengguna. Untuk mengurangi efek Concept Drift, model penyajian perlu diperbarui dari umpan balik pengguna baru sedekat mungkin secara real-time untuk mencerminkan minat terbaru pengguna. Mengingat perbedaan ini dan pengamatan masalah yang timbul dari produksi kami, kami merancang , sistem skala besar untuk rekomendasi untuk mengatasi masalah-masalah ini. Kami melakukan eksperimen ekstensif untuk memverifikasi dan mengulang desain kami di lingkungan produksi. Monolith mampu Monolith (1) Memberikan kekuatan ekspresif penuh untuk fitur-fitur jarang melalui perancangan tabel hash tanpa tabrakan dan mekanisme penggusuran fitur dinamis; (2) Mengembalikan umpan balik penyajian ke pelatihan secara real-time dengan pelatihan online. Didukung oleh kapasitas arsitektur ini, Monolith secara konsisten mengungguli sistem yang mengadopsi trik hash dengan tabrakan dengan penggunaan memori yang kira-kira sama, dan mencapai AUC penyajian online state-of-the-art tanpa terlalu membebani kekuatan komputasi server kami. Sisa makalah ini diorganisir sebagai berikut. Kami pertama-tama menguraikan detail desain tentang bagaimana Monolith mengatasi tantangan yang ada dengan tabel hash tanpa tabrakan dan pelatihan real-time di Bagian 2. Eksperimen dan hasil akan disajikan di Bagian 3, bersama dengan kesimpulan yang telah diuji di produksi dan beberapa diskusi tentang trade-off antara kepekaan waktu, keandalan, dan kualitas model. Bagian 4 merangkum pekerjaan terkait dan membandingkannya dengan Monolith. Bagian 5 menyimpulkan karya ini. 2 DESAIN Arsitektur keseluruhan Monolith umumnya mengikuti pengaturan Worker- arameter erver TensorFlow yang terdistribusi (Gambar Dalam arsitektur Worker-PS, mesin ditugaskan peran yang berbeda; mesin Worker bertanggung jawab untuk melakukan komputasi seperti yang didefinisikan oleh graf, dan mesin PS menyimpan parameter dan memperbaruinya sesuai dengan gradien yang dihitung oleh Worker. P S 2). Dalam model rekomendasi, parameter dikategorikan menjadi dua set: padat dan jarang. Parameter padat adalah bobot/variabel dalam jaringan saraf dalam, dan parameter jarang mengacu pada tabel penyematan yang sesuai dengan fitur jarang. Dalam desain kami, baik parameter padat maupun jarang adalah bagian dari TensorFlow Graph, dan disimpan di server parameter. Mirip dengan Variabel TensorFlow untuk parameter padat, kami merancang serangkaian operasi HashTable yang sangat efisien, tanpa tabrakan, dan fleksibel untuk parameter jarang. Sebagai pelengkap keterbatasan TensorFlow yang timbul dari pemisahan pelatihan dan inferensi, pelatihan online Monolith yang dapat diskalakan secara elastis dirancang untuk menyinkronkan parameter secara efisien dari PS pelatihan ke PS penyajian online dalam interval pendek, dengan jaminan ketahanan model yang disediakan oleh mekanisme toleransi kesalahan. 2.1 Tabel Hash Prinsip pertama dalam desain representasi parameter jarang kami adalah menghindari menjejalkan informasi dari ID yang berbeda ke dalam penyematan ukuran tetap yang sama. Mensimulasikan tabel penyematan berukuran dinamis dengan Variabel TensorFlow siap pakai pasti menyebabkan tabrakan ID, yang memburuk karena ID baru masuk dan tabel tumbuh. Oleh karena itu, alih-alih membangun di atas Variabel, kami mengembangkan HashTable kunci-nilai baru untuk parameter jarang kami. HashTable kami memanfaatkan Cuckoo Hashmap [ ] di latar belakang, yang mendukung penyisipan kunci baru tanpa bertabrakan dengan yang sudah ada. Cuckoo Hashing mencapai kompleksitas waktu 𝑂 (1) dalam kasus terburuk untuk pencarian dan penghapusan, dan 𝑂 (1) waktu rata-rata yang diharapkan untuk penyisipan. Seperti yang diilustrasikan pada Gambar , ia mempertahankan dua tabel 𝑇0, 𝑇1 dengan fungsi hash yang berbeda ℎ0 (𝑥), ℎ1 (𝑥), dan sebuah elemen akan disimpan di salah satunya. Saat mencoba menyisipkan elemen 16 3 𝐴 ke dalam 𝑇0, ia pertama-tama mencoba menempatkan 𝐴 di ℎ0 (𝐴); Jika ℎ0 (𝐴) ditempati oleh elemen lain 𝐵, ia akan menggusur 𝐵 dari 𝑇0 dan mencoba menyisipkan 𝐵 ke dalam 𝑇1 dengan logika yang sama. Proses ini akan diulang sampai semua elemen stabil, atau peng-hashing terjadi ketika penyisipan mengalami siklus. Pengurangan jejak memori juga merupakan pertimbangan penting dalam desain kami. Pendekatan naif menyisipkan setiap ID baru ke dalam HashTable akan menghabiskan memori dengan cepat. Pengamatan model produksi nyata mengarah pada dua kesimpulan: (1) ID yang muncul hanya beberapa kali memiliki kontribusi terbatas untuk meningkatkan kualitas model. Pengamatan penting adalah bahwa ID didistribusikan berekor panjang, di mana ID populer mungkin muncul jutaan kali sementara yang tidak populer muncul tidak lebih dari sepuluh kali. Penyematan yang sesuai dengan ID yang jarang ini kurang terlatih karena kurangnya data pelatihan dan model tidak akan dapat membuat estimasi yang baik berdasarkan mereka. Pada akhirnya, ID ini kemungkinan tidak akan memengaruhi hasil, sehingga kualitas model tidak akan terpengaruh oleh penghapusan ID dengan kejadian rendah ini; (2) ID basi dari sejarah yang jauh jarang berkontribusi pada model saat ini karena banyak di antaranya tidak pernah dikunjungi. Ini mungkin disebabkan oleh pengguna yang tidak lagi aktif, atau video pendek yang sudah usang. Menyimpan penyematan untuk ID ini tidak dapat membantu model dengan cara apa pun selain menguras memori PS kami dengan sia-sia. Berdasarkan pengamatan ini, kami merancang beberapa heuristik pemfilteran ID fitur untuk implementasi HashTable yang lebih efisien memori: (1) ID difilter sebelum dimasukkan ke dalam tabel penyematan. Kami memiliki dua metode pemfilteran: Pertama, kami memfilter berdasarkan kejadian mereka sebelum dimasukkan sebagai kunci, di mana ambang batas kejadian adalah hyperparameter yang dapat disetel yang bervariasi untuk setiap model; Selain itu, kami menggunakan filter probabilistik yang membantu mengurangi penggunaan memori lebih lanjut; ![#Figure 4: Streaming Engine. Siklus umpan balik informasi dari [Pengguna → Server Model → Pekerja Pelatihan → Server Model → Pengguna] akan memakan waktu lama ketika mengambil jalur Pelatihan Batch, sementara Pelatihan Online akan menutup siklus lebih instan.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID diberi waktu dan diatur untuk kedaluwarsa setelah tidak aktif selama periode waktu yang ditentukan. Waktu kedaluwarsa juga dapat disetel untuk setiap tabel penyematan untuk memungkinkan pembedaan fitur dengan sensitivitas yang berbeda terhadap informasi historis. Dalam implementasi kami, HashTable diimplementasikan sebagai operasi sumber daya TensorFlow. Mirip dengan Variabel, pencarian dan pembaruan juga diimplementasikan sebagai operasi TensorFlow asli untuk integrasi yang lebih mudah dan kompatibilitas yang lebih baik. 2.2 Pelatihan Online Di Monolith, pelatihan dibagi menjadi dua tahap (Gambar 1): (1) Tahap pelatihan batch. Tahap ini berfungsi sebagai loop pelatihan TensorFlow biasa: Di setiap langkah pelatihan, seorang pekerja pelatihan membaca satu mini-batch contoh pelatihan dari penyimpanan, meminta parameter dari PS, menghitung lintasan maju dan mundur, dan akhirnya mendorong parameter yang diperbarui ke PS pelatihan. Sedikit berbeda dari tugas pembelajaran mendalam umum lainnya, kami hanya melatih dataset kami untuk satu lintasan. Pelatihan batch berguna untuk melatih data historis ketika kami memodifikasi arsitektur model kami dan melatih ulang model; (2) Tahap pelatihan online. Setelah model diterapkan ke penyajian online, pelatihan tidak berhenti tetapi memasuki tahap pelatihan online. Alih-alih membaca contoh mini-batch dari penyimpanan, seorang pekerja pelatihan mengonsumsi data real-time secara on-the-fly dan memperbarui PS pelatihan. PS pelatihan secara berkala menyinkronkan parameternya ke PS penyajian, yang akan berlaku pada sisi pengguna segera. Hal ini memungkinkan model kami untuk secara interaktif beradaptasi sesuai dengan umpan balik pengguna secara real-time. Monolith dibangun dengan kemampuan untuk beralih mulus antara pelatihan batch dan pelatihan online. Hal ini dimungkinkan oleh desain mesin streaming kami seperti yang diilustrasikan oleh Gambar 2.2.1 Mesin Streaming. 4. Dalam desain kami, kami menggunakan satu antrian Kafka [ ] untuk mencatat tindakan pengguna (misalnya, Klik item atau sukai item dll.) dan antrian Kafka lain untuk fitur. Inti dari mesin adalah pekerjaan streaming Flink [ ] untuk Penggabung Fitur online. Penggabung online menggabungkan fitur dengan label dari tindakan pengguna dan menghasilkan contoh pelatihan, yang kemudian ditulis ke antrian Kafka. Antrian untuk contoh pelatihan dikonsumsi oleh pelatihan online dan pelatihan batch: 13 4 Untuk pelatihan online, pekerja pelatihan langsung membaca data dari antrian Kafka; Untuk pelatihan batch, pekerjaan pembuangan data akan terlebih dahulu membuang data ke HDFS [ ]; Setelah data di HDFS terakumulasi sejumlah tertentu, pekerja pelatihan akan mengambil data dari HDFS dan melakukan pelatihan batch. 18 Parameter yang diperbarui di PS pelatihan akan didorong ke PS penyajian sesuai dengan jadwal sinkronisasi parameter. Dalam aplikasi dunia nyata, log tindakan pengguna dan fitur dialirkan ke penggabung online (Gambar tanpa jaminan urutan waktu. Oleh karena itu, kami menggunakan kunci unik untuk setiap permintaan sehingga tindakan pengguna dan fitur dapat dipasangkan dengan benar. 2.2.2 Penggabung Online. 5) Kelambatan tindakan pengguna juga bisa menjadi masalah. Misalnya, pengguna mungkin perlu beberapa hari sebelum mereka memutuskan untuk membeli item yang disajikan kepada mereka beberapa hari yang lalu. Ini adalah tantangan bagi penggabung karena jika semua fitur disimpan dalam cache, itu tidak akan muat dalam memori. Dalam sistem kami, penyimpanan kunci-nilai di disk digunakan untuk menyimpan fitur yang menunggu selama periode waktu tertentu. Ketika log tindakan pengguna tiba, ia pertama-tama mencari cache dalam memori, dan kemudian mencari penyimpanan kunci-nilai jika cache hilang. Masalah lain yang muncul dalam aplikasi dunia nyata adalah bahwa distribusi contoh negatif dan positif sangat tidak merata, di mana jumlah yang pertama bisa berkali-kali lebih tinggi daripada yang terakhir. Untuk mencegah contoh positif kewalahan oleh contoh negatif, strategi umum adalah melakukan pengambilan sampel negatif. Ini tentu akan mengubah distribusi yang mendasari model yang dilatih, menyesuaikannya menuju probabilitas yang lebih tinggi untuk membuat prediksi positif. Sebagai perbaikan, kami menerapkan koreksi log odds [ ] selama penyajian, memastikan bahwa model online adalah estimator yang tidak bias dari distribusi asli. 19 Selama pelatihan online, kluster pelatihan Monolith terus menerima data dari modul penyajian online dan memperbarui parameter pada PS pelatihan. Langkah krusial untuk memungkinkan PS penyajian online mendapatkan manfaat dari parameter yang baru dilatih ini adalah sinkronisasi parameter model yang diperbarui. Di lingkungan produksi, kami menghadapi beberapa tantangan: 2.2.3 Sinkronisasi Parameter. Model pada PS penyajian online tidak boleh berhenti menyajikan saat memperbarui. Model kami dalam produksi biasanya berukuran beberapa terabyte, dan sebagai hasilnya mengganti semua parameter membutuhkan waktu. Tidak dapat ditoleransi untuk menghentikan PS online dari menyajikan model selama proses penggantian, dan pembaruan harus dilakukan secara on-the-fly; Mentransfer model multi-terabyte secara keseluruhan dari PS pelatihan ke PS penyajian online akan memberikan tekanan besar pada bandwidth jaringan dan memori pada PS, karena memerlukan ukuran memori model ganda untuk menerima model yang baru tiba. Agar pelatihan online dapat diskalakan hingga ukuran skenario bisnis kami, kami merancang mekanisme sinkronisasi parameter periodik on-the-fly inkremental di Monolith berdasarkan beberapa karakteristik model kami yang patut diperhatikan: (1) Parameter jarang mendominasi ukuran model rekomendasi; (2) Mengingat rentang waktu jendela yang singkat, hanya sebagian kecil ID yang dilatih dan penyematannya diperbarui; (3) Variabel padat bergerak jauh lebih lambat daripada penyematan jarang. Ini karena dalam pengoptimal berbasis momentum, akumulasi momentum untuk variabel padat diperbesar oleh ukuran data pelatihan rekomendasi yang sangat besar, sementara hanya beberapa penyematan jarang yang menerima pembaruan dalam satu batch data. (1) dan (2) memungkinkan kami untuk mengeksploitasi pembaruan jarang di semua ID fitur. Di Monolith, kami mempertahankan kumpulan hash kunci yang disentuh, yang mewakili ID yang penyematannya dilatih sejak sinkronisasi parameter terakhir. Kami mendorong subset parameter jarang yang kuncinya ada dalam kumpulan kunci yang disentuh dengan interval waktu menit dari PS pelatihan ke PS penyajian online. Paket pembaruan parameter inkremental yang relatif kecil ini ringan untuk transmisi jaringan dan tidak akan menyebabkan lonjakan memori tajam selama sinkronisasi. Kami juga mengeksploitasi (3) untuk lebih mengurangi I/O jaringan dan penggunaan memori dengan menetapkan jadwal sinkronisasi yang lebih agresif untuk parameter jarang, sambil memperbarui parameter padat lebih jarang. Ini dapat memberi kami situasi di mana parameter padat yang kami sajikan adalah versi yang relatif basi dibandingkan dengan bagian jarang. Namun, ketidakkonsistenan semacam itu dapat ditoleransi karena alasan yang disebutkan dalam (3) karena tidak ada kerugian yang mencolok yang teramati. 2.3 Toleransi Kesalahan Sebagai sistem dalam produksi, Monolith dirancang dengan kemampuan untuk memulihkan PS jika terjadi kegagalan. Pilihan umum untuk toleransi kesalahan adalah membuat snapshot keadaan model secara berkala, dan pulih dari snapshot terbaru ketika kegagalan PS terdeteksi. Pilihan frekuensi snapshot memiliki dua dampak utama: (1) Kualitas model. Secara intuitif, kualitas model lebih sedikit menderita dari hilangnya riwayat terbaru dengan peningkatan frekuensi snapshot. (2) Overhead komputasi. Membuat snapshot model multi-terabyte tidak gratis. Ini menimbulkan salinan memori besar dan I/O disk. Sebagai trade-off antara kualitas model dan overhead komputasi, Monolith membuat snapshot semua PS pelatihan setiap hari. Meskipun PS akan kehilangan pembaruan satu hari jika terjadi kegagalan, kami menemukan bahwa penurunan kinerja dapat ditoleransi melalui eksperimen kami. 3 EVALUASI Untuk pemahaman yang lebih baik tentang manfaat dan trade-off yang dibawa oleh desain yang kami usulkan, kami melakukan beberapa eksperimen dalam skala produksi dan uji A/B dengan lalu lintas penyajian langsung untuk mengevaluasi dan memverifikasi Monolith dari berbagai aspek. Kami bertujuan untuk menjawab pertanyaan-pertanyaan berikut melalui eksperimen kami: (1) Seberapa besar manfaat yang bisa kita dapatkan dari HashTable tanpa tabrakan? (2) Seberapa penting pelatihan online real-time? (3) Apakah desain sinkronisasi parameter Monolith cukup kuat dalam skenario produksi skala besar? Di bagian ini, kami pertama-tama menyajikan pengaturan eksperimental kami dan kemudian membahas hasil dan temuan kami secara rinci. 3.1 Pengaturan Eksperimental Seperti yang dijelaskan di Bagian tabel penyematan di Monolith diimplementasikan sebagai HashTable tanpa tabrakan. Untuk membuktikan perlunya menghindari tabrakan dalam tabel penyematan dan mengukur keuntungan dari implementasi kami yang tanpa tabrakan, kami melakukan dua kelompok eksperimen pada dataset Movielens dan pada dataset produksi internal kami: 3.1.1 Tabel Penyematan. 2.1, (1) Dataset ml-25m [ ]. Ini adalah dataset publik standar untuk peringkat film, berisi 25 juta peringkat yang melibatkan sekitar 162.000 pengguna dan 62.000 film. MovieLens 11 • . Label asli adalah peringkat dari Pra-pemrosesan label 0,5 hingga 5,0, sedangkan dalam produksi tugas kami sebagian besar menerima sinyal biner dari pengguna. Untuk mensimulasikan model produksi kami dengan lebih baik, kami mengonversi label skala menjadi label biner dengan memperlakukan skor ≥ 3,5 sebagai sampel positif dan sisanya sebagai sampel negatif. • Model dan metrik. Kami mengimplementasikan model DeepFM standar, arsitektur model yang umum digunakan untuk masalah rekomendasi. Ini terdiri dari komponen FM dan komponen padat (Gambar 6). Prediksi dievaluasi oleh AUC karena ini adalah pengukuran utama untuk model nyata. • Tabrakan penyematan. Dataset ini berisi sekitar 160 ribu ID pengguna dan 60 ribu ID film. Untuk membandingkan dengan versi tabel penyematan tanpa tabrakan, kami melakukan kelompok eksperimen lain di mana ID dipra-proses dengan hashing MD5 dan kemudian dipetakan ke ruang ID yang lebih kecil. Akibatnya, beberapa ID akan berbagi penyematannya dengan yang lain. Tabel 1 menunjukkan statistik rinci ID pengguna dan film sebelum dan sesudah hashing. (2) . Dataset Rekomendasi Internal Kami juga melakukan eksperimen pada model rekomendasi di lingkungan produksi. Model ini umumnya mengikuti arsitektur multi-tower, dengan setiap tower bertanggung jawab untuk mempelajari prediksi jenis perilaku pengguna tertentu. Setiap model memiliki sekitar 1000 tabel penyematan, dan distribusi ukuran tabel penyematan sangat tidak merata; Ruang ID asli tabel penyematan adalah 248. Dalam baseline kami, kami menerapkan trik hashing dengan menguraikan untuk mengendalikan ukuran tabel penyematan. Lebih khusus lagi, kami menggunakan dua tabel penyematan yang lebih kecil alih-alih satu yang raksasa untuk menghasilkan penyematan unik untuk setiap ID dengan kombinasi vektor: di mana 𝐸𝑟 , 𝐸𝑞 adalah penyematan yang sesuai dengan 𝐼𝐷𝑟 , 𝐼𝐷𝑞. Ini secara efektif mengurangi ukuran tabel penyematan dari 248 menjadi 225; • Model ini disajikan dalam produksi nyata, dan kinerja eksperimen ini diukur dengan AUC online dengan lalu lintas penyajian nyata. Selama pelatihan online, kami memperbarui PS penyajian online kami dengan kumpulan parameter terbaru dengan interval tingkat menit. Kami merancang dua kelompok eksperimen untuk memverifikasi kualitas model dan ketahanan sistem. 3.1.2 Pelatihan Online. (1) . Untuk menyelidiki perlunya frekuensi pembaruan tingkat menit, kami melakukan eksperimen yang menyinkronkan parameter dari model pelatihan ke model prediksi dengan interval yang berbeda. Frekuensi Pembaruan Dataset yang kami gunakan adalah dataset Criteo Display Ads Challenge3, dataset standar skala besar untuk benchmarking model CTR. Ini berisi data 7 hari yang diurutkan secara kronologis yang mencatat fitur dan tindakan klik. Untuk eksperimen ini, kami menggunakan model DeepFM standar seperti yang dijelaskan di 6. Untuk mensimulasikan pelatihan online, kami melakukan pra-pemrosesan berikut untuk dataset. Kami mengambil data 7 hari dari dataset, dan membaginya menjadi dua bagian: 5 hari data untuk pelatihan batch, dan 2 hari untuk pelatihan online. Kami selanjutnya membagi 2 hari data menjadi 𝑁 shard secara kronologis. Pelatihan online disimulasikan oleh algoritma 1. Dengan demikian, kami mensimulasikan sinkronisasi parameter yang dilatih ke PS penyajian online dengan interval yang ditentukan oleh jumlah shard data. Kami bereksperimen dengan 𝑁 = 10, 50, 100, yang kira-kira sesuai dengan interval pembaruan 5 jam, 1 jam, dan 30 menit. (2) . Selain itu, kami juga melakukan eksperimen langsung dengan lalu lintas penyajian nyata untuk lebih menunjukkan pentingnya pelatihan online dalam aplikasi dunia nyata. Eksperimen A/B ini membandingkan pelatihan online dengan pelatihan batch pada salah satu model Iklan kami dalam produksi. Eksperimen Langsung 3.2 Hasil dan Analisis Hasil dari dataset MovieLens dan dataset rekomendasi Internal keduanya menunjukkan bahwa tabrakan penyematan akan membahayakan kualitas model. 3.2.1 Efek Tabrakan Penyematan. (1) Model dengan HashTable tanpa tabrakan secara konsisten mengungguli model dengan tabrakan. Kesimpulan ini tetap berlaku terlepas dari Peningkatan jumlah epoch pelatihan. Seperti yang ditunjukkan pada Gambar model dengan tabel penyematan tanpa tabrakan memiliki AUC yang lebih tinggi sejak epoch pertama dan konvergen pada nilai yang lebih tinggi; 7, Perubahan distribusi seiring berjalannya waktu karena Concept Drift. Seperti yang ditunjukkan pada Gambar model dengan tabel penyematan tanpa tabrakan juga kuat seiring berjalannya waktu dan konteks pengguna/item berubah. 8, (2) Kelangkaan data yang disebabkan oleh tabel penyematan tanpa tabrakan tidak menyebabkan overfitting model. Seperti yang ditunjukkan pada Gambar model dengan tabel penyematan tanpa tabrakan tidak mengalami overfitting setelah konvergen. 7, ![#Figure 8: Effect of Embedding Collision On A Recommendation Model In Production Kami mengukur kinerja model rekomendasi ini dengan AUC penyajian online, yang berfluktuasi di berbagai hari karena concept-drift.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-d9i3eb9.jpeg) ![#Figure 9: Online training v.s. Batch training on Criteo dataset. Garis biru: AUC model dengan pelatihan online; Garis kuning: AUC model pelatihan batch yang dievaluasi terhadap data streaming.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-o0j3ej8.jpeg) Kami menemukan bahwa frekuensi sinkronisasi parameter yang lebih tinggi selalu kondusif untuk meningkatkan AUC penyajian online, dan bahwa model penyajian online lebih toleran terhadap hilangnya beberapa shard PS daripada yang kami harapkan. 3.2.2 Pelatihan Online: Menukar Keandalan Demi Realtime. (1) . Dalam eksperimen pelatihan streaming online kami dengan dataset Criteo Display Ads Challenge, kualitas model secara konsisten meningkat dengan peningkatan frekuensi sinkronisasi parameter, sebagaimana terbukti dari perbandingan dari dua perspektif: Efek Frekuensi Sinkronisasi Parameter (1) • Model dengan pelatihan online berkinerja lebih baik daripada model tanpa. Gambar membandingkan AUC model pelatihan online yang dievaluasi oleh shard data berikut versus model pelatihan batch yang dievaluasi oleh setiap shard data; 9a, 9b, 9c • Model dengan interval sinkronisasi parameter yang lebih kecil berkinerja lebih baik daripada yang dengan interval yang lebih besar. Gambar dan Tabel membandingkan AUC penyajian online untuk model dengan interval sinkronisasi 5 jam, 1 jam, dan 30 menit. 10 2 Eksperimen A/B langsung antara pelatihan online dan pelatihan batch pada model Iklan dalam produksi juga menunjukkan bahwa ada peningkatan signifikan dalam AUC penyajian online (Tabel 3).