ફેબ્રુઆરી-માર્ચ 2019 માં, સોશિયલ નેટવર્ક ફીડને રેન્ક આપવા માટે એક સ્પર્ધા યોજાઈ હતી SNA હેકાથોન 2019, જેમાં અમારી ટીમે પ્રથમ સ્થાન મેળવ્યું હતું. લેખમાં હું સ્પર્ધાના સંગઠન વિશે વાત કરીશ, અમે જે પદ્ધતિઓ અજમાવી છે અને મોટા ડેટા પર તાલીમ માટે કેટબૂસ્ટ સેટિંગ્સ વિશે વાત કરીશ.

SNA હેકાથોન

આ ત્રીજી વખત છે જ્યારે આ નામ હેઠળ હેકાથોનનું આયોજન કરવામાં આવ્યું છે. તે સામાજિક નેટવર્ક ok.ru દ્વારા ગોઠવવામાં આવે છે, અનુક્રમે, કાર્ય અને ડેટા સીધા આ સામાજિક નેટવર્કથી સંબંધિત છે.
આ કિસ્સામાં SNA (સામાજિક નેટવર્ક વિશ્લેષણ) એ સામાજિક ગ્રાફના વિશ્લેષણ તરીકે નહીં, પરંતુ સામાજિક નેટવર્કના વિશ્લેષણ તરીકે વધુ યોગ્ય રીતે સમજવામાં આવે છે.

• 2014માં, કાર્ય પોસ્ટને કેટલી લાઈક્સ મળશે તેની આગાહી કરવાનું હતું.
• 2016 માં - VVZ કાર્ય (કદાચ તમે પરિચિત છો), સામાજિક ગ્રાફના વિશ્લેષણની નજીક.
• 2019 માં, વપરાશકર્તાને પોસ્ટ પસંદ આવશે તેવી સંભાવનાના આધારે વપરાશકર્તાના ફીડને રેન્કિંગ કરો.

હું 2014 વિશે કહી શકતો નથી, પરંતુ 2016 અને 2019 માં, ડેટા વિશ્લેષણ ક્ષમતાઓ ઉપરાંત, મોટા ડેટા સાથે કામ કરવાની કુશળતા પણ જરૂરી હતી. મને લાગે છે કે તે મશીન લર્નિંગ અને મોટી ડેટા પ્રોસેસિંગ સમસ્યાઓનું સંયોજન હતું જેણે મને આ સ્પર્ધાઓ તરફ આકર્ષિત કર્યું, અને આ ક્ષેત્રોમાં મારા અનુભવે મને જીતવામાં મદદ કરી.

mlbootcamp

2019 માં, સ્પર્ધાનું આયોજન પ્લેટફોર્મ પર કરવામાં આવ્યું હતું https://mlbootcamp.ru.

આ સ્પર્ધા 7 ફેબ્રુઆરીના રોજ ઓનલાઈન શરૂ થઈ હતી અને તેમાં 3 કાર્યો હતા. કોઈપણ સાઇટ પર નોંધણી કરાવી શકે છે, ડાઉનલોડ કરી શકે છે આધારરેખા અને તમારી કારને થોડા કલાકો માટે લોડ કરો. 15 માર્ચના રોજ ઓનલાઈન સ્ટેજના અંતે, દરેક શો જમ્પિંગ ઈવેન્ટના ટોપ 15ને ઓફલાઈન સ્ટેજ માટે Mail.ru ઓફિસમાં આમંત્રિત કરવામાં આવ્યા હતા, જે 30 માર્ચથી 1 એપ્રિલ દરમિયાન યોજાઈ હતી.

ઉદ્દેશ

સ્ત્રોત ડેટા વપરાશકર્તા ID (userId) અને પોસ્ટ ID (objectId) પ્રદાન કરે છે. જો વપરાશકર્તાને કોઈ પોસ્ટ બતાવવામાં આવી હોય, તો ડેટામાં userId, objectId, આ પોસ્ટ પરની વપરાશકર્તાની પ્રતિક્રિયાઓ (પ્રતિસાદ) અને ચિત્રો અને ટેક્સ્ટ્સની વિવિધ સુવિધાઓ અથવા લિંક્સનો સમૂહ શામેલ હોય છે.

વપરાશકર્તા આઈડી	objectId	માલિક આઈડી	પ્રતિસાદ	છબીઓ
3555	22	5677	[ગમ્યું, ક્લિક કર્યું]	[હેશ1]
12842	55	32144	[નાપસંદ]	[hash2,hash3]
13145	35	5677	[ક્લિક કર્યું, શેર કર્યું]	[હેશ2]

ટેસ્ટ ડેટા સેટમાં સમાન માળખું છે, પરંતુ પ્રતિસાદ ફીલ્ડ ખૂટે છે. કાર્ય પ્રતિસાદ ક્ષેત્રમાં 'ગમ્યું' પ્રતિક્રિયાની હાજરીની આગાહી કરવાનું છે.
સબમિશન ફાઇલમાં નીચેનું માળખું છે:

વપરાશકર્તા આઈડી	સૉર્ટ કરેલ સૂચિ[ઑબ્જેક્ટ આઈડી]
123	78,13,54,22
128	35,61,55
131	35,68,129,11

મેટ્રિક એ વપરાશકર્તાઓ માટે સરેરાશ ROC AUC છે.

ડેટાનું વધુ વિગતવાર વર્ણન અહીં મળી શકે છે કાઉન્સિલ વેબસાઇટ. તમે પરીક્ષણો અને ચિત્રો સહિતનો ડેટા પણ ત્યાં ડાઉનલોડ કરી શકો છો.

ઑનલાઇન સ્ટેજ

ઑનલાઇન તબક્કે, કાર્યને 3 ભાગોમાં વહેંચવામાં આવ્યું હતું

• સહયોગી સિસ્ટમ - છબીઓ અને લખાણો સિવાય તમામ સુવિધાઓનો સમાવેશ કરે છે;
• છબીઓ - ફક્ત છબીઓ વિશેની માહિતી શામેલ છે;
• ટેક્સ્ટ્સ - ફક્ત પાઠો વિશેની માહિતી શામેલ છે.

ઑફલાઇન સ્ટેજ

ઑફલાઇન તબક્કે, ડેટામાં તમામ સુવિધાઓનો સમાવેશ થતો હતો, જ્યારે ટેક્સ્ટ અને છબીઓ છૂટાછવાયા હતા. ડેટાસેટમાં 1,5 ગણી વધુ પંક્તિઓ હતી, જેમાંથી પહેલાથી ઘણી બધી હતી.

સમસ્યાનો ઉકેલ

હું કામ પર સીવી કરું છું, તેથી મેં આ સ્પર્ધામાં મારી સફર "ઇમેજ" કાર્ય સાથે શરૂ કરી. જે ડેટા આપવામાં આવ્યો હતો તે યુઝરઆઈડી, ઑબ્જેક્ટઆઈડી, માલિક આઈડી (જે જૂથમાં પોસ્ટ પ્રકાશિત કરવામાં આવી હતી), પોસ્ટ બનાવવા અને પ્રદર્શિત કરવા માટેના ટાઇમસ્ટેમ્પ્સ અને અલબત્ત, આ પોસ્ટ માટેની છબી હતી.
ટાઈમસ્ટેમ્પ પર આધારિત ઘણી સુવિધાઓ જનરેટ કર્યા પછી, આગળનો વિચાર ઈમેનેટ પર પૂર્વ-પ્રશિક્ષિત ન્યુરોનના અંતિમ સ્તરને લેવાનો હતો અને આ એમ્બેડિંગ્સને બૂસ્ટિંગ માટે મોકલવાનો હતો.

પરિણામો પ્રભાવશાળી ન હતા. ઇમેજનેટ ચેતાકોષમાંથી એમ્બેડિંગ્સ અપ્રસ્તુત છે, મેં વિચાર્યું, મારે મારું પોતાનું ઓટોએનકોડર બનાવવાની જરૂર છે.

તેમાં ઘણો સમય લાગ્યો અને પરિણામ સુધર્યું નહીં.

ફીચર જનરેશન

છબીઓ સાથે કામ કરવામાં ઘણો સમય લાગે છે, તેથી મેં કંઈક સરળ કરવાનું નક્કી કર્યું.
જેમ તમે તરત જ જોઈ શકો છો, ડેટાસેટમાં ઘણી સ્પષ્ટ સુવિધાઓ છે, અને વધુ પડતી પરેશાન ન કરવા માટે, મેં હમણાં જ કેટબૂસ્ટ લીધું છે. ઉકેલ ઉત્તમ હતો, કોઈપણ સેટિંગ્સ વિના હું તરત જ લીડરબોર્ડની પ્રથમ લાઇન પર પહોંચ્યો.

ત્યાં ઘણો ડેટા છે અને તે લાકડાના ફોર્મેટમાં મૂક્યો છે, તેથી બે વાર વિચાર કર્યા વિના, મેં સ્કાલા લીધું અને સ્પાર્કમાં બધું લખવાનું શરૂ કર્યું.

સૌથી સરળ સુવિધાઓ કે જેણે ઇમેજ એમ્બેડિંગ્સ કરતાં વધુ વૃદ્ધિ આપી છે:

• ડેટામાં ઑબ્જેક્ટઆઈડી, યુઝરઆઈડી અને ઓનરઆઈડી કેટલી વાર દેખાયા (લોકપ્રિયતા સાથે સંબંધ હોવો જોઈએ);
• યુઝરઆઈડીએ માલિક આઈડીમાંથી કેટલી પોસ્ટ જોઈ છે (જૂથમાં વપરાશકર્તાની રુચિ સાથે સંબંધ હોવો જોઈએ);
• માલિકની આઈડીમાંથી કેટલા અનન્ય યુઝરઆઈડીએ પોસ્ટ્સ જોયા (જૂથના પ્રેક્ષકોના કદને પ્રતિબિંબિત કરે છે).

ટાઈમસ્ટેમ્પ પરથી તે દિવસનો સમય મેળવવાનું શક્ય હતું કે જેમાં વપરાશકર્તાએ ફીડ જોયો (સવાર/બપોર/સાંજ/રાત્રિ). આ શ્રેણીઓને જોડીને, તમે વિશેષતાઓ જનરેટ કરવાનું ચાલુ રાખી શકો છો:

• યુઝરઆઈડી સાંજે કેટલી વાર લોગ ઈન થયું;
• કયા સમયે આ પોસ્ટ મોટાભાગે બતાવવામાં આવે છે (objectId) વગેરે.

આ બધાએ ધીમે ધીમે મેટ્રિક્સમાં સુધારો કર્યો. પરંતુ તાલીમ ડેટાસેટનું કદ લગભગ 20M રેકોર્ડ્સ છે, તેથી વિશેષતાઓ ઉમેરવાથી તાલીમ ખૂબ જ ધીમી પડી.

મેં ડેટાનો ઉપયોગ કરવાના મારા અભિગમ પર પુનર્વિચાર કર્યો છે. ડેટા સમય-આધારિત હોવા છતાં, મને "ભવિષ્યમાં" કોઈ સ્પષ્ટ માહિતી લીક જોવા મળી નથી, તેમ છતાં, માત્ર કિસ્સામાં, મેં તેને આ રીતે તોડી નાખ્યું:

અમને આપવામાં આવેલ તાલીમ સમૂહ (ફેબ્રુઆરી અને માર્ચના 2 અઠવાડિયા) 2 ભાગોમાં વિભાજિત કરવામાં આવ્યો હતો.
મોડલને છેલ્લા એન દિવસોના ડેટા પર તાલીમ આપવામાં આવી હતી. ઉપર વર્ણવેલ એકત્રીકરણ પરીક્ષણ સહિત તમામ ડેટા પર બનાવવામાં આવ્યું હતું. તે જ સમયે, ડેટા દેખાયો કે જેના પર લક્ષ્ય વેરીએબલના વિવિધ એન્કોડિંગ્સ બનાવવાનું શક્ય છે. સૌથી સરળ અભિગમ એ કોડનો પુનઃઉપયોગ કરવાનો છે જે પહેલેથી જ નવી સુવિધાઓ બનાવી રહ્યું છે, અને તેને ફક્ત તે ડેટા ફીડ કરો કે જેના પર તેને તાલીમ આપવામાં આવશે નહીં અને લક્ષ્ય = 1.

આમ, અમને સમાન સુવિધાઓ મળી છે:

• યુઝરઆઈડીએ ગ્રુપ માલિક આઈડીમાં કેટલી વાર પોસ્ટ જોઈ છે;
• ગ્રૂપ ઓનર આઈડીમાં યુઝરઆઈડીએ કેટલી વાર પોસ્ટ લાઈક કરી;
• માલિકની આઈડીમાંથી વપરાશકર્તાઆઈડીને ગમતી પોસ્ટ્સની ટકાવારી.

એટલે કે, તે બહાર આવ્યું સરેરાશ લક્ષ્ય એન્કોડિંગ વિશિષ્ટ લક્ષણોના વિવિધ સંયોજનો માટે ડેટાસેટના ભાગ પર. સૈદ્ધાંતિક રીતે, કેટબૂસ્ટ લક્ષ્ય એન્કોડિંગ પણ બનાવે છે અને આ દૃષ્ટિકોણથી કોઈ ફાયદો નથી, પરંતુ, ઉદાહરણ તરીકે, આ જૂથમાં પોસ્ટ્સને પસંદ કરનારા અનન્ય વપરાશકર્તાઓની સંખ્યાને ગણવાનું શક્ય બન્યું. તે જ સમયે, મુખ્ય ધ્યેય હાંસલ કરવામાં આવ્યો હતો - મારા ડેટાસેટને ઘણી વખત ઘટાડવામાં આવ્યો હતો, અને સુવિધાઓ જનરેટ કરવાનું ચાલુ રાખવું શક્ય હતું.

જ્યારે catboost માત્ર પસંદ કરેલી પ્રતિક્રિયાના આધારે એન્કોડિંગ બનાવી શકે છે, ત્યારે પ્રતિસાદમાં અન્ય પ્રતિક્રિયાઓ હોય છે: ફરીથી શેર કરેલ, નાપસંદ, નાપસંદ, ક્લિક કરેલ, અવગણવામાં આવેલ, એન્કોડિંગ્સ જેના માટે મેન્યુઅલી કરી શકાય છે. મેં તમામ પ્રકારના એકત્રીકરણની પુનઃગણતરી કરી અને ઓછા મહત્વ સાથેના લક્ષણોને દૂર કર્યા જેથી ડેટાસેટમાં વધારો ન થાય.

તે સમયે હું વિશાળ માર્જિનથી પ્રથમ સ્થાને હતો. ગૂંચવણમાં મૂકેલી એકમાત્ર વસ્તુ એ હતી કે ઇમેજ એમ્બેડિંગ્સ લગભગ કોઈ વૃદ્ધિ દર્શાવતું નથી. કેટબૂસ્ટને બધું આપવાનો વિચાર આવ્યો. અમે Kmeans ઈમેજીસને ક્લસ્ટર કરીએ છીએ અને નવી સ્પષ્ટ સુવિધા ઈમેજકેટ મેળવીએ છીએ.

KMeans માંથી મેળવેલા ક્લસ્ટરોને મેન્યુઅલ ફિલ્ટરિંગ અને મર્જ કર્યા પછી અહીં કેટલાક વર્ગો છે.

imageCat ના આધારે અમે જનરેટ કરીએ છીએ:

• નવી વર્ગીકૃત સુવિધાઓ:
  • યુઝરઆઈડી દ્વારા કઈ ઈમેજકેટને મોટાભાગે જોવામાં આવી હતી;
  • કઈ ઈમેજકેટ મોટાભાગે માલિક આઈડી બતાવે છે;
  • યુઝરઆઈડી દ્વારા કઈ ઈમેજકેટને સૌથી વધુ પસંદ કરવામાં આવી હતી;
• વિવિધ કાઉન્ટર્સ:
  • યુઝરઆઈડી પર કેટલી અનન્ય ઈમેજકેટ જોઈ;
  • ઉપર વર્ણવ્યા મુજબ લગભગ 15 સમાન સુવિધાઓ વત્તા લક્ષ્ય એન્કોડિંગ.

ટેક્સ્ટ્સ

ઈમેજ કોમ્પિટિશનના પરિણામો મને અનુકૂળ આવ્યા અને મેં પાઠો પર હાથ અજમાવવાનું નક્કી કર્યું. મેં પહેલાં ટેક્સ્ટ્સ સાથે વધુ કામ કર્યું નથી અને, મૂર્ખતાપૂર્વક, મેં tf-idf અને svd પર દિવસને મારી નાખ્યો. પછી મેં doc2vec સાથે બેઝલાઇન જોયું, જે મને જે જોઈએ છે તે બરાબર કરે છે. doc2vec પરિમાણોને સહેજ સમાયોજિત કર્યા પછી, મને ટેક્સ્ટ એમ્બેડિંગ્સ મળી.

અને પછી મેં ઈમેજીસ માટે કોડનો ફરીથી ઉપયોગ કર્યો, જેમાં મેં ઈમેજ એમ્બેડીંગને ટેક્સ્ટ એમ્બેડીંગ્સ સાથે બદલ્યું. પરિણામે, મેં ટેક્સ્ટ સ્પર્ધામાં 2જું સ્થાન મેળવ્યું.

સહયોગી સિસ્ટમ

ત્યાં એક સ્પર્ધા બાકી હતી જેને મેં હજુ સુધી લાકડી વડે "પોક" કર્યું ન હતું, અને લીડરબોર્ડ પર AUC દ્વારા નક્કી કરવામાં આવે તો, આ ચોક્કસ સ્પર્ધાના પરિણામોની ઑફલાઇન સ્ટેજ પર સૌથી વધુ અસર થવી જોઈએ.
મેં સ્રોત ડેટામાંની બધી સુવિધાઓ લીધી, સ્પષ્ટપણે પસંદ કરી અને છબીઓ પર આધારિત સુવિધાઓ સિવાય, છબીઓ માટે સમાન એકંદરની ગણતરી કરી. ફક્ત આને કેટબૂસ્ટમાં મૂકવાથી હું બીજા સ્થાને આવી ગયો.

કૅટબૂસ્ટ ઑપ્ટિમાઇઝેશનના પ્રથમ પગલાં

એક પ્રથમ અને બે બીજા સ્થાને મને આનંદ થયો, પરંતુ એક સમજણ હતી કે મેં કંઈ ખાસ કર્યું નથી, જેનો અર્થ છે કે હું હોદ્દા ગુમાવવાની અપેક્ષા રાખી શકું છું.

સ્પર્ધાનું કાર્ય વપરાશકર્તાની અંદરની પોસ્ટ્સને ક્રમ આપવાનું છે, અને આ બધા સમયે હું વર્ગીકરણની સમસ્યાને હલ કરી રહ્યો હતો, એટલે કે, ખોટા મેટ્રિકને ઑપ્ટિમાઇઝ કરી રહ્યો હતો.

ચાલો હું તમને એક સરળ ઉદાહરણ આપું:

વપરાશકર્તા આઈડી	objectId	આગાહી	જમીની સત્ય
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

ચાલો એક નાનું પુનર્ગઠન કરીએ

વપરાશકર્તા આઈડી	objectId	આગાહી	જમીની સત્ય
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

અમને નીચેના પરિણામો મળે છે:

આ મોડેલ	એયુસી	વપરાશકર્તા1 એયુસી	વપરાશકર્તા2 એયુસી	અર્થ એયુસી
વિકલ્પ 1	0,8	1,0	0,0	0,5
વિકલ્પ 2	0,7	0,75	1,0	0,875

જેમ તમે જોઈ શકો છો, એકંદર AUC મેટ્રિકમાં સુધારો કરવાનો અર્થ એ નથી કે વપરાશકર્તાની અંદર સરેરાશ AUC મેટ્રિકમાં સુધારો કરવો.

કેટબૂસ્ટ રેન્કિંગ મેટ્રિક્સને કેવી રીતે ઑપ્ટિમાઇઝ કરવું તે જાણે છે બોક્સમાંથી. મેં રેન્કિંગ મેટ્રિક્સ વિશે વાંચ્યું, સફળતાની વાર્તાઓ કેટબૂસ્ટનો ઉપયોગ કરતી વખતે અને રાતોરાત તાલીમ આપવા માટે YetiRankPairwise સેટ કરો. પરિણામ પ્રભાવશાળી ન હતું. હું અંડરટ્રેઇન થયેલો હતો તે નક્કી કરીને, મેં એરર ફંક્શનને ક્વેરીઆરએમએસઇમાં બદલ્યું, જે કેટબૂસ્ટ દસ્તાવેજીકરણ દ્વારા નક્કી કરીને, ઝડપથી કન્વર્જ થાય છે. અંતે, વર્ગીકરણ માટેની તાલીમ વખતે મને સમાન પરિણામો મળ્યા, પરંતુ આ બે મોડેલોના જોડાણોએ સારો વધારો કર્યો, જે મને ત્રણેય સ્પર્ધાઓમાં પ્રથમ સ્થાને લાવ્યો.

"કોલાબોરેટિવ સિસ્ટમ્સ" સ્પર્ધાના ઓનલાઈન સ્ટેજની સમાપ્તિની 5 મિનિટ પહેલાં, સેર્ગેઈ શાલનોવ મને બીજા સ્થાને ખસેડ્યો. અમે સાથે મળીને આગળનો રસ્તો ચાલ્યો.

ઑફલાઇન તબક્કા માટે તૈયારી કરી રહ્યાં છીએ

અમને RTX 2080 TI વિડિયો કાર્ડ વડે ઑનલાઇન તબક્કામાં વિજયની ખાતરી આપવામાં આવી હતી, પરંતુ 300 રુબેલ્સનું મુખ્ય ઇનામ અને સંભવતઃ, અંતિમ પ્રથમ સ્થાને પણ અમને આ 000 અઠવાડિયા સુધી કામ કરવાની ફરજ પડી હતી.

જેમ જેમ તે બહાર આવ્યું તેમ, સેર્ગેએ પણ કેટબૂસ્ટનો ઉપયોગ કર્યો. અમે વિચારો અને સુવિધાઓની આપ-લે કરી, અને હું તેના વિશે શીખ્યો અન્ના વેરોનિકા ડોરોગુશ દ્વારા અહેવાલ જેમાં મારા ઘણા પ્રશ્નોના જવાબો હતા અને તે પણ જે તે સમય સુધીમાં મારી પાસે નહોતા.

રિપોર્ટ જોઈને મને એ વિચાર તરફ દોરી ગયો કે આપણે બધા પરિમાણોને ડિફોલ્ટ મૂલ્યમાં પરત કરવાની જરૂર છે, અને સેટિંગ્સને ખૂબ જ કાળજીપૂર્વક અને સુવિધાઓના સમૂહને ઠીક કર્યા પછી જ કરો. હવે એક તાલીમમાં લગભગ 15 કલાકનો સમય લાગ્યો, પરંતુ એક મોડેલ રેન્કિંગ સાથેના જોડાણમાં મેળવેલા કરતા વધુ સારી ઝડપ મેળવવામાં સફળ થયું.

ફીચર જનરેશન

કોલાબોરેટિવ સિસ્ટમ્સ સ્પર્ધામાં, મોડેલ માટે મહત્વપૂર્ણ તરીકે મોટી સંખ્યામાં સુવિધાઓનું મૂલ્યાંકન કરવામાં આવે છે. દાખ્લા તરીકે, auditweights_spark_svd - સૌથી મહત્વપૂર્ણ સંકેત, પરંતુ તેનો અર્થ શું છે તે વિશે કોઈ માહિતી નથી. મેં વિચાર્યું કે મહત્વપૂર્ણ લક્ષણોના આધારે વિવિધ એકત્રીકરણની ગણતરી કરવી યોગ્ય રહેશે. ઉદાહરણ તરીકે, વપરાશકર્તા દ્વારા, જૂથ દ્વારા, ઑબ્જેક્ટ દ્વારા સરેરાશ auditweights_spark_svd. તે જ ડેટાનો ઉપયોગ કરીને ગણતરી કરી શકાય છે જેના પર કોઈ તાલીમ આપવામાં આવતી નથી અને લક્ષ્ય = 1, એટલે કે સરેરાશ auditweights_spark_svd વપરાશકર્તા દ્વારા તેને ગમતી વસ્તુઓ દ્વારા. ઉપરાંત મહત્વપૂર્ણ સંકેતો auditweights_spark_svd, ત્યાં ઘણા હતા. અહીં તેમાંથી કેટલાક છે:

• auditweightsCtrGender
• ઓડિટવેઇટCtrHigh
• userOwnerCounterCreateLikes

ઉદાહરણ તરીકે, સરેરાશ auditweightsCtrGender userId અનુસાર તે સરેરાશ મૂલ્યની જેમ જ એક મહત્વપૂર્ણ લક્ષણ હોવાનું બહાર આવ્યું છે userOwnerCounterCreateLikes userId+ownerId દ્વારા. આનાથી તમને પહેલેથી જ લાગે છે કે તમારે ક્ષેત્રોનો અર્થ સમજવાની જરૂર છે.

મહત્વના લક્ષણો પણ હતા ઓડિટવેઈટલાઈક્સકાઉન્ટ и ઓડિટવેઇટસશૉસકાઉન્ટ. એકને બીજા દ્વારા વિભાજીત કરીને, એક વધુ મહત્વપૂર્ણ લક્ષણ પ્રાપ્ત થયું.

ડેટા લીક

સ્પર્ધા અને ઉત્પાદન મોડેલિંગ ખૂબ જ અલગ કાર્યો છે. ડેટા તૈયાર કરતી વખતે, બધી વિગતો ધ્યાનમાં લેવી અને પરીક્ષણમાં લક્ષ્ય ચલ વિશે કેટલીક બિન-તુચ્છ માહિતી આપવી ખૂબ જ મુશ્કેલ છે. જો અમે પ્રોડક્શન સોલ્યુશન બનાવી રહ્યા છીએ, તો અમે મોડલને તાલીમ આપતી વખતે ડેટા લીકનો ઉપયોગ ટાળવાનો પ્રયાસ કરીશું. પરંતુ જો આપણે સ્પર્ધા જીતવા માંગીએ છીએ, તો ડેટા લીક એ શ્રેષ્ઠ સુવિધાઓ છે.

ડેટાનો અભ્યાસ કર્યા પછી, તમે જોઈ શકો છો કે ઑબ્જેક્ટઆઈડી મૂલ્યો અનુસાર ઓડિટવેઈટલાઈક્સકાઉન્ટ и ઓડિટવેઇટસશૉસકાઉન્ટ ફેરફાર, જેનો અર્થ છે કે આ વિશેષતાઓના મહત્તમ મૂલ્યોનો ગુણોત્તર પ્રદર્શન સમયે ગુણોત્તર કરતાં પોસ્ટ કન્વર્ઝનને વધુ સારી રીતે પ્રતિબિંબિત કરશે.

પ્રથમ લીક અમને મળી છે auditweightsLikesCountMax/auditweightsShowsCountMax.
પરંતુ જો આપણે ડેટાને વધુ નજીકથી જોઈએ તો શું? ચાલો શો તારીખ દ્વારા સૉર્ટ કરીએ અને મેળવો:

objectId	વપરાશકર્તા આઈડી	ઓડિટવેઇટસશૉસકાઉન્ટ	ઓડિટવેઈટલાઈક્સકાઉન્ટ	લક્ષ્ય (ગમ્યું છે)
1	1	12	3	કદાચ ના
1	2	15	3	કદાચ હા
1	3	16	4

મને આશ્ચર્ય થયું જ્યારે મને આ પ્રકારનું પહેલું ઉદાહરણ મળ્યું અને તે બહાર આવ્યું કે મારી આગાહી સાચી પડી નથી. પરંતુ, ઑબ્જેક્ટની અંદર આ લાક્ષણિકતાઓના મહત્તમ મૂલ્યોમાં વધારો થયો છે તે હકીકતને ધ્યાનમાં લેતા, અમે આળસુ ન હતા અને શોધવાનું નક્કી કર્યું auditweightsShowsCountNext и auditweightsLikesCountNext, એટલે કે, સમયની આગલી ક્ષણે મૂલ્યો. એક લક્ષણ ઉમેરીને
(ઓડિટવેઈટસશોકાઉન્ટનેક્સ્ટ-ઓડિટવેઈટશોકાઉન્ટ)/(ઓડિટવેઈટલાઈક્સકાઉન્ટ-ઓડિટવેઈટલાઈક્સકાઉન્ટ નેક્સ્ટ) અમે ઝડપથી એક તીવ્ર કૂદકો લગાવ્યો.
માટે નીચેના મૂલ્યો શોધીને સમાન લિકનો ઉપયોગ કરી શકાય છે userOwnerCounterCreateLikes userId+ownerId ની અંદર અને, ઉદાહરણ તરીકે, auditweightsCtrGender objectId+userGender ની અંદર. અમને લિક સાથે 6 સમાન ક્ષેત્રો મળ્યા અને તેમાંથી શક્ય તેટલી વધુ માહિતી મેળવી.

તે સમય સુધીમાં, અમે સહયોગી સુવિધાઓમાંથી શક્ય તેટલી વધુ માહિતી મેળવી લીધી હતી, પરંતુ છબી અને ટેક્સ્ટ સ્પર્ધાઓમાં પાછા ફર્યા ન હતા. મારી પાસે તપાસ કરવા માટે એક સરસ વિચાર હતો: છબીઓ અથવા ટેક્સ્ટ પર આધારિત સુવિધાઓ સંબંધિત સ્પર્ધાઓમાં કેટલી આપે છે?

ઇમેજ અને ટેક્સ્ટ સ્પર્ધાઓમાં કોઈ લીક નહોતું, પરંતુ ત્યાં સુધીમાં મેં ડિફૉલ્ટ કૅટબૂસ્ટ પરિમાણો પરત કરી દીધા હતા, કોડ સાફ કર્યો હતો અને કેટલીક સુવિધાઓ ઉમેરી હતી. કુલ હતું:

નિર્ણય	ટૂંક સમયમાં
છબીઓ સાથે મહત્તમ	0.6411
મહત્તમ કોઈ છબીઓ નથી	0.6297
બીજા સ્થાને પરિણામ	0.6295

નિર્ણય	ટૂંક સમયમાં
પાઠો સાથે મહત્તમ	0.666
ટેક્સ્ટ વિના મહત્તમ	0.660
બીજા સ્થાને પરિણામ	0.656

નિર્ણય	ટૂંક સમયમાં
સહયોગમાં મહત્તમ	0.745
બીજા સ્થાને પરિણામ	0.723

તે સ્પષ્ટ થઈ ગયું કે અમે પાઠો અને છબીઓમાંથી ઘણું બધું સ્ક્વિઝ કરી શકીશું નહીં, અને કેટલાક સૌથી રસપ્રદ વિચારોનો પ્રયાસ કર્યા પછી, અમે તેમની સાથે કામ કરવાનું બંધ કર્યું.

સહયોગી પ્રણાલીઓમાં વિશેષતાઓની વધુ પેઢીએ વધારો આપ્યો ન હતો, અને અમે રેન્કિંગ શરૂ કર્યું. ઓનલાઈન તબક્કે, વર્ગીકરણ અને રેન્કિંગના જોડાણે મને થોડો વધારો આપ્યો, કારણ કે તે બહાર આવ્યું કારણ કે મેં વર્ગીકરણની તાલીમ લીધી હતી. LogLoss (0,745 વિ. 0,725)ના પરિણામની નજીક ક્યાંય પણ YetiRanlPairwise સહિતની ભૂલ ફંક્શન્સમાંથી કોઈ પણ ઉત્પાદન કર્યું નથી. QueryCrossEntropy માટે હજુ પણ આશા હતી, જે લોન્ચ થઈ શકી નથી.

ઑફલાઇન સ્ટેજ

ઑફલાઇન સ્ટેજ પર, ડેટા સ્ટ્રક્ચર એ જ રહ્યું, પરંતુ તેમાં નાના ફેરફારો હતા:

• આઇડેન્ટિફાયર userId, objectId, ownerId પુનઃરેન્ડમાઇઝ કરવામાં આવ્યા હતા;
• ઘણા ચિહ્નો દૂર કરવામાં આવ્યા હતા અને કેટલાકનું નામ બદલવામાં આવ્યું હતું;
• ડેટા લગભગ 1,5 ગણો વધ્યો છે.

સૂચિબદ્ધ મુશ્કેલીઓ ઉપરાંત, એક મોટો ફાયદો હતો: ટીમને RTX 2080TI સાથે એક મોટું સર્વર ફાળવવામાં આવ્યું હતું. હું લાંબા સમયથી htop માણી રહ્યો છું.

ત્યાં ફક્ત એક જ વિચાર હતો - જે પહેલાથી અસ્તિત્વમાં છે તે ફક્ત પુનઃઉત્પાદન કરવા માટે. સર્વર પર વાતાવરણ સેટ કરવામાં થોડા કલાકો ગાળ્યા પછી, અમે ધીમે ધીમે ચકાસવાનું શરૂ કર્યું કે પરિણામો પુનઃઉત્પાદન કરી શકાય તેવા હતા. અમે જે મુખ્ય સમસ્યાનો સામનો કરી રહ્યા છીએ તે ડેટા વોલ્યુમમાં વધારો છે. અમે લોડને થોડો ઘટાડવાનું નક્કી કર્યું અને catboost પેરામીટર ctr_complexity=1 સેટ કર્યું. આ ગતિ થોડી ઓછી કરે છે, પરંતુ મારા મોડેલે કામ કરવાનું શરૂ કર્યું, પરિણામ સારું હતું - 0,733. સર્ગેઈ, મારાથી વિપરીત, ડેટાને 2 ભાગોમાં વિભાજિત કર્યો ન હતો અને તમામ ડેટા પર તાલીમ આપી હતી, જો કે આનાથી ઓનલાઈન સ્ટેજ પર શ્રેષ્ઠ પરિણામો મળ્યા, ઓફલાઈન સ્ટેજ પર ઘણી મુશ્કેલીઓ હતી. જો અમે જનરેટ કરેલી તમામ સુવિધાઓ લઈએ અને તેમને કેટબૂસ્ટમાં ધકેલી દેવાનો પ્રયાસ કરીએ, તો ઑનલાઇન સ્ટેજ પર કંઈપણ કામ કરશે નહીં. સેર્ગેઇએ ટાઇપ ઓપ્ટિમાઇઝેશન કર્યું, ઉદાહરણ તરીકે, float64 પ્રકારોને float32 માં રૂપાંતરિત કરવું. આ લેખમાં તમે પાંડામાં મેમરી ઓપ્ટિમાઇઝેશન પર માહિતી મેળવી શકો છો. પરિણામે, સેર્ગેઈએ તમામ ડેટાનો ઉપયોગ કરીને CPU પર તાલીમ લીધી અને લગભગ 0,735 મેળવ્યા.

આ પરિણામો જીતવા માટે પૂરતા હતા, પરંતુ અમે અમારી સાચી ઝડપ છુપાવી હતી અને ખાતરી કરી શકી ન હતી કે અન્ય ટીમો તે જ કરી રહી નથી.

છેલ્લા સુધી લડવું

Catboost ટ્યુનિંગ

અમારું સોલ્યુશન સંપૂર્ણપણે પુનઃઉત્પાદિત કરવામાં આવ્યું હતું, અમે ટેક્સ્ટ ડેટા અને છબીઓની વિશેષતાઓ ઉમેરી હતી, તેથી જે બાકી હતું તે કેટબૂસ્ટ પરિમાણોને ટ્યુન કરવાનું હતું. સર્ગેઈએ થોડી સંખ્યામાં પુનરાવર્તનો સાથે CPU પર તાલીમ લીધી, અને મેં ctr_complexity=1 સાથે તાલીમ લીધી. એક દિવસ બાકી હતો, અને જો તમે હમણાં જ પુનરાવૃત્તિઓ ઉમેરી અથવા ctr_complexity વધારી, તો સવાર સુધીમાં તમે વધુ સારી ઝડપ મેળવી શકશો અને આખો દિવસ ચાલી શકશો.

ઑફલાઇન તબક્કે, સાઇટ પર શ્રેષ્ઠ ઉકેલ ન પસંદ કરીને ઝડપ ખૂબ જ સરળતાથી છુપાવી શકાય છે. સબમિશન બંધ થાય તે પહેલાં અમે લીડરબોર્ડમાં છેલ્લી મિનિટોમાં ભારે ફેરફારોની અપેક્ષા રાખી હતી અને બંધ ન કરવાનો નિર્ણય લીધો હતો.

અન્નાના વિડિયોમાંથી, મેં શીખ્યું કે મોડેલની ગુણવત્તા સુધારવા માટે, નીચેના પરિમાણો પસંદ કરવાનું શ્રેષ્ઠ છે:

• શીખવાની_દર — ડિફૉલ્ટ મૂલ્યની ગણતરી ડેટાસેટના કદના આધારે કરવામાં આવે છે. લર્નિંગ_રેટ વધારવા માટે પુનરાવર્તનોની સંખ્યામાં વધારો કરવો જરૂરી છે.
• l2_leaf_reg — રેગ્યુલરાઈઝેશન ગુણાંક, ડિફોલ્ટ મૂલ્ય 3, પ્રાધાન્યમાં 2 થી 30 પસંદ કરો. મૂલ્યમાં ઘટાડો ઓવરફિટમાં વધારો તરફ દોરી જાય છે.
• બેગિંગ_તાપમાન - નમૂનામાં પદાર્થોના વજનમાં રેન્ડમાઇઝેશન ઉમેરે છે. ડિફૉલ્ટ મૂલ્ય 1 છે, જ્યાં વજન ઘાતાંકીય વિતરણમાંથી દોરવામાં આવે છે. મૂલ્યમાં ઘટાડો ઓવરફિટમાં વધારો તરફ દોરી જાય છે.
• રેન્ડમ_સ્ટ્રેન્થ - ચોક્કસ પુનરાવર્તન પર વિભાજનની પસંદગીને અસર કરે છે. રેન્ડમ_સ્ટ્રેન્થ જેટલું ઊંચું હશે, ઓછા મહત્વના વિભાજનની પસંદગીની તકો વધારે છે. દરેક અનુગામી પુનરાવર્તન પર, રેન્ડમનેસ ઘટે છે. મૂલ્યમાં ઘટાડો ઓવરફિટમાં વધારો તરફ દોરી જાય છે.

અન્ય પરિમાણોની અંતિમ પરિણામ પર ઘણી ઓછી અસર હોય છે, તેથી મેં તેમને પસંદ કરવાનો પ્રયાસ કર્યો નથી. ctr_complexity=1 સાથે મારા GPU ડેટાસેટ પર તાલીમના એક પુનરાવર્તનમાં 20 મિનિટનો સમય લાગ્યો, અને ઘટાડેલા ડેટાસેટ પર પસંદ કરેલા પરિમાણો સંપૂર્ણ ડેટાસેટ પરના શ્રેષ્ઠ પરિમાણો કરતાં થોડા અલગ હતા. અંતે, મેં 30% ડેટા પર લગભગ 10 પુનરાવર્તનો કર્યા, અને પછી તમામ ડેટા પર લગભગ 10 વધુ પુનરાવર્તનો કર્યા. તે આના જેવું કંઈક બહાર આવ્યું:

• શીખવાની_દર મેં ડિફોલ્ટથી 40% વધારો કર્યો છે;
• l2_leaf_reg તે જ છોડી દીધું;
• બેગિંગ_તાપમાન и રેન્ડમ_સ્ટ્રેન્થ 0,8 સુધી ઘટાડી.

અમે નિષ્કર્ષ પર આવી શકીએ છીએ કે મોડલ ડિફૉલ્ટ પરિમાણો સાથે અન્ડરટ્રેઇન કરવામાં આવ્યું હતું.

જ્યારે મેં લીડરબોર્ડ પર પરિણામ જોયું ત્યારે મને ખૂબ જ આશ્ચર્ય થયું:

આ મોડેલ	મોડેલ 1	મોડેલ 2	મોડેલ 3	જોડાણ
ટ્યુનિંગ વિના	0.7403	0.7404	0.7404	0.7407
ટ્યુનિંગ સાથે	0.7406	0.7405	0.7406	0.7408

મેં મારા માટે નિષ્કર્ષ કાઢ્યો કે જો મોડેલની ઝડપી એપ્લિકેશનની જરૂર નથી, તો પછી બિન-ઓપ્ટિમાઇઝ પરિમાણોનો ઉપયોગ કરીને ઘણા મોડેલોના જોડાણ સાથે પરિમાણોની પસંદગીને બદલવું વધુ સારું છે.

Sergey ડેટાસેટના કદને GPU પર ચલાવવા માટે તેને ઑપ્ટિમાઇઝ કરી રહ્યો હતો. સૌથી સરળ વિકલ્પ એ ડેટાના ભાગને કાપી નાખવાનો છે, પરંતુ આ ઘણી રીતે કરી શકાય છે:

• ડેટાસેટ મેમરીમાં ફિટ થવાનું શરૂ ન થાય ત્યાં સુધી ધીમે ધીમે સૌથી જૂનો ડેટા (ફેબ્રુઆરીની શરૂઆત) દૂર કરો;
• સૌથી ઓછા મહત્વ સાથે લક્ષણો દૂર કરો;
• યુઝર આઈડી દૂર કરો જેના માટે માત્ર એક જ એન્ટ્રી છે;
• ફક્ત તે જ વપરાશકર્તા આઈડી છોડો જે પરીક્ષણમાં છે.

અને છેવટે, બધા વિકલ્પોમાંથી એક જોડાણ બનાવો.

છેલ્લું જોડાણ

છેલ્લા દિવસની મોડી સાંજ સુધીમાં, અમે 0,742 ની ઉપજ આપતા અમારા મોડલ્સનું એક જોડાણ તૈયાર કર્યું હતું. રાતોરાત મેં મારું મૉડલ ctr_complexity=2 સાથે લૉન્ચ કર્યું અને 30 મિનિટને બદલે 5 કલાક સુધી પ્રશિક્ષિત કર્યું. માત્ર સવારે 4 વાગ્યે તેની ગણતરી થઈ, અને મેં છેલ્લું જોડાણ બનાવ્યું, જેણે જાહેર લીડરબોર્ડ પર 0,7433 આપ્યું.

સમસ્યાને ઉકેલવા માટેના વિવિધ અભિગમોને લીધે, અમારી આગાહીઓ મજબૂત રીતે સહસંબંધિત ન હતી, જેણે જોડાણમાં સારો વધારો કર્યો. સારું જોડાણ મેળવવા માટે, કાચા મોડેલ અનુમાન અનુમાનનો ઉપયોગ કરવો વધુ સારું છે(prediction_type='RawFormulaVal') અને સ્કેલ_pos_weight=neg_count/pos_count સેટ કરો.

વેબસાઇટ પર તમે જોઈ શકો છો ખાનગી લીડરબોર્ડ પર અંતિમ પરિણામો.

અન્ય ઉકેલો

ઘણી ટીમોએ ભલામણ કરનાર સિસ્ટમ અલ્ગોરિધમ્સના નિયમોનું પાલન કર્યું. હું, આ ક્ષેત્રમાં નિષ્ણાત ન હોવાને કારણે, તેમનું મૂલ્યાંકન કરી શકતો નથી, પરંતુ મને 2 રસપ્રદ ઉકેલો યાદ છે.

• નિકોલે અનોખિનનો ઉકેલ. નિકોલે, Mail.ru ના કર્મચારી હોવાને કારણે, ઈનામો માટે અરજી કરી ન હતી, તેથી તેનો ધ્યેય મહત્તમ ઝડપ હાંસલ કરવાનો ન હતો, પરંતુ સરળતાથી માપી શકાય તેવા ઉકેલ મેળવવાનો હતો.
• જ્યુરી પ્રાઇઝ વિજેતા ટીમના નિર્ણય પર આધારિત છે ફેસબુક તરફથી આ લેખ, મેન્યુઅલ વર્ક વિના ખૂબ જ સારી ઇમેજ ક્લસ્ટરિંગ માટે મંજૂરી છે.

નિષ્કર્ષ

મારી સ્મૃતિમાં સૌથી વધુ શું અટકી ગયું છે:

• જો ડેટામાં સ્પષ્ટ લક્ષણો છે, અને તમે લક્ષ્ય એન્કોડિંગને યોગ્ય રીતે કેવી રીતે કરવું તે જાણો છો, તો પણ કેટબૂસ્ટનો પ્રયાસ કરવો વધુ સારું છે.
• જો તમે સ્પર્ધામાં ભાગ લઈ રહ્યા હોવ, તો તમારે લર્નિંગ_રેટ અને પુનરાવર્તનો સિવાયના પરિમાણો પસંદ કરવામાં સમય બગાડવો જોઈએ નહીં. એક ઝડપી ઉકેલ એ છે કે ઘણા મોડેલોનું જોડાણ બનાવવું.
• બૂસ્ટિંગ્સ GPU પર શીખી શકે છે. કેટબૂસ્ટ GPU પર ખૂબ જ ઝડપથી શીખી શકે છે, પરંતુ તે ઘણી બધી મેમરી ખાય છે.
• વિચારોના વિકાસ અને પરીક્ષણ દરમિયાન, નાનું rsm~=0.2 (માત્ર CPU) અને ctr_complexity=1 સેટ કરવું વધુ સારું છે.
• અન્ય ટીમોથી વિપરીત, અમારા મોડલ્સના જોડાણે મોટો વધારો કર્યો. અમે ફક્ત વિચારોનું આદાનપ્રદાન કર્યું અને જુદી જુદી ભાષાઓમાં લખ્યું. ડેટાને વિભાજિત કરવા માટે અમારી પાસે એક અલગ અભિગમ હતો અને, મને લાગે છે કે, દરેકની પોતાની ભૂલો હતી.
• તે સ્પષ્ટ નથી કે શા માટે રેન્કિંગ ઑપ્ટિમાઇઝેશન વર્ગીકરણ ઑપ્ટિમાઇઝેશન કરતાં ખરાબ પ્રદર્શન કર્યું.
• મેં પાઠો સાથે કામ કરવાનો થોડો અનુભવ મેળવ્યો અને ભલામણકર્તા સિસ્ટમો કેવી રીતે બનાવવામાં આવે છે તેની સમજ મેળવી.

લાગણીઓ, જ્ઞાન અને પ્રાપ્ત ઈનામો માટે આયોજકોનો આભાર.

સોર્સ: www.habr.com