In februari-maart 2019 werd een wedstrijd gehouden om de sociale netwerkfeed te rangschikken , waarin ons team de eerste plaats behaalde. In het artikel zal ik het hebben over de organisatie van de competitie, de methoden die we hebben geprobeerd en de catboost-instellingen voor training op big data.
SNA-hackathon
Het is de derde keer dat er een hackathon onder deze naam wordt gehouden. Het wordt georganiseerd door het sociale netwerk ok.ru, respectievelijk de taak en gegevens zijn rechtstreeks gerelateerd aan dit sociale netwerk.
SNA (sociale netwerkanalyse) wordt in dit geval correcter opgevat, niet als een analyse van een sociale grafiek, maar eerder als een analyse van een sociaal netwerk.
- In 2014 was het de taak om te voorspellen hoeveel likes een bericht zou krijgen.
- In 2016 - de VVZ-taak (misschien kent u deze), dichter bij de analyse van de sociale grafiek.
- In 2019 wordt de feed van de gebruiker gerangschikt op basis van de waarschijnlijkheid dat de gebruiker het bericht leuk zal vinden.
Over 2014 kan ik niets zeggen, maar in 2016 en 2019 waren naast vaardigheden op het gebied van data-analyse ook vaardigheden in het werken met big data vereist. Ik denk dat het de combinatie van machinaal leren en problemen met de verwerking van big data was die mij naar deze wedstrijden trok, en mijn ervaring op deze gebieden heeft mij geholpen om te winnen.
mlbootcamp
In 2019 werd de wedstrijd op het platform georganiseerd .
De wedstrijd begon online op 7 februari en bestond uit 3 taken. Iedereen kon zich op de site registreren, downloaden en laad uw auto een paar uur in. Aan het einde van de online fase op 15 maart werden de top 15 van elk springevenement uitgenodigd op het Mail.ru-kantoor voor de offline fase, die plaatsvond van 30 maart tot 1 april.
Taak
De brongegevens bieden gebruikers-ID's (userId) en post-ID's (objectId). Als de gebruiker een bericht te zien kreeg, bevatten de gegevens een regel met userId, objectId, gebruikersreacties op dit bericht (feedback) en een reeks verschillende functies of links naar afbeeldingen en teksten.
| gebruikersnaam | objectId | eigenaarId | feedback | afbeeldingen |
|---|---|---|---|---|
| 3555 | 22 | 5677 | [leuk gevonden, geklikt] | [hash1] |
| 12842 | 55 | 32144 | [niet leuk gevonden] | [hash2,hash3] |
| 13145 | 35 | 5677 | [geklikt, gedeeld] | [hash2] |
De testdataset bevat een vergelijkbare structuur, maar het feedbackveld ontbreekt. De taak is om de aanwezigheid van de 'like'-reactie in het feedbackveld te voorspellen.
Het indieningsbestand heeft de volgende structuur:
| gebruikersnaam | GesorteerdeLijst[objectId] |
|---|---|
| 123 | 78,13,54,22 |
| 128 | 35,61,55 |
| 131 | 35,68,129,11 |
De statistiek is de gemiddelde ROC AUC voor gebruikers.
Een meer gedetailleerde beschrijving van de gegevens kunt u vinden op. Ook kunt u daar gegevens downloaden, waaronder tests en foto's.
Online podium
In de online fase was de taak verdeeld in 3 delen
- — bevat alle functies behalve afbeeldingen en teksten;
- — bevat alleen informatie over afbeeldingen;
- — bevat alleen informatie over teksten.
Offline podium
In de offline fase omvatten de gegevens alle kenmerken, terwijl teksten en afbeeldingen schaars waren. Er waren 1,5 keer meer rijen in de dataset, waarvan er al veel waren.
De oplossing van het probleem
Omdat ik op het werk CV's maak, begon ik mijn reis in deze wedstrijd met de taak 'Afbeeldingen'. De gegevens die werden verstrekt waren userId, objectId, eigenaarId (de groep waarin het bericht werd gepubliceerd), tijdstempels voor het maken en weergeven van het bericht, en uiteraard de afbeelding voor dit bericht.
Na het genereren van verschillende functies op basis van tijdstempels, was het volgende idee om de voorlaatste laag van het neuron, vooraf getraind op Imagenet, te gebruiken en deze inbedding te stimuleren.
De resultaten waren niet indrukwekkend. Inbedding van het imagenet-neuron is niet relevant, dacht ik, ik moet mijn eigen autoencoder maken.
Het kostte veel tijd en het resultaat verbeterde niet.
Functiegeneratie
Het werken met afbeeldingen kost veel tijd, dus besloot ik iets eenvoudigers te doen.
Zoals je meteen kunt zien, zijn er verschillende categorische kenmerken in de dataset, en om me er niet al te veel zorgen over te maken, heb ik gewoon catboost genomen. De oplossing was uitstekend, zonder enige instellingen kwam ik meteen op de eerste regel van het klassement.
Er zijn behoorlijk veel gegevens en deze zijn opgemaakt in parketformaat, dus zonder er twee keer over na te denken, nam ik scala en begon alles in spark te schrijven.
De eenvoudigste functies die meer groei opleverden dan het insluiten van afbeeldingen:
- hoe vaak objectId, userId en ownId in de gegevens voorkomen (zou moeten correleren met populariteit);
- hoeveel berichten userId heeft gezien van ownId (moet correleren met de interesse van de gebruiker in de groep);
- hoeveel unieke userIds berichten van ownId hebben bekeken (weerspiegelt de grootte van het publiek van de groep).
Uit tijdstempels kon het tijdstip worden afgeleid waarop de gebruiker de feed bekeek (ochtend/middag/avond/nacht). Door deze categorieën te combineren, kunt u functies blijven genereren:
- hoe vaak userId 's avonds heeft ingelogd;
- op welk tijdstip dit bericht het vaakst wordt getoond (objectId) enzovoort.
Dit alles verbeterde geleidelijk de statistieken. Maar de omvang van de trainingsdataset bedraagt ongeveer 20 miljoen records, dus het toevoegen van functies vertraagde de training aanzienlijk.
Ik heb mijn benadering van het gebruik van data heroverwogen. Hoewel de gegevens tijdsafhankelijk zijn, heb ik “in de toekomst” geen duidelijke informatielekken gezien, maar voor het geval dat heb ik het als volgt opgesplitst:
De ons aangeboden trainingsset (februari en 2 weken maart) was opgedeeld in 2 delen.
Het model is getraind op gegevens van de afgelopen N dagen. De hierboven beschreven aggregaties zijn gebaseerd op alle gegevens, inclusief de test. Tegelijkertijd zijn er gegevens verschenen waarop het mogelijk is verschillende coderingen van de doelvariabele te bouwen. De eenvoudigste aanpak is om code die al nieuwe functies creëert, opnieuw te gebruiken en er eenvoudigweg gegevens aan toe te voegen waarop deze niet zal worden getraind en target = 1.
We hebben dus vergelijkbare kenmerken:
- Hoe vaak heeft userId een bericht in de groep ownId gezien;
- Hoe vaak heeft userId het bericht in de groep ownId leuk gevonden;
- Het percentage berichten dat userId leuk vond van ownId.
Dat wil zeggen, het bleek gemiddelde doelcodering op een deel van de dataset voor verschillende combinaties van categorische kenmerken. In principe bouwt catboost ook doelcodering en vanuit dit oogpunt is er geen voordeel, maar het werd bijvoorbeeld mogelijk om het aantal unieke gebruikers te tellen dat berichten in deze groep leuk vond. Tegelijkertijd werd het hoofddoel bereikt: mijn dataset werd verschillende keren verkleind en het was mogelijk om door te gaan met het genereren van functies.
Hoewel catboost alleen codering kan opbouwen op basis van de reactie die ik leuk vind, heeft feedback andere reacties: opnieuw gedeeld, niet leuk gevonden, niet leuk gevonden, aangeklikt, genegeerd, coderingen waarvoor handmatig kan worden gedaan. Ik heb allerlei soorten aggregaten opnieuw berekend en kenmerken met een laag belang geëlimineerd om de dataset niet te overdrijven.
Tegen die tijd stond ik met ruime voorsprong op de eerste plaats. Het enige dat verwarrend was, was dat de inbedding van afbeeldingen vrijwel geen groei vertoonde. Het idee ontstond om alles aan catboost te geven. We clusteren Kmeans-afbeeldingen en krijgen een nieuwe categorische functie imageCat.
Hier zijn enkele klassen na het handmatig filteren en samenvoegen van clusters verkregen van KMeans.
Op basis van imageCat genereren we:
- Nieuwe categorische functies:
- Welke imageCat werd het vaakst bekeken door userId;
- Welke imageCat toont het vaakst eigenaarId;
- Welke imageCat werd het vaakst gewaardeerd door userId;
- Diverse tellers:
- Hoeveel unieke imageCat keken naar userId;
- Ongeveer 15 vergelijkbare functies plus doelcodering zoals hierboven beschreven.
teksten
De resultaten van de beeldwedstrijd bevielen mij en ik besloot een poging te wagen met teksten. Ik heb nog niet veel met teksten gewerkt en, dwaas genoeg, heb ik de dag gedood op tf-idf en svd. Toen zag ik de basislijn met doc2vec, die precies doet wat ik nodig heb. Nadat ik de doc2vec-parameters enigszins had aangepast, kreeg ik tekstinsluitingen.
En vervolgens hergebruikte ik eenvoudigweg de code voor de afbeeldingen, waarbij ik de afbeeldingsinsluitingen verving door tekstinsluitingen. Hierdoor behaalde ik de 2e plaats in de tekstwedstrijd.
Collaboratief systeem
Er was nog één wedstrijd over die ik nog niet met een stok had “geprikt”, en afgaande op de AUC op het scorebord hadden de resultaten van deze specifieke competitie de grootste impact moeten hebben gehad op het offline podium.
Ik heb alle kenmerken uit de brongegevens genomen, categorische kenmerken geselecteerd en dezelfde aggregaten berekend als voor afbeeldingen, behalve de kenmerken op basis van de afbeeldingen zelf. Door dit in catboost te zetten, kwam ik op de 2e plaats.
Eerste stappen van catboost-optimalisatie
Eén eerste en twee tweede plaatsen bevielen mij, maar er was begrip dat ik niets bijzonders had gedaan, waardoor ik positieverlies kon verwachten.
De taak van de concurrentie is om berichten binnen de gebruiker te rangschikken, en al die tijd was ik het classificatieprobleem aan het oplossen, dat wil zeggen het optimaliseren van de verkeerde statistiek.
Ik zal een eenvoudig voorbeeld geven:
| gebruikersnaam | 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 |
Laten we een kleine herschikking maken
| gebruikersnaam | 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 |
We krijgen de volgende resultaten:
| Model | AUC | Gebruiker1 AUC | Gebruiker2 AUC | gemiddelde AUC |
|---|---|---|---|---|
| optie 1 | 0,8 | 1,0 | 0,0 | 0,5 |
| optie 2 | 0,7 | 0,75 | 1,0 | 0,875 |
Zoals u kunt zien, betekent het verbeteren van de algehele AUC-metriek niet dat de gemiddelde AUC-metriek binnen een gebruiker wordt verbeterd.
Kattenboost uit de doos. Ik las over rankingstatistieken, bij gebruik van catboost en stel YetiRankPairwise in om 's nachts te trainen. Het resultaat was niet indrukwekkend. Omdat ik besloot dat ik te weinig getraind was, veranderde ik de foutfunctie in QueryRMSE, die, te oordelen naar de catboost-documentatie, sneller convergeert. Uiteindelijk behaalde ik dezelfde resultaten als bij het trainen voor classificatie, maar de ensembles van deze twee modellen gaven een goede stijging, wat mij in alle drie de competities naar de eerste plaats bracht.
Vijf minuten voor de afsluiting van de online fase van de wedstrijd “Collaborative Systems” bracht Sergey Shalnov mij naar de tweede plaats. Samen liepen we het verdere pad.
Voorbereiden op de offline fase
We waren verzekerd van de overwinning in de online fase met een RTX 2080 TI-videokaart, maar de hoofdprijs van 300 roebel en hoogstwaarschijnlijk zelfs de laatste eerste plaats dwongen ons deze 000 weken te werken.
Het bleek dat Sergey ook catboost gebruikte. We wisselden ideeën en functies uit, en ik leerde erover die antwoorden bevatte op veel van mijn vragen, en zelfs op de vragen die ik toen nog niet had.
Toen ik het rapport bekeek, kwam ik op het idee dat we alle parameters naar de standaardwaarde moeten terugzetten, en de instellingen heel zorgvuldig moeten uitvoeren, en pas nadat we een aantal functies hebben hersteld. Nu duurde één training ongeveer 15 uur, maar één model slaagde erin een snelheid te behalen die beter was dan die verkregen in het ensemble met ranking.
Functiegeneratie
In de Collaborative Systems competitie wordt een groot aantal features als belangrijk beoordeeld voor het model. Bijvoorbeeld, auditweights_spark_svd - het belangrijkste teken, maar er is geen informatie over wat het betekent. Ik dacht dat het de moeite waard zou zijn om de verschillende aggregaten te tellen op basis van belangrijke kenmerken. Bijvoorbeeld het gemiddelde van auditweights_spark_svd per gebruiker, per groep, per object. Hetzelfde kan worden berekend met behulp van gegevens waarop geen training wordt uitgevoerd en doel = 1, dat wil zeggen gemiddeld auditweights_spark_svd per gebruiker op objecten die hij leuk vond. Belangrijke tekenen bovendien auditweights_spark_svd, er waren er meerdere. Hier zijn er een aantal:
- auditgewichtenCtrGender
- controlegewichtenCtrHigh
- userOwnerCounterCreateLikes
Het gemiddelde bijvoorbeeld auditgewichtenCtrGender volgens userId bleek het een belangrijk kenmerk te zijn, net als de gemiddelde waarde userOwnerCounterCreateLikes door gebruikers-ID+eigenaar-ID. Dit zou u al moeten doen denken dat u de betekenis van de velden moet begrijpen.
Ook belangrijke kenmerken waren auditweightsLikesCount и auditgewichtenShowsCount. Door de een door de ander te delen, werd een nog belangrijker kenmerk verkregen.
Datalekken
Competitie- en productiemodellering zijn heel verschillende taken. Bij het voorbereiden van gegevens is het erg moeilijk om met alle details rekening te houden en niet-triviale informatie over de doelvariabele in de test niet over te brengen. Als we een productieoplossing creëren, zullen we proberen datalekken te vermijden bij het trainen van het model. Maar als we de competitie willen winnen, zijn datalekken de beste eigenschap.
Nadat u de gegevens heeft bestudeerd, kunt u dat zien aan de hand van de objectId-waarden auditweightsLikesCount и auditgewichtenShowsCount verandering, wat betekent dat de verhouding van de maximale waarden van deze functies de postconversie veel beter zal weerspiegelen dan de verhouding op het moment van weergave.
Het eerste lek dat we hebben gevonden is auditweightsLikesCountMax/auditweightsShowsCountMax.
Maar wat als we de gegevens nader bekijken? Laten we sorteren op showdatum en het volgende krijgen:
| objectId | gebruikersnaam | auditgewichtenShowsCount | auditweightsLikesCount | doelwit (is leuk) |
|---|---|---|---|---|
| 1 | 1 | 12 | 3 | waarschijnlijk niet |
| 1 | 2 | 15 | 3 | misschien wel |
| 1 | 3 | 16 | 4 |
Het was verrassend toen ik het eerste voorbeeld vond en het bleek dat mijn voorspelling niet uitkwam. Maar rekening houdend met het feit dat de maximale waarden van deze kenmerken binnen het object een toename opleverden, waren we niet lui en besloten we te vinden auditweightsShowsCountNext и auditweightsLikesCountNext, dat wil zeggen de waarden op het volgende moment. Door een functie toe te voegen
(auditweightsShowsCountNext-auditweightsShowsCount)/(auditweightsLikesCount-auditweightsLikesCountNext) we maakten snel een scherpe sprong.
Soortgelijke lekken kunnen worden gebruikt door de volgende waarden te vinden userOwnerCounterCreateLikes binnen userId+eigenaarId en bijvoorbeeld auditgewichtenCtrGender binnen objectId+userGender. We hebben 6 vergelijkbare velden met lekken gevonden en daar zoveel mogelijk informatie uit gehaald.
Tegen die tijd hadden we zoveel mogelijk informatie uit samenwerkingsfuncties gehaald, maar we keerden niet terug naar beeld- en tekstwedstrijden. Ik had een geweldig idee om te controleren: hoeveel opleveren features die direct op afbeeldingen of teksten zijn gebaseerd bij relevante wedstrijden?
Er waren geen lekken in de afbeeldings- en tekstwedstrijden, maar tegen die tijd had ik de standaard catboost-parameters teruggegeven, de code opgeschoond en een paar functies toegevoegd. Het totaal was:
| beslissing | spoedig |
|---|---|
| Maximaal met afbeeldingen | 0.6411 |
| Maximaal geen afbeeldingen | 0.6297 |
| Resultaat tweede plaats | 0.6295 |
| beslissing | spoedig |
|---|---|
| Maximaal met teksten | 0.666 |
| Maximaal zonder teksten | 0.660 |
| Resultaat tweede plaats | 0.656 |
| beslissing | spoedig |
|---|---|
| Maximaal in samenwerken | 0.745 |
| Resultaat tweede plaats | 0.723 |
Het werd duidelijk dat het onwaarschijnlijk was dat we veel uit teksten en afbeeldingen zouden kunnen halen, en nadat we een paar van de meest interessante ideeën hadden uitgeprobeerd, stopten we ermee.
Verdere generatie van functies in samenwerkingssystemen leverde geen toename op en we begonnen met rangschikken. In de online fase leverde het classificatie- en ranking-ensemble mij een kleine stijging op, zo bleek omdat ik de classificatie te weinig trainde. Geen van de foutfuncties, inclusief YetiRanlPairwise, produceerde ook maar enigszins het resultaat van LogLoss (0,745 versus 0,725). Er was nog steeds hoop voor QueryCrossEntropy, dat niet gelanceerd kon worden.
Offline podium
In de offline fase bleef de datastructuur hetzelfde, maar er waren kleine wijzigingen:
- ID's userId, objectId en ownId zijn opnieuw willekeurig gemaakt;
- verschillende borden zijn verwijderd en een aantal heeft een nieuwe naam gekregen;
- de gegevens zijn ongeveer 1,5 keer toegenomen.
Naast de genoemde problemen was er één groot pluspunt: het team kreeg een grote server toegewezen met een RTX 2080TI. Ik geniet al heel lang van htop.
Er was maar één idee: simpelweg reproduceren wat al bestaat. Nadat we een paar uur hadden besteed aan het opzetten van de omgeving op de server, begonnen we geleidelijk aan te verifiëren dat de resultaten reproduceerbaar waren. Het grootste probleem waarmee we worden geconfronteerd, is de toename van het datavolume. We hebben besloten de belasting een beetje te verminderen en de catboost-parameter ctr_complexity=1 in te stellen. Dit verlaagt de snelheid een beetje, maar mijn model begon te werken, het resultaat was goed - 0,733. Sergey heeft, in tegenstelling tot mij, de gegevens niet in twee delen opgesplitst en op alle gegevens getraind, hoewel dit in de online fase de beste resultaten opleverde, waren er in de offline fase veel moeilijkheden. Als we alle functies die we hebben gegenereerd zouden gebruiken en proberen ze in catboost te stoppen, zou niets werken in de online fase. Sergey deed type-optimalisatie, door bijvoorbeeld float2-typen om te zetten in float64. U kunt informatie vinden over geheugenoptimalisatie in panda's. Als gevolg hiervan trainde Sergey op de CPU met behulp van alle gegevens en behaalde ongeveer 0,735.
Deze resultaten waren genoeg om te winnen, maar we verborgen onze ware snelheid en konden er niet zeker van zijn dat andere teams niet hetzelfde deden.
Vecht tot het laatst
Catboost-afstemming
Onze oplossing werd volledig gereproduceerd, we voegden de functies van tekstgegevens en afbeeldingen toe, dus het enige dat overbleef was het afstemmen van de catboost-parameters. Sergey trainde op de CPU met een klein aantal iteraties, en ik trainde op die met ctr_complexity=1. Er was nog één dag over, en als je alleen maar iteraties zou toevoegen of de ctr_complexiteit zou vergroten, dan zou je tegen de ochtend een nog betere snelheid kunnen krijgen en de hele dag kunnen lopen.
In de offline fase kunnen snelheden heel gemakkelijk worden verborgen door simpelweg niet de beste oplossing op de site te kiezen. We verwachtten drastische veranderingen in het klassement in de laatste minuten voordat de inzendingen sloten en besloten niet te stoppen.
Uit Anna's video heb ik geleerd dat je, om de kwaliteit van het model te verbeteren, het beste de volgende parameters kunt selecteren:
- leertempo — De standaardwaarde wordt berekend op basis van de grootte van de dataset. Het verhogen van de leersnelheid vereist het vergroten van het aantal iteraties.
- l2_blad_reg — Regularisatiecoëfficiënt, standaardwaarde 3, bij voorkeur een keuze tussen 2 en 30. Het verlagen van de waarde leidt tot een toename van de overfit.
- opzaktemperatuur — voegt randomisatie toe aan de gewichten van objecten in de steekproef. De standaardwaarde is 1, waarbij de gewichten worden ontleend aan een exponentiële verdeling. Het verlagen van de waarde leidt tot een toename van de overfit.
- willekeurige_sterkte — Beïnvloedt de keuze van splitsingen bij een specifieke iteratie. Hoe hoger de willekeurige_sterkte, hoe groter de kans dat er een splitsing met een lage belangrijkheid wordt geselecteerd. Bij elke volgende iteratie neemt de willekeur af. Het verlagen van de waarde leidt tot een toename van de overfit.
Andere parameters hebben een veel kleiner effect op het eindresultaat, dus ik heb niet geprobeerd ze te selecteren. Eén herhaling van de training op mijn GPU-dataset met ctr_complexity=1 duurde 20 minuten, en de geselecteerde parameters op de beperkte dataset verschilden enigszins van de optimale parameters op de volledige dataset. Uiteindelijk heb ik ongeveer 30 iteraties uitgevoerd op 10% van de gegevens, en daarna nog ongeveer 10 iteraties op alle gegevens. Het bleek ongeveer zo:
- leertempo Ik ben met 40% verhoogd ten opzichte van de standaardwaarde;
- l2_blad_reg liet het hetzelfde;
- opzaktemperatuur и willekeurige_sterkte teruggebracht tot 0,8.
We kunnen concluderen dat het model onvoldoende getraind was met de standaardparameters.
Ik was zeer verrast toen ik het resultaat op het scorebord zag:
| Model | 1-model | 2-model | 3-model | ensemble |
|---|---|---|---|---|
| Zonder afstemming | 0.7403 | 0.7404 | 0.7404 | 0.7407 |
| Met afstemming | 0.7406 | 0.7405 | 0.7406 | 0.7408 |
Ik concludeerde voor mezelf dat als snelle toepassing van het model niet nodig is, het beter is om de selectie van parameters te vervangen door een ensemble van verschillende modellen die niet-geoptimaliseerde parameters gebruiken.
Sergey was de grootte van de dataset aan het optimaliseren om deze op de GPU uit te voeren. De eenvoudigste optie is om een deel van de gegevens af te snijden, maar dit kan op verschillende manieren:
- verwijder geleidelijk de oudste gegevens (begin februari) totdat de dataset in het geheugen begint te passen;
- verwijder functies met het laagste belang;
- verwijder userIds waarvoor er slechts één vermelding is;
- laat alleen de userIds achter die in de test voorkomen.
En maak uiteindelijk een ensemble van alle opties.
Het laatste ensemble
Tegen het einde van de avond van de laatste dag hadden we een geheel van onze modellen opgesteld dat 0,742 opleverde. Van de ene op de andere dag lanceerde ik mijn model met ctr_complexity=2 en in plaats van 30 minuten trainde het 5 uur lang. Pas om 4 uur 's ochtends werd er geteld en maakte ik het laatste ensemble, dat 0,7433 opleverde op het publieke scorebord.
Vanwege verschillende benaderingen om het probleem op te lossen, waren onze voorspellingen niet sterk gecorreleerd, wat een goede toename van het geheel opleverde. Om een goed ensemble te krijgen, is het beter om de ruwe modelvoorspellingen voorspellen (prediction_type='RawFormulaVal') te gebruiken en scale_pos_weight=neg_count/pos_count in te stellen.
Op de website kun je zien .
Andere oplossingen
Veel teams volgden de canons van aanbevelingssysteemalgoritmen. Ik, omdat ik geen expert op dit gebied ben, kan ze niet beoordelen, maar ik herinner me twee interessante oplossingen.
- . Nikolay, een medewerker van Mail.ru, had geen prijzen aangevraagd, dus zijn doel was niet om de maximale snelheid te bereiken, maar om een gemakkelijk schaalbare oplossing te verkrijgen.
- De beslissing van het juryprijswinnende team op basis van , maakte zeer goede beeldclustering mogelijk zonder handmatig werk.
Conclusie
Wat het meest in mijn geheugen is blijven hangen:
- Als de gegevens categorische kenmerken bevatten en u weet hoe u de doelcodering correct moet uitvoeren, is het nog steeds beter om catboost te proberen.
- Als u aan een wedstrijd deelneemt, moet u geen tijd verspillen met het selecteren van andere parameters dan learning_rate en iteraties. Een snellere oplossing is om een ensemble van meerdere modellen te maken.
- Boostings kunnen leren op de GPU. Catboost kan heel snel leren op de GPU, maar neemt veel geheugen in beslag.
- Tijdens het ontwikkelen en testen van ideeën is het beter om een kleine rsm~=0.2 (alleen CPU) en ctr_complexity=1 in te stellen.
- In tegenstelling tot andere teams gaf het ensemble van onze modellen een grote toename. We wisselden alleen ideeën uit en schreven in verschillende talen. We hadden een andere aanpak bij het splitsen van de gegevens en volgens mij hadden ze allemaal hun eigen bugs.
- Het is niet duidelijk waarom ranking-optimalisatie slechter presteerde dan classificatie-optimalisatie.
- Ik heb enige ervaring opgedaan met het werken met teksten en heb inzicht gekregen in hoe aanbevelingssystemen worden gemaakt.
Dank aan de organisatoren voor de emoties, kennis en ontvangen prijzen.
Bron: www.habr.com