फेब्रुवारी-मार्च 2019 मध्ये, सोशल नेटवर्क फीड रँक करण्यासाठी एक स्पर्धा आयोजित करण्यात आली होती SNA हॅकाथॉन 2019, ज्यामध्ये आमच्या संघाने प्रथम स्थान मिळविले. लेखात मी स्पर्धेचे आयोजन, आम्ही प्रयत्न केलेल्या पद्धती आणि मोठ्या डेटावरील प्रशिक्षणासाठी कॅटबूस्ट सेटिंग्जबद्दल बोलेन.

SNA हॅकाथॉन

या नावाने हॅकाथॉन आयोजित करण्याची ही तिसरी वेळ आहे. हे सामाजिक नेटवर्क ok.ru द्वारे आयोजित केले जाते, अनुक्रमे, कार्य आणि डेटा थेट या सोशल नेटवर्कशी संबंधित आहेत.
या प्रकरणात एसएनए (सोशल नेटवर्क विश्लेषण) हे सामाजिक आलेखाचे विश्लेषण म्हणून नव्हे तर सामाजिक नेटवर्कचे विश्लेषण म्हणून अधिक योग्यरित्या समजले जाते.

• 2014 मध्ये, एखाद्या पोस्टला किती लाईक्स मिळतील याचा अंदाज बांधणे हे काम होते.
• 2016 मध्ये - व्हीव्हीझेड कार्य (कदाचित आपण परिचित आहात), सामाजिक आलेखच्या विश्लेषणाच्या जवळ.
• 2019 मध्ये, वापरकर्त्याला पोस्ट आवडेल या शक्यतेवर आधारित वापरकर्त्याच्या फीडची रँकिंग केली जाते.

मी 2014 बद्दल सांगू शकत नाही, परंतु 2016 आणि 2019 मध्ये डेटा विश्लेषण क्षमतेव्यतिरिक्त, मोठ्या डेटासह कार्य करण्याचे कौशल्य देखील आवश्यक होते. मला वाटते की मशीन लर्निंग आणि डेटा प्रोसेसिंगच्या मोठ्या समस्यांचे संयोजन मला या स्पर्धांकडे आकर्षित करते आणि या क्षेत्रातील माझ्या अनुभवाने मला जिंकण्यास मदत केली.

mlbootcamp

2019 मध्ये व्यासपीठावर स्पर्धा आयोजित करण्यात आली होती https://mlbootcamp.ru.

ही स्पर्धा 7 फेब्रुवारी रोजी ऑनलाइन सुरू झाली आणि त्यात 3 कार्ये होती. साइटवर कोणीही नोंदणी करू शकते, डाउनलोड करू शकते बेसलाइन आणि काही तासांसाठी तुमची कार लोड करा. 15 मार्च रोजी ऑनलाइन स्टेजच्या शेवटी, प्रत्येक शो जंपिंग इव्हेंटच्या शीर्ष 15 जणांना 30 मार्च ते 1 एप्रिल या कालावधीत झालेल्या ऑफलाइन स्टेजसाठी Mail.ru कार्यालयात आमंत्रित केले गेले.

उद्दिष्ट

स्त्रोत डेटा वापरकर्ता आयडी (userId) आणि पोस्ट आयडी (objectId) प्रदान करतो. जर वापरकर्त्याला पोस्ट दाखवली असेल, तर डेटामध्ये userId, objectId, या पोस्टवरील वापरकर्त्याच्या प्रतिक्रिया (फीडबॅक) आणि विविध वैशिष्ट्यांचा संच किंवा चित्रे आणि मजकूरांच्या लिंक्स असलेली एक ओळ असते.

userId	ऑब्जेक्ट आयडी	मालक आयडी	अभिप्राय	प्रतिमा
3555	22	5677	[आवडले, क्लिक केले]	[हॅश१]
12842	55	32144	[नापसंत]	[हॅश2,हॅश3]
13145	35	5677	[क्लिक केले, शेअर केले]	[हॅश१]

चाचणी डेटा सेटमध्ये समान रचना आहे, परंतु फीडबॅक फील्ड गहाळ आहे. फीडबॅक फील्डमध्ये 'आवडलेल्या' प्रतिक्रियेच्या उपस्थितीचा अंदाज लावणे हे कार्य आहे.
सबमिशन फाइलची खालील रचना आहे:

userId	क्रमवारी सूची[ऑब्जेक्ट आयडी]
123	78,13,54,22
128	35,61,55
131	35,68,129,11

मेट्रिक हे वापरकर्त्यांसाठी सरासरी ROC AUC आहे.

डेटाचे अधिक तपशीलवार वर्णन येथे आढळू शकते कौन्सिल वेबसाइट. तुम्ही तेथे चाचण्या आणि चित्रांसह डेटा देखील डाउनलोड करू शकता.

ऑनलाइन स्टेज

ऑनलाइन टप्प्यावर, कार्य 3 भागांमध्ये विभागले गेले होते

• सहयोगी यंत्रणा - प्रतिमा आणि मजकूर वगळता सर्व वैशिष्ट्ये समाविष्ट आहेत;
• प्रतिमा - केवळ प्रतिमांबद्दल माहिती समाविष्ट करते;
• मजकूर - केवळ मजकुरांबद्दल माहिती समाविष्ट करते.

ऑफलाइन स्टेज

ऑफलाइन टप्प्यावर, डेटामध्ये सर्व वैशिष्ट्ये समाविष्ट आहेत, तर मजकूर आणि प्रतिमा विरळ होत्या. डेटासेटमध्ये 1,5 पट अधिक पंक्ती होत्या, त्यापैकी आधीच भरपूर होत्या.

समस्येचे निराकरण

मी कामावर CV करत असल्याने, मी या स्पर्धेतील माझा प्रवास “Images” टास्कने सुरू केला. वापरकर्ता आयडी, ऑब्जेक्ट आयडी, मालक आयडी (ज्या गटामध्ये पोस्ट प्रकाशित करण्यात आली होती), पोस्ट तयार करण्यासाठी आणि प्रदर्शित करण्यासाठी टाइमस्टॅम्प आणि अर्थातच, या पोस्टसाठी प्रतिमा प्रदान करण्यात आला होता.
टाइमस्टॅम्पवर आधारित अनेक वैशिष्ट्ये व्युत्पन्न केल्यानंतर, इमेजनेटवर पूर्व-प्रशिक्षित न्यूरॉनचा उपांत्य स्तर घेणे आणि हे एम्बेडिंग बूस्टिंगसाठी पाठवणे ही पुढील कल्पना होती.

परिणाम प्रभावी नव्हते. इमेजनेट न्यूरॉनमधील एम्बेडिंग अप्रासंगिक आहेत, मला वाटले, मला स्वतःचे ऑटोएनकोडर बनवावे लागेल.

यात बराच वेळ गेला आणि परिणाम सुधारला नाही.

वैशिष्ट्य निर्मिती

प्रतिमांसह कार्य करण्यास बराच वेळ लागतो, म्हणून मी काहीतरी सोपे करण्याचा निर्णय घेतला.
जसे तुम्ही लगेच पाहू शकता, डेटासेटमध्ये अनेक स्पष्ट वैशिष्ट्ये आहेत आणि जास्त त्रास होऊ नये म्हणून, मी नुकतेच catboost घेतले. समाधान उत्कृष्ट होते, कोणत्याही सेटिंग्जशिवाय मी लगेच लीडरबोर्डच्या पहिल्या ओळीत पोहोचलो.

भरपूर डेटा आहे आणि तो पर्केट स्वरूपात मांडला आहे, म्हणून दोनदा विचार न करता, मी स्केला घेतला आणि सर्व काही स्पार्कमध्ये लिहायला सुरुवात केली.

प्रतिमा एम्बेडिंगपेक्षा अधिक वाढ देणारी सर्वात सोपी वैशिष्ट्ये:

• डेटामध्ये ऑब्जेक्टआयडी, यूजरआयडी आणि मालक आयडी किती वेळा दिसले (लोकप्रियतेशी संबंधित असावे);
• युजरआयडीने मालक आयडीवरून किती पोस्ट पाहिल्या आहेत (गटातील वापरकर्त्याच्या स्वारस्याशी संबंधित असावे);
• मालक आयडी वरून किती अनन्य वापरकर्ता आयडींनी पोस्ट पाहिल्या (गटाच्या प्रेक्षकांचा आकार प्रतिबिंबित करते).

टाइमस्टॅम्पवरून वापरकर्त्याने फीड पाहिलेल्या दिवसाची वेळ (सकाळी/दुपार/संध्याकाळ/रात्री) मिळवणे शक्य होते. या श्रेण्या एकत्र करून, तुम्ही वैशिष्ट्ये निर्माण करणे सुरू ठेवू शकता:

• युजरआयडीने संध्याकाळी किती वेळा लॉग इन केले;
• कोणत्या वेळी ही पोस्ट बहुतेकदा दर्शविली जाते (ऑब्जेक्टआयडी) आणि असेच.

या सगळ्यामुळे हळूहळू मेट्रिक्स सुधारत गेले. परंतु प्रशिक्षण डेटासेटचा आकार सुमारे 20M रेकॉर्ड आहे, त्यामुळे वैशिष्ट्ये जोडल्याने प्रशिक्षण मोठ्या प्रमाणात मंदावले.

डेटा वापरण्याच्या माझ्या दृष्टिकोनावर मी पुनर्विचार केला आहे. जरी डेटा वेळेवर अवलंबून असला तरी, मला "भविष्यात" कोणतीही स्पष्ट माहिती लीक झाल्याचे दिसले नाही, तरीही, फक्त बाबतीत, मी ते असे तोडले:

आम्हाला दिलेला प्रशिक्षण संच (फेब्रुवारी आणि मार्चचे 2 आठवडे) 2 भागांमध्ये विभागले गेले.
मॉडेलला मागील N दिवसांच्या डेटावर प्रशिक्षण देण्यात आले. वर वर्णन केलेले एकत्रीकरण चाचणीसह सर्व डेटावर तयार केले गेले होते. त्याच वेळी, डेटा दिसला ज्यावर लक्ष्य व्हेरिएबलचे विविध एन्कोडिंग तयार करणे शक्य आहे. सर्वात सोपा दृष्टीकोन म्हणजे कोडचा पुनर्वापर करणे जो आधीच नवीन वैशिष्ट्ये तयार करत आहे आणि फक्त त्याला डेटा फीड करणे ज्यावर तो प्रशिक्षित होणार नाही आणि लक्ष्य = 1.

अशा प्रकारे, आम्हाला समान वैशिष्ट्ये मिळाली:

• युजरआयडीने ग्रुप ओनरआयडीमध्ये किती वेळा पोस्ट पाहिली आहे;
• ग्रुप ओनरआयडीमधील पोस्ट युजरआयडीला किती वेळा आवडली;
• userId ला मालक आयडी वरून आवडलेल्या पोस्टची टक्केवारी.

म्हणजेच ते निघाले म्हणजे लक्ष्य एन्कोडिंग विशिष्ट वैशिष्ट्यांच्या विविध संयोजनांसाठी डेटासेटच्या भागावर. तत्वतः, कॅटबूस्ट लक्ष्य एन्कोडिंग देखील तयार करते आणि या दृष्टिकोनातून कोणताही फायदा नाही, परंतु, उदाहरणार्थ, या गटातील पोस्ट आवडलेल्या अद्वितीय वापरकर्त्यांची संख्या मोजणे शक्य झाले. त्याच वेळी, मुख्य ध्येय साध्य केले गेले - माझा डेटासेट अनेक वेळा कमी केला गेला आणि वैशिष्ट्ये निर्माण करणे सुरू ठेवणे शक्य झाले.

कॅटबूस्ट फक्त आवडलेल्या प्रतिक्रियेवर आधारित एन्कोडिंग तयार करू शकते, फीडबॅकमध्ये इतर प्रतिक्रिया असतात: रीशेअर, नापसंत, नापसंत, क्लिक केलेले, दुर्लक्षित, एन्कोडिंग ज्यासाठी मॅन्युअली केले जाऊ शकते. डेटासेट वाढू नये म्हणून मी सर्व प्रकारच्या एकत्रितांची पुनर्गणना केली आणि कमी महत्त्व असलेली वैशिष्ट्ये काढून टाकली.

तोपर्यंत मी मोठ्या फरकाने पहिल्या स्थानावर होतो. फक्त एक गोष्ट गोंधळात टाकणारी होती की इमेज एम्बेडिंगने जवळजवळ कोणतीही वाढ दर्शविली नाही. कॅटबूस्टला सर्वकाही देण्याची कल्पना आली. आम्ही Kmeans प्रतिमा क्लस्टर करतो आणि एक नवीन स्पष्ट वैशिष्ट्य imageCat मिळवतो.

KMeans मधून मिळवलेले क्लस्टर्स मॅन्युअल फिल्टरिंग आणि विलीन केल्यानंतर येथे काही वर्ग आहेत.

imageCat वर आधारित आम्ही व्युत्पन्न करतो:

• नवीन वर्गीय वैशिष्ट्ये:
  • userId द्वारे कोणती imageCat बहुतेक वेळा पाहिली गेली;
  • कोणती इमेज कॅट बहुतेकदा मालक आयडी दर्शवते;
  • userId द्वारे कोणती imageCat सर्वाधिक पसंत केली गेली;
• विविध काउंटर:
  • युजरआयडीकडे किती युनिक इमेज कॅटने पाहिले;
  • वर वर्णन केल्याप्रमाणे सुमारे 15 समान वैशिष्ट्ये अधिक लक्ष्य एन्कोडिंग.

मजकूर

प्रतिमा स्पर्धेतील निकाल माझ्यासाठी अनुकूल ठरले आणि मी मजकूरांवर प्रयत्न करण्याचा निर्णय घेतला. मी याआधी मजकूरांसह जास्त काम केले नाही आणि मूर्खपणाने, मी tf-idf आणि svd वर दिवस मारला. मग मी doc2vec सह बेसलाइन पाहिली, जे मला आवश्यक तेच करते. doc2vec पॅरामीटर्स किंचित समायोजित केल्यावर, मला मजकूर एम्बेडिंग मिळाले.

आणि मग मी फक्त इमेजसाठी कोड पुन्हा वापरला, ज्यामध्ये मी इमेज एम्बेडिंग्ज मजकूर एम्बेडिंगसह बदलले. परिणामी, मी मजकूर स्पर्धेत दुसरा क्रमांक पटकावला.

सहयोगी यंत्रणा

एक स्पर्धा बाकी होती जी मी अजून काठीने "पोक" केलेली नव्हती आणि लीडरबोर्डवरील AUC द्वारे निर्णय घेतल्यास, या विशिष्ट स्पर्धेच्या निकालांचा ऑफलाइन स्टेजवर सर्वात जास्त परिणाम व्हायला हवा होता.
मी स्त्रोत डेटामध्ये असलेली सर्व वैशिष्ट्ये घेतली, वर्गीकृत निवडली आणि प्रतिमांवर आधारित वैशिष्ट्ये वगळता, प्रतिमांसाठी समान समुच्चयांची गणना केली. हे फक्त कॅटबूस्टमध्ये टाकल्याने मला दुसरे स्थान मिळाले.

कॅटबूस्ट ऑप्टिमायझेशनची पहिली पायरी

एक प्रथम आणि दोन द्वितीय स्थान मला आनंदित केले, परंतु एक समज होती की मी काही विशेष केले नाही, याचा अर्थ मी पद गमावण्याची अपेक्षा करू शकतो.

स्पर्धेचे कार्य वापरकर्त्यामधील पोस्ट रँक करणे आहे आणि या सर्व वेळी मी वर्गीकरण समस्या सोडवत होतो, म्हणजेच चुकीचे मेट्रिक ऑप्टिमाइझ करत होतो.

मी तुम्हाला एक साधे उदाहरण देतो:

userId	ऑब्जेक्ट आयडी	अंदाज	खरे सत्य
1	10	0.9	1
1	11	0.8	1
1	12	0.7	1
1	13	0.6	1
1	14	0.5	0
2	15	0.4	0
2	16	0.3	1

चला एक छोटी पुनर्रचना करूया

userId	ऑब्जेक्ट आयडी	अंदाज	खरे सत्य
1	10	0.9	1
1	11	0.8	1
1	12	0.7	1
1	13	0.6	0
2	16	0.5	1
2	15	0.4	0
1	14	0.3	1

आम्हाला खालील परिणाम मिळतात:

मॉडेल	एयूसी	वापरकर्ता1 AUC	वापरकर्ता2 AUC	म्हणजे AUC
पर्याय 1	0,8	1,0	0,0	0,5
पर्याय 2	0,7	0,75	1,0	0,875

तुम्ही बघू शकता, एकूण AUC मेट्रिक सुधारणे म्हणजे वापरकर्त्यामधील सरासरी AUC मेट्रिक सुधारणे असा होत नाही.

कॅटबूस्ट रँकिंग मेट्रिक्स कसे ऑप्टिमाइझ करायचे हे माहित आहे बॉक्समधून. मी रँकिंग मेट्रिक्सबद्दल वाचले, यशोगाथा catboost वापरताना आणि रात्रभर ट्रेन करण्यासाठी YetiRankPairwise सेट करा. परिणाम प्रभावी नव्हता. मी कमी प्रशिक्षण घेतले आहे हे ठरवून, मी त्रुटी फंक्शन QueryRMSE मध्ये बदलले, जे, catboost दस्तऐवजीकरणानुसार, वेगाने एकत्रित होते. सरतेशेवटी, वर्गीकरणासाठी प्रशिक्षण घेत असताना मला समान परिणाम मिळाले, परंतु या दोन मॉडेल्सच्या जोडणीने चांगली वाढ केली, ज्यामुळे मला तिन्ही स्पर्धांमध्ये प्रथम स्थान मिळाले.

"सहयोगी प्रणाली" स्पर्धेचा ऑनलाइन टप्पा संपण्याच्या 5 मिनिटे आधी, सेर्गेई शालनोव्हने मला दुसऱ्या स्थानावर नेले. पुढच्या वाटेला आम्ही एकत्रच निघालो.

ऑफलाइन टप्प्यासाठी तयारी करत आहे

आम्हाला ऑनलाइन स्टेजमध्ये RTX 2080 TI व्हिडिओ कार्डसह विजयाची हमी देण्यात आली होती, परंतु 300 रूबलचे मुख्य बक्षीस आणि बहुधा, अंतिम प्रथम स्थान देखील आम्हाला या 000 आठवड्यांसाठी काम करण्यास भाग पाडले.

असे झाले की, सेर्गेने कॅटबूस्ट देखील वापरले. आम्ही कल्पना आणि वैशिष्ट्यांची देवाणघेवाण केली आणि मी याबद्दल शिकलो अण्णा वेरोनिका डोरोगुश यांचा अहवाल ज्यात माझ्या अनेक प्रश्नांची उत्तरे आहेत आणि त्या वेळेपर्यंत माझ्याकडे नव्हत्या.

अहवाल पाहिल्यानंतर मला कल्पना आली की आपल्याला सर्व पॅरामीटर्स डीफॉल्ट मूल्यावर परत करणे आवश्यक आहे आणि सेटिंग्ज अतिशय काळजीपूर्वक आणि वैशिष्ट्यांचा संच निश्चित केल्यानंतरच करा. आता एका प्रशिक्षणाला सुमारे 15 तास लागले, परंतु एका मॉडेलने रँकिंगसह एकत्रित केलेल्या वेगापेक्षा चांगला वेग प्राप्त केला.

वैशिष्ट्य निर्मिती

कोलॅबोरेटिव्ह सिस्टम्स स्पर्धेत, मॉडेलसाठी मोठ्या प्रमाणात वैशिष्ट्यांचे मूल्यमापन केले जाते. उदाहरणार्थ, auditweights_spark_svd - सर्वात महत्वाचे चिन्ह, परंतु त्याचा अर्थ काय आहे याबद्दल कोणतीही माहिती नाही. मला वाटले की महत्त्वाच्या वैशिष्ट्यांच्या आधारे विविध समुच्चयांची गणना करणे फायदेशीर ठरेल. उदाहरणार्थ, वापरकर्त्याद्वारे, गटानुसार, ऑब्जेक्टद्वारे सरासरी ऑडिटवेट_स्पार्क_एसव्हीडी. ज्या डेटावर कोणतेही प्रशिक्षण दिले जात नाही आणि लक्ष्य = 1, म्हणजे सरासरी, याचा वापर करून त्याची गणना केली जाऊ शकते auditweights_spark_svd वापरकर्त्याद्वारे त्याला आवडलेल्या वस्तूंद्वारे. याशिवाय महत्त्वाची चिन्हे auditweights_spark_svd, अनेक होते. त्यापैकी काही येथे आहेत:

• auditweightsCtrGender
• ऑडिटवेटCtrHigh
• userOwnerCounterCreateLikes

उदाहरणार्थ, सरासरी auditweightsCtrGender userId नुसार हे एक महत्त्वाचे वैशिष्ट्य ठरले, अगदी सरासरी मूल्याप्रमाणे userOwnerCounterCreateLikes userId+ownerId द्वारे. यामुळे तुम्हाला फील्डचा अर्थ समजून घेणे आवश्यक आहे असे तुम्हाला आधीच वाटले पाहिजे.

महत्वाची वैशिष्ट्ये देखील होती ऑडिटवेट लाइकसंख्या и ऑडिटवेटशो काउंट. एकाला दुसर्‍याने विभाजित केल्याने आणखी एक महत्त्वाचे वैशिष्ट्य प्राप्त झाले.

डेटा लीक

स्पर्धा आणि उत्पादन मॉडेलिंग खूप भिन्न कार्ये आहेत. डेटा तयार करताना, सर्व तपशील विचारात घेणे आणि चाचणीमध्ये लक्ष्य व्हेरिएबलबद्दल काही क्षुल्लक माहिती न देणे खूप कठीण आहे. आम्ही उत्पादन उपाय तयार करत असल्यास, आम्ही मॉडेलला प्रशिक्षण देताना डेटा लीक टाळण्याचा प्रयत्न करू. पण जर आम्हाला स्पर्धा जिंकायची असेल, तर डेटा लीक हे सर्वोत्तम वैशिष्ट्य आहे.

डेटाचा अभ्यास केल्यावर, आपण ते ऑब्जेक्टआयडी मूल्यांनुसार पाहू शकता ऑडिटवेट लाइकसंख्या и ऑडिटवेटशो काउंट बदल, म्हणजे या वैशिष्ट्यांच्या कमाल मूल्यांचे गुणोत्तर प्रदर्शनाच्या वेळी असलेल्या गुणोत्तरापेक्षा पोस्ट रूपांतरण अधिक चांगले प्रतिबिंबित करेल.

आम्हाला आढळलेली पहिली गळती आहे auditweightsLikesCountMax/auditweightsShowsCountMax.
पण जर आपण डेटाकडे अधिक बारकाईने पाहिले तर? चला शो तारखेनुसार क्रमवारी लावा आणि मिळवा:

ऑब्जेक्ट आयडी	userId	ऑडिटवेटशो काउंट	ऑडिटवेट लाइकसंख्या	लक्ष्य (आवडले आहे)
1	1	12	3	कदाचित नाही
1	2	15	3	कदाचित होय
1	3	16	4

मला आश्चर्य वाटले जेव्हा मला असे पहिले उदाहरण सापडले आणि असे दिसून आले की माझी भविष्यवाणी खरी ठरली नाही. परंतु, ऑब्जेक्टमधील या वैशिष्ट्यांच्या कमाल मूल्यांमध्ये वाढ झाली आहे हे लक्षात घेऊन, आम्ही आळशी नव्हतो आणि शोधण्याचा निर्णय घेतला. ऑडिटवेटशो काउंटनेक्स्ट и auditweightsLikesCountNext, म्हणजे, वेळेच्या पुढच्या क्षणी मूल्ये. एक वैशिष्ट्य जोडून
(auditweightsShowsCountNext-auditweightsShowsCount)/(auditweightsLikesCount-auditweightsLikesCountNext) आम्ही पटकन तीक्ष्ण उडी मारली.
खालील मूल्ये शोधून तत्सम गळती वापरली जाऊ शकते userOwnerCounterCreateLikes userId+ownerId मध्ये आणि उदाहरणार्थ, auditweightsCtrGender objectId+userGender मध्ये. आम्हाला लीक असलेली 6 समान फील्ड सापडली आणि त्यांच्याकडून शक्य तितकी माहिती काढली.

तोपर्यंत, आम्ही सहयोगी वैशिष्ट्यांमधून शक्य तितकी माहिती पिळून काढली होती, परंतु प्रतिमा आणि मजकूर स्पर्धांमध्ये परतलो नाही. मला तपासण्याची एक चांगली कल्पना होती: संबंधित स्पर्धांमध्ये प्रतिमा किंवा मजकूरांवर आधारित वैशिष्ट्ये थेट किती देतात?

प्रतिमा आणि मजकूर स्पर्धांमध्ये कोणतेही लीक नव्हते, परंतु तोपर्यंत मी डिफॉल्ट कॅटबूस्ट पॅरामीटर्स परत केले होते, कोड साफ केला होता आणि काही वैशिष्ट्ये जोडली होती. एकूण होते:

निर्णय	लवकरच
प्रतिमांसह कमाल	0.6411
कमाल नाही प्रतिमा	0.6297
द्वितीय क्रमांकाचा निकाल	0.6295

निर्णय	लवकरच
मजकूरांसह कमाल	0.666
मजकुराशिवाय कमाल	0.660
द्वितीय क्रमांकाचा निकाल	0.656

निर्णय	लवकरच
सहकार्यात जास्तीत जास्त	0.745
द्वितीय क्रमांकाचा निकाल	0.723

हे स्पष्ट झाले की आम्ही मजकूर आणि प्रतिमांमधून बरेच काही पिळून काढू शकलो नाही आणि काही सर्वात मनोरंजक कल्पनांचा प्रयत्न केल्यानंतर, आम्ही त्यांच्याबरोबर काम करणे थांबवले.

सहयोगी प्रणालींमधील वैशिष्ट्यांच्या पुढील पिढीने वाढ दिली नाही आणि आम्ही रँकिंग सुरू केले. ऑनलाइन टप्प्यावर, वर्गीकरण आणि रँकिंगच्या जोडणीने मला थोडीशी वाढ दिली, कारण मी वर्गीकरणाचे प्रशिक्षण घेतले आहे. लॉगलॉसने (०.७४५ वि. ०.७२५) केलेल्या निकालाच्या जवळपास कोठेही YetiRanlPairwise सह एरर फंक्शन तयार झाले नाही. QueryCrossEntropy साठी अजूनही आशा होती, जी लॉन्च होऊ शकली नाही.

ऑफलाइन स्टेज

ऑफलाइन टप्प्यावर, डेटा संरचना समान राहिली, परंतु किरकोळ बदल झाले:

• अभिज्ञापक userId, objectId, ownerId पुन्हा यादृच्छिक केले गेले;
• अनेक चिन्हे काढून टाकण्यात आली आणि अनेकांची नावे बदलण्यात आली;
• डेटा अंदाजे 1,5 पट वाढला आहे.

सूचीबद्ध अडचणींव्यतिरिक्त, एक मोठा प्लस होता: संघाला RTX 2080TI सह एक मोठा सर्व्हर वाटप करण्यात आला. मी बर्याच काळापासून htop चा आनंद घेतला आहे.

फक्त एक कल्पना होती - आधीपासून अस्तित्वात असलेल्या गोष्टींचे पुनरुत्पादन करणे. सर्व्हरवर वातावरण सेट करण्यासाठी काही तास घालवल्यानंतर, आम्ही हळूहळू परिणाम पुनरुत्पादक असल्याचे सत्यापित करू लागलो. डेटा व्हॉल्यूममध्ये वाढ ही मुख्य समस्या आहे. आम्ही भार थोडा कमी करण्याचे ठरवले आणि catboost पॅरामीटर ctr_complexity=1 सेट केले. यामुळे गती थोडी कमी होते, परंतु माझे मॉडेल कार्य करू लागले, परिणाम चांगला होता - 0,733. सेर्गेईने, माझ्या विपरीत, डेटाला 2 भागांमध्ये विभाजित केले नाही आणि सर्व डेटावर प्रशिक्षण दिले, जरी यामुळे ऑनलाइन टप्प्यावर सर्वोत्तम परिणाम मिळाले, ऑफलाइन टप्प्यावर अनेक अडचणी होत्या. जर आम्ही व्युत्पन्न केलेली सर्व वैशिष्ट्ये घेतली आणि त्यांना कॅटबूस्टमध्ये ढकलण्याचा प्रयत्न केला, तर ऑनलाइन टप्प्यावर काहीही कार्य करणार नाही. सेर्गेने टाइप ऑप्टिमायझेशन केले, उदाहरणार्थ, फ्लोट64 प्रकारांना फ्लोट32 मध्ये रूपांतरित करणे. या लेखातील, आपण पांडांमध्ये मेमरी ऑप्टिमायझेशनची माहिती शोधू शकता. परिणामी, सर्जीने सर्व डेटा वापरून CPU वर प्रशिक्षण दिले आणि सुमारे 0,735 मिळाले.

हे परिणाम जिंकण्यासाठी पुरेसे होते, परंतु आम्ही आमचा खरा वेग लपवला आणि इतर संघ असे करत नाहीत याची खात्री पटली नाही.

शेवटपर्यंत लढा

Catboost ट्यूनिंग

आमचे समाधान पूर्णपणे पुनरुत्पादित केले गेले, आम्ही मजकूर डेटा आणि प्रतिमांची वैशिष्ट्ये जोडली, त्यामुळे फक्त कॅटबूस्ट पॅरामीटर्स ट्यून करणे बाकी होते. सेर्गेने CPU वर थोड्या पुनरावृत्तीसह प्रशिक्षण दिले आणि मी ctr_complexity=1 सह प्रशिक्षण घेतले. एक दिवस बाकी होता, आणि जर तुम्ही फक्त पुनरावृत्ती जोडली किंवा ctr_complexity वाढवली, तर सकाळपर्यंत तुम्हाला आणखी चांगला वेग मिळेल आणि दिवसभर चालता येईल.

ऑफलाइन टप्प्यावर, साइटवर सर्वोत्तम उपाय न निवडून वेग अगदी सहजपणे लपवला जाऊ शकतो. सबमिशन बंद होण्यापूर्वी आणि न थांबण्याचा निर्णय घेण्यापूर्वी आम्हाला लीडरबोर्डमध्ये तीव्र बदल अपेक्षित होते.

अण्णांच्या व्हिडिओवरून, मी शिकलो की मॉडेलची गुणवत्ता सुधारण्यासाठी, खालील पॅरामीटर्स निवडणे चांगले आहे:

• शिक्षण_दर — डीफॉल्ट मूल्य डेटासेटच्या आकारावर आधारित मोजले जाते. शिक्षण_दर वाढवण्यासाठी पुनरावृत्तीची संख्या वाढवणे आवश्यक आहे.
• l2_leaf_reg — नियमितीकरण गुणांक, डीफॉल्ट मूल्य 3, शक्यतो 2 ते 30 निवडा. मूल्य कमी केल्याने ओव्हरफिटमध्ये वाढ होते.
• बॅगिंग_तापमान - नमुन्यातील वस्तूंच्या वजनामध्ये यादृच्छिकीकरण जोडते. डीफॉल्ट मूल्य 1 आहे, जेथे घातांकीय वितरणातून वजने काढली जातात. मूल्य कमी केल्याने ओव्हरफिटमध्ये वाढ होते.
• यादृच्छिक_शक्ती — विशिष्ट पुनरावृत्तीवर विभाजनांच्या निवडीवर परिणाम करते. यादृच्छिक_शक्ती जितकी जास्त असेल तितकी कमी महत्त्वाची स्प्लिट निवडण्याची शक्यता जास्त असते. प्रत्येक त्यानंतरच्या पुनरावृत्तीवर, यादृच्छिकता कमी होते. मूल्य कमी केल्याने ओव्हरफिटमध्ये वाढ होते.

इतर पॅरामीटर्सचा अंतिम निकालावर खूपच लहान प्रभाव पडतो, म्हणून मी त्यांना निवडण्याचा प्रयत्न केला नाही. ctr_complexity=1 सह माझ्या GPU डेटासेटवर प्रशिक्षणाच्या एका पुनरावृत्तीला 20 मिनिटे लागली आणि कमी केलेल्या डेटासेटवरील निवडलेले पॅरामीटर्स पूर्ण डेटासेटवरील इष्टतम पॅरामीटर्सपेक्षा थोडे वेगळे होते. शेवटी, मी 30% डेटावर सुमारे 10 पुनरावृत्ती केली आणि नंतर सर्व डेटावर सुमारे 10 पुनरावृत्ती केली. हे असे काहीतरी बाहेर आले:

• शिक्षण_दर मी डीफॉल्ट मधून 40% वाढलो;
• l2_leaf_reg तेच सोडले;
• बॅगिंग_तापमान и यादृच्छिक_शक्ती 0,8 पर्यंत कमी केले.

आम्ही असा निष्कर्ष काढू शकतो की मॉडेल डीफॉल्ट पॅरामीटर्ससह अधोरेखित होते.

जेव्हा मी लीडरबोर्डवर निकाल पाहिला तेव्हा मला खूप आश्चर्य वाटले:

मॉडेल	मॉडेल 1	मॉडेल 2	मॉडेल 3	जोडणी
ट्यूनिंगशिवाय	0.7403	0.7404	0.7404	0.7407
ट्यूनिंगसह	0.7406	0.7405	0.7406	0.7408

मी स्वत: साठी असा निष्कर्ष काढला आहे की जर मॉडेलचा द्रुत अनुप्रयोग आवश्यक नसेल, तर नॉन-ऑप्टिमाइझ केलेले पॅरामीटर्स वापरून अनेक मॉडेल्सच्या जोडणीसह पॅरामीटर्सची निवड बदलणे चांगले आहे.

सेर्गे डेटासेटचा आकार GPU वर चालवण्यासाठी अनुकूल करत होता. डेटाचा काही भाग कापून टाकणे हा सर्वात सोपा पर्याय आहे, परंतु हे अनेक प्रकारे केले जाऊ शकते:

• डेटासेट मेमरीमध्ये बसू लागेपर्यंत सर्वात जुना डेटा (फेब्रुवारीच्या सुरुवातीस) हळूहळू काढून टाका;
• सर्वात कमी महत्त्व असलेली वैशिष्ट्ये काढा;
• वापरकर्ता आयडी काढून टाका ज्यासाठी फक्त एकच एंट्री आहे;
• फक्त चाचणीमध्ये असलेले userIds सोडा.

आणि शेवटी, सर्व पर्यायांमधून एक जोडणी बनवा.

शेवटची जोडणी

शेवटच्या दिवशी संध्याकाळी उशिरापर्यंत, आम्ही आमच्या मॉडेल्सचा एक समूह तयार केला होता ज्याने 0,742 उत्पन्न दिले. रात्रभर मी माझे मॉडेल ctr_complexity=2 सह लॉन्च केले आणि ३० मिनिटांऐवजी ते ५ तास प्रशिक्षित झाले. फक्त पहाटे 30 वाजता ते मोजले गेले आणि मी शेवटचे एकत्र केले, ज्याने सार्वजनिक लीडरबोर्डवर 5 दिले.

समस्येचे निराकरण करण्याच्या वेगवेगळ्या पध्दतींमुळे, आमचे अंदाज मजबूतपणे परस्परसंबंधित नव्हते, ज्यामुळे एकत्रिकरणात चांगली वाढ झाली. चांगली जोडणी मिळविण्यासाठी, कच्च्या मॉडेलचा अंदाज वापरणे चांगले आहे (prediction_type='RawFormulaVal') आणि स्केल_pos_weight=neg_count/pos_count सेट करा.

वेबसाइटवर आपण पाहू शकता खाजगी लीडरबोर्डवर अंतिम परिणाम.

इतर उपाय

अनेक संघांनी शिफारस प्रणाली अल्गोरिदमच्या नियमांचे पालन केले. मी, या क्षेत्रातील तज्ञ नसल्यामुळे, त्यांचे मूल्यांकन करू शकत नाही, परंतु मला 2 मनोरंजक उपाय आठवतात.

• निकोले अनोखिनचे समाधान. निकोले, Mail.ru चा कर्मचारी असल्याने, बक्षिसेसाठी अर्ज केला नाही, म्हणून त्याचे ध्येय जास्तीत जास्त गती प्राप्त करणे नव्हते, परंतु सहज स्केलेबल समाधान प्राप्त करणे हे होते.
• ज्युरी पुरस्कार विजेत्या संघाचा निर्णय यावर आधारित हा लेख फेसबुकवरून, मॅन्युअल कार्याशिवाय खूप चांगल्या प्रतिमा क्लस्टरिंगसाठी अनुमती आहे.

निष्कर्ष

माझ्या आठवणीत सर्वात जास्त काय अडकले:

• डेटामध्ये स्पष्ट वैशिष्ट्ये असल्यास आणि लक्ष्य एन्कोडिंग योग्यरित्या कसे करायचे हे आपल्याला माहित असल्यास, कॅटबूस्ट वापरणे अद्याप चांगले आहे.
• तुम्ही स्पर्धेत भाग घेत असाल, तर तुम्ही लर्निंग_रेट आणि पुनरावृत्ती व्यतिरिक्त इतर पॅरामीटर्स निवडण्यात वेळ वाया घालवू नये. वेगवान उपाय म्हणजे अनेक मॉडेल्सची जोडणी करणे.
• GPU वर बूस्टिंग शिकू शकतात. कॅटबूस्ट GPU वर खूप लवकर शिकू शकते, परंतु ते खूप मेमरी खाऊन टाकते.
• कल्पनांच्या विकास आणि चाचणी दरम्यान, लहान rsm~=0.2 (केवळ CPU) आणि ctr_complexity=1 सेट करणे चांगले आहे.
• इतर संघांच्या विपरीत, आमच्या मॉडेल्सच्या जोडणीने मोठी वाढ केली. आम्ही फक्त विचारांची देवाणघेवाण केली आणि वेगवेगळ्या भाषांमध्ये लिहिले. डेटा विभाजित करण्याचा आमचा दृष्टीकोन वेगळा होता आणि मला वाटते, प्रत्येकाचे स्वतःचे बग होते.
• वर्गीकरण ऑप्टिमायझेशनपेक्षा रँकिंग ऑप्टिमायझेशन वाईट का केले हे स्पष्ट नाही.
• मला मजकुरांसोबत काम करण्याचा अनुभव आणि शिफारस प्रणाली कशी बनवल्या जातात हे समजले.

मिळालेल्या भावना, ज्ञान आणि पारितोषिकांसाठी आयोजकांचे आभार.

स्त्रोत: www.habr.com