Voortbouwend op het thema van machine learning-wedstrijden op Habré, willen we lezers kennis laten maken met nog twee platforms. Ze zijn zeker niet zo groot als Kaggle, maar verdienen zeker aandacht.

Persoonlijk hou ik niet zo van Kaggle om verschillende redenen:

• ten eerste duren de competities daar vaak meerdere maanden, en actieve deelname vergt veel inspanning;
• ten tweede publieke kernels (publieke oplossingen). Kaggle-aanhangers adviseren hen te behandelen met de kalmte van Tibetaanse monniken, maar in werkelijkheid is het best zonde als iets waar je al een maand of twee naartoe werkt, ineens voor iedereen op een presenteerblaadje op een presenteerblaadje blijkt te liggen.

Gelukkig worden er op andere platforms machine learning-wedstrijden gehouden en zullen een aantal van deze wedstrijden worden besproken.

IDAO	SNA-hackathon 2019
Officiële taal: Engels, organisatoren: Yandex, Sberbank, HSE	Officiële Russische taal, organisatoren: Mail.ru Group
Onlineronde: 15 januari — 11 februari 2019; Finale ter plaatse: 4-6 april 2019	online - van 7 februari tot 15 maart; offline - van 30 maart tot 1 april.
Gebruik een bepaalde set gegevens over een deeltje in de Large Hadron Collider (traject, momentum en andere tamelijk complexe fysieke parameters) om te bepalen of het een muon is of niet Uit deze verklaring werden 2 taken geïdentificeerd: – in één hoefde je alleen maar je voorspelling te versturen, - en in de andere - de volledige code en het model voor voorspelling, en de uitvoering was onderworpen aan vrij strikte beperkingen op het gebied van looptijd en geheugengebruik	Voor de SNA Hackathon-wedstrijd zijn logboeken verzameld van inhoudsweergaven van open groepen in gebruikersnieuwsfeeds voor februari-maart 2018. De testset bevat de laatste anderhalve week van maart. Elke vermelding in het logboek bevat informatie over wat er werd getoond en aan wie, evenals hoe de gebruiker op deze inhoud reageerde: beoordeelde het, gaf commentaar, negeerde het of verborg het in de feed. De essentie van de taken van de SNA Hackathon is om elke gebruiker van het sociale netwerk Odnoklassniki in zijn feed te rangschikken, waarbij de berichten die een "klasse" zullen krijgen, zo hoog mogelijk worden geplaatst. In de online fase was de taak verdeeld in 3 delen: 1. rangschik berichten op basis van verschillende samenwerkingskenmerken 2. rangschik berichten op basis van de afbeeldingen die ze bevatten 3. rangschik berichten op basis van de tekst die ze bevatten
Complexe aangepaste statistiek, zoiets als ROC-AUC	Gemiddelde ROC-AUC per gebruiker
Prijzen voor de eerste etappe - T-shirts voor N plaatsen, doorgang naar de tweede etappe, waar accommodatie en maaltijden werden betaald tijdens de competitie Tweede fase - ??? (Om bepaalde redenen was ik niet aanwezig bij de prijsuitreiking en kon ik uiteindelijk niet achterhalen wat de prijzen waren). Ze beloofden laptops aan alle leden van het winnende team	Prijzen voor de eerste etappe - T-shirts voor de 100 beste deelnemers, doorgang naar de tweede etappe, waar reizen naar Moskou, accommodatie en maaltijden tijdens de competitie werden betaald. Ook werden er tegen het einde van de eerste fase prijzen bekendgemaakt voor de beste in 3 taken in fase 1: iedereen won een RTX 2080 TI-videokaart! De tweede etappe was een teamfase, teams bestonden uit 2 tot 5 personen, prijzen: 1e plaats - 300 roebel 2e plaats - 200 roebel 3e plaats - 100 roebel juryprijs - 100 roebel
Officiële telegramgroep, ~190 deelnemers, communicatie in het Engels, vragen moesten enkele dagen wachten op antwoord	Officiële groep in telegram, ~1500 deelnemers, actieve taakbespreking tussen deelnemers en organisatoren
De organisatoren zorgden voor twee basisoplossingen: eenvoudig en geavanceerd. Simple vereiste minder dan 16 GB RAM, en geavanceerd geheugen paste niet in 16. Tegelijkertijd konden de deelnemers, een beetje vooruitkijkend, niet significant beter presteren dan de geavanceerde oplossing. Er waren geen problemen bij het lanceren van deze oplossingen. Opgemerkt moet worden dat er in het geavanceerde voorbeeld een opmerking was met een hint over waar te beginnen met het verbeteren van de oplossing.	Voor elk van de taken werden primitieve basisoplossingen aangereikt, die gemakkelijk door de deelnemers konden worden overtroffen. In de begindagen van de wedstrijd stuitten de deelnemers op verschillende problemen: ten eerste werden de gegevens in het Apache Parquet-formaat gegeven en werkten niet alle combinaties van Python en het parketpakket foutloos. De tweede moeilijkheid was het downloaden van afbeeldingen uit de mailwolk; op dit moment is er geen gemakkelijke manier om een ​​grote hoeveelheid gegevens in één keer te downloaden. Als gevolg hiervan vertraagden deze problemen de deelnemers een paar dagen.

IDAO. Eerste fase

De taak was om muon-/niet-muondeeltjes te classificeren op basis van hun kenmerken. Het belangrijkste kenmerk van deze taak was de aanwezigheid van een gewichtskolom in de trainingsgegevens, die de organisatoren zelf interpreteerden als vertrouwen in het antwoord voor deze lijn. Het probleem was dat nogal wat rijen negatieve gewichten bevatten.

Nadat we een paar minuten hadden nagedacht over de lijn met de hint (de hint vestigde simpelweg de aandacht op dit kenmerk van de gewichtskolom) en deze grafiek hadden gemaakt, besloten we drie opties aan te vinken:

1) het doel van lijnen met negatieve gewichten omkeren (en dienovereenkomstig wegen)
2) verschuif de gewichten naar de minimumwaarde, zodat ze vanaf 0 beginnen
3) Gebruik geen snaargewichten

De derde optie bleek de slechtste, maar de eerste twee verbeterden het resultaat, de beste was optie nr. 1, die ons meteen naar de huidige tweede plaats bracht in de eerste taak en eerste in de tweede.

Onze volgende stap was het controleren van de gegevens op ontbrekende waarden. De organisatoren gaven ons al uitgekamde gegevens, waar nogal wat ontbrekende waarden waren, en deze werden vervangen door -9999.

We hebben ontbrekende waarden gevonden in de kolommen MatchedHit_{X,Y,Z}[N] en MatchedHit_D{X,Y,Z}[N], en alleen als N=2 of 3. Zoals we begrijpen, deden sommige deeltjes dat niet passeer alle 4 de detectoren en stopte op de 3e of 4e plaat. De gegevens bevatten ook Lexra_{X,Y}[N]-kolommen, die blijkbaar hetzelfde beschrijven als MatchedHit_{X,Y,Z}[N], maar met behulp van een soort extrapolatie. Deze magere gissingen suggereerden dat Lextra_{X,Y}[N] de ontbrekende waarden in MatchedHit_{X,Y,Z}[N] zou kunnen vervangen (alleen voor X- en Y-coördinaten). MatchedHit_Z[N] was goed gevuld met de mediaan. Dankzij deze manipulaties konden we in beide taken de eerste tussenplaats bereiken.

Aangezien ze niets hebben gegeven voor het winnen van de eerste etappe, hadden we daar kunnen stoppen, maar we zijn doorgegaan, hebben een aantal mooie foto's gemaakt en nieuwe features bedacht.

We hebben bijvoorbeeld ontdekt dat als we de snijpunten van een deeltje met elk van de vier detectorplaten uitzetten, we kunnen zien dat de punten op elk van de platen zijn gegroepeerd in vijf rechthoeken met een beeldverhouding van 5 tot 4 en gecentreerd op het punt (5), en in Er zijn geen punten in de eerste rechthoek.

Plaatnummer / rechthoekafmetingen	1	2	3	4	5
Plaat 1	500 × 625	1000 × 1250	2000 × 2500	4000 × 5000	8000 × 10000
Plaat 2	520 × 650	1040 × 1300	2080 × 2600	4160 × 5200	8320 × 10400
Plaat 3	560 × 700	1120 × 1400	2240 × 2800	4480 × 5600	8960 × 11200
Plaat 4	600 × 750	1200 × 1500	2400 × 3000	4800 × 6000	9600 × 12000

Nadat we deze afmetingen hadden bepaald, hebben we voor elk deeltje vier nieuwe categorische kenmerken toegevoegd: het nummer van de rechthoek waarin het elke plaat snijdt.

We merkten ook dat de deeltjes zich vanuit het midden naar de zijkanten leken te verspreiden en het idee ontstond om op de een of andere manier de ‘kwaliteit’ van deze verstrooiing te evalueren. Idealiter zou het waarschijnlijk mogelijk zijn om afhankelijk van het startpunt een soort ‘ideale’ parabool te bedenken en de afwijking ervan te schatten, maar we beperkten ons tot de ‘ideale’ rechte lijn. Nadat we voor elk punt van binnenkomst zulke ideale rechte lijnen hadden geconstrueerd, konden we de standaardafwijking van het traject van elk deeltje ten opzichte van deze rechte lijn berekenen. Omdat de gemiddelde afwijking voor doel = 1 152 was en voor doel = 0 390, hebben we dit kenmerk voorlopig als goed beoordeeld. En inderdaad, deze functie bereikte meteen de top van de nuttigste.

We waren opgetogen en voegden de afwijking van alle vier de snijpunten voor elk deeltje van de ideale rechte lijn toe als vier extra kenmerken (en ze werkten ook goed).

Links naar wetenschappelijke artikelen over het onderwerp van de wedstrijd, aan ons gegeven door de organisatoren, brachten het idee naar voren dat we verre van de eersten zijn die dit probleem hebben opgelost en dat er misschien een soort gespecialiseerde software bestaat. Nadat we een repository op github hadden ontdekt waar de methoden IsMuonSimple, IsMuon en IsMuonLoose waren geïmplementeerd, hebben we ze met kleine aanpassingen naar onze site overgebracht. De methoden zelf waren heel eenvoudig: als de energie bijvoorbeeld lager is dan een bepaalde drempel, dan is het geen muon, anders is het een muon. Dergelijke eenvoudige kenmerken kunnen uiteraard geen toename opleveren in het geval van het gebruik van gradiëntversterking, dus hebben we nog een significante "afstand" aan de drempel toegevoegd. Deze functies zijn ook enigszins verbeterd. Misschien was het, door de bestaande methoden grondiger te analyseren, mogelijk om sterkere methoden te vinden en deze aan de borden toe te voegen.

Aan het einde van de competitie hebben we de “snelle” oplossing voor het tweede probleem enigszins aangepast; uiteindelijk verschilde deze op de volgende punten van de basislijn:

1. In rijen met een negatief gewicht werd het doel omgekeerd
2. Ontbrekende waarden ingevuld in MatchedHit_{X,Y,Z}[N]
3. Diepte teruggebracht tot 7
4. Verlaagd leerpercentage naar 0.1 (was 0.19)

Als gevolg hiervan hebben we meer functies geprobeerd (niet erg succesvol), parameters geselecteerd en catboost, lightgbm en xgboost getraind, verschillende combinaties van voorspellingen geprobeerd en voordat we de privé openden, wonnen we vol vertrouwen bij de tweede taak, en bij de eerste behoorden we tot de leiders.

Na het openen van de privé stonden we op de 10e plaats voor de 1e taak en 3e voor de tweede. Alle leiders raakten door de war en de snelheid privé was hoger dan op het libboard. Het lijkt erop dat de gegevens slecht gestratificeerd waren (of er waren bijvoorbeeld geen rijen met negatieve gewichten in de privémodus) en dit was een beetje frustrerend.

SNA Hackathon 2019 - Teksten. Eerste fase

De taak was om gebruikersposts op het sociale netwerk Odnoklassniki te rangschikken op basis van de tekst die ze bevatten; naast de tekst waren er nog een paar kenmerken van de post (taal, eigenaar, datum en tijd van creatie, datum en tijd van weergave ).

Als klassieke benadering van het werken met tekst zou ik twee opties willen benadrukken:

1. Elk woord in een n-dimensionale vectorruimte in kaart brengen, zodat vergelijkbare woorden vergelijkbare vectoren hebben (lees meer in ons artikel), en vervolgens het gemiddelde woord voor de tekst vinden of mechanismen gebruiken die rekening houden met de relatieve positie van woorden (CNN, LSTM/GRU).
2. Met behulp van modellen die direct met hele zinnen kunnen werken. Bert bijvoorbeeld. In theorie zou deze aanpak beter moeten werken.

Omdat dit mijn eerste ervaring met teksten was, zou het verkeerd zijn om iemand les te geven, dus zal ik het mezelf leren. Dit zijn de tips die ik mezelf zou geven aan het begin van de wedstrijd:

1. Voordat je iets gaat leren, kijk naar de gegevens! Naast de tekst zelf hadden de gegevens verschillende kolommen en was het mogelijk om er veel meer uit te persen dan ik. Het eenvoudigste is om voor sommige kolommen gemiddelde doelcodering te gebruiken.
2. Leer niet van alle data! Er waren veel gegevens (ongeveer 17 miljoen rijen) en het was absoluut niet nodig om ze allemaal te gebruiken om hypothesen te testen. De training en voorbewerking verliepen vrij traag, en ik had uiteraard de tijd gehad om interessantere hypothesen te testen.
3. <Controversieel advies> Je hoeft niet op zoek te gaan naar een geweldig model. Ik heb veel tijd besteed aan het uitzoeken van Elmo en Bert, in de hoop dat ze me onmiddellijk naar een hoge plaats zouden brengen, en als resultaat gebruikte ik vooraf getrainde FastText-insluitingen voor de Russische taal. Met Elmo kon ik geen betere snelheid bereiken, en met Bert had ik nog steeds geen tijd om daar achter te komen.
4. <Controversieel advies> U hoeft niet naar één geweldige functie te zoeken. Kijkend naar de data viel het mij op dat ongeveer 1 procent van de teksten eigenlijk geen tekst bevat! Maar er waren links naar bepaalde bronnen, en ik schreef een eenvoudige parser die de site opende en de titel en beschrijving eruit haalde. Het leek een goed idee, maar toen liet ik me meeslepen en besloot alle links voor alle teksten te analyseren, waardoor ik opnieuw veel tijd verloor. Dit alles leverde geen noemenswaardige verbetering op in het eindresultaat (hoewel ik bijvoorbeeld wel bedacht dat er sprake was van stammen).
5. Klassieke functies werken. Wij Googlen bijvoorbeeld “tekstkenmerken kaggle”, lezen en voegen alles toe. TF-IDF zorgde voor een verbetering, evenals statistische kenmerken zoals tekstlengte, woorden en de hoeveelheid interpunctie.
6. Als er DateTime-kolommen zijn, is het de moeite waard deze in verschillende afzonderlijke functies te ontleden (uren, dagen van de week, enz.). Welke kenmerken moeten worden benadrukt, moeten worden geanalyseerd met behulp van grafieken/enkele statistieken. Hier deed ik in een opwelling alles correct en benadrukte ik de noodzakelijke kenmerken, maar een normale analyse zou geen pijn hebben gedaan (bijvoorbeeld zoals we deden bij de finale).

Als resultaat van de wedstrijd heb ik één Keras-model getraind met woordconvolutie, en een ander gebaseerd op LSTM en GRU. Beiden gebruikten vooraf getrainde FastText-insluitingen voor de Russische taal (ik heb een aantal andere insluitingen geprobeerd, maar deze werkten het beste). Na het middelen van de voorspellingen behaalde ik de uiteindelijke 7e plaats van de 76 deelnemers.

Na de eerste fase werd het gepubliceerd artikel van Nikolaj Anokhin, die de tweede plaats behaalde (hij deed mee buiten competitie), en zijn oplossing herhaalde tot op zekere hoogte de mijne, maar hij ging verder dankzij het aandachtsmechanisme van de vraag-sleutel-waarde.

Tweede fase OK & IDAO

De tweede etappes van de competities vonden vrijwel opeenvolgend plaats, dus besloot ik ze samen te bekijken.

Eerst kwamen ik en het nieuw verworven team terecht in het indrukwekkende kantoor van het bedrijf Mail.ru, waar het onze taak was om de modellen van drie nummers uit de eerste fase te combineren: tekst, afbeeldingen en samenwerking. Hiervoor werd iets meer dan 2 dagen uitgetrokken, wat erg weinig bleek te zijn. In feite konden we onze resultaten uit de eerste fase alleen maar herhalen zonder enige winst uit de fusie te behalen. Uiteindelijk behaalden we de 5e plaats, maar we konden het tekstmodel niet gebruiken. Na naar de oplossingen van andere deelnemers te hebben gekeken, lijkt het de moeite waard om te proberen de teksten te clusteren en toe te voegen aan het samenwerkingsmodel. Een neveneffect van deze fase was nieuwe indrukken, ontmoetingen en communicatie met coole deelnemers en organisatoren, evenals een ernstig slaapgebrek, wat het resultaat van de laatste fase van IDAO mogelijk heeft beïnvloed.

De taak tijdens de laatste fase van IDAO 2019 was het voorspellen van de wachttijd voor een bestelling voor Yandex-taxichauffeurs op de luchthaven. In fase 2 werden 3 taken = 3 luchthavens geïdentificeerd. Voor elke luchthaven worden van minuut tot minuut gegevens gegeven over het aantal taxibestellingen gedurende zes maanden. En als testgegevens werden de volgende maand en minuut-voor-minuut gegevens over bestellingen van de afgelopen 2 weken gegeven. Er was weinig tijd (1,5 dag), de taak was vrij specifiek, slechts één persoon van het team kwam naar de competitie - en als gevolg daarvan was het tegen het einde een trieste plek. Interessante ideeën waren onder meer pogingen om externe gegevens te gebruiken: het weer, files en statistieken voor taxibestellingen in Yandex. Hoewel de organisatoren niet zeiden wat deze luchthavens waren, gingen veel deelnemers ervan uit dat het Sheremetyevo, Domodedovo en Vnukovo waren. Hoewel deze veronderstelling na de wedstrijd werd weerlegd, verbeterden kenmerken uit bijvoorbeeld weersgegevens uit Moskou de resultaten, zowel bij de validatie als op het scorebord.

Conclusie

1. ML-wedstrijden zijn cool en interessant! Hier vindt u het gebruik van vaardigheden op het gebied van data-analyse en in sluwe modellen en technieken, en gewoon gezond verstand is welkom.
2. ML is al een enorme hoeveelheid kennis die exponentieel lijkt te groeien. Ik stelde mezelf ten doel om kennis te maken met verschillende gebieden (signalen, afbeeldingen, tabellen, tekst) en besefte al hoeveel er te studeren valt. Na deze wedstrijden besloot ik bijvoorbeeld het volgende te bestuderen: clusteralgoritmen, geavanceerde technieken voor het werken met gradiëntversterkende bibliotheken (in het bijzonder het werken met CatBoost op de GPU), capsulenetwerken, het query-sleutel-waarde-aandachtsmechanisme.
3. Niet door Kaggle alleen! Er zijn veel andere competities waarbij het gemakkelijker is om in ieder geval een T-shirt te bemachtigen, en er zijn meer kansen op andere prijzen.
4. Communiceren! Er is al een grote gemeenschap op het gebied van machine learning en data-analyse, er zijn thematische groepen in telegram, slack en serieuze mensen van Mail.ru, Yandex en andere bedrijven beantwoorden vragen en helpen beginners en degenen die hun pad op dit gebied voortzetten van kennis.
5. Ik raad iedereen die geïnspireerd is door het vorige punt aan om eens langs te gaan datafest – een grote vrije conferentie in Moskou, die van 10 tot 11 mei zal plaatsvinden.

Bron: www.habr.com