Di Dalam Monolit ByteDance: Mesin yang Memberdayakan Umpan Konten yang Lebih Cerdas dan 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 terukur dan real-time 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 deep learning skala produksi seperti TensorFlow atau PyTorch diadopsi secara universal, kerangka kerja tujuan umum ini tidak memenuhi permintaan 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 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 ketahanan kesalahan tinggi; akhirnya, kami membuktikan bahwa keandalan sistem dapat ditukar demi pembelajaran real-time. 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 individu 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 hal itu akan paling baik menggambarkan potret pengguna dan membuat prediksi tentang minat dan perilaku masa depan pengguna. Deep learning telah mendominasi model rekomendasi [ , , , , , ] karena sejumlah besar data pengguna sangat cocok untuk model saraf yang digerakkan oleh data secara masif. Namun, upaya untuk memanfaatkan kekuatan deep learning 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 deep learning konvensional seperti pemodelan bahasa atau visi komputer dalam dua aspek: 5 6 10 12 20 21 (1) Fitur sebagian besar bersifat jarang, kategorikal, dan berubah secara dinamis; (2) Distribusi data pelatihan yang mendasarinya tidak stasioner, alias Concept Drift [8]. Perbedaan tersebut telah menimbulkan tantangan unik bagi para peneliti dan insinyur yang bekerja pada sistem rekomendasi. 1.1 Jarang dan Dinamis Data untuk rekomendasi sebagian besar berisi fitur kategorikal yang jarang, beberapa di antaranya muncul dengan frekuensi rendah. Praktik umum pemetaan mereka ke ruang embedding berdimensi tinggi akan menimbulkan serangkaian masalah: • Berbeda dengan model bahasa di mana jumlah potongan kata terbatas, jumlah pengguna dan item peringkat berkali-kali lipat lebih besar. Tabel embedding yang sangat besar ini hampir tidak mungkin muat dalam memori satu host; • Lebih buruk lagi, ukuran tabel embedding diharapkan bertambah seiring waktu karena lebih banyak pengguna dan item yang ditambahkan, sementara kerangka kerja seperti [ , ] menggunakan variabel padat berukuran tetap untuk mewakili tabel embedding. 1 17 Dalam praktiknya, banyak sistem mengadopsi hashing dengan tabrakan rendah [ , ] sebagai cara untuk mengurangi jejak memori dan memungkinkan penambahan ID. Ini bergantung pada asumsi yang terlalu idealis bahwa ID dalam tabel embedding 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 jumlah kemunculan yang jauh lebih signifikan. Dengan pertumbuhan organik ukuran tabel embedding, 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 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 menggeser semangat mereka setiap menit berikutnya. Akibatnya, distribusi data pengguna yang mendasarinya tidak stasioner, fenomena yang biasa disebut 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 dalam pengamatan masalah yang timbul dari produksi kami, kami merancang , sistem skala besar untuk rekomendasi guna 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-fitur jarang dengan merancang tabel hash tanpa tabrakan dan mekanisme pengusiran fitur dinamis; (2) Mengembalikan umpan balik penyajian ke pelatihan secara real-time dengan pelatihan online. Diberdayakan 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 mutakhir 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 real-time di Bagian 2. Eksperimen dan hasil akan disajikan di Bagian 3, bersama dengan kesimpulan yang diuji produksi 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 karya ini. 2 DESAIN Arsitektur keseluruhan Monolith umumnya mengikuti pengaturan Worker- arameter erver terdistribusi TensorFlow (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 embedding 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 dari PS pelatihan ke PS penyajian secara efisien dalam interval waktu singkat, 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 embedding berukuran tetap yang sama. Mensimulasikan tabel embedding berukuran dinamis dengan Variabel TensorFlow yang siap pakai pasti akan menyebabkan tabrakan ID, yang diperburuk 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 latar belakang, yang mendukung penyisipan kunci baru tanpa bertabrakan dengan yang sudah ada. Cuckoo Hashing mencapai kompleksitas waktu 𝑂 (1) kasus terburuk untuk pencarian dan penghapusan, dan amortisasi 𝑂 (1) yang diharapkan untuk penyisipan. Seperti yang diilustrasikan pada Gambar , tabel ini memelihara 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 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 menemui 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 terdistribusi 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 memengaruhi hasil, sehingga kualitas model tidak akan terpengaruh oleh penghapusan ID dengan jumlah kemunculan rendah ini; (2) ID usang dari riwayat yang jauh jarang berkontribusi pada model saat ini karena banyak di antaranya tidak pernah dikunjungi. Hal ini mungkin disebabkan oleh pengguna yang tidak lagi aktif, atau video pendek yang sudah ketinggalan zaman. Menyimpan embedding 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 hemat memori: (1) ID difilter sebelum mereka diterima ke dalam tabel embedding. Kami memiliki dua metode pemfilteran: Pertama, kami memfilter berdasarkan jumlah kemunculannya sebelum mereka dimasukkan sebagai kunci, di mana ambang batas kemunculan adalah hiperparameter yang dapat disetel yang bervariasi untuk setiap model; Selain itu, kami menggunakan filter probabilistik yang membantu mengurangi penggunaan memori lebih lanjut; ![#Gambar 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, sementara Pelatihan Online 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 embedding 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: Dalam setiap langkah pelatihan, 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 deep learning 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 kembali model tersebut; (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. Hal ini memungkinkan model kami untuk beradaptasi secara interaktif sesuai dengan umpan balik pengguna secara real-time. Monolith dibangun dengan kemampuan untuk beralih dengan 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 antrean Kafka [ ] untuk mencatat tindakan pengguna (misalnya, Klik pada 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 pembuangan data akan terlebih dahulu membuang data ke HDFS [ ]; Setelah data di HDFS terakumulasi hingga 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, pengguna mungkin membutuhkan beberapa hari sebelum mereka memutuskan untuk membeli barang yang ditampilkan beberapa hari 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 lebih dari 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 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. Hal ini tentu akan mengubah distribusi yang mendasarinya dari model yang dilatih, menyesuaikannya ke arah probabilitas 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, cluster pelatihan Monolith terus menerima data dari modul penyajian online dan memperbarui parameter di PS pelatihan. Langkah penting 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 melayani 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 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 memori ukuran 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 yang singkat, hanya sebagian kecil dari ID yang dilatih dan embedding-nya diperbarui; (3) Variabel padat bergerak jauh lebih lambat daripada embedding jarang. Ini karena dalam optimizer berbasis 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 set hash dari kunci yang disentuh, yang mewakili ID yang embedding-nya dilatih sejak sinkronisasi parameter terakhir. Kami mendorong subset parameter jarang yang kuncinya berada dalam set kunci yang disentuh dengan interval waktu satu 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 yang tajam selama sinkronisasi. Kami juga memanfaatkan (3) untuk mengurangi I/O jaringan dan penggunaan memori lebih lanjut dengan mengatur jadwal sinkronisasi yang lebih agresif untuk parameter jarang, sambil 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 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 gagal. Pilihan umum untuk toleransi kesalahan adalah mengambil snapshot keadaan 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 lebih sedikit terpengaruh oleh hilangnya riwayat terbaru dengan peningkatan frekuensi snapshot. (2) Overhead komputasi. Mengambil snapshot model multi-terabyte tidak gratis. Hal 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 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 kita bisa mendapat manfaat 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 embedding di Monolith diimplementasikan sebagai HashTable tanpa tabrakan. Untuk membuktikan perlunya menghindari tabrakan dalam tabel embedding dan untuk mengukur keuntungan dari implementasi tanpa tabrakan kami, kami melakukan dua kelompok eksperimen pada dataset Movielens dan pada dataset produksi internal kami: 3.1.1 Tabel Embedding. 2.1, (1) Dataset ml-25m [ ]. Ini adalah dataset standar publik 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. Dataset 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 dipraproses 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 mempelajari prediksi jenis perilaku pengguna tertentu. 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 dengan 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 dengan AUC online dengan lalu lintas penyajian nyata. Selama pelatihan online, kami memperbarui PS penyajian online kami dengan set parameter terbaru dengan interval satu menit. Kami merancang dua kelompok eksperimen untuk memverifikasi kualitas model dan ketahanan sistem. 3.1.2 Pelatihan Online. (1) . Untuk menyelidiki perlunya frekuensi pembaruan satu 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. Dataset 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 pada 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 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 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 tetap berlaku terlepas dari Peningkatan jumlah epoch pelatihan. Seperti yang ditunjukkan pada Gambar model dengan tabel embedding 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 embedding tanpa tabrakan juga kuat seiring berjalannya waktu dan konteks pengguna/item berubah. 8, (2) Jarang 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, ![#Gambar 8: Efek Tabrakan Embedding Pada Model Rekomendasi Dalam Produksi 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) ![#Gambar 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 kehilangan 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 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 yang 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 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 lonjakan 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 ditoleransi. Ingat bahwa variabel