Працягваючы тэму конкурсаў па машынным навучанні на хабры, жадаем пазнаёміць чытачоў яшчэ з двума платформамі. Яны вядома не такія вялізныя як kaggle, але ўвагі вызначана заслугоўваюць.
Асабіста мне kaggle не надта падабаецца па некалькіх прычынах:
- па-першае, спаборніцтвы там часта доўжацца па некалькі месяцаў, і для актыўнага ўдзелу даводзіцца марнаваць безліч сіл;
- па-другое, public kernels (публічныя рашэнні). Адэпты kaggle раяць да іх ставіцца са спакоем тыбецкіх манахаў, але ў рэальнасці даволі крыўдна, калі тое, да чаго ты ішоў месяц ці два, раптам аказваецца выкладзеным на сподачку ўсім запар.
На шчасце, спаборніцтвы па машынным навучанні праводзяцца і на іншых платформах, і аб пары такіх спаборніцтваў і пайдзе прамову.
| Афіцыйная мова: англійская, арганізатары: Яндэкс, Ашчадбанк, ВШЭ |
Афіцыйная мова: руская, арганізатары: Mail.ru Group |
| Online Round: Jan 15 - Feb 11, 2019; On-Site Final: Apr 4-6, 2019 |
анлайн - з 7 лютага па 15 сакавіка; афлайн - з 30 сакавіка па 1 красавіка. |
| Па некаторым наборы дадзеных аб часціцы ў вялікім адронным калайдары (аб траекторыі, імпульсе, і іншых даволі складаных фізічных параметрах) вызначыць мюон гэта ці не З гэтай пастаноўкі было выдзелена 2 задачы: - у адной трэба было проста адправіць сваё прадказанне, - а ў іншай - поўны код і мадэль для прадказання, і на выкананне накладваліся даволі цвёрдыя абмежаванні на час працы і выкарыстанне памяці |
Для спаборніцтва SNA Hackathon былі сабраны логі паказаў кантэнту з адкрытых груп у стужках навін карыстальнікаў за люты-сакавік 2018 года. У тэставае мноства схаваны апошнія паўтара тыдня сакавіка. Кожны запіс у логу змяшчае інфармацыю аб тым, што і каму было паказана, а таксама аб тым, як адрэагаваў карыстальнік на гэты кантэнт: паставіў "клас", пракаментаваў, праігнараваў або схаваў са стужкі. Сутнасць задач SNA Hackathon у тым, каб для кожнага карыстальніка сацыяльнай сеткі Аднакласнікі адранжыраваць яго стужку, як мага вышэй узнімаючы тыя пасты, якія атрымаюць «клас». На онлайн этапе задача была разбіта на 3 часткі: 1. адранжыраваць пасты па разнастайных калабаратыўных прыкметах 2. адранжыраваць пасты па змешчаных у іх выявах 3. аранжыраваць пасты па тэксту, які ў іх змяшчаецца |
| Складаная кастамная метрыка, нешта накшталт ROC-AUC | Сярэдні ROC-AUC па карыстальнікам |
| Прызы за першы этап - футболкі за N месцаў, праход у другі этап, дзе аплачваліся пражыванне і харчаванне падчас конкурсу Другі этап -??? (Я па пэўных прычынах на цырымоніі ўзнагароджання не прысутнічаў і выведаць, што ў выніку былі за прызы не змог). Абяцалі ноўтбукі ўсім членам каманды-пераможцаў |
Прызы за першы этап - футболкі 100 лепшым удзельнікам, праход у другі этап, дзе аплачваліся праезд да Масквы, пражыванне і харчаванне падчас конкурсу. Таксама бліжэй да канца першага этапу абвясцілі аб прызах лепшым па 3 задачам на 1 этапе: кожны выйграў па відэакарце RTX 2080 TI! Другі этап - камандны, у камандах было ад 2 да 5 чалавек, прызы: 1 месца - 300 000 рублёў 2 месца - 200 000 рублёў 3 месца - 100 000 рублёў прыз журы - 100 000 рублёў |
| Афіцыйная група ў telegram, ~190 удзельнікаў, зносіны на англійскай, на пытанні даводзілася чакаць адказу па некалькі дзён. | Афіцыйная група ў telegram, ~1500 удзельнікаў, актыўнае абмеркаванне задач паміж удзельнікамі і арганізатарамі |
| Арганізатары падалі два базавыя рашэнні, простае і прасунутае. Простае патрабавала менш за 16 Гб аператыўнай памяці, а прасунутае ў 16 ужо не ўлазілі. Пры гэтым, забягаючы крыху наперад, ва ўдзельнікаў не ўдалося значна перасягнуць прасунутае рашэнне. Складанасцяў па запуску гэтых рашэнняў не было. Варта адзначыць, што ў прасунутым прыкладзе прысутнічаў каментар з падказкай з чаго пачаць паляпшэнне рашэння. | Даваліся базавыя прымітыўныя рашэнні для кожнай з задач, лёгка пераўзыходзіліся ўдзельнікамі. У першыя дні конкурсу ўдзельнікі сутыкнуліся з некалькімі цяжкасцямі: па-першае, дадзеныя былі дадзеныя ў фармаце Apache Parquet, і не ўсе камбінацыі Python і пакета parquet працавалі без памылак. Другой складанасцю стала выпампоўванне малюнкаў з аблокі mail, на дадзены момант няма простага спосабу запампаваць вялікі аб'ём дадзеных за раз. У выніку гэтыя праблемы затрымалі ўдзельнікаў на пару дзён. |
IDAO. Першы этап
Задачай было класіфікацыя часціц мюон / ня мюон па іх характарыстыках. Ключавой асаблівасцю дадзенай задачы была наяўнасць у трэніровачных дадзеных калонкі weight, якую самі арганізатары тлумачылі як упэўненасць у адказе для гэтага радка. Праблема складалася ў тым, што даволі шмат радкоў утрымоўвалі адмоўныя вагі.
Падумаўшы некалькі хвілін над радком з падказкай (падказка проста зважала на гэтую асаблівасць калонкі weight) і пабудаваўшы гэты графік, мы вырашылі праверыць 3 варыянты:
1) інвертаваць таргет у радкоў з адмоўнай вагой (і вагі адпаведна)
2) ссунуць вагі на мінімальнае значэнне, так каб яны пачыналіся з 0
3) не выкарыстоўваць вагі для радкоў
Трэці варыянт аказаўся самым горшым, а вось першыя два паляпшалі вынік, лепшым аказаўся варыянт №1, які адразу нас вывеў на бягучае другое месца па першай задачы і на першае ў другой.
Наступным нашым крокам быў прагляд даных на прадмет прапушчаных значэнняў. Арганізатары далі нам ужо прычасаныя дадзеныя, дзе прапушчаных значэнняў было даволі мала, і яны былі заменены на -9999.
Мы выявілі прапушчаныя значэнні ў калонках MatchedHit_{X,Y,Z}[N] і MatchedHit_D{X,Y,Z}[N], прычым толькі калі N=2 ці 3. Як мы зразумелі, некаторыя часціцы не праляталі ўсе 4 дэтэктары , і спыняліся або на 3 ці на 4 пласціне. У дадзеных таксама прысутнічалі калонкі Lextra_{X,Y}[N], якія мабыць апісваюць тое ж самае, што і MatchedHit_{X,Y,Z}[N], але выкарыстоўваючы нейкую экстрапаляцыю. Гэтыя бедныя здагадкі дазволілі выказаць здагадку, што замест прапушчаных значэнняў у MatchedHit_{X,Y,Z}[N] можна падставіць Lextra_{X,Y}[N] (толькі для X і Y каардынат). MatchedHit_Z[N] добра запаўнялася медыянай. Гэтыя маніпуляцыі дазволілі нам выйсці на 1 прамежкавае месца па абодвух задач.
Улічваючы, што за перамогу ў першым этапе нічога не давалі, можна было б спыніцца на гэтым, але мы працягнулі, намалявалі некалькі прыгожых карцінак і прыдумалі новыя фічы.
Напрыклад, мы выявілі, што калі пабудаваць кропкі скрыжаванняў часціцы з кожнай з чатырох пласцін дэтэктараў, то можна заўважыць, што кропкі на кожнай з пласцін групуюцца ў 5 прастакутнікаў з суадносінамі бакоў 4 да 5 і цэнтрам у кропцы (0,0), і ў першым прамавугольніку кропак няма.
| № пласціны / памеры прамавугольнікаў | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| Пласціна 1 | 500х625 | 1000х1250 | 2000х2500 | 4000х5000 | 8000х10000 |
| Пласціна 2 | 520х650 | 1040х1300 | 2080х2600 | 4160х5200 | 8320х10400 |
| Пласціна 3 | 560х700 | 1120х1400 | 2240х2800 | 4480х5600 | 8960х11200 |
| Пласціна 4 | 600х750 | 1200х1500 | 2400х3000 | 4800х6000 | 9600х12000 |
Вызначыўшы гэтыя памеры, мы дадалі для кожнай часціцы 4 новыя катэгарыяльныя фічы - нумар прастакутніка, у якім яна перасякаюць кожную пласціну.
Таксама мы заўважылі, што часціцы як бы разлятаюцца ў бакі ад цэнтра і з'явілася ідэя неяк ацаніць "якасць" гэтага разлёту. У ідэале, мусіць, можна было б прыдумаць нейкую "ідэальную" парабалу ў залежнасці ад кропкі ўлёту і ацаніць ад яе адхіленне, але мы абмежаваліся "ідэальнай" прамой. Пабудаваўшы такія ідэальныя прамыя для кожнай кропкі ўлёту, мы змаглі палічыць сярэдне-квадратычнае адхіленне траекторыі кожнай часціцы ад гэтай прамой. Паколькі сярэдняе адхіленне для target = 1 аказалася 152, а для target = 0 атрымалася 390, мы папярэдне ацанілі дадзеную фічу як добрую. Дадзеная фіча адразу патрапіла ў топ самых карысных.
Мы ўзрадаваліся, і дадалі адхіленне ўсіх 4 кропак скрыжавання для кожнай часціцы ад ідэальнай прамой як дадатковыя 4 фічы (і яны таксама нядрэнна працавалі).
Спасылкі на навуковыя артыкулы па тэме конкурсу, дадзеныя нам арганізатарамі, наштурхнулі на думку, што мы далёка не першыя, хто вырашае дадзеную задачу і, магчыма, існуе нейкі спецыялізаваны софт. Выявіўшы на github рэпазітар, дзе былі рэалізаваны метады IsMuonSimple, IsMuon, IsMuonLoose, мы перанеслі іх да сябе з невялікімі мадыфікацыямі. Самі метады былі вельмі простыя: напрыклад, калі энергія менш нейкага парога - то гэта не мюон, інакш мюон. Настолькі простыя прыкметы відавочна не маглі даць прыросту ў выпадку выкарыстання градыентнага бустынгу, таму мы дадалі яшчэ знакавую "адлегласць" да парога. Гэтыя фічы таксама крыху палепшылі. Магчыма, прааналізаваўшы існуючыя методыкі больш грунтоўна, можна было знайсці і мацнейшыя метады і дадаць іх у прыкметы.
Пад канец конкурсу мы крыху пацюнілі «хуткае» рашэнне для другой задачы, у выніку яно адрознівалася ад baseline па наступных пунктах:
- У радках з адмоўнай вагай быў інвертаваны target
- Запоўнілі прапушчаныя значэнні ў MatchedHit_{X,Y,Z}[N]
- Зменшылі глыбіню да 7
- Зменшылі learning rate да 0.1 (было 0.19)
У выніку мы спрабавалі яшчэ фічы (не асоба ўдала), падабралі параметры і навучылі catboost, lightgbm і xgboost, паспрабавалі розныя блендынгі прадказанняў і перад адкрыццём привата ўпэўнена выйгравалі па другой задачы, а па першай былі сярод лідэраў.
Пасля адкрыцця прывата мы апынуліся на 10 месцы па 1 задачы і на 3 па другой. Усе лідэры перамяшаліся, і хуткі на прываце аказаўся вышэй чым на лібербордзе. Здаецца, што дадзеныя былі дрэнна стратыфікаваная (ці напрыклад, у прываце не было радкоў з адмоўнымі вагамі) і гэта крыху засмуціла.
SNA Hackathon 2019 - Тэксты. Першы этап
Задачай было адранжыраваць пасты карыстальніка ў сацыяльнай сетцы Аднакласнікі па тэксту, які ў іх змяшчае, акрамя тэксту было яшчэ трохі характарыстык паста (мова, уладальнік, дата і час стварэння, дата і час прагляду).
У якасці класічных падыходаў да працы з тэкстам я б вылучыў два варыянты:
- Адлюстраванне кожнага слова ў n-мерную вектарную прастору, такое каб у падобных слоў былі падобныя вектара (падрабязней можна прачытаць у ), затым або знаходжанне сярэдняга слова для тэксту або выкарыстанне механізмаў, якія ўлічаць узаемнае размяшчэнне слоў (CNN, LSTM/GRU).
- Выкарыстанне мадэляў, якія адразу ўмеюць працаваць з цэлымі прапановамі. Напрыклад, Bert. У тэорыі гэты падыход павінен працаваць лепш.
Паколькі гэта быў мой першы досвед працы з тэкстамі, будзе няправільна вучыць кагосьці, таму я буду вучыць сябе. Вось такія парады я б даў сабе на пачатак конкурсу:
- Перш чым бегчы нешта навучаць, паглядзі на дадзеныя! Апроч непасрэдна тэкстаў у дадзеных было некалькі калонак і з іх можна было выціснуць значна больш, чым зрабіў я. Самае простае - зрабіць mean target encoding для часткі калонак.
- Не вучыся на ўсіх дадзеных! Дадзеных было вельмі шмат (прыкладна 17 млн радкоў) і для праверкі гіпотэз было зусім неабавязкова выкарыстоўваць іх усе. Навучанне і перадапрацоўка былі вельмі павольныя, і я відавочна б паспеў праверыць больш цікавых гіпотэз.
- <Спрэчная рада> Не трэба шукаць кілер-мадэль. Я доўга разбіраўся з Elmo і Bert, спадзеючыся, што яны адразу мяне вывядуць на высокае месца, а ў выніку выкарыстоўваў прадугледжаныя эмбедынгі FastText для рускай мовы. З Elmo не атрымалася дасягнуць лепшага хутка, а з Bert так і не паспеў разабрацца.
- <Спрэчная рада> Не трэба шукаць адну кілер-фічу. Паглядзеўшы на дадзеныя, я заўважыў, што ў раёне 1 працэнта тэкстаў не змяшчаюць, уласна, тэксту! Але затое там былі спасылкі на нейкія рэсурсы, і я напісаў просценькі парсер, які адчыняў сайт і выцягваў назву і апісанне. Накшталт добрая ідэя, але потым я захапіўся, вырашыў распарсіць усе спасылкі для ўсіх тэкстаў і зноў страціў шмат часу. Значнага паляпшэння выніковага выніку ўсё гэта не дало (хоць разабраўся са стэмінгам, напрыклад).
- Класічныя фічы працуюць. Гуглим, напрыклад, "text features kaggle", чытаем і ўсё дадаем. TF-IDF давала паляпшэнне, статыстычныя фічы, накшталт даўжыні тэксту, словы, колькасці пунктуацыі – таксама.
- Калі ёсць DateTime калонкі, варта іх разабраць на некалькі асобных фіч (гадзіны, дні тыдня і г.д). Якія менавіта фічы вылучыць, варта прааналізаваць графікамі / нейкімі метрыкамі. Тут я па сутнасці зрабіў усё правільна і патрэбныя фічы вылучыў, але нармальны аналіз бы не перашкодзіў (напрыклад, як мы зрабілі на фінале).
Па выніку конкурсу я навучыў адну keras мадэль са скруткам па словах, і яшчэ адну на аснове LSTM і GRU. І там і там выкарыстоўваліся прадугледжаныя FastText эмбедынгі для рускай мовы (я паспрабаваў і шэраг іншых эмбедынгаў, але менавіта гэтыя працавалі лепш за ўсё). Асерадніўшы прадказанні, я заняў выніковае 7 месца з 76 удзельнікаў.
Ужо пасля першага этапа была апублікавана , які заняў другое месца (ён удзельнічаў па-за конкурсам), і яго рашэнне да нейкага этапу паўтарала маё, але ён сышоў далей за кошт механізму query-key-value attention.
Другі этап OK & IDAO
Другія этапы конкурсаў праходзілі амаль запар, таму я вырашыў разгледзець іх разам.
Спачатку я з нованабытай камандай патрапіў ва ўражлівы офіс кампаніі Mail.ru, дзе нашай задачай было аб'яднаць мадэлі трох трэкаў з першага этапу – тэксту, карцінкі і калаб. На гэта было адведзена крыху больш за 2 сутак, што аказалася вельмі мала. Па сутнасці, мы змаглі толькі паўтарыць свае вынікі першага этапа, не атрымаўшы ніякага выйгрышу ад аб'яднання. У выніку мы занялі 5 месца, але тэкставую мадэль выкарыстоўваць не ўдалося. Паглядзеўшы на рашэнні іншых удзельнікаў, здаецца, што варта паспрабаваць кластарызаваць тэксты і дадаць іх да мадэлі калаба. Пабочным эфектам гэтага этапу сталі новыя ўражанні, знаёмствы і зносіны з крутымі ўдзельнікамі і арганізатарамі, а таксама моцны недасыпанне, якое магчыма адбілася і на выніку фінальнага этапу IDAO.
Задачай на вочным этапе IDAO 2019 Final было прадказанне часу чакання замовы для яндэкс-таксістаў у аэрапорце. На 2 этапе былі выдзелены 3 задачы = 3 аэрапорта. Для кожнага аэрапорта дадзены пахвілінныя даныя аб колькасці заказаў таксі за паўгода. А ў якасці тэставых дадзеных быў дадзены наступны месяц і штохвілінныя дадзеныя аб замовах за мінулыя 2 тыдні. Часу было мала (1,5 дня), задача была даволі спецыфічнай, з каманды на конкурс прыехаў толькі адзін чалавек - і як вынік сумнае месца бліжэй да канца. З цікавых ідэй былі спробы выкарыстоўваць знешніх дадзеных: аб надвор'і, корках і статыстыцы заказаў яндэкс-таксі. Хаця арганізатары і не сказалі, што гэта за аэрапорты, многія ўдзельнікі выказалі здагадку, што гэта былі Шарамеццева, Дамадзедава і Унукава. Хоць пасля конкурсу гэтая здагадка была абвергнута, фічы, напрыклад, з пагодных дадзеных Масквы паляпшалі вынік і на валідацыі і на лідэрбордзе.
Заключэнне
- ML-конкурсы гэта крута і цікава! Тут знойдзецца ўжыванне ўменням і па аналізе дадзеных, і па хітрых мадэлях і тэхнікам, ды і проста разумны сэнс вітаецца.
- ML - гэта ўжо велізарны пласт ведаў, які здаецца што расце экспанентна. Я паставіў сабе мэту пазнаёміцца з рознымі абласцямі (сігналы, карцінкі, табліцы, тэкст) і ўжо зразумеў, як шмат усяго трэба вывучыць. Напрыклад, пасля гэтых конкурсаў я вырашыў вывучаць: алгарытмы кластарызацыі, прасунутыя тэхнікі працы з бібліятэкамі градыентнага бустынгу (у прыватнасці папрацаваць з CatBoost на GPU), капсульныя сеткі, механізм query-key-value attention.
- Ня kaggle'ом адзіным! Ёсць шмат іншых конкурсаў, дзе хаця б футболку атрымаць прасцей, ды і на іншыя прызы больш шанцаў.
- Майце зносіны! У вобласці машыннага навучання і аналізу дадзеных ужо вялікае community, ёсць тэматычныя групы ў telegram, slack, і сур'ёзныя людзі з Mail.ru, Яндэкса і іншых кампаній адказваюць на пытанні і дапамагаюць пачаткоўцам і якія працягваюць свой шлях у гэтай вобласці ведаў.
- Усім, хто прасяк папярэднім пунктам, раю наведаць - буйную бясплатную канферэнцыю ў Маскве, якая пройдзе ўжо 10-11 траўня.
Крыніца: habr.com