பிப்ரவரி-மார்ச் 2019 இல், சமூக வலைப்பின்னல் ஊட்டத்தை தரவரிசைப்படுத்த ஒரு போட்டி நடத்தப்பட்டது , அதில் எங்கள் அணி முதலிடம் பெற்றது. கட்டுரையில் நான் போட்டியின் அமைப்பு, நாங்கள் முயற்சித்த முறைகள் மற்றும் பெரிய தரவுகளில் பயிற்சிக்கான கேட்பூஸ்ட் அமைப்புகள் பற்றி பேசுவேன்.
SNA ஹேக்கத்தான்
இந்தப் பெயரில் ஹேக்கத்தான் நடத்தப்படுவது இது மூன்றாவது முறையாகும். இது முறையே சமூக வலைப்பின்னல் ok.ru ஆல் ஒழுங்கமைக்கப்பட்டுள்ளது, பணி மற்றும் தரவு இந்த சமூக வலைப்பின்னலுடன் நேரடியாக தொடர்புடையது.
இந்த விஷயத்தில் SNA (சமூக வலைப்பின்னல் பகுப்பாய்வு) என்பது ஒரு சமூக வரைபடத்தின் பகுப்பாய்வாக அல்ல, மாறாக ஒரு சமூக வலைப்பின்னலின் பகுப்பாய்வாக மிகவும் சரியாக புரிந்து கொள்ளப்படுகிறது.
- 2014 ஆம் ஆண்டில், ஒரு இடுகையைப் பெறும் விருப்பங்களின் எண்ணிக்கையைக் கணிப்பது பணியாக இருந்தது.
- 2016 இல் - VVZ பணி (ஒருவேளை உங்களுக்குத் தெரிந்திருக்கலாம்), சமூக வரைபடத்தின் பகுப்பாய்விற்கு நெருக்கமானது.
- 2019 இல், பயனர் இடுகையை விரும்புவதற்கான சாத்தியக்கூறுகளின் அடிப்படையில் பயனரின் ஊட்டத்தை தரவரிசைப்படுத்துதல்.
2014 ஐப் பற்றி என்னால் சொல்ல முடியாது, ஆனால் 2016 மற்றும் 2019 இல், தரவு பகுப்பாய்வு திறன்களுக்கு கூடுதலாக, பெரிய தரவுகளுடன் பணிபுரியும் திறன்களும் தேவைப்பட்டன. மெஷின் லேர்னிங் மற்றும் பெரிய டேட்டா ப்ராசசிங் பிரச்சனைகளின் கலவையே இந்தப் போட்டிகளுக்கு என்னை ஈர்த்தது என்று நினைக்கிறேன், இந்தப் பகுதிகளில் எனது அனுபவம் எனக்கு வெற்றி பெற உதவியது.
mlbootcamp
2019 இல், போட்டி மேடையில் ஏற்பாடு செய்யப்பட்டது .
போட்டி பிப்ரவரி 7 அன்று ஆன்லைனில் தொடங்கியது மற்றும் 3 பணிகளைக் கொண்டிருந்தது. தளத்தில் யார் வேண்டுமானாலும் பதிவு செய்யலாம், பதிவிறக்கம் செய்யலாம் உங்கள் காரை சில மணிநேரங்களுக்கு ஏற்றவும். மார்ச் 15 அன்று ஆன்லைன் மேடையின் முடிவில், ஒவ்வொரு ஷோ ஜம்பிங் நிகழ்வின் முதல் 15 பேர் மார்ச் 30 முதல் ஏப்ரல் 1 வரை நடந்த ஆஃப்லைன் மேடைக்கு Mail.ru அலுவலகத்திற்கு அழைக்கப்பட்டனர்.
பணி
மூல தரவு பயனர் ஐடிகள் (பயனர் ஐடி) மற்றும் போஸ்ட் ஐடிகள் (ஆப்ஜெக்ட் ஐடி) ஆகியவற்றை வழங்குகிறது. பயனருக்கு இடுகை காட்டப்பட்டால், தரவு பயனர் ஐடி, ஆப்ஜெக்ட்ஐடி, இந்த இடுகைக்கான பயனர் எதிர்வினைகள் (கருத்து) மற்றும் பல்வேறு அம்சங்கள் அல்லது படங்கள் மற்றும் உரைகளுக்கான இணைப்புகளைக் கொண்ட ஒரு வரியைக் கொண்டிருக்கும்.
| பயனர் ஐடி | objectId | உரிமையாளர் ஐடி | கருத்து | படங்கள் |
|---|---|---|---|---|
| 3555 | 22 | 5677 | [பிடித்தேன், கிளிக் செய்தேன்] | [ஹாஷ்1] |
| 12842 | 55 | 32144 | [விரும்பவில்லை] | [hash2,hash3] |
| 13145 | 35 | 5677 | [கிளிக் செய்யப்பட்டது, பகிரப்பட்டது] | [ஹாஷ்2] |
சோதனைத் தரவுத் தொகுப்பில் இதே போன்ற அமைப்பு உள்ளது, ஆனால் பின்னூட்டப் புலம் இல்லை. பின்னூட்டப் புலத்தில் 'பிடித்த' எதிர்வினை இருப்பதைக் கணிப்பதே பணி.
சமர்ப்பிக்கும் கோப்பு பின்வரும் கட்டமைப்பைக் கொண்டுள்ளது:
| பயனர் ஐடி | வரிசைப்படுத்தப்பட்ட பட்டியல்[objectId] |
|---|---|
| 123 | 78,13,54,22 |
| 128 | 35,61,55 |
| 131 | 35,68,129,11 |
மெட்ரிக் என்பது பயனர்களுக்கான சராசரி ROC AUC ஆகும்.
தரவு பற்றிய விரிவான விளக்கத்தை இங்கே காணலாம். சோதனைகள் மற்றும் படங்கள் உட்பட தரவையும் நீங்கள் பதிவிறக்கலாம்.
ஆன்லைன் மேடை
ஆன்லைன் கட்டத்தில், பணி 3 பகுதிகளாக பிரிக்கப்பட்டது
- - படங்கள் மற்றும் உரைகள் தவிர அனைத்து அம்சங்களையும் உள்ளடக்கியது;
- - படங்களைப் பற்றிய தகவல்களை மட்டுமே உள்ளடக்கியது;
- - உரைகள் பற்றிய தகவல்களை மட்டுமே உள்ளடக்கியது.
ஆஃப்லைன் நிலை
ஆஃப்லைன் கட்டத்தில், தரவு அனைத்து அம்சங்களையும் உள்ளடக்கியது, உரைகள் மற்றும் படங்கள் குறைவாகவே இருந்தன. தரவுத்தொகுப்பில் 1,5 மடங்கு அதிகமான வரிசைகள் இருந்தன, அவற்றில் ஏற்கனவே நிறைய இருந்தன.
சிக்கல் தீர்க்கும்
நான் பணியிடத்தில் சிவி செய்வதால், இந்தப் போட்டியில் எனது பயணத்தை “படங்கள்” பணியுடன் தொடங்கினேன். பயனர் ஐடி, ஆப்ஜெக்ட் ஐடி, ஓனர்ஐடி (இடுகை வெளியிடப்பட்ட குழு), இடுகையை உருவாக்கி காண்பிப்பதற்கான நேர முத்திரைகள் மற்றும் இந்த இடுகைக்கான படம் ஆகியவை வழங்கப்பட்ட தரவு.
நேர முத்திரைகளின் அடிப்படையில் பல அம்சங்களை உருவாக்கிய பிறகு, அடுத்த யோசனையானது இமேஜ்நெட்டில் முன் பயிற்சி பெற்ற நியூரானின் இறுதி அடுக்கை எடுத்து, இந்த உட்பொதிவுகளை ஊக்குவிப்பதற்கு அனுப்புவதாகும்.
முடிவுகள் சுவாரஸ்யமாக இல்லை. இமேஜ்நெட் நியூரானில் இருந்து உட்பொதித்தல்கள் பொருத்தமற்றவை, நான் நினைத்தேன், நான் சொந்தமாக ஆட்டோஎன்கோடரை உருவாக்க வேண்டும்.
இது நிறைய நேரம் எடுத்தது மற்றும் முடிவு மேம்படவில்லை.
அம்சம் உருவாக்கம்
படங்களுடன் பணிபுரிய நிறைய நேரம் எடுக்கும், எனவே எளிமையான ஒன்றைச் செய்ய முடிவு செய்தேன்.
நீங்கள் உடனடியாக பார்க்க முடியும் என, தரவுத்தொகுப்பில் பல வகைப்படுத்தப்பட்ட அம்சங்கள் உள்ளன, மேலும் அதிகமாக தொந்தரவு செய்யக்கூடாது என்பதற்காக, நான் கேட்பூஸ்ட் எடுத்தேன். தீர்வு சிறப்பாக இருந்தது, எந்த அமைப்பும் இல்லாமல் நான் உடனடியாக லீடர்போர்டின் முதல் வரிக்கு வந்தேன்.
நிறைய தரவு உள்ளது மற்றும் அது பார்க்வெட் வடிவத்தில் அமைக்கப்பட்டுள்ளது, எனவே இரண்டு முறை யோசிக்காமல், நான் ஸ்கலாவை எடுத்து எல்லாவற்றையும் தீப்பொறியில் எழுத ஆரம்பித்தேன்.
படத்தை உட்பொதிப்பதை விட அதிக வளர்ச்சியைக் கொடுத்த எளிய அம்சங்கள்:
- ஆப்ஜெக்ட்ஐடி, யூசர்ஐடி மற்றும் ஓனர்ஐடி ஆகியவை தரவுகளில் எத்தனை முறை தோன்றின (பிரபலத்துடன் தொடர்புடையதாக இருக்க வேண்டும்);
- எத்தனை இடுகைகளை userId பார்த்துள்ளது (குழுவில் பயனரின் ஆர்வத்துடன் தொடர்புடையதாக இருக்க வேண்டும்);
- உரிமையாளர் ஐடியில் இருந்து எத்தனை தனிப்பட்ட பயனர் ஐடிகள் இடுகைகளைப் பார்த்தன (குழுவின் பார்வையாளர்களின் அளவைப் பிரதிபலிக்கிறது).
நேர முத்திரைகளிலிருந்து பயனர் ஊட்டத்தைப் பார்த்த நாளின் நேரத்தைப் பெற முடிந்தது (காலை/மதியம்/மாலை/இரவு). இந்த வகைகளை இணைப்பதன் மூலம், நீங்கள் தொடர்ந்து அம்சங்களை உருவாக்கலாம்:
- மாலையில் எத்தனை முறை userId உள்நுழைந்தது;
- எந்த நேரத்தில் இந்த இடுகை பெரும்பாலும் காட்டப்படுகிறது (objectId) மற்றும் பல.
இவை அனைத்தும் படிப்படியாக அளவீடுகளை மேம்படுத்தின. ஆனால் பயிற்சி தரவுத்தொகுப்பின் அளவு சுமார் 20M பதிவுகள், எனவே அம்சங்களைச் சேர்ப்பது பயிற்சியை வெகுவாகக் குறைக்கிறது.
தரவைப் பயன்படுத்துவதற்கான எனது அணுகுமுறையை நான் மறுபரிசீலனை செய்தேன். தரவு நேரத்தைச் சார்ந்தது என்றாலும், "எதிர்காலத்தில்" வெளிப்படையான தகவல் கசிவுகள் எதையும் நான் காணவில்லை, இருப்பினும், நான் அதை இப்படி உடைத்தேன்:
எங்களுக்கு வழங்கப்பட்ட பயிற்சி தொகுப்பு (பிப்ரவரி மற்றும் மார்ச் 2 வாரங்கள்) 2 பகுதிகளாக பிரிக்கப்பட்டது.
இந்த மாடல் கடந்த N நாட்களிலிருந்து தரவைப் பயிற்றுவித்தது. மேலே விவரிக்கப்பட்ட திரட்டல்கள் சோதனை உட்பட அனைத்து தரவுகளிலும் கட்டமைக்கப்பட்டுள்ளன. அதே நேரத்தில், இலக்கு மாறியின் பல்வேறு குறியாக்கங்களை உருவாக்கக்கூடிய தரவு தோன்றியது. ஏற்கனவே புதிய அம்சங்களை உருவாக்கிக்கொண்டிருக்கும் குறியீட்டை மீண்டும் பயன்படுத்துவதே எளிமையான அணுகுமுறையாகும், மேலும் அது பயிற்சியளிக்கப்படாத தரவு மற்றும் இலக்கு = 1.
எனவே, நாங்கள் இதே போன்ற அம்சங்களைப் பெற்றுள்ளோம்:
- குழு உரிமையாளர் ஐடியில் எத்தனை முறை பயனர் ஐடி ஒரு இடுகையைப் பார்த்தது;
- குழு உரிமையாளர் ஐடியில் இடுகையை எத்தனை முறை பயனர் ஐடி விரும்பியது;
- உரிமையாளர் ஐடியில் இருந்து பயனர் ஐடி விரும்பிய இடுகைகளின் சதவீதம்.
அதாவது, அது மாறியது இலக்கு குறியாக்கம் வகைப்படுத்தப்பட்ட அம்சங்களின் பல்வேறு சேர்க்கைகளுக்கான தரவுத்தொகுப்பின் ஒரு பகுதி. கொள்கையளவில், கேட்பூஸ்ட் இலக்கு குறியாக்கத்தையும் உருவாக்குகிறது மற்றும் இந்த கண்ணோட்டத்தில் எந்த நன்மையும் இல்லை, ஆனால், எடுத்துக்காட்டாக, இந்த குழுவில் இடுகைகளை விரும்பிய தனிப்பட்ட பயனர்களின் எண்ணிக்கையை கணக்கிட முடிந்தது. அதே நேரத்தில், முக்கிய குறிக்கோள் அடையப்பட்டது - எனது தரவுத்தொகுப்பு பல முறை குறைக்கப்பட்டது, மேலும் அம்சங்களை உருவாக்குவதைத் தொடர முடிந்தது.
கேட்பூஸ்ட் விரும்பிய எதிர்வினையின் அடிப்படையில் மட்டுமே குறியாக்கத்தை உருவாக்க முடியும், பின்னூட்டம் பிற எதிர்வினைகளைக் கொண்டுள்ளது: மறுபகிர்வு, பிடிக்காதது, விரும்பாதது, கிளிக் செய்தல், புறக்கணிக்கப்பட்டது, கைமுறையாகச் செய்யக்கூடிய குறியாக்கங்கள். தரவுத்தொகுப்பை உயர்த்தாமல் இருக்க, அனைத்து வகையான தொகுப்புகளையும் மீண்டும் கணக்கிட்டு, குறைந்த முக்கியத்துவத்துடன் அம்சங்களை நீக்கிவிட்டேன்.
அப்போது நான் அதிக வித்தியாசத்தில் முதல் இடத்தில் இருந்தேன். குழப்பமான ஒரே விஷயம் என்னவென்றால், பட உட்பொதிப்புகள் கிட்டத்தட்ட எந்த வளர்ச்சியையும் காட்டவில்லை. கேட்பூஸ்ட் எல்லாம் கொடுக்க யோசனை வந்தது. Kmeans படங்களை நாங்கள் கிளஸ்டர் செய்து, ஒரு புதிய வகைப்படுத்தல் அம்சமான imageCat ஐப் பெறுகிறோம்.
KMeans இலிருந்து பெறப்பட்ட கிளஸ்டர்களை கைமுறையாக வடிகட்டுதல் மற்றும் ஒன்றிணைத்த பிறகு சில வகுப்புகள் இங்கே உள்ளன.
imageCat அடிப்படையில் நாங்கள் உருவாக்குகிறோம்:
- புதிய வகைப்படுத்தப்பட்ட அம்சங்கள்:
- எந்த இமேஜ் கேட் பயனர் ஐடியால் அடிக்கடி பார்க்கப்பட்டது;
- எந்த இமேஜ் கேட் பெரும்பாலும் உரிமையாளர் ஐடியைக் காட்டுகிறது;
- எந்த இமேஜ் கேட் பயனர் ஐடியால் அடிக்கடி விரும்பப்பட்டது;
- பல்வேறு கவுண்டர்கள்:
- யூசர் ஐடியில் எத்தனை தனிப்பட்ட இமேஜ்கேட் பார்த்தது;
- மேலே விவரிக்கப்பட்டுள்ளபடி சுமார் 15 ஒத்த அம்சங்கள் மற்றும் இலக்கு குறியாக்கம்.
நூல்கள்
படப் போட்டியின் முடிவுகள் எனக்குப் பொருத்தமாக இருந்தன, மேலும் நான் உரைகளில் முயற்சி செய்ய முடிவு செய்தேன். நான் இதற்கு முன்பு உரைகளுடன் அதிகம் வேலை செய்யவில்லை, முட்டாள்தனமாக, tf-idf மற்றும் svd இல் அந்த நாளைக் கொன்றேன். பின்னர் நான் doc2vec உடன் பேஸ்லைனைப் பார்த்தேன், அது எனக்குத் தேவையானதைச் செய்கிறது. doc2vec அளவுருக்களை சிறிது சரிசெய்ததால், எனக்கு உரை உட்பொதிப்புகள் கிடைத்தன.
பின்னர் நான் படங்களுக்கான குறியீட்டை மீண்டும் பயன்படுத்தினேன், அதில் பட உட்பொதிப்புகளை உரை உட்பொதிப்புடன் மாற்றினேன். அதன் பலனாக, உரைப் போட்டியில் 2ம் இடம் பிடித்தேன்.
கூட்டு அமைப்பு
நான் இன்னும் ஒரு குச்சியால் "குத்தவில்லை" என்று ஒரு போட்டி உள்ளது, மேலும் லீடர்போர்டில் AUC ஐப் பார்த்தால், இந்த குறிப்பிட்ட போட்டியின் முடிவுகள் ஆஃப்லைன் மேடையில் மிகப்பெரிய தாக்கத்தை ஏற்படுத்தியிருக்க வேண்டும்.
நான் மூலத் தரவுகளில் உள்ள அனைத்து அம்சங்களையும் எடுத்து, வகைப்படுத்தப்பட்டவற்றைத் தேர்ந்தெடுத்து, படங்களின் அடிப்படையிலான அம்சங்களைத் தவிர, படங்களுக்கான அதே திரட்டுகளைக் கணக்கிட்டேன். இதை கேட்பூஸ்டில் போட்டதால் தான் 2வது இடம் கிடைத்தது.
கேட்பூஸ்ட் தேர்வுமுறையின் முதல் படிகள்
ஒரு முதல் மற்றும் இரண்டு இரண்டாவது இடங்கள் எனக்கு மகிழ்ச்சி அளித்தன, ஆனால் நான் சிறப்பு எதுவும் செய்யவில்லை என்ற புரிதல் இருந்தது, அதாவது பதவிகளை இழப்பதை எதிர்பார்க்கலாம்.
போட்டியின் பணி பயனருக்குள் இடுகைகளை வரிசைப்படுத்துவதாகும், இந்த நேரத்தில் நான் வகைப்பாடு சிக்கலைத் தீர்த்துக்கொண்டிருந்தேன், அதாவது தவறான மெட்ரிக்கை மேம்படுத்துதல்.
ஒரு எளிய உதாரணம் தருகிறேன்:
| பயனர் ஐடி | objectId | கணிப்பை | அடிப்படை உண்மை |
|---|---|---|---|
| 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 |
ஒரு சிறிய மறுசீரமைப்பு செய்வோம்
| பயனர் ஐடி | objectId | கணிப்பை | அடிப்படை உண்மை |
|---|---|---|---|
| 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 |
பின்வரும் முடிவுகளைப் பெறுகிறோம்:
| மாதிரி | AUC ம் | பயனர்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 மெட்ரிக்கை மேம்படுத்துவது அல்ல.
கேட்பூஸ்ட் பெட்டியிலிருந்து. தரவரிசை அளவீடுகளைப் பற்றி படித்தேன், கேட்பூஸ்டைப் பயன்படுத்தும் போது மற்றும் ஒரே இரவில் பயிற்சி செய்ய YetiRankPairwise அமைக்கவும். முடிவு சுவாரஸ்யமாக இல்லை. நான் பயிற்சி பெறவில்லை என்று முடிவு செய்து, பிழைச் செயல்பாட்டை QueryRMSE க்கு மாற்றினேன், இது கேட்பூஸ்ட் ஆவணங்கள் மூலம் ஆராயும்போது, வேகமாக ஒன்றிணைகிறது. இறுதியில், வகைப்பாட்டிற்கான பயிற்சியின் போது அதே முடிவுகளை நான் பெற்றேன், ஆனால் இந்த இரண்டு மாடல்களின் குழுமங்களும் ஒரு நல்ல அதிகரிப்பைக் கொடுத்தன, இது என்னை மூன்று போட்டிகளிலும் முதல் இடத்திற்கு கொண்டு வந்தது.
"கூட்டு அமைப்புகள்" போட்டியின் ஆன்லைன் நிலை முடிவதற்கு 5 நிமிடங்களுக்கு முன்பு, செர்ஜி ஷால்னோவ் என்னை இரண்டாவது இடத்திற்கு நகர்த்தினார். நாங்கள் ஒன்றாக அடுத்த பாதையில் நடந்தோம்.
ஆஃப்லைன் நிலைக்குத் தயாராகிறது
ஆர்டிஎக்ஸ் 2080 டிஐ வீடியோ கார்டு மூலம் ஆன்லைன் ஸ்டேஜில் எங்களுக்கு வெற்றி உறுதி, ஆனால் முக்கிய பரிசு 300 ரூபிள் மற்றும் இறுதி முதல் இடம் கூட இந்த 000 வாரங்களுக்கு வேலை செய்ய எங்களை கட்டாயப்படுத்தியது.
அது முடிந்தவுடன், செர்ஜி கேட்பூஸ்டையும் பயன்படுத்தினார். நாங்கள் யோசனைகளையும் அம்சங்களையும் பரிமாறிக்கொண்டோம், அதைப் பற்றி நான் கற்றுக்கொண்டேன் அதில் எனது பல கேள்விகளுக்கான பதில்கள் இருந்தன, மேலும் அந்த நேரத்தில் என்னிடம் இல்லாதவைகளும் கூட.
அறிக்கையைப் பார்ப்பது, எல்லா அளவுருக்களையும் இயல்புநிலை மதிப்பிற்குத் திரும்பப் பெற வேண்டும், மேலும் அமைப்புகளை மிகவும் கவனமாகச் செய்ய வேண்டும் மற்றும் அம்சங்களின் தொகுப்பை சரிசெய்த பின்னரே செய்ய வேண்டும் என்ற எண்ணத்திற்கு என்னை அழைத்துச் சென்றது. இப்போது ஒரு பயிற்சி சுமார் 15 மணிநேரம் எடுத்தது, ஆனால் ஒரு மாடல் தரவரிசையில் குழுமத்தில் பெறப்பட்டதை விட சிறந்த வேகத்தைப் பெற முடிந்தது.
அம்சம் உருவாக்கம்
கூட்டு அமைப்புகள் போட்டியில், மாடலுக்கு அதிக எண்ணிக்கையிலான அம்சங்கள் முக்கியமானதாக மதிப்பிடப்படுகிறது. உதாரணத்திற்கு, auditweights_spark_svd - மிக முக்கியமான அடையாளம், ஆனால் அதன் அர்த்தம் பற்றி எந்த தகவலும் இல்லை. முக்கியமான அம்சங்களின் அடிப்படையில் பல்வேறு திரட்டுகளை எண்ணுவது பயனுள்ளது என்று நினைத்தேன். எடுத்துக்காட்டாக, பயனர், குழு, பொருளின் அடிப்படையில் சராசரி auditweights_spark_svd. எந்தப் பயிற்சியும் செய்யப்படாத தரவுகளைப் பயன்படுத்திக் கணக்கிடலாம் மற்றும் இலக்கு = 1, அதாவது சராசரி auditweights_spark_svd அவர் விரும்பிய பொருள்களால் பயனரால். தவிர முக்கியமான அறிகுறிகள் auditweights_spark_svd, பல இருந்தன. அவற்றில் சில இங்கே:
- தணிக்கை எடைகள்CtrGender
- தணிக்கை எடைகள்CtrHigh
- userOwnerCounterCreateLikes
உதாரணமாக, சராசரி தணிக்கை எடைகள்CtrGender பயனர் ஐடியின் படி இது சராசரி மதிப்பைப் போலவே ஒரு முக்கியமான அம்சமாக மாறியது userOwnerCounterCreateLikes பயனர் ஐடி + உரிமையாளர் ஐடி மூலம். புலங்களின் அர்த்தத்தை நீங்கள் புரிந்து கொள்ள வேண்டும் என்று இது ஏற்கனவே சிந்திக்க வைக்க வேண்டும்.
முக்கிய அம்சங்களும் இருந்தன தணிக்கை எடைகள் விருப்ப எண்ணிக்கை и தணிக்கை எடைகள் காட்சிகள் எண்ணிக்கை. ஒன்றன்பின் ஒன்றாகப் பிரித்து, இன்னும் முக்கியமான அம்சம் கிடைத்தது.
தரவு கசிவுகள்
போட்டி மற்றும் உற்பத்தி மாடலிங் மிகவும் வேறுபட்ட பணிகள். தரவைத் தயாரிக்கும் போது, அனைத்து விவரங்களையும் கணக்கில் எடுத்துக்கொள்வது மற்றும் சோதனையில் இலக்கு மாறியைப் பற்றிய சில அற்பமான தகவல்களைத் தெரிவிக்காமல் இருப்பது மிகவும் கடினம். நாங்கள் ஒரு உற்பத்தி தீர்வை உருவாக்குகிறோம் என்றால், மாதிரியைப் பயிற்றுவிக்கும் போது தரவு கசிவுகளைப் பயன்படுத்துவதைத் தவிர்க்க முயற்சிப்போம். ஆனால் நாம் போட்டியில் வெற்றிபெற விரும்பினால், தரவு கசிவுகள் சிறந்த அம்சங்களாகும்.
தரவைப் படித்த பிறகு, objectId மதிப்புகளின்படி அதைக் காணலாம் தணிக்கை எடைகள் விருப்ப எண்ணிக்கை и தணிக்கை எடைகள் காட்சிகள் எண்ணிக்கை மாற்றம், அதாவது, இந்த அம்சங்களின் அதிகபட்ச மதிப்புகளின் விகிதம், காட்சி நேரத்தில் உள்ள விகிதத்தை விட பிந்தைய மாற்றத்தை சிறப்பாக பிரதிபலிக்கும்.
நாங்கள் கண்டறிந்த முதல் கசிவு auditweightsLikesCountMax/auditweightsShowsCountMax.
ஆனால் தரவை இன்னும் நெருக்கமாகப் பார்த்தால் என்ன செய்வது? நிகழ்ச்சி தேதியின்படி வரிசைப்படுத்தி பெறுவோம்:
| objectId | பயனர் ஐடி | தணிக்கை எடைகள் காட்சிகள் எண்ணிக்கை | தணிக்கை எடைகள் விருப்ப எண்ணிக்கை | இலக்கு (பிடித்துள்ளது) |
|---|---|---|---|---|
| 1 | 1 | 12 | 3 | அநேகமாக இல்லை |
| 1 | 2 | 15 | 3 | ஒருவேளை ஆம் |
| 1 | 3 | 16 | 4 |
இதுபோன்ற முதல் உதாரணத்தை நான் கண்டுபிடித்தபோது ஆச்சரியமாக இருந்தது, மேலும் எனது கணிப்பு உண்மையாகவில்லை என்று மாறியது. ஆனால், பொருளுக்குள் இந்த குணாதிசயங்களின் அதிகபட்ச மதிப்புகள் அதிகரித்தன என்ற உண்மையை கணக்கில் எடுத்துக்கொண்டு, நாங்கள் சோம்பேறியாக இல்லை, கண்டுபிடிக்க முடிவு செய்தோம். ஆடிட்வெயிட்ஸ் ஷோஸ்கவுண்ட்நெக்ஸ்ட் и தணிக்கை எடைகள்LikesCountNext, அதாவது, அடுத்த கணத்தில் மதிப்புகள். ஒரு அம்சத்தைச் சேர்ப்பதன் மூலம்
(auditweightsShowsCountNext-auditweightsShowsCount)/(auditweightsLikesCount-auditweightsLikesCountNext) நாங்கள் விரைவாக குதித்தோம்.
பின்வரும் மதிப்புகளைக் கண்டறிவதன் மூலம் இதேபோன்ற கசிவுகளைப் பயன்படுத்தலாம் userOwnerCounterCreateLikes userId+ownerId க்குள் மற்றும், எடுத்துக்காட்டாக, தணிக்கை எடைகள்CtrGender objectId+userGenderக்குள். கசிவுகளுடன் ஒத்த 6 புலங்களைக் கண்டறிந்து அவற்றிலிருந்து முடிந்தவரை தகவல்களைப் பிரித்தெடுத்தோம்.
அந்த நேரத்தில், கூட்டு அம்சங்களிலிருந்து முடிந்தவரை தகவல்களைப் பிழிந்தோம், ஆனால் படம் மற்றும் உரைப் போட்டிகளுக்குத் திரும்பவில்லை. நான் சரிபார்க்க ஒரு சிறந்த யோசனை இருந்தது: படங்கள் அல்லது உரைகளை அடிப்படையாகக் கொண்ட அம்சங்கள் தொடர்புடைய போட்டிகளில் எவ்வளவு வழங்குகின்றன?
படம் மற்றும் உரைப் போட்டிகளில் கசிவுகள் எதுவும் இல்லை, ஆனால் அந்த நேரத்தில் நான் இயல்புநிலை கேட்பூஸ்ட் அளவுருக்களைத் திருப்பி, குறியீட்டை சுத்தம் செய்து சில அம்சங்களைச் சேர்த்தேன். மொத்தம் இருந்தது:
| முடிவு | விரைவில் |
|---|---|
| படங்களுடன் அதிகபட்சம் | 0.6411 |
| அதிகபட்சம் படங்கள் இல்லை | 0.6297 |
| இரண்டாம் இடம் முடிவு | 0.6295 |
| முடிவு | விரைவில் |
|---|---|
| உரைகளுடன் அதிகபட்சம் | 0.666 |
| உரைகள் இல்லாமல் அதிகபட்சம் | 0.660 |
| இரண்டாம் இடம் முடிவு | 0.656 |
| முடிவு | விரைவில் |
|---|---|
| கூட்டுப்பணியில் அதிகபட்சம் | 0.745 |
| இரண்டாம் இடம் முடிவு | 0.723 |
உரைகள் மற்றும் படங்களை எங்களால் அதிகம் கசக்க முடியாது என்பது தெளிவாகத் தெரிந்தது, மேலும் சில சுவாரஸ்யமான யோசனைகளை முயற்சித்த பிறகு, நாங்கள் அவர்களுடன் வேலை செய்வதை நிறுத்திவிட்டோம்.
கூட்டு அமைப்புகளில் மேலும் தலைமுறை அம்சங்கள் அதிகரிக்கவில்லை, நாங்கள் தரவரிசைப்படுத்தத் தொடங்கினோம். ஆன்லைன் கட்டத்தில், வகைப்பாடு மற்றும் தரவரிசை குழுமம் எனக்கு ஒரு சிறிய அதிகரிப்பைக் கொடுத்தது, ஏனெனில் நான் வகைப்படுத்தலில் பயிற்சி பெற்றேன். YetiRanlPairwise உட்பட எந்தப் பிழைச் செயல்பாடுகளும் LogLoss செய்த (0,745 vs. 0,725) முடிவுக்கு அருகில் எங்கும் உருவாக்கப்படவில்லை. QueryCrossEntropy பற்றிய நம்பிக்கை இன்னும் இருந்தது, அதைத் தொடங்க முடியவில்லை.
ஆஃப்லைன் நிலை
ஆஃப்லைன் கட்டத்தில், தரவு அமைப்பு அப்படியே இருந்தது, ஆனால் சிறிய மாற்றங்கள் இருந்தன:
- அடையாளங்காட்டிகள் userId, objectId, ownerId ஆகியவை மறுசீரமைக்கப்பட்டன;
- பல அடையாளங்கள் அகற்றப்பட்டு பல பெயர்கள் மாற்றப்பட்டன;
- தரவு தோராயமாக 1,5 மடங்கு அதிகரித்துள்ளது.
பட்டியலிடப்பட்ட சிரமங்களுக்கு கூடுதலாக, ஒரு பெரிய பிளஸ் இருந்தது: குழுவிற்கு RTX 2080TI உடன் பெரிய சர்வர் ஒதுக்கப்பட்டது. நான் நீண்ட காலமாக htop ஐ அனுபவித்து வருகிறேன்.
ஒரே ஒரு யோசனை இருந்தது - ஏற்கனவே இருப்பதை வெறுமனே இனப்பெருக்கம் செய்ய. சேவையகத்தில் சுற்றுச்சூழலை அமைக்க இரண்டு மணிநேரம் செலவழித்த பிறகு, முடிவுகள் மீண்டும் உருவாக்கக்கூடியவை என்பதை நாங்கள் படிப்படியாக சரிபார்க்க ஆரம்பித்தோம். நாம் எதிர்கொள்ளும் முக்கிய பிரச்சனை தரவு அளவு அதிகரிப்பு ஆகும். சுமையை சிறிது குறைக்கவும் மற்றும் catboost அளவுருவை ctr_complexity=1 அமைக்கவும் முடிவு செய்தோம். இது வேகத்தை சிறிது குறைக்கிறது, ஆனால் எனது மாதிரி வேலை செய்யத் தொடங்கியது, இதன் விளைவாக நன்றாக இருந்தது - 0,733. செர்ஜி, என்னைப் போலல்லாமல், தரவை 2 பகுதிகளாகப் பிரிக்கவில்லை மற்றும் எல்லா தரவையும் பயிற்றுவித்தார், இது ஆன்லைன் கட்டத்தில் சிறந்த முடிவுகளைக் கொடுத்தாலும், ஆஃப்லைன் கட்டத்தில் பல சிரமங்கள் இருந்தன. நாங்கள் உருவாக்கிய அனைத்து அம்சங்களையும் எடுத்து அவற்றை கேட்பூஸ்டுக்குள் தள்ள முயற்சித்தால், ஆன்லைன் கட்டத்தில் எதுவும் செயல்படாது. செர்ஜி டைப் ஆப்டிமைசேஷன் செய்தார், எடுத்துக்காட்டாக, float64 வகைகளை float32 ஆக மாற்றினார். பாண்டாக்களில் நினைவக மேம்படுத்தல் பற்றிய தகவலை நீங்கள் காணலாம். இதன் விளைவாக, செர்ஜி அனைத்து தரவையும் பயன்படுத்தி CPU இல் பயிற்சி பெற்றார் மற்றும் சுமார் 0,735 பெற்றார்.
இந்த முடிவுகள் வெற்றி பெற போதுமானதாக இருந்தன, ஆனால் நாங்கள் எங்கள் உண்மையான வேகத்தை மறைத்துவிட்டோம், மற்ற அணிகளும் இதைச் செய்யவில்லை என்பதை உறுதிப்படுத்த முடியவில்லை.
கடைசி வரை போராடு
கேட்பூஸ்ட் டியூனிங்
எங்கள் தீர்வு முழுமையாக மறுஉருவாக்கம் செய்யப்பட்டது, நாங்கள் உரை தரவு மற்றும் படங்களின் அம்சங்களைச் சேர்த்துள்ளோம், எனவே கேட்பூஸ்ட் அளவுருக்களை மாற்றியமைப்பது மட்டுமே எஞ்சியுள்ளது. செர்ஜி சிபியுவில் குறைந்த எண்ணிக்கையிலான மறு செய்கைகளுடன் பயிற்சி பெற்றார், மேலும் நான் 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 |
மாதிரியின் விரைவான பயன்பாடு தேவையில்லை என்றால், உகந்ததாக இல்லாத அளவுருக்களைப் பயன்படுத்தி பல மாதிரிகளின் குழுமத்துடன் அளவுருக்களின் தேர்வை மாற்றுவது நல்லது என்று நானே முடிவு செய்தேன்.
தரவுத்தொகுப்பின் அளவை ஜிபியுவில் இயக்க செர்ஜி மேம்படுத்திக் கொண்டிருந்தார். தரவின் ஒரு பகுதியை துண்டிப்பதே எளிய விருப்பம், ஆனால் இது பல வழிகளில் செய்யப்படலாம்:
- தரவுத்தொகுப்பு நினைவகத்தில் பொருந்தத் தொடங்கும் வரை பழைய தரவை (பிப்ரவரி தொடக்கம்) படிப்படியாக அகற்றவும்;
- குறைந்த முக்கியத்துவம் கொண்ட அம்சங்களை அகற்றவும்;
- ஒரே ஒரு நுழைவு உள்ள பயனர் ஐடிகளை அகற்றவும்;
- சோதனையில் இருக்கும் பயனர் ஐடிகளை மட்டும் விட்டு விடுங்கள்.
இறுதியில், அனைத்து விருப்பங்களிலிருந்தும் ஒரு குழுமத்தை உருவாக்கவும்.
கடைசி குழுமம்
கடைசி நாளின் பிற்பகுதியில், 0,742 விளைச்சல் தரும் எங்கள் மாடல்களின் குழுமத்தை நாங்கள் அமைத்துள்ளோம். ஒரே இரவில் நான் எனது மாடலை ctr_complexity=2 உடன் அறிமுகப்படுத்தினேன், 30 நிமிடங்களுக்குப் பதிலாக 5 மணிநேரம் பயிற்சி அளித்தேன். அதிகாலை 4 மணிக்கு மட்டுமே அது கணக்கிடப்பட்டது, நான் கடைசி குழுமத்தை உருவாக்கினேன், இது பொது லீடர்போர்டில் 0,7433 கொடுத்தது.
சிக்கலைத் தீர்ப்பதற்கான பல்வேறு அணுகுமுறைகள் காரணமாக, எங்கள் கணிப்புகள் வலுவாக தொடர்புபடுத்தப்படவில்லை, இது குழுமத்தில் நல்ல அதிகரிப்பைக் கொடுத்தது. ஒரு நல்ல குழுமத்தைப் பெற, மூல மாதிரி கணிப்புகள் கணிப்பு (முன்கணிப்பு_வகை='RawFormulaVal') மற்றும் scale_pos_weight=neg_count/pos_count ஆகியவற்றை அமைப்பது நல்லது.
இணையதளத்தில் பார்க்கலாம் .
மற்ற தீர்வுகள்
பல அணிகள் சிபாரிசு அமைப்பு அல்காரிதம்களின் நியதிகளைப் பின்பற்றின. நான், இந்தத் துறையில் நிபுணராக இல்லாததால், அவற்றை மதிப்பீடு செய்ய முடியாது, ஆனால் 2 சுவாரஸ்யமான தீர்வுகளை நான் நினைவில் வைத்திருக்கிறேன்.
- . நிகோலே, Mail.ru இன் பணியாளராக இருப்பதால், பரிசுகளுக்கு விண்ணப்பிக்கவில்லை, எனவே அவரது குறிக்கோள் அதிகபட்ச வேகத்தை அடைவது அல்ல, ஆனால் எளிதில் அளவிடக்கூடிய தீர்வைப் பெறுவது.
- ஜூரி பரிசு பெற்ற அணியின் முடிவு அடிப்படையில் , கைமுறையாக வேலை செய்யாமல் மிகச் சிறந்த படக் கிளஸ்டரிங் அனுமதிக்கப்படுகிறது.
முடிவுக்கு
என் நினைவில் அதிகம் பதிந்தவை:
- தரவுகளில் வகைப்படுத்தப்பட்ட அம்சங்கள் இருந்தால், இலக்கு குறியாக்கத்தை எவ்வாறு சரியாகச் செய்வது என்பது உங்களுக்குத் தெரிந்தால், கேட்பூஸ்டை முயற்சிப்பது இன்னும் நல்லது.
- நீங்கள் ஒரு போட்டியில் பங்கேற்கிறீர்கள் என்றால், learning_rate மற்றும் மறு செய்கைகளைத் தவிர வேறு அளவுருக்களைத் தேர்ந்தெடுப்பதில் நேரத்தை வீணடிக்க வேண்டாம். பல மாதிரிகளின் குழுமத்தை உருவாக்குவதே விரைவான தீர்வாகும்.
- GPU இல் பூஸ்டிங் கற்றுக்கொள்ளலாம். கேட்பூஸ்ட் GPU இல் மிக விரைவாகக் கற்றுக்கொள்ள முடியும், ஆனால் அது நிறைய நினைவகத்தை சாப்பிடுகிறது.
- யோசனைகளின் வளர்ச்சி மற்றும் சோதனையின் போது, ஒரு சிறிய rsm~=0.2 (CPU மட்டும்) மற்றும் ctr_complexity=1 ஐ அமைப்பது நல்லது.
- மற்ற அணிகளைப் போலல்லாமல், எங்கள் மாடல்களின் குழுமம் பெரிய அதிகரிப்பைக் கொடுத்தது. நாங்கள் வெவ்வேறு மொழிகளில் கருத்துக்களைப் பரிமாறிக்கொண்டோம். தரவைப் பிரிப்பதற்கு எங்களிடம் வேறுபட்ட அணுகுமுறை இருந்தது, ஒவ்வொன்றும் அதன் சொந்த பிழைகள் என்று நான் நினைக்கிறேன்.
- வகைப்படுத்தல் தேர்வுமுறையை விட தரவரிசை மேம்படுத்தல் ஏன் மோசமாகச் செயல்பட்டது என்பது தெளிவாகத் தெரியவில்லை.
- நான் உரைகளுடன் பணிபுரிந்த சில அனுபவத்தையும் பரிந்துரையாளர் அமைப்புகள் எவ்வாறு உருவாக்கப்படுகின்றன என்பதைப் பற்றிய புரிதலையும் பெற்றேன்.
பெற்ற உணர்வுகள், அறிவு மற்றும் பரிசுகளுக்கு ஏற்பாட்டாளர்களுக்கு நன்றி.
ஆதாரம்: www.habr.com