Tęsdami Habré mašininio mokymosi konkursų temą, norėtume supažindinti skaitytojus su dar dviem platformomis. Jie tikrai nėra tokie dideli kaip kaggle, bet tikrai nusipelno dėmesio.
Asmeniškai aš per daug nemėgstu kaggle dėl kelių priežasčių:
- pirma, varžybos ten dažnai trunka kelis mėnesius, o aktyvus dalyvavimas reikalauja daug pastangų;
- antra, viešieji branduoliai (vieši sprendimai). Kaggle šalininkai pataria su jais elgtis ramiai kaip Tibeto vienuoliai, tačiau iš tikrųjų labai gaila, kai kažkas, dėl ko dirbi mėnesį ar du, staiga pasirodo, kad kiekvienam išdėliota ant sidabrinio padėklo.
Laimei, mašininio mokymosi konkursai rengiami kitose platformose, o keletas iš šių konkursų bus aptariami.
| Oficiali kalba: anglų, organizatoriai: Yandex, Sberbank, HSE |
Oficiali rusų kalba, organizatoriai: Mail.ru grupė |
| Internetinis turas: 15 m. sausio 11 d. – vasario 2019 d.; Finalas vietoje: 4 m. balandžio 6–2019 d |
internetu – nuo vasario 7 iki kovo 15 d.; neprisijungus – nuo kovo 30 iki balandžio 1 d. |
| Naudodami tam tikrą duomenų rinkinį apie didžiojo hadronų greitintuvo dalelę (trajektoriją, impulsą ir kitus gana sudėtingus fizinius parametrus), nustatykite, ar tai miuonas, ar ne. Iš šio teiginio buvo nustatytos 2 užduotys: - viename jūs tiesiog turėjote atsiųsti savo prognozę, - ir kitoje - visas numatymo kodas ir modelis, o vykdymui buvo taikomi gana griežti veikimo laiko ir atminties naudojimo apribojimai. |
SNA Hackathon konkursui buvo renkami atvirų grupių turinio rodymo žurnalai vartotojų naujienų kanaluose 2018 m. vasario–kovo mėn. Testų rinkinyje yra paskutinė kovo pusantros savaitė. Kiekviename žurnalo įraše pateikiama informacija apie tai, kas buvo rodoma ir kam, taip pat kaip vartotojas reagavo į šį turinį: įvertino, pakomentavo, ignoravo ar paslėpė nuo informacijos santraukos. „SNA Hackathon“ užduočių esmė yra reitinguoti kiekvieną socialinio tinklo „Odnoklassniki“ vartotoją savo kanalą, pakeliant kuo aukščiau tuos įrašus, kurie gaus „klasę“. Internetiniame etape užduotis buvo padalinta į 3 dalis: 1. reitinguoti pareigybes pagal įvairias bendradarbiavimo charakteristikas 2. reitinguokite įrašus pagal juose esančius vaizdus 3. reitinguoti postus pagal juose esantį tekstą |
| Sudėtinga tinkinta metrika, panaši į ROC-AUC | Vidutinis vartotojo ROC-AUC |
| Pirmojo etapo prizai - marškinėliai už N vietas, perėjimas į antrąjį etapą, kur varžybų metu buvo apmokėta nakvynė ir maitinimas Antrasis etapas - ??? (Dėl tam tikrų priežasčių apdovanojimo ceremonijoje nedalyvavau ir negalėjau sužinoti, kokie buvo prizai). Visiems laimėjusios komandos nariams jie pažadėjo nešiojamus kompiuterius |
Pirmojo etapo prizai - marškinėliai 100 geriausių dalyvių, patekimas į antrąjį etapą, kur buvo apmokėta kelionė į Maskvą, apgyvendinimas ir maitinimas varžybų metu. Taip pat pirmojo etapo pabaigoje buvo paskelbti prizai 3 etapo geriausiems 1 užduotyse: visi laimėjo RTX 2080 TI vaizdo plokštę! Antrasis etapas buvo komandinis, komandos sudarė nuo 2 iki 5 žmonių, prizai: 1 vieta - 300 000 rublių 2 vieta - 200 000 rublių 3 vieta - 100 000 rublių žiuri prizas - 100 000 rublių |
| Oficiali telegramų grupė, ~190 dalyvių, bendravimas anglų kalba, į klausimus atsakymo teko laukti kelias dienas | Oficiali grupė telegramoje, ~1500 dalyvių, aktyvus užduočių aptarimas tarp dalyvių ir organizatorių |
| Organizatoriai pateikė du pagrindinius sprendimus – paprastus ir pažangius. Paprastai reikėjo mažiau nei 16 GB RAM, o išplėstinė atmintis netilpo į 16. Tuo pačiu metu, šiek tiek žvelgiant į priekį, dalyviai negalėjo gerokai pralenkti pažangaus sprendimo. Paleidus šiuos sprendimus nekilo jokių sunkumų. Pažymėtina, kad išplėstiniame pavyzdyje buvo komentaras su užuomina, nuo ko pradėti tobulinti sprendimą. | Kiekvienai užduočiai buvo pateikti pagrindiniai primityvūs sprendimai, kuriuos dalyviai nesunkiai pranoko. Pirmosiomis konkurso dienomis dalyviai susidūrė su keletu sunkumų: pirma, duomenys buvo pateikti Apache Parquet formatu, o ne visi Python ir parketo paketo deriniai veikė be klaidų. Antrasis sunkumas buvo nuotraukų atsisiuntimas iš pašto debesies; šiuo metu nėra lengvo būdo vienu metu atsisiųsti didelį kiekį duomenų. Todėl šios problemos dalyvius atitolino porai dienų. |
IDAO. Pirmas lygmuo
Užduotis buvo suskirstyti miuonų/ne miuonų daleles pagal jų charakteristikas. Pagrindinis šios užduoties bruožas buvo svorio stulpelio buvimas treniruočių duomenyse, kurį patys organizatoriai interpretavo kaip pasitikėjimą šios eilutės atsakymu. Problema ta, kad nemažai eilučių buvo neigiamų svorių.
Kelias minutes pagalvoję apie liniją su užuomina (užuomina tiesiog atkreipė dėmesį į šią svorio stulpelio savybę) ir sukūrę šią grafiką, nusprendėme patikrinti 3 variantus:
1) apverskite eilučių su neigiamu svoriu (ir atitinkamai svoriais) tikslą
2) perkelkite svorius į mažiausią reikšmę, kad jie prasidėtų nuo 0
3) nenaudokite stygų svarmenų
Trečias variantas pasirodė pats prasčiausias, tačiau pirmieji du pagerino rezultatą, geriausias variantas Nr.1, kuris iškart atvedė į dabartinę antrąją vietą pirmoje užduotyje ir pirmus antroje.
Kitas mūsų žingsnis buvo peržiūrėti duomenis dėl trūkstamų verčių. Organizatoriai mums davė jau sušukuotus duomenis, kur trūko nemažai reikšmių, o jas pakeitė -9999.
Radome trūkstamų reikšmių stulpeliuose MatchedHit_{X,Y,Z}[N] ir MatchedHit_D{X,Y,Z}[N] ir tik tada, kai N=2 arba 3. Kaip suprantame, kai kurios dalelės nebuvo praleidžia visus 4 detektorius ir sustojo 3 arba 4 plokštelėje. Duomenyse taip pat buvo Lextra_{X,Y}[N] stulpelių, kurie, matyt, apibūdina tą patį kaip MatchedHit_{X,Y,Z}[N], tačiau naudojant tam tikrą ekstrapoliaciją. Šie menki spėjimai rodo, kad Lextra_{X,Y}[N] galima pakeisti trūkstamomis reikšmėmis MatchedHit_{X,Y,Z}[N] (tik X ir Y koordinatėms). MatchedHit_Z[N] buvo gerai užpildytas mediana. Šios manipuliacijos leido mums pasiekti 1-ąją tarpinę vietą abiejose užduotyse.
Atsižvelgiant į tai, kad jie nieko nedavė už laimėjimą pirmame etape, galėjome sustoti, bet tęsėme, nupiešėme gražių paveikslėlių ir sugalvojome naujų funkcijų.
Pavyzdžiui, mes nustatėme, kad jei nubraižome dalelės susikirtimo taškus su kiekviena iš keturių detektoriaus plokštelių, pamatysime, kad kiekvienos plokštės taškai yra sugrupuoti į 5 stačiakampius, kurių kraštinių santykis yra 4 ir 5, o jų centras yra taškas (0,0), o pirmame stačiakampyje taškų nėra.
| Plokštelės nr. / stačiakampio matmenys | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| 1 plokštelė | 500h625 | 1000h1250 | 2000h2500 | 4000h5000 | 8000h10000 |
| 2 plokštelė | 520h650 | 1040h1300 | 2080h2600 | 4160h5200 | 8320h10400 |
| 3 plokštelė | 560h700 | 1120h1400 | 2240h2800 | 4480h5600 | 8960h11200 |
| 4 plokštelė | 600h750 | 1200h1500 | 2400h3000 | 4800h6000 | 9600h12000 |
Nustatę šiuos matmenis, kiekvienai dalelei pridėjome 4 naujus kategorinius požymius - stačiakampio, kuriame ji kerta kiekvieną plokštę, skaičių.
Taip pat pastebėjome, kad dalelės tarsi sklaidosi į šonus nuo centro ir kilo mintis kaip nors įvertinti šio sklaidos „kokybę“. Idealiu atveju tikriausiai būtų galima sugalvoti kokią nors „idealią“ parabolę priklausomai nuo kilimo taško ir įvertinti nuokrypį nuo jo, bet apsiribojome „idealia“ tiesia linija. Sukūrę tokias idealias tiesias linijas kiekvienam įėjimo taškui, galėjome apskaičiuoti kiekvienos dalelės trajektorijos standartinį nuokrypį nuo šios tiesės. Kadangi vidutinis tikslo = 1 nuokrypis buvo 152, o tikslas = 0 - 390, preliminariai įvertinome šią savybę kaip gerą. Ir iš tiesų, ši funkcija iškart pateko į naudingiausių viršūnę.
Mes apsidžiaugėme ir kaip papildomas 4 ypatybes pridėjome visų 4 susikirtimo taškų kiekvienai dalelei nuokrypį nuo idealios tiesės (ir jie taip pat veikė gerai).
Organizatorių pateiktos nuorodos į mokslinius straipsnius konkurso tema paskatino mintį, kad mes toli gražu nesame pirmieji, išsprendę šią problemą ir, ko gero, yra kažkokia specializuota programinė įranga. Github svetainėje atradę saugyklą, kurioje buvo įdiegti metodai IsMuonSimple, IsMuon, IsMuonLoose, su nedideliais pakeitimais perkėlėme juos į savo svetainę. Patys metodai buvo labai paprasti: pavyzdžiui, jei energija mažesnė už tam tikrą slenkstį, tai nėra miuonas, kitu atveju tai yra miuonas. Tokios paprastos funkcijos akivaizdžiai negalėjo padidinti gradiento padidinimo, todėl prie slenksčio pridėjome dar vieną reikšmingą „atstumą“. Šios funkcijos taip pat buvo šiek tiek patobulintos. Galbūt, nuodugniau išanalizavus esamus metodus, pavyko rasti stipresnių metodų ir juos įtraukti į ženklus.
Varžybų pabaigoje šiek tiek pakoregavome „greitą“ antrosios problemos sprendimą; galiausiai jis skyrėsi nuo pradinio šiais punktais:
- Neigiamą svorį turinčiose eilutėse taikinys buvo apverstas
- Užpildytos trūkstamos reikšmės MatchedHit_{X,Y,Z}[N]
- Sumažintas gylis iki 7
- Sumažintas mokymosi rodiklis iki 0.1 (buvo 0.19)
Dėl to išbandėme daugiau funkcijų (nelabai sėkmingai), pasirinkome parametrus ir išmokome catboost, lightgbm ir xgboost, išbandėme skirtingus prognozių derinius ir prieš atidarydami privatų užtikrintai laimėjome antroje užduotyje, o pirmoje buvome tarp lyderiai.
Atidarę privačią užėmėme 10 vietą pagal 1 užduotį ir 3 vietą pagal antrąją. Visi lyderiai susimaišė, o greitis privačiai buvo didesnis nei libboarde. Atrodo, kad duomenys buvo prastai stratifikuoti (arba, pavyzdžiui, privačiame tinkle nebuvo eilučių su neigiamu svoriu), ir tai buvo šiek tiek apmaudu.
SNA Hackathon 2019 – tekstai. Pirmas lygmuo
Užduotis buvo reitinguoti vartotojų įrašus socialiniame tinkle Odnoklassniki pagal juose esantį tekstą; be teksto, buvo dar keletas įrašo savybių (kalba, savininkas, sukūrimo data ir laikas, peržiūros data ir laikas ).
Kaip klasikinį požiūrį į darbą su tekstu, norėčiau pabrėžti dvi galimybes:
- Kiekvieno žodžio atvaizdavimas į n dimensijų vektorių erdvę taip, kad panašūs žodžiai turėtų panašius vektorius (daugiau skaitykite ), tada suraskite vidutinį teksto žodį arba naudodami mechanizmus, kurie atsižvelgia į santykinę žodžių padėtį (CNN, LSTM/GRU).
- Naudoti modelius, kurie gali iš karto dirbti su visais sakiniais. Pavyzdžiui, Bertas. Teoriškai šis metodas turėtų veikti geriau.
Kadangi tai buvo mano pirmoji patirtis su tekstais, būtų neteisinga ką nors mokyti, todėl mokysiuos pati. Štai patarimus, kuriuos sau duočiau konkurso pradžioje:
- Prieš bėgdami ko nors mokyti, pažiūrėkite į duomenis! Be paties teksto, duomenys turėjo keletą stulpelių ir iš jų buvo galima išspausti daug daugiau nei aš. Paprasčiausias dalykas yra padaryti kai kurių stulpelių tikslinę kodavimą.
- Nesimokyk iš visų duomenų! Duomenų buvo daug (apie 17 mln. eilučių) ir visiškai nebūtina jų visų naudoti hipotezėms tikrinti. Mokymas ir išankstinis apdorojimas buvo gana lėtas, ir, žinoma, būčiau turėjęs laiko patikrinti įdomesnes hipotezes.
- <Prieštaringas patarimas> Nereikia ieškoti žudiko modelio. Ilgai sugalvojau Elmo ir Bertą, tikėdamasis, kad jie tuoj pat iškels mane į aukštą vietą, todėl panaudojau „FastText“ iš anksto paruoštus rusų kalbai skirtus įterpimus. Su Elmo negalėjau pasiekti geresnio greičio, o su Bertu vis tiek neturėjau laiko to išsiaiškinti.
- <Prieštaringas patarimas> Nereikia ieškoti vienos žudikės funkcijos. Žvelgdamas į duomenis pastebėjau, kad maždaug 1 procente tekstų iš tikrųjų nėra teksto! Tačiau buvo nuorodų į kai kuriuos išteklius, ir aš parašiau paprastą analizatorių, kuris atidarė svetainę ir ištraukia pavadinimą bei aprašymą. Atrodė, kad tai gera mintis, bet tada aš užsimaniau ir nusprendžiau išanalizuoti visas visų tekstų nuorodas ir vėl praradau daug laiko. Visa tai nesuteikė reikšmingo galutinio rezultato pagerėjimo (nors, pavyzdžiui, supratau, kad jis yra susijęs).
- Klasikinės funkcijos veikia. Mes Google, pavyzdžiui, „text features kaggle“, skaitome ir pridedame viską. TF-IDF patobulino, kaip ir statistinės funkcijos, tokios kaip teksto ilgis, žodžiai ir skyrybos ženklų kiekis.
- Jei yra DateTime stulpelių, verta juos išanalizuoti į kelias atskiras funkcijas (valandas, savaitės dienas ir kt.). Kurias savybes reikėtų paryškinti, reikėtų analizuoti naudojant grafikus/kai kurias metrikas. Čia pagal užgaidą viską padariau teisingai ir išryškinau reikiamas ypatybes, bet normali analizė nepakenktų (pavyzdžiui, kaip padarėme finale).
Varžybų rezultatas – vieną kero modelį apmokiau su žodžio vingiavimu, o kitą – LSTM ir GRU pagrindu. Abu jie naudojo iš anksto paruoštus „FastText“ įterpimus rusų kalbai (išbandžiau daugybę kitų įterpimų, bet šie veikė geriausiai). Suvidurkinus prognozes užėmiau galutinę 7 vietą iš 76 dalyvių.
Po pirmojo etapo jis buvo paskelbtas , kuris užėmė antrąją vietą (dalyvavo ne konkurso), o jo sprendimas iki kurio nors etapo pakartojo manąjį, tačiau jis nuėjo toliau dėl užklausos-rakto-vertės dėmesio mechanizmo.
Antrasis etapas OK & IDAO
Antrieji varžybų etapai vyko beveik iš eilės, todėl nusprendžiau juos apžiūrėti kartu.
Pirmiausia aš ir naujai įsigyta komanda atsidūrėme įspūdingame Mail.ru įmonės biure, kur mūsų užduotis buvo sujungti trijų pirmojo etapo takelių modelius – tekstą, paveikslėlius ir bendradarbiavimą. Tam buvo skirtos kiek daugiau nei 2 dienos, kurių pasirodė labai mažai. Tiesą sakant, mes galėjome pakartoti savo rezultatus tik nuo pirmojo etapo, negaudami jokios naudos iš susijungimo. Galiausiai užėmėme 5 vietą, bet negalėjome panaudoti tekstinio modelio. Pažvelgus į kitų dalyvių sprendimus, atrodo, kad vertėjo pabandyti tekstus sugrupuoti ir įtraukti į kolabo modelį. Šalutinis šio etapo poveikis buvo nauji įspūdžiai, susitikimai ir bendravimas su šauniais dalyviais ir organizatoriais, taip pat didelis miego trūkumas, kuris galėjo turėti įtakos paskutinio IDAO etapo rezultatui.
IDAO 2019 finalinio etapo užduotis buvo numatyti, kiek laiko laukti užsakymo Yandex taksi vairuotojams oro uoste. 2 etape buvo nustatytos 3 užduotys = 3 oro uostai. Kiekvienam oro uostui pateikiami minutės duomenys apie taksi užsakymų skaičių per šešis mėnesius. Ir kaip bandymo duomenys buvo pateikti kito mėnesio ir minutės duomenys apie pastarųjų 2 savaičių užsakymus. Laiko buvo mažai (1,5 dienos), užduotis buvo gana konkreti, į konkursą atėjo tik vienas žmogus iš komandos - dėl to į pabaigą tai buvo liūdna vieta. Įdomios idėjos apėmė bandymus panaudoti išorinius duomenis: orus, kamščius ir „Yandex“ taksi užsakymų statistiką. Nors organizatoriai nesakė, kokie tai oro uostai, daugelis dalyvių manė, kad tai Šeremetjevo, Domodedovo ir Vnukovo oro uostai. Nors po varžybų ši prielaida buvo paneigta, ypatybės, pavyzdžiui, iš Maskvos orų duomenų pagerino rezultatus tiek patvirtinant, tiek pirmaujančiųjų sąraše.
išvada
- ML varžybos šaunios ir įdomios! Čia rasite duomenų analizės, gudrių modelių ir technikų įgūdžių panaudojimą, sveikintinas tiesiog sveikas protas.
- ML jau yra didžiulis žinių bagažas, kuris, atrodo, auga eksponentiškai. Išsikėliau sau tikslą susipažinti su įvairiomis sritimis (signalai, paveikslėliai, lentelės, tekstas) ir jau supratau, kiek daug reikia mokytis. Pavyzdžiui, po šių konkursų nusprendžiau studijuoti: klasterizacijos algoritmus, pažangias technologijas dirbant su gradiento didinimo bibliotekomis (ypač dirbant su CatBoost GPU), kapsulinius tinklus, užklausos-rakto-vertės dėmesio mechanizmą.
- Ne vien kaggle! Yra daug kitų konkursų, kuriuose lengviau gauti bent marškinėlius, o daugiau šansų į kitus prizus.
- Bendrauti! Jau dabar yra didelė bendruomenė mašininio mokymosi ir duomenų analizės srityje, yra teminės grupės telegramoje, slack, o rimti žmonės iš Mail.ru, Yandex ir kitų kompanijų atsako į klausimus ir padeda pradedantiesiems ir tęsiantiems savo kelią šioje srityje. žinių.
- Visiems, kuriuos įkvėpė ankstesnis taškas, patariu apsilankyti — didelė nemokama konferencija Maskvoje, kuri vyks gegužės 10-11 d.
Šaltinis: www.habr.com