Vo februári až marci 2019 sa uskutočnila súťaž o hodnotenie informačného kanála sociálnej siete , v ktorej naše družstvo obsadilo prvé miesto. V článku budem hovoriť o organizácii súťaže, metódach, ktoré sme vyskúšali, a nastaveniach catboost pre tréning na veľkých dátach.
SNA Hackathon
Pod týmto názvom sa hackathon koná už po tretíkrát. Organizuje ho sociálna sieť ok.ru, respektíve úloha a údaje priamo súvisia s touto sociálnou sieťou.
SNA (analýza sociálnej siete) je v tomto prípade správnejšie chápaná nie ako analýza sociálneho grafu, ale skôr ako analýza sociálnej siete.
- V roku 2014 bolo úlohou predpovedať počet lajkov, ktoré príspevok získa.
- V roku 2016 - úloha VVZ (možno vám je známa), bližšie k analýze sociálneho grafu.
- V roku 2019 hodnotenie informačného kanála používateľa na základe pravdepodobnosti, že sa používateľovi bude príspevok páčiť.
Nemôžem povedať o roku 2014, ale v rokoch 2016 a 2019 boli okrem schopnosti analýzy údajov potrebné aj zručnosti v práci s veľkými údajmi. Myslím, že to bola kombinácia strojového učenia a problémov so spracovaním veľkých dát, čo ma prilákalo do týchto súťaží a moje skúsenosti v týchto oblastiach mi pomohli vyhrať.
mlbootcamp
V roku 2019 bola súťaž organizovaná na platforme .
Súťaž začala online 7. februára a pozostávala z 3 úloh. Ktokoľvek sa mohol zaregistrovať na stránke, stiahnuť a naložiť svoje auto na niekoľko hodín. Na konci online fázy 15. marca bolo 15 najlepších z každého parkúrového podujatia pozvaných do kancelárie Mail.ru na offline fázu, ktorá sa konala od 30. marca do 1. apríla.
Úloha
Zdrojové údaje poskytujú ID používateľov (userId) a ID príspevkov (objectId). Ak sa používateľovi zobrazil príspevok, potom údaje obsahujú riadok obsahujúci userId, objectId, reakcie používateľov na tento príspevok (spätná väzba) a súbor rôznych funkcií alebo odkazov na obrázky a texty.
| ID používateľa | objectId | Id vlastníka | spätná väzba | obrazy |
|---|---|---|---|---|
| 3555 | 22 | 5677 | [páči sa mi, klikol] | [hash1] |
| 12842 | 55 | 32144 | [nepáči sa mi] | [hash2, hash3] |
| 13145 | 35 | 5677 | [kliknuté, zdieľané] | [hash2] |
Súbor testovacích údajov obsahuje podobnú štruktúru, chýba však pole spätnej väzby. Úlohou je predpovedať prítomnosť „páči sa mi“ reakcie v poli spätnej väzby.
Súbor na odoslanie má nasledujúcu štruktúru:
| ID používateľa | SortedList[objectId] |
|---|---|
| 123 | 78,13,54,22 |
| 128 | 35,61,55 |
| 131 | 35,68,129,11 |
Metrikou je priemerná ROC AUC pre používateľov.
Podrobnejší popis údajov nájdete na. Môžete si tam stiahnuť aj dáta vrátane testov a obrázkov.
Online scéna
V online fáze bola úloha rozdelená na 3 časti
- — obsahuje všetky funkcie okrem obrázkov a textov;
- — obsahuje iba informácie o obrázkoch;
- — obsahuje informácie len o textoch.
Offline scéna
Vo fáze offline údaje zahŕňali všetky funkcie, zatiaľ čo texty a obrázky boli zriedkavé. V datasete bolo 1,5-krát viac riadkov, ktorých už bolo veľa.
Riešenie problému
Keďže v práci robím životopis, svoju cestu v tejto súťaži som začal úlohou „Obrázky“. Poskytnuté údaje boli userId, objectId, ownerId (skupina, v ktorej bol príspevok zverejnený), časové pečiatky na vytvorenie a zobrazenie príspevku a samozrejme obrázok pre tento príspevok.
Po vygenerovaní niekoľkých funkcií na základe časových pečiatok bolo ďalšou myšlienkou vziať predposlednú vrstvu neurónu vopred natrénovanú na imagenet a poslať tieto vloženia na posilnenie.
Výsledky neboli pôsobivé. Vloženie z neurónu imagenet je irelevantné, pomyslel som si, musím si vytvoriť vlastný autokóder.
Trvalo to veľa času a výsledok sa nezlepšil.
Generovanie funkcií
Práca s obrázkami zaberá veľa času, preto som sa rozhodol urobiť niečo jednoduchšie.
Ako môžete okamžite vidieť, v súbore údajov je niekoľko kategorických funkcií a aby som sa príliš neobťažoval, vzal som len catboost. Riešenie bolo výborné, bez akýchkoľvek nastavení som sa okamžite dostal na prvý riadok rebríčka.
Existuje pomerne veľa údajov a sú usporiadané vo formáte parket, takže som bez rozmýšľania vzal scala a začal som všetko písať v iskri.
Najjednoduchšie funkcie, ktoré poskytli väčší rast ako vkladanie obrázkov:
- koľkokrát sa objectId, userId a ownerId objavilo v údajoch (malo by korelovať s popularitou);
- koľko príspevkov používateľské ID videlo od vlastníka (malo by korelovať so záujmom používateľa o skupinu);
- koľko jedinečných identifikátorov userId zobrazilo príspevky od vlastníka (odzrkadľuje veľkosť publika skupiny).
Z časových pečiatok bolo možné získať čas dňa, kedy používateľ sledoval informačný kanál (ráno/poobede/večer/noc). Kombináciou týchto kategórií môžete pokračovať vo vytváraní funkcií:
- koľkokrát sa userId prihlásil večer;
- v akom čase sa tento príspevok najčastejšie zobrazuje (objectId) atď.
To všetko postupne zlepšovalo metriky. Veľkosť súboru údajov o tréningu je však približne 20 miliónov záznamov, takže pridávanie funkcií značne spomalilo tréning.
Prehodnotil som svoj prístup k používaniu údajov. Aj keď sú údaje časovo závislé, nezaznamenal som žiadne zjavné úniky informácií „v budúcnosti“, napriek tomu som ich pre každý prípad rozobral takto:
Tréningový set, ktorý nám bol poskytnutý (február a 2 týždne v marci) bol rozdelený na 2 časti.
Model bol trénovaný na dátach z posledných N dní. Vyššie opísané agregácie boli postavené na všetkých údajoch vrátane testu. Zároveň sa objavili dáta, na ktorých je možné stavať rôzne kódovania cieľovej premennej. Najjednoduchším prístupom je opätovné použitie kódu, ktorý už vytvára nové funkcie, a jednoducho doň vložiť údaje, na ktorých sa nebude trénovať, a cieľ = 1.
Získali sme teda podobné vlastnosti:
- Koľkokrát už userId videl príspevok v skupine ownerId;
- Koľkokrát sa používateľovi userId páčil príspevok v skupine ownerId;
- Percento príspevkov, ktoré sa páčili používateľovi userId od vlastníka.
To znamená, že sa ukázalo stredné cieľové kódovanie na časti súboru údajov pre rôzne kombinácie kategorických znakov. Catboost v zásade tiež buduje cieľové kódovanie a z tohto hľadiska to nemá žiadny prínos, ale napríklad bolo možné spočítať počet jedinečných používateľov, ktorým sa páčili príspevky v tejto skupine. Zároveň bol dosiahnutý hlavný cieľ – môj súbor údajov sa niekoľkokrát zmenšil a bolo možné pokračovať vo generovaní funkcií.
Zatiaľ čo catboost dokáže vytvoriť kódovanie iba na základe reakcie, ktorá sa mi páči, spätná väzba má aj iné reakcie: opätovné zdieľanie, nepáči sa mi, nepáči sa mi, klikne, ignoruje, kódovanie je možné vykonať manuálne. Prepočítal som všetky druhy agregátov a eliminoval funkcie s nízkou dôležitosťou, aby sa nenafúkol súbor údajov.
V tom čase som bol s veľkým náskokom na prvom mieste. Jediné, čo bolo mätúce, bolo, že vkladanie obrázkov nevykazovalo takmer žiadny rast. Prišiel nápad dať všetko do catboostu. Zhlukujeme obrázky Kmeans a získame novú kategorickú funkciu imageCat.
Tu sú niektoré triedy po manuálnom filtrovaní a zlúčení klastrov získaných z KMeans.
Na základe imageCat generujeme:
- Nové kategorické funkcie:
- Ktorý imageCat bol najčastejšie zobrazovaný podľa userId;
- Ktorý imageCat najčastejšie zobrazuje ownerId;
- Ktorý imageCat sa najčastejšie páčil podľa userId;
- Rôzne počítadlá:
- Koľko jedinečných imageCat sa pozrelo na userId;
- Asi 15 podobných funkcií plus cieľové kódovanie, ako je opísané vyššie.
texty
Výsledky v obrázkovej súťaži mi vyhovovali a rozhodol som sa vyskúšať texty. Predtým som s textami veľmi nepracoval a hlúpo som zabil deň na tf-idf a svd. Potom som videl základnú líniu s doc2vec, ktorý robí presne to, čo potrebujem. Po miernej úprave parametrov doc2vec som získal vloženie textu.
A potom som jednoducho znova použil kód pre obrázky, v ktorých som nahradil vloženie obrázkov vložením textu. Vďaka tomu som v textovej súťaži obsadil 2. miesto.
Kolaboratívny systém
Zostala jedna súťaž, do ktorej som ešte „nepopichal“ palicou a súdiac podľa AUC na rebríčku, výsledky tejto konkrétnej súťaže mali mať najväčší vplyv na offline scénu.
Vzal som všetky funkcie, ktoré boli v zdrojových údajoch, vybral som kategoriálne a vypočítal som rovnaké agregáty ako pre obrázky, okrem prvkov založených na samotných obrázkoch. Práve zaradením tohto do catboostu som sa dostal na 2. miesto.
Prvé kroky optimalizácie catboost
Jedno prvé a dve druhé miesta ma potešili, ale došlo k pochopeniu, že som nič špeciálne neurobil, čiže som mohol očakávať stratu pozícií.
Cieľom súťaže je zoradiť príspevky v rámci používateľa a celý ten čas som riešil klasifikačný problém, teda optimalizáciu nesprávnej metriky.
Uvediem jednoduchý príklad:
| ID používateľa | objectId | predpoveď | krutá pravda |
|---|---|---|---|
| 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 |
Urobme malú prestavbu
| ID používateľa | objectId | predpoveď | krutá pravda |
|---|---|---|---|
| 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 |
Získame nasledujúce výsledky:
| Model | AUC | Používateľ 1 AUC | Používateľ 2 AUC | priemerná AUC |
|---|---|---|---|---|
| Možnosť 1 | 0,8 | 1,0 | 0,0 | 0,5 |
| Možnosť 2 | 0,7 | 0,75 | 1,0 | 0,875 |
Ako vidíte, zlepšenie celkovej metriky AUC neznamená zlepšenie priemernej metriky AUC v rámci používateľa.
Catboost zo škatule. Čítal som o hodnotiacich metrikách, pri použití catboost a nastavte YetiRankPairwise na tréning cez noc. Výsledok nebol pôsobivý. Keďže som sa rozhodol, že som nedostatočne vyškolený, zmenil som chybovú funkciu na QueryRMSE, ktorá, súdiac podľa dokumentácie catboost, konverguje rýchlejšie. Nakoniec som dosiahol rovnaké výsledky ako pri tréningu na klasifikáciu, ale súbory týchto dvoch modelov dali dobrý nárast, čo ma vynieslo na prvé miesto na všetkých troch súťažiach.
5 minút pred uzavretím online fázy súťaže „Collaborative Systems“ ma Sergey Shalnov posunul na druhé miesto. Spoločne sme kráčali po ďalšej ceste.
Príprava na fázu offline
Mali sme zaručené víťazstvo v online fáze s grafickou kartou RTX 2080 TI, ale hlavná cena 300 000 rubľov a pravdepodobne aj konečné prvé miesto nás prinútili tieto 2 týždne pracovať.
Ako sa ukázalo, Sergey tiež používal catboost. Vymieňali sme si nápady a funkcie a ja som sa o tom dozvedel ktorý obsahoval odpovede na mnohé moje otázky, a dokonca aj na tie, ktoré som dovtedy ešte nemal.
Zobrazenie správy ma priviedlo k myšlienke, že musíme vrátiť všetky parametre na predvolenú hodnotu a nastavenia vykonať veľmi opatrne a až po oprave súboru funkcií. Teraz jeden tréning trval asi 15 hodín, ale jednému modelu sa podarilo získať rýchlosť lepšiu ako v súbore s hodnotením.
Generovanie funkcií
V súťaži Collaborative Systems je veľké množstvo funkcií hodnotených ako dôležité pre model. Napríklad, auditweights_spark_svd - najdôležitejší znak, ale neexistujú žiadne informácie o tom, čo to znamená. Myslel som, že by stálo za to spočítať rôzne agregáty na základe dôležitých vlastností. Napríklad priemer auditweights_spark_svd podľa používateľa, skupiny, objektu. To isté možno vypočítať pomocou údajov, na ktorých sa nevykonáva žiadny tréning a cieľ = 1, teda priemer auditweights_spark_svd používateľom podľa predmetov, ktoré sa mu páčili. Okrem toho dôležité znaky auditweights_spark_svd, bolo ich viacero. Tu sú niektoré z nich:
- auditweightsCtrGender
- auditweightsCtrHigh
- userOwnerCounterCreateLikes
Napríklad priemer auditweightsCtrGender podľa userId sa to ukázalo ako dôležitá vlastnosť, rovnako ako priemerná hodnota userOwnerCounterCreateLikes podľa userId+ownerId. Už toto by vás malo prinútiť myslieť si, že musíte pochopiť význam polí.
Tiež dôležité funkcie boli auditweightsLikesCount и auditweightsShowsCount. Rozdelením jedného od druhého sa získala ešte dôležitejšia vlastnosť.
Únik údajov
Konkurenčné a výrobné modelovanie sú veľmi odlišné úlohy. Pri príprave dát je veľmi ťažké zohľadniť všetky detaily a nesprostredkovať v teste nejaké netriviálne informácie o cieľovej premennej. Ak vytvárame produkčné riešenie, pokúsime sa vyhnúť používaniu dátových únikov pri trénovaní modelu. Ale ak chceme vyhrať súťaž, potom sú úniky dát tou najlepšou vlastnosťou.
Po preštudovaní údajov to môžete vidieť podľa hodnôt objectId auditweightsLikesCount и auditweightsShowsCount zmena, čo znamená, že pomer maximálnych hodnôt týchto funkcií bude odrážať po konverzii oveľa lepšie ako pomer v čase zobrazenia.
Prvý únik, ktorý sme našli, je auditweightsLikesCountMax/auditweightsShowsCountMax.
Čo ak sa však na údaje pozrieme bližšie? Zoraďme podľa dátumu predstavenia a získame:
| objectId | ID používateľa | auditweightsShowsCount | auditweightsLikesCount | cieľ (páči sa mi) |
|---|---|---|---|---|
| 1 | 1 | 12 | 3 | pravdepodobne nie |
| 1 | 2 | 15 | 3 | Možno áno |
| 1 | 3 | 16 | 4 |
Bolo prekvapujúce, keď som našiel prvý takýto príklad a ukázalo sa, že moja predpoveď sa nenaplnila. Ale berúc do úvahy skutočnosť, že maximálne hodnoty týchto charakteristík v rámci objektu vzrástli, neboli sme leniví a rozhodli sme sa nájsť auditweightsShowsCountNext и auditweightsLikesCountNext, teda hodnoty v nasledujúcom časovom okamihu. Pridaním funkcie
(auditweightsShowsCountNext-auditweightsShowsCount)/(auditweightsLikesCount-auditweightsLikesCountNext) rýchlo sme urobili prudký skok.
Podobné úniky by sa dali použiť nájdením nasledujúcich hodnôt pre userOwnerCounterCreateLikes v rámci userId+ownerId a napr. auditweightsCtrGender v rámci objectId+userGender. Našli sme 6 podobných polí s únikmi a vytiahli z nich čo najviac informácií.
V tom čase sme z kolaboratívnych funkcií vyžmýkali čo najviac informácií, ale nevrátili sme sa k obrázkovým a textovým súťažiam. Mal som skvelý nápad skontrolovať: koľko dávajú funkcie priamo založené na obrázkoch alebo textoch v relevantných súťažiach?
V súťažiach obrázkov a textov sa nevyskytli žiadne úniky, ale dovtedy som vrátil predvolené parametre catboost, vyčistil kód a pridal niekoľko funkcií. Celková suma bola:
| rozhodnutie | čoskoro |
|---|---|
| Maximálne s obrázkami | 0.6411 |
| Maximálne žiadne obrázky | 0.6297 |
| Výsledok druhého miesta | 0.6295 |
| rozhodnutie | čoskoro |
|---|---|
| Maximálne s textami | 0.666 |
| Maximálne bez textov | 0.660 |
| Výsledok druhého miesta | 0.656 |
| rozhodnutie | čoskoro |
|---|---|
| Maximálne v spolupráci | 0.745 |
| Výsledok druhého miesta | 0.723 |
Bolo zrejmé, že je nepravdepodobné, že by sme boli schopní vytlačiť veľa z textov a obrázkov, a keď sme vyskúšali niekoľko najzaujímavejších nápadov, prestali sme s nimi pracovať.
Ďalšia generácia funkcií v kolaboratívnych systémoch nepriniesla nárast a začali sme hodnotiť. V online fáze mi súbor klasifikácie a hodnotenia priniesol malý nárast, ako sa ukázalo, pretože som klasifikáciu podtrénoval. Žiadna z chybových funkcií, vrátane YetiRanlPairwise, nepriniesla ani zďaleka taký výsledok ako LogLoss (0,745 vs. 0,725). Stále existovala nádej pre QueryCrossEntropy, ktorú sa nepodarilo spustiť.
Offline scéna
Vo fáze offline zostala štruktúra údajov rovnaká, ale došlo k malým zmenám:
- identifikátory userId, objectId, ownerId boli opätovne randomizované;
- viaceré nápisy boli odstránené a viaceré boli premenované;
- údaje sa zvýšili približne 1,5-krát.
Okrem uvedených ťažkostí tu bolo jedno veľké plus: tímu bol pridelený veľký server s RTX 2080TI. Htop ma baví už dlho.
Bola tu len jedna myšlienka – jednoducho reprodukovať to, čo už existuje. Po niekoľkých hodinách strávených nastavovaním prostredia na serveri sme postupne začali overovať, či sú výsledky reprodukovateľné. Hlavným problémom, ktorému čelíme, je nárast objemu dát. Rozhodli sme sa trochu znížiť záťaž a nastavili sme parameter catboost ctr_complexity=1. Tým sa rýchlosť trochu zníži, ale môj model začal fungovať, výsledok bol dobrý - 0,733. Sergey, na rozdiel odo mňa, nerozdelil údaje na 2 časti a trénoval na všetkých údajoch, hoci to prinieslo najlepšie výsledky v online fáze, v offline fáze bolo veľa problémov. Ak by sme vzali všetky funkcie, ktoré sme vygenerovali, a pokúsili sa ich vložiť do catboostu, potom by v online fáze nič nefungovalo. Sergej robil optimalizáciu typov, napríklad konvertoval typy float64 na float32. Informácie o optimalizácii pamäte nájdete v pandách. Výsledkom bolo, že Sergey trénoval na CPU pomocou všetkých údajov a dostal asi 0,735.
Tieto výsledky stačili na víťazstvo, ale skryli sme našu skutočnú rýchlosť a nemohli sme si byť istí, že ostatné tímy nerobia to isté.
Bojujte do posledného
Ladenie Catboost
Naše riešenie bolo plne reprodukované, pridali sme funkcie textových údajov a obrázkov, takže zostávalo už len doladiť parametre catboost. Sergey trénoval na CPU s malým počtom iterácií a ja som trénoval na tom s ctr_complexity=1. Zostal jeden deň a ak ste pridali iterácie alebo zvýšili ctr_complexity, ráno by ste mohli dosiahnuť ešte lepšiu rýchlosť a chodiť celý deň.
Vo fáze offline môžu byť rýchlosti veľmi ľahko skryté jednoduchým výberom nie najlepšieho riešenia na stránke. Očakávali sme drastické zmeny v rebríčku v posledných minútach pred uzavretím prihlášok a rozhodli sme sa nezastaviť.
Z Anninho videa som sa dozvedel, že na zlepšenie kvality modelu je najlepšie vybrať nasledujúce parametre:
- miera_učenia — Predvolená hodnota sa vypočíta na základe veľkosti súboru údajov. Zvýšenie miery učenia si vyžaduje zvýšenie počtu iterácií.
- l2_leaf_reg — Regularizačný koeficient, predvolená hodnota 3, prednostne si vyberte od 2 do 30. Zníženie hodnoty vedie k zvýšeniu previsu.
- teplota vrecovania — pridáva náhodnosť k hmotnostiam objektov vo vzorke. Predvolená hodnota je 1, pričom váhy sa čerpajú z exponenciálneho rozdelenia. Zníženie hodnoty vedie k zvýšeniu nadmerného zaťaženia.
- náhodná_sila — Ovplyvňuje výber rozdelenia v konkrétnej iterácii. Čím vyššia je hodnota random_strength, tým vyššia je pravdepodobnosť, že sa vyberie rozdelenie s nízkou dôležitosťou. Pri každej ďalšej iterácii sa náhodnosť znižuje. Zníženie hodnoty vedie k zvýšeniu nadmerného zaťaženia.
Ostatné parametre majú na konečný výsledok oveľa menší vplyv, preto som sa ich nesnažil vyberať. Jedna iterácia tréningu na mojom súbore údajov GPU s ctr_complexity=1 trvala 20 minút a vybrané parametre na zmenšenom súbore údajov sa mierne líšili od optimálnych parametrov na kompletnom súbore údajov. Nakoniec som urobil asi 30 iterácií na 10% údajov a potom ďalších asi 10 iterácií na všetkých dátach. Ukázalo sa niečo takéto:
- miera_učenia Zvýšil som o 40 % z predvolenej hodnoty;
- l2_leaf_reg nechal to rovnaké;
- teplota vrecovania и náhodná_sila znížená na 0,8.
Môžeme konštatovať, že model bol podtrénovaný s predvolenými parametrami.
Bol som veľmi prekvapený, keď som videl výsledok v tabuľke výsledkov:
| Model | model 1 | model 2 | model 3 | súbor |
|---|---|---|---|---|
| Bez ladenia | 0.7403 | 0.7404 | 0.7404 | 0.7407 |
| S tuningom | 0.7406 | 0.7405 | 0.7406 | 0.7408 |
Sám som dospel k záveru, že ak nie je potrebná rýchla aplikácia modelu, potom je lepšie nahradiť výber parametrov súborom niekoľkých modelov s neoptimalizovanými parametrami.
Sergey optimalizoval veľkosť súboru údajov na jeho spustenie na GPU. Najjednoduchšou možnosťou je odrezať časť údajov, ale to sa dá urobiť niekoľkými spôsobmi:
- postupne odstraňovať najstaršie údaje (začiatkom februára), kým sa súbor údajov nezačne zmestiť do pamäte;
- odstrániť prvky s najnižšou dôležitosťou;
- odstrániť userId, pre ktoré existuje iba jeden záznam;
- ponechajte iba ID používateľov, ktoré sú v teste.
A nakoniec vytvorte súbor zo všetkých možností.
Posledný súbor
Do neskorého večera posledného dňa sme zostavili súbor našich modelov, ktorý dal 0,742. Cez noc som spustil svoj model s ctr_complexity=2 a namiesto 30 minút trénoval 5 hodín. Až o 4:0,7433 sa to počítalo a ja som urobil posledný súbor, ktorý dal XNUMX na verejnej priečke.
V dôsledku rôznych prístupov k riešeniu problému naše predpovede neboli silne korelované, čo prinieslo dobrý nárast súboru. Ak chcete získať dobrý súbor, je lepšie použiť predpovede predpovedí surového modelu (prediction_type='RawFormulaVal') a nastaviť scale_pos_weight=neg_count/pos_count.
Na webovej stránke môžete vidieť .
Iné riešenia
Mnoho tímov postupovalo podľa kánonov algoritmov odporúčacieho systému. Ja, nie som odborník v tejto oblasti, ich nemôžem zhodnotiť, no pamätám si 2 zaujímavé riešenia.
- . Nikolay, zamestnanec Mail.ru, sa neuchádzal o ceny, takže jeho cieľom nebolo dosiahnuť maximálnu rýchlosť, ale získať ľahko škálovateľné riešenie.
- Rozhodnutie víťazného tímu o Cene poroty na základe , umožnilo veľmi dobré zhlukovanie obrázkov bez ručnej práce.
Záver
Čo mi najviac utkvelo v pamäti:
- Ak sú v údajoch kategorické prvky a viete, ako správne urobiť cieľové kódovanie, je stále lepšie vyskúšať catboost.
- Ak sa zúčastňujete súťaže, nemali by ste strácať čas výberom iných parametrov ako learning_rate a iterations. Rýchlejšie riešenie je vytvoriť súbor niekoľkých modelov.
- Zosilnenia sa môžu učiť na GPU. Catboost sa dokáže veľmi rýchlo učiť na GPU, ale zaberá veľa pamäte.
- Počas vývoja a testovania nápadov je lepšie nastaviť malé rsm~=0.2 (len CPU) a ctr_complexity=1.
- Na rozdiel od iných tímov súbor našich modelov dal veľký nárast. Len sme si vymieňali nápady a písali v rôznych jazykoch. Mali sme odlišný prístup k rozdeleniu údajov a myslím si, že každý mal svoje vlastné chyby.
- Nie je jasné, prečo bola optimalizácia hodnotenia vykonaná horšie ako optimalizácia klasifikácie.
- Získal som nejaké skúsenosti s prácou s textami a porozumel som tomu, ako sa vytvárajú systémy odporúčaní.
Ďakujeme organizátorom za emócie, vedomosti a získané ceny.
Zdroj: hab.com