Në shkurt-mars 2019 u zhvillua një konkurs për renditjen e burimeve të rrjeteve sociale , në të cilin ekipi ynë zuri vendin e parë. Në artikull do të flas për organizimin e konkursit, metodat që provuam dhe cilësimet e catboost për trajnime në të dhëna të mëdha.
SNA Hackathon
Kjo është hera e tretë që zhvillohet një hackathon me këtë emër. Organizohet nga rrjeti social ok.ru, respektivisht, detyra dhe të dhënat lidhen drejtpërdrejt me këtë rrjet social.
SNA (analiza e rrjetit social) në këtë rast kuptohet më saktë jo si një analizë e një grafiku social, por më tepër si një analizë e një rrjeti social.
- Në vitin 2014, detyra ishte të parashikohej numri i pëlqimeve që do të merrte një postim.
- Në vitin 2016 - detyra VVZ (ndoshta jeni të njohur), më afër analizës së grafikut social.
- Në vitin 2019, renditja e furnizimit të përdoruesit bazuar në gjasat që përdoruesi të pëlqejë postimin.
Nuk mund të them për vitin 2014, por në vitin 2016 dhe 2019, përveç aftësive të analizës së të dhënave, kërkoheshin edhe aftësi për të punuar me të dhëna të mëdha. Mendoj se ishte kombinimi i të mësuarit të makinerive dhe problemeve të përpunimit të të dhënave të mëdha që më tërhoqën në këto gara dhe përvoja ime në këto fusha më ndihmoi të fitoja.
mlbootcamp
Në vitin 2019, konkursi u organizua në platformë .
Konkursi filloi online më 7 shkurt dhe përbëhej nga 3 detyra. Çdokush mund të regjistrohet në sit, shkarko dhe ngarkoni makinën tuaj për disa orë. Në fund të skenës në internet më 15 mars, 15 më të mirët e secilës ngjarje kërcimi në shfaqje u ftuan në zyrën e Mail.ru për fazën offline, e cila u zhvillua nga 30 Mars deri më 1 Prill.
Detyrë
Të dhënat burimore ofrojnë ID-të e përdoruesve (userId) dhe ID-të e postimit (objectId). Nëse përdoruesit i është shfaqur një postim, atëherë të dhënat përmbajnë një rresht që përmban userId, objectId, reagimet e përdoruesit ndaj këtij postimi (feedback) dhe një grup funksionesh të ndryshme ose lidhje me foto dhe tekste.
| ID e përdoruesit | objektId | pronarId | reagim | images |
|---|---|---|---|---|
| 3555 | 22 | 5677 | [pëlqyer, klikuar] | [hash1] |
| 12842 | 55 | 32144 | [i papëlqyer] | [hash2,hash3] |
| 13145 | 35 | 5677 | [klikuar, ndarë] | [hash2] |
Grupi i të dhënave të testimit përmban një strukturë të ngjashme, por fusha e reagimit mungon. Detyra është të parashikohet prania e reagimit 'të pëlqyer' në fushën e reagimit.
Dosja e dorëzimit ka strukturën e mëposhtme:
| ID e përdoruesit | Lista e renditur[objectId] |
|---|---|
| 123 | 78,13,54,22 |
| 128 | 35,61,55 |
| 131 | 35,68,129,11 |
Metrika është mesatarja ROC AUC për përdoruesit.
Një përshkrim më i detajuar i të dhënave mund të gjendet në. Ju gjithashtu mund të shkarkoni të dhëna atje, duke përfshirë testet dhe fotografitë.
Faza online
Në fazën online, detyra u nda në 3 pjesë
- — përfshin të gjitha veçoritë përveç imazheve dhe teksteve;
- — përfshin vetëm informacione rreth imazheve;
- — përfshin informacion vetëm për tekstet.
Faza jashtë linje
Në fazën offline, të dhënat përfshinin të gjitha veçoritë, ndërsa tekstet dhe imazhet ishin të rralla. Kishte 1,5 herë më shumë rreshta në grupin e të dhënave, nga të cilat tashmë kishte shumë.
Zgjidhja e problemit
Duke qenë se bëj CV në punë, rrugëtimin tim në këtë konkurs e nisa me detyrën “Imazhe”. Të dhënat që u dhanë ishin userId, objectId, ownerId (grupi në të cilin u publikua postimi), vulat kohore për krijimin dhe shfaqjen e postimit dhe, natyrisht, imazhi për këtë postim.
Pas gjenerimit të disa veçorive të bazuara në stampat kohore, ideja tjetër ishte të merrej shtresa e parafundit e neuronit të trajnuar paraprakisht në imagenet dhe t'i dërgonte këto ngulitje në rritje.
Rezultatet nuk ishin mbresëlënëse. Përfshirjet nga neuroni i imazhetit janë të parëndësishme, mendova, duhet të bëj autoenkoderin tim.
U desh shumë kohë dhe rezultati nuk u përmirësua.
Gjenerimi i veçorive
Puna me imazhe kërkon shumë kohë, kështu që vendosa të bëj diçka më të thjeshtë.
Siç mund ta shihni menjëherë, ka disa veçori kategorike në grupin e të dhënave, dhe për të mos u mërzitur shumë, thjesht mora catboost. Zgjidhja ishte e shkëlqyeshme, pa asnjë cilësim arrita menjëherë në rreshtin e parë të tabelës së drejtuesve.
Ka mjaft të dhëna dhe janë të shtruara në formatin e parketit, kështu që pa u menduar dy herë, mora Scalën dhe fillova të shkruaj gjithçka në shkëndijë.
Karakteristikat më të thjeshta që dhanë më shumë rritje sesa futjet e imazhit:
- sa herë objekti, ID-ja e përdoruesit dhe ID e pronarit janë shfaqur në të dhëna (duhet të lidhen me popullaritetin);
- sa postime ka parë userId nga pronari (duhet të lidhen me interesin e përdoruesit në grup);
- sa userIds unike kanë parë postime nga pronari (pasqyron madhësinë e audiencës së grupit).
Nga vulat kohore ishte e mundur të merrej ora e ditës në të cilën përdoruesi shikonte furnizimin (mëngjes/pasdite/mbrëmje/natë). Duke kombinuar këto kategori, mund të vazhdoni të gjeneroni veçori:
- sa herë userId është regjistruar në mbrëmje;
- në cilën orë shfaqet më shpesh ky postim (objectId) dhe kështu me radhë.
E gjithë kjo gradualisht përmirësoi metrikën. Por madhësia e grupit të të dhënave të trajnimit është rreth 20 milion rekorde, kështu që shtimi i veçorive e ngadalësoi shumë trajnimin.
Unë kam rimenduar qasjen time për përdorimin e të dhënave. Megjithëse të dhënat varen nga koha, unë nuk pashë ndonjë rrjedhje të dukshme informacioni "në të ardhmen", megjithatë, për çdo rast, e zbërtheva kështu:
Seti i trajnimit që na u dha (shkurt dhe 2 javë mars) ishte i ndarë në 2 pjesë.
Modeli u trajnua mbi të dhënat e N ditëve të fundit. Grumbullimet e përshkruara më sipër u ndërtuan mbi të gjitha të dhënat, duke përfshirë testin. Në të njëjtën kohë, janë shfaqur të dhëna mbi të cilat është e mundur të ndërtohen kodime të ndryshme të ndryshores së synuar. Qasja më e thjeshtë është të ripërdorni kodin që tashmë po krijon veçori të reja, dhe thjesht t'i jepni të dhëna mbi të cilat nuk do të trajnohet dhe synoni = 1.
Kështu, ne morëm karakteristika të ngjashme:
- Sa herë ka parë userId një postim në pronarin e grupit;
- Sa herë userId e ka pëlqyer postimin në pronarin e grupit;
- Përqindja e postimeve që userId i pëlqeu nga pronari Id.
Domethënë doli kodimi mesatar i synuar në një pjesë të grupit të të dhënave për kombinime të ndryshme të veçorive kategorike. Në parim, catboost ndërton gjithashtu kodimin e synuar dhe nga ky këndvështrim nuk ka asnjë përfitim, por, për shembull, u bë e mundur numërimi i numrit të përdoruesve unikë që pëlqejnë postimet në këtë grup. Në të njëjtën kohë, qëllimi kryesor u arrit - grupi i të dhënave ime u zvogëlua disa herë dhe ishte e mundur të vazhdoja të gjeneroja veçori.
Ndërsa catboost mund të ndërtojë kodim vetëm në bazë të reagimit të pëlqyer, reagimet kanë reagime të tjera: të rindarë, të papëlqyer, të papëlqyer, të klikuar, të shpërfillur, kodime për të cilat mund të bëhen manualisht. Rillogarita të gjitha llojet e agregateve dhe eliminova veçoritë me rëndësi të ulët për të mos fryrë grupin e të dhënave.
Në atë kohë unë isha në vendin e parë me një diferencë të madhe. E vetmja gjë që ishte konfuze ishte se futjet e imazhit nuk treguan pothuajse asnjë rritje. Ideja erdhi për të dhënë gjithçka për catboost. Ne grupojmë imazhet e Kmeans dhe marrim një veçori të re kategorike imageCat.
Këtu janë disa klasa pas filtrimit manual dhe bashkimit të grupimeve të marra nga KMeans.
Bazuar në imageCat ne gjenerojmë:
- Karakteristikat e reja kategorike:
- Cili imageCat u pa më shpesh nga userId;
- Cili imageCat më shpesh tregon pronarin ID;
- Cili imageCat pëlqehej më shpesh nga userId;
- Sportele të ndryshme:
- Sa imazhe unike shikoi userId;
- Rreth 15 veçori të ngjashme plus kodimin e objektivit siç përshkruhet më sipër.
tekstet
Rezultatet në konkursin e imazhit më përshtaten dhe vendosa të provoj dorën time në tekste. Nuk kam punuar shumë me tekste më parë dhe marrëzisht e kam vrarë ditën në tf-idf dhe svd. Pastaj pashë bazën me doc2vec, i cili bën pikërisht atë që më nevojitet. Duke rregulluar pak parametrat doc2vec, mora ngulitje teksti.
Dhe pastaj thjesht ripërdora kodin për imazhet, në të cilat zëvendësova ngulitje të imazhit me ngulitje teksti. Si rezultat, unë zura vendin e 2-të në konkursin e tekstit.
Sistemi bashkëpunues
Kishte mbetur një konkurs që ende nuk e kisha "shpirë" me shkop, dhe duke gjykuar nga AUC në tabelën e drejtuesve, rezultatet e këtij konkursi të veçantë duhet të kishin ndikimin më të madh në fazën offline.
Mora të gjitha tiparet që ishin në të dhënat burimore, zgjodha ato kategorike dhe llogarita të njëjtat agregate si për imazhet, përveç veçorive të bazuara në vetë imazhet. Thjesht vendosja e kësaj në catboost më çoi në vendin e 2-të.
Hapat e parë të optimizimit të catboost
Një vend i parë dhe dy i dyti më kënaqën, por u kuptua se nuk kisha bërë asgjë të veçantë, që do të thotë se mund të prisja një humbje pozicionesh.
Detyra e konkursit është të rendit postimet brenda përdoruesit, dhe gjatë gjithë kësaj kohe po zgjidhja problemin e klasifikimit, domethënë, duke optimizuar metrikën e gabuar.
Më lejoni t'ju jap një shembull të thjeshtë:
| ID e përdoruesit | objektId | parashikim | e vërteta bazë |
|---|---|---|---|
| 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 |
Le të bëjmë një riorganizim të vogël
| ID e përdoruesit | objektId | parashikim | e vërteta bazë |
|---|---|---|---|
| 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 |
Ne marrim rezultatet e mëposhtme:
| Model | AUC | Përdoruesi 1 AUC | Përdoruesi 2 AUC | do të thotë AUC |
|---|---|---|---|---|
| Opsioni 1 | 0,8 | 1,0 | 0,0 | 0,5 |
| Opsioni 2 | 0,7 | 0,75 | 1,0 | 0,875 |
Siç mund ta shihni, përmirësimi i metrikës së përgjithshme AUC nuk do të thotë përmirësim i metrikës mesatare të AUC brenda një përdoruesi.
Catboost nga kutia. Kam lexuar për matjet e renditjes, kur përdorni catboost dhe vendosni YetiRankPairwise të stërvitet gjatë natës. Rezultati nuk ishte mbresëlënës. Duke vendosur që nuk isha i trajnuar, ndryshova funksionin e gabimit në QueryRMSE, i cili, duke gjykuar nga dokumentacioni i catboost, konvergjon më shpejt. Në fund mora të njëjtat rezultate si në stërvitjen për klasifikim, por ansamblet e këtyre dy modeleve dhanë një rritje të mirë, gjë që më solli vendin e parë në të tre garat.
5 minuta para mbylljes së skenës online të konkursit "Sistemet Bashkëpunuese", Sergej Shalnov më çoi në vendin e dytë. Së bashku ecëm rrugën e mëtejshme.
Përgatitja për fazën offline
Na ishte garantuar fitorja në skenën online me një kartë video RTX 2080 TI, por çmimi kryesor prej 300 rubla dhe, me shumë mundësi, edhe vendi i parë përfundimtar na detyruan të punojmë për këto 000 javë.
Siç doli, Sergey përdori gjithashtu catboost. Kemi shkëmbyer ide dhe veçori dhe mësova e cila përmbante përgjigje për shumë nga pyetjet e mia, madje edhe për ato që nuk i kisha pasur ende në atë kohë.
Shikimi i raportit më çoi në idenë se duhet t'i kthejmë të gjithë parametrat në vlerën e paracaktuar dhe t'i bëjmë cilësimet me shumë kujdes dhe vetëm pasi të rregullojmë një grup funksionesh. Tani një stërvitje zgjati rreth 15 orë, por një model arriti të merrte një shpejtësi më të mirë se ajo e marrë në ansambël me renditje.
Gjenerimi i veçorive
Në konkursin e Sistemeve Bashkëpunuese, një numër i madh karakteristikash vlerësohen si të rëndësishme për modelin. Për shembull, auditweights_spark_svd - shenja më e rëndësishme, por nuk ka asnjë informacion se çfarë do të thotë. Mendova se do të ishte e vlefshme të numëroja agregatët e ndryshëm bazuar në karakteristika të rëndësishme. Për shembull, auditweights_spark_svd mesatare sipas përdoruesit, grupit, objektit. E njëjta gjë mund të llogaritet duke përdorur të dhëna mbi të cilat nuk është kryer asnjë trajnim dhe objektivi = 1, domethënë mesatarja auditweights_spark_svd nga përdoruesi sipas objekteve që i pëlqenin. Shenja të rëndësishme përveç auditweights_spark_svd, ishin disa. Ja disa prej tyre:
- peshat e auditimitCtrGjinia
- peshat e auditimitCtrLart
- përdoruesOwnerCounterCreatePëlqime
Për shembull, mesatarja peshat e auditimitCtrGjinia sipas userId doli të ishte një veçori e rëndësishme, ashtu si vlera mesatare përdoruesOwnerCounterCreatePëlqime nga userId+ownerId. Kjo tashmë duhet t'ju bëjë të mendoni se duhet të kuptoni kuptimin e fushave.
Gjithashtu karakteristika të rëndësishme ishin Pesha e auditimitPëlqimeNumërimi и peshën e auditimitShfaq Numri. Duke e ndarë njërën nga tjetra, u përftua një veçori edhe më e rëndësishme.
Rrjedhjet e të dhënave
Konkurrenca dhe modelimi i prodhimit janë detyra shumë të ndryshme. Gjatë përgatitjes së të dhënave, është shumë e vështirë të merren parasysh të gjitha detajet dhe të mos përcillen disa informacione jo të parëndësishme në lidhje me variablin e synuar në test. Nëse po krijojmë një zgjidhje prodhimi, do të përpiqemi të shmangim përdorimin e rrjedhjeve të të dhënave gjatë trajnimit të modelit. Por nëse duam të fitojmë konkursin, atëherë rrjedhjet e të dhënave janë tiparet më të mira.
Pasi të keni studiuar të dhënat, mund të shihni se sipas vlerave të objektit Pesha e auditimitPëlqimeNumërimi и peshën e auditimitShfaq Numri ndryshimi, që do të thotë se raporti i vlerave maksimale të këtyre veçorive do të pasqyrojë konvertimin e postës shumë më mirë sesa raporti në momentin e shfaqjes.
Rrjedhja e parë që gjetëm është peshave të auditimitPëlqimeNumërimiMaks/pesha e auditimitShfaq NumriMaks.
Por çka nëse i shikojmë të dhënat më nga afër? Le të renditim sipas datës së shfaqjes dhe të marrim:
| objektId | ID e përdoruesit | peshën e auditimitShfaq Numri | Pesha e auditimitPëlqimeNumërimi | objektiv (është i pëlqyer) |
|---|---|---|---|---|
| 1 | 1 | 12 | 3 | me siguri jo |
| 1 | 2 | 15 | 3 | ndoshta po |
| 1 | 3 | 16 | 4 |
Ishte e habitshme kur gjeta shembullin e parë të tillë dhe doli që parashikimi im nuk u realizua. Por, duke marrë parasysh faktin se vlerat maksimale të këtyre karakteristikave brenda objektit dhanë një rritje, ne nuk u përtaci dhe vendosëm të gjejmë pesha e auditimitShfaq NumriTjetra и peshat e auditimitPëlqimetNumriTjetër, domethënë vlerat në momentin tjetër në kohë. Duke shtuar një veçori
(AuditweightsShowsCountNext-AuditweightsShowsCount)/(audit-peshoreSlikescount-AuditweightSlikescountNext) bëmë një kërcim të fortë shpejt.
Rrjedhje të ngjashme mund të përdoren duke gjetur vlerat e mëposhtme për përdoruesOwnerCounterCreatePëlqime brenda userId+ownerId dhe, për shembull, peshat e auditimitCtrGjinia brenda objectId+userGender. Kemi gjetur 6 fusha të ngjashme me rrjedhje dhe kemi nxjerrë sa më shumë informacion prej tyre.
Deri në atë kohë, ne kishim shtrydhur sa më shumë informacion që të ishte e mundur nga veçoritë e bashkëpunimit, por nuk u kthyem në garat e imazhit dhe tekstit. Kisha një ide të shkëlqyeshme për të kontrolluar: sa japin veçoritë e bazuara drejtpërdrejt në imazhe ose tekste në konkurset përkatëse?
Nuk kishte rrjedhje në konkurset e imazhit dhe tekstit, por deri në atë kohë kisha kthyer parametrat e paracaktuar të catboost, pastrova kodin dhe shtova disa veçori. Totali ishte:
| vendim | i shpejtë |
|---|---|
| Maksimumi me imazhe | 0.6411 |
| Maksimumi nuk ka imazhe | 0.6297 |
| Rezultati i vendit të dytë | 0.6295 |
| vendim | i shpejtë |
|---|---|
| Maksimumi me tekste | 0.666 |
| Maksimumi pa tekste | 0.660 |
| Rezultati i vendit të dytë | 0.656 |
| vendim | i shpejtë |
|---|---|
| Maksimumi në bashkëpunim | 0.745 |
| Rezultati i vendit të dytë | 0.723 |
U bë e qartë se nuk kishim gjasa të kishim mundësi të shtrydhnim shumë tekste dhe imazhe, dhe pasi provuam disa nga idetë më interesante, ndaluam së punuari me to.
Gjenerimi i mëtejshëm i veçorive në sistemet bashkëpunuese nuk dha një rritje dhe ne filluam të renditemi. Në skenën online, ansambli i klasifikimit dhe renditjes më dha një rritje të vogël, siç doli sepse e kisha nëntrajnuar klasifikimin. Asnjë nga funksionet e gabimit, duke përfshirë YetiRanlPairwise, nuk prodhoi diku afër rezultatit që bëri LogLoss (0,745 kundrejt 0,725). Kishte ende shpresë për QueryCrossEntropy, i cili nuk mund të lansohej.
Faza jashtë linje
Në fazën offline, struktura e të dhënave mbeti e njëjtë, por pati ndryshime të vogla:
- identifikuesit userId, objectId, ownerId u rirandomizuan;
- disa tabela u hoqën dhe disa u riemëruan;
- të dhënat janë rritur afërsisht 1,5 herë.
Përveç vështirësive të listuara, kishte një plus të madh: ekipit iu nda një server i madh me një RTX 2080TI. Unë kam shijuar htop për një kohë të gjatë.
Kishte vetëm një ide - thjesht të riprodhonte atë që ekziston. Pasi kaluam disa orë duke vendosur mjedisin në server, gradualisht filluam të verifikonim që rezultatet ishin të riprodhueshme. Problemi kryesor me të cilin po përballemi është rritja e vëllimit të të dhënave. Vendosëm të zvogëlojmë pak ngarkesën dhe vendosëm parametrin catboost ctr_complexity=1. Kjo ul shpejtësinë pak, por modeli im filloi të funksionojë, rezultati ishte i mirë - 0,733. Sergei, ndryshe nga unë, nuk i ndau të dhënat në 2 pjesë dhe u stërvit në të gjitha të dhënat, megjithëse kjo dha rezultatet më të mira në fazën online, në fazën offline kishte shumë vështirësi. Nëse do të merrnim të gjitha tiparet që krijuam dhe do të përpiqeshim t'i fusnim në catboost, atëherë asgjë nuk do të funksiononte në fazën online. Sergey bëri optimizimin e tipit, për shembull, duke konvertuar llojet float64 në float32. Mund të gjeni informacione për optimizimin e kujtesës në panda. Si rezultat, Sergey stërviti në CPU duke përdorur të gjitha të dhënat dhe mori rreth 0,735.
Këto rezultate ishin të mjaftueshme për të fituar, por ne fshehëm shpejtësinë tonë të vërtetë dhe nuk mund të ishim të sigurt se skuadrat e tjera nuk po bënin të njëjtën gjë.
Luftoni deri në fund
Tuning Catboost
Zgjidhja jonë u riprodhua plotësisht, ne shtuam veçoritë e të dhënave dhe imazheve të tekstit, kështu që mbeti vetëm të rregullonim parametrat e catboost. Sergey stërviti në CPU me një numër të vogël përsëritjesh, dhe unë u stërvita në atë me ctr_complexity=1. Kishte mbetur edhe një ditë, dhe nëse thjesht shtoni përsëritje ose rritni ctr_complexity, atëherë deri në mëngjes mund të merrni një shpejtësi edhe më të mirë dhe të ecni gjithë ditën.
Në fazën offline, shpejtësitë mund të fshihen shumë lehtë thjesht duke zgjedhur jo zgjidhjen më të mirë në sit. Prisnim ndryshime drastike në tabelën e liderëve në minutat e fundit para mbylljes së paraqitjeve dhe vendosëm të mos ndalemi.
Nga videoja e Anna, mësova se për të përmirësuar cilësinë e modelit, është mirë të zgjidhni parametrat e mëposhtëm:
- shkalla e të mësuarit — Vlera e paracaktuar llogaritet bazuar në madhësinë e grupit të të dhënave. Rritja e normës së mësimit kërkon rritjen e numrit të përsëritjeve.
- l2_leaf_reg — Koeficienti i rregullimit, vlera e paracaktuar 3, preferohet të zgjidhni nga 2 në 30. Zvogëlimi i vlerës çon në një rritje të mbipërshtatjes.
- thes_temperatura — shton rastësi në peshat e objekteve në kampion. Vlera e paracaktuar është 1, ku peshat janë nxjerrë nga një shpërndarje eksponenciale. Ulja e vlerës çon në një rritje të mbipërshtatjes.
- fuqi_i rastit — Ndikon në zgjedhjen e ndarjeve në një përsëritje specifike. Sa më e lartë të jetë fuqia_rastësore, aq më e lartë është mundësia që të zgjidhet një ndarje me rëndësi të ulët. Në çdo përsëritje të mëvonshme, rastësia zvogëlohet. Ulja e vlerës çon në një rritje të mbipërshtatjes.
Parametrat e tjerë kanë një efekt shumë më të vogël në rezultatin përfundimtar, kështu që nuk u përpoqa t'i zgjedh ato. Një përsëritje e trajnimit në grupin tim të të dhënave GPU me ctr_complexity=1 zgjati 20 minuta dhe parametrat e zgjedhur në grupin e të dhënave të reduktuara ishin paksa të ndryshme nga ato optimale në grupin e plotë të të dhënave. Në fund, bëra rreth 30 përsëritje në 10% të të dhënave, dhe më pas rreth 10 përsëritje të tjera në të gjitha të dhënat. Doli diçka si kjo:
- shkalla e të mësuarit Unë u rrita me 40% nga parazgjedhja;
- l2_leaf_reg e la të njëjtë;
- thes_temperatura и fuqi_i rastit reduktuar në 0,8.
Mund të konkludojmë se modeli ishte nëntrajnuar me parametrat e paracaktuar.
U befasova shumë kur pashë rezultatin në tabelën e drejtuesve:
| Model | modeli 1 | modeli 2 | modeli 3 | ansambël |
|---|---|---|---|---|
| Pa akordim | 0.7403 | 0.7404 | 0.7404 | 0.7407 |
| Me akordim | 0.7406 | 0.7405 | 0.7406 | 0.7408 |
Përfundova për veten time që nëse aplikimi i shpejtë i modelit nuk është i nevojshëm, atëherë është më mirë të zëvendësohet përzgjedhja e parametrave me një ansambël prej disa modelesh duke përdorur parametra jo të optimizuar.
Sergey po optimizonte madhësinë e grupit të të dhënave për ta ekzekutuar atë në GPU. Mundësia më e thjeshtë është ndërprerja e një pjese të të dhënave, por kjo mund të bëhet në disa mënyra:
- hiqni gradualisht të dhënat më të vjetra (fillimi i shkurtit) derisa grupi i të dhënave të fillojë të futet në kujtesë;
- hiqni veçoritë me rëndësinë më të vogël;
- hiqni ID-të e përdoruesve për të cilat ka vetëm një hyrje;
- lini vetëm ID-të e përdoruesve që janë në test.
Dhe në fund të fundit, bëni një ansambël nga të gjitha opsionet.
Ansambli i fundit
Në orët e vona të mbrëmjes së ditës së fundit, ne kishim paraqitur një ansambël të modeleve tona që jepnin 0,742. Brenda natës lansova modelin tim me ctr_complexity=2 dhe në vend të 30 minutave u stërvita për 5 orë. Vetëm në orën 4 të mëngjesit u numërua dhe bëra ansamblin e fundit, i cili dha 0,7433 në tabelën e drejtuesve të publikut.
Për shkak të qasjeve të ndryshme për zgjidhjen e problemit, parashikimet tona nuk ishin të lidhura fort, gjë që dha një rritje të mirë në ansambël. Për të marrë një ansambël të mirë, është më mirë të përdorni modelin e papërpunuar të parashikimeve predict(prediction_type='RawFormulaVal') dhe të vendosni scale_pos_weight=neg_count/pos_count.
Në faqen e internetit mund të shihni .
Zgjidhje të tjera
Shumë ekipe ndoqën kanonet e algoritmeve të sistemit rekomandues. Unë, duke mos qenë ekspert në këtë fushë, nuk mund t'i vlerësoj, por mbaj mend 2 zgjidhje interesante.
- . Nikolay, duke qenë punonjës i Mail.ru, nuk aplikoi për çmime, kështu që qëllimi i tij nuk ishte të arrinte shpejtësinë maksimale, por të merrte një zgjidhje lehtësisht të shkallëzueshme.
- Vendimi i ekipit fitues të çmimit të jurisë bazuar në , lejohet për grupim shumë të mirë të imazheve pa punë manuale.
Përfundim
Ajo që më ka mbetur më shumë në kujtesë:
- Nëse ka veçori kategorike në të dhëna dhe ju e dini se si të bëni kodimin e synuar në mënyrë korrekte, është akoma më mirë të provoni catboost.
- Nëse jeni duke marrë pjesë në një konkurs, nuk duhet të humbni kohë duke përzgjedhur parametra të tjerë përveç normës së mësimit dhe përsëritjeve. Një zgjidhje më e shpejtë është të bëni një ansambël të disa modeleve.
- Rritjet mund të mësohen në GPU. Catboost mund të mësojë shumë shpejt në GPU, por ha shumë memorie.
- Gjatë zhvillimit dhe testimit të ideve, është më mirë të vendosni një rsm të vogël~=0.2 (vetëm CPU) dhe ctr_complexity=1.
- Ndryshe nga ekipet e tjera, ansambli i modeleve tona dha një rritje të madhe. Kemi shkëmbyer vetëm ide dhe kemi shkruar në gjuhë të ndryshme. Ne kishim një qasje të ndryshme për ndarjen e të dhënave dhe, mendoj, secila kishte gabimet e veta.
- Nuk është e qartë pse optimizimi i renditjes ka performuar më keq se optimizimi i klasifikimit.
- Kam fituar një përvojë duke punuar me tekste dhe një kuptim se si janë krijuar sistemet e rekomanduesve.
Falenderojmë organizatorët për emocionet, njohuritë dhe çmimet e marra.
Burimi: www.habr.com