2018 में, हमारी टीम ने पारंपरिक रूप से RecSys चैलेंज में भाग लिया। यह रिकसेंसर कॉन्फ्रेंस के हिस्से के रूप में रखी गई सिफारिशकर्ताओं पर एक वार्षिक प्रतियोगिता है। यह कागल में प्रतियोगिताओं जितना बड़ा नहीं है, लेकिन इसे सिफारिश प्रणालियों में सबसे प्रतिष्ठित प्रतियोगिताओं में से एक माना जाता है। इस बार कार्य संगीतमय था - स्वचालित रूप से निरंतर प्लेलिस्ट के लिए एक प्रणाली का निर्माण करना आवश्यक था। इस पोस्ट में, मैं अपने फैसले के बारे में विस्तार से बात करता हूं। मैं आपको बिल्ली के लिए आमंत्रित करता हूं।

प्रतियोगिता के बारे में

इस वर्ष, प्रतियोगिता के लिए डेटा Spotify द्वारा प्रदान किया गया था, एक संगीत स्ट्रीमिंग सेवा (जो दुर्भाग्य से, रूसी संघ में आधिकारिक रूप से उपलब्ध नहीं है)। अनुशंसाएँ Spotify में उत्पाद के सबसे महत्वपूर्ण भागों में से एक हैं और उपयोगकर्ताओं को नए संगीत खोजने, प्लेलिस्ट बनाने या उनकी वरीयताओं के आधार पर रेडियो सुनने की अनुमति देते हैं।

प्रतियोगिता प्रतिभागियों को एक स्वचालित प्लेलिस्ट निरंतरता एल्गोरिथ्म बनाने की आवश्यकता थी। मिलियन प्लेलिस्ट दैटसेट, जिसका नाम स्वयं के लिए बोलता है, को प्रशिक्षण डेटा के रूप में प्रस्तुत किया गया था। प्लेलिस्ट में कौन से ट्रैक निहित हैं, इसके बारे में जानकारी के अलावा, पटरियों के बारे में मेटा-जानकारी भी प्रदान की गई थी: कलाकार, शीर्षक, अवधि, एल्बम का नाम।

आप यहां प्रतियोगिता के बारे में अधिक पढ़ सकते हैं।

प्रतियोगिता की चुनौती

अनुशंसा प्रणालियों के लिए प्रतियोगिता का कार्य क्लासिक है: उपयोगकर्ता के लिए शीर्ष-के अनुशंसाएँ उत्पन्न करना, उसके कार्यों के इतिहास को जानना, लेकिन सामान्य उपयोगकर्ता-आइटम के बजाय, प्लेलिस्ट-ट्रैक यहां दिखाई देता है। अधिक औपचारिक शब्दों में, प्लेलिस्ट के कुछ हिस्सों (बाद में बीज के रूप में संदर्भित) को परीक्षण के आंकड़ों में दिया गया था, और उन्हें बनाने के कई अलग-अलग तरीके थे। K = (5, 10, 25, 100) के लिए पहले K पटरियों और K पटरियों के साथ यादृच्छिक रूप से चुने गए बीज थे। पहले ट्रैक के साथ बीज भी थे और केवल प्लेलिस्ट के नाम के साथ। होल्डआउट्स में शामिल नहीं किए गए ट्रैक्स की भविष्यवाणी की जानी थी। प्रत्येक प्लेलिस्ट के लिए, ठीक 500 भविष्यवाणियों की आवश्यकता थी।

मैट्रिक्स

प्रतियोगिता की एक विशेषता यह थी कि मीट्रिक एक नहीं थी, जैसा कि अधिकांश प्रतियोगिताओं में प्रथागत है, लेकिन कई। नीचे मैं उनमें से प्रत्येक के बारे में बताऊंगा।

आर प्रेसिजन

यह मीट्रिक दिखाती है कि हमने संबंधित पटरियों के किस अनुपात का अनुमान लगाया था।

$$$R- परिशुद्धता = \ frac {| G \ cap {} R_ {1: | G |} |} |} = G | =$

NDCG

यह एक क्लासिक रैंकिंग गुणवत्ता मीट्रिक है, आप इसके बारे में पढ़ सकते हैं, उदाहरण के लिए, यहां

क्लिक्स

Spotify में प्लेलिस्ट जारी रखने के लिए एक तंत्र है (आप इसे लेख की शुरुआत में स्क्रीनशॉट में देख सकते हैं): यह कई ट्रैक प्रदान करता है जिनका उपयोग प्लेलिस्ट को विस्तारित करने के लिए किया जा सकता है और यदि कोई नहीं आया, तो आप रिफ्रेश बटन पर क्लिक कर सकते हैं और सिफारिशों का अगला बैच प्राप्त कर सकते हैं। पहली पसंद के ऐसे अपडेट की संख्या क्लिक मेट्रिक है। अधिक बस, पहले प्रासंगिक सिफारिश की स्थिति (इस मामले में, 10 से विभाजित)।

इसके बाद, टीमों को प्रत्येक मैट्रिक्स के लिए एक रैंक दिया जाता है। फिर रैंक को बोर्डा काउंट इलेक्शन स्ट्रेटेजी स्कीम के अनुसार एकत्रित किया जाता है। अगर $$$पी$प्रतिभागियों की संख्या है, फिर 1 रैंक वाली टीम मिलती है $$$p-1$अंक, 2 के रैंक के साथ एक टीम प्राप्त करता है $$$पी -2$अंक और इतने पर।

निर्णय

मान्यता योजना

ट्रेन / परीक्षण विभाजन को खेलने के लिए, हमने मूल डेटासेट को तीन भागों में विभाजित किया है: पहले भाग में 980k प्लेलिस्ट थी, दूसरे और तीसरे भाग में 10k प्रत्येक था। फिर, दूसरे और तीसरे भाग से प्रत्येक प्लेलिस्ट को बीज और होल्डआउट भागों में विभाजित किया गया था, और बीज भागों के आकार को उसी तरह से चुना गया था जैसा कि प्रदान किए गए परीक्षण सेट में था, और शेष ट्रैक होल्डआउट में गिर गए।

उम्मीदवारों का चयन

अनुशंसित सिस्टम अक्सर एक दो-चरण दृष्टिकोण का उपयोग करते हैं: सबसे पहले, एक सरल मॉडल (जैसे, मैट्रिक्स फैक्टराइजेशन ) का उपयोग करते हुए, उम्मीदवारों को आइटम के पूरे सेट से चुना जाता है, और फिर उम्मीदवारों को एक अधिक जटिल मॉडल (जैसे, ग्रेडिएंटिंग ) द्वारा गुणों के व्यापक सेट पर रैंक किया जाता है। सीमित कंप्यूटिंग संसाधनों के कारण, सबसे पहले, उम्मीदवारों का चयन आवश्यक है: यदि हम उम्मीदवारों के रूप में उपलब्ध पटरियों के पूरे सेट का उपयोग करते हैं, तो एक प्लेलिस्ट के लिए हमें मॉडल के माध्यम से लगभग एक लाख ऑब्जेक्ट को चलाना होगा।

मैट्रिक्स फैक्टराइजेशन का उपयोग कर उम्मीदवारों का चयन

मैट्रिक्स फैक्टराइजेशन निर्माण प्रणालियों के निर्माण के लिए सबसे आम तरीकों में से एक है। इस पद्धति का मुख्य विचार छोटे आयामों के दो मैट्रिक्स (यू और आई) के उत्पाद के रूप में उपयोगकर्ताओं और वस्तुओं के बीच बातचीत का एक विरल मैट्रिक्स पेश करना है। फिर हम वेक्टर I को मैट्रिक्स I से वेक्टर गुणा करके उपयोगकर्ता के लिए सिफारिशें प्राप्त कर सकते हैं।

मैट्रिक्स फैक्टराइज़ेशन के लिए, हमने WARP (भारित अनुमानित-रैंक पेयरवाइज़) नुकसान के साथ लाइटफ़एम लाइब्रेरी का उपयोग किया। हमारे पास दो अलग-अलग मॉडल भी थे - एक प्लेलिस्ट के लिए, जिसमें एक गैर-खाली बीज होता है, और दूसरा प्लेलिस्ट के लिए जिसका केवल नाम (कोल्ड स्टार्ट) होता है।

WARP नुकसान

यह नुकसान समारोह रैंकिंग कार्यों में दूसरों की तुलना में बेहतर है। यह त्रिकोणीय (उपयोगकर्ता, पॉजिटिव, एटिट्यूड, negative_item) के साथ काम करता है और इसकी एक बहुत महत्वपूर्ण विशेषता है - नकारात्मक उदाहरणों का चयन संयोग से नहीं होता है, लेकिन इस तरह से चयनित नकारात्मक उदाहरण मॉडल की वर्तमान रैंकिंग को "तोड़" देते हैं, अर्थात्। एक सकारात्मक उदाहरण से अधिक थे।

इस प्रकार, WARP हानि का उपयोग करके एक मॉडल को प्रशिक्षित करने की प्रक्रिया लगभग इस प्रकार होगी:

1. एक जोड़े के लिए $$$(उपयोगकर्ता, सकारात्मक \ _item)$हम सभी अन्य मदों के बीच एक यादृच्छिक नकारात्मक उदाहरण का चयन करेंगे (यह समझना महत्वपूर्ण है कि यह केवल तभी करने योग्य है यदि नकारात्मक उदाहरण चुनने की संभावना, जो वास्तव में सकारात्मक होगी, काफी छोटा है)। जोड़ी की भविष्यवाणी की गणना करें $$$(उपयोगकर्ता, सकारात्मक \ _item)$और $$$(उपयोगकर्ता, नकारात्मक \ _item)$और यदि कोई विकार नहीं था (जो कि मॉडल ने सकारात्मक उदाहरण के लिए उच्च स्कोर की भविष्यवाणी की थी), तो हम नकारात्मक उदाहरणों का नमूना लेते रहते हैं जब तक कि उल्लंघन नहीं होता है।
2. यदि हमें पहले प्रयास में उल्लंघन मिला है, तो हम एक बड़ा ग्रेडिएंट कदम उठा सकते हैं, क्योंकि इसका मतलब है कि इस समय मॉडल अक्सर सकारात्मक लोगों के ऊपर नकारात्मक उदाहरण डालता है और इसके वजन को दृढ़ता से अपडेट करना आवश्यक है। यदि हमें लंबे समय तक एक उपयुक्त नकारात्मक उदाहरण की तलाश करनी थी, तो हम एक छोटा कदम उठाते हैं - मॉडल पहले से ही अच्छी तरह से प्रशिक्षित है।

WARP हानि का एक अधिक औपचारिक विवरण मूल लेख या इस पोस्ट में पाया जा सकता है।

LightFM

मॉडल के पहले संस्करण में केवल सहयोगी जानकारी का उपयोग किया गया था: प्लेलिस्ट प्लेलिस्ट में ट्रैक_आईडी ट्रैक की उपस्थिति, बाइनरी स्पार्स मैट्रिक्स के रूप में प्रस्तुत की गई। कई मैट्रिसेस एक प्लेलिस्ट, एक ट्रैक के एक कॉलम के अनुरूप थे।

$$$स्कोर (p, t) = b_t + b_t + <q_p, q_t>$

LightFM + पाठ सुविधाएँ

यह मॉडल प्लेलिस्ट के नाम से प्लेलिस्ट के नाम के बजाय शब्दों के एम्बेडिंग का उपयोग करता है। किसी प्लेलिस्ट का एम्बेडिंग उसके शब्दों के एम्बेडिंग का योग है।

$$$स्कोर (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}$।
जहाँ $$$f_p$- ये प्लेलिस्ट के नाम से शब्द हैं।

इस प्रकार, हम एक ठंड शुरू होने की समस्या को हल करते हैं - हम प्लेलिस्ट के लिए बेहतर सिफारिशें प्रदान कर सकते हैं जिनका केवल एक नाम है।

प्रतियोगिता के आयोजकों ने यह भी जानकारी दी थी कि प्लेलिस्ट के छिपे हुए हिस्से में कितने ट्रैक थे। अगर छिपा हुआ हिस्सा होता $$$k$पटरियों तो हम चुनते हैं $$$अधिकतम (k * 15, k + 700)$उम्मीदवारों। इन नंबरों की प्रकृति एक साधारण विधर्मी है, जो निम्नलिखित विचारों से आविष्कृत है: हम छोटे नाटककारों के लिए पर्याप्त उम्मीदवार चाहते हैं (इसलिए) $$$k + 700$), और हम यह भी चाहते हैं कि अंतिम डेटासेट में समय और मेमोरी के मामले में प्रदर्शन कारणों से लगभग 10 मिलियन पंक्तियाँ हों (इसलिए k 15, k 50 नहीं , उदाहरण के लिए)।

श्रेणी

हमारे द्वारा चयनित उम्मीदवारों के बाद, हम अनुशंसाओं के निर्माण के कार्य को एक द्विआधारी वर्गीकरण समस्या के रूप में मान सकते हैं: चयनित उम्मीदवारों में से प्रत्येक पटरियों के लिए, हम भविष्यवाणी करना सीखते हैं कि क्या यह ट्रैक वास्तव में प्लेलिस्ट में था।

हमारे प्रशिक्षण डेटासेट में, प्रत्येक पंक्ति में जोड़ी (प्लेलिस्ट, ट्रैक) के लिए संकेत होंगे, और यदि प्लेलिस्ट में ट्रैक है और 0 नहीं तो लेबल 1 होगा।

संकेत के रूप में, कई अलग-अलग समूहों का उपयोग किया गया था।

लाइटएफएम मॉडल पर आधारित विशेषताएं

जैसा कि ऊपर वर्णित है, लाइटएफएम मॉडल में हमें वैक्टर मिला $$$q_p, q_t$और खोपड़ी $$$b_p, b_t$।
संकेतों के रूप में हम उपयोग करेंगे $$$b_p, b_t$, < $$$q_p, q_t>$और प्लेलिस्ट p के लिए सभी उम्मीदवारों के बीच ट्रैक टी की रैंक (रैंक सूत्र द्वारा गणना की गई थी)। इन चार विशेषताओं को लाइटएफएम और लाइटएफएम टेक्स्ट मॉडल दोनों से लिया गया था।

ट्रैक सह-घटना पर आधारित संकेत

चलो $$$n_ {i, j}$पटरियों से युक्त प्लेलिस्ट की संख्या है $$$मैं$और $$$ज$साथ ही साथ $$$n_i$- ट्रैक वाले प्लेलिस्ट की संख्या $$$मैं$। इन मूल्यों की गणना सभी बीज भागों से युक्त प्लेलिस्ट के एक निश्चित सेट पर की गई थी।

प्लेलिस्ट दें $$$पी$पटरियों के होते हैं $$$t_1, t_2, ..., t_n$। ट्रैक के लिए $$$टी$मानों की गणना करें $$$n_ {t, t_1}, n_ {t, t_2}, ..., n_ {t, t_n}$और उनके लिए हम विभिन्न आँकड़ों की गणना करेंगे: न्यूनतम, अधिकतम, औसत और औसत। फिर हम मात्राओं के लिए समान आँकड़ों की गणना करते हैं $$$\ frac {n_ {t, t}}} {n_ {t_1}}, \ frac {n_ {t, t_2}} {n_ {t_2}}, ..., \ frac {n_ {t, t_n}} {} n_ {t_n}}$ । पहले मामले में, हम बस देखते हैं कि प्लेलिस्ट से पटरियों के साथ लक्ष्य ट्रैक कितनी बार मिला है, और दूसरे मामले में, हम इसे अन्य पटरियों की आवृत्ति के लिए भी सामान्य करते हैं। सामान्यीकरण मॉडल को लोकप्रिय पटरियों के लिए पीछे हटने में मदद नहीं करता है और पटरियों के बारे में अधिक सटीक जानकारी निकालने में वास्तव में समान है।

अन्य संकेत

जोड़ी के लिए सभी विशेषताओं की गणना की जाती है। $$$(पी, टी)$।

• प्लेलिस्ट में अद्वितीय कलाकारों की संख्या $$$पी$।
• प्लेलिस्ट में अद्वितीय एल्बमों की संख्या $$$पी$।
• एक प्लेलिस्ट में पटरियों की संख्या और प्रतिशत $$$पी$ट्रैक के रूप में एक ही एल्बम / कलाकार के साथ $$$टी$।
• ट्रैक कितनी बार मिला $$$टी$सभी प्लेलिस्ट में।
• कलाकार / एल्बम ने कितनी बार ट्रैक किया $$$टी$सभी प्लेलिस्ट में।
• प्लेलिस्ट के बीज और होल्डआउट भागों में पटरियों की संख्या $$$पी$।

सिफारिश मॉडल

अंतिम सिफारिशों का निर्माण करने के लिए, हमने XGBoost का उपयोग किया। मॉडल को प्रशिक्षित किया गया था $$$II_ {उम्मीदवार}$, हाइपरपरमीटर का चयन किया गया $$$III_ {उम्मीदवार}$आरओसी एयूसी मीट्रिक द्वारा। इस मीट्रिक को इसलिए चुना गया क्योंकि यह वर्गीकरण की समस्याओं के लिए शास्त्रीय है। सभी विशेषताएं समान रूप से उपयोगी नहीं हैं, इसलिए मॉडल के विशेषता महत्व के मूल्यों को देखना दिलचस्प होगा।

यह देखा जा सकता है कि सह-घटना सामान्यीकृत का संकेत काफी हद तक दूसरों से बाहर खड़ा है। इसका मतलब यह है कि पटरियों की सह-घटना के बारे में जानकारी बहुत मजबूत संकेत देती है, जो सामान्य रूप से आश्चर्य की बात नहीं है। इसके अलावा, इस सुविधा का उपयोग लाइटफ़ एम मॉडल के बजाय एक उम्मीदवार के चयन के रूप में किया जा सकता है, और इसने परिणाम को और भी बदतर बना दिया।

अन्य

लोहा

सभी मॉडल इंटेल Xeon E5-2679 v3 (28 कोर, 56 धागे), 256 जीबी रैम के साथ सर्वर पर प्रशिक्षित किए गए थे। अंतिम पाइपलाइन सीखने में लगभग 100 घंटे लगते हैं और पीक पर 200 जीबी मेमोरी की खपत होती है, और समय का एक महत्वपूर्ण (लगभग 90%) उम्मीदवार चयन मॉडल के प्रशिक्षण में खर्च किया गया था। रैंकिंग मॉडल को बहुत तेज़ी से प्रशिक्षित किया गया था - लगभग दो घंटे (हाइपरपरमेटर्स के चयन की गिनती नहीं)।

Feil

बिना असफल हुए नहीं।

प्रतियोगिता के कठिन दिन पर, हमने एक मिनी-हैकथॉन की व्यवस्था करने का फैसला किया, अंत में हमने वह सब कुछ एकत्र किया जो हमारे पास था: सह-घटना के आधार पर उम्मीदवारों का चयन, बूस्टिंग के लिए नई सुविधाओं का एक गुच्छा, और ऐसा लगेगा कि ऐसा हो सकता है?
लेकिन सत्यापन की गति वास्तव में थोड़ी बढ़ गई थी, इसलिए हमने सबमिशन को अंधा कर दिया और इसे भेजा, योजना बनाई कि हमारे पास जाम को ठीक करने के लिए एक दिन शेष होगा। जमा भेजने के बाद, उन्हें पता चला कि यह दिन नहीं, बल्कि आखिरी दिन था। और नए सबमिट की गति हमारे सर्वश्रेष्ठ सबमिट की तुलना में बहुत कम थी। यह पता लगाने का कोई समय नहीं था कि ऐसा क्यों हुआ, इसलिए हमने सबसे अच्छा जमा प्रस्तुत किया, जो तीसरे स्थान पर रहा।

अंतिम दिन भी, हमने सीखा कि दो अलग-अलग प्रकार के बीज हैं: पहले के पटरियों के साथ, और यादृच्छिक वाले, और सत्यापन में हमने हमेशा यादृच्छिक लोगों को चुना, लेकिन लीडरबोर्ड पर इसका शायद ही कोई बड़ा प्रभाव होगा।
प्रतियोगिता के एक दिन, लीडरबोर्ड पर सभी टीमों के लिए आर-प्रेसिजन मीट्रिक का मूल्य तेजी से बढ़ गया। हमने इसके लिए कोई महत्व नहीं दिया, लेकिन प्रतियोगिता के अंत में हमें पता चला कि आयोजकों ने मीट्रिक के एक और घटक को जोड़ा - ट्रैक कलाकार का एक मैच। यह सत्यापन मीट्रिक में भी जोड़ा जा सकता है और, संभवतः, बेहतर गति।

कोड

हमारा समाधान जुपिटर-लैपटॉप के रूप में तैयार किया गया है और इसे क्रमिक रूप से चलाकर पुन: पेश किया जा सकता है। केवल इसके लिए आपको 200Gb + RAM और एक दो दिन की मशीन चाहिए।

अन्य प्रतिभागियों के निर्णय

पहली जगह जीतने वाली टीम भी नियमित रूप से रेसिस चैलेंज में भाग लेती है और उच्च स्थान लेती है। उनका समाधान हमारे समान है, लेकिन जावा में लागू किया गया है ।

दूसरे फाइनलिस्ट के पास एक दिलचस्प दृष्टिकोण है - उन्होंने अपने भागों से प्लेलिस्ट को बहाल करने के लिए डेनोइसिंग ऑटोकेनडर का उपयोग किया।

निष्कर्ष

यदि आप अंतिम लीडरबोर्ड को देखते हैं, तो हमारी टीम रैंकिंग मेट्रिक्स (आर-सटीक और एनडीसीजी) में छठे और चौथे स्थान पर है, और पहले क्लिक मेट्रिक में। यह कैसे हुआ? और ऐसा इसलिए हुआ क्योंकि LightFM Text मॉडल का उपयोग करके कोल्ड स्टार्ट समस्या के अच्छे समाधान के कारण। जब हम प्लेलिस्ट से एक भी ट्रैक का अनुमान नहीं लगाते हैं, तो क्लिक मीट्रिक अधिक गंभीर रूप से जुर्माना करता है। लाइटएफएम टेक्स्ट मॉडल के उपयोग से क्लिक औसत मीट्रिक में 2.2 से 1.78 तक सुधार हुआ।

सरल मॉडल का उपयोग करने वाले उम्मीदवारों का चयन और अधिक जटिल मॉडल के साथ आगे की रैंकिंग अभी भी टॉप-के सिफारिशों के निर्माण की क्लासिक समस्याओं में सबसे सफल में से एक है। लेकिन साथ ही, सत्यापन योजना का सही ढंग से निर्माण करना बहुत महत्वपूर्ण है ताकि उम्मीदवार चयन मॉडल और रैंकिंग मॉडल दोनों की तुलना की जा सके।

इसके अलावा, यह योजना उत्पादन प्रणालियों के लिए काफी उपयुक्त है - आप मैट्रिक्स फैक्टराइजेशन के आधार पर अपनी सिफारिश प्रणाली का निर्माण शुरू कर सकते हैं, और फिर इसे दूसरे चरण में जोड़कर सुधार कर सकते हैं।

यदि आप लेख के बारे में कोई प्रश्न पूछना चाहते हैं, तो बेझिझक उनसे टिप्पणी में पूछें :)

पुनश्च हमने इस बारे में अधिक विस्तृत लेख आरईएसवाईएस सम्मेलन में कार्यशाला के लिए लिखा। साइट पर उसकी सामग्री तक पहुंच सीमित है, इसलिए यदि आप हमारे समाधान के बारे में कुछ और जानकारी जानने में रुचि रखते हैं, तो मुझे पीएम में लिखें।