For å fortsette temaet for maskinlæringskonkurranser på Habré, vil vi gjerne introdusere leserne for ytterligere to plattformer. De er absolutt ikke så store som kaggle, men de fortjener definitivt oppmerksomhet.

Personlig liker jeg ikke kaggle for mye av flere grunner:

• for det første varer konkurranser der ofte i flere måneder, og aktiv deltakelse krever mye innsats;
• for det andre offentlige kjerner (offentlige løsninger). Kaggle-tilhengere anbefaler å behandle dem med roen til tibetanske munker, men i virkeligheten er det ganske synd når noe du har jobbet mot i en måned eller to plutselig viser seg å være lagt ut på et sølvfat for alle.

Heldigvis arrangeres maskinlæringskonkurranser på andre plattformer, og et par av disse konkurransene vil bli diskutert.

IDAO	SNA Hackathon 2019
Offisielt språk: engelsk, arrangører: Yandex, Sberbank, HMS	Offisielt russisk språk, arrangører: Mail.ru Group
Online-runde: 15. januar – 11. februar 2019; Finale på stedet: 4.–6. april 2019	online - fra 7. februar til 15. mars; offline – fra 30. mars til 1. april.
Ved å bruke et visst sett med data om en partikkel i Large Hadron Collider (bane, momentum og andre ganske komplekse fysiske parametere), avgjør om det er en myon eller ikke Fra denne uttalelsen ble det identifisert 2 oppgaver: — i en måtte du bare sende spådommen din, - og i den andre - den komplette koden og modellen for prediksjon, og utførelsen var underlagt ganske strenge restriksjoner på kjøretid og minnebruk	For SNA Hackathon-konkurransen ble det samlet inn logger over innholdsvisninger fra åpne grupper i brukernyhetsfeeds for februar-mars 2018. Testsettet inneholder den siste halvannen uken av mars. Hver oppføring i loggen inneholder informasjon om hva som ble vist og til hvem, samt hvordan brukeren reagerte på dette innholdet: vurderte det, kommenterte, ignorerte det eller skjulte det fra feeden. Essensen av SNA Hackathons oppgaver er å rangere hver bruker av det sosiale nettverket Odnoklassniki feeden hans, og heve så høyt som mulig de innleggene som vil motta en "klasse". På nettstadiet ble oppgaven delt inn i 3 deler: 1. rangere stillinger i henhold til ulike samarbeidsegenskaper 2. ranger innlegg basert på bildene de inneholder 3. ranger innlegg i henhold til teksten de inneholder
Kompleks tilpasset beregning, noe sånt som ROC-AUC	Gjennomsnittlig ROC-AUC etter bruker
Premier for første etappe - T-skjorter for N plasser, overgang til andre etappe, hvor overnatting og måltider ble betalt under konkurransen Andre fase - ??? (Av visse grunner var jeg ikke til stede ved prisutdelingen og klarte ikke å finne ut hva premiene var til slutt). De lovet bærbare datamaskiner til alle medlemmer av vinnerlaget	Premier for første etappe - T-skjorter for de 100 beste deltakerne, passasje til andre etappe, hvor reise til Moskva, overnatting og måltider under konkurransen ble betalt. Mot slutten av første etappe ble det også annonsert premier for de beste i 3 oppgaver på trinn 1: alle vant et RTX 2080 TI-skjermkort! Den andre etappen var en teametappe, lagene besto av 2 til 5 personer, premier: 1. plass - 300 000 rubler 2. plass - 200 000 rubler 3. plass - 100 000 rubler jurypris - 100 000 rubler
Offisiell telegramgruppe, ~190 deltakere, kommunikasjon på engelsk, spørsmål måtte vente flere dager på svar	Offisiell gruppe i telegram, ~1500 deltakere, aktiv diskusjon av oppgaver mellom deltakere og arrangører
Arrangørene leverte to grunnleggende løsninger, enkle og avanserte. Enkel krevde mindre enn 16 GB RAM, og avansert minne passet ikke inn i 16. Samtidig, ser man litt fremover, klarte ikke deltakerne å utkonkurrere den avanserte løsningen nevneverdig. Det var ingen vanskeligheter med å lansere disse løsningene. Det skal bemerkes at i det avanserte eksemplet var det en kommentar med et hint om hvor man kan begynne å forbedre løsningen.	Det ble gitt grunnleggende primitive løsninger for hver av oppgavene, som enkelt ble overgått av deltakerne. I de første dagene av konkurransen møtte deltakerne flere vanskeligheter: For det første ble dataene gitt i Apache Parkett-format, og ikke alle kombinasjoner av Python og parkettpakken fungerte uten feil. Den andre vanskeligheten var å laste ned bilder fra e-postskyen; for øyeblikket er det ingen enkel måte å laste ned en stor mengde data på en gang. Som et resultat forsinket disse problemene deltakerne i et par dager.

IDAO. Første etappe

Oppgaven var å klassifisere myon/ikke-myon-partikler etter deres egenskaper. Nøkkeltrekket ved denne oppgaven var tilstedeværelsen av en vektkolonne i treningsdataene, som arrangørene selv tolket som tillit til svaret for denne linjen. Problemet var at ganske mange rader inneholdt negative vekter.

Etter å ha tenkt noen minutter på linjen med hintet (hintet trakk rett og slett oppmerksomheten til denne funksjonen i vektkolonnen) og bygget denne grafen, bestemte vi oss for å sjekke 3 alternativer:

1) inverter målet for linjer med negative vekter (og vekter deretter)
2) flytt vektene til minimumsverdien slik at de starter fra 0
3) ikke bruk strengvekter

Det tredje alternativet viste seg å være det dårligste, men de to første forbedret resultatet, det beste var alternativ nr. 1, som umiddelbart brakte oss til nåværende andreplass i første oppgave og først i andre.

Vårt neste skritt var å gå gjennom dataene for manglende verdier. Arrangørene ga oss allerede kjemmede data, hvor det manglet en del verdier, og de ble erstattet av -9999.

Vi fant manglende verdier i kolonnene MatchedHit_{X,Y,Z}[N] og MatchedHit_D{X,Y,Z}[N], og bare når N=2 eller 3. Som vi forstår, gjorde ikke noen partikler det passere alle 4 detektorene, og stoppet enten på 3. eller 4. plate. Dataene inneholdt også Lextra_{X,Y}[N]-kolonner, som tilsynelatende beskriver det samme som MatchedHit_{X,Y,Z}[N], men med en slags ekstrapolering. Disse magre gjetningene antydet at Lextra_{X,Y}[N] kunne erstattes av de manglende verdiene i MatchedHit_{X,Y,Z}[N] (kun for X- og Y-koordinater). MatchedHit_Z[N] var godt fylt med medianen. Disse manipulasjonene tillot oss å nå 1. mellomplass i begge oppgavene.

Med tanke på at de ikke ga noe for å vinne den første etappen, kunne vi ha stoppet der, men vi fortsatte, tegnet noen vakre bilder og kom opp med nye funksjoner.

For eksempel fant vi at hvis vi plotter skjæringspunktene til en partikkel med hver av de fire detektorplatene, kan vi se at punktene på hver av platene er gruppert i 5 rektangler med et sideforhold på 4 til 5 og sentrert ved punktet (0,0), og i Det er ingen punkter i det første rektangelet.

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

Etter å ha bestemt disse dimensjonene, la vi til 4 nye kategoriske funksjoner for hver partikkel - nummeret på rektangelet der den skjærer hver plate.

Vi la også merke til at partiklene så ut til å spre seg til sidene fra midten, og ideen oppsto om å på en eller annen måte evaluere "kvaliteten" på denne spredningen. Ideelt sett ville det sannsynligvis vært mulig å komme opp med en slags "ideell" parabel avhengig av startpunktet og estimere avviket fra det, men vi begrenset oss til den "ideelle" rette linjen. Etter å ha konstruert slike ideelle rette linjer for hvert inngangspunkt, var vi i stand til å beregne standardavviket til banen til hver partikkel fra denne rette linjen. Siden gjennomsnittlig avvik for mål = 1 var 152, og for mål = 0 var det 390, vurderte vi tentativt denne funksjonen som god. Og faktisk kom denne funksjonen umiddelbart til toppen av de mest nyttige.

Vi var glade og la til avviket til alle 4 skjæringspunktene for hver partikkel fra den ideelle rette linjen som ytterligere 4 funksjoner (og de fungerte også bra).

Lenker til vitenskapelige artikler om temaet for konkurransen, gitt til oss av arrangørene, fikk ideen om at vi er langt fra de første til å løse dette problemet, og kanskje det er en slags spesialisert programvare. Etter å ha oppdaget et depot på github hvor metodene IsMuonSimple, IsMuon, IsMuonLoose ble implementert, overførte vi dem til nettstedet vårt med mindre modifikasjoner. Metodene i seg selv var veldig enkle: for eksempel hvis energien er mindre enn en viss terskel, så er det ikke en myon, ellers er det en myon. Slike enkle funksjoner kunne åpenbart ikke gi en økning i tilfelle bruk av gradientforsterkning, så vi la til en annen betydelig "avstand" til terskelen. Disse funksjonene har også blitt litt forbedret. Kanskje, ved å analysere eksisterende metoder mer grundig, var det mulig å finne sterkere metoder og legge dem til skiltene.

På slutten av konkurransen finjusterte vi litt den "raske" løsningen for det andre problemet; til slutt skilte den seg fra grunnlinjen på følgende punkter:

1. I rader med negativ vekt ble målet snudd
2. Fyll ut manglende verdier i MatchedHit_{X,Y,Z}[N]
3. Redusert dybde til 7
4. Redusert læringsraten til 0.1 (var 0.19)

Som et resultat prøvde vi flere funksjoner (ikke særlig vellykket), valgte parametere og trent catboost, lightgbm og xgboost, prøvde forskjellige blandinger av spådommer, og før vi åpnet den private vant vi selvsikkert på den andre oppgaven, og på den første var vi blant de ledere.

Etter å ha åpnet privaten var vi på 10. plass for 1. oppgave og 3. for andre. Alle lederne ble blandet sammen, og farten privat var høyere enn på libboardet. Det ser ut til at dataene var dårlig stratifisert (eller for eksempel at det ikke var noen rader med negativ vekt i privaten) og dette var litt frustrerende.

SNA Hackathon 2019 - Tekster. Første etappe

Oppgaven var å rangere brukerinnlegg på det sosiale nettverket Odnoklassniki basert på teksten de inneholdt; i tillegg til teksten var det noen flere kjennetegn ved innlegget (språk, eier, dato og klokkeslett for opprettelse, dato og klokkeslett for visning ).

Som klassiske tilnærminger til å jobbe med tekst, vil jeg fremheve to alternativer:

1. Kartlegge hvert ord til et n-dimensjonalt vektorrom slik at lignende ord har lignende vektorer (les mer i vår artikkel), deretter enten å finne gjennomsnittsordet for teksten eller bruke mekanismer som tar hensyn til den relative plasseringen til ordene (CNN, LSTM/GRU).
2. Bruke modeller som umiddelbart kan fungere med hele setninger. For eksempel Bert. I teorien burde denne tilnærmingen fungere bedre.

Siden dette var min første erfaring med tekster, ville det være feil å lære noen, så jeg skal lære meg selv. Dette er tipsene jeg ville gitt meg selv i begynnelsen av konkurransen:

1. Før du løper for å lære noe, se på dataene! I tillegg til selve teksten hadde dataene flere kolonner og det var mulig å presse ut mye mer fra dem enn jeg gjorde. Det enkleste er å gjøre gjennomsnittlig målkoding for noen av kolonnene.
2. Ikke lær av alle dataene! Det var mye data (ca. 17 millioner rader) og det var absolutt ikke nødvendig å bruke alle for å teste hypoteser. Trening og forbehandling gikk ganske tregt, og jeg ville åpenbart hatt tid til å teste flere interessante hypoteser.
3. <Kontroversielle råd> Du trenger ikke å lete etter en mordermodell. Jeg brukte lang tid på å finne ut Elmo og Bert, i håp om at de umiddelbart ville ta meg til et høyt sted, og som et resultat brukte jeg FastText forhåndstrente innbygginger for det russiske språket. Jeg kunne ikke oppnå bedre fart med Elmo, og jeg hadde fortsatt ikke tid til å finne ut av det med Bert.
4. <Kontroversielle råd> Du trenger ikke å lete etter en morder funksjon. Når jeg så på dataene, la jeg merke til at rundt 1 prosent av tekstene faktisk ikke inneholder tekst! Men det var lenker til noen ressurser, og jeg skrev en enkel parser som åpnet siden og trakk ut tittelen og beskrivelsen. Det virket som en god idé, men så ble jeg revet med og bestemte meg for å analysere alle lenkene til alle tekstene og mistet igjen mye tid. Alt dette ga ingen vesentlig forbedring i sluttresultatet (selv om jeg for eksempel fant ut stemming).
5. Klassiske funksjoner fungerer. Vi Googler for eksempel «tekstfunksjoner kaggle», leser og legger til alt. TF-IDF ga en forbedring, det samme gjorde statistiske funksjoner som tekstlengde, ord og mengden tegnsetting.
6. Hvis det er DateTime-kolonner, er det verdt å analysere dem i flere separate funksjoner (timer, ukedager osv.). Hvilke funksjoner som skal fremheves bør analyseres ved hjelp av grafer/noen beregninger. Her, på et innfall, gjorde jeg alt riktig og fremhevet de nødvendige funksjonene, men en normal analyse ville ikke ha skadet (for eksempel som vi gjorde i finalen).

Som et resultat av konkurransen trente jeg en keras-modell med ordfolding, og en annen basert på LSTM og GRU. Begge brukte ferdigtrente FastText-innbygginger for det russiske språket (jeg prøvde en rekke andre innbygginger, men det var disse som fungerte best). Etter å ha snittet spådommene, tok jeg den endelige 7. plassen av 76 deltakere.

Etter den første fasen ble den publisert artikkel av Nikolai Anokhin, som tok andreplassen (han deltok utenfor konkurransen), og løsningen hans opp til et eller annet stadium gjentok min, men han gikk videre på grunn av søke-nøkkel-verdi oppmerksomhetsmekanismen.

Andre trinn OK & IDAO

De andre stadiene av konkurransene fant sted nesten fortløpende, så jeg bestemte meg for å se på dem sammen.

Først havnet jeg og det nyervervede teamet på det imponerende kontoret til Mail.ru-selskapet, der vår oppgave var å kombinere modellene til tre spor fra første trinn - tekst, bilder og samarbeid. Det ble satt av litt mer enn 2 dager til dette, noe som viste seg å være svært lite. Faktisk var vi bare i stand til å gjenta resultatene våre fra første fase uten å få noen gevinster fra fusjonen. Til slutt tok vi 5. plass, men vi klarte ikke å bruke tekstmodellen. Etter å ha sett på løsningene til andre deltakere, ser det ut til at det var verdt å prøve å gruppere tekstene og legge dem til samarbeidsmodellen. En bieffekt av dette stadiet var nye inntrykk, møte og kommunikasjon med kule deltakere og arrangører, samt alvorlig mangel på søvn, som kan ha påvirket resultatet av sluttfasen av IDAO.

Oppgaven på IDAO 2019 Final fasen var å forutsi ventetiden for en ordre for Yandex taxisjåfører på flyplassen. På trinn 2 ble 3 oppgaver = 3 flyplasser identifisert. For hver flyplass er det gitt minutt-for-minutt-data om antall drosjebestillinger for seks måneder. Og som testdata ble neste måned og minutt-for-minutt-data om bestillinger for de siste 2 ukene gitt. Det ble lite tid (1,5 dager), oppgaven var ganske spesifikk, kun én person fra laget kom til konkurransen – og som et resultat ble det en trist plass mot slutten. Interessante ideer inkluderte forsøk på å bruke eksterne data: vær, trafikkork og Yandex taxibestillingsstatistikk. Selv om arrangørene ikke sa hva disse flyplassene var, antok mange deltakere at de var Sheremetyevo, Domodedovo og Vnukovo. Selv om denne antagelsen ble tilbakevist etter konkurransen, forbedret funksjoner, for eksempel fra Moskva værdata, resultatene både på validering og på ledertavlen.

Konklusjon

1. ML-konkurranser er kule og interessante! Her finner du bruk av ferdigheter innen dataanalyse, og i snedige modeller og teknikker, og rett og slett sunn fornuft er velkommen.
2. ML er allerede en enorm kunnskapsmengde som ser ut til å vokse eksponentielt. Jeg satte meg som mål å sette meg inn i ulike områder (signaler, bilder, tabeller, tekst) og skjønte allerede hvor mye det er å studere. For eksempel, etter disse konkurransene bestemte jeg meg for å studere: klyngealgoritmer, avanserte teknikker for å jobbe med gradientforsterkende biblioteker (spesielt arbeid med CatBoost på GPU), kapselnettverk, søke-nøkkel-verdi oppmerksomhetsmekanismen.
3. Ikke med kaggle alene! Det er mange andre konkurranser hvor det er lettere å få minst en T-skjorte, og det er flere sjanser for andre premier.
4. Kommunisere! Det er allerede et stort fellesskap innen maskinlæring og dataanalyse, det er tematiske grupper innen telegram, slakk og seriøse personer fra Mail.ru, Yandex og andre selskaper svarer på spørsmål og hjelper nybegynnere og de som fortsetter sin vei på dette feltet av kunnskap.
5. Jeg anbefaler alle som ble inspirert av forrige punkt å besøke datafest — en stor gratiskonferanse i Moskva, som finner sted 10.-11. mai.

Kilde: www.habr.com