Februarja in marca 2019 je potekalo tekmovanje za razvrščanje vira družbenega omrežja , na katerem je naša ekipa zasedla prvo mesto. V članku bom govoril o organizaciji tekmovanja, metodah, ki smo jih preizkusili, in nastavitvah catboost za trening na velikih podatkih.
SNA Hackathon
Hackathon pod tem imenom poteka že tretjič. Organizira ga socialno omrežje ok.ru, oziroma so naloga in podatki neposredno povezani s tem socialnim omrežjem.
SNA (social network analysis) v tem primeru ni pravilneje razumeti kot analizo socialnega grafa, temveč kot analizo socialnega omrežja.
- Leta 2014 je bila naloga napovedati, koliko všečkov bo objava dobila.
- Leta 2016 - naloga VVZ (morda ste seznanjeni), bližje analizi socialnega grafa.
- V letu 2019 razvrščanje uporabnikovega vira glede na verjetnost, da bo uporabniku objava všeč.
Za leto 2014 ne morem reči, v letih 2016 in 2019 pa so bile poleg sposobnosti analize podatkov potrebne tudi veščine dela z velikimi podatki. Mislim, da me je na ta tekmovanja pritegnila kombinacija strojnega učenja in velikih težav pri obdelavi podatkov, moje izkušnje na teh področjih pa so mi pomagale zmagati.
mlbootcamp
V letu 2019 je bilo tekmovanje organizirano na platformi .
Tekmovanje se je začelo preko spleta 7. februarja in je bilo sestavljeno iz 3 nalog. Vsak se lahko registrira na spletnem mestu, prenese in naložite avto za nekaj ur. Na koncu spletne etape 15. marca je bilo najboljših 15 vsake skakalne prireditve povabljenih v pisarno Mail.ru za offline etapo, ki je potekala od 30. marca do 1. aprila.
Naloga
Izvorni podatki zagotavljajo ID-je uporabnikov (userId) in ID-je objave (objectId). Če je bila uporabniku prikazana objava, potem podatki vsebujejo vrstico, ki vsebuje userId, objectId, odziv uporabnika na to objavo (feedback) in niz različnih funkcij ali povezav do slik in besedil.
| Uporabniško ime | objectId | lastnikId | povratne informacije | slike |
|---|---|---|---|---|
| 3555 | 22 | 5677 | [všečkal, kliknil] | [hash1] |
| 12842 | 55 | 32144 | [ni všeč] | [hash2,hash3] |
| 13145 | 35 | 5677 | [kliknjeno, deljeno] | [hash2] |
Testni niz podatkov vsebuje podobno strukturo, vendar manjka polje za povratne informacije. Naloga je napovedati prisotnost odziva 'všeč mi je' v polju za povratne informacije.
Datoteka za predložitev ima naslednjo strukturo:
| Uporabniško ime | SortedList[objectId] |
|---|---|
| 123 | 78,13,54,22 |
| 128 | 35,61,55 |
| 131 | 35,68,129,11 |
Meritev je povprečni ROC AUC za uporabnike.
Podrobnejši opis podatkov najdete na. Tam lahko tudi prenesete podatke, vključno s testi in slikami.
Spletni oder
Na spletni stopnji je bila naloga razdeljena na 3 dele
- — vključuje vse funkcije razen slik in besedil;
- — vključuje le informacije o slikah;
- — vključuje le informacije o besedilih.
Oder brez povezave
V fazi brez povezave so podatki vključevali vse funkcije, besedila in slike pa so bili redki. V naboru podatkov je bilo 1,5-krat več vrstic, ki jih je bilo že veliko.
Rešitev problema
Ker CV pišem v službi, sem svojo pot v tem natečaju začela z nalogo “Slike”. Zagotovljeni podatki so bili userId, objectId, ownerId (skupina, v kateri je bila objava objavljena), časovni žigi za ustvarjanje in prikaz objave ter seveda slika za to objavo.
Po generiranju več funkcij, ki temeljijo na časovnih žigih, je bila naslednja ideja, da vzamemo predzadnjo plast nevrona, predhodno usposobljenega na imagenetu, in te vdelave pošljemo v pospeševanje.
Rezultati niso bili impresivni. Vdelave iz nevrona imagenet so nepomembne, pomislil sem, narediti moram svoj avtokodirnik.
Trajalo je veliko časa in rezultat se ni izboljšal.
Generiranje funkcij
Delo s slikami vzame veliko časa, zato sem se odločil narediti nekaj preprostejšega.
Kot lahko takoj vidite, je v naboru podatkov več kategoričnih značilnosti in da se ne bi preveč obremenjeval, sem vzel samo catboost. Rešitev je bila odlična, brez nastavitev sem takoj prišel v prvo vrstico lestvice.
Podatkov je kar veliko in razporejenih v parketni obliki, zato sem brez premisleka vzel scalo in začel vse pisati v sparku.
Najenostavnejše funkcije, ki so omogočile večjo rast kot vdelave slik:
- kolikokrat so se objectId, userId in ownerId pojavili v podatkih (naj bo v korelaciji s priljubljenostjo);
- koliko objav je userId videl od ownerId (mora biti v korelaciji z uporabnikovim zanimanjem za skupino);
- koliko edinstvenih userId-jev si je ogledalo objave lastnika ID-ja (odraža velikost občinstva skupine).
Iz časovnih žigov je bilo mogoče pridobiti čas dneva, ko je uporabnik gledal vir (zjutraj/popoldan/zvečer/noč). Če združite te kategorije, lahko še naprej ustvarjate funkcije:
- kolikokrat se je userId prijavil zvečer;
- ob kateri uri je ta objava največkrat prikazana (objectId) itd.
Vse to je postopoma izboljšalo meritve. Toda velikost nabora podatkov o usposabljanju je približno 20 milijonov zapisov, zato je dodajanje funkcij močno upočasnilo usposabljanje.
Ponovno sem razmislil o svojem pristopu k uporabi podatkov. Čeprav so podatki odvisni od časa, nisem opazil nobenega očitnega uhajanja informacij "v prihodnosti", vendar sem jih za vsak slučaj razčlenil takole:
Vadbeni sklop, ki smo ga dobili (februar in 2 tedna marca), je bil razdeljen na 2 dela.
Model je bil učen na podlagi podatkov iz zadnjih N dni. Zgoraj opisane agregacije so bile zgrajene na vseh podatkih, vključno s testom. Hkrati so se pojavili podatki, na podlagi katerih je mogoče graditi različna kodiranja ciljne spremenljivke. Najenostavnejši pristop je, da ponovno uporabite kodo, ki že ustvarja nove funkcije, in ji preprosto vnesete podatke, na katerih se ne bo učila, in cilj = 1.
Tako smo dobili podobne lastnosti:
- Kolikokrat je userId videl objavo v skupini ownerId;
- Kolikokrat je userId všečkal objavo v skupini ownerId;
- Odstotek objav, ki jih je userId všečkal lastniku.
Se pravi, izkazalo se je srednje ciljno kodiranje na delu nabora podatkov za različne kombinacije kategoričnih značilnosti. Načeloma catboost gradi tudi ciljno kodiranje in s tega vidika ni nobene koristi, vendar je na primer postalo mogoče šteti število edinstvenih uporabnikov, ki so všečkali objave v tej skupini. Hkrati je bil dosežen glavni cilj - moj nabor podatkov se je večkrat zmanjšal in bilo je mogoče nadaljevati z ustvarjanjem funkcij.
Medtem ko lahko catboost ustvari kodiranje samo na podlagi všečkane reakcije, ima povratna informacija še druge reakcije: nadaljnja skupna raba, nevšečkanje, nevšečkanje, klik, prezrtje, kodiranja za katere je mogoče izvesti ročno. Ponovno sem izračunal vse vrste agregatov in izločil funkcije z nizko pomembnostjo, da ne bi napihnil nabora podatkov.
Takrat sem bil z veliko razliko na prvem mestu. Edina stvar, ki je bila zmedena, je bila, da vdelane slike skoraj niso pokazale rasti. Prišla je ideja, da vse dam catboostu. Združimo slike Kmeans in dobimo novo kategorično funkcijo imageCat.
Tukaj je nekaj razredov po ročnem filtriranju in združevanju gruč, pridobljenih iz KMeans.
Na osnovi imageCat ustvarimo:
- Nove kategorične značilnosti:
- Kateri imageCat si je najpogosteje ogledal userId;
- Kateri imageCat najpogosteje prikazuje ownerId;
- Kateri imageCat je bil najpogosteje všeč uporabniku UserId;
- Različni števci:
- Koliko edinstvenih imageCat si je ogledalo userId;
- Približno 15 podobnih funkcij in ciljno kodiranje, kot je opisano zgoraj.
Besedila
Rezultati na slikovnem natečaju so mi ustrezali in odločila sem se preizkusiti v besedilih. Prej se nisem kaj dosti ukvarjal s teksti in sem po neumnosti ubil dan na tf-idf in svd. Potem sem videl osnovno linijo z doc2vec, ki naredi točno to, kar potrebujem. Po rahli prilagoditvi parametrov doc2vec sem dobil besedilne vdelave.
In potem sem preprosto ponovno uporabil kodo za slike, v kateri sem vdelane slike zamenjal z vdelanimi besedili. Posledično sem zasedla 2. mesto na besedilnem tekmovanju.
Sodelovalni sistem
Ostalo je še eno tekmovanje, ki ga še nisem “pocukal” s palico in sodeč po AUC na lestvici bi morali rezultati prav tega tekmovanja najbolj vplivati na offline oder.
Vzel sem vse značilnosti, ki so bile v izvornih podatkih, izbral kategorične in izračunal enake agregate kot za slike, razen značilnosti, ki temeljijo na samih slikah. Samo dajanje tega v catboost me je pripeljalo do 2. mesta.
Prvi koraki optimizacije catboost
Eno prvo in dve drugi mesti sta me veselili, vendar je bilo razumevanje, da nisem naredil nič posebnega, kar pomeni, da lahko pričakujem izgubo pozicij.
Cilj tekmovanja je rangiranje objav znotraj uporabnika, jaz pa sem ves ta čas reševal problem klasifikacije, torej optimizacijo napačne metrike.
Naj vam dam preprost primer:
| Uporabniško ime | objectId | napoved | zemeljska resnica |
|---|---|---|---|
| 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 |
Naredimo majhno preureditev
| Uporabniško ime | objectId | napoved | zemeljska resnica |
|---|---|---|---|
| 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 |
Dobimo naslednje rezultate:
| Model | AUC | Uporabnik1 AUC | Uporabnik2 AUC | povprečna AUC |
|---|---|---|---|---|
| Možnost 1 | 0,8 | 1,0 | 0,0 | 0,5 |
| Možnost 2 | 0,7 | 0,75 | 1,0 | 0,875 |
Kot lahko vidite, izboljšanje splošne metrike AUC ne pomeni izboljšanje povprečne metrike AUC pri uporabniku.
Catboost iz škatle. Prebral sem o meritvah razvrščanja, pri uporabi catboost in nastavite YetiRankPairwise za vadbo čez noč. Rezultat ni bil navdušujoč. Ker sem se odločil, da sem premalo usposobljen, sem funkcijo napake spremenil v QueryRMSE, ki, sodeč po dokumentaciji catboost, konvergira hitreje. Na koncu sem dosegel enak rezultat kot pri treningu za razvrstitev, vendar sta zasedbi teh dveh modelov dobro napredovali, kar me je pripeljalo do prvega mesta na vseh treh tekmovanjih.
5 minut pred zaključkom spletnega odra tekmovanja "Sodelovalni sistemi" me je Sergej Šalnov premaknil na drugo mesto. Nadaljnjo pot smo prehodili skupaj.
Priprave na fazo brez povezave
Zagotovljena nam je bila zmaga na spletni stopnji z grafično kartico RTX 2080 TI, vendar nas je glavna nagrada v višini 300 rubljev in najverjetneje celo končno prvo mesto prisilila, da smo delali ta 000 tedna.
Kot se je izkazalo, je Sergej uporabljal tudi catboost. Izmenjali smo si ideje in funkcije in izvedel sem več o ki je vsebovala odgovore na številna moja vprašanja in tudi tista, ki jih takrat še nisem imel.
Ogled poročila me je pripeljal do ideje, da moramo vse parametre vrniti na privzete vrednosti, nastavitve pa opraviti zelo previdno in šele po popravku nabora funkcij. Zdaj je en trening trajal približno 15 ur, vendar je enemu modelu uspelo doseči hitrost, ki je bila višja od tiste, dosežene v ansamblu z uvrstitvijo.
Generiranje funkcij
V tekmovanju Collaborative Systems je veliko število lastnosti ocenjenih kot pomembnih za model. na primer auditweights_spark_svd - najpomembnejši znak, vendar ni podatkov o tem, kaj pomeni. Mislil sem, da bi bilo vredno prešteti različne agregate na podlagi pomembnih lastnosti. Na primer, povprečje auditweights_spark_svd po uporabniku, po skupini, po objektu. Enako lahko izračunamo s podatki, na katerih se ne izvaja noben trening in cilj = 1, torej povprečje auditweights_spark_svd po uporabniku po predmetih, ki so mu bili všeč. Poleg tega pomembni znaki auditweights_spark_svd, bilo jih je več. Tukaj je nekaj izmed njih:
- auditweightsCtrGender
- auditweightsCtrHigh
- userOwnerCounterCreateLikes
Na primer povprečje auditweightsCtrGender glede na userId se je izkazalo, da je pomembna lastnost, tako kot povprečna vrednost userOwnerCounterCreateLikes po UserId+ownerId. Že zaradi tega bi morali pomisliti, da morate razumeti pomen polj.
Pomembne lastnosti so bile tudi auditweightsLikesCount и auditweightsShowsCount. Z delitvijo enega z drugim smo dobili še pomembnejšo lastnost.
Puščanje podatkov
Modeliranje tekmovanja in proizvodnje sta zelo različni nalogi. Pri pripravi podatkov je zelo težko upoštevati vse podrobnosti in v testu ne prenesti nekaterih netrivialnih informacij o ciljni spremenljivki. Če ustvarjamo produkcijsko rešitev, se bomo pri urjenju modela poskušali izogniti uhajanju podatkov. Če pa želimo zmagati v konkurenci, potem je uhajanje podatkov najboljša lastnost.
Ko ste preučili podatke, lahko to vidite glede na vrednosti objectId auditweightsLikesCount и auditweightsShowsCount sprememba, kar pomeni, da bo razmerje največjih vrednosti teh funkcij veliko bolje odražalo naknadno pretvorbo kot razmerje v času prikaza.
Prvo puščanje, ki smo ga našli, je auditweightsLikesCountMax/auditweightsShowsCountMax.
Kaj pa, če pogledamo podatke natančneje? Razvrstimo po datumu oddaje in dobimo:
| objectId | Uporabniško ime | auditweightsShowsCount | auditweightsLikesCount | cilj (je všeč) |
|---|---|---|---|---|
| 1 | 1 | 12 | 3 | verjetno ne |
| 1 | 2 | 15 | 3 | Mogoče ja |
| 1 | 3 | 16 | 4 |
Presenetljivo je bilo, ko sem našel prvi tak primer in izkazalo se je, da se moja napoved ni uresničila. Toda ob upoštevanju dejstva, da so se največje vrednosti teh značilnosti znotraj objekta povečale, nismo bili leni in smo se odločili najti auditweightsShowsCountNext и auditweightsLikesCountNext, to je vrednosti v naslednjem trenutku. Z dodajanjem funkcije
(auditweightsShowsCountNext-auditweightsShowsCount)/(auditweightsLikesCount-auditweightsLikesCountNext) hitro smo naredili oster skok.
Podobna puščanja bi lahko uporabili z iskanjem naslednjih vrednosti za userOwnerCounterCreateLikes znotraj userId+ownerId in npr. auditweightsCtrGender znotraj objectId+userGender. Našli smo 6 podobnih polj z uhajanji in iz njih izvlekli čim več informacij.
Do takrat smo iz sodelovalnih funkcij iztisnili čim več informacij, vendar se nismo vrnili k tekmovanjem slik in besedil. Imel sem odlično idejo, da preverim: koliko dajejo funkcije, ki temeljijo neposredno na slikah ali besedilih, na ustreznih tekmovanjih?
Na natečajih za slike in besedilo ni bilo uhajanja, vendar sem do takrat vrnil privzete parametre catboost, očistil kodo in dodal nekaj funkcij. Skupno je bilo:
| odločitev | kmalu |
|---|---|
| Največ s slikami | 0.6411 |
| Največje dovoljeno število slik | 0.6297 |
| Rezultat drugega mesta | 0.6295 |
| odločitev | kmalu |
|---|---|
| Največ z besedili | 0.666 |
| Največ brez besedil | 0.660 |
| Rezultat drugega mesta | 0.656 |
| odločitev | kmalu |
|---|---|
| Maksimalno v sodelovanju | 0.745 |
| Rezultat drugega mesta | 0.723 |
Postalo je očitno, da iz besedil in slik verjetno ne bomo mogli iztisniti veliko, in ko smo preizkusili nekaj najbolj zanimivih idej, smo nehali delati z njimi.
Nadaljnja generacija funkcij v sistemih za sodelovanje ni prinesla povečanja in začeli smo z razvrščanjem. Na spletni stopnji mi je zasedba za razvrstitev in uvrstitev dala majhno povišanje, kot se je izkazalo, ker sem premalo treniral razvrstitev. Nobena od funkcij za napake, vključno z YetiRanlPairwise, ni dala niti blizu rezultata, ki ga je dosegla LogLoss (0,745 v primerjavi z 0,725). Še vedno je bilo upanje za QueryCrossEntropy, ki ga ni bilo mogoče zagnati.
Oder brez povezave
V fazi brez povezave je struktura podatkov ostala enaka, vendar je prišlo do manjših sprememb:
- identifikatorji userId, objectId, ownerId so bili ponovno naključni;
- več znakov je bilo odstranjenih in več preimenovanih;
- podatki so se povečali za približno 1,5-krat.
Poleg naštetih težav je bil en velik plus: ekipi je bil dodeljen velik strežnik z RTX 2080TI. Že dolgo uživam v htopu.
Bila je le ena ideja - preprosto reproducirati že obstoječe. Potem ko smo porabili nekaj ur za nastavitev okolja na strežniku, smo postopoma začeli preverjati, ali so rezultati ponovljivi. Glavna težava, s katero se soočamo, je povečanje količine podatkov. Odločili smo se, da malo zmanjšamo obremenitev in nastavimo catboost parameter ctr_complexity=1. To malo zmanjša hitrost, vendar je moj model začel delovati, rezultat je bil dober - 0,733. Sergey za razliko od mene ni razdelil podatkov na 2 dela in se je uril na vseh podatkih, čeprav je to dalo najboljše rezultate na spletni stopnji, na stopnji brez povezave je bilo veliko težav. Če bi vzeli vse funkcije, ki smo jih ustvarili, in jih poskušali stlačiti v catboost, potem na spletni stopnji ne bi delovalo nič. Sergej je opravil optimizacijo tipov, na primer pretvoril tipe float64 v float32. Informacije o optimizaciji pomnilnika najdete v pandah. Posledično je Sergej treniral na CPE z uporabo vseh podatkov in dobil približno 0,735.
Ti rezultati so bili dovolj za zmago, vendar smo skrivali svojo pravo hitrost in nismo mogli biti prepričani, da druge ekipe ne počnejo enako.
Borite se do zadnjega
Catboost nastavitev
Naša rešitev je bila v celoti reproducirana, dodali smo funkcije besedilnih podatkov in slik, tako da je ostalo samo še prilagoditi parametre catboost. Sergej je treniral na procesorju z majhnim številom iteracij, jaz pa na tistem s ctr_complexity=1. Ostal je še en dan in če bi samo dodali iteracije ali povečali ctr_complexity, bi do jutra lahko dosegli še večjo hitrost in hodili ves dan.
Na stopnji brez povezave je mogoče hitrosti zelo enostavno skriti, če preprosto izberete ne najboljšo rešitev na spletnem mestu. Pričakovali smo drastične spremembe na lestvici najboljših v zadnjih minutah pred zaključkom prijav in se odločili, da se ne bomo ustavili.
Iz Anninega videa sem izvedel, da je za izboljšanje kakovosti modela najbolje izbrati naslednje parametre:
- stopnja učenja — Privzeta vrednost se izračuna na podlagi velikosti nabora podatkov. Povečanje learning_rate zahteva povečanje števila ponovitev.
- l2_leaf_reg — Regulacijski koeficient, privzeta vrednost 3, prednostna izbira med 2 in 30. Zmanjšanje vrednosti povzroči povečanje overfita.
- temperatura_vreče — doda randomizacijo uteži predmetov v vzorcu. Privzeta vrednost je 1, kjer so uteži vzete iz eksponentne porazdelitve. Zmanjšanje vrednosti povzroči povečanje overfita.
- naključna_moč — Vpliva na izbiro razcepov pri določeni ponovitvi. Višja kot je random_strength, večja je možnost, da bo izbrana razdelitev z nizko pomembnostjo. Pri vsaki naslednji ponovitvi se naključnost zmanjša. Zmanjšanje vrednosti povzroči povečanje overfita.
Drugi parametri imajo veliko manjši vpliv na končni rezultat, zato jih nisem poskušal izbrati. Ena ponovitev usposabljanja na mojem naboru podatkov GPU s ctr_complexity=1 je trajala 20 minut, izbrani parametri na zmanjšanem naboru podatkov pa so se nekoliko razlikovali od optimalnih na celotnem naboru podatkov. Na koncu sem naredil približno 30 iteracij na 10% podatkov in nato še približno 10 iteracij na vseh podatkih. Izkazalo se je nekaj takega:
- stopnja učenja Povečal sem za 40 % glede na privzeto;
- l2_leaf_reg pustil enako;
- temperatura_vreče и naključna_moč znižana na 0,8.
Sklepamo lahko, da je bil model premalo usposobljen s privzetimi parametri.
Bil sem zelo presenečen, ko sem videl rezultat na lestvici:
| Model | model 1 | model 2 | model 3 | ansambel |
|---|---|---|---|---|
| Brez tuninga | 0.7403 | 0.7404 | 0.7404 | 0.7407 |
| Z uglaševanjem | 0.7406 | 0.7405 | 0.7406 | 0.7408 |
Sam sem ugotovil, da če hitra uporaba modela ni potrebna, je bolje zamenjati izbor parametrov z nizom več modelov z uporabo neoptimiziranih parametrov.
Sergey je optimiziral velikost nabora podatkov za izvajanje v GPE. Najenostavnejša možnost je odrezati del podatkov, vendar je to mogoče storiti na več načinov:
- postopoma odstranite najstarejše podatke (začetek februarja), dokler se nabor podatkov ne začne prilegati pomnilniku;
- odstranite funkcije z najmanjšo pomembnostjo;
- odstranite uporabniške ID-je, za katere obstaja samo en vnos;
- pustite samo uporabniške ID-je, ki so v testu.
In končno, sestavite ansambel iz vseh možnosti.
Zadnji ansambel
Do poznega večera zadnjega dne smo postavili skupino naših modelov, ki so prinesli 0,742. Čez noč sem zagnal svoj model s ctr_complexity=2 in namesto 30 minut je treniral 5 ur. Šele ob 4. uri zjutraj je bil preštet in sem sestavil zadnjo zasedbo, ki je na javni lestvici dala 0,7433.
Zaradi različnih pristopov k reševanju problema naše napovedi niso bile močno povezane, kar je dalo dobro povečanje ansambla. Če želite dobiti dober ansambel, je bolje uporabiti neobdelane napovedi modela predict(prediction_type='RawFormulaVal') in nastaviti scale_pos_weight=neg_count/pos_count.
Na spletni strani si lahko ogledate .
Druge rešitve
Številne ekipe so sledile kanonom algoritmov priporočljivega sistema. Ker nisem strokovnjak na tem področju, jih ne morem oceniti, vendar se spomnim 2 zanimivih rešitev.
- . Nikolay, ki je bil zaposlen pri Mail.ru, se ni prijavil za nagrade, zato njegov cilj ni bil doseči največjo hitrost, temveč pridobiti enostavno nadgradljivo rešitev.
- Odločitev ekipe, ki je prejela nagrado žirije na podlagi , omogoča zelo dobro združevanje slik v gruče brez ročnega dela.
Zaključek
Kaj se mi je najbolj vtisnilo v spomin:
- Če so v podatkih kategorične značilnosti in veste, kako pravilno narediti ciljno kodiranje, je še vedno bolje poskusiti catboost.
- Če sodelujete na tekmovanju, ne smete izgubljati časa z izbiro parametrov, razen rate_Learning in ponovitev. Hitrejša rešitev je izdelava ansambla iz več modelov.
- Okrepitve se lahko učijo na GPE. Catboost se lahko zelo hitro uči na GPE, vendar poje veliko pomnilnika.
- Med razvojem in testiranjem idej je bolje nastaviti majhen rsm~=0.2 (samo CPE) in ctr_complexity=1.
- Za razliko od drugih ekip je zasedba naših manekenk in modelov dala velik porast. Izmenjevali smo le ideje in pisali v različnih jezikih. Imeli smo drugačen pristop k delitvi podatkov in mislim, da je imel vsak svoje napake.
- Ni jasno, zakaj je bila optimizacija razvrščanja slabša od optimizacije klasifikacije.
- Pridobil sem nekaj izkušenj z delom z besedili in razumel, kako nastanejo sistemi priporočil.
Hvala organizatorjem za čustva, znanje in prejete nagrade.
Vir: www.habr.com