Towards Better Recommendation Systems – Towards AI

Penulis: Blok Bangunan

Awalnya diterbitkan di Towards AI the World’s Leading AI and Technology News and Media Company. Jika Anda membuat produk atau layanan terkait AI, kami mengundang Anda untuk mempertimbangkan menjadi sponsor AI. Di Towards AI, kami membantu menskalakan AI dan startup teknologi. Biarkan kami membantu Anda melepaskan teknologi Anda kepada massa.

Tabel Penyematan Tanpa Benturan, Pelatihan Online, dan Toleransi Kesalahan

Foto oleh Daniel Korpai di Unsplash

Sistem Rekomendasi adalah aplikasi pembelajaran mesin yang paling umum. Kami melihat mereka beraksi di setiap platform media sosial, situs web streaming, pasar online, dan hampir semua situs web yang menampilkan iklan.

Terlepas dari prevalensinya, ada banyak ruang untuk perbaikan dalam cara Sistem Rekomendasi dirancang. Dalam artikel hari ini, kami akan meninjau makalah terbaru yang diterbitkan oleh tim di Bytedance, perusahaan induk TikTok. Sistem Rekomendasi Real-Time Dengan Tabel Penyematan Tanpa Benturan

Para penulis menyoroti tiga kontribusi utama dari pekerjaan mereka:

Tabel penyematan tanpa tabrakan dan Kedaluwarsa untuk menangani data kategorikal. Platform Pelatihan Online untuk memastikan bahwa model diperbarui saat preferensi pengguna berubah. Snapshot Berkala (salinan) untuk membuat sistem toleran terhadap kesalahan.

Masalah 1: Ruang Fitur yang Meledak

Intinya, mesin rekomendasi dilatih untuk memprediksi apakah sesuatu yang ditampilkan kepada Anda akan diklik atau tidak. Mesin rekomendasi mencoba membuat prediksi ini menggunakan dua jenis data:

Data tentang pengguna dapat berupa fitur seperti usia, waktu login, pembelian/klik/tampilan sebelumnya, dll. Data tentang item yang ditampilkan. Misalnya, jika Anda menggunakan aplikasi pengiriman makanan, fitur yang digunakan bisa berupa jenis masakan, bahan, peringkat restoran, dll.
Foto oleh Saundarya Srinivasan di Unsplash

Dalam banyak kasus, fitur yang digunakan untuk melatih model dapat berupa variabel kategori yaitu nilai non-numerik yang dapat dikategorikan misalnya fusi, burger, pizza, dll. dalam kasus jenis masakan. Perlu juga dicatat bahwa pengguna/item itu sendiri adalah variabel kategori karena biasanya direpresentasikan dalam bentuk pengidentifikasi unik (ID).

Dalam pembelajaran mendalam, metode umum untuk menangani variabel kategori adalah dengan menggunakan penyematan. Di mana setiap kategori dipetakan ke vektor n-dimensi. Lapisan embedding biasanya hanya tabel pencarian tempat ID unik dipetakan ke representasi vektor yang sesuai.

Variabel kategori menimbulkan masalah karena bisa saja ada kategori baru yang muncul sewaktu-waktu. Mungkin ada item makanan baru yang mulai bermunculan pada hari tertentu, atau aplikasi mungkin memiliki pengguna baru yang mendaftar. Secara teoritis, tidak ada batasan jumlah kategori yang dapat dimiliki seseorang untuk setiap fitur tertentu.

Namun, kami tidak dapat memiliki lapisan penyematan dengan memori tak terbatas. Implikasi dari hal ini adalah bahwa beberapa ID dapat dipetakan ke vektor n-dimensi yang sama. Asumsikan bahwa kita ditugaskan untuk memasukkan 11 bola ke dalam 10 kotak, apa pun yang kita lakukan setidaknya satu kotak akan berisi lebih dari satu bola. Skenario ini adalah apa yang kita sebut tabrakan. Tabrakan dapat menghambat kemampuan model Pembelajaran Mesin untuk membedakan berbagai kategori.

Larutan

Penulis memecahkan masalah ini dengan menggunakan:

Kategori Pemfilteran dan Pengusiran Cuckoo Hashing

Hashing adalah konsep mengambil input dari berbagai ukuran dan memetakannya ke output dengan ukuran tetap. Fungsi hash yang ideal dapat memastikan tidak ada tabrakan yaitu, tidak ada dua input yang dapat dipetakan ke output yang sama. Struktur data seperti kamus dan peta hash memanfaatkan fungsi hashing.

Penulis menyatakan bahwa banyak sistem rekomendasi mencoba untuk mengurangi tabrakan dalam tabel penyematan dengan memilih fungsi hash yang memastikan tabrakan rendah. Mereka berpendapat bahwa ini masih merugikan model pembelajaran mesin.

Idealnya, jika kita menggunakan tabel embedding, kita ingin menggunakan fungsi hash yang memastikan tidak ada dua input yang dipetakan ke posisi yang sama di tabel embedding. Penulis menggunakan Cuckoo HashMap untuk tujuan ini.

Cuckoo HashMap

Gambar dari kertas: https://arxiv.org/pdf/2209.07663.pdf

Seperti yang ditunjukkan pada gambar, Cuckoo HashMap memiliki dua Tabel Hash T0 dan T1. Setiap Tabel Hash memiliki fungsi hash yang unik, T0 menggunakan h0 dan T1 menggunakan h1. Fungsi hash memutuskan di mana input yang diberikan disimpan dalam tabel embedding.

Ilustrasi cara kerja Cuckoo HashMap dan cara menangani tabrakan ditunjukkan pada gambar di atas.

Saat item A masuk, item tersebut di-hash oleh h0 (ditulis sebagai h0(A)) ke posisi di T0, tetapi lokasi tersebut sudah memiliki item B di dalamnya (ini adalah tabrakan). Yang terjadi dalam skenario ini adalah A dipindahkan ke lokasi, dan B diusir. Saat diusir B dipindahkan ke T1 dengan menghitung h1(B) namun, ada tabrakan lain. Sekarang C diusir, dan h0(C) dihitung, bertabrakan dengan D. h1(D) dihitung. Akhirnya, h1(D) sesuai dengan lokasi di T1 yang kosong.

Amati bagaimana algoritme memastikan bahwa tidak ada dua item yang menempati lokasi yang sama di tabel hash dengan merelokasi semua item yang bertabrakan dengan item yang masuk.

Menyaring dan Mengusir Kategori

Untuk membatasi ukuran lapisan/tabel yang disematkan, penulis menyadari bahwa kategori/ID tertentu sangat jarang terjadi. Memiliki penyematan unik untuk item semacam itu tidak terlalu berguna karena model akan kurang cocok pada kategori tersebut karena jarang diamati dalam pelatihan.

Pengamatan cerdik lainnya yang penulis tunjukkan adalah bahwa ID/kategori tertentu mungkin menjadi tidak aktif setelah jangka waktu tertentu dan memiliki parameter untuknya tidak lagi masuk akal. Ini bisa jadi pengguna tidak masuk selama setahun, produk di amazon tidak dibeli dalam 3 bulan terakhir, dll.

Berdasarkan pengamatan tersebut, penulis memfilter kategori/ID berdasarkan seberapa sering mereka muncul dan jika tidak aktif lebih lama dari periode tertentu. Ini memastikan bahwa hanya kategori/ID yang paling relevan yang ada di tabel penyematan.

Masalah 2: Konsep Drift

Model pembelajaran mesin dilatih berdasarkan data yang dikumpulkan dari masa lalu. Namun, tidak ada jaminan bahwa masa lalu dapat mewakili masa depan secara akurat. Kita semua telah menyaksikan tren menjadi terkenal dan memudar seiring berjalannya waktu. Preferensi kami juga berubah seiring waktu.

Dalam dunia data science, fenomena ini disebut sebagai Concept Drift. Di mana distribusi data yang dipelajari model tidak lagi akurat, dan interaksi antar fitur tidak sama. Drift Konsep adalah alasan utama mengapa model pembelajaran mesin perlu dilatih ulang secara berkala untuk memastikan bahwa kinerjanya tidak menurun drastis dan mereka belajar tentang konsep yang muncul.

Larutan

Pelatihan online adalah proses pelatihan model segera setelah titik data baru muncul. Misalnya, jika Anda memutuskan untuk mulai menonton acara baru di Netflix, saat Anda menekan tombol putar itu, titik pelatihan baru dengan label positif (sejak Anda mengklik) telah dibuat. Model sekarang dapat menjalankan forward pass untuk menghitung kerugian dan memperbarui bobotnya sesuai dengan itu.

Gambar dari kertas: https://arxiv.org/pdf/2209.07663.pdf

Dalam makalah ini, penulis membuat sebuah framework yang dapat menjalankan batch (pelatihan offline) bersamaan dengan pelatihan online. Namun, yang menjadi perhatian di sini adalah bahwa model yang dilatih (Training Worker dan Training Parameter Server (PS) seperti yang terlihat pada gambar) dan model yang aktif digunakan (Serving Parameter Server (PS)) untuk memberikan rekomendasi berbeda dan dapat berjalan. dalam cluster yang berbeda.

Ini karena menjalankan model dalam mode kereta lebih lambat daripada menjalankannya dalam mode inferensi karena gradien tidak perlu dihitung dalam mode inferensi. Hal ini membawa kita pada pertanyaan bagaimana bobot Training dan Serving PS bisa disinkronkan (dibuat sama).

Berdasarkan pemahaman kami, penulis memberikan wawasan utama berikut yang menawarkan solusi untuk masalah tersebut:

Sebagian besar parameter model rekomendasi sebagian besar adalah fitur yang jarang, yaitu fitur kategorikal dan embeddings yang sesuai. Hanya beberapa fitur jarang yang cenderung diperbarui dalam jangka waktu tertentu. Bayangkan platform media sosial seperti Tiktok pada waktu tertentu, hanya sebagian kecil dari pengguna yang dapat masuk ke aplikasi meskipun jumlah total pengguna aktif harian mencapai beberapa juta. Model yang menggunakan pengoptimal berbasis momentum untuk memperbarui bobotnya cenderung membutuhkan waktu lama hingga bobotnya berubah secara signifikan. Bobot milik Deep Neural Network eksklusif dari penyematan disebut sebagai parameter padat.

Berdasarkan dua pengamatan pertama, penulis mengembangkan metodologi untuk melacak fitur renggang mana yang telah diperbarui selama pelatihan (online dan offline). Hanya parameter ID/fitur yang telah diperbarui selama pelatihan yang dikirim ke PS Penayangan untuk memperbarui parameternya. Ini ditunjukkan melalui tanda panah dari PS Pelatihan ke PS Penyajian pada gambar.

Penulis memperbarui parameter jarang setiap menit. Hal ini dapat dilakukan karena sebagian kecil dari ID yang diperbarui selama pelatihan online. Di sisi lain, parameter padat diperbarui pada frekuensi yang jauh lebih rendah. Terlepas dari perbedaan versi penyematan dan parameter padat di Serving PS, penulis menyoroti bahwa tidak ada penurunan performa yang signifikan.

Kombinasi pelatihan online dan batch dengan rencana cerdas untuk memperbarui bobot model memungkinkan mesin rekomendasi mempelajari tentang perubahan preferensi pengguna.

Masalah 3: Toleransi Kesalahan

Agar sistem toleran terhadap kesalahan, ia harus dapat berfungsi seperti yang diinginkan bahkan jika terjadi kegagalan. Perhatikan betapa jarangnya aplikasi perangkat lunak populer berhenti bekerja sepenuhnya. Hal ini karena para insinyur menjadikannya titik untuk menambahkan resistensi terhadap kegagalan sebanyak mungkin.

Metode umum untuk mencapai toleransi kesalahan adalah dengan membuat salinan server, basis data, dll. Ingatlah bahwa pada akhirnya, server hanyalah sebuah komputer. Itu bisa rusak, rusak, dan tidak berfungsi kapan saja, seperti halnya perangkat Anda sendiri. Memiliki banyak mesin yang menjalankan dan menyimpan kumpulan informasi dan data yang sama memastikan bahwa segera setelah mesin gagal, salinannya dapat mengambil alih dan melayani permintaan apa pun yang diarahkan padanya.

Penulis mengikuti pendekatan yang sama untuk membuat mesin rekomendasi mereka kuat terhadap kegagalan. Mereka membuat salinan bobot model (disebut sebagai snapshot). Namun, ada beberapa seluk-beluk yang perlu disorot.

Model bisa sangat besar, dan membuat terlalu banyak salinannya bisa mahal karena Anda harus membayar semua memori yang digunakan. Perlu menemukan keseimbangan yang tepat antara membuat salinan dan memiliki bobot terkini. Jika salinan sudah tua, itu berarti tidak mengetahui semua cara preferensi pengguna telah berubah sejak salinan dibuat.

Dalam percobaan mereka, penulis menemukan bahwa membuat salinan harian dari model mereka bekerja dengan baik tanpa penurunan kinerja model yang signifikan meskipun ada kegagalan server atau pusat data yang menyimpan model tersebut.

Kesimpulan

Monolith mengajarkan kita cara mencapai penyematan tanpa tabrakan dan keuntungan membersihkan fitur/ID yang tidak digunakan. Ini menunjukkan kepada kita bagaimana model dapat menangani penyimpangan konsep dengan lebih baik dengan memanfaatkan pelatihan online dan teknik sinkronisasi parameter yang cerdas. Ini juga menunjukkan pentingnya menemukan keseimbangan yang tepat dalam membuat salinan parameter model untuk memastikan toleransi kesalahan.

Terima kasih telah membaca artikel ini, kami harap Anda telah mempelajari sesuatu yang baru! Jika Anda memiliki pertanyaan atau pemikiran, silakan bagikan di bagian komentar di bawah.

Referensi

Monolit Tinjauan Kertas: Menuju Sistem Rekomendasi yang Lebih Baik awalnya diterbitkan di Towards AI on Medium, di mana orang melanjutkan percakapan dengan menyoroti dan menanggapi cerita ini.

Diterbitkan melalui Menuju AI

Author: Jonathan Kelly