Bagaimana kami belajar merekomendasikan film dan mengapa Anda tidak harus hanya mengandalkan peringkat

Bayangkan Anda ingin menghabiskan malam menonton film, tetapi tidak tahu mana yang harus dipilih. Pengguna Yandex sering menemukan diri mereka dalam situasi yang sama, sehingga tim kami mengembangkan rekomendasi yang dapat ditemukan di Search and Air. Tampaknya ini rumit: kami mengambil peringkat pengguna, dengan bantuan mereka kami melatih mobil untuk menemukan film yang cenderung memberi 5 poin, kami mendapatkan daftar film yang sudah jadi. Tetapi pendekatan ini tidak berhasil. Mengapa? Itulah yang akan saya ceritakan hari ini.

Sedikit sejarah. Kembali pada tahun 2006, Netflix meluncurkan kontes pembelajaran mesin Netflix Prize. Jika Anda tiba-tiba lupa, maka perusahaan belum streaming di Internet, tetapi menyewa film dalam DVD. Tetapi meskipun begitu, penting baginya untuk memprediksi peringkat pengguna untuk merekomendasikan sesuatu kepadanya. Jadi, inti dari kompetisi: untuk memprediksi peringkat pemirsa adalah 10% lebih baik (menurut metrik RMSE) daripada Cinematch, sistem rekomendasi Netflix. Ini adalah salah satu kompetisi massal pertama semacam ini. Bunga memanaskan dataset besar (lebih dari 100 juta peringkat), serta hadiah $ 1 juta.

Kompetisi berakhir pada 2009. Tim-tim Bellagor's Pragmatic Chaos dan The Ensemble mencapai garis finish dengan hasil yang sama (RMSE = 0,8567), tetapi Ensemble mengambil tempat kedua karena mereka mengirim solusi 20 menit lebih lambat daripada para pesaing. Hasil dan pekerjaan dapat ditemukan di sini . Tetapi hal yang paling menarik adalah berbeda. Jika Anda yakin cerita yang berulang di konferensi khusus, algoritma yang menang tidak muncul dalam produksi dalam layanan streaming video yang segera diluncurkan. Saya tidak dapat berbicara tentang alasan keputusan orang lain, tetapi saya akan memberi tahu Anda mengapa kami melakukan hal yang sama.

Peringkat pribadi

Untuk beberapa waktu sekarang, pengguna Yandex dapat menilai film yang telah mereka tonton. Dan tidak hanya di KinoPoisk, tetapi juga di hasil pencarian. Seiring waktu, kami telah mengumpulkan ratusan juta perkiraan puluhan juta orang. Pada titik tertentu, kami memutuskan untuk menggunakan data ini untuk membantu pengguna memahami seberapa besar mereka menginginkan film. Faktanya, kami memecahkan masalah yang sama seperti pada kontes Netflix Prize, yaitu, kami memperkirakan peringkat apa yang akan diberikan pengguna pada film tersebut. Pada saat itu, peringkat KinoPoisk dan IMDB sudah ada, yang dibangun berdasarkan peringkat orang. Kami membangun peringkat pribadi, jadi kami memutuskan untuk menggunakan skala terpisah sebagai persentase untuk menghindari kesamaan visual dan kebingungan.



Ngomong-ngomong, kebutuhan untuk mengkorelasikan skala poin dan persentasenya adalah sakit kepala yang terpisah dan tidak terlihat, jadi saya akan membicarakannya sebentar. Tampaknya untuk skala 10 poin, ambil 10% untuk setiap poin - dan intinya ada di topi. Tapi tidak. Alasannya adalah psikologi dan kebiasaan. Misalnya, dari sudut pandang pengguna, peringkat 8/10 jauh lebih baik daripada 80%. Bagaimana cara menghubungkan ini? Dengan crowdsourcing! Dan begitulah yang kami lakukan: kami meluncurkan tugas di Tolok, di mana para penembak menggambarkan harapan film dengan skor atau persentase tertentu dari peringkat pribadi. Berdasarkan markup ini, kami memilih fungsi yang menerjemahkan prediksi skor dari titik ke persentase sehingga harapan pengguna tetap terjaga.


Memprediksi harapan dari film itu berguna, tetapi akan menyenangkan untuk membangun rekomendasi juga. Artinya, segera tunjukkan daftar film bagus kepada orang tersebut. Pada saat itu, banyak dari Anda mungkin berpikir: "Dan mari kita urutkan film-film yang belum ditonton pengguna berdasarkan peringkat pribadi." Awalnya kami juga berpikir begitu. Tetapi kemudian saya harus menyelesaikan dua masalah.

Masalah alat

Ketika pengguna mencari film tertentu (atau ingin menyewa DVD tertentu), layanan harus memprediksi peringkat film tertentu ini. Persisnya masalah ini diselesaikan di kontes Netflix Prize, tempat metrik RMSE digunakan. Tetapi rekomendasinya memecahkan masalah yang berbeda: Anda tidak perlu menebak nilainya, tetapi untuk menemukan film yang pada akhirnya akan ditonton. Dan metrik RMSE melakukan pekerjaan yang buruk ini. Misalnya, penalti untuk memperkirakan peringkat 2 bukannya 1 sama persis dengan 5 bukannya 4. Tapi sistem kami seharusnya tidak pernah merekomendasikan film yang menempatkan pengguna 2! Metrik berbasis daftar jauh lebih cocok untuk tugas ini, seperti Precision @ K, Recall @ K, MRR, atau NDCG. Saya tidak bisa membantu tetapi memberi tahu Anda sedikit lebih banyak tentang mereka (tetapi jika Anda tidak tertarik dengan metrik, lewati saja paragraf berikutnya).

Mari kita mulai dengan metrik.MRR (artinya peringkat timbal balik). Kami akan melihat posisi apa di peringkat yang akan menjadi film yang berinteraksi dengan pengguna (misalnya, menonton atau memuji) dalam periode pengujian. Metrik MRR adalah posisi terbalik rata-rata pengguna dari film semacam itu. Yaitu$$$MRR = \frac{1}{|U|} \sum_{u=1}^{|U|} \frac{1}{rank_u}$. Metrik seperti itu, tidak seperti RMSE, mengevaluasi seluruh daftar, tetapi, sayangnya, hanya terlihat pada elemen tebakan pertama. Namun, mudah untuk memodifikasi metrik untuk menghilangkan kelemahan ini. Kami dapat menghitung jumlah posisi terbalik dari semua film yang berinteraksi dengan pengguna. Metrik ini disebut Peringkat Hit Rata-Rata Timbal Balik. Metrik ini memperhitungkan semua film yang ditebak dalam masalah ini. Perhatikan bahwa posisi k dalam pembayaran menerima bobot 1 / k untuk film yang ditebak dan 0 untuk film lain. Seringkali, 1 / log (k) digunakan alih-alih 1 / k: ini lebih cenderung sesuai dengan probabilitas bahwa pengguna akan menggulir ke posisi k. Hasilnya adalah metrik DCG (diskon keuntungan kumulatif)$$$DCG = \frac{1}{|U|} \sum_{u=1}^{|U|} \sum_{pos=1}^{N} \frac{gain_{pos}}{\max(1, \log(pos))}$. Tetapi kontribusi pengguna yang berbeda untuk metrik berbeda: untuk seseorang kami menebak semua film, untuk seseorang kami tidak menebak apa pun. Karenanya, sebagai aturan, metrik ini dinormalisasi. Bagi DCG setiap pengguna ke dalam DCG peringkat terbaik untuk pengguna itu. Metrik yang dihasilkan disebut NDCG (gain kumulatif diskon yang dinormalisasi). Ini banyak digunakan untuk menilai kualitas peringkat.

Jadi, setiap tugas memiliki metrik sendiri. Tetapi masalah selanjutnya tidak begitu jelas.

Masalah pilihan

Cukup sulit untuk dijelaskan, tetapi saya akan coba. Ternyata orang memberi nilai tinggi bukan pada film yang biasanya mereka tonton. Karya film langka, klasik, arthouse mendapatkan nilai tertinggi, tetapi ini tidak menghentikan orang di malam hari setelah bekerja dengan senang hati menonton komedi yang bagus, film aksi baru atau opera ruang angkasa yang spektakuler. Selain itu, pengguna di Yandex tidak menghargai semua film yang pernah mereka tonton dan pernah tonton di suatu tempat. Dan jika kita hanya fokus pada peringkat tertinggi, maka kita berisiko mendapat umpan film yang direkomendasikan yang akan terlihat logis, pengguna bahkan mungkin mengenali kualitasnya, tetapi pada akhirnya mereka tidak akan menonton apa pun.

Misalnya, beginilah tampilan umpan film saya jika kami mengukurnya berdasarkan peringkat pribadi dan tidak tahu apa-apa tentang pandangan saya di masa lalu. Film yang bagus. Tetapi saya tidak ingin memeriksanya hari ini.



Ternyata dalam kondisi peringkat yang tersebar dan kekurangan film dengan peringkat tinggi, ada baiknya tidak hanya melihat peringkatnya saja. Nah, kemudian kita latih mobil untuk memprediksi tampilan film yang direkomendasikan, dan bukan peringkatnya. Tampaknya logis, karena pengguna menginginkan ini. Apa yang bisa salah? Masalahnya adalah bahwa rekaman itu akan diisi dengan film, yang masing-masing cukup cocok untuk hiburan di malam hari, tetapi peringkat pribadi mereka akan rendah. Pengguna, tentu saja, akan memperhatikan fakta bahwa tidak ada "karya besar" dalam rekaman itu, yang berarti bahwa kredibilitas rekomendasi akan dirusak, mereka tidak akan menonton apa yang seharusnya mereka lihat.

Sebagai hasilnya, kami sampai pada pemahaman bahwa keseimbangan antara dua ekstrem diperlukan. Penting untuk melatih mesin sehingga potensi untuk melihat dan persepsi rekomendasi oleh seseorang diperhitungkan.

Bagaimana rekomendasi kami bekerja

Sistem kami adalah bagian dari Pencarian, jadi kami perlu membuat rekomendasi dengan sangat cepat: waktu respons layanan harus kurang dari 100 milidetik. Oleh karena itu, kami mencoba untuk melakukan sebanyak mungkin operasi berat offline, pada tahap persiapan data. Semua film dan pengguna dalam sistem rekomendasi diwakili oleh profil (penting untuk tidak bingung dengan akun), yang meliputi kunci objek, penghitung dan embedding (dengan kata lain, vektor di ruang tertentu). Profil film disiapkan setiap hari di YT ( dibaca sebagai "Yt" ) dan dimuat ke dalam RAM mesin yang menanggapi permintaan. Tetapi dengan pengguna, semuanya sedikit lebih rumit.

Setiap hari kami juga membuat profil pengguna utama di YT dan mengirimkannya ke toko Yandex, yang darinya Anda bisa mendapatkan profil dalam beberapa puluh milidetik. Tetapi data dengan cepat menjadi usang jika seseorang secara aktif menonton dan mengevaluasi video. Tidak baik jika rekomendasi mulai terlambat. Karenanya, kami membaca aliran acara pengguna dan membentuk bagian dinamis dari profil. Ketika seseorang memasukkan permintaan, kami menggabungkan profil dari repositori dengan profil dinamis dan mendapatkan satu profil, yang dapat tertinggal dari kenyataan hanya dalam beberapa detik.

Ini terjadi offline (yaitu, di muka), dan sekarang kita langsung menuju ke runtime. Di sini sistem rekomendasi terdiri dari dua langkah. Pemeringkatan seluruh basis data film terlalu panjang, jadi pada langkah pertama kami cukup memilih beberapa ratus kandidat, yaitu, kami menemukan film yang mungkin menarik bagi pemirsa. Ini termasuk lukisan populer dan lukisan yang dekat dengan pengguna di beberapa hiasan. Ada beberapa algoritma untuk menemukan tetangga terdekat dengan cepat, kami menggunakan HNSW (Hierarchical Navigable Small World). Dengannya, kami menemukan film yang paling dekat dengan pengguna hanya dalam beberapa milidetik.

Pada langkah kedua, kami mengekstrak fitur (kadang-kadang mereka juga disebut faktor) oleh film, pengguna dan pasangan pengguna / film dan peringkat kandidat menggunakan CatBoost. Biarkan saya mengingatkan Anda: kami sudah menyadari bahwa kami perlu fokus tidak hanya pada pandangan, tetapi juga pada karakteristik kualitas rekomendasi lainnya, jadi untuk pemeringkatan kami sampai pada kombinasi beberapa model CatBoost yang dilatih untuk berbagai target.

Untuk menemukan kandidat, kami menggunakan embeddings dari beberapa dekomposisi matriks: dari versi klasik ALS, yang memprediksi penilaian, hingga variasi yang lebih kompleks berdasarkan SVD ++. Sebagai fitur untuk peringkat, baik penghitung acara pengguna sederhana dan film, CTR untuk berbagai acara, serta model pra-pelatihan yang lebih kompleks digunakan. Misalnya, prediksi ALS juga berfungsi sebagai fitur. Salah satu model yang paling berguna adalah merekomendasikan jaringan syaraf DSSM, yang mungkin akan saya bicarakan sedikit lagi.

Rekomendasi DSSM

DSSM adalah jaringan saraf dua menara. Setiap menara membangun embedding sendiri, maka jarak cosinus dipertimbangkan antara embeddings, angka ini adalah output jaringan. Artinya, jaringan belajar untuk mengevaluasi kedekatan objek di menara kiri dan kanan. Jaringan saraf yang sama digunakan, misalnya, dalam pencarian web untuk menemukan dokumen yang relevan dengan permintaan. Untuk tugas pencarian, permintaan dikirim ke salah satu menara, dan dokumen ke yang lain. Untuk jaringan kami, peran permintaan dimainkan oleh pengguna, dan film bertindak sebagai dokumen.

Menara film ini dibangun berdasarkan data tentang film: ini adalah judul, deskripsi, genre, negara, aktor, dll. Bagian jaringan ini sangat mirip dengan pencarian. Namun, untuk pemirsa kami ingin menggunakan kisahnya. Untuk melakukan ini, kami menggabungkan penyisipan film dari cerita tersebut dengan waktu yang pudar sejak saat acara. Kemudian, di atas total embedding, kami menerapkan beberapa lapisan jaringan dan sebagai hasilnya kami mendapatkan embedding ukuran 400.



Jika Anda segera memperhitungkan seluruh riwayat pengguna dalam penyematan, ini akan sangat memperlambat pelatihan. Karena itu, kita menuju trik dan mempelajari jaringan dalam dua tahap. Pertama, pelajari InnerDSSM yang lebih sederhana. Di pintu masuk, ia hanya menerima 50 acara terakhir dari riwayat pengguna tanpa membaginya menjadi beberapa jenis acara (tampilan, peringkat ...). Kemudian kami melatih kembali InnerDSSM yang dihasilkan sepanjang sejarah pengguna, tetapi dengan pengelompokan ke dalam jenis acara. Jadi kami mendapatkan OuterDSSM, yang digunakan dalam runtime.

Menggunakan jaringan runtime di dahi membutuhkan sumber daya komputasi yang cukup banyak. Oleh karena itu, kami menyimpan embeddings dari menara film dalam database, dan embeddings menurut riwayat pengguna diperbarui dekat waktu nyata. Jadi, selama pemrosesan permintaan, Anda hanya perlu menerapkan sebagian kecil OuterDSSM dan menghitung cosinus, ini tidak memakan banyak waktu.

Kesimpulan

Sekarang rekomendasi kami sudah tersedia dalam pencarian kami (misalnya, dengan permintaan [apa yang harus dilihat] ), di layanan Yandex.Air, dan versi yang disesuaikan dari teknologi ini juga digunakan di Yandex.Stations. Tapi ini bukan berarti kita bisa santai. Kami terus melatih model baru, menerapkan lebih banyak data, mencoba pendekatan baru untuk pelatihan dan metrik kualitas baru. Menurut pendapat saya, semakin tua area, semakin sulit untuk dikembangkan. Tapi ini adalah minat utama para spesialis.