Mnamo Februari-Machi 2019, shindano lilifanyika ili kuorodhesha malisho ya mtandao wa kijamii , ambapo timu yetu ilichukua nafasi ya kwanza. Katika makala nitazungumza juu ya shirika la mashindano, njia tulizojaribu, na mipangilio ya kiboreshaji cha mafunzo kwenye data kubwa.
SNA Hackathon
Hii ni mara ya tatu kwamba hackathon chini ya jina hili inafanyika. Imeandaliwa na mtandao wa kijamii ok.ru, kwa mtiririko huo, kazi na data zinahusiana moja kwa moja na mtandao huu wa kijamii.
SNA (uchambuzi wa mtandao wa kijamii) katika kesi hii inaeleweka kwa usahihi zaidi sio kama uchambuzi wa grafu ya kijamii, lakini kama uchambuzi wa mtandao wa kijamii.
- Mnamo 2014, kazi ilikuwa kutabiri idadi ya likes ambazo chapisho lingepata.
- Mnamo 2016 - kazi ya VVZ (labda unajulikana), karibu na uchambuzi wa grafu ya kijamii.
- Mnamo 2019, weka orodha ya mipasho ya mtumiaji kulingana na uwezekano kwamba mtumiaji atapenda chapisho.
Siwezi kusema kuhusu 2014, lakini mwaka wa 2016 na 2019, pamoja na uwezo wa uchambuzi wa data, ujuzi wa kufanya kazi na data kubwa pia ulihitajika. Nadhani ilikuwa mchanganyiko wa kujifunza kwa mashine na matatizo makubwa ya usindikaji wa data ambayo yalinivutia kwenye mashindano haya, na uzoefu wangu katika maeneo haya ulinisaidia kushinda.
mlbootcamp
Mnamo 2019, shindano hilo lilipangwa kwenye jukwaa .
Shindano hilo lilianza mkondoni mnamo Februari 7 na lilikuwa na majukumu 3. Mtu yeyote anaweza kujiandikisha kwenye tovuti, pakua na kupakia gari lako kwa saa chache. Mwishoni mwa hatua ya mtandaoni mnamo Machi 15, 15 bora wa kila tukio la kuruka onyesho walialikwa kwenye ofisi ya Mail.ru kwa hatua ya nje ya mtandao, ambayo ilifanyika kutoka Machi 30 hadi Aprili 1.
Kazi
Data chanzo hutoa vitambulisho vya mtumiaji (kitambulisho cha mtumiaji) na vitambulisho vya chapisho (objectId). Ikiwa mtumiaji alionyeshwa chapisho, basi data ina laini iliyo na kitambulisho cha mtumiaji, kitu kitambulisho, maoni ya mtumiaji kwa chapisho hili (maoni) na seti ya vipengele au viungo mbalimbali vya picha na maandishi.
| kitambulisho cha mtumiaji | objectId | kitambulisho cha mmiliki | maoni | picha |
|---|---|---|---|---|
| 3555 | 22 | 5677 | [ilipenda, imebofya] | [hash1] |
| 12842 | 55 | 32144 | [haikupenda] | [hash2, hash3] |
| 13145 | 35 | 5677 | [ilibofya, ilishirikiwa] | [hash2] |
Seti ya data ya majaribio ina muundo sawa, lakini sehemu ya maoni haipo. Jukumu ni kutabiri uwepo wa majibu 'yaliyopendwa' katika sehemu ya maoni.
Faili ya uwasilishaji ina muundo ufuatao:
| kitambulisho cha mtumiaji | Orodha Iliyopangwa[objectId] |
|---|---|
| 123 | 78,13,54,22 |
| 128 | 35,61,55 |
| 131 | 35,68,129,11 |
Kipimo ni wastani wa ROC AUC kwa watumiaji.
Maelezo ya kina zaidi ya data yanaweza kupatikana. Unaweza pia kupakua data huko, ikiwa ni pamoja na vipimo na picha.
Hatua ya mtandaoni
Katika hatua ya mtandaoni, kazi iligawanywa katika sehemu 3
- - inajumuisha vipengele vyote isipokuwa picha na maandishi;
- - inajumuisha habari tu kuhusu picha;
- β inajumuisha habari kuhusu maandishi pekee.
Hatua ya nje ya mtandao
Katika hatua ya nje ya mtandao, data ilijumuisha vipengele vyote, ilhali maandishi na picha zilikuwa chache. Kulikuwa na safu mlalo mara 1,5 zaidi kwenye mkusanyiko wa data, ambazo tayari zilikuwa nyingi.
Suluhisho la tatizo
Kwa kuwa mimi hufanya CV kazini, nilianza safari yangu katika shindano hili na kazi ya "Picha". Data ambayo ilitolewa ilikuwa userId, objectId, ownerId (kundi ambalo chapisho lilichapishwa), mihuri ya muda ya kuunda na kuonyesha chapisho, na, bila shaka, picha ya chapisho hili.
Baada ya kutoa vipengele kadhaa kulingana na mihuri ya muda, wazo lililofuata lilikuwa kuchukua safu ya mwisho ya neuroni iliyofunzwa awali kwenye imagenet na kutuma upachikaji huu kwenye uboreshaji.
Matokeo hayakuwa ya kuvutia. Upachikaji kutoka kwa neuroni ya imagenet sio muhimu, nilifikiri, nahitaji kutengeneza kisimbaji kiotomatiki changu mwenyewe.
Ilichukua muda mwingi na matokeo hayakuboresha.
Kizazi cha kipengele
Kufanya kazi na picha huchukua muda mwingi, kwa hivyo niliamua kufanya kitu rahisi zaidi.
Kama unavyoona mara moja, kuna huduma kadhaa za kitengo kwenye hifadhidata, na ili nisijisumbue sana, nilichukua kiboreshaji tu. Suluhisho lilikuwa bora, bila mipangilio yoyote nilifika mara moja kwenye safu ya kwanza ya ubao wa wanaoongoza.
Kuna data nyingi na imewekwa katika muundo wa parquet, kwa hivyo bila kufikiria mara mbili, nilichukua scala na kuanza kuandika kila kitu kwa cheche.
Vipengele rahisi vilivyotoa ukuaji zaidi kuliko upachikaji wa picha:
- ni mara ngapi objectId, userId na ownerId vilionekana kwenye data (inapaswa kuhusishwa na umaarufu);
- ni machapisho mangapi ya kitambulisho cha mtumiaji ameona kutoka kwa kitambulisho cha mmiliki (yanapaswa kuhusishwa na maslahi ya mtumiaji kwenye kikundi);
- ni vitambulisho vingapi vya kipekee vya mtumiaji vilivyotazama machapisho kutoka kwa kitambulisho cha mmiliki (huonyesha ukubwa wa hadhira ya kikundi).
Kutoka kwa mihuri ya muda iliwezekana kupata muda wa siku ambapo mtumiaji alitazama mipasho (asubuhi/mchana/jioni/usiku). Kwa kuchanganya kategoria hizi, unaweza kuendelea kutoa vipengele:
- mtumiajiId aliingia mara ngapi jioni;
- ni wakati gani chapisho hili linaonyeshwa mara nyingi (objectId) na kadhalika.
Yote hii polepole iliboresha metriki. Lakini saizi ya seti ya data ya mafunzo ni takriban rekodi 20M, kwa hivyo kuongeza vipengele kulipunguza kasi ya mafunzo.
Nimefikiria tena mbinu yangu ya kutumia data. Ingawa data inategemea wakati, sikuona uvujaji wa habari yoyote dhahiri "katika siku zijazo", walakini, ikiwa tu, niliivunja kama hii:
Seti ya mafunzo iliyotolewa kwetu (Februari na wiki 2 za Machi) iligawanywa katika sehemu 2.
Muundo huo ulifunzwa kuhusu data kutoka siku N zilizopita. Majumuisho yaliyofafanuliwa hapo juu yalijengwa kwenye data yote, pamoja na jaribio. Wakati huo huo, data imeonekana ambayo inawezekana kujenga encodings mbalimbali za kutofautiana kwa lengo. Njia rahisi zaidi ni kutumia tena nambari ya kuthibitisha ambayo tayari inaunda vipengele vipya, na kuilisha tu data ambayo haitafunzwa na kulenga = 1.
Kwa hivyo, tulipata sifa zinazofanana:
- Ni mara ngapi userId kuona chapisho kwenye kitambulisho cha mmiliki wa kikundi;
- Ni mara ngapi userId alipenda chapisho katika kitambulisho cha mmiliki wa kikundi;
- Asilimia ya machapisho ambayo userId alipenda kutoka kwa kitambulisho cha mmiliki.
Hiyo ni, iligeuka maana ya usimbaji lengwa kwa sehemu ya mkusanyiko wa data kwa michanganyiko mbalimbali ya vipengele vya kategoria. Kimsingi, catboost pia hujenga encoding lengo na kutoka kwa mtazamo huu hakuna faida, lakini, kwa mfano, ikawa inawezekana kuhesabu idadi ya watumiaji wa kipekee ambao walipenda machapisho katika kikundi hiki. Wakati huo huo, lengo kuu lilipatikana - hifadhidata yangu ilipunguzwa mara kadhaa, na iliwezekana kuendelea kutoa huduma.
Ingawa catboost inaweza kuunda usimbaji tu kulingana na maoni yaliyopendezwa, maoni yana miitikio mingine: iliyoshirikiwa upya, haijapendwa, haijapendwa, kubofya, kupuuzwa, usimbaji ambao unaweza kufanywa mwenyewe. Nilihesabu tena aina zote za mijumuisho na kuondoa vipengele vilivyo na umuhimu wa chini ili nisijaze mkusanyiko wa data.
Wakati huo nilikuwa katika nafasi ya kwanza kwa tofauti kubwa. Jambo pekee ambalo lilikuwa linachanganya ni kwamba upachikaji wa picha ulionyesha karibu hakuna ukuaji. Wazo lilikuja kutoa kila kitu kwa catboost. Tunakusanya picha za Kmeans na kupata kipengele kipya cha picha ya Cat.
Hapa kuna baadhi ya madarasa baada ya kuchuja kwa mikono na kuunganishwa kwa vikundi vilivyopatikana kutoka kwa KMeans.
Kulingana na pichaCat tunatengeneza:
- Vipengele vipya vya kitengo:
- Picha ya Paka gani mara nyingi ilitazamwa na userId;
- Ambayo pichaPaka mara nyingi huonyesha kitambulisho cha mmiliki;
- Ni picha gani ya Paka ilipendwa zaidi na mtumiajiId;
- Kaunta mbalimbali:
- Ni picha ngapi za kipekee zaPaka ilitazama userId;
- Takriban vipengele 15 vinavyofanana pamoja na usimbaji lengwa kama ilivyoelezwa hapo juu.
Maandishi
Matokeo katika shindano la picha yalinifaa na niliamua kujaribu mkono wangu kwenye maandishi. Sijafanya kazi sana na maandishi hapo awali na, kwa ujinga, niliua siku kwenye tf-idf na svd. Kisha nikaona msingi na doc2vec, ambayo hufanya kile ninachohitaji. Baada ya kurekebisha kidogo vigezo vya doc2vec, nilipata upachikaji wa maandishi.
Na kisha nilitumia tena nambari ya picha, ambayo nilibadilisha upachikaji wa picha na upachikaji wa maandishi. Kama matokeo, nilichukua nafasi ya 2 kwenye shindano la maandishi.
Mfumo wa ushirikiano
Kulikuwa na shindano moja lililosalia ambalo nilikuwa bado "sijachokoza" kwa fimbo, na kwa kuzingatia AUC kwenye ubao wa wanaoongoza, matokeo ya shindano hili mahususi yangefaa kuwa na athari kubwa zaidi kwenye hatua ya nje ya mtandao.
Nilichukua vipengele vyote vilivyokuwa kwenye data ya chanzo, nikachagua za kategoria na kukokotoa hesabu sawa na za picha, isipokuwa vipengele kulingana na picha zenyewe. Kuweka tu hii katika uboreshaji kumenifikisha kwenye nafasi ya 2.
Hatua za kwanza za uboreshaji wa catboost
Nafasi moja ya kwanza na ya pili ilinifurahisha, lakini kulikuwa na uelewa kwamba sikuwa nimefanya chochote maalum, ambayo inamaanisha ningeweza kutarajia kupoteza nafasi.
Kusudi la shindano ni kupanga machapisho ndani ya mtumiaji, na wakati huu wote nilikuwa nikisuluhisha shida ya uainishaji, ambayo ni, kuboresha metriki isiyo sahihi.
Acha nikupe mfano rahisi:
| kitambulisho cha mtumiaji | objectId | utabiri | ukweli wa msingi |
|---|---|---|---|
| 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 |
Wacha tufanye upangaji upya mdogo
| kitambulisho cha mtumiaji | objectId | utabiri | ukweli wa msingi |
|---|---|---|---|
| 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 |
Tunapata matokeo yafuatayo:
| mfano | AUC | Mtumiaji1 AUC | Mtumiaji2 AUC | maana ya AUC |
|---|---|---|---|---|
| Chaguo 1 | 0,8 | 1,0 | 0,0 | 0,5 |
| Chaguo 2 | 0,7 | 0,75 | 1,0 | 0,875 |
Kama unavyoona, kuboresha kipimo cha jumla cha AUC haimaanishi kuboresha wastani wa kipimo cha AUC ndani ya mtumiaji.
Kuongeza kasi kutoka kwa sanduku. Nilisoma kuhusu viwango vya viwango, unapotumia catboost na uweke YetiRankPairwise kufanya mazoezi usiku kucha. Matokeo hayakuwa ya kuvutia. Kuamua kuwa sikufundishwa vizuri, nilibadilisha utendakazi wa makosa kuwa QueryRMSE, ambayo, kwa kuzingatia hati za catboost, hubadilika haraka. Mwishowe, nilipata matokeo sawa na wakati wa mafunzo ya uainishaji, lakini ensembles za aina hizi mbili zilitoa ongezeko nzuri, ambalo lilinileta nafasi ya kwanza katika mashindano yote matatu.
Dakika 5 kabla ya kufungwa kwa hatua ya mtandaoni ya shindano la "Mifumo ya Ushirikiano", Sergey Shalnov alinihamisha hadi nafasi ya pili. Tulitembea njia zaidi pamoja.
Inajiandaa kwa hatua ya nje ya mtandao
Tulihakikishiwa ushindi katika hatua ya mtandaoni na kadi ya video ya RTX 2080 TI, lakini tuzo kuu ya rubles 300 na, uwezekano mkubwa, hata nafasi ya kwanza ya mwisho ilitulazimisha kufanya kazi kwa wiki hizi 000.
Kama ilivyotokea, Sergey pia alitumia kiboreshaji. Tulibadilishana mawazo na vipengele, na nikajifunza kuhusu ambayo ilikuwa na majibu kwa maswali yangu mengi, na hata yale ambayo nilikuwa bado sina wakati huo.
Kuangalia ripoti kuliniongoza kwenye wazo kwamba tunahitaji kurudisha vigezo vyote kwa thamani ya chaguo-msingi, na kufanya mipangilio kwa uangalifu sana na tu baada ya kurekebisha seti ya vipengele. Sasa mafunzo moja yalichukua kama masaa 15, lakini mtindo mmoja uliweza kupata kasi bora kuliko ile iliyopatikana kwenye mkusanyiko na cheo.
Kizazi cha kipengele
Katika shindano la Mifumo ya Ushirikiano, idadi kubwa ya vipengele hutathminiwa kuwa muhimu kwa modeli. Kwa mfano, auditweights_spark_svd - ishara muhimu zaidi, lakini hakuna taarifa kuhusu maana yake. Nilidhani ingefaa kuhesabu majumuisho mbalimbali kulingana na vipengele muhimu. Kwa mfano, wastani wa auditweights_spark_svd kwa mtumiaji, kwa kikundi, kwa kitu. Vile vile vinaweza kuhesabiwa kwa kutumia data ambayo hakuna mafunzo yanayofanywa na lengo = 1, yaani, wastani auditweights_spark_svd kwa mtumiaji kwa vitu alivyopenda. Mbali na ishara muhimu auditweights_spark_svd, kulikuwa na kadhaa. Hapa kuna baadhi yao:
- uzaniCtrGender
- auditweightsCTrHigh
- userOwnerCounterCreateLikes
Kwa mfano, wastani uzaniCtrGender kulingana na userId iligeuka kuwa kipengele muhimu, kama thamani ya wastani userOwnerCounterCreateLikes kwa mtumiajiId+ownerId. Hii inapaswa kukufanya ufikirie kuwa unahitaji kuelewa maana ya uwanja.
Pia vipengele muhimu vilikuwa auditweightsLikesCount ΠΈ auditweightsShowsCount. Kugawanya moja kwa nyingine, kipengele muhimu zaidi kilipatikana.
Uvujaji wa data
Ushindani na modeli za uzalishaji ni kazi tofauti sana. Wakati wa kuandaa data, ni vigumu sana kuzingatia maelezo yote na si kuwasilisha taarifa zisizo za kawaida kuhusu kutofautiana kwa lengo katika mtihani. Ikiwa tunaunda suluhisho la uzalishaji, tutajaribu kuzuia kutumia uvujaji wa data wakati wa kufunza modeli. Lakini ikiwa tunataka kushinda shindano, basi uvujaji wa data ndio sifa bora zaidi.
Baada ya kusoma data, unaweza kuona kwamba kulingana na maadili ya objectId auditweightsLikesCount ΠΈ auditweightsShowsCount mabadiliko, ambayo ina maana kwamba uwiano wa thamani za juu zaidi za vipengele hivi utaonyesha ubadilishaji wa chapisho bora zaidi kuliko uwiano wakati wa kuonyesha.
Uvujaji wa kwanza tuliopata ni auditweightsLikesCountMax/auditweightsShowsCountMax.
Lakini vipi ikiwa tutaangalia data kwa karibu zaidi? Wacha tupange kulingana na tarehe ya onyesho na tupate:
| objectId | kitambulisho cha mtumiaji | auditweightsShowsCount | auditweightsLikesCount | lengo (limependwa) |
|---|---|---|---|---|
| 1 | 1 | 12 | 3 | pengine si |
| 1 | 2 | 15 | 3 | labda ndiyo |
| 1 | 3 | 16 | 4 |
Ilikuwa ya kushangaza nilipopata mfano wa kwanza kama huo na ikawa kwamba utabiri wangu haukutimia. Lakini, kwa kuzingatia ukweli kwamba maadili ya juu ya sifa hizi ndani ya kitu yalitoa ongezeko, hatukuwa wavivu na tuliamua kupata. auditweightsShowsCountNext ΠΈ auditweightsLikesCountNext, yaani, maadili kwa wakati unaofuata kwa wakati. Kwa kuongeza kipengele
(ukaguziUzitoMaonyeshoHesabuInayofuata-uzaniMaonyeshoYaHesabu)/(ukaguziUzitoUnapendwaHesabu-kaguziUzitoLikesCountInayofuata) tukaruka kwa kasi haraka.
Uvujaji sawa unaweza kutumika kwa kutafuta maadili yafuatayo ya userOwnerCounterCreateLikes ndani ya userId+ownerId na, kwa mfano, uzaniCtrGender ndani ya objectId+userGender. Tulipata sehemu 6 zinazofanana na uvujaji na tukatoa maelezo mengi iwezekanavyo kutoka kwao.
Kufikia wakati huo, tulikuwa tumetoa habari nyingi iwezekanavyo kutoka kwa vipengele vya ushirikiano, lakini hatukurudi kwenye mashindano ya picha na maandishi. Nilikuwa na wazo nzuri la kuangalia: ni kiasi gani vipengele vinavyotokana moja kwa moja na picha au maandishi hutoa katika mashindano husika?
Hakukuwa na uvujaji katika mashindano ya picha na maandishi, lakini wakati huo nilikuwa nimerudisha vigezo vya chaguo-msingi vya catboost, nikasafisha msimbo na kuongeza vipengele vichache. Jumla ilikuwa:
| uamuzi | hivi karibuni |
|---|---|
| Upeo na picha | 0.6411 |
| Upeo hakuna picha | 0.6297 |
| Matokeo ya nafasi ya pili | 0.6295 |
| uamuzi | hivi karibuni |
|---|---|
| Upeo na maandishi | 0.666 |
| Upeo bila maandishi | 0.660 |
| Matokeo ya nafasi ya pili | 0.656 |
| uamuzi | hivi karibuni |
|---|---|
| Upeo katika ushirikiano | 0.745 |
| Matokeo ya nafasi ya pili | 0.723 |
Ikawa dhahiri kwamba hatukuweza kufinya maandishi na picha nyingi, na baada ya kujaribu mawazo kadhaa ya kuvutia zaidi, tuliacha kufanya kazi nao.
Kizazi zaidi cha vipengele katika mifumo shirikishi haikutoa ongezeko, na tulianza kuorodhesha. Katika hatua ya mtandaoni, uainishaji na mkusanyiko wa cheo ulinipa ongezeko kidogo, kama ilivyotokea kwa sababu nilipunguza uainishaji. Hakuna hitilafu zozote, ikiwa ni pamoja na YetiRanlPairwise, iliyotoa popote karibu na matokeo ambayo LogLoss ilifanya (0,745 dhidi ya 0,725). Bado kulikuwa na matumaini ya QueryCrossEntropy, ambayo haikuweza kuzinduliwa.
Hatua ya nje ya mtandao
Katika hatua ya nje ya mtandao, muundo wa data ulibaki vile vile, lakini kulikuwa na mabadiliko madogo:
- vitambulisho vya mtumiaji, kitambulisho cha kitu, kitambulisho cha mmiliki vilifanywa upya;
- ishara kadhaa ziliondolewa na kadhaa zilibadilishwa jina;
- data imeongezeka takriban mara 1,5.
Mbali na shida zilizoorodheshwa, kulikuwa na nyongeza moja kubwa: timu ilipewa seva kubwa na RTX 2080TI. Nimefurahia htop kwa muda mrefu.
Kulikuwa na wazo moja tu - kuzaliana tu kile ambacho tayari kipo. Baada ya kutumia saa kadhaa kuweka mazingira kwenye seva, tulianza hatua kwa hatua kuthibitisha kwamba matokeo yalikuwa yanazalishwa tena. Tatizo kuu tunalokabiliana nalo ni ongezeko la kiasi cha data. Tuliamua kupunguza mzigo kidogo na kuweka parameta ya catboost ctr_complexity=1. Hii inapunguza kasi kidogo, lakini mfano wangu ulianza kufanya kazi, matokeo yalikuwa mazuri - 0,733. Sergey, tofauti na mimi, hakugawanya data katika sehemu 2 na alifunzwa kwenye data yote, ingawa hii ilitoa matokeo bora katika hatua ya mkondoni, katika hatua ya nje ya mkondo kulikuwa na shida nyingi. Ikiwa tutachukua vipengele vyote tulivyotengeneza na kujaribu kuvisukuma kwenye kiboreshaji, basi hakuna kitu kingefanya kazi kwenye hatua ya mtandaoni. Sergey alifanya uboreshaji wa aina, kwa mfano, kubadilisha aina za float64 kuwa float32. Unaweza kupata habari juu ya uboreshaji wa kumbukumbu kwenye pandas. Kama matokeo, Sergey alipata mafunzo kwenye CPU kwa kutumia data zote na alipata takriban 0,735.
Matokeo haya yalitosha kushinda, lakini tulificha kasi yetu ya kweli na hatukuweza kuwa na uhakika kwamba timu zingine hazifanyi hivyo.
Pambana hadi mwisho
Urekebishaji wa kiboreshaji
Suluhisho letu lilitolewa kikamilifu, tuliongeza vipengele vya data ya maandishi na picha, kwa hivyo kilichobaki ni kurekebisha vigezo vya catboost. Sergey alipata mafunzo kwenye CPU na idadi ndogo ya marudio, na nilifanya mazoezi kwenye ile iliyo na ctr_complexity=1. Kulikuwa na siku moja iliyosalia, na ikiwa umeongeza tu marudio au kuongeza ctr_complexity, basi kufikia asubuhi unaweza kupata kasi nzuri zaidi na kutembea siku nzima.
Katika hatua ya nje ya mtandao, kasi inaweza kufichwa kwa urahisi sana kwa kuchagua tu si suluhisho bora kwenye tovuti. Tulitarajia mabadiliko makubwa katika ubao wa wanaoongoza katika dakika za mwisho kabla ya mawasilisho kufungwa na tukaamua kutokoma.
Kutoka kwa video ya Anna, nilijifunza kwamba ili kuboresha ubora wa mfano, ni bora kuchagua vigezo vifuatavyo:
- kiwango_cha_kujifunza - Thamani chaguo-msingi huhesabiwa kulingana na saizi ya mkusanyiko wa data. Kuongeza kiwango cha_kujifunza kunahitaji kuongeza idadi ya marudio.
- l2_reg_ya_jani - Mgawo wa kurekebisha, thamani chaguo-msingi 3, ikiwezekana kuchagua kutoka 2 hadi 30. Kupungua kwa thamani husababisha kuongezeka kwa overfit.
- bagging_joto - inaongeza ujanibishaji kwa uzani wa vitu kwenye sampuli. Thamani chaguo-msingi ni 1, ambapo uzani hutolewa kutoka kwa usambazaji wa kielelezo. Kupungua kwa thamani husababisha kuongezeka kwa overfit.
- bila mpangilio_nguvu - Huathiri uchaguzi wa mgawanyiko kwa marudio maalum. Kadiri nguvu_za nasibu zilivyo juu, ndivyo uwezekano wa mgawanyiko wa umuhimu wa chini utachaguliwa unavyoongezeka. Katika kila marudio yanayofuata, nasibu hupungua. Kupungua kwa thamani husababisha kuongezeka kwa overfit.
Vigezo vingine vina athari ndogo zaidi kwenye matokeo ya mwisho, kwa hivyo sikujaribu kuwachagua. Marudio moja ya mafunzo kwenye hifadhidata yangu ya GPU na ctr_complexity=1 ilichukua dakika 20, na vigezo vilivyochaguliwa kwenye hifadhidata iliyopunguzwa vilikuwa tofauti kidogo na zile bora kwenye hifadhidata kamili. Mwishowe, nilifanya marudio 30 kwenye 10% ya data, na kisha marudio 10 zaidi kwenye data yote. Iliibuka kitu kama hiki:
- kiwango_cha_kujifunza Niliongezeka kwa 40% kutoka kwa chaguo-msingi;
- l2_reg_ya_jani aliiacha sawa;
- bagging_joto ΠΈ bila mpangilio_nguvu imepungua hadi 0,8.
Tunaweza kuhitimisha kuwa mfano huo haukufundishwa na vigezo vya msingi.
Nilishangaa sana nilipoona matokeo kwenye ubao wa wanaoongoza:
| mfano | mfano 1 | mfano 2 | mfano 3 | kukusanyika |
|---|---|---|---|---|
| Bila tuning | 0.7403 | 0.7404 | 0.7404 | 0.7407 |
| Pamoja na kurekebisha | 0.7406 | 0.7405 | 0.7406 | 0.7408 |
Nilihitimisha mwenyewe kwamba ikiwa utumiaji wa haraka wa mfano hauhitajiki, basi ni bora kuchukua nafasi ya uteuzi wa vigezo na mkusanyiko wa mifano kadhaa kwa kutumia vigezo visivyoboreshwa.
Sergey alikuwa akiboresha saizi ya hifadhidata ili kuiendesha kwenye GPU. Chaguo rahisi ni kukata sehemu ya data, lakini hii inaweza kufanywa kwa njia kadhaa:
- ondoa hatua kwa hatua data ya zamani zaidi (mwanzo wa Februari) hadi hifadhidata ianze kutoshea kwenye kumbukumbu;
- ondoa vipengele vilivyo na umuhimu wa chini;
- ondoa vitambulisho vya mtumiaji ambavyo kuna ingizo moja tu;
- acha tu vitambulisho vya mtumiaji vilivyo kwenye jaribio.
Na mwishowe, fanya mkusanyiko kutoka kwa chaguzi zote.
Ensemble ya mwisho
Kufikia jioni ya siku ya mwisho, tulikuwa tumeweka mkusanyiko wa miundo yetu ambayo ilitoa 0,742. Mara moja nilizindua mfano wangu na ctr_complexity=2 na badala ya dakika 30 ilifanya mazoezi kwa masaa 5. Saa 4 tu ilihesabiwa, na nilifanya mkusanyiko wa mwisho, ambao ulitoa 0,7433 kwenye ubao wa wanaoongoza wa umma.
Kwa sababu ya njia tofauti za kutatua shida, utabiri wetu haukuwa na uhusiano mkubwa, ambao ulitoa ongezeko nzuri la mkusanyiko. Ili kupata mkusanyiko mzuri, ni bora kutumia utabiri mbichi wa modeli (prediction_type='RawFormulaVal') na kuweka scale_pos_weight=neg_count/pos_count.
Kwenye tovuti unaweza kuona .
Suluhu zingine
Timu nyingi zilifuata kanuni za kanuni za mfumo wa wapendekezaji. Mimi, si mtaalam katika uwanja huu, siwezi kuwatathmini, lakini nakumbuka suluhisho 2 za kupendeza.
- . Nikolay, akiwa mfanyakazi wa Mail.ru, hakuomba tuzo, kwa hivyo lengo lake halikuwa kufikia kasi ya juu, lakini kupata suluhisho la urahisi.
- Uamuzi wa timu ya kushinda Tuzo ya Jury kulingana na , kuruhusiwa kwa nguzo nzuri sana za picha bila kazi ya mwongozo.
Hitimisho
Ni nini kilikaa kwenye kumbukumbu yangu zaidi:
- Ikiwa kuna vipengele vya kitengo katika data, na unajua jinsi ya kufanya usimbaji wa lengo kwa usahihi, bado ni bora kujaribu catboost.
- Ikiwa unashiriki katika shindano, hupaswi kupoteza muda kuchagua vigezo vingine zaidi ya kiwango_kujifunza na marudio. Suluhisho la haraka ni kufanya mkusanyiko wa mifano kadhaa.
- Viongezeo vinaweza kujifunza kwenye GPU. Catboost inaweza kujifunza kwa haraka sana kwenye GPU, lakini inakula kumbukumbu nyingi.
- Wakati wa ukuzaji na majaribio ya maoni, ni bora kuweka rsm~=0.2 ndogo (CPU pekee) na ctr_complexity=1.
- Tofauti na timu zingine, mkusanyiko wa mifano yetu ulitoa ongezeko kubwa. Tulibadilishana mawazo tu na kuandika kwa lugha tofauti. Tulikuwa na mbinu tofauti ya kugawanya data na, nadhani, kila moja ilikuwa na mende zake.
- Haijulikani kwa nini uboreshaji wa nafasi ulifanya vibaya zaidi kuliko uboreshaji wa uainishaji.
- Nilipata uzoefu wa kufanya kazi na maandishi na uelewa wa jinsi mifumo ya wapendekezaji hufanywa.
Asante kwa waandaaji kwa hisia, maarifa na zawadi walizopokea.
Chanzo: mapenzi.com