Helmi-maaliskuussa 2019 järjestettiin kilpailu sosiaalisen verkoston syötteen paremmuusjärjestykseen , jossa joukkueemme sijoittui ykköseksi. Artikkelissa kerron kilpailun järjestämisestä, kokeilemamme menetelmistä ja catboost-asetuksista big datan harjoitteluun.
SNA Hackathon
Tämä on kolmas kerta, kun hackathon tällä nimellä järjestetään. Sen järjestää sosiaalinen verkosto ok.ru, vastaavasti tehtävä ja tiedot liittyvät suoraan tähän sosiaaliseen verkostoon.
SNA (social network analysis) ei tässä tapauksessa ymmärretä paremmin sosiaalisen graafin analyysinä, vaan sosiaalisen verkoston analyysinä.
- Vuonna 2014 tehtävänä oli ennustaa julkaisun saamien tykkäysten määrää.
- Vuonna 2016 - VVZ-tehtävä (ehkä olet tuttu), lähempänä sosiaalisen kaavion analyysiä.
- Vuonna 2019 käyttäjän syötteen luokittelu sen perusteella, kuinka todennäköisesti käyttäjä pitää julkaisusta.
Vuodesta 2014 en osaa sanoa, mutta vuosina 2016 ja 2019 vaadittiin data-analyysikykyjen lisäksi myös big datan kanssa työskentelytaitoja. Luulen, että koneoppimisen ja isojen tietojenkäsittelyongelmien yhdistelmä houkutteli minut näihin kilpailuihin, ja kokemukseni näiltä alueilta auttoi minua voittamaan.
mlbootcamp
Vuonna 2019 kilpailu järjestettiin alustalla .
Kilpailu alkoi verkossa 7. helmikuuta ja koostui 3 tehtävästä. Kuka tahansa voi rekisteröityä sivustolle, ladata ja lastata autoasi muutamaksi tunniksi. Online-vaiheen päätteeksi 15. maaliskuuta kunkin show jumping -tapahtuman 15 parasta kutsuttiin Mail.ru-toimistoon offline-vaiheeseen, joka järjestettiin 30. maaliskuuta - 1. huhtikuuta.
Tehtävä
Lähdetiedot sisältävät käyttäjätunnukset (userId) ja viestitunnukset (objectId). Jos käyttäjälle näytettiin viesti, data sisältää rivin, joka sisältää userId:n, objectId:n, käyttäjien reaktiot tähän viestiin (palaute) sekä joukon erilaisia ominaisuuksia tai linkkejä kuviin ja teksteihin.
| käyttäjätunnus | objektitunnus | omistajatunnus | palaute | kuvien |
|---|---|---|---|---|
| 3555 | 22 | 5677 | [tykkäsin, napsautettiin] | [hash1] |
| 12842 | 55 | 32144 | [en pitänyt] | [hash2, hash3] |
| 13145 | 35 | 5677 | [klikattu, jaettu] | [hash2] |
Testiaineisto sisältää samanlaisen rakenteen, mutta palautekenttä puuttuu. Tehtävänä on ennustaa "tykätty"-reaktion esiintyminen palautekentässä.
Lähetystiedostolla on seuraava rakenne:
| käyttäjätunnus | Lajiteltu luettelo[objektin tunnus] |
|---|---|
| 123 | 78,13,54,22 |
| 128 | 35,61,55 |
| 131 | 35,68,129,11 |
Mittari on käyttäjien keskimääräinen ROC AUC.
Tarkempi kuvaus tiedoista löytyy osoitteesta. Sieltä voi myös ladata dataa, mukaan lukien testit ja kuvat.
Online-lava
Verkkovaiheessa tehtävä jaettiin 3 osaan
- — sisältää kaikki ominaisuudet paitsi kuvia ja tekstejä;
- — sisältää vain tietoja kuvista;
- — sisältää tietoa vain teksteistä.
Offline-vaihe
Offline-vaiheessa data sisälsi kaikki ominaisuudet, kun taas tekstit ja kuvat olivat harvassa. Aineistossa oli 1,5 kertaa enemmän rivejä, joita oli jo paljon.
Ongelmanratkaisu
Koska teen CV:tä töissä, aloitin matkani tässä kilpailussa ”Kuvat” -tehtävällä. Annetut tiedot olivat userId, objectId, ownerId (ryhmä, jossa viesti julkaistiin), aikaleimat julkaisun luomista ja näyttämistä varten sekä tietysti tämän viestin kuva.
Useiden aikaleimoihin perustuvien ominaisuuksien luomisen jälkeen seuraava idea oli ottaa toiseksi viimeinen kerros neuronista, joka on esiopetettu imagenetissä ja lähettää nämä upotukset tehostukseen.
Tulokset eivät olleet vaikuttavia. Upotukset imagenet-neuronista ovat merkityksettömiä, ajattelin, että minun täytyy tehdä oma autoenkooderi.
Se vei paljon aikaa, eikä tulos parantunut.
Ominaisuuden sukupolvi
Kuvien käsittely vie paljon aikaa, joten päätin tehdä jotain yksinkertaisempaa.
Kuten heti huomaat, tietojoukossa on useita kategorisia ominaisuuksia, ja otin vain catboostin, jotta se ei vaivautuisi liikaa. Ratkaisu oli erinomainen, ilman asetuksia pääsin heti tulostaulukon ensimmäiselle riville.
Dataa on melko paljon ja se on aseteltu parkettimuotoon, joten kahdesti miettimättä otin scalan ja aloin kirjoittaa kaiken kipinällä.
Yksinkertaisimmat ominaisuudet, jotka lisäsivät kasvua kuin kuvien upottaminen:
- kuinka monta kertaa objectId, userId ja ownerId esiintyivät tiedoissa (pitäisi korreloida suosion kanssa);
- kuinka monta viestiä userId on nähnyt omistajaId:ltä (pitäisi korreloida käyttäjän kiinnostuksen kanssa ryhmää kohtaan);
- kuinka monta yksilöllistä userId:tä katseli viestejä omistajatunnukselta (heijastaa ryhmän yleisön kokoa).
Aikaleimoista oli mahdollista saada aika vuorokaudesta, jolloin käyttäjä katsoi syötettä (aamu/iltapäivä/ilta/yö). Yhdistämällä nämä luokat voit jatkaa ominaisuuksien luomista:
- kuinka monta kertaa userId kirjautui sisään illalla;
- milloin tämä viesti useimmiten näytetään (objectId) ja niin edelleen.
Kaikki tämä paransi mittareita vähitellen. Mutta harjoitustietojoukon koko on noin 20 miljoonaa tietuetta, joten ominaisuuksien lisääminen hidasti harjoittelua huomattavasti.
Olen miettinyt uudelleen lähestymistapaani datan käyttöön. Vaikka tiedot ovat aikariippuvaisia, en nähnyt selviä tietovuotoja "tulevaisuudessa", kuitenkin, varmuuden vuoksi, rikoin ne näin:
Meille tarjottu koulutuspaketti (helmikuu ja maaliskuun 2 viikkoa) jaettiin kahteen osaan.
Mallia koulutettiin viimeisten N päivän tietojen perusteella. Yllä kuvatut aggregaatiot perustuivat kaikkiin tietoihin, mukaan lukien testi. Samalla on ilmestynyt dataa, jolle on mahdollista rakentaa erilaisia kohdemuuttujan koodauksia. Yksinkertaisin tapa on käyttää uudelleen koodia, joka luo jo uusia ominaisuuksia, ja syöttää sille tietoja, joihin sitä ei opeteta, ja kohde = 1.
Saimme siis samanlaisia ominaisuuksia:
- Kuinka monta kertaa userId on nähnyt viestin ryhmässä ownerId;
- Kuinka monta kertaa userId piti viestistä ryhmässä ownerId;
- Niiden viestien prosenttiosuus, joista userId on pitänyt omistajaId:stä.
Eli kävi ilmi keskimääräinen kohdekoodaus osan tietojoukosta kategoristen ominaisuuksien eri yhdistelmille. Periaatteessa catboost rakentaa myös kohdekoodausta ja tästä näkökulmasta ei ole mitään hyötyä, mutta esimerkiksi tuli mahdolliseksi laskea tämän ryhmän viesteistä tykänneiden yksittäisten käyttäjien määrä. Samalla saavutettiin päätavoite - tietojoukkoani pienennettiin useita kertoja ja ominaisuuksien luomista oli mahdollista jatkaa.
Vaikka catboost voi rakentaa koodauksen vain tykätyn reaktion perusteella, palautteessa on muita reaktioita: uudelleenjaettu, ei-tykätty, ei-tykätty, napsautettu, ohitettu, koodaukset, jotka voidaan tehdä manuaalisesti. Laskin uudelleen kaikenlaiset aggregaatit ja poistin vähämerkityksisiä ominaisuuksia, jotta tietojoukko ei kasvaisi.
Tuolloin olin ykkössijalla leveällä marginaalilla. Ainoa hämmentävä asia oli, että kuvien upotukset eivät juurikaan kasvaneet. Tuli idea antaa kaikkensa catboostiin. Klusteroimme Kmeans-kuvat ja saamme uuden kategorisen ominaisuuden imageCat.
Tässä on joitain luokkia manuaalisen suodatuksen ja KMeansista saatujen klusterien yhdistämisen jälkeen.
ImageCatin perusteella luomme:
- Uudet kategorialliset ominaisuudet:
- Mitä imageCatia useimmin tarkasteltiin userId;
- Mikä imageCat näyttää useimmiten omistajan tunnuksen;
- Mistä imageCatista userId piti eniten;
- Erilaisia laskureita:
- Kuinka monta yksilöllistä imageCat katsoi käyttäjätunnusta;
- Noin 15 samanlaista ominaisuutta sekä kohdekoodaus, kuten yllä on kuvattu.
Tekstit
Kuvakilpailun tulokset sopivat minulle ja päätin kokeilla tekstejä. En ole ennen paljon työskennellyt tekstien parissa ja typerästi tapain päivän tf-idf:llä ja svd:llä. Sitten näin perustilan doc2vecillä, joka tekee juuri sen, mitä tarvitsen. Muokattuani hieman doc2vec-parametreja, sain tekstin upotuksia.
Ja sitten yksinkertaisesti käytin uudelleen kuvien koodia, jossa korvasin kuvien upotukset tekstin upotuksilla. Tuloksena sain 2. sijan tekstikilpailussa.
Yhteistyöjärjestelmä
Jäljellä oli yksi kilpailu, jota en ollut vielä "töstänyt" kepillä, ja tulostaulukon AUC:n perusteella tämän kilpailun tuloksilla olisi pitänyt olla suurin vaikutus offline-vaiheeseen.
Otin kaikki lähdetiedoissa olevat ominaisuudet, valitsin kategorisiksi ja laskin samat aggregaatit kuin kuville, paitsi itse kuviin perustuvista ominaisuuksista. Pelkästään tämän laittaminen catboostiin sai minut 2. sijalle.
Catboostin optimoinnin ensimmäiset askeleet
Yksi ensimmäinen ja kaksi toista sijaa ilahduttivat minua, mutta ymmärrys siitä, etten ollut tehnyt mitään erityistä, tarkoittaa, että voin odottaa sijoitusten menetystä.
Kilpailun tavoitteena on asettaa postaukset paremmuusjärjestykseen käyttäjän sisällä, ja koko tämän ajan ratkaisin luokitteluongelmaa eli optimoin väärää mittaria.
Annan yksinkertaisen esimerkin:
| käyttäjätunnus | objektitunnus | ennustus | perusteellinen totuus |
|---|---|---|---|
| 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 |
Tehdään pieni uudelleenjärjestely
| käyttäjätunnus | objektitunnus | ennustus | perusteellinen totuus |
|---|---|---|---|
| 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 |
Saamme seuraavat tulokset:
| Malli | AUC | Käyttäjä1 AUC | Käyttäjä2 AUC | keskimääräinen AUC |
|---|---|---|---|---|
| Vaihtoehto 1 | 0,8 | 1,0 | 0,0 | 0,5 |
| Vaihtoehto 2 | 0,7 | 0,75 | 1,0 | 0,875 |
Kuten näet, yleisen AUC-mittarin parantaminen ei tarkoita käyttäjän keskimääräisen AUC-mittarin parantamista.
Catboost laatikosta. Luin sijoitusmittareista, kun käytät catboostia ja aseta YetiRankPairwise harjoittelemaan yön yli. Tulos ei ollut vaikuttava. Päätin, että olin alikoulutettu, vaihdoin virhetoiminnon QueryRMSE:ksi, joka catboost-dokumentaation perusteella konvergoi nopeammin. Lopulta sain samat tulokset kuin luokittelua harjoitellessa, mutta näiden kahden mallin kokoonpanot antoivat hyvän nousun, mikä toi minut ykkössijalle kaikissa kolmessa kilpailussa.
5 minuuttia ennen "Yhteistyöjärjestelmät" -kilpailun verkkovaiheen päättymistä Sergei Shalnov nosti minut toiselle sijalle. Kävelimme yhdessä pidemmän polun.
Valmistautuminen offline-vaiheeseen
Online-vaiheen voitto taattiin RTX 2080 TI -näytönohjaimella, mutta 300 000 ruplan pääpalkinto ja todennäköisesti jopa lopullinen ykköspaikka pakottivat meidät työskentelemään nämä 2 viikkoa.
Kuten kävi ilmi, Sergey käytti myös catboostia. Vaihdoimme ideoita ja ominaisuuksia, ja opin joka sisälsi vastaukset moniin kysymyksiini, ja jopa niihin, joita minulla ei ollut siihen mennessä vielä ollut.
Raporttia katsellessa sain ajatuksen, että meidän on palautettava kaikki parametrit oletusarvoihin ja tehtävä asetukset erittäin huolellisesti ja vasta ominaisuuksien korjaamisen jälkeen. Nyt yksi harjoittelu kesti noin 15 tuntia, mutta yksi malli onnistui saamaan paremman nopeuden kuin sijoituksella varustetussa kokoonpanossa.
Ominaisuuden sukupolvi
Collaborative Systems -kilpailussa suuri joukko ominaisuuksia arvioidaan mallin kannalta tärkeiksi. Esimerkiksi, auditweights_spark_svd - tärkein merkki, mutta ei ole tietoa siitä, mitä se tarkoittaa. Ajattelin, että kannattaisi laskea eri aggregaatit tärkeiden ominaisuuksien perusteella. Esimerkiksi keskimääräinen auditweights_spark_svd käyttäjän, ryhmän tai objektin mukaan. Sama voidaan laskea käyttämällä dataa, jolle ei harjoiteta ja tavoite = 1, eli keskiarvo auditweights_spark_svd käyttäjä kohteiden mukaan, joista hän piti. Lisäksi tärkeitä merkkejä auditweights_spark_svd, niitä oli useita. Tässä muutama niistä:
- auditweightsCtrGender
- auditweightsCtrHigh
- userOwnerCounterCreateLikes
Esimerkiksi keskiarvo auditweightsCtrGender userId:n mukaan se osoittautui tärkeäksi ominaisuudeksi, aivan kuten keskiarvokin userOwnerCounterCreateLikes käyttäjätunnus+omistajatunnus. Tämän pitäisi jo saada sinut ajattelemaan, että sinun on ymmärrettävä kenttien merkitys.
Myös tärkeitä ominaisuuksia olivat auditweightsLikesCount и auditweightsShowsCount. Jakamalla toinen toisella, saatiin vielä tärkeämpi ominaisuus.
Tietovuotoja
Kilpailu ja tuotannon mallinnus ovat hyvin erilaisia tehtäviä. Dataa valmisteltaessa on erittäin vaikea ottaa huomioon kaikki yksityiskohdat ja olla välittämättä jotain ei-triviaalia tietoa testin kohdemuuttujasta. Jos luomme tuotantoratkaisua, pyrimme välttämään tietovuotojen käyttöä mallin koulutuksessa. Mutta jos haluamme voittaa kilpailun, tietovuodot ovat parhaita ominaisuuksia.
Tutkittuasi tiedot voit nähdä sen objektiId-arvojen mukaan auditweightsLikesCount и auditweightsShowsCount muutos, mikä tarkoittaa, että näiden ominaisuuksien maksimiarvojen suhde kuvastaa jälkeistä muuntamista paljon paremmin kuin näyttöhetken suhde.
Ensimmäinen löydetty vuoto on auditweightsLikesCountMax/auditweightsShowsCountMax.
Mutta entä jos tarkastelemme tietoja tarkemmin? Lajittele esityspäivämäärän mukaan ja saa:
| objektitunnus | käyttäjätunnus | auditweightsShowsCount | auditweightsLikesCount | kohde (on tykätty) |
|---|---|---|---|---|
| 1 | 1 | 12 | 3 | luultavasti ei |
| 1 | 2 | 15 | 3 | ehkä kyllä |
| 1 | 3 | 16 | 4 |
Oli yllättävää, kun löysin ensimmäisen tällaisen esimerkin ja kävi ilmi, että ennustukseni ei toteutunut. Mutta kun otetaan huomioon se tosiasia, että näiden ominaisuuksien maksimiarvot esineessä nousivat, emme olleet laiskoja ja päätimme löytää auditweightsShowsCountNext и auditweightsLikesCountNext, eli arvot seuraavalla hetkellä. Lisäämällä ominaisuuden
(auditweightsShowsCountNext-auditweightsShowsCount)/(auditweightsLikesCount-auditweightsLikesCountNext) teimme jyrkän hypyn nopeasti.
Samanlaisia vuotoja voidaan käyttää etsimällä seuraavat arvot userOwnerCounterCreateLikes sisällä userId+ownerId ja esim. auditweightsCtrGender sisällä objectId+userGender. Löysimme 6 samanlaista kenttää, joissa oli vuotoja ja poimimme niistä mahdollisimman paljon tietoa.
Siihen mennessä olimme puristaneet mahdollisimman paljon tietoa yhteistyöominaisuuksista, mutta emme palanneet kuva- ja tekstikilpailuihin. Tuli hyvä idea tarkistaa: kuinka paljon suoraan kuviin tai teksteihin perustuvat ominaisuudet antavat asiaankuuluvissa kilpailuissa?
Kuva- ja tekstikilpailuissa ei ollut vuotoja, mutta siihen mennessä olin palauttanut oletusarvoiset catboost-parametrit, siivonnut koodin ja lisännyt muutamia ominaisuuksia. Yhteensä oli:
| päätös | pian |
|---|---|
| Maksimi kuvilla | 0.6411 |
| Enintään ei kuvia | 0.6297 |
| Toisen sijan tulos | 0.6295 |
| päätös | pian |
|---|---|
| Maksimi teksteillä | 0.666 |
| Maksimi ilman tekstejä | 0.660 |
| Toisen sijan tulos | 0.656 |
| päätös | pian |
|---|---|
| Yhteistyössä maksimissaan | 0.745 |
| Toisen sijan tulos | 0.723 |
Kävi selväksi, että tuskin pystymme saamaan paljon irti teksteistä ja kuvista, ja kokeiltuamme paria mielenkiintoisinta ideaa lopetimme työskentelyn niiden kanssa.
Yhteistyöjärjestelmien ominaisuuksien lisääminen ei tuonut lisäystä, ja aloitimme sijoituksen. Verkkovaiheessa luokittelu ja ranking-yhtye antoi minulle pienen lisäyksen, mikä kävi ilmi, koska olin alikouluttanut luokituksen. Mikään virhefunktioista, mukaan lukien YetiRanlPairwise, ei tuottanut lähellekään LogLossin tulosta (0,745 vs. 0,725). Vielä oli toivoa QueryCrossEntropysta, jota ei voitu käynnistää.
Offline-vaihe
Offline-vaiheessa tietorakenne pysyi samana, mutta pieniä muutoksia tapahtui:
- tunnisteet userId, objectId, ownerId satunnaistettiin uudelleen;
- useita kylttejä poistettiin ja useat nimettiin uudelleen;
- data on kasvanut noin 1,5-kertaiseksi.
Listattujen vaikeuksien lisäksi oli yksi iso plussa: joukkueelle osoitettiin suuri palvelin RTX 2080TI:llä. Olen nauttinut htopista pitkään.
Oli vain yksi idea - yksinkertaisesti toistaa jo olemassa oleva. Vietettyämme muutaman tunnin ympäristön asennuksessa palvelimelle, aloimme vähitellen varmistaa, että tulokset olivat toistettavissa. Suurin kohtaamamme ongelma on tietomäärän kasvu. Päätimme vähentää kuormitusta hieman ja asettimme catboost-parametrin ctr_complexity=1. Tämä hidastaa nopeutta hieman, mutta mallini alkoi toimia, tulos oli hyvä - 0,733. Sergey, toisin kuin minä, ei jakanut tietoja kahteen osaan ja harjoitteli kaikkia tietoja, vaikka tämä antoi parhaat tulokset online-vaiheessa, offline-vaiheessa oli monia vaikeuksia. Jos ottaisimme kaikki luomamme ominaisuudet käyttöön ja yrittäisimme työntää ne catboostiin, mikään ei toimisi verkkovaiheessa. Sergey teki tyyppioptimoinnin, esimerkiksi muuntaen float2-tyypit float64:ksi. Löydät tietoa pandan muistin optimoinnista. Seurauksena oli, että Sergey harjoitteli CPU:ta käyttämällä kaikkia tietoja ja sai noin 0,735.
Nämä tulokset riittivät voittoon, mutta piilotimme todellisen nopeudemme emmekä voineet olla varmoja siitä, etteivätkö muut joukkueet tekisi samoin.
Taistele viimeiseen asti
Catboostin viritys
Ratkaisumme toistettiin täysin, lisäsimme tekstidatan ja kuvien ominaisuudet, joten jäljellä oli vain catboost-parametrien virittäminen. Sergey harjoitteli CPU:ta pienellä iteraatiomäärällä, ja minä harjoittelin sitä, jossa ctr_complexity=1. Jäljellä oli yksi päivä, ja jos vain lisäisi iteraatioita tai lisäisi ctr_complexityä, niin aamulla saat vielä paremman nopeuden ja kävelet koko päivän.
Offline-vaiheessa nopeudet voidaan helposti piilottaa valitsemalla vain sivuston ei-paras ratkaisu. Odotimme dramaattisia muutoksia tulostaulukossa viimeisten minuuttien aikana ennen hakujen päättymistä ja päätimme olla lopettamatta.
Annan videosta opin, että mallin laadun parantamiseksi on parasta valita seuraavat parametrit:
- oppimisnopeus — Oletusarvo lasketaan tietojoukon koon perusteella. Oppimisnopeuden kasvattaminen vaatii iteraatioiden määrän lisäämistä.
- l2_leaf_reg — Regularisointikerroin, oletusarvo 3, mieluiten väliltä 2-30. Arvon pienentäminen johtaa ylisovituksen lisääntymiseen.
- pussituksen_lämpötila — lisää satunnaistuksen otoksen objektien painoihin. Oletusarvo on 1, jossa painot on otettu eksponentiaalisesta jakaumasta. Arvon pienentäminen johtaa ylikuormituksen lisääntymiseen.
- satunnainen_voimakkuus — Vaikuttaa splittien valintaan tietyssä iteraatiossa. Mitä korkeampi random_strength, sitä suurempi mahdollisuus valita vähämerkityksinen jako. Jokaisella myöhemmällä iteraatiolla satunnaisuus pienenee. Arvon pienentäminen johtaa ylikuormituksen lisääntymiseen.
Muilla parametreilla on paljon pienempi vaikutus lopputulokseen, joten en yrittänyt valita niitä. Yksi harjoituksen iteraatio GPU-tietojoukossani ctr_complexity=1 kesti 20 minuuttia, ja valitut parametrit supistetussa tietojoukossa poikkesivat hieman koko tietojoukon optimaalisista parametreista. Lopulta tein noin 30 iteraatiota 10 %:lle tiedoista ja sitten vielä noin 10 iteraatiota kaikille tiedoille. Siitä tuli jotain tällaista:
- oppimisnopeus Lisäsin oletusarvosta 40 %;
- l2_leaf_reg jätti sen saman;
- pussituksen_lämpötila и satunnainen_voimakkuus vähennetty 0,8:aan.
Voimme päätellä, että malli oli alikoulutettu oletusparametreilla.
Olin hyvin yllättynyt, kun näin tuloksen tulostaulukossa:
| Malli | malli 1 | malli 2 | malli 3 | yhtye |
|---|---|---|---|---|
| Ilman viritystä | 0.7403 | 0.7404 | 0.7404 | 0.7407 |
| Virityksen kanssa | 0.7406 | 0.7405 | 0.7406 | 0.7408 |
Päättelin itse, että jos mallin nopeaa soveltamista ei tarvita, on parempi korvata parametrien valinta useiden mallien joukolla, jossa käytetään ei-optimoituja parametreja.
Sergey optimoi tietojoukon kokoa ajaakseen sitä GPU:ssa. Yksinkertaisin vaihtoehto on leikata osa tiedoista, mutta se voidaan tehdä useilla tavoilla:
- poista vanhimmat tiedot vähitellen (helmikuun alussa), kunnes tietojoukko alkaa mahtua muistiin;
- poista vähiten tärkeitä ominaisuuksia;
- poista käyttäjätunnukset, joille on vain yksi merkintä;
- jätä vain testissä olevat käyttäjätunnukset.
Ja lopuksi, tee kokonaisuus kaikista vaihtoehdoista.
Viimeinen yhtye
Viimeisen päivän myöhään iltaan mennessä olimme laatineet mallistomme, joka tuotti 0,742. Yön aikana julkaisin mallini ctr_complexity=2:lla ja 30 minuutin sijaan se harjoitteli 5 tuntia. Vasta klo 4 laskettiin, ja tein viimeisen kokoonpanon, joka antoi 0,7433 julkisessa tulostaulukossa.
Erilaisten lähestymistapojen vuoksi ongelman ratkaisuun ennustuksemme eivät korreloineet vahvasti, mikä antoi hyvän lisäyksen kokonaisuuteen. Hyvän kokonaisuuden saamiseksi on parempi käyttää raakamalliennusteita ennustaa(prediction_type='RawFormulaVal') ja asettaa scale_pos_weight=neg_count/pos_count.
Sivustolla näet .
Muut ratkaisut
Monet tiimit seurasivat suositusjärjestelmän algoritmien kanoneja. Koska en ole tämän alan asiantuntija, en osaa arvioida niitä, mutta muistan 2 mielenkiintoista ratkaisua.
- . Nikolay, joka on Mail.ru:n työntekijä, ei hakenut palkintoja, joten hänen tavoitteenaan ei ollut saavuttaa maksiminopeutta, vaan saada helposti skaalautuva ratkaisu.
- Tuomariston palkinnon saaneen joukkueen päätös perustuu , mahdollistaa erittäin hyvän kuvan klusteroinnin ilman manuaalista työtä.
Johtopäätös
Mikä jäi eniten mieleeni:
- Jos tiedoissa on kategorisia ominaisuuksia ja osaat tehdä kohdekoodauksen oikein, on silti parempi kokeilla catboostia.
- Jos osallistut kilpailuun, sinun ei tule tuhlata aikaa muiden parametrien kuin learning_rate ja iteraatioiden valitsemiseen. Nopeampi ratkaisu on tehdä kokonaisuus useista malleista.
- Tehostukset voivat oppia GPU:lla. Catboost oppii erittäin nopeasti GPU:lla, mutta se syö paljon muistia.
- Ideoiden kehittämisen ja testauksen aikana on parempi asettaa pieni rsm~=0.2 (vain CPU) ja ctr_complexity=1.
- Toisin kuin muut joukkueet, malliemme kokonaisuus nosti valtavasti. Vaihdoimme vain ajatuksia ja kirjoitimme eri kielillä. Meillä oli erilainen lähestymistapa tietojen jakamiseen, ja mielestäni jokaisella oli omat buginsa.
- Ei ole selvää, miksi sijoituksen optimointi toimi huonommin kuin luokituksen optimointi.
- Sain jonkin verran kokemusta tekstien parissa työskentelemisestä ja ymmärrystä suositusjärjestelmien tekemisestä.
Kiitos järjestäjille tunteista, tiedosta ja saaduista palkinnoista.
Lähde: will.com