Di Sebalik Monolit ByteDance: Enjin yang Menggerakkan Suapan Kandungan yang Lebih Pintar dan Pantas

```html 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∗, Fudan University 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 berskala dan waktu nyata sangat penting bagi banyak bisnis yang didorong oleh umpan balik pelanggan yang peka waktu, seperti peringkat video pendek atau iklan online. Meskipun kerangka kerja pembelajaran mendalam skala produksi seperti Ten-sorFlow atau PyTorch diadopsi secara luas, kerangka kerja tujuan umum 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 tersebut 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 nyata dari sistem rekomendasi lainnya. Kontribusi kami bersifat multifaset: pertama, kami membuat tabel embedding tanpa tabrakan dengan optimasi seperti embedding yang kedaluwarsa dan pemfilteran frekuensi untuk mengurangi jejak memori; kedua, kami menyediakan arsitektur pelatihan online siap produksi dengan toleransi kesalahan yang tinggi; akhirnya, kami membuktikan bahwa keandalan sistem dapat ditukar dengan pembelajaran waktu nyata. Monolith telah berhasil diterapkan dalam produk BytePlus Recommend2. Monolith 1 PENDAHULUAN 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 waktu nyata adalah tujuan umum dari aplikasi bisnis ini. Untuk mencapai ini, informasi dari interaksi terakhir pengguna sering digunakan sebagai masukan utama untuk melatih model, karena itu akan paling menggambarkan potret pengguna dan membuat prediksi tentang minat dan perilaku pengguna di masa depan. Pembelajaran mendalam telah mendominasi model rekomendasi [ , , , , , ] karena data pengguna dalam jumlah besar sangat cocok untuk model saraf yang didorong oleh data secara massal. 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, atau dikenal sebagai Concept Drift [8]. Perbedaan tersebut telah menimbulkan tantangan unik bagi peneliti dan insinyur yang bekerja pada sistem rekomendasi. 1.1 Kekeramatan dan Dinamisme Data untuk rekomendasi sebagian besar mengandung fitur kategorikal yang jarang, beberapa di antaranya muncul dengan frekuensi rendah. Praktik umum memetakannya ke ruang embedding berdimensi tinggi akan menimbulkan serangkaian masalah: • Berbeda dengan model bahasa di mana jumlah bagian kata terbatas, jumlah pengguna dan item peringkat adalah magnitudya lebih besar. Tabel embedding yang sangat besar ini sulit untuk dimasukkan ke dalam memori satu host; • Lebih buruk lagi, ukuran tabel embedding diharapkan tumbuh seiring waktu karena lebih banyak pengguna dan item ditambahkan, sementara kerangka kerja seperti [ , ] menggunakan variabel padat berukuran tetap untuk merepresentasikan tabel embedding. 1 17 Dalam praktiknya, banyak sistem mengadopsi hashing tabrakan rendah [ , ] sebagai cara untuk mengurangi jejak memori dan memungkinkan pertumbuhan ID. Ini bergantung pada asumsi yang terlalu idealis bahwa ID dalam tabel embedding didistribusikan secara merata dalam frekuensi, dan tabrakan tidak berbahaya bagi kualitas model. Sayangnya, ini jarang terjadi pada sistem rekomendasi dunia nyata, di mana sejumlah kecil pengguna atau item memiliki kejadian yang jauh lebih banyak. Dengan pertumbuhan organik ukuran tabel embedding, kemungkinan tabrakan kunci hash meningkat dan menyebabkan penurunan kualitas model 3 6 [3]. Oleh karena itu, permintaan alami untuk sistem rekomendasi skala produksi adalah memiliki kapasitas untuk menangkap sebanyak mungkin fitur dalam parameternya, dan juga memiliki kemampuan untuk secara elastis menyesuaikan jumlah pengguna dan item yang coba didaftarkannya. 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 menggeser semangat mereka setiap menit berikutnya. Akibatnya, distribusi data pengguna yang mendasarinya tidak stasioner, fenomena yang biasa disebut sebagai Concept Drift [8]. 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 dengan waktu nyata untuk mencerminkan minat terbaru pengguna. Mengingat perbedaan ini dan pengamatan terhadap masalah yang timbul dari produksi kami, kami merancang , sistem rekomendasi skala besar untuk mengatasi kesulitan ini. Kami melakukan eksperimen ekstensif untuk memverifikasi dan mengulang desain kami di lingkungan produksi. Monolith mampu Monolith (1) Memberikan kekuatan ekspresif penuh untuk fitur yang jarang melalui desain tabel hash tanpa tabrakan dan mekanisme pengeluaran fitur dinamis; (2) Melakukan umpan balik penyajian kembali 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 canggih tanpa membebani kekuatan komputasi server kami secara berlebihan. Sisa makalah ini disusun sebagai berikut. Kami pertama-tama menguraikan detail desain tentang bagaimana Monolith mengatasi tantangan yang ada dengan tabel hash tanpa tabrakan dan pelatihan waktu nyata di Bagian 2. Eksperimen dan hasil akan disajikan di Bagian 3, bersama dengan kesimpulan yang diuji 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 pekerjaan ini. 2 DESAIN Arsitektur keseluruhan Monolith umumnya mengikuti pengaturan Worker- arameter erver TensorFlow yang terdistribusi (Gambar Dalam arsitektur Worker-PS, mesin diberi peran yang berbeda; mesin Worker bertanggung jawab untuk melakukan komputasi seperti yang didefinisikan oleh grafik, 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 embedding yang sesuai dengan fitur jarang. Dalam desain kami, baik parameter padat maupun jarang adalah bagian dari Grafik TensorFlow, 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 kami untuk representasi parameter jarang adalah untuk menghindari penggabungan informasi dari ID yang berbeda ke dalam embedding berukuran tetap yang sama. Mensimulasikan tabel embedding berukuran dinamis dengan Variabel TensorFlow yang siap pakai pasti akan menyebabkan tabrakan ID, yang diperburuk ketika ID baru tiba 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 dalamnya, yang mendukung penyisipan kunci baru tanpa bertabrakan dengan yang sudah ada. Cuckoo Hashing mencapai kompleksitas waktu 𝑂 (1) kasus terburuk untuk pencarian dan penghapusan, dan waktu amortisasi yang diharapkan 𝑂 (1) untuk penyisipan. Seperti yang diilustrasikan pada Gambar tabel ini 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 𝑇0, pertama-tama ia mencoba menempatkan 𝐴 di ℎ0 (𝐴); Jika ℎ0 (𝐴) ditempati oleh elemen lain 𝐵, ia akan mengeluarkan 𝐵 dari 𝑇0 dan mencoba menyisipkan 𝐵 ke 𝑇1 dengan logika yang sama. Proses ini akan diulang sampai semua elemen stabil, atau rehash terjadi ketika penyisipan mengalami siklus. Pengurangan jejak memori juga merupakan pertimbangan penting dalam desain kami. Pendekatan naif untuk menyisipkan setiap ID baru ke dalam HashTable akan menghabiskan memori dengan cepat. Pengamatan model produksi nyata mengarah pada dua kesimpulan: (1) ID yang hanya muncul beberapa kali memiliki kontribusi terbatas untuk meningkatkan kualitas model. Pengamatan penting adalah bahwa ID didistribusikan dalam ekor panjang, di mana ID populer dapat muncul jutaan kali sementara yang tidak populer muncul tidak lebih dari sepuluh kali. Embedding 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 mempengaruhi hasil, jadi kualitas model tidak akan terpengaruh oleh penghapusan ID dengan kejadian rendah ini; (2) ID usang dari riwayat yang jauh jarang berkontribusi pada model saat ini karena banyak di antaranya tidak pernah dikunjungi. Ini bisa jadi karena pengguna yang tidak lagi aktif, atau video pendek yang sudah ketinggalan zaman. Menyimpan embedding untuk ID ini tidak dapat membantu model sama sekali 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 mereka diakui ke dalam tabel embedding. Kami memiliki dua metode pemfilteran: Pertama kami memfilter berdasarkan kejadian mereka sebelum mereka disisipkan sebagai kunci, di mana ambang kejadian adalah hyperparameter yang dapat disesuaikan yang bervariasi untuk setiap model; Selain itu, kami menggunakan filter probabilistik yang membantu mengurangi penggunaan memori lebih lanjut; ![#Figure 4: Streaming Engine. Lingkaran 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 lingkaran lebih cepat.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID diberi stempel waktu dan diatur untuk kedaluwarsa setelah tidak aktif untuk periode waktu yang telah ditentukan. Waktu kedaluwarsa juga dapat disesuaikan untuk setiap tabel embedding untuk memungkinkan pembedaan fitur dengan sensitivitas 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, pekerja pelatihan membaca satu mini-batch contoh pelatihan dari penyimpanan, meminta parameter dari PS, menghitung lintasan maju dan mundur, dan akhirnya mengirimkan parameter yang diperbarui ke PS pelatihan. Sedikit berbeda dari tugas pembelajaran mendalam umum lainnya, kami hanya melatih kumpulan data kami untuk satu lintasan. Pelatihan batch berguna untuk melatih data historis ketika kami memodifikasi arsitektur model kami dan melatih kembali 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, 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 segera berlaku di sisi pengguna. Ini memungkinkan model kami untuk beradaptasi secara interaktif sesuai dengan umpan balik pengguna secara real-time. Monolith dibangun dengan kemampuan untuk beralih mulus antara pelatihan batch dan pelatihan online. Ini dimungkinkan oleh desain mesin streaming kami seperti yang diilustrasikan oleh Gambar 2.2.1 Streaming Engine. 4. Dalam desain kami, kami menggunakan satu antrian Kafka [ ] untuk mencatat tindakan pengguna (Misalnya, Klik item atau suka item, dll.) dan antrian Kafka lain untuk fitur. Inti dari mesin adalah pekerjaan streaming Flink [ ] untuk Penyatuan fitur online. Penyatuan 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 dalam jumlah tertentu, pekerja pelatihan akan mengambil data dari HDFS dan melakukan pelatihan batch. 18 Parameter yang diperbarui di PS pelatihan akan dikirim ke PS penyajian sesuai dengan jadwal sinkronisasi parameter. Dalam aplikasi dunia nyata, log tindakan pengguna dan fitur dialirkan ke penyatu 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 Online Joiner. 5) Keterlambatan tindakan pengguna juga bisa menjadi masalah. Misalnya, pengguna mungkin membutuhkan beberapa hari sebelum mereka memutuskan untuk membeli barang yang disajikan beberapa hari yang lalu. Ini adalah tantangan bagi penyatu karena jika semua fitur disimpan dalam cache, itu tidak akan muat di memori. Dalam sistem kami, penyimpanan kunci-nilai di disk digunakan untuk menyimpan fitur yang menunggu lebih dari periode waktu tertentu. Ketika log tindakan pengguna tiba, pertama-tama ia 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 lipat 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 mendasarinya dari model yang dilatih, menyesuaikannya menuju kemungkinan prediksi positif yang lebih tinggi. 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 Mono-lith terus menerima data dari modul penyajian online dan memperbarui parameter pada PS pelatihan. Langkah penting untuk memungkinkan PS penyajian online mendapat 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 melayani saat memperbarui. Model kami dalam produksi biasanya berukuran beberapa terabyte, dan sebagai hasilnya mengganti semua parameter membutuhkan waktu. Akan sangat tidak tertahankan untuk menghentikan PS online dari melayani 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 membutuhkan ukuran memori model dua kali lipat untuk menerima model yang baru tiba. Agar pelatihan online dapat diskalakan ke ukuran skenario bisnis kami, kami merancang mekanisme sinkronisasi parameter periodik on-the-fly inkremental di Monolith berdasarkan beberapa karakteristik model kami yang terlihat: (1) Parameter jarang mendominasi ukuran model rekomendasi; (2) Mengingat jendela waktu yang singkat, hanya sebagian kecil dari ID yang dilatih dan embeddingnya diperbarui; (3) Variabel padat bergerak jauh lebih lambat daripada embedding jarang. Ini karena dalam pengoptimal momentum, akumulasi momentum untuk variabel padat diperkuat oleh ukuran data pelatihan rekomendasi yang sangat besar, sementara hanya sedikit embedding jarang yang menerima pembaruan dalam satu batch data. (1) dan (2) memungkinkan kami untuk memanfaatkan pembaruan jarang di semua ID fitur. Di Monolith, kami memelihara kumpulan hash dari kunci yang disentuh, mewakili ID yang embeddingnya dilatih sejak sinkronisasi parameter terakhir. Kami mengirimkan subset parameter jarang yang kuncinya ada dalam set 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 memanfaatkan (3) untuk lebih mengurangi I/O jaringan dan penggunaan memori dengan mengatur jadwal sinkronisasi yang lebih agresif untuk parameter jarang, sementara memperbarui parameter padat lebih jarang. Ini dapat membuat kami berada dalam situasi di mana parameter padat yang kami layani adalah versi yang relatif basi dibandingkan dengan bagian yang 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 terpengaruh oleh hilangnya riwayat terbaru dengan peningkatan frekuensi snapshot. (2) Overhead komputasi. Membuat snapshot model multi-terabyte tidak gratis. Ini menimbulkan salinan memori dan I/O disk dalam jumlah besar. 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 berikut melalui eksperimen kami: (1) Seberapa besar manfaat yang bisa kita dapatkan dari HashTable tanpa tabrakan? (2) Seberapa penting pelatihan online waktu nyata? (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 embedding di Monolith diimplementasikan sebagai HashTable tanpa tabrakan. Untuk membuktikan perlunya menghindari tabrakan dalam tabel embedding dan untuk mengukur keuntungan dari implementasi kami yang tanpa tabrakan, kami melakukan dua kelompok eksperimen pada kumpulan data Movielens dan pada kumpulan data produksi internal kami: 3.1.1 Tabel Embedding. 2.1, (1) Kumpulan data ml-25m [ ]. Ini adalah kumpulan data 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, sementara 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 [9] standar, arsitektur model yang umum digunakan untuk masalah rekomendasi. Ini terdiri dari komponen FM dan komponen padat (Gambar 6). Prediksi dievaluasi oleh AUC [2] karena ini adalah pengukuran utama untuk model nyata. • Tabrakan embedding. Kumpulan data ini berisi sekitar 160K ID pengguna dan 60K ID film. Untuk membandingkan dengan versi tabel embedding 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 embedding mereka 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 belajar memprediksi jenis perilaku pengguna yang terspesialisasi. Setiap model memiliki sekitar 1000 tabel embedding, dan distribusi ukuran tabel embedding sangat tidak merata; Ruang ID asli tabel embedding adalah 248. Dalam baseline kami, kami menerapkan trik hashing dengan mendekomposisi untuk menahan ukuran tabel embedding. Lebih spesifik, kami menggunakan dua tabel embedding yang lebih kecil alih-alih satu tabel yang sangat besar untuk menghasilkan embedding unik untuk setiap ID melalui kombinasi vektor: di mana 𝐸𝑟 , 𝐸𝑞 adalah embedding yang sesuai dengan 𝐼𝐷𝑟 , 𝐼𝐷𝑞. Ini secara efektif mengurangi ukuran tabel embedding dari 248 menjadi 225; • Model ini disajikan dalam produksi nyata, dan kinerja eksperimen ini diukur oleh AUC online dengan lalu lintas penyajian nyata. Selama pelatihan online, kami memperbarui PS penyajian online kami dengan set 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 Kumpulan data yang kami gunakan adalah kumpulan data Criteo Display Ads Challenge3, kumpulan data skala besar standar untuk benchmark model CTR. Ini berisi 7 hari data yang diurutkan secara kronologis yang mencatat fitur dan tindakan klik. Untuk eksperimen ini, kami menggunakan model DeepFM standar seperti yang dijelaskan di [9] 6. Untuk mensimulasikan pelatihan online, kami melakukan pra-pemrosesan berikut untuk kumpulan data. Kami mengambil 7 hari data dari kumpulan data, 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 kumpulan data MovieLens dan kumpulan data rekomendasi Internal keduanya menunjukkan bahwa tabrakan embedding akan membahayakan kualitas model. 3.2.1 Efek Tabrakan Embedding. (1) Model dengan HashTable tanpa tabrakan secara konsisten mengungguli model dengan tabrakan. Kesimpulan ini berlaku terlepas dari Peningkatan jumlah epoch pelatihan. Seperti yang ditunjukkan pada Gambar model dengan tabel embedding tanpa tabrakan memiliki AUC 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 embedding tanpa tabrakan juga kuat seiring berjalannya waktu dan konteks pengguna/item berubah. 8, (2) Kekeramatan data yang disebabkan oleh tabel embedding tanpa tabrakan tidak menyebabkan overfitting model. Seperti yang ditunjukkan pada Gambar model dengan tabel embedding 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 sepanjang 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 model penyajian online lebih toleran terhadap hilangnya beberapa shard PS daripada yang kami harapkan. 3.2.2 Pelatihan Online: Menukar Keandalan Demi Waktu Nyata. (1) . Dalam eksperimen pelatihan streaming online kami dengan kumpulan data 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). Terinspirasi oleh pengamatan ini, kami menyinkronkan parameter jarang ke PS penyajian model produksi kami sesering mungkin (saat ini pada tingkat menit), sejauh overhead komputasi dan keandalan sistem dapat bertahan. Mengingat bahwa variabel padat membutuhkan pembaruan yang lebih jarang seperti yang dibahas dalam