In Februarie-Maart 2019 is 'n sosiale netwerk-voerranglyskompetisie gehou waarin ons span die eerste plek behaal het. In die artikel sal ek praat oor die organisasie van die kompetisie, die metodes wat ons probeer het, en die katboost-instellings vir opleiding op groot data.
SNA Hackathon
Die hackathon onder hierdie naam word vir die derde keer gehou. Dit word onderskeidelik deur die sosiale netwerk ok.ru georganiseer, die taak en data is direk verwant aan hierdie sosiale netwerk.
SNA (sosiale netwerkanalise) word in hierdie geval meer korrek verstaan nie as sosiale grafiek analise nie, maar eerder as sosiale netwerk analise.
- In 2014 was die uitdaging om die aantal likes wat 'n plasing sou kry te voorspel.
- In 2016 is die VVZ-taak (jy is dalk bekend daarmee), nader aan die ontleding van 'n sosiale grafiek.
- In 2019, rangskik 'n gebruiker se stroom op grond van die waarskynlikheid dat 'n gebruiker van 'n plasing sal hou.
Ek kan nie sê oor 2014 nie, maar in 2016 en 2019 was benewens die vermoë om data te ontleed, ook vaardighede nodig om met groot data te werk. Ek dink dit was die kombinasie van masjienleer en grootdata-take wat my na hierdie kompetisies gelok het, en ervaring in hierdie gebiede het my gehelp om te wen.
mlbootcamp
In 2019 is die kompetisie op die platform gereël .
Die kompetisie het op 7 Februarie aanlyn begin en het uit 3 take bestaan. Enigeen kan op die webwerf registreer, aflaai en laai jou kar vir 'n paar uur. Aan die einde van die aanlyn-verhoog op 15 Maart is die top-15 van elke skouspring na die Mail.ru-kantoor genooi vir die vanlyn verhoog, wat van 30 Maart tot 1 April plaasgevind het.
Taak
Die brondata verskaf gebruikers-ID's (userId) en pos-ID's (objectId). As die gebruiker 'n plasing gewys is, dan bevat die data 'n reël wat userId, objectId, gebruikersreaksies op hierdie plasing (terugvoer) en 'n stel verskeie kenmerke of skakels na prente en tekste bevat.
| gebruiker-ID | objectId | eienaar-ID | terugvoer | beelde |
|---|---|---|---|---|
| 3555 | 22 | 5677 | [het gelaaik, geklik] | [hash1] |
| 12842 | 55 | 32144 | [hou nie van] | [hash2, hash3] |
| 13145 | 35 | 5677 | [geklik, herdeel] | [hash2] |
Die toetsdatastel bevat 'n soortgelyke struktuur, maar die terugvoerveld ontbreek. Die taak is om die teenwoordigheid van 'n 'like'-reaksie in die terugvoerveld te voorspel.
Die indieninglêer het die volgende struktuur:
| gebruiker-ID | SortedList[objectId] |
|---|---|
| 123 | 78,13,54,22 |
| 128 | 35,61,55 |
| 131 | 35,68,129,11 |
Metriek - gemiddelde ROC AUC deur gebruikers.
'n Meer gedetailleerde beskrywing van die data kan gevind word by. Ook daar kan jy data aflaai, insluitend toetse en prente.
Aanlyn verhoog
Op die aanlyn stadium is die taak in 3 dele verdeel
- - sluit alle kenmerke in, behalwe vir beelde en tekste;
- - sluit slegs beeldinligting in;
- - bevat slegs inligting oor tekste.
Vanlyn verhoog
Op die vanlyn stadium het die data alle kenmerke ingesluit, terwyl tekste en beelde yl was. Die rye in die datastel, wat reeds baie was, het 1,5 keer meer geword.
Die oplossing van die probleem
Aangesien ek cv by die werk doen, het ek my reis in hierdie kompetisie begin met die "Images" taak. Die data wat verskaf is, is die userId, objectId, ownerId (die groep waarin die plasing gepubliseer word), tydstempels vir die skep en vertoon van die plasing, en natuurlik die prent vir hierdie plasing.
Nadat 'n paar tydstempel-gebaseerde kenmerke gegenereer is, was die volgende idee om die voorlaaste laag van die neurale netwerk wat vooraf op imagenet opgelei is, te neem en hierdie inbeddings na 'n hupstoot te stuur.
Die resultate was nie indrukwekkend nie. Inbeddings van die beeldnetneuron is irrelevant, het ek gedink, ek moet my eie outo-enkodeerder indien.
Dit het baie tyd geneem en die resultaat het nie verbeter nie.
Kenmerkgenerasie
Om met beelde te werk neem baie tyd, en ek het besluit om iets eenvoudiger te doen.
Soos jy dadelik kan sien, is daar verskeie kategoriese kenmerke in die datastel, en om nie te veel pla nie, het ek net catboost geneem. Die oplossing was uitstekend, sonder enige instellings het ek dadelik by die eerste reël van die ranglys uitgekom.
Daar is baie data en hulle is in die parketformaat uitgelê, so sonder om twee keer te dink, het ek scala geneem en alles in vonkel begin skryf.
Die eenvoudigste kenmerke wat meer groei as beeldinbeddings gegee het:
- hoeveel keer objectId, userId en ownerId in die data voorgekom het (moet met gewildheid korreleer);
- hoeveel plasings userId vanaf eienaarId gesien het (moet korreleer met die gebruiker se belangstelling in die groep);
- hoeveel unieke gebruiker-ID's plasings bekyk het volgens eienaar-ID (weerspieël die grootte van die groep se gehoor).
Van tydstempels was dit moontlik om die tyd van die dag te kry waarop die gebruiker die voer gekyk het (oggend/middag/aand/nag). Deur hierdie kategorieë te kombineer, kan jy voortgaan om kenmerke te genereer:
- hoeveel keer userId saans ingeteken het;
- op watter tydstip hierdie pos meer gereeld gewys word (objectId) ensovoorts.
Dit alles het die metrieke geleidelik verbeter. Maar die grootte van die opleidingdatastel is ongeveer 20M rekords, so die toevoeging van kenmerke het opleiding aansienlik vertraag.
Ek het my benadering tot die gebruik van data hersien. Alhoewel die data tydafhanklik is, het ek geen duidelike lekkasies van inligting "in die toekoms" gesien nie, nietemin, net ingeval, ek het dit so gebreek:
Die opleidingstel wat aan ons verskaf is (Februarie en 2 weke van Maart) is in 2 dele verdeel.
Het die model opgelei op die data van die laaste N dae. Die samevoegings hierbo beskryf is gebou op alle data, insluitend die toets. Terselfdertyd het data verskyn waarop dit moontlik is om verskeie enkoderings van die teikenveranderlike te bou. Die maklikste benadering is om die kode wat reeds nuwe kenmerke skep, te hergebruik en dit net data te voer wat nie opgelei sal word nie en teiken = 1.
Ons het dus soortgelyke kenmerke:
- Hoeveel keer het userId die plasing in die eienaarId-groep gesien;
- Hoeveel keer het userId die plasing na die groepeienaar-ID gelaaik;
- Persentasie plasings waarvan userId van eienaarId gehou het.
Dit wil sê, dit het geblyk gemiddelde teikenkodering op 'n deel van die datastel vir verskeie kombinasies van kategoriese kenmerke. In beginsel bou catboost ook teikenkodering en vanuit hierdie oogpunt is daar geen voordeel nie, maar dit het byvoorbeeld moontlik geword om die aantal unieke gebruikers wat van plasings in hierdie groep gehou het, te tel. Terselfdertyd is die hoofdoel bereik - my datastel het verskeie kere afgeneem, en dit was moontlik om voort te gaan om kenmerke te genereer.
Terwyl catboost enkodering slegs op die gelaaide reaksie kan bou, het terugvoer ander reaksies: herdeel, nie van gehou nie, ongewens, geklik, geïgnoreer, wat met die hand geënkodeer kan word. Ek het allerhande aggregate getel en kenmerke met min belangrikheid uitgefiltreer om nie die datastel op te blaas nie.
Teen daardie tyd was ek met 'n groot marge in die eerste plek. Die enigste verleentheid was dat beeldinbeddings amper nie 'n toename gegee het nie. Die idee het gekom om alles aan die genade van catboost te gee. Ons groepeer Kmeans-beelde en kry 'n nuwe kategoriese kenmerk imageCat.
Hier is 'n paar klasse na die handfiltrering en samevoeging van groepe wat van KMeans verkry is.
Op grond van imageCat genereer ons:
- Nuwe kategoriese kenmerke:
- Watter imageCat is die meeste deur userId bekyk;
- Watter imageCat wys die meeste eienaarId;
- Watter imageCat was die meeste gehou deur userId;
- Verskeie tellers:
- Hoeveel unieke imageCat het gekyk userId;
- Ongeveer 15 soortgelyke kenmerke plus teikenkodering soos hierbo beskryf.
tekste
Die uitslae in die beeldkompetisie het my gepas en ek het besluit om myself in die tekste te probeer. Ek het voorheen nie veel met tekste gewerk nie en het 'n dwase dag op tf-idf en svd doodgemaak. Toe sien ek die basislyn met doc2vec, wat presies doen wat ek nodig het. Nadat ek die doc2vec-parameters 'n bietjie aangepas het, het ek teksinbeddings gekry.
En toe het ek sommer die kode vir beelde hergebruik, waarin ek beeldinbeddings met teksinbeddings vervang het. Gevolglik het ek 2de plek in die kompetisie van tekste gekry.
Samewerkende stelsel
Daar was een kompetisie oor wat ek nog nie "met 'n stok gesteek het nie", en te oordeel aan die AUC op die puntelys, moes die uitslae van hierdie spesifieke kompetisie die meeste impak op die vanlyn verhoog gehad het.
Ek het al die kenmerke wat in die oorspronklike data was, geneem, die kategoriese kinders gekies en dieselfde aggregate as vir die beelde bereken, behalwe vir die kenmerke vir die beelde self. Net om dit in catboost te sit het my in die 2de plek gekry.
Eerste stappe van catboost-optimalisering
Een eerste en twee tweede plekke het my behaag, maar daar was 'n begrip dat ek niks spesiaals gedoen het nie, wat beteken dat ons 'n verlies aan posisies kan verwag.
Die taak van die kompetisie is om plasings binne die gebruiker te rangskik, en al hierdie tyd het ek die klassifikasieprobleem opgelos, dit wil sê ek het die verkeerde maatstaf geoptimaliseer.
Ek sal 'n eenvoudige voorbeeld gee:
| gebruiker-ID | objectId | voorspelling | grond waarheid |
|---|---|---|---|
| 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 |
Maak 'n klein verandering
| gebruiker-ID | objectId | voorspelling | grond waarheid |
|---|---|---|---|
| 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 |
Ons kry die volgende resultate:
| Model | AOK | Gebruiker1AUC | Gebruiker2AUC | beteken AUC |
|---|---|---|---|---|
| Opsie 1 | 0,8 | 1,0 | 0,0 | 0,5 |
| Opsie 2 | 0,7 | 0,75 | 1,0 | 0,875 |
Soos gesien kan word, beteken 'n verbetering in die algehele AUC-metriek nie 'n verbetering in die gemiddelde AUC-metriek binne 'n gebruiker nie.
Catboost uit die boks. Ek lees oor rangordemaatstawwe, wanneer jy catboost gebruik en stel om YetiRankPairwise oornag op te lei. Die resultaat is nie indrukwekkend nie. Toe ek besluit het dat ek ondergeoefen is, het ek die foutfunksie verander na QueryRMSE, wat, te oordeel aan die katboost-dokumentasie, vinniger konvergeer. Gevolglik het ek dieselfde resultate gekry as toe ek vir klassifikasie geoefen het, maar die ensembles van hierdie twee modelle het 'n goeie toename gegee, wat my na die eerste plekke in al drie kompetisies gebring het.
5 minute voor die sluiting van die aanlyn verhoog in die Collaborative Systems-kompetisie het Sergey Shalnov my na die tweede plek geskuif. Ons het die res van die pad saam gestap.
Voorbereiding vir die vanlyn stadium
Die oorwinning in die aanlynfase is gewaarborg deur die RTX 2080 TI-videokaart, maar die hoofprys van 300 000 roebels en eerder die finale eerste plek het ons vir hierdie 2 weke laat werk.
Soos dit geblyk het, het Sergey ook catboost gebruik. Ons het idees en kenmerke uitgeruil, en ek het geleer oor waarin daar antwoorde was op baie van my vrae, en selfs op dié wat teen daardie tyd nog nie aan my verskyn het nie.
Om die verslag te bekyk, het my tot die idee gelei dat dit nodig is om alle parameters terug te keer na die verstekwaarde, en om die instellings baie versigtig te hanteer en eers nadat die stel funksies reggestel is. Nou het een opleiding ongeveer 15 uur geneem, maar een model het daarin geslaag om 'n telling beter te kry as wat dit in 'n ensemble met 'n rangorde geblyk het.
Kenmerkgenerasie
In die "Samewerkende Stelsels"-kompetisie word 'n groot aantal kenmerke as belangrik vir die model geëvalueer. Byvoorbeeld, ouditgewigte_vonk_svd - die belangrikste teken, terwyl daar geen inligting is oor wat dit beteken nie. Ek het gedink dit sou die moeite werd wees om die verskillende aggregate op grond van belangrike kenmerke te tel. Byvoorbeeld, gemiddelde ouditgewigte_spark_svd per gebruiker, per groep, per voorwerp. Dieselfde kan bereken word op die data waarop opleiding nie uitgevoer word nie en teiken = 1, dit wil sê die gemiddelde ouditgewigte_vonk_svd deur gebruiker deur voorwerpe waarvan hy hou. Belangrike kenmerke buitendien ouditgewigte_vonk_svd, daar was verskeie. Hier is 'n paar van hulle:
- ouditgewigteCtrlGeslag
- ouditgewigteCtrHigh
- userOwnerCounterCreateLikes
Byvoorbeeld, die gemiddelde waarde ouditgewigteCtrlGeslag deur userId blyk 'n belangrike kenmerk te wees, net soos die gemiddelde waarde userOwnerCounterCreateLikes deur userId+ownerId. Dit moes jou al laat dink het oor die behoefte om die betekenis van die velde te hanteer.
Ook belangrike kenmerke was ouditgewigteHou vanTel и ouditgewigteShowsCount. Deur die een in die ander te verdeel, het ons 'n selfs belangriker kenmerk gekry.
Datalek
Kompetisie- en produksiemodelle is baie verskillende take. Wanneer data voorberei word, is dit baie moeilik om al die besonderhede in ag te neem en nie sommige nie-onbeduidende inligting oor die teikenveranderlike op die toets oor te dra nie. As ons 'n produksie-oplossing skep, sal ons probeer om datalekkasies te vermy wanneer ons die model oplei. Maar as ons die kompetisie wil wen, dan is datalekkasies die beste kenmerke.
Nadat u die data ondersoek het, kan u dit sien volgens die objectId van die waarde ouditgewigteHou vanTel и ouditgewigteShowsCount verander, wat beteken dat die verhouding van die maksimum waardes van hierdie kenmerke die omskakeling van die pos baie beter sal weerspieël as die verhouding ten tye van vertoon.
Die eerste lekkasie wat ons gevind het, is ouditgewigteHou vanCountMax/ouditgewigteShowsCountMax.
Wat as ons die data van nader bekyk? Sorteer volgens vertoningsdatum en kry:
| objectId | gebruiker-ID | ouditgewigteShowsCount | ouditgewigteHou vanTel | teiken (word gehou) |
|---|---|---|---|---|
| 1 | 1 | 12 | 3 | waarskynlik nie |
| 1 | 2 | 15 | 3 | Miskien ja |
| 1 | 3 | 16 | 4 |
Dit was verbasend toe ek die eerste sulke voorbeeld kry en dit blyk dat my voorspelling nie waar geword het nie. Maar gegewe die feit dat die maksimum waardes van hierdie kenmerke binne die voorwerp 'n toename gegee het, was ons nie te lui nie en het besluit om te vind ouditgewigteShowsCountVolgende и ouditgewigteHou vanTelVolgende, dit wil sê die waardes op die volgende tydstip. Deur 'n kenmerk by te voeg
(ouditgewigteShowsCountNext-ouditgewigteShowsCount)/(ouditgewigteLikesCount-ouditgewigteLikesCountNext) ons het 'n skerp sprong vorentoe gemaak.
Soortgelyke lekkasies kan uitgebuit word deur die volgende waardes te vind userOwnerCounterCreateLikes binne userId+ownerId en, byvoorbeeld, ouditgewigteCtrlGeslag binne objectId+userGender. Ons het 6 soortgelyke velde met lekkasies gevind en soveel inligting as moontlik daaruit onttrek.
Teen daardie tyd het ons die maksimum inligting uit samewerkende kenmerke gepers, maar nie teruggekeer na kompetisies van beelde en tekste nie. Daar was 'n goeie idee om na te gaan: hoeveel gee kenmerke direk vir beelde of tekste in die ooreenstemmende kompetisies?
Daar was geen lekkasies in die beeld- en tekskompetisies nie, maar teen daardie tyd het ek die verstekparameters van catboost teruggestuur, die kode skoongemaak en 'n paar kenmerke bygevoeg. Totaal het geblyk:
| besluit | binnekort |
|---|---|
| Maksimum met beelde | 0.6411 |
| Maksimum sonder beelde | 0.6297 |
| Tweede plek uitslag | 0.6295 |
| besluit | binnekort |
|---|---|
| Maksimum met tekste | 0.666 |
| Maksimum sonder tekste | 0.660 |
| Tweede plek uitslag | 0.656 |
| besluit | binnekort |
|---|---|
| Maksimum in samewerkende | 0.745 |
| Tweede plek uitslag | 0.723 |
Dit het duidelik geword dat dit onwaarskynlik was dat ons veel uit tekste en beelde sou kon druk, en nadat ons 'n paar van die interessantste idees probeer het, het ons opgehou om daarmee te werk.
Verdere generering van kenmerke in samewerkende stelsels het nie 'n toename gegee nie, en ons het begin rangorde. Op die aanlyn stadium het die ensemble van klassifikasie en rangorde my 'n klein toename gegee, soos dit geblyk het, omdat ek die klassifikasie ondergeoefen het. Nie een van die foutfunksies, insluitend YetiRanlPairwise, het selfs naby die resultaat gekom wat LogLoss gedoen het nie (0,745 vs. 0,725). Daar was hoop vir QueryCrossEntropy, wat nie geloods kon word nie.
Vanlyn verhoog
Op die vanlyn stadium het die datastruktuur dieselfde gebly, maar daar was klein veranderinge:
- identifiseerders userId, objectId, ownerId is her-ewekansig gemaak;
- 'n paar kenmerke is verwyder en 'n paar hernoem;
- data het met ongeveer 1,5 keer toegeneem.
Benewens die probleme hierbo gelys, was daar een groot pluspunt: 'n groot bediener met 'n RTX 2080TI is aan die span toegewys. Ek geniet htop al lank.
Die idee was een – reproduseer net wat reeds daar is. Nadat ons 'n paar uur spandeer het om die omgewing op die bediener op te stel, het ons geleidelik begin kyk of die resultate reproduceerbaar was. Die grootste probleem waarmee ons te kampe het, is die toename in die hoeveelheid data. Ons het besluit om die las effens te verminder en die catboost-parameter ctr_complexity=1 te stel. Dit verlaag die spoed effens, maar my model het begin werk, die resultaat was goed - 0,733. Sergey, anders as ek, het nie die data in 2 dele verdeel nie en opgelei op al die data, alhoewel dit die beste resultaat op die aanlyn stadium gelewer het, was daar baie probleme op die vanlyn stadium. As ons al die kenmerke wat ons gegenereer het, neem en probeer om dit reguit in 'n catboost te plaas, dan sou niks op die aanlyn stadium gebeur het nie. Sergey het tipe-optimalisering gedoen, byvoorbeeld, om float64 na float32-tipes om te skakel. Jy kan inligting oor geheue-optimalisering in pandas vind. As gevolg hiervan het Sergey al die data op die SVE geleer en ongeveer 0,735 gekry.
Hierdie uitslae was genoeg om te wen, maar ons het ons werklike telling weggesteek en kon nie seker wees dat ander spanne nie dieselfde doen nie.
Veg tot op die laaste
tuning catboost
Ons oplossing is volledig gereproduseer, ons het teksdata en beeldkenmerke bygevoeg, so dit het net oorgebly om die catboost-parameters in te stel. Sergey het opgelei op die SVE met 'n klein aantal herhalings, en ek het opgelei op ctr_complexity=1. Daar was een dag oor, en as jy net herhalings bygevoeg het of ctr_complexity verhoog het, dan kan jy teen die oggend nog beter spoed kry en heeldag loop.
Op die vanlyn stadium kan die tellings baie maklik weggesteek word, bloot deur nie die beste oplossing op die webwerf te kies nie. Ons het dramatiese veranderinge in die puntelys verwag in die laaste minute voor die sluiting van voorleggings en het besluit om nie op te hou nie.
Uit Anna se video het ek geleer dat om die kwaliteit van die model te verbeter, dit die beste is om die volgende parameters te kies:
- leerkoers - Die verstekwaarde word bereken op grond van die grootte van die datastel. 'n Toename in leertempo vereis 'n toename in die aantal iterasies.
- l2_blaarreg - Regulariseringskoëffisiënt, verstekwaarde 3, dit is wenslik om van 2 tot 30 te kies. Vermindering van die waarde lei tot 'n toename in oorfit.
- bagging_temperatuur - voeg ewekansigheid by die gewigte van voorwerpe in die steekproef. Die verstekwaarde is 1, waarin die gewigte gekies word uit 'n eksponensiële verspreiding. Verlaging van die waarde lei tot 'n toename in oorfit.
- ewekansige_sterkte — Beïnvloed die keuse van verdelings by 'n spesifieke iterasie. Hoe hoër die ewekansige_sterkte, hoe groter is die kans dat 'n verdeling met 'n lae belangrikheid gekies word. By elke volgende iterasie neem die ewekansigheid af. Verlaging van die waarde lei tot 'n toename in oorfit.
Ander parameters het baie minder effek op die finale resultaat, so ek het nie probeer om hulle te kies nie. Een herhaling van opleiding op my GPU-datastel met ctr_complexity=1 het 20 minute geneem, en die geselekteerde parameters op die verminderde datastel was effens anders as die optimale op die volledige datastel. Gevolglik het ek ongeveer 30 iterasies op 10% van die data gedoen, en dan nog ongeveer 10 iterasies op al die data. Dit het iets soos volg uitgedraai:
- leerkoers Ek het met 40% toegeneem vanaf die verstek;
- l2_blaarreg dieselfde gelaat;
- bagging_temperatuur и ewekansige_sterkte verminder tot 0,8.
Daar kan tot die gevolgtrekking gekom word dat die model ondergeoefen is met verstekparameters.
Ek was baie verbaas toe ek die uitslag op die puntelys sien:
| Model | model 1 | model 2 | model 3 | ensemble |
|---|---|---|---|---|
| Sonder tuning | 0.7403 | 0.7404 | 0.7404 | 0.7407 |
| met stemming | 0.7406 | 0.7405 | 0.7406 | 0.7408 |
Ek het self tot die gevolgtrekking gekom dat as jy nie 'n vinnige toepassing van die model nodig het nie, dit beter is om die keuse van parameters te vervang met 'n ensemble van verskeie modelle op nie-geoptimaliseerde parameters.
Sergey was betrokke by die optimalisering van die grootte van die datastel om dit op die GPU te laat loop. Die maklikste opsie is om 'n deel van die data af te sny, maar dit kan op verskeie maniere gedoen word:
- verwyder die oudste data geleidelik (begin Februarie) totdat die datastel in die geheue begin pas;
- verwyder kenmerke met die laagste belangrikheid;
- verwyder gebruiker-ID waarvoor daar net een inskrywing is;
- laat slegs die gebruiker-ID wat in die toets is.
En op die ou end - om 'n ensemble van alle opsies te maak.
Laaste Ensemble
Teen die laataand van die laaste dag het ons 'n ensemble van ons modelle geplaas, wat 0,742 gegee het. Snags het ek my model met ctr_complexity=2 gehardloop en in plaas van 30 minute, het dit vir 5 uur geoefen. Eers 4 uur die oggend het sy getel, en ek het die laaste ensemble gemaak, wat 0,7433 op die publieke puntelys gegee het.
As gevolg van verskillende benaderings om die probleem op te los, was ons voorspellings nie sterk gekorreleer nie, wat 'n goeie toename in die ensemble gegee het. Om 'n goeie ensemble te kry is dit beter om die rou model voorspellings predict (prediction_type='RawFormulaVal') te gebruik en scale_pos_weight=neg_count/pos_count te stel.
Op die webwerf kan jy sien .
Ander oplossings
Baie spanne het die kanons van aanbevelingsalgoritmes gevolg. Ek, nie 'n kenner op hierdie gebied nie, kan hulle nie evalueer nie, maar ek onthou 2 interessante oplossings.
- . Nikolai, synde 'n werknemer van Mail.ru, het geen pryse geëis nie, so hy het homself die doelwit gestel om nie die maksimum spoed te kry nie, maar om 'n maklik skaalbare oplossing te kry.
- Die besluit van die span wat die Jurieprys ontvang het, gebaseer op , het dit moontlik gemaak om beelde baie goed te groepeer sonder handwerk.
Gevolgtrekking
Wat die meeste in my geheue vassteek:
- As daar kategoriese kenmerke in die data is, en jy weet hoe om teikenkodering korrek te doen, is dit steeds beter om catboost te probeer.
- As jy aan 'n kompetisie deelneem, moet jy nie tyd mors om ander parameters as leertempo en iterasies te kies nie. ’n Vinniger oplossing is om ’n ensemble van verskeie modelle te maak.
- Versterkings kan op die GPU leer. Catboost kan baie vinnig op die GPU leer, maar vreet baie geheue.
- Terwyl idees ontwikkel en getoets word, is dit beter om klein rsm~=0.2 (slegs CPU) en ctr_complexity=1 te stel.
- Anders as ander spanne het die ensemble van ons modelle 'n groot toename gegee. Ons het net idees uitgeruil en in verskillende tale geskryf. Ons het 'n ander benadering tot datapartisionering gehad en ek dink almal het hul eie foute gehad.
- Dit is nie duidelik waarom rangorde-optimering swakker gevaar het as klassifikasie-optimering nie.
- Ek het 'n bietjie ervaring met tekste gekry en 'n begrip van hoe aanbevelerstelsels gemaak word.
Dankie aan die organiseerders vir die emosies, kennis en pryse.
Bron: will.com