Pada tahun 2018, tim kami secara tradisional mengambil bagian dalam Tantangan RecSys . Ini adalah kontes tahunan tentang sistem rekomendasi yang diadakan sebagai bagian dari konferensi RecSys. Ini tidak sebesar kompetisi di Kaggle, tetapi dianggap sebagai salah satu kompetisi paling bergengsi dalam sistem rekomendasi. Kali ini tugasnya adalah musikal - perlu untuk membangun sebuah sistem untuk melanjutkan playlist secara otomatis. Dalam posting ini, saya berbicara secara rinci tentang keputusan kami. Saya mengundang Anda untuk kucing.

Tentang kontes

Tahun ini, data untuk kompetisi disediakan oleh Spotify , layanan streaming musik (yang, sayangnya, tidak tersedia secara resmi di Federasi Rusia). Rekomendasi adalah salah satu bagian terpenting dari produk di Spotify dan memungkinkan pengguna menemukan musik baru, membuat daftar putar, atau mendengarkan radio berdasarkan preferensi mereka.

Peserta kontes diperlukan untuk membuat algoritma kelanjutan daftar putar otomatis. Dataset Daftar Putar Million, nama yang berbicara sendiri, disajikan sebagai data pelatihan. Selain informasi tentang trek mana yang terdapat dalam daftar putar, meta-informasi tentang trek juga disediakan: artis, judul, durasi, nama album.

Anda dapat membaca lebih lanjut tentang kontes di sini .

Tantangan kompetisi

Tugas kompetisi adalah klasik untuk sistem rekomendasi: menghasilkan rekomendasi top-K untuk pengguna, mengetahui sejarah tindakannya, tetapi alih-alih item pengguna biasa, trek daftar putar muncul di sini. Dalam istilah yang lebih formal, bagian daftar putar (selanjutnya disebut seed) diberikan dalam data uji, dan ada beberapa cara berbeda untuk membentuknya. Untuk K = (5, 10, 25, 100) ada biji dengan trek K pertama dan trek K dipilih secara acak. Ada juga seed dengan track pertama dan hanya dengan nama playlist. Track yang tidak termasuk dalam holdout harus diprediksi. Untuk setiap daftar putar, dibutuhkan 500 prediksi.

Metrik

Salah satu fitur dari kompetisi adalah bahwa metrik itu bukan satu, seperti kebiasaan di sebagian besar kompetisi, tetapi beberapa. Di bawah ini saya akan menceritakan tentang masing-masing.

R presisi

Metrik ini menunjukkan proporsi trek relevan yang kami duga.

$$$R-precision = \ frac {| G \ cap {} R_ {1: | G |} |} {| G |}$

NDCG

Ini adalah metrik kualitas peringkat klasik, Anda dapat membacanya, misalnya, di sini

Klik

Spotify memiliki mekanisme untuk melanjutkan daftar putar (Anda dapat melihatnya di tangkapan layar di awal artikel): Spotify menawarkan beberapa lagu yang dapat digunakan untuk memperluas daftar putar, dan jika tidak ada yang muncul, Anda dapat mengklik tombol segarkan dan mendapatkan kumpulan rekomendasi berikutnya. Jumlah pembaruan tersebut untuk pilihan pertama adalah metrik Klik. Lebih sederhana lagi, posisi rekomendasi relevan pertama (dalam hal ini, dibagi 10).

Selanjutnya, tim diberi peringkat untuk masing-masing metrik. Kemudian peringkat dikumpulkan berdasarkan skema Strategi Pemilu Counta Borda. Jika $$$p$Apakah jumlah peserta, maka tim dengan pangkat 1 mendapat $$$p-1$poin, tim dengan pangkat 2 menerima $$$p-2$poin dan sebagainya.

Solusi

Skema validasi

Untuk memainkan split train / test, kami membagi dataset asli menjadi tiga bagian: bagian pertama berisi daftar putar 980k, bagian kedua dan ketiga masing-masing berisi 10k. Kemudian, setiap daftar putar dari bagian kedua dan ketiga dibagi menjadi bagian seed dan holdout, dan ukuran bagian seed dipilih dengan cara yang sama seperti pada set tes yang disediakan, dan track yang tersisa jatuh ke dalam holdout.

Seleksi kandidat

Sistem yang disarankan sering menggunakan pendekatan dua tahap: pertama, menggunakan model yang lebih sederhana (mis., Faktorisasi matriks ), kandidat dipilih dari seluruh rangkaian item, dan kemudian kandidat diberi peringkat oleh model yang lebih kompleks (mis., Peningkatan gradien ) pada serangkaian atribut yang lebih luas. Pemilihan kandidat diperlukan, pertama-tama, karena sumber daya komputasi yang terbatas: jika kita menggunakan seluruh rangkaian trek yang tersedia sebagai kandidat, maka untuk satu daftar putar kita harus mengarahkan sekitar satu juta objek melalui model.

Pemilihan kandidat menggunakan faktorisasi matriks

Factorisasi matriks adalah salah satu pendekatan yang paling umum untuk membangun sistem rekomendasi. Gagasan utama dari metode ini adalah untuk menyajikan matriks jarang interaksi antara pengguna dan item dalam bentuk produk dari dua matriks (U dan I) dimensi yang lebih kecil. Kemudian kita bisa mendapatkan rekomendasi untuk pengguna dengan mengalikan vektor dari matriks U dengan matriks I.

Untuk faktorisasi matriks, kami menggunakan pustaka LightFM dengan kerugian WARP (Weighted Approximate-Rank Pairwise) . Kami juga memiliki dua model yang berbeda - satu untuk daftar putar yang memiliki benih tidak kosong, dan yang lainnya untuk daftar putar yang hanya memiliki nama (mulai dingin).

Kerugian WARP

Fungsi kerugian ini lebih baik daripada yang lain dalam tugas peringkat. Ini berfungsi dengan tiga kali lipat (pengguna, positive_item, negative_item) dan memiliki satu fitur yang sangat penting - pemilihan contoh negatif tidak terjadi secara kebetulan, tetapi sedemikian rupa sehingga contoh negatif yang dipilih "memecah" peringkat peringkat model saat ini, mis. lebih tinggi dari contoh positif.

Dengan demikian, prosedur pelatihan model menggunakan kehilangan WARP akan kira-kira sebagai berikut:

1. Untuk pasangan $$$(pengguna, positif \ _item)$kami akan memilih contoh negatif acak di antara semua item lainnya (penting untuk memahami bahwa ini hanya diperlukan jika probabilitas untuk memilih contoh negatif, yang sebenarnya akan positif, cukup kecil). Hitung prediksi pasangan $$$(pengguna, positif \ _item)$dan $$$(pengguna, negatif \ _item)$dan jika tidak ada gangguan (yaitu, model memperkirakan skor yang lebih tinggi untuk contoh positif), maka kami terus sampel contoh negatif sampai pelanggaran terjadi.
2. Jika kami menerima pelanggaran pada upaya pertama, maka kami dapat mengambil langkah gradien besar, karena ini berarti bahwa saat ini model sering menempatkan contoh negatif di atas yang positif dan perlu untuk memperbarui bobotnya dengan kuat. Jika kita harus mencari contoh negatif yang cocok untuk waktu yang lama, maka kita mengambil langkah kecil - modelnya sudah terlatih dengan baik.

Deskripsi yang lebih formal tentang kehilangan WARP dapat ditemukan di artikel asli atau di pos ini .

Lightfm

Versi pertama dari model hanya menggunakan informasi kolaboratif: keberadaan track track_id di playlist playlist_id, disajikan sebagai matriks biner jarang. Sejumlah matriks terkait dengan daftar putar, kolom ke trek.

$$$score (p, t) = b_t + b_t + <q_p, q_t>$

Fitur teks LightFM +

Model ini menggunakan embedding kata-kata dari nama daftar putar alih-alih playlist_id. Embedding daftar putar adalah jumlah embeddings dari kata-katanya.

$$$score (p, t) = b_p + b_t + <q_p, q_t>$
$$$b_p = \ sum_ {i \ in {f_p}} {b_i}$, $$$q_p = \ sum_ {i \ in {f_p}} {q_i}$,
dimana $$$f_p$- Ini adalah kata-kata dari nama daftar putar.

Jadi, kami memecahkan masalah permulaan yang dingin - kami dapat memberikan rekomendasi yang lebih baik untuk daftar putar yang hanya memiliki nama.

Penyelenggara kontes juga memberikan informasi tentang berapa banyak lagu yang ada di bagian tersembunyi daftar putar. Jika bagian yang tersembunyi itu $$$k$trek lalu kita pilih $$$maks (k * 15, k + 700)$kandidat. Sifat dari angka-angka ini adalah heuristik sederhana, diciptakan dari pertimbangan berikut: kami ingin memiliki cukup kandidat untuk daftar putar kecil (oleh karena itu $$$k + 700$), dan kami juga ingin dataset akhir memiliki sekitar 10 juta baris untuk alasan kinerja dalam hal waktu dan memori (oleh karena itu k 15, bukan k 50, misalnya).

Peringkat

Setelah kami memilih kandidat, kami dapat mempertimbangkan tugas menyusun rekomendasi sebagai masalah klasifikasi biner: untuk setiap trek di kandidat yang dipilih, kami belajar untuk memprediksi apakah trek ini benar-benar ada dalam daftar putar.

Dalam dataset pelatihan kami, setiap baris akan berisi tanda untuk pasangan (daftar putar, trek), dan label akan menjadi 1 jika ada trek dalam daftar putar dan 0 jika tidak.

Sebagai tanda, beberapa kelompok berbeda digunakan.

Fitur berdasarkan model LightFM

Seperti dijelaskan di atas, dalam model LightFM kami mendapat vektor $$$q_p, q_t$dan skalar $$$b_p, b_t$.
Sebagai tanda kita akan gunakan $$$b_p, b_t$, < $$$q_p, q_t>$dan peringkat trek t di antara semua kandidat untuk daftar putar p (peringkat dihitung dengan rumus ). Keempat atribut ini diambil dari model LightFM dan LightFM Text.

Tanda-tanda berdasarkan track co-kejadian

Biarkan $$$n_ {i, j}$Apakah jumlah daftar putar berisi lagu $$$i$dan $$$j$bersama juga $$$n_i$- jumlah daftar putar yang berisi trek $$$i$. Nilai-nilai ini dihitung pada satu set daftar putar yang terdiri dari semua bagian unggulan.

Biarkan daftar putar $$$p$terdiri dari trek $$$t_1, t_2, ..., t_n$. Untuk trek $$$t$hitung nilainya $$$n_ {t, t_1}, n_ {t, t_2}, ..., n_ {t, t_n}$dan untuk mereka kami akan menghitung berbagai statistik: minimum, maksimum, rata-rata dan median. Lalu kami menghitung statistik yang sama untuk jumlah $$$\ frac {n_ {t, t_1}} {n_ {t_1}}, \ frac {n_ {t, t_2}} {n_ {t_2}}, ..., \ frac {n_ {t, t_n}} { n_ {t_n}}$. Dalam kasus pertama, kami hanya menonton seberapa sering trek target bertemu dengan trek dari daftar putar, dan dalam kasus kedua, kami juga menormalkan ini dengan frekuensi kemunculan trek lain. Normalisasi membantu model untuk tidak melatih ulang untuk trek populer dan lebih akurat mengekstrak informasi tentang seberapa banyak trek benar-benar mirip.

Tanda-tanda lainnya

Semua karakteristik dihitung untuk pasangan. $$$(p, t)$.

• Jumlah artis unik dalam daftar putar $$$p$.
• Jumlah album unik dalam daftar putar $$$p$.
• Jumlah dan persentase trek dalam daftar putar $$$p$dengan album / artis yang sama dengan trek $$$t$.
• Berapa kali trek bertemu $$$t$di semua daftar putar.
• Berapa kali artis / album melacak $$$t$di semua daftar putar.
• Jumlah trek di seed dan bagian holdout dari daftar putar $$$p$.

Model Rekomendasi

Untuk membangun rekomendasi akhir, kami menggunakan XGBoost . Model dilatih $$$II_ {kandidat}$, hiperparameter dipilih pada $$$III_ {kandidat}$oleh ROC AUC metric. Metrik ini dipilih karena klasik untuk masalah klasifikasi. Tidak semua fitur sama-sama bermanfaat, sehingga akan menarik untuk melihat nilai-nilai pentingnya fitur dari model.

Dapat dilihat bahwa tanda co-kejadian dinormalisasi berarti secara signifikan menonjol dari yang lain. Ini berarti bahwa informasi tentang kemunculan trek memberikan sinyal yang sangat kuat, yang, secara umum, tidak mengejutkan. Selain itu, fitur ini dapat digunakan sebagai pemilihan kandidat alih-alih model LightFM, dan ini memberikan hasil yang tidak lebih buruk.

Lainnya

Besi

Semua model dilatih di server dengan Intel Xeon E5-2679 v3 (28 core, 56 threads), RAM 256Gb. Mempelajari pipa akhir membutuhkan waktu sekitar 100 jam dan menghabiskan memori 200Gb di puncaknya, dan sebagian besar (sekitar 90%) dari waktu dihabiskan untuk melatih model pemilihan kandidat. Model peringkat dilatih cukup cepat - sekitar dua jam (tidak termasuk pemilihan hiperparameter).

Gagal

Bukan tanpa gagal.

Pada hari kedua terakhir kompetisi, kami memutuskan untuk mengatur mini-hackathon, pada akhirnya kami mengumpulkan semua yang kami miliki: pemilihan kandidat berdasarkan kemunculan bersama, sekelompok fitur baru untuk meningkatkan, dan sepertinya itu bisa terjadi seperti itu?
Tetapi kecepatan validasi benar-benar tumbuh sedikit, jadi kami membutakan pengajuan dan mengirimkannya, berencana bahwa kita akan memiliki satu hari lagi untuk memperbaiki kusen. Setelah mereka mengirim kiriman, mereka mengetahui bahwa itu bukan hari kedua dari belakang, tetapi yang terakhir. Dan kecepatan pengiriman baru jauh lebih rendah daripada pengiriman terbaik kami. Tidak ada waktu untuk mencari tahu mengapa ini terjadi, jadi kami menyabot pengiriman terbaik, yang tetap di tempat ketiga.

Juga pada hari terakhir, kami belajar bahwa ada dua jenis benih yang berbeda: dengan trek K pertama, dan yang acak, dan dalam validasi kami selalu memilih yang acak, tetapi ini tidak akan berdampak besar pada papan peringkat.
Suatu hari dalam kompetisi, nilai metrik R-Precision untuk semua tim di papan peringkat meningkat tajam. Kami tidak mementingkan hal ini, tetapi pada akhir kompetisi kami menemukan bahwa panitia menambahkan satu komponen lagi ke metrik - pertandingan artis trek. Ini juga dapat ditambahkan ke metrik validasi dan, mungkin, peningkatan kecepatan.

Kode

Solusi kami dirancang dalam bentuk Jupyter-laptop dan dapat direproduksi (!) Dengan meluncurkannya secara berurutan. Hanya untuk ini, Anda memerlukan mesin dengan 200Gb + RAM dan beberapa hari.

Keputusan peserta lain

Tim yang memenangkan tempat pertama juga secara teratur berpartisipasi dalam Tantangan RecSys dan mengambil tempat tinggi. Solusi mereka mirip dengan kita, tetapi diimplementasikan di Jawa .

Finalis kedua memiliki pendekatan yang agak menarik - mereka menggunakan Denoising Autoencoder untuk mengembalikan daftar putar dari bagian mereka .

Kesimpulan

Jika Anda melihat leaderboard terakhir, maka tim kami berada di peringkat keenam dan keempat dalam metrik peringkat (R-Precision dan NDCG), dan yang pertama di metrik Clicks. Bagaimana itu bisa terjadi? Dan itu terjadi karena solusi yang baik untuk masalah mulai dingin menggunakan model Teks LightFM. Metrik Klik lebih berat saat kami tidak menebak satu lagu pun dari daftar putar. Menggunakan model LightFM Text meningkatkan metrik Klik rata-rata dari 2,2 menjadi 1,78.

Pendekatan dengan memilih kandidat menggunakan model yang lebih sederhana dan peringkat lebih lanjut dengan model yang lebih kompleks masih merupakan salah satu yang paling sukses dalam masalah klasik dalam membangun rekomendasi top-K. Tetapi pada saat yang sama, sangat penting untuk membangun skema validasi dengan benar sehingga model pemilihan kandidat dan model pemeringkatan dapat dibandingkan.

Juga, skema ini sangat cocok untuk sistem produksi - Anda dapat mulai membangun sistem rekomendasi Anda berdasarkan faktorisasi matriks, dan kemudian memperbaikinya dengan menambahkan tahap kedua.

Jika Anda memiliki pertanyaan tentang artikel ini, silakan bertanya di komentar :)

PS Kami menulis artikel yang lebih rinci tentang ini untuk lokakarya di konferensi RecSys. Akses ke materi-materinya di situs terbatas, jadi jika Anda tertarik mempelajari sedikit lebih detail tentang solusi kami, tuliskan kepada saya di PM.