Í framhaldi af þema vélnámskeppni á Habré, viljum við kynna lesendum fyrir tveimur kerfum til viðbótar. Þeir eru vissulega ekki eins stórir og kaggle, en þeir eiga svo sannarlega skilið athygli.

Persónulega líkar mér ekki of mikið af kaggli af ýmsum ástæðum:

• í fyrsta lagi standa keppnir þar oft yfir í nokkra mánuði og virk þátttaka krefst mikillar fyrirhafnar;
• í öðru lagi opinberir kjarna (opinberar lausnir). Fylgjendur Kaggle ráðleggja að koma fram við þá af æðruleysi tíbetskra munka, en í raun er það mjög synd þegar eitthvað sem þú hefur unnið að í einn eða tvo mánuð reynist allt í einu vera sett á silfurfati fyrir alla.

Sem betur fer eru vélanámskeppnir haldnar á öðrum kerfum og verður fjallað um nokkrar af þessum keppnum.

IDAO	SNA Hackathon 2019
Opinbert tungumál: Enska, skipuleggjendur: Yandex, Sberbank, HSE	Opinber rússneska tungumál, skipuleggjendur: Mail.ru Group
Online umferð: 15. janúar - 11. febrúar, 2019; Úrslitaleikur á staðnum: 4.-6. apríl 2019	á netinu - frá 7. febrúar til 15. mars; offline - frá 30. mars til 1. apríl.
Með því að nota ákveðið safn af gögnum um ögn í Large Hadron Collider (ferill, skriðþunga og aðrar frekar flóknar eðlisfræðilegar breytur), ákvarða hvort það sé múon eða ekki Út frá þessari yfirlýsingu voru 2 verkefni auðkennd: — í einni þurftirðu bara að senda spá þína, - og í hinu - heill kóðann og líkanið fyrir spá, og framkvæmdin var háð nokkuð ströngum takmörkunum á keyrslutíma og minnisnotkun	Fyrir SNA Hackathon keppnina var safnað saman skrám yfir efni sem birtist frá opnum hópum í fréttastraumum notenda fyrir febrúar-mars 2018. Prófasettið inniheldur síðustu og hálfa vikuna í mars. Hver færsla í skránni inniheldur upplýsingar um hvað var sýnt og hverjum, svo og hvernig notandinn brást við þessu efni: gaf því einkunn, skrifaði athugasemdir, hunsaði það eða faldi það fyrir straumnum. Kjarninn í verkefnum SNA Hackathon er að raða hverjum notanda samfélagsnetsins Odnoklassniki straumnum sínum, hækka eins hátt og mögulegt er þær færslur sem fá „bekk“. Á netstigi var verkefninu skipt í 3 hluta: 1. raða stöðum eftir ýmsum samstarfseiginleikum 2. raða færslum út frá myndunum sem þær innihalda 3. raða færslum í samræmi við textann sem þau innihalda
Flókið sérsniðið mæligildi, eitthvað eins og ROC-AUC	Meðaltal ROC-AUC eftir notanda
Verðlaun fyrir fyrsta áfanga - Bolir fyrir N sæti, leið á annað þrep þar sem greitt var fyrir gistingu og fæði á meðan á keppni stóð. Annar áfangi - ??? (Af ákveðnum ástæðum var ég ekki viðstaddur verðlaunaafhendinguna og gat ekki komist að því hver verðlaunin voru að lokum). Þeir lofuðu fartölvum til allra meðlima sigurliðsins	Verðlaun fyrir fyrsta þrep - Bolir fyrir 100 bestu þátttakendur, ferð á annan áfanga þar sem greitt var fyrir ferðir til Moskvu, gisting og fæði á meðan keppnin stóð yfir. Einnig, undir lok fyrsta áfanga, voru tilkynnt um verðlaun fyrir það besta í 3 verkefnum á stigi 1: allir unnu RTX 2080 TI skjákort! Annað stig var liðakeppni, lið skipuðu 2 til 5 manns, verðlaun: 1. sæti - 300 rúblur 2. sæti - 200 rúblur 3. sæti - 100 rúblur verðlaun dómnefndar - 100 rúblur
Opinber símskeytahópur, ~190 þátttakendur, samskipti á ensku, spurningar þurftu að bíða í nokkra daga eftir svari	Opinber hópur í símskeyti, ~1500 þátttakendur, virkar umræður um verkefni milli þátttakenda og skipuleggjenda
Skipuleggjendur komu með tvær grunnlausnir, einfaldar og háþróaðar. Einfalt þurfti minna en 16 GB af vinnsluminni og háþróað minni passaði ekki inn í 16. Á sama tíma, þegar litið var aðeins fram á veginn, gátu þátttakendur ekki staðið sig verulega betur en háþróaða lausnin. Engir erfiðleikar voru við að koma þessum lausnum á markað. Það skal tekið fram að í þróaða dæminu var athugasemd með vísbendingu um hvar ætti að byrja að bæta lausnina.	Frumstæðar grunnlausnir voru gefnar fyrir hvert verkefni sem þátttakendur komust auðveldlega fram úr. Á fyrstu dögum keppninnar lentu þátttakendur í nokkrum erfiðleikum: Í fyrsta lagi voru gögnin gefin upp á Apache Parket sniði og ekki virkuðu allar samsetningar Python og parketpakkans án villna. Annað vandamálið var að hlaða niður myndum úr póstskýinu; í augnablikinu er engin auðveld leið til að hlaða niður miklu magni af gögnum í einu. Þess vegna töfðu þessi vandamál þátttakendum um nokkra daga.

IDAO. Fyrsta stig

Verkefnið var að flokka muon/non-muon agnir eftir eiginleikum þeirra. Lykilatriði þessa verkefnis var tilvist þyngdarsúlu í þjálfunargögnunum, sem skipuleggjendur sjálfir túlkuðu sem traust á svarinu fyrir þessa línu. Vandamálið var að allmargar línur innihéldu neikvæðar lóðir.

Eftir að hafa hugsað í nokkrar mínútur um línuna með vísbendingunni (vísbendingin vakti einfaldlega athygli á þessum eiginleika þyngdarsúlunnar) og smíðað þetta graf, ákváðum við að athuga 3 valkosti:

1) snúa við marki lína með neikvæða þyngd (og lóð í samræmi við það)
2) færðu lóðin í lágmarksgildið þannig að þau byrja á 0
3) ekki nota strengjaþyngd

Þriðji kosturinn reyndist verstur en tveir fyrstu bættu útkomuna, bestur var valkostur nr. 1 sem kom okkur strax í núverandi annað sæti í fyrra verkefninu og það fyrsta í því síðara.

Næsta skref okkar var að skoða gögnin með tilliti til gilda sem vantaði. Skipuleggjendur gáfu okkur þegar greidd gögn, þar sem vantaði töluvert af gildum, og þeim var skipt út fyrir -9999.

Við fundum gildi sem vantaði í MatchedHit_{X,Y,Z}[N] og MatchedHit_D{X,Y,Z}[N] dálkunum og aðeins þegar N=2 eða 3. Eins og við skiljum gerðu sumar agnir það ekki fara framhjá öllum 4 skynjarunum og stoppa annað hvort á 3. eða 4. plötu. Gögnin innihéldu einnig Lextra_{X,Y}[N] dálka, sem greinilega lýsa því sama og MatchedHit_{X,Y,Z}[N], en með einhvers konar framreikningi. Þessar fádæma getgátur gáfu til kynna að hægt væri að skipta út Lextra_{X,Y}[N] fyrir gildin sem vantaði í MatchedHit_{X,Y,Z}[N] (aðeins fyrir X og Y hnit). MatchedHit_Z[N] var vel fyllt með miðgildi. Þessar aðgerðir gerðu okkur kleift að ná 1. millisæti í báðum verkefnum.

Í ljósi þess að þeir gáfu ekkert fyrir að vinna fyrsta áfangann, hefðum við getað stoppað þar, en við héldum áfram, teiknuðum fallegar myndir og komum með nýja eiginleika.

Til dæmis komumst við að því að ef við teiknum skurðpunkta ögn við hverja skynjaraplötunna fjögurra, getum við séð að punktarnir á hverri plötu eru flokkaðir í 5 ferhyrninga með stærðarhlutfallið 4 til 5 og miðaðir við punkturinn (0,0), og í Það eru engir punktar í fyrsta rétthyrningnum.

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

Eftir að hafa ákvarðað þessar stærðir bættum við við 4 nýjum flokkunareinkennum fyrir hverja ögn - númerið á rétthyrningnum þar sem hún sker hverja plötu.

Við tókum líka eftir því að agnirnar virtust dreifast til hliðanna frá miðjunni og hugmyndin kom upp um að á einhvern hátt meta „gæði“ þessarar dreifingar. Helst væri sennilega hægt að koma með einhvers konar „hugsjóna“ fleygboga eftir flugtakspunkti og áætla frávikið frá henni, en við takmörkuðum okkur við „hugsjón“ beinu línuna. Eftir að hafa smíðað svona hugsjóna beinar línur fyrir hvern innkomustað gátum við reiknað út staðalfrávik ferils hverrar ögn frá þessari beinu línu. Þar sem meðalfrávik fyrir mark = 1 var 152 og fyrir mark = 0 var það 390, matum við þennan eiginleika sem góðan. Og reyndar náði þessi eiginleiki strax efst á þeim gagnlegustu.

Við vorum ánægð og bættum við frávik allra 4 skurðpunktanna fyrir hverja ögn frá hinni fullkomnu beinu línu sem 4 viðbótareiginleikum (og þeir virkuðu líka vel).

Tenglar á vísindagreinar um efni keppninnar, sem skipuleggjendur gáfu okkur, ýttu undir þá hugmynd að við séum langt frá því að vera fyrstir til að leysa þetta vandamál og ef til vill sé til einhvers konar sérhæfður hugbúnaður. Eftir að hafa uppgötvað geymslu á github þar sem aðferðirnar IsMuonSimple, IsMuon, IsMuonLoose voru útfærðar, fluttum við þær á síðuna okkar með smávægilegum breytingum. Aðferðirnar sjálfar voru mjög einfaldar: til dæmis, ef orkan er minni en ákveðinn þröskuldur, þá er það ekki múon, annars er það múon. Slíkir einfaldir eiginleikar gátu augljóslega ekki gefið aukningu ef notað er hallauppörvun, svo við bættum annarri verulegri „fjarlægð“ við þröskuldinn. Þessir eiginleikar hafa einnig verið endurbættir lítillega. Ef til vill var hægt, með því að greina núverandi aðferðir betur, að finna sterkari aðferðir og bæta þeim við merkin.

Í lok keppninnar breyttum við aðeins „fljótu“ lausninni fyrir annað vandamálið; á endanum var hún frábrugðin grunnlínunni í eftirfarandi atriðum:

1. Í röðum með neikvæða þyngd var markinu snúið við
2. Fyllt út gildi sem vantar í MatchedHit_{X,Y,Z}[N]
3. Minnkað dýpt í 7
4. Lækkaði námshlutfall í 0.1 (var 0.19)

Fyrir vikið reyndum við fleiri eiginleika (ekki mjög vel), völdum færibreytum og þjálfuðum catboost, lightgbm og xgboost, prófuðum mismunandi blöndur af spám og áður en við opnuðum einkahlutann unnum við öruggan sigur á öðru verkefninu, og í því fyrra vorum við meðal þeirra. leiðtogar.

Eftir að hafa opnað einkahlutann vorum við í 10. sæti fyrir 1. verkefni og 3. fyrir annað. Allir leiðtogarnir rugluðust saman og hraðinn í einrúmi var meiri en á libboard. Svo virðist sem gögnin hafi verið illa lagskipt (eða til dæmis voru engar línur með neikvæða þyngd í einkalífinu) og þetta var svolítið pirrandi.

SNA Hackathon 2019 - Textar. Fyrsta stig

Verkefnið var að raða færslum notenda á Odnoklassniki samfélagsnetinu út frá textanum sem þær innihéldu; auk textans voru nokkur fleiri einkenni færslunnar (tungumál, eigandi, dagsetning og tími stofnunar, dagsetning og tími áhorfs ).

Sem klassískar aðferðir við að vinna með texta myndi ég draga fram tvo valkosti:

1. Að kortleggja hvert orð í n-vídd vigurrými þannig að svipuð orð hafa svipaða vektora (lesið meira í grein okkar), þá annað hvort að finna meðalorð fyrir textann eða nota kerfi sem taka mið af hlutfallslegri stöðu orða (CNN, LSTM/GRU).
2. Nota líkan sem geta strax unnið með heilar setningar. Til dæmis, Bert. Fræðilega séð ætti þessi nálgun að virka betur.

Þar sem þetta var fyrsta reynsla mín af texta væri rangt að kenna einhverjum, svo ég mun kenna sjálfum mér. Þetta eru ráðin sem ég myndi gefa sjálfri mér í upphafi keppninnar:

1. Áður en þú hleypur til að kenna eitthvað skaltu skoða gögnin! Auk textans sjálfs voru gögnin með nokkrum dálkum og það var hægt að kreista mun meira út úr þeim en ég. Einfaldast er að gera meina markkóðun fyrir suma dálkana.
2. Ekki læra af öllum gögnunum! Það var mikið af gögnum (um 17 milljónir raða) og það var alls ekki nauðsynlegt að nota þau öll til að prófa tilgátur. Þjálfun og forvinnsla gekk frekar hægt og ég hefði augljóslega haft tíma til að prófa áhugaverðari tilgátur.
3. <Umdeild ráð> Engin þörf á að leita að morðingja fyrirsætu. Ég eyddi löngum tíma í að finna út Elmo og Bert, í von um að þeir myndu taka mig strax á háan stað, og þar af leiðandi notaði ég FastText forþjálfaðar innfellingar fyrir rússnesku. Ég gat ekki náð betri hraða með Elmo, og ég hafði enn ekki tíma til að átta mig á því með Bert.
4. <Umdeild ráð> Engin þörf á að leita að einum drápseiginleika. Þegar ég skoðaði gögnin tók ég eftir því að um það bil 1 prósent af textunum innihalda í raun ekki texta! En það voru tenglar á sum auðlindir, og ég skrifaði einfaldan þáttara sem opnaði síðuna og dró út titilinn og lýsinguna. Það virtist vera góð hugmynd, en svo fór ég í taugarnar á mér og ákvað að flokka alla tengla fyrir alla textana og tapaði aftur miklum tíma. Allt þetta skilaði ekki marktækum framförum í lokaniðurstöðunni (þó ég hafi til dæmis fundið út stemming).
5. Klassískir eiginleikar virka. Við gúglum til dæmis „textaeiginleikar kaggle“, lesum og bætum öllu við. TF-IDF veitti framför, eins og tölfræðilegir eiginleikar eins og lengd texta, orð og magn greinarmerkja.
6. Ef það eru DateTime dálkar er þess virði að flokka þá í nokkra aðskilda eiginleika (tíma, vikudaga osfrv.). Hvaða eiginleika ætti að auðkenna ætti að greina með því að nota línurit/sumar mælingar. Hér gerði ég allt rétt og undirstrikaði nauðsynlega eiginleika, en venjuleg greining hefði ekki skaðað (til dæmis eins og við gerðum í úrslitaleiknum).

Sem afleiðing af keppninni þjálfaði ég eitt keras líkan með orðamótun og annað byggt á LSTM og GRU. Báðir notuðu þeir fyrirfram þjálfaðar FastText innfellingar fyrir rússneska tungumálið (ég prófaði fjölda annarra innfellinga, en þetta voru þær sem virkuðu best). Eftir að hafa reiknað meðaltal af spánum náði ég 7. sætinu af 76 þátttakendum.

Eftir fyrsta áfanga var hún birt grein eftir Nikolai Anokhin, sem náði öðru sæti (hann tók þátt utan keppni), og lausn hans upp að einhverju stigi endurtók mína, en hann gekk lengra vegna fyrirspurnar-lykill-gildis athygliskerfisins.

Annað stig OK & IDAO

Seinni áfangar keppnanna fóru fram nánast í röð og því ákvað ég að skoða þau saman.

Í fyrsta lagi enduðum ég og nýfengið teymi á glæsilegri skrifstofu Mail.ru fyrirtækisins, þar sem verkefni okkar var að sameina líkön þriggja laga frá fyrsta stigi - texta, myndir og samstarf. Aðeins meira en 2 dagar voru í þetta, sem reyndist mjög lítið. Reyndar gátum við aðeins endurtekið niðurstöður okkar frá fyrsta áfanga án þess að fá ávinning af sameiningunni. Á endanum náðum við 5. sæti en við gátum ekki notað textamódelið. Eftir að hafa skoðað lausnir annarra þátttakenda virðist sem það hafi verið þess virði að reyna að flokka textana og bæta þeim við samstarfslíkanið. Aukaverkanir af þessu stigi voru nýjar birtingar, hitting og samskipti við flotta þátttakendur og skipuleggjendur, auk alvarlegs svefnleysis, sem gæti hafa haft áhrif á niðurstöðu lokastigs IDAO.

Verkefnið á lokastigi IDAO 2019 var að spá fyrir um biðtíma eftir pöntun fyrir Yandex leigubílstjóra á flugvellinum. Á stigi 2 voru 3 verkefni = 3 flugvellir auðkenndir. Fyrir hvern flugvöll eru gefin upp gögn frá mínútu fyrir mínútu um fjölda leigubílapantana í sex mánuði. Og sem prófunargögn voru gefin upp næsta mánuð og gögn frá mínútu fyrir mínútu um pantanir undanfarnar 2 vikur. Það var lítill tími (1,5 dagur), verkefnið var frekar ákveðið, aðeins einn úr liðinu mætti ​​í keppnina - og þar af leiðandi var þetta dapur staður undir lokin. Áhugaverðar hugmyndir voru meðal annars tilraunir til að nota ytri gögn: veður, umferðarteppur og tölfræði Yandex leigubílapöntunar. Þrátt fyrir að skipuleggjendur hafi ekki sagt hvaða flugvellir þetta væru, gerðu margir þátttakendur ráð fyrir að þeir væru Sheremetyevo, Domodedovo og Vnukovo. Þrátt fyrir að þessi tilgáta hafi verið hrakin eftir keppnina, bættu eiginleikar, til dæmis, úr veðurgögnum í Moskvu, árangurinn bæði við staðfestingu og á stigatöflunni.

Ályktun

1. ML keppnir eru flottar og áhugaverðar! Hér finnur þú notkun kunnáttu í gagnagreiningu, og í slægri líkönum og tækni, og einfaldlega skynsemi er velkomin.
2. ML er nú þegar gríðarlegur þekkingarhópur sem virðist fara vaxandi. Ég setti mér það markmið að kynnast mismunandi sviðum (merki, myndir, töflur, texti) og var þegar búinn að átta mig á því hversu mikið er að læra. Til dæmis, eftir þessar keppnir, ákvað ég að læra: þyrpingareiknirit, háþróaða tækni til að vinna með hallaaukandi bókasöfn (sérstaklega að vinna með CatBoost á GPU), hylkjanet, fyrirspurnarlykil-gildi athygliskerfi.
3. Ekki með kaggle einum! Það eru margar aðrar keppnir þar sem auðveldara er að fá að minnsta kosti stuttermabol og það eru fleiri möguleikar á öðrum verðlaunum.
4. Samskipti! Það er nú þegar stórt samfélag á sviði vélanáms og gagnagreiningar, það eru þemahópar í símskeyti, slaka og alvarlegt fólk frá Mail.ru, Yandex og öðrum fyrirtækjum svarar spurningum og hjálpar byrjendum og þeim sem halda áfram brautinni á þessu sviði af þekkingu.
5. Ég ráðlegg öllum sem voru innblásnir af fyrri punktinum að heimsækja gagnahátíð — stór ókeypis ráðstefna í Moskvu, sem verður 10.-11. maí.

Heimild: www.habr.com