فيبروري-مارچ 2019 ۾، هڪ مقابلو منعقد ڪيو ويو سماجي نيٽ ورڪ فيڊ جي درجه بندي ڪرڻ لاء جنهن ۾ اسان جي ٽيم پهرين جڳهه ورتي. آرٽيڪل ۾ آئون مقابلي جي تنظيم بابت ڳالهائيندس، طريقن جي اسان ڪوشش ڪئي، ۽ وڏي ڊيٽا تي ٽريننگ لاء catboost سيٽنگون.
SNA Hackathon
هي ٽيون ڀيرو آهي ته هن نالي سان هيڪاٿون منعقد ڪيو ويو آهي. اهو منظم ڪيو ويو آهي سماجي نيٽ ورڪ ok.ru، ترتيب سان، ڪم ۽ ڊيٽا سڌو سنئون هن سماجي نيٽ ورڪ سان لاڳاپيل آهن.
SNA (سماجي نيٽ ورڪ جو تجزيو) هن معاملي ۾ وڌيڪ صحيح طور تي سمجھيو ويو آهي هڪ سماجي گراف جي تجزيي جي طور تي نه، بلڪه هڪ سماجي نيٽ ورڪ جي تجزيي جي طور تي.
- 2014 ۾، ڪم اهو هو ته هڪ پوسٽ کي پسند ڪرڻ جو تعداد پيش ڪيو ويندو.
- 2016 ۾ - VVZ ڪم (شايد توهان واقف آهيو)، سماجي گراف جي تجزيي جي ويجهو.
- 2019 ۾، صارف جي فيڊ جي درجه بندي انهي امڪان جي بنياد تي ته صارف پوسٽ پسند ڪندو.
مان 2014 جي باري ۾ نٿو چئي سگهان، پر 2016 ۽ 2019 ۾، ڊيٽا جي تجزيي جي صلاحيتن کان علاوه، وڏي ڊيٽا سان ڪم ڪرڻ جي صلاحيتن جي پڻ ضرورت هئي. مان سمجهان ٿو ته اهو مشين جي سکيا ۽ وڏي ڊيٽا پروسيسنگ مسئلن جو ميلاپ هو جنهن مون کي انهن مقابلن ڏانهن راغب ڪيو، ۽ انهن علائقن ۾ منهنجي تجربي منهنجي مدد ڪئي.
mlbootcamp
2019 ۾، مقابلو پليٽ فارم تي منظم ڪيو ويو .
مقابلو آن لائن 7 فيبروري تي شروع ٿيو ۽ 3 ڪمن تي مشتمل ھو. ڪو به ماڻهو سائيٽ تي رجسٽر ڪري سگهي ٿو، ڊائون لوڊ ۽ ڪجھ ڪلاڪن لاءِ پنھنجي ڪار لوڊ ڪريو. 15 مارچ تي آن لائن اسٽيج جي پڄاڻي تي، هر شو جمپنگ ايونٽ جي ٽاپ 15 کي آف لائن اسٽيج لاءِ Mail.ru آفيس ۾ مدعو ڪيو ويو، جيڪو 30 مارچ کان 1 اپريل تائين ٿيو.
مقصد
ماخذ ڊيٽا صارف IDs (userId) ۽ پوسٽ IDs (objectId) مهيا ڪري ٿو. جيڪڏهن صارف هڪ پوسٽ ڏيکاريو ويو، پوء ڊيٽا ۾ هڪ لائن شامل آهي userId، ObjectId، صارف جي رد عمل تي هن پوسٽ (راءِ) ۽ مختلف خاصيتن جو هڪ سيٽ يا تصويرن ۽ متن جي لنڪ.
| يوزر آئي ڊي | اعتراض جي سڃاڻپ | مالڪ جي سڃاڻپ | موٽ | تصويرون |
|---|---|---|---|---|
| 3555 | 22 | 5677 | [پسند ڪيو، ڪلڪ ڪيو] | [hash1] |
| 12842 | 55 | 32144 | [ناپسند] | [hash2,hash3] |
| 13145 | 35 | 5677 | [ڪلڪ ڪيو، شيئر ڪيو] | [hash2] |
ٽيسٽ ڊيٽا سيٽ ۾ ساڳي جوڙجڪ شامل آهي، پر موٽ واري فيلڊ غائب آهي. ڪم اهو آهي ته راء جي ميدان ۾ 'پسند' ردعمل جي موجودگي جي اڳڪٿي ڪرڻ.
جمع ڪرائڻ واري فائل کي ھيٺ ڏنل ڍانچي آھي:
| يوزر آئي ڊي | ترتيب ڏنل فهرست[ObjectId] |
|---|---|
| 123 | 78,13,54,22 |
| 128 | 35,61,55 |
| 131 | 35,68,129,11 |
ميٽرڪ آهي اوسط ROC AUC صارفين لاءِ.
ڊيٽا جي وڌيڪ تفصيلي وضاحت تي ڳولهي سگهجي ٿو. توھان پڻ ڊائون لوڊ ڪري سگھوٿا اتي ڊيٽا، بشمول ٽيسٽ ۽ تصويرون.
آن لائين اسٽيج
آن لائين اسٽيج تي، ڪم کي 3 حصن ۾ ورهايو ويو
- - تصويرون ۽ نصوص کان سواء سڀ خاصيتون شامل آهن؛
- - صرف تصويرن بابت معلومات شامل آهي؛
- - صرف متن جي باري ۾ معلومات شامل آهي.
آف لائن اسٽيج
آف لائن اسٽيج تي، ڊيٽا سڀني خصوصيتن ۾ شامل هئي، جڏهن ته متن ۽ تصويرون گهٽ هيون. ڊيٽا سيٽ ۾ 1,5 ڀيرا وڌيڪ قطارون هيون، جن مان اڳ ۾ ئي تمام گهڻيون هيون.
مسئلي جو حل
جيئن ته مان ڪم تي CV ڪندو آهيان، مون هن مقابلي ۾ ”تصويرون“ ٽاسڪ سان پنهنجو سفر شروع ڪيو. ڊيٽا جيڪا مهيا ڪئي وئي هئي userId، ObjectId، مالڪ آئي ڊي (جنهن ۾ پوسٽ شايع ڪئي وئي هئي)، پوسٽ ٺاهڻ ۽ ڊسپلي ڪرڻ لاء ٽائيم اسٽيمپ، ۽ يقينا، هن پوسٽ لاء تصوير.
ٽائم اسٽيمپ جي بنياد تي ڪيترن ئي خاصيتن کي پيدا ڪرڻ کان پوء، ايندڙ خيال اهو هو ته نيورون جي آخري پرت کي تصويري نيٽ تي اڳ ۾ تربيت ڏني وڃي ۽ انهن ايمبيڊنگ کي وڌائڻ لاء موڪليو.
نتيجا متاثر ڪندڙ نه هئا. Imagenet نيورون مان ايمبيڊنگس غير لاڳاپيل آهن، مون سوچيو، مون کي پنهنجو پاڻ کي آٽو اينڪوڊر ٺاهڻ جي ضرورت آهي.
اهو گهڻو وقت ورتو ۽ نتيجو بهتر نه ٿيو.
خاصيت جي نسل
تصويرن سان ڪم ڪرڻ تمام گهڻو وقت وٺندو آهي، تنهنڪري مون ڪجهه آسان ڪرڻ جو فيصلو ڪيو.
جئين توهان فوري طور تي ڏسي سگهو ٿا، ڊيٽا سيٽ ۾ ڪيترائي خاص خاصيتون آهن، ۽ تمام گهڻو پريشان نه ڪرڻ لاء، مون صرف ورتو catboost. حل شاندار هو، بغير ڪنهن سيٽنگ جي مون کي فوري طور تي ليڊر بورڊ جي پهرين لائن تي پهچي ويو.
هتي ڪافي ڊيٽا آهي ۽ اها پارڪ جي شڪل ۾ رکيل آهي، تنهنڪري ٻه ڀيرا سوچڻ کان سواء، مون اسڪالا ورتو ۽ هر شيء کي چمڪ ۾ لکڻ شروع ڪيو.
سڀ کان آسان خاصيتون جيڪي تصوير ايمبيڊنگ کان وڌيڪ ترقي ڏنيون آهن:
- ڊيٽا ۾ ڪيترا ڀيرا ObjectId، userId ۽ ownerId ظاهر ٿيا (مقبوليت سان لاڳاپيل هجڻ گهرجي)؛
- ڪيتريون پوسٽون يوزر آءِ ڊي مالڪ آئي ڊي مان ڏٺيون آهن (گروپ ۾ استعمال ڪندڙ جي دلچسپي سان لاڳاپيل هجڻ گهرجي)؛
- ڪيترين ئي منفرد يوزر آئي ڊيز مالڪ آئي ڊي مان پوسٽون ڏٺيون آهن (گروپ جي سامعين جي سائيز کي ظاهر ڪري ٿو).
ٽائم اسٽيمپس مان اهو حاصل ڪرڻ ممڪن هو ته ڏينهن جو وقت جنهن تي صارف فيڊ ڏٺو (صبح/دوپڻ/شام/رات). انهن قسمن کي گڏ ڪندي، توهان خاصيتون ٺاهي سگهو ٿا:
- ڪيترا ڀيرا يوزر آئي ڊي شام ۾ لاگ ان ٿيو؛
- ڪهڙي وقت تي هي پوسٽ اڪثر ڏيکاري ويندي آهي (objectId) وغيره.
اهو سڀ ڪجهه تدريجي طور تي ميٽرڪ بهتر ڪيو. پر ٽريننگ ڊيٽا سيٽ جي سائيز 20M رڪارڊ بابت آهي، تنهنڪري خاصيتون شامل ڪرڻ ٽريننگ کي تمام گهڻو سست ڪيو.
مون ڊيٽا کي استعمال ڪرڻ لاء منهنجي طريقي تي غور ڪيو آهي. جيتوڻيڪ ڊيٽا وقت تي منحصر آهي، مون کي "مستقبل ۾" ڪو به واضح معلومات ليڪ نه ڏٺو، پر ان جي باوجود، صرف ان صورت ۾، مون ان کي هن طرح ٽوڙيو:
اسان کي مهيا ڪيل تربيتي سيٽ (فيبروري ۽ مارچ جي 2 هفتا) کي 2 حصن ۾ ورهايو ويو.
ماڊل آخري اين ڏينهن کان ڊيٽا تي تربيت ڪئي وئي. مٿي بيان ڪيل مجموعا سڀني ڊيٽا تي ٺهيل هئا، بشمول ٽيسٽ. ساڳئي وقت، ڊيٽا ظاهر ٿي چڪو آهي جنهن تي اهو ممڪن آهي ته ٽارگيٽ متغير جي مختلف انڪوڊنگ ٺاهڻ. سادي طريقي سان ڪوڊ ٻيهر استعمال ڪرڻ آهي جيڪو اڳ ۾ ئي نئين خاصيتون ٺاهي رهيو آهي، ۽ صرف ان کي ڊيٽا کي فيڊ ڪيو جنهن تي اهو تربيت نه ڪيو ويندو ۽ ٽارگيٽ = 1.
ان ڪري، اسان وٽ ساڳيون خاصيتون آهن:
- ڪيترا ڀيرا يوزر آئي ڊي گروپ مالڪ جي آئي ڊي ۾ پوسٽ ڏٺو آهي؛
- ڪيترا ڀيرا يوزر آئي ڊي گروپ مالڪ جي پوسٽ کي پسند ڪيو؛
- پوسٽن جو سيڪڙو جيڪي يوزر آئي ڊي کي مالڪ مان پسند ڪيو.
اهو آهي، اهو نڪتو مطلب ٽارگيٽ انڪوڊنگ ڊيٽا سيٽ جي حصي تي مختلف مجموعن لاءِ ڪيٽيگريڪل فيچرز. اصولي طور تي، ڪيٽ بوسٽ پڻ ٽارگيٽ انڪوڊنگ ٺاهي ٿو ۽ ان نقطي نظر کان ڪو به فائدو نه آهي، پر، مثال طور، اهو ممڪن ٿيو ته منفرد استعمال ڪندڙن جو تعداد ڳڻڻ جيڪي هن گروپ ۾ پوسٽون پسند ڪن ٿا. ساڳئي وقت، بنيادي مقصد حاصل ڪيو ويو - منهنجو ڊيٽا سيٽ ڪيترائي ڀيرا گهٽجي ويو، ۽ اهو ممڪن هو ته خاصيتون پيدا ڪرڻ جاري رکڻ.
جڏهن ته catboost انڪوڊنگ ٺاهي سگھي ٿو صرف پسند ڪيل رد عمل جي بنياد تي، موٽ ۾ ٻيا رد عمل آهن: ٻيهر شيئر، ناپسند، ناپسند، ڪلڪ، نظرانداز، انڪوڊنگس جن لاءِ دستي طور ڪري سگهجي ٿو. مون سڀني قسمن جي مجموعن کي ٻيهر ڳڻيو ۽ گهٽ اهميت سان خصوصيتن کي ختم ڪيو ته جيئن ڊيٽا سيٽ ۾ واڌ نه ٿئي.
ان وقت تائين مان وڏي مارجن سان پهرين نمبر تي هوس. صرف هڪ شيء جيڪا مونجهارو هئي اها تصوير ايمبيڊنگ تقريبن ڪا به ترقي نه ڏيکاري. خيال آيو ته سڀڪنھن شيء کي catboost ڏي. اسان Kmeans تصويرن کي ڪلستر ڪريون ٿا ۽ هڪ نئين درجه بندي خصوصيت اميج ڪيٽ حاصل ڪريو.
ھتي ڪجھ ڪلاس آھن دستي فلٽرنگ کان پوءِ ۽ ڪلسٽرن کي ملائڻ کان پوءِ KMeans مان حاصل ڪيل.
ImageCat جي بنياد تي اسان پيدا ڪريون ٿا:
- نئين درجه بندي خاصيتون:
- ڪھڙي تصوير ڪيٽ اڪثر ڪري يوزر آئي ڊي جي ذريعي ڏٺو ويو؛
- ڪھڙي تصوير ڪيٽ اڪثر ڪري مالڪ جي سڃاڻپ ڏيکاري ٿي؛
- UserId پاران ڪھڙي تصوير ڪيٽ کي اڪثر پسند ڪيو ويو؛
- مختلف شماريات:
- صارف آئي ڊي تي ڪيتريون ئي منفرد تصوير ڪيٽ نظر آئي؛
- اٽڪل 15 ساڳي خاصيتون ۽ ٽارگيٽ انڪوڊنگ جيئن مٿي بيان ڪيو ويو آهي.
لکتون
تصويري مقابلي جا نتيجا مون لاءِ موزون ٿيا ۽ مون فيصلو ڪيو ته متن تي پنهنجو هٿ آزمايو. مون اڳ ۾ نصوص سان گهڻو ڪم نه ڪيو آهي ۽، بيوقوفيء سان، مون ڏينهن کي قتل ڪيو tf-idf ۽ svd. پوءِ مون ڏٺو بيس لائين doc2vec سان، جيڪو ائين ڪري ٿو جيڪو مون کي گهربل آهي. doc2vec پيٽرول کي ٿورڙي ترتيب ڏيڻ سان، مون کي ٽيڪسٽ ايمبيڊنگ حاصل ڪيو.
۽ پوءِ مون تصويرن لاءِ صرف ڪوڊ ٻيهر استعمال ڪيو، جنهن ۾ مون تصوير جي ايمبيڊنگ کي ٽيڪسٽ ايمبيڊنگس سان تبديل ڪيو. نتيجي طور، مون ٽيڪسٽ مقابلي ۾ 2nd جاء ورتي.
تعاون وارو نظام
اتي ھڪڙو مقابلو رهجي ويو ھو ته مون اڃا تائين "پوڪ" نه ڪيو ھو لٺ سان، ۽ ليڊر بورڊ تي AUC پاران فيصلو ڪندي، ھن خاص مقابلي جي نتيجن کي آف لائن اسٽيج تي تمام وڏو اثر ٿيڻ گھرجي.
مون اهي سڀئي خاصيتون ورتيون جيڪي ماخذ ڊيٽا ۾ هيون، چونڊيل ڪيٽيگريڪل ۽ ساڳيا مجموعا ڳڻيا جيئن تصويرن لاءِ، سواءِ انهن خاصيتن جي جيڪي پاڻ تصويرن تي ٻڌل آهن. بس هن کي ڪيٽ بوسٽ ۾ رکڻ مون کي ٻئي نمبر تي پهچايو.
catboost جي اصلاح جا پھريون قدم
هڪ پهرين ۽ ٻه سيڪنڊ مون کي خوش ڪيو، پر اتي هڪ سمجھ هئي ته مون ڪجهه خاص نه ڪيو آهي، جنهن جو مطلب آهي ته مان پوزيشن جي نقصان جي اميد ڪري سگهان ٿو.
مقابلي جو ڪم صارف جي اندر پوسٽن جي درجه بندي ڪرڻ آهي، ۽ اهو سڀ وقت آئون درجه بندي جي مسئلي کي حل ڪري رهيو آهيان، اهو آهي، غلط ميٽرڪ کي بهتر ڪرڻ.
مان توهان کي هڪ سادي مثال ڏيان ٿو:
| يوزر آئي ڊي | اعتراض جي سڃاڻپ | اڳڪٿي | زميني حقيقت |
|---|---|---|---|
| 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 |
اچو ته هڪ ننڍڙي ترتيب ڏيو
| يوزر آئي ڊي | اعتراض جي سڃاڻپ | اڳڪٿي | زميني حقيقت |
|---|---|---|---|
| 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 ۾ تبديل ڪيو، جيڪو، ڪيٽ بوسٽ دستاويزن طرفان فيصلو ڪندي، تيزيء سان تبديل ڪري ٿو. آخر ۾، مون کي ساڳيو نتيجو مليو جڏهن ڪلاس جي تربيت لاء، پر انهن ٻن ماڊلن جي ensembles هڪ سٺو واڌارو ڏنو، جنهن مون کي سڀني ٽن مقابلن ۾ پهرين جاء تي آندو.
5 منٽ اڳ "Collaborative Systems" مقابلي جي آن لائن اسٽيج جي بند ٿيڻ کان، سرجي شالنوف مون کي ٻئي نمبر تي منتقل ڪيو. اسان گڏجي اڳتي وڌڻ جو رستو اختيار ڪيو.
آف لائن اسٽيج جي تياري
اسان کي آن لائن اسٽيج ۾ RTX 2080 TI ويڊيو ڪارڊ سان فتح جي ضمانت ڏني وئي، پر 300 روبل جو بنيادي انعام ۽، گهڻو ڪري، حتمي پهرين جڳهه اسان کي انهن 000 هفتن لاء ڪم ڪرڻ تي مجبور ڪيو.
جيئن اهو نڪتو، سرجي پڻ استعمال ڪيو catboost. اسان خيالن ۽ خاصيتن کي مٽايو، ۽ مون بابت سکيو جنهن ۾ منهنجي ڪيترن ئي سوالن جا جواب هئا، ۽ اهي به جيڪي مون وٽ ان وقت تائين نه هئا.
رپورٽ کي ڏسڻ سان مون کي ان خيال جي طرف راغب ڪيو ويو ته اسان کي سڀني پيرا ميٽرز کي ڊفالٽ قيمت ڏانهن موٽڻ جي ضرورت آهي، ۽ سيٽنگون تمام احتياط سان ڪريو ۽ صرف خاصيتن جي هڪ سيٽ کي درست ڪرڻ کان پوء. ھاڻي ھڪڙي ٽريننگ تقريبا 15 ڪلاڪ ورتي، پر ھڪڙي نموني ھڪڙي رفتار حاصل ڪرڻ ۾ مدد ڪئي جيڪا درجه بندي سان گڏ حاصل ڪئي وئي آھي.
خاصيت جي نسل
تعاون واري نظام جي مقابلي ۾، خاصيتن جي وڏي تعداد جو اندازو لڳايو ويو آھي ماڊل لاءِ اھم. مثال طور، auditweights_spark_svd - سڀ کان اهم نشاني، پر ان جي معني بابت ڪا ڄاڻ ناهي. مون سوچيو ته اهم خصوصيتن جي بنياد تي مختلف مجموعن کي ڳڻڻ مناسب ٿيندو. مثال طور، اوسط auditweights_spark_svd صارف طرفان، گروپ طرفان، اعتراض طرفان. ساڳيو حساب ڪري سگهجي ٿو ڊيٽا استعمال ڪندي جنهن تي ڪابه تربيت نه ڪئي وئي آهي ۽ ٽارگيٽ = 1، اهو آهي، اوسط auditweights_spark_svd صارف طرفان شين جي طرفان هن کي پسند ڪيو. ان کان علاوه اهم نشانيون auditweights_spark_svd، ڪيترائي هئا. هتي انهن مان ڪجهه آهن:
- auditweightsCtrGender
- auditweightsCtrHigh
- userOwnerCounterCreateLikes
مثال طور، اوسط auditweightsCtrGender يوزر آئي ڊي جي مطابق اهو هڪ اهم خصوصيت ثابت ٿيو، صرف اوسط قدر وانگر userOwnerCounterCreateLikes userId+ownerId ذريعي. اهو توهان کي اڳ ۾ ئي سوچڻ گهرجي ته توهان کي فيلڊ جي معني کي سمجهڻ جي ضرورت آهي.
پڻ اهم خاصيتون هيون auditweightsLikesCount и آڊٽ وزن ڏيکاريو شمار. هڪ ٻئي کي ورهائڻ سان، اڃا به وڌيڪ اهم خصوصيت حاصل ڪئي وئي هئي.
ڊيٽا ليڪ
مقابلي ۽ پيداوار ماڊلنگ تمام مختلف ڪم آهن. ڊيٽا تيار ڪرڻ وقت، سڀني تفصيلن کي حساب ۾ رکڻ ۽ ٽيسٽ ۾ ٽارگيٽ متغير بابت ڪجھ غير معمولي معلومات نه ڏيڻ تمام ڏکيو آهي. جيڪڏهن اسان هڪ پيداوار حل ٺاهي رهيا آهيون، اسين ڪوشش ڪنداسين ته ڊيٽا ليڪ استعمال ڪرڻ کان بچڻ جي ڪوشش ڪنداسين جڏهن ماڊل ٽريننگ ڪندا. پر جيڪڏهن اسان مقابلو کٽڻ چاهيون ٿا ته پوءِ ڊيٽا ليڪ بهترين خاصيتون آهن.
ڊيٽا کي اڀياس ڪرڻ کان پوء، توهان ڏسي سگهو ٿا ته ObjectId قدرن جي مطابق auditweightsLikesCount и آڊٽ وزن ڏيکاريو شمار تبديلي، جنهن جو مطلب آهي ته انهن خاصيتن جي وڌ ۾ وڌ قدرن جو تناسب پوسٽ ڪنورشن کي ڊسپلي جي وقت جي نسبت کان گهڻو بهتر ظاهر ڪندو.
اسان کي پهريون ليک مليو آهي auditweightsLikesCountMax/auditweightsShowsCountMax.
پر ڇا جيڪڏهن اسان ڊيٽا کي وڌيڪ ويجهي نظر سان ڏسون ٿا؟ اچو ته ترتيب ڏيو شو جي تاريخ ۽ حاصل ڪريو:
| اعتراض جي سڃاڻپ | يوزر آئي ڊي | آڊٽ وزن ڏيکاريو شمار | auditweightsLikesCount | ھدف (پسند آھي) |
|---|---|---|---|---|
| 1 | 1 | 12 | 3 | شايد نه |
| 1 | 2 | 15 | 3 | شايد ها |
| 1 | 3 | 16 | 4 |
حيرت ان وقت ٿي جڏهن مون کي پهريون اهڙو مثال مليو ۽ اهو معلوم ٿيو ته منهنجي اڳڪٿي سچ نه ٿي. پر، انهي حقيقت کي نظر ۾ رکندي ته اعتراض جي اندر انهن خاصيتن جي وڌ ۾ وڌ قدر وڌائي، اسان سست نه هئاسين ۽ ڳولڻ جو فيصلو ڪيو. auditweightsShowsCountNext и 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، ڪٿي به پيدا نه ٿيو نتيجي جي ويجهو جيڪو LogLoss ڪيو (0,745 بمقابله 0,725). QueryCrossEntropy لاءِ اڃا اميد هئي، جيڪا شروع نه ٿي سگهي.
آف لائن اسٽيج
آف لائن اسٽيج تي، ڊيٽا جو ڍانچو ساڳيو رهيو، پر ننڍيون تبديليون هيون:
- سڃاڻپ ڪندڙ userId، ObjectId، ownerId ٻيهر ترتيب ڏني وئي؛
- ڪيترائي نشان ختم ڪيا ويا ۽ ڪيترائي نالا تبديل ڪيا ويا.
- ڊيٽا تقريبن 1,5 ڀيرا وڌي وئي آهي.
فهرستن جي مشڪلاتن کان علاوه، ھڪڙو وڏو پلس ھو: ٽيم کي RTX 2080TI سان گڏ ھڪڙو وڏو سرور مختص ڪيو ويو. مون هڪ ڊگهي وقت تائين htop مزو ڪيو آهي.
اتي صرف هڪ خيال هو - صرف ان کي ٻيهر پيدا ڪرڻ لاء جيڪو اڳ ۾ ئي موجود آهي. سرور تي ماحول کي ترتيب ڏيڻ ۾ ڪجھ ڪلاڪ خرچ ڪرڻ کان پوء، اسان آهستي آهستي تصديق ڪرڻ شروع ڪيو ته نتيجا ٻيهر پيدا ڪرڻ وارا هئا. بنيادي مسئلو جيڪو اسان کي منهن ڏئي رهيا آهيون اهو آهي ڊيٽا جي مقدار ۾ اضافو. اسان فيصلو ڪيو ته ٿورڙو لوڊ گھٽايو ۽ سيٽ بوسٽ پيٽرول سيٽ ڪيو ctr_complexity=1. اها رفتار ٿوري گھٽائي ٿي، پر منهنجو ماڊل ڪم ڪرڻ شروع ڪيو، نتيجو سٺو هو - 0,733. سرجي، منهنجي برعڪس، ڊيٽا کي 2 حصن ۾ نه ورهايو ۽ سڀني ڊيٽا تي تربيت ڪئي، جيتوڻيڪ اهو آن لائن اسٽيج تي بهترين نتيجا ڏنو، آف لائن اسٽيج تي ڪيتريون ئي مشڪلاتون هيون. جيڪڏهن اسان اهي سڀئي خاصيتون ورتيون جيڪي اسان پيدا ڪيون ۽ انهن کي ڪيٽ بوسٽ ۾ ڌڪڻ جي ڪوشش ڪئي، پوءِ آن لائن اسٽيج تي ڪجھ به ڪم نه ڪندو. سرجي ٽائيپ آپٽمائيزيشن ڪيو، مثال طور، فلوٽ 64 قسمن کي فلوٽ 32 ۾ تبديل ڪرڻ. توھان حاصل ڪري سگھوٿا ميموري جي اصلاح تي معلومات پنڊس ۾. نتيجي طور، سرجي سڀني ڊيٽا کي استعمال ڪندي سي پي يو تي تربيت ڪئي ۽ اٽڪل 0,735 حاصل ڪيو.
اهي نتيجا کٽڻ لاءِ ڪافي هئا، پر اسان پنهنجي سچي رفتار کي لڪايو ۽ پڪ نه ٿي سگهياسين ته ٻيون ٽيمون به ائين نه ڪري رهيون هيون.
آخري دم تائين وڙهڻ
Catboost ٽيوننگ
اسان جو حل مڪمل طور تي ٻيهر تيار ڪيو ويو، اسان ٽيڪسٽ ڊيٽا ۽ تصويرن جي خاصيتن کي شامل ڪيو، تنهنڪري باقي رهيل ڪيٽ بوسٽ پيٽرولر کي ٽيون ڪرڻ هو. سرجي سي پي يو تي ٿورڙي تعداد ۾ ٽريننگ سان ٽريننگ ڪئي، ۽ مون ھڪڙي تي تربيت ڪئي ctr_complexity=1 سان. ھڪڙو ڏينھن بچيو ھو، ۽ جيڪڏھن توھان صرف ورجائي وڌو يا ctr_complexity وڌايو، ته پوءِ صبح تائين توھان اڃا بھتر رفتار حاصل ڪري سگھوٿا ۽ سڄو ڏينھن ھلندا رھو.
آف لائن اسٽيج تي، رفتار تمام آسانيءَ سان لڪائي سگھجي ٿي صرف سائيٽ تي بهترين حل نه چونڊڻ سان. اسان آخري منٽن ۾ ليڊربورڊ ۾ سخت تبديلين جي توقع ڪئي ان کان اڳ جمع ٿيل بند ٿيڻ ۽ بند نه ڪرڻ جو فيصلو ڪيو.
انا جي وڊيو مان، مون سکيو ته ماڊل جي معيار کي بهتر ڪرڻ لاء، اهو بهتر آهي ته هيٺين معيارن کي چونڊڻ لاء:
- سکيا جي شرح - ڊفالٽ ويل ڊيٽا سيٽ جي سائيز جي بنياد تي ڳڻيو ويندو آهي. سکيا جي_ شرح کي وڌائڻ لاءِ ٻيهر ورجائڻ جي تعداد کي وڌائڻ جي ضرورت آھي.
- l2_leaf_reg — ريگيولرائيزيشن ڪوفيشيٽ، ڊفالٽ ويليو 3، ترجيحي طور تي 2 کان 30 تائين چونڊيو. قدر گھٽجڻ اوورفٽ ۾ اضافو ٿي سگھي ٿو.
- bagging_temperature - نموني ۾ شين جي وزن کي بي ترتيب ڪرڻ شامل ڪري ٿو. ڊفالٽ ويليو 1 آهي، جتي وزن ورهايل ورهاست مان ٺهيل آهن. قيمت گھٽائڻ سان اوورفٽ ۾ اضافو ٿئي ٿو.
- random_strength - هڪ مخصوص ورجائي تي تقسيم جي چونڊ کي متاثر ڪري ٿو. random_strength جيتري وڌيڪ هوندي، اوترو ئي اوترو گهٽ اهميت واري تقسيم جو موقعو چونڊيو ويندو. هر ايندڙ ورهاڱي تي، بي ترتيبي گھٽجي ٿي. قيمت گھٽائڻ سان اوورفٽ ۾ اضافو ٿئي ٿو.
ٻيا پيٽرولر حتمي نتيجن تي تمام ننڍا اثر آهن، تنهنڪري مون انهن کي چونڊڻ جي ڪوشش نه ڪئي. ctr_complexity=1 سان منهنجي GPU ڊيٽا سيٽ تي ٽريننگ جو هڪ ورجائي 20 منٽ کنيا، ۽ گهٽيل ڊيٽا سيٽ تي چونڊيل پيرا ميٽر مڪمل ڊيٽا سيٽ تي بهتر کان ٿورو مختلف هئا. آخر ۾، مون ڊيٽا جي 30 سيڪڙو تي اٽڪل 10 ورجاءُ ڪيا، ۽ پوءِ سڀني ڊيٽا تي اٽڪل 10 وڌيڪ ورجاءُ ڪيا. اهو ڪجهه هن طرح ظاهر ٿيو:
- سکيا جي شرح مون ڊفالٽ مان 40٪ وڌايو؛
- l2_leaf_reg ان کي ساڳيو ڇڏي؛
- bagging_temperature и random_strength 0,8 تائين گھٽجي ويو.
اسان اهو نتيجو ڪري سگهون ٿا ته ماڊل ڊفالٽ پيٽرولر سان گڏ تربيت ڪئي وئي هئي.
مون کي ڏاڍي حيرت ٿي جڏهن مون ليڊر بورڊ تي نتيجو ڏٺو:
| ماڊل | ماڊل 1 | ماڊل 2 | ماڊل 3 | گڏ ڪرڻ |
|---|---|---|---|---|
| بغير ٽيوننگ | 0.7403 | 0.7404 | 0.7404 | 0.7407 |
| ٽيوننگ سان | 0.7406 | 0.7405 | 0.7406 | 0.7408 |
مون پنهنجي لاء اهو نتيجو ڪيو ته جيڪڏهن ماڊل جي تڪڙي ايپليڪيشن جي ضرورت نه آهي، پوء اهو بهتر آهي ته پيٽرولر جي چونڊ کي تبديل ڪرڻ لاء ڪيترن ئي ماڊل جي هڪ جوڙي سان غير اصلاحي پيٽرولر استعمال ڪندي.
سرجي ڊيٽا سيٽ جي سائيز کي بهتر ڪري رهيو هو ان کي GPU تي هلائڻ لاءِ. سڀ کان آسان اختيار ڊيٽا جو حصو ڪٽي ڪرڻ آهي، پر اهو ڪيترن ئي طريقن سان ڪري سگهجي ٿو:
- آهستي آهستي پراڻي ڊيٽا کي هٽايو (فبروري جي شروعات) جيستائين ڊيٽا سيٽ ياداشت ۾ فٽ ٿيڻ شروع ٿئي.
- گھٽ اھميت سان خاصيتون ختم ڪريو؛
- UserIds کي هٽايو جنهن لاءِ صرف هڪ داخلا آهي؛
- صرف استعمال ڪندڙ IDs ڇڏي ڏيو جيڪي امتحان ۾ آھن.
۽ آخرڪار، سڀني اختيارن مان ھڪڙو ٺاھيو.
آخري مجموعو
آخري ڏينهن جي دير سان شام تائين، اسان اسان جي ماڊل جو هڪ جوڙيو هو جيڪو 0,742 پيدا ڪيو. رات جو مون پنهنجو ماڊل ctr_complexity=2 سان لانچ ڪيو ۽ 30 منٽن جي بدران 5 ڪلاڪن تائين تربيت ڪئي. صرف 4 تي اهو ڳڻيو ويو، ۽ مون آخري مجموعو ٺاهيو، جيڪو عوامي ليڊر بورڊ تي 0,7433 ڏنو.
مسئلي کي حل ڪرڻ جي مختلف طريقن جي ڪري، اسان جون اڳڪٿيون مضبوط طور تي لاڳاپا نه هئا، جنهن جي جوڙجڪ ۾ سٺو واڌارو ڏنو. سٺي نموني حاصل ڪرڻ لاءِ، اهو بهتر آهي ته خام ماڊل اڳڪٿيون اڳڪٿيون استعمال ڪريو (prediction_type='RawFormulaVal') ۽ اسڪيل_pos_weight=neg_count/pos_count سيٽ ڪريو.
ويب سائيٽ تي توهان ڏسي سگهو ٿا .
ٻيا حل
ڪيتريون ئي ٽيمون سفارش ڪندڙ سسٽم الگورتھم جي ڪنن جي پيروي ڪئي. مان، هن فيلڊ ۾ ماهر نه هجڻ ڪري، انهن جو اندازو نه ٿو ڪري سگهان، پر مون کي ياد آهي 2 دلچسپ حل.
- . Nikolay، Mail.ru جي ملازم هجڻ جي ڪري، انعام لاء درخواست نه ڏني هئي، تنهنڪري هن جو مقصد وڌ ۾ وڌ رفتار حاصل ڪرڻ نه هو، پر هڪ آساني سان اسپيبل حل حاصل ڪرڻ هو.
- جيوري انعام کٽڻ واري ٽيم جي فيصلي جي بنياد تي ، دستي ڪم کان سواءِ تمام سٺي تصوير ڪلسٽرنگ جي اجازت ڏني وئي.
ٿڪل
منهنجي يادگيري ۾ سڀ کان وڌيڪ ڇا آهي:
- جيڪڏهن ڊيٽا ۾ ڪيٽيگريڪل خاصيتون آهن، ۽ توهان ڄاڻو ٿا ته ٽارگيٽ انڪوڊنگ ڪيئن ڪجي صحيح طريقي سان، اهو اڃا به بهتر آهي ته ڪوشش ڪريو catboost.
- جيڪڏھن توھان ھڪڙي مقابلي ۾ حصو وٺي رھيا آھيو، توھان کي وقت ضايع نه ڪرڻ گھرجي پيراميٽر چونڊڻ کان سواءِ learning_rate ۽ iterations. هڪ تيز حل ڪيترن ئي ماڊلز جي هڪ ensemble ڪرڻ آهي.
- Boostings GPU تي سکي سگھي ٿو. Catboost GPU تي تمام جلدي سکي سگھي ٿو، پر اھو تمام گھڻو ياداشت کائيندو آھي.
- خيالن جي ترقي ۽ جانچ دوران، اهو بهتر آهي ته هڪ ننڍڙو rsm~=0.2 (صرف CPU) ۽ ctr_complexity=1 مقرر ڪيو وڃي.
- ٻين ٽيمن جي ابتڙ، اسان جي ماڊلز جي ensemble هڪ وڏو اضافو ڏنو. اسان رڳو خيالن جو تبادلو ڪيو ۽ مختلف ٻولين ۾ لکيو. اسان وٽ ڊيٽا کي ورهائڻ جو هڪ مختلف طريقو هو ۽، مان سمجهان ٿو، هر هڪ پنهنجا پنهنجا ڪيڙا هئا.
- اهو واضح ناهي ته درجه بندي جي اصلاح جي درجه بندي بهتر ڪرڻ کان وڌيڪ خراب ڪارڪردگي آهي.
- مون ڪجھ تجربو حاصل ڪيو نصوص سان ڪم ڪرڻ ۽ سمجھڻ جو طريقو سفارش ڪندڙ سسٽم ڪيئن ٺاھيو ويو آھي.
جذبن، علم ۽ انعام حاصل ڪرڻ لاء منتظمين جي مهرباني.
جو ذريعو: www.habr.com