Di Dalam Monolit ByteDance: Enjin yang Memberi Kuasa Suapan Kandungan Lebih Pintar dan Pantas

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 sensitif terhadap waktu, seperti peringkat video pendek atau iklan online. Meskipun kerangka kerja pembelajaran mendalam skala produksi seperti Ten-sorFlow atau PyTorch diadopsi secara universal, 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 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 nyata dari sistem rekomendasi lainnya. Kontribusi kami berlipat ganda: pertama, kami membuat tabel penyematan bebas tabrakan dengan optimasi seperti penyematan yang kedaluwarsa dan pemfilteran frekuensi untuk mengurangi jejak memori; kedua, kami menyediakan arsitektur pelatihan online yang siap produksi dengan ketahanan kesalahan tinggi; akhirnya, kami membuktikan bahwa keandalan sistem dapat ditukar dengan pembelajaran waktu nyata. Monolith telah berhasil diterapkan dalam 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 waktu nyata adalah tujuan umum dari aplikasi bisnis ini. Untuk tujuan ini, informasi dari interaksi terbaru pengguna sering digunakan sebagai input 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 saraf yang didorong oleh data masif. Namun, upaya untuk memanfaatkan kekuatan pembelajaran mendalam dalam sistem rekomendasi tingkat industri terus menghadapi masalah yang timbul dari karakteristik unik data yang berasal dari perilaku pengguna dunia nyata. Data ini sangat berbeda dari yang digunakan dalam masalah pembelajaran mendalam konvensional seperti pemodelan bahasa atau visi komputer dalam dua aspek: 5 6 10 12 20 21 (1) Fitur-fiturnya sebagian besar jarang, kategorikal, dan berubah secara dinamis; (2) Distribusi data pelatihan yang mendasarinya tidak stasioner, atau dikenal sebagai Concept Drift . Perbedaan seperti itu telah menimbulkan tantangan unik bagi para peneliti dan insinyur yang bekerja pada sistem rekomendasi. 1.1 Ketersebaran 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 jauh lebih besar. Tabel penyematan yang sangat besar ini sulit untuk dimasukkan ke dalam memori satu host; • Lebih buruk lagi, ukuran tabel penyematan diharapkan bertambah seiring waktu karena lebih banyak pengguna dan item diterima, sementara kerangka kerja seperti [ , ] menggunakan variabel padat berukuran tetap untuk mewakili tabel penyematan. 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 penyematan didistribusikan secara merata dalam frekuensi, dan tabrakan tidak berbahaya bagi kualitas model. Sayangnya, hal ini jarang terjadi pada sistem rekomendasi dunia nyata, di mana sejumlah kecil pengguna atau item memiliki kejadian yang secara signifikan lebih banyak. Dengan pertumbuhan organik ukuran tabel penyematan, kemungkinan tabrakan kunci hash meningkat dan menyebabkan penurunan kualitas model 3 6 . 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 menyesuaikan jumlah pengguna dan item yang coba dicatat secara elastis. 1.2 Distribusi Tidak 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 umumnya 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. Sehubungan dengan perbedaan ini dan pengamatan masalah yang timbul dari produksi kami, kami merancang , sistem rekomendasi skala besar untuk mengatasi poin-poin 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 yang jarang secara desain tabel hash bebas tabrakan dan mekanisme penggusuran fitur dinamis; (2) Melakukan umpan balik penyajian kembali ke pelatihan secara real-time dengan pelatihan online. Didukung oleh kapasitas arsitektural 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 daya komputasi server kami. Sisa makalah ini diatur sebagai berikut. Kami pertama-tama menguraikan detail desain tentang bagaimana Monolith menangani tantangan yang ada dengan tabel hash bebas tabrakan dan pelatihan waktu nyata di Bagian 2. Eksperimen dan hasil akan disajikan di Bagian 3, bersama dengan kesimpulan yang diuji coba dan beberapa diskusi tentang trade-off antara sensitivitas 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 ditugaskan peran yang berbeda; mesin Worker bertanggung jawab untuk melakukan komputasi sebagaimana 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 merujuk pada tabel penyematan yang sesuai dengan fitur jarang. Dalam desain kami, baik parameter padat maupun jarang adalah bagian dari Graf TensorFlow, dan disimpan di server parameter. Mirip dengan Variabel TensorFlow untuk parameter padat, kami merancang satu set operasi HashTable yang sangat efisien, bebas tabrakan, dan fleksibel untuk parameter jarang. Sebagai pelengkap keterbatasan Tensor-Flow 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 menghindari penjejalan informasi dari ID yang berbeda ke dalam penyematan berukuran tetap yang sama. Mensimulasikan tabel penyematan berukuran dinamis dengan Variabel TensorFlow yang siap pakai pasti akan menyebabkan tabrakan ID, yang meningkat saat 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 menggunakan Cuckoo Hashmap [ ] di belakang layar, 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) amortisasi 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 𝑇0, pertama-tama mencoba menempatkan 𝐴 di ℎ0 (𝐴); Jika ℎ0 (𝐴) ditempati oleh elemen lain 𝐵, ia akan menggusur 𝐵 dari 𝑇0 dan mencoba menyisipkan 𝐵 ke 𝑇1 dengan logika yang sama. Proses ini akan diulang sampai semua elemen stabil, atau peng-hashan ulang terjadi saat penyisipan menemui 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 dalam long-tail, 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 dilatih karena kurangnya data pelatihan dan model tidak akan dapat membuat perkiraan 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 usang dari riwayat 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 sedikit 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 diterima ke dalam tabel penyematan. Kami memiliki dua metode pemfilteran: Pertama kami memfilter berdasarkan kejadiannya sebelum mereka dimasukkan sebagai kunci, di mana ambang batas kejadian adalah parameter 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. Lingkaran umpan balik informasi dari [Pengguna → Server Model → Pekerja Pelatihan → Server Model → Pengguna] akan memakan waktu lama ketika mengambil jalur Pelatihan Batch, sedangkan 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 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, pekerja pelatihan membaca 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 saat kami memodifikasi arsitektur model 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, pekerja pelatihan mengonsumsi data real-time saat bepergian dan memperbarui PS pelatihan. PS pelatihan secara berkala menyinkronkan parameternya ke PS penyajian, yang akan segera berlaku di sisi pengguna. Hal 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. Hal ini dimungkinkan oleh desain mesin streaming kami seperti yang diilustrasikan oleh Gambar 2.2.1 Streaming Engine. 4. Dalam desain kami, kami menggunakan satu antrean Kafka [ ] untuk mencatat tindakan pengguna (Misalnya. Klik item atau suka item dll.) dan antrean Kafka lain untuk fitur. Inti dari mesin adalah pekerjaan streaming Flink [ ] untuk Online Feature Joiner. Penggabung online menggabungkan fitur dengan label dari tindakan pengguna dan menghasilkan contoh pelatihan, yang kemudian ditulis ke antrean Kafka. Antrean untuk contoh pelatihan dikonsumsi oleh pelatihan online dan pelatihan batch: 13 4 Untuk pelatihan online, pekerja pelatihan langsung membaca data dari antrean Kafka; Untuk pelatihan batch, pekerjaan pengalihan data akan terlebih dahulu mengalihkan 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 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 Online Joiner. 5) Keterlambatan tindakan pengguna juga bisa menjadi masalah. Misalnya, pengguna mungkin membutuhkan beberapa hari sebelum mereka memutuskan untuk membeli barang yang mereka lihat beberapa hari yang lalu. Ini adalah tantangan bagi penggabung 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 jangka 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 timbul 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 dibanjiri oleh contoh negatif, strategi umum adalah melakukan pengambilan sampel negatif. Hal ini tentu akan mengubah distribusi yang mendasarinya dari model yang dilatih, menyesuaikannya ke arah 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, cluster pelatihan Mono-lith terus menerima data dari modul penyajian online dan memperbarui parameter di 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 akibatnya mengganti semua parameter membutuhkan waktu. Akan sangat tidak tertoleransi untuk menghentikan PS online dari menyajikan model selama proses penggantian, dan pembaruan harus dilakukan saat bepergian; 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 ganda untuk menerima model yang baru tiba. Agar pelatihan online dapat ditingkatkan ke ukuran skenario bisnis kami, kami merancang mekanisme sinkronisasi parameter periodik inkremental saat bepergian di Monolith berdasarkan beberapa karakteristik model kami yang patut diperhatikan: (1) Parameter jarang mendominasi ukuran model rekomendasi; (2) Mengingat rentang waktu yang singkat, hanya sebagian kecil ID yang dilatih dan penyematan mereka diperbarui; (3) Variabel padat bergerak jauh lebih lambat daripada penyematan jarang. Ini karena dalam pengoptimal momentum, akumulasi momentum untuk variabel padat diperkuat 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 memanfaatkan pembaruan jarang di semua ID fitur. Di Monolith, kami mempertahankan kumpulan hash dari 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 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. Hal ini dapat menyebabkan situasi di mana parameter padat yang kami sajikan adalah versi yang relatif usang dibandingkan dengan bagian yang jarang. Namun, ketidaksesuaian seperti itu dapat ditoleransi karena alasan yang disebutkan dalam (3) karena tidak ada kerugian yang mencolok yang diamati. 2.3 Toleransi Kesalahan Sebagai sistem dalam produksi, Monolith dirancang dengan kemampuan untuk memulihkan PS jika gagal. Pilihan umum untuk toleransi kesalahan adalah mengambil snapshot status model secara berkala, dan memulihkan dari snapshot terbaru ketika kegagalan PS terdeteksi. Pilihan frekuensi snapshot memiliki dua dampak utama: (1) Kualitas model. Secara intuitif, kualitas model menderita lebih sedikit dari kehilangan riwayat terbaru dengan peningkatan frekuensi snapshot. (2) Overhead komputasi. Mengambil 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 mengambil snapshot semua PS pelatihan setiap hari. Meskipun PS akan kehilangan pembaruan satu hari jika terjadi kegagalan, kami menemukan bahwa degradasi 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 dengan eksperimen kami: (1) Seberapa besar manfaat yang bisa kita dapatkan dari HashTable Bebas Tabrakan? (2) Seberapa penting pelatihan online waktu nyata? (3) Apakah desain sinkronisasi parameter Monolith cukup kuat dalam skenario produksi skala besar? Dalam 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 bebas tabrakan. Untuk membuktikan perlunya menghindari tabrakan dalam tabel penyematan dan mengukur perolehan dari implementasi bebas tabrakan kami, 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 adalah 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 160rb ID pengguna dan 60rb ID film. Untuk membandingkan dengan versi tabel penyematan bebas 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 penyematan mereka dengan yang lain. Tabel 1 menunjukkan statistik terperinci tentang ID pengguna dan film sebelum dan sesudah hashing. 9 (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 penyematan, dan distribusi ukuran tabel penyematan sangat tidak merata; Ruang ID asli dari tabel penyematan adalah 248. Dalam baseline kami, kami menerapkan trik hashing dengan menguraikan untuk menahan ukuran tabel penyematan. Lebih spesifik, kami menggunakan dua tabel penyematan yang lebih kecil alih-alih satu tabel 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 set parameter terbaru dengan interval menit. Kami merancang dua kelompok eksperimen untuk memverifikasi kualitas model dan ketahanan sistem. 3.1.2 Pelatihan Online. (1) . Untuk menyelidiki perlunya frekuensi pembaruan 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 skala besar standar untuk benchmarking 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 dataset. Kami mengambil 7 hari data dari dataset, dan membaginya menjadi dua bagian: 5 hari data untuk pelatihan batch, dan 2 hari untuk pelatihan online. Kami lebih lanjut 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 secara kasar 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 membahayakan kualitas model. 3.2.1 Efek Tabrakan Penyematan. (1) Model dengan HashTable Bebas Tabrakan secara konsisten mengungguli model dengan tabrakan. Kesimpulan ini berlaku terlepas dari Peningkatan jumlah epoch pelatihan. Seperti yang ditunjukkan pada Gambar model dengan tabel penyematan bebas 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 bebas tabrakan juga kuat seiring berjalannya waktu dan konteks pengguna/item berubah. 8, (2) Ketersebaran data yang disebabkan oleh tabel penyematan bebas tabrakan tidak menyebabkan overfitting model. Seperti yang ditunjukkan pada Gambar model dengan tabel penyematan bebas 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 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 kehilangan beberapa shard PS daripada yang kami harapkan. 3.2.2 Pelatihan Online: Menukar Keandalan Dengan Waktu Nyata. (1) . Dalam eksperimen pelatihan streaming online kami dengan dataset Criteo Display Ads Challenge, kualitas model terus meningkat dengan peningkatan frekuensi sinkronisasi parameter, sebagaimana dibuktikan oleh 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