Продовжуючи тему конкурсів з машинного навчання на хабрі, хочемо познайомити читачів ще із двома платформами. Вони звичайно не такі великі як 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 місце, але текстову модель використати не вдалося. Подивившись рішення інших учасників, здається, що варто спробувати кластеризувати тексти і додати їх до моделі колабу. Побічним ефектом цього етапу стали нові враження, знайомства та спілкування з крутими учасниками та організаторами, а також сильний недосип, який, можливо, позначився і на результаті фінального етапу 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