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

```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∗, 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 dapat diskalakan dan real-time sangat penting bagi banyak bisnis yang didorong oleh umpan balik pelanggan yang sensitif 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 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 beragam: pertama, kami membuat tabel penyematan tanpa tabrakan dengan optimasi seperti penyematan yang dapat kedaluwarsa dan pemfilteran frekuensi untuk mengurangi jejak memorinya; kedua, kami menyediakan arsitektur pelatihan online yang siap produksi dengan ketahanan kesalahan yang 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 mendapatkan 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 akan paling baik menggambarkan potret pengguna dan membuat prediksi tentang minat dan perilaku pengguna di masa depan. 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-menerus dihadapkan pada masalah yang timbul dari karakteristik unik data yang berasal dari perilaku pengguna di 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 sebagian besar jarang, kategorikal, dan berubah secara dinamis; (2) Distribusi data pelatihan yang mendasarinya bersifat non-stasioner, alias Concept Drift [8]. Perbedaan tersebut 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: • Tidak seperti model bahasa di mana jumlah potongan kata terbatas, jumlah pengguna dan item peringkat berorde lebih besar. Tabel penyematan yang sangat besar ini sulit untuk dimasukkan ke dalam memori host tunggal; • Lebih buruk lagi, ukuran tabel penyematan diharapkan tumbuh seiring waktu karena lebih banyak pengguna dan item yang ditambahkan, sementara kerangka kerja seperti [ , ] menggunakan variabel padat berukuran tetap untuk merepresentasikan 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 terdistribusi 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 penyematan, peluang 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 menyesuaikan jumlah pengguna dan item yang coba dicatat secara elastis. 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 bersifat non-stasioner, fenomena yang umum 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 real-time untuk mencerminkan minat terbaru pengguna. Mengingat perbedaan ini dan pengamatan masalah yang timbul dari produksi kami, kami merancang , sistem rekomendasi skala besar untuk mengatasi 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 langka dengan merancang tabel hash tanpa tabrakan dan mekanisme pengusiran fitur dinamis; (2) Melakukan loop 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 serupa, dan mencapai AUC penyajian online state-of-the-art tanpa membebani daya komputasi server kami secara berlebihan. 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 produksi dan beberapa diskusi tentang trade-off antara sensitivitas waktu, keandalan, dan kualitas model. Bagian 4 merangkum karya terkait dan membandingkannya dengan Monolith. Bagian 5 menyimpulkan karya ini. 2 DESAIN Arsitektur Monolith secara keseluruhan 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 mendalam, dan parameter jarang mengacu pada tabel penyematan yang sesuai dengan fitur langka. Dalam desain kami, parameter padat dan 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 langka. Sebagai pelengkap keterbatasan TensorFlow yang timbul dari pemisahan pelatihan dan inferensi, pelatihan online Monolith yang dapat diskalakan secara elastis dirancang untuk menyinkronkan parameter dari PS pelatihan ke PS penyajian secara efisien dalam interval waktu singkat, dengan jaminan ketahanan model yang diberikan oleh mekanisme toleransi kesalahan. 2.1 Tabel Hash Prinsip pertama dalam desain representasi parameter langka kami adalah menghindari memasukkan informasi dari ID yang berbeda ke dalam penyematan berukuran tetap yang sama. Mensimulasikan tabel penyematan berukuran dinamis dengan Variabel TensorFlow siap pakai pasti akan menyebabkan tabrakan ID, yang semakin parah ketika ID baru tiba dan tabel tumbuh. Oleh karena itu, alih-alih membangun di atas Variabel, kami mengembangkan HashTable kunci-nilai baru untuk parameter langka kami. HashTable kami menggunakan Cuckoo Hashmap [ ] di balik layar, yang mendukung penyisipan kunci baru tanpa bertabrakan dengan yang sudah ada. Cuckoo Hashing mencapai kompleksitas waktu kasus terburuk 𝑂 (1) untuk pencarian dan penghapusan, dan amortisasi 𝑂 (1) 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. Ketika mencoba menyisipkan elemen 16 3 𝐴 ke dalam 𝑇0, ia pertama-tama mencoba menempatkan 𝐴 di ℎ0 (𝐴); Jika ℎ0 (𝐴) ditempati oleh elemen lain 𝐵, ia akan mengeluarkan 𝐵 dari 𝑇0 dan mencoba menyisipkan 𝐵 ke dalam 𝑇1 dengan logika yang sama. Proses ini akan diulang sampai semua elemen stabil, atau rehash terjadi ketika penyisipan masuk ke dalam 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 hanya muncul beberapa kali memiliki kontribusi terbatas untuk meningkatkan kualitas model. Pengamatan penting adalah bahwa ID terdistribusi ekor panjang, di mana ID populer dapat 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, 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 mungkin disebabkan oleh pengguna yang tidak aktif lagi, atau video pendek yang sudah ketinggalan zaman. Menyimpan penyematan untuk ID ini tidak dapat membantu model sedikit pun kecuali untuk 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 dimasukkan ke dalam tabel penyematan. Kami memiliki dua metode pemfilteran: Pertama kami memfilter berdasarkan kejadian mereka sebelum mereka 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: Mesin Streaming. 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 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 Tensor-Flow. 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 Tensor-Flow biasa: Di setiap langkah pelatihan, pekerja pelatihan membaca mini-batch contoh pelatihan dari penyimpanan, meminta parameter dari PS, menghitung pass maju dan mundur, dan akhirnya mendorong parameter yang diperbarui ke PS pelatihan. Sedikit berbeda dari tugas pembelajaran mendalam umum lainnya, kami hanya melatih kumpulan data kami untuk satu pass. 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, pekerja pelatihan mengonsumsi data real-time sambil jalan dan memperbarui PS pelatihan. PS pelatihan secara berkala menyinkronkan parameternya ke PS penyajian, yang akan berlaku pada sisi pengguna segera. Ini memungkinkan model kami untuk berinteraksi secara interaktif beradaptasi 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 Mesin Streaming. 4. Dalam desain kami, kami menggunakan satu antrean Kafka [ ] untuk mencatat tindakan pengguna (misalnya, Klik item atau sukai item, dll.) dan antrean Kafka lain untuk fitur. Inti dari mesin ini 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 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 dump 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 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) Keterlambatan tindakan pengguna juga bisa menjadi masalah. Misalnya, seorang pengguna mungkin membutuhkan beberapa hari sebelum mereka memutuskan untuk membeli item yang ditampilkan 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 key-value di disk digunakan untuk menyimpan fitur yang menunggu lebih dari periode waktu tertentu. Ketika log tindakan pengguna tiba, ia pertama-tama mencari cache dalam memori, dan kemudian mencari penyimpanan key-value 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 dibanjiri oleh contoh negatif, strategi umum adalah melakukan pengambilan sampel negatif. Ini tentu akan mengubah distribusi yang mendasari model yang dilatih, menyesuaikannya ke arah kemungkinan prediksi positif yang lebih tinggi. Sebagai perbaikan, kami menerapkan koreksi log odds [ ] selama penyajian, memastikan bahwa model online adalah estimator 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 dihadapkan pada 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 tertoleransi untuk menghentikan PS online dari melayani model selama proses penggantian, dan pembaruan harus dilakukan sambil jalan; Mentransfer model multi-terabyte secara keseluruhan dari PS pelatihan ke PS penyajian online akan memberikan tekanan besar pada bandwidth jaringan dan memori di PS, karena membutuhkan ukuran memori model ganda untuk menerima model yang baru tiba. Agar pelatihan online dapat diskalakan ke ukuran skenario bisnis kami, kami merancang mekanisme sinkronisasi parameter periodik sambil jalan inkremental di Monolith berdasarkan beberapa karakteristik yang terlihat dari model kami: (1) Parameter langka mendominasi ukuran model rekomendasi; (2) Mengingat rentang waktu yang singkat, hanya sebagian kecil ID yang dilatih dan penyematannya diperbarui; (3) Variabel padat bergerak jauh lebih lambat daripada penyematan langka. Ini karena dalam pengoptimal berbasis momentum, akumulasi momentum untuk variabel padat diperbesar oleh ukuran data pelatihan rekomendasi yang sangat besar, sementara hanya beberapa penyematan langka yang menerima pembaruan dalam satu batch data. (1) dan (2) memungkinkan kami untuk memanfaatkan pembaruan langka di semua ID fitur. Di Monolith, kami memelihara kumpulan hash kunci yang disentuh, yang mewakili ID yang penyematannya dilatih sejak sinkronisasi parameter terakhir. Kami mendorong subset parameter langka yang kuncinya berada 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 langka, sementara memperbarui parameter padat lebih jarang. Hal ini dapat membuat kami berada dalam situasi di mana parameter padat yang kami sajikan adalah versi yang relatif usang dibandingkan dengan bagian langka. Namun, inkonsistensi 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 gagal. Pilihan umum untuk toleransi kesalahan adalah memotret 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 mengalami lebih sedikit kerugian dari hilangnya riwayat terbaru dengan peningkatan frekuensi snapshot. (2) Overhead komputasi. Memotret model multi-terabyte tidak gratis. Ini menimbulkan salinan memori dan I/O disk yang besar. Sebagai trade-off antara kualitas model dan overhead komputasi, Monolith memotret semua PS pelatihan setiap hari. Meskipun PS akan kehilangan pembaruan sehari 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 kami yang diusulkan, kami melakukan beberapa eksperimen dalam skala produksi dan pengujian 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 real-time? (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 tanpa tabrakan. Untuk membuktikan perlunya menghindari tabrakan dalam tabel penyematan 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 Penyematan. 2.1, (1) Kumpulan data ml-25m [ ]. Ini adalah kumpulan data publik standar untuk peringkat film, berisi 25 juta peringkat yang melibatkan sekitar 162.000 pengguna dan 62.000 film. MovieLens 11 • *Pra-pemrosesan label*. Label asli adalah peringkat dari 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 [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 penyematan. Kumpulan data ini berisi sekitar 160 ribu ID pengguna dan 60 ribu ID film. Untuk membandingkan dengan versi tabel penyematan yang tanpa tabrakan, kami melakukan kelompok eksperimen lain di mana ID diproses sebelumnya 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 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 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 dekomposisi untuk mengurangi 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 melayani 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 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 Kumpulan data yang kami gunakan adalah kumpulan data Criteo Display Ads Challenge3, kumpulan data standar skala besar untuk pembandingan model CTR. Ini berisi 7 hari data yang diurutkan secara kronologis yang mencatat fitur dan tindakan klik. Untuk eksperimen ini, kami menggunakan model DeepFM [9] standar seperti yang dijelaskan di 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 𝑁 pecahan secara kronologis. Pelatihan online disimulasikan oleh algoritma 1. Oleh karena itu, kami mensimulasikan sinkronisasi parameter yang dilatih ke PS penyajian dengan interval yang ditentukan oleh jumlah pecahan 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 kumpulan data MovieLens dan kumpulan data 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 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 akan menyebabkan overfitting model. Seperti yang ditunjukkan pada Gambar model dengan tabel penyematan tanpa tabrakan tidak mengalami overfitting setelah konvergen. 7, ![#Figure 8: Efek Tabrakan Penyematan Pada Model Rekomendasi di Produksi Kami mengukur kinerja model rekomendasi ini dengan AUC penyajian online, yang berfluktuasi dari hari ke hari karena concept-drift.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-d9i3eb9.jpeg) ![#Figure 9: Pelatihan online vs. Pelatihan batch pada dataset Criteo. 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 pecahan PS daripada yang kami harapkan. 3.2.2 Pelatihan Online: Menukar Keandalan Dengan Realtime. (1) . Dalam eksperimen pelatihan streaming online kami dengan kumpulan data Criteo Display Ads Challenge, kualitas model terus meningkat dengan peningkatan frekuensi sinkronisasi parameter, seperti yang terlihat 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 pecahan data berikut versus model pelatihan batch yang dievaluasi oleh setiap pecahan 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