*фарм — (от англ. farming) — долгое и занудное повторение определенных игровых действий с определенной целью (получение опыта, добыча ресурсов и др.).

Введение

Недавно (1 октября) стартовала новая сессия прекрасного курса по DS/ML (очень рекомендую в качестве начального курса всем, кто хочет, как это теперь называется, "войти" в DS). И, как обычно, после окончания любого курса у выпускников возникает вопрос — а где теперь получить практический опыт, чтобы закрепить пока еще сырые теоретические знания. Если вы зададите этот вопрос на любом профильном форуме — ответ, скорее всего, будет один — иди решай Kaggle. Kaggle — это да, но с чего начать и как наиболее эффективно использовать эту платформу для прокачки практических навыков? В данной статье автор постарается на своем опыте дать ответы на эти вопросы, а также описать расположение основных грабель на поле соревновательного DS, чтобы ускорить процесс прокачки и получать от этого фан.

Несколько слов про курс от его создателей:

Курс mlcourse.ai — одна из масштабных активностей сообщества OpenDataScience. @yorko и компания (~ 60 чел.) демонстрируют, что классные навыки можно получить и вне стен университета и даже абсолютно бесплатно. Основная идея курса — оптимальное сочетание теории и практики. С одной стороны, изложение основных концепций происходит не без математики, с другой стороны — куча домашних заданий, соревнования Kaggle Inclass и проекты дадут, при определенном вложении сил с вашей стороны, отличные навыки машинного обучения. Нельзя не отметить соревновательную природу курса — ведется общий рейтинг студентов, что сильно мотивирует. Также курс отличается тем, что он проходит в действительно живом сообществе.

В рамках курса проходят два соревнования Kaggle Inclass. Оба очень интересные, в них неплохо работает построение признаков. Первое — идентификация пользователя по последовательности посещенных сайтов. Второе — предсказание популярности статьи на Медиуме. Главная польза — от двух домашних заданий, где надо проявить смекалку и побить бейзлайны в этих соревнованиях.

Отдав должное курсу и его создателям, продолжаем нашу историю...

Вспоминаю себя полтора года назад, пройден курс (еще первая версия) от Andrew Ng, закончена специализация от МФТИ, прочитана гора книг — теоретических знаний полна головушка, но при попытке решить любую базовую боевую задачу — возникает ступор. Нет, как решать задачу — понятно, какие алгоритмы применять — тоже понятно, но вот код пишется очень тяжело, с поминутным заходом на хелп sklearn / pandas, и т.д. Почему так — нет наработанных пайплайнов и ощущения кода "на кончиках пальцев".

Так дело не пойдет, подумал автор, и ушел на Kaggle. Сразу с боевого соревнования начинать было страшно, и первой ласточкой стало Getting started соревнование "House Prices: Advanced Regression Techniques", на котором и оформился тот подход к эффективной прокачке, который описан в этой статье.

В том, что будет описано дальше, нет никакого know-how, все техники, методы и приемы — очевидны и предсказуемы, но это не умаляет их эффективности. По крайней мере, следуя им, автору удалось взять плашку Kaggle Competition Master за полгода и три соревнования в соло режиме и, на момент написания данной статьи, входить в top-200 мирового рейтинга Kaggle. Кстати, это отвечает на вопрос, почему автор вообще позволил себе смелость написать статью такого рода.

В двух словах что вообще такое Kaggle

Kaggle — одна из наиболее известных платформ для проведения соревнований по Data Science, В каждом соревновании организаторы выкладывают описание задачи, данные для решения этой задачи, метрику, по которой будет оцениваться решение — и устанавливают сроки и призы. Участникам дается от 3 до 5 попыток (по воле организаторов) в день на "сабмит" (посылку своего варианта решения).

Данные делятся на тренировочную выборку (train) и тестовую (test). Для тренировочной части известно значение целевой переменной (target), для тестовой — нет. Задача участников создать модель, которая, будучи обучена на тренировочной части данных выдаст максимальный результат на тестовой.

Каждый участник делает предсказания для тестовой выборки — и отсылает результат на Kaggle, далее робот (которому известна целевая переменная для теста) оценивает присланный результат, который отображается на лидерборде.

Но не все так просто — тестовые данные, в свою очередь, делятся в определенной пропорции на публичную (public) и приватную (private) часть. В течение соревнования присланное решение оценивается, согласно установленной организаторами метрике, на публичной части данных и выкладывается на лидерборд (т.н. паблик лидерборд) — по которому участники могут оценивать качество своих моделей. Окончательное решение (обычно два — по выбору участника) оценивается на приватной части тестовых данных — и результат попадает на приватный лидерборд, который доступен только после окончания соревнования и по которому, собственно, и оцениваются финальные результаты, раздаются призы, плюшки, и медальки.

Таким образом, в течение соревнования участникам доступна только информация как их модель повела себя (какой результат — или скор она показала) на публичной части тестовых данных. Если, в случае сферического коня в вакууме, приватная часть данных совпадает по распределению и статистикам с публичной — все прекрасно, если же нет — то модель, которая показала себя хорошо на паблике может не сработать на приватной части, то есть заоверфититься (переобучиться). И вот тут-то возникает то, что на жаргоне называется "полетом", когда люди с 10 места на паблике улетают вниз на 1000-2000 мест на приватной части из-за того, что выбранная ими модель переобучилась и не смогла выдать необходимую точность на новых данных.

Как этого избежать? Для этого, в первую очередь, необходимо построить правильную схему валидации, то, чему учат на первых уроках практически на всех курсах по DS. Т.к. если ваша модель не может выдать правильный прогноз на данных, которых она никогда не видела — то какую бы навороченную технику вы бы не применяли, сколь сложные нейронные сети не строили — в продакшен такую модель выпускать нельзя, т.к. ее результаты ничего не стоят.

Для каждого соревнования на Kaggle создается своя отдельная страничка на которой есть раздел с данными, с описанием метрики — и самое для нас интересное — форум и кернелы.

Форум он и на Kaggle форум, народ пишет, обсуждает и делится идеями. А вот кернелы — это уже интереснее. По сути, это возможность запускать свой код, который имеет непосредственный доступ к данным соревнования в облаке Kaggle (аналог амазоновского AWS, гугловского GCE, и т.д.) На каждый кернел выделяются ограниченные ресурсы, поэтому если данных не очень много, то работать с ними вы можете прямо из браузера на сайте Kaggle — пишете код, запускаете на выполнение, сабмитите результат. Два года назад Kaggle был приобретен компанией Google, так что неудивительно, что "под капотом" данный функционал использует Google Cloud Engine.

Более того было несколько соревнований (недавнее — Mercari), где с данными можно было работать вообще только через кернелы. Очень интересный формат, нивелирующий разницу в железе у участников и заставляющий включить мозг на предмет оптимизации кода и подходов, так как, естественно, в кернелах было жесткое ограничение по ресурсам, на тот момент — 4 cores / 16 GB RAM / 60 minutes run-time / 1 GB scratch and output disk space. Работая над этим соревнованием, автор узнал больше об оптимизации нейронных сетей, чем из любого теоретического курса. Немного не хватило до золота, финишировал соло 23-м, но опыта и удовольствия получил изрядно…

Пользуясь случаем еще раз хочу сказать Спасибо коллегам из ods.ai — Артуру Степаненко (arthur), Константину Лопухину (kostia), Сергею Фиронову (sergeif) за советы и поддержку в этом соревновании. Вообще было много интересных моментов, Константин Лопухин (kostia), взявший первое место вместе с Pawel Jankiewicz, потом выложил то, что в чатике назвали "эталонное унижение в 75 строк" — кернел в 75 строк кода, выдающий результат в золотую зону лидерборда. Это, конечно, надо видеть :)

Ладно, отвлеклись, так вот — народ пишет код и выкладывает кернелы с решениями, интересными идеями и прочим. Обычно в каждом соревновании через пару недель появляется один-два прекрасных EDA (exploratory data analysis) кернела, с подробнейшим описанием датасета, статистик, характеристик и т.д. И парочка бейзлайнов (базовых решений), которые, конечно, показывают не самый лучший результат на лидерборде, но их можно использовать в качестве отправной точки для создания своего решения.

Почему Kaggle?

На самом деле без разницы на какой платформе вы будете играть, просто Kaggle — одна из первых и наиболее раскрученных, с прекрасным коммьюнити и достаточно комфортным окружением (надеюсь они доработают кернелы на предмет стабильности и производительности, а то многие помнят тот ад, что творился в Mercari) Но, в целом, платформа очень удобна и самодостаточна, да и плашки ее пока еще ценятся.

Небольшое отступление вообще на тему соревновательного DS. Очень часто, в статьях, разговорах и прочем общении звучит мысль, что это все туфта, к реальным задачам опыт в соревнованиях не имеет никакого отношения, и народ там занимается тем, что тюнит 5-й знак после запятой, что есть маразм и оторвано от реальности. Давайте разберемся в этом вопросе немного подробнее:

Как практикующие DS-специалисты, в отличие от академии и науки, мы, в нашей работе, должны и будем решать задачи бизнеса. То есть (тут отсылка к CRISP-DM) для решения поставленной задачи необходимо:

• понять бизнес-задачу
• оценить данные на предмет может ли в них скрываться ответ на эту бизнес задачу
• собрать дополнительные данные, если существующих недостаточно для получения ответа
• выбрать метрику, которая наиболее точно саппроксимирует бизнес-цель
• и уже только после этого выбирать модель, преобразовывать данные под выбранную модель и "стекать хгбусты". (С)

Первым четырем пунктам из этого списка не учат нигде (поправьте меня, если появились такие курсы — запишусь не раздумывая), тут только перенимать опыт коллег, работающих в этой отрасли. А вот последний пункт — начиная с выбора модели и далее, можно и нужно прокачивать в соревнованиях.

В любом соревновании большую часть работы за нас выполнили организаторы. У нас есть описанная бизнес-цель, выбрана аппроксимирующая метрика, собраны данные — и наша задача построить из всего этого лего работающий пайплайн. И вот тут-то и прокачиваются навыки — как работать с пропусками, как готовить данные для нейронных сетей и деревьев (и почему нейронные сети требуют особого подхода), как грамотно построить валидацию, как не переобучиться, как подобрать гиперпараметры, как …… да еще десятка два "как", грамотное исполнение которых и отличает хорошего спеца от проходных людей в нашей профессии.

Что можно "фармить" на Kaggle

В основном, и это разумно, все новички приходят на Kaggle, чтобы получать и прокачивать практический опыт, но не стоит забывать, что помимо этого есть еще как минимум две цели:

• Фарм медалей и плашек
• Фарм репутации в Kaggle-коммьюнити

Главное, что надо помнить — эти три цели абсолютно разные, для их достижения требуются разные подходы, и не надо их смешивать особенно на начальном этапе!

Не зря подчеркнуто "на начальном этапе", когда вы прокачаетесь — эти три цели сольются в одну и будут решаться параллельно, но пока вы только начинаете — не смешивайте их! Этим вы избежите боли, разочарования и обиды на этот несправедливый мир.

Пройдемся кратко по целям снизу вверх:

• Репутация — прокачивается написанием хороших постов (и комментариев) на форуме и созданием полезных кернелов. Например EDA кернелы (см. выше), посты с описанием нестандартных техник и т.д.
• Медали — очень неоднозначный и хейтовый топик, но да ладно. Прокачивается блендингом паблик кернелов (*), участием в команде с перекосом в опыте, ну и созданием своего топ-пайплайна.
• Опыт — прокачивается разбором решений и работой над ошибками.

(*) блендинг паблик кернелов — техника фарма медалей, при которой выбираются выложенные кернелы с максимальным скором на паблик лидерборде, их предсказания усредняются (блендятся), результат сабмитится. Как правило такой метод приводит к жесткому оверфиту (переобучению на трейн) и полету на прайвете, но иногда позволяет получить сабмит чуть ли не в серебро. Автор, на начальном этапе, не рекомендует подобный подход (читай ниже про пояс и штаны).

Рекомендую первой целью выбрать "опыт" и придерживаться его до момента, когда вы почувствуете, что готовы работать над двумя/тремя целями одновременно.

Есть еще два момента, которые стоит упомянуть (Владимир Игловиков (ternaus) — спасибо за напоминание).

Первое — это конвертация усилий, вложенных в Kaggle в новое, более интересное и/или высокооплачиваемое место работы. Как бы ни были нивелированы сейчас плашки Kaggle, но для понимающих людей строчка в резюме "Kaggle Competition Master", да и другие ачивки все-таки чего-то да стоят.

В качестве иллюстрации этого момента можно привести два интервью (раз, два) с нашими коллегами Сергеем Мушинским (cepera_ang) и Александром Буслаевым (albu)

А также мнение Валерия Бабушкина (venheads):

Валерий Бабушкин — Head of Data Science в X5 Retail Group (текущая численность подразделения 30 человек + 20 вакансий с 2019 года)

Руководитель группы аналитики Яндекс Советника

Kaggle Competition Master является отличной прокси метрикой для оценки будущего участника команды. Конечно в связи с последними событиями в виде команд по 30 человек и неприкрытых паровозов требуется чуть более тщательное изучение профиля чем раньше, но это все равно дело нескольких минут. Человек, добившийся звания мастера, с большой долей вероятности умеет писать как минимум среднего качества код, сносно разбирается в машинном обучении, умеет чистить данные и строить стабильные решения. Если лычкой мастера еще нельзя похвастаться, то сам факт участия это тоже плюс, как минимум кандидат знает про существования Кагла и не поленился и потратил время на его освоение. А если было запущено что-то кроме публичного кернела и полученное решение превзошло его результаты (что довольно легко проверить), то это повод для детальной беседы по поводу технических деталей, что гораздо лучше и интереснее, чем классические вопросы по теории, ответы на которые дают меньше понимания как человек будет в будущем справляться с работой. Единственная чего следует опасаться и с чем я сталкивался, что некоторые люди думают что работа DS это примерно как Кагл, что в корне не верно. Еще многие думают что DS = ML, что тоже является ошибкой

Второй момент — это то, что решение многих задач можно оформлять в виде пре-принтов или статей, что с одной стороны позволяет знаниям, которые коллективный разум родил во время соревнования не умереть в дебрях форума, а с другой добавляет в портфолио авторов еще одну строчку и +1 к visibility, что в любом случае положительно сказывается и на карьере и на индексе цитируемости.

Как избежать боли от потери медали

Забить!

Поясню. Практически в каждом соревновании ближе к его окончанию на паблик выкладывается кернел с решением, которое сдвигает весь лидерборд вверх, ну а вас, с вашим решением, соответственно вниз. И каждый раз на форуме начинается БОЛЬ! Как же так, вот у меня было решение на серебро, а теперь я даже на бронзу не тяну. Что за дела, верните все взад.

Помните — Kaggle — соревновательный DS. В том, на каком месте лидерборда вы находитесь — зависит только от вас. Не от того парня, что выложил кернел, не от того сошлись звезды или нет, а только от того сколько усилий вы приложили к решению и все ли возможные пути к его улучшению вы использовали.

Если паблик кернел сбивает вас с вашего места на лидерборде — это не ваше место.

Вместо того, чтобы изливать боль от несправедливости мира — поблагодарите этого парня. Серьезно, паблик кернел с лучшим решением, чем ваше означает, что вы чего-то упустили в своих пайплайнах. Найдите что именно, улучшите ваш пайплайн — и обойдите всю ту толпу хомячков с одинаковым скором. Помните, чтобы вернуться на свое место вам надо просто быть чуть-чуть лучше чем этот паблик.

Как меня этот момент расстраивал в первых соревнованиях, аж руки опускались, вот ты в серебре — и вот ты в … низу лидерборда. Ничего, надо просто собраться, понять где и что ты упустил — переделать свое решение — и вернуться на место.

Тем более, что этот момент будет присутствовать только на ранней стадии вашего соревновательного процесса. Чем опытнее вы станете — тем меньше на вас будут оказывать влияние выложенные кернелы и звезды. В одном из последних соревнований (Talking Data, в котором наша команда заняла 8-е место) тоже выложили такой кернел, но он удостоился всего одной строчки в нашем командном чате от Павла Плескова (ppleskov): "Парни, я заблендил его с нашим решением, стало только хуже — выбрасываем". То есть весь полезный сигнал, который вытаскивал из данных этот кернел был уже вытащен нашими моделями.

И еще насчет медалей — помните:

"пояс без техники нужен только для поддержания штанов"(С)

Где, на чем и как писать код.

Тут моя рекомендация — python 3.6 на jupyter notebook под ubuntu. Python уже давно стал стандартом де-факто в DS, учитывая наличие огромного количества библиотек и коммьюнити, jupyter, особенно с наличием jupyter_contrib_nbextensions очень удобен для быстрого прототипирования, анализа и обработки данных, ubuntu — удобна сама по себе, плюс часть обработки данных иногда проще делать в bash :)

После установки jupyter_contrib_nbextensions сразу рекомендую включить:

• Collapsible headings (очень помогает в организации блоков кода)
• Code folding (то же самое)
• Split cells (редко, но полезен если надо что-то дебажить в параллель)

И ваша жизнь станет намного проще и приятней.

Как только ваши пайплайны станут более-менее стабильными, код рекомендую сразу выносить в отдельные модули. Поверьте — переписывать его вы будете не раз и не два и даже не пять. Но — это нормально.

Есть прямо противоположный подход, когда участники стараются использовать jupyter notebook как можно реже и только в случае необходимости, предпочитая, сразу писать пайплайны скриптами. (адептом такого варианта является, например, (Владимир Игловиков (ternaus))

И есть те, кто пытается совместить jupyter с какой-либо IDE, например pycharm.

Каждый подход имеет право на жизнь, в каждом есть свои плюсы и минусы, как говорится "на вкус и цвет все фломастеры разные". Выбирайте то, в чем вам удобно работать.

Но при любом варианте возьмите за правило

сохранять код для каждого сделанного сабмита/OOF (см.ниже).

(*) OOF — out of folds, техника получения предсказаний модели для тренировочной части датасета используя кросс-валидацию. Незаменима для дальнейшей сборки нескольких решений в ансамбль. Преподается опять же на курсах или легко гуглится.

Как? Ну тут есть как минимум три варианта:

• Для каждого соревнования создается отдельный репозиторий на гитхабе или битбакете и код для каждого сабмита коммитится в репозиторий с комментарием, в котором содержится полученный скор, параметры модели, и т.д.
• Код каждого сабмита собирается в отдельный архив, с именем файла, в котором указана вся метаинформация сабмита (тот же скор, параметры, и т.д.)
• Используется система контроля версий заточенная именно под DS/ML. Например https://dvc.org.

В целом, в коммьюнити существует тенденция постепенного перехода на третий вариант, т.к. и первый и второй имеют свои недостатки, но зато они просты, надежны и, честно говоря, для Kaggle их вполне хватает.

Да, еще про python для тех, кто не программист — не бойтесь его. Ваша задача понять основные структуры кода и базовую суть языка, чтобы разобраться в чужих кернелах и написать свои библиотеки. В Сети много хороших курсов для начинающих, возможно в комментариях подскажут где именно. К сожалению (или к счастью) не могу оценить качество таких курсов, поэтому ссылок в статье не привожу.

Итак, переходим к фреймворку

Примечание

Все дальнейшее описание будет основано на работе с табличными и текстовыми данными. Картинки, которых сейчас очень много на Kaggle — это отдельная тема с отдельными фреймворками. На базовом уровне хорошо уметь их обрабатывать, хотя бы для того, чтобы прогнать через что-то типа ResNet/VGG и вытащить фичи, но более глубокая и тонкая работа с ними — это отдельная и очень обширная тема, не рассматриваемая в рамках данной статьи.

Автор честно признается, что не очень умеет в картинки. Единственная попытка приобщиться к прекрасному была в соревновании Camera Identification, в котором, кстати, наши команды с тегом [ods.ai] взорвали весь лидерборд до такой степени, что админам Kaggle пришлось зайти к нам в слак в гости, убедиться, что все в рамках правил — и успокоить коммьюнити. Так вот, в этом соревновании мне досталось почетное серебро с 46-м местом, а когда прочитал описание топовых решений от наших коллег, то понял, что забраться выше и не светит — там у них применяется реально черная магия с аугментацией, добросом 300Гб данных, жертвоприношениями и прочим.

В общем если хотите начинать с картинок — то вам нужны другие фреймворки и другие руководства.

Основная цель

Ваша задача написать пайплайны (оформленные в виде jupyter notebooks + модули) для следующих задач:

• EDA (exploratory data analysis). Тут надо сделать замечание — на Kaggle есть специально обученные люди :), которые в каждом соревновании пилят сногсшибательные EDA кернелы. Переплюнуть их у вас вряд-ли получится, но понимать, как можно смотреть на данные все-равно придется, т.к. В боевых задачах этим специально обученным человеком будете вы. Поэтому изучаем подходы, расширяем наши библиотеки.
• Data Cleaning — все, что касается очистки данных. Выбросы, пропуски, и т.д.
• Data preparation — все, что касается подготовки данных для модели. Несколько блоков:
  
  • Общий
  • Для регрессий/нейронных сетей
  • Для деревьев
  • Специальный (временные ряды, картинки, FM/FFM)
  • Текст (Vectorizers, TF-IDF, Embeddings)
• Models
  
  • Linear models
  • Tree models
  • Neural Networks
  • Exotic (FM/FFM)
• Feature selection
• Hyperparameters search
• Ensemble

В кернелах обычно все эти задачи собраны в единый код, что и понятно, но очень рекомендую для каждой из этих подзадач завести отдельный ноутбук и отдельный модуль (набор модулей). Так вам потом будет проще.

Предупреждая возможный холивар — структура данного фреймворка не истина в последней инстанции, есть много других способов структурировать свои пайплайны- это всего лишь один из них.

Данные передаются между модулями либо в виде CSV, либо feather/pickle/hdf — что вам удобнее и к чему вы привыкли или лежит душа.

На самом деле много еще зависит и от количества данных, в TalkingData, например, пришлось идти через memmap, чтобы обойти нехватку памяти при создании датасета для lgb.

В остальных случаях — основные данные хранятся в hdf/feather, что-то маленькое (типа набора выбранных атрибутов) — в CSV. Повторюсь — шаблонов нет, кто к чему привык, с тем и работайте.

Начальный этап

Идем в любое Getting started соревнование (как уже упоминалось, автор начинал с House Prices: Advanced Regression Techniques), и начинаем создавать наши ноутбуки. Читаем паблик кернелы, копируем куски кода, процедуры, подходы, и т.д. и т.п. Прогоняем данные через пайплайн, сабмитим — смотрим на результат, улучшаем и так по кругу.

Задача на данном этапе — собрать эффективно работающий пайплайн полного цикла — от загрузки и очистки данных до финального сабмита.

Примерный список того, что должно быть уже готовым и работающим на 100% перед переходом к следующему этапу:

• EDA. (статистики по датасету, боксплоты, разброс категорий, ...)
• Data Cleaning. (пропуски через fillna, чистка категорий, объединение категорий)
• Data preparation
  
  • Общий (обработка категорий — label/ohe/frequency, проекция числовых на категории, трансформация числовых, бининг)
  • Для регрессий (различное масштабирование)
• Models
  
  • Linear models (различные регрессии — ridge/logistic)
  • Tree models (lgb)
• Feature selection
  
  • grid/random search
• Ensemble
  
  • Regression / lgb

Идем в бой

Выбираем любое понравившееся соревнование и … начинаем :)

• Смотрим на данные, читаем форумы и строим устойчивую схему валидации. Не будет нормальной схемы — будете летать на лидерборде, как в соревнованиях от Mercedes, Santander и прочих. Посмотрите на лидерборд Mercedes, например (зеленые стрелочки и цифры означают на сколько позиций народ поднялся в лидерборде по сравнению с пабликом, красные — на сколько улетел вниз):

  
  

  Также рекомендую почитать статью и выступление Данилы Савенкова (danila_savenkov):

  
  

  Также данная тема хорошо освещена в курсе How to Win a Data Science Competition: Learn from Top Kagglers"

  
  

Пока нет рабочей валидационной схемы — дальше не идем!!!

• Прогоняем данные через наш сформированный пайплайн и сабмитим результат
• Хватаемся за голову, психуем, успокаиваемся… и продолжаем…
• Читаем все кернелы на предмет использованных техник и подходов
• Читаем все обсуждения на форуме
• Переделываем/дополняем пайплайны новыми техниками
• Переходим к п. 1

Помним — наша цель на данном этапе — получить опыт! Наполнить наши пайплайны рабочими подходами и методами, заполнить наши модули работающим кодом. Не заморачиваемся на медалях — вернее как, здорово, если получится сразу занять свое место на лидерборде, но если нет — не паримся. Мы пришли сюда не на пять минут, медали и плашки никуда не уйдут.

Вот соревнование закончено, вы где-то там, казалось бы все — хватаемся за следующее?

НЕТ!

Что вы делаете дальше:

• Ждете пять дней. Не читайте форум, забудьте про Kaggle на это время. Дайте мозгу отдохнуть и размылить взгляд.
• Возвращаетесь к соревнованию. За эти пять дней по правилам хорошего тона все топы выложат описание своих решений — в постах на форуме, в виде кернелов, в виде гитхабовских репозиториев.

И тут начинается ваш персональный АД!

• Вы берете несколько листов формата А4, на каждом пишете название модуля из вышеописанного фреймворка (EDA/ Preparation/ Model/ Ensemble/ Feature selection/ Hyperparameters search/ ...)
• Последовательно читаете все решения, выписываете на соответствующие листочки новые для вас техники, методы, подходы.

И самое страшное:

• Последовательно по каждому модулю пишете (подсматриваете) реализацию этих подходов и методов, расширяя ваш пайплайн и библиотеки.
• В режиме пост-сабмита прогоняете данные через ваш обновленный пайплайн до тех пор, пока у вас не будет решения в золотую зону ну или пока не кончится терпение и нервы.

И вот только после этого переходим к следующему соревнованию.

Нет, я не охренел. Да, можно и проще. Вам решать.

Почему ждать 5 дней, а не читать сразу, ведь на форуме можно позадавать вопросы? На данном этапе (на мой взгляд) лучше читать уже сформированные треды с обсуждениями решений, вопросы, которые у вас могут возникнуть — либо кто-то уже задаст, либо их лучше пока вообще не задавать, а искать ответ самим )

Зачем все это делать именно так? Ну, еще раз — задача данного этапа наработать базу решений, методов и подходов. Боевую рабочую базу. Чтобы в следующем соревновании вы не тратили время, а сразу сказали — ага, тут может зайти mean target encoding, и кстати, у меня и правильный код для этого через фолды в фолдах есть. Или о! помнится тогда заходил ансамбль через scipy.optimize, а кстати у меня и код уже готов.

Как-то так...

Выходим на рабочий режим

В таком режиме решаем несколько соревнований. С каждым разом замечаем, что записей на листках становится все меньше и меньше, а кода в модулях все больше и больше. Постепенно задача анализа сводится к тому, что вы просто читаете описание решения, говорите ага, ого, ах вот оно как! И добавляете в себе в копилку одно-два новых заклинания или подхода.

После этого режим меняется на режим работы над ошибками. База у вас уже готова, теперь ее просто надо правильно применять. После каждого соревнования, читая описание решений, смотрите — что вы не сделали, что можно было сделать лучше, что вы упустили, ну или где вы конкретно лажанулись, как у меня случилось в Toxic. Шел достаточно хорошо, в подбрюшье золота, а на private улетел вниз на 1500 позиций. Обидно до слез… но успокоился, нашел ошибку, написал пост в слаке — и выучил урок.

Признаком окончательного выхода на рабочий режим может служить тот факт, что одно из описаний топового решения будет написано от вашего никнейма.

Что примерно должно быть в пайплайнах к концу данного этапа:

• Всевозможные варианты предобработки и создания числовых фичей — проекции, отношения,
• Различные методы работы с категориями — Mean target encoding в правильном варианте, частоты, label / ohe,
• Различные схемы ембеддингов над текстом (Glove, Word2Vec, Fasttext)
• Различные схемы векторизации текста (Count, TF-IDF, Hash)
• Несколько валидационных схем (N*M для стандартной кросс-валидации, time-based, by group)
• Bayesian optimization / hyperopt / что-то еще для подбора гиперпараметров
• Shuffle / Target permutation / Boruta / RFE — для отбора фич
• Линейные модели — в едином стиле над одним набором данных
• LGB/XGB/Catboost — в едином стиле над одним набором данных

Автор сделал метаклассы отдельно для линейных и tree-based моделей, с единым внешним интерфейсом, чтобы нивелировать различия в API у разных моделей. Зато теперь можно в едином ключе одной строчкой запускать, например, LGB или XGB над одним обработанным набором данных.

• Несколько нейронных сетей на все случаи жизни (не берем пока картинки) — embeddings/CNN/RNN для текста, RNN для последовательностей, Feed-Forward для всего остального. Хорошо еще понимать и уметь автоенкодеры.
• Ансамбль на базе lgb/regression/scipy — для задач регрессии и классификации
• Хорошо еще уже уметь Genetic Algorithms, иногда они хорошо заходят

Подытожим

Любой спорт, а соревновательный DS — это тоже спорт, это много-много пота и много-много работы. Это не хорошо и не плохо, это факт. Участие в соревнованиях (если грамотно подойти к процессу) очень хорошо прокачивает технические скиллы, плюс более-менее качает спортивный дух, когда очень не хочется что-то делать, прямо ломает всего — но встаешь к ноутбуку, переделываешь модель, запускаешь на обсчет, чтобы таки выгрызть этот несчастный 5-й знак после запятой.

Так что решайте Kaggle — фармите опыт, медали и фан!

Пара слов про пайплайны автора

В этом разделе попробую описать основную идею собранных за полтора года пайплайнов и модулей. Опять же — данный подход не претендует на универсальность или уникальность, но вдруг кому поможет.

• Весь код по фиче-инжинирингу, кроме mean target encoding, вынесен в отдельный модуль в виде функций. Пробовал собирать через объекты, получилось громоздко, да и в данном случае и не надо.
• Все функции фиче-инжиниринга выполнены в едином стиле и имеют единую сигнатуру вызова и возврата:

def do_cat_dummy(data, attrs, prefix_sep='_ohe_', params=None):
        # do something
        return _data, new_attrs

На вход передаем датасет, атрибуты для работы, префикс для новых атрибутов и дополнительные параметры. На выходе получаем новый датасет с новыми атрибутами и список этих атрибутов. Далее это новый датасет сохраняется в отдельный pickle/feather.

Что это дает — мы получаем возможность быстро собрать датасет для обучения из предсгенеренных кубиков. Например для категорий делаем сразу три обработки — Label Encoding / OHE / Frequency, сохраняем в три отдельных feather, и далее на этапе моделирования просто играемся этими блоками, одним элегантным движением создавая различные датасеты для обучения.

    pickle_list = [
        'attrs_base',
        'cat67_ohe',
    #    'cat67_freq',
    ]
    short_prefix = 'base_ohe'

    _attrs, use_columns, data = load_attrs_from_pickle(pickle_list)
    cat_columns = []

Если надо собрать другой датасет — меняем pickle_list, перезагружаем, и работаем с новым датасетом.

Основной набор функций над табличными данными (вещественными и категориальными) включает в себя различное кодирование категорий, проекцию числовых атрибутов на категориальные, а также различные трансформации.

    def do_cat_le(data, attrs, params=None, prefix='le_'):
    def do_cat_dummy(data, attrs, prefix_sep='_ohe_', params=None):
    def do_cat_cnt(data, attrs, params=None, prefix='cnt_'):
    def do_cat_fact(data, attrs, params=None, prefix='bin_'):
    def do_cat_comb(data, attrs_op, params=None, prefix='cat_'):
    def do_proj_num_2cat(data, attrs_op, params=None, prefix='prj_'):

Универсальный швейцарский нож для комбинирования атрибутов, в который передаем список исходные атрибутов и список функций преобразования, на выходе получаем, как обычно, датасет и список новых атрибутов.

    def do_iter_num(data, attrs_op, params=None, prefix='comb_'):

Плюс разные дополнительные специфические преобразователи.

Для обработки текстовых данных используется отдельный модуль, включающий в себя различные методы препроцессинга, токенизации, лемматизирования/стемминга, перевода в частотную таблицу, ну и т.д. и т.п. Все стандартно, используя sklearn, nltk и keras.

Временные ряды обрабатываются также отдельным модулем, с функциями преобразования исходного датасета как для обычных задач (регрессии/классификации), так и для sequence-to-sequence. Спасибо Francois Chollet, что допилил таки keras, чтобы построение моделей seq-2-seq не походило на вудуистский ритуал вызова демонов.

В том же модуле, кстати, находятся и функции обычного статистического анализа рядов — проверка на стационарность, STL-декомпозиция, и т.д… Очень помогает на начальном этапе анализа, чтобы "пощупать" ряд и посмотреть что он вообще такое.

• Функции, которые нельзя применить сразу ко всему датасету, а нужно использовать внутри фолдов при кросс-валидации вынесены в отдельный модуль:

  
  
  • Mean target encoding
  • Upsampling / Downsampling
  
  

  Они передаются внутрь класса модели (про модели читай ниже) на этапе обучения.

  
  

    _fpreproc = fpr_target_enc
    _fpreproc_params = fpr_target_enc_params

    _fpreproc_params.update(**{
        'use_columns' : cat_columns,
    })

• Для моделирования создан метакласс, обобщающий понятие модель, с абстрактными методами: fit/predict/set_params/ и т.д. Для каждой конкретной библиотеки (LGB, XGB, Catboost, SKLearn, RGF, ...) создана реализация этого метакласса.

То есть для работы с LGB мы создаем модель

    model_to_use = 'lgb'
    model = KudsonLGB(task='classification')

Для XGB:

    model_to_use = 'xgb'
    metric_name= 'auc'
    task='classification'

    model = KudsonXGB(task=task, metric_name=metric_name)

И все функции далее оперируют с model.

• Для валидации создано несколько функций, сразу считающих и предсказание и OOF для нескольких сидов при кросс-валидации, а также отдельная функция для обычной валидации через train_test_split. Все функции валидации оперируют методами мета-модели, что дает моделе-независимый код и облегчает подключение к пайплайну любой другой библиотеки.

  
  

  res = cv_make_oof(
  model, model_params, fit_params, dataset_params, XX_train[use_columns], yy_train, XX_Kaggle[use_columns], folds, scorer=scorer, metric_name=metric_name, fpreproc=_fpreproc, fpreproc_params=_fpreproc_params,  model_seed=model_seed, silence=True
  )
  score = res['score']

  
  

• Для feature selection — ничего интересного, стандартный RFE, и мои любимые shuffle permutation во всех возможных вариантах.

  
  

• Для поиска гиперпараметров в основном используется Bayesian optimization, опять же в унифицированном виде для того, чтобы можно было запустить поиск для любой модели (через модуль кросс-валидации). Этот блок живет в том же ноутбуке, что и моделирование.

  
  

• Для ансамблей сделано несколько функций, унифицировано для задач регрессии и классификации на базе Ridge/Logreg, LGB, Neural network и моего любимого scipy.optimize.

  
  

  Небольшое пояснение — каждая модель из пайплайна выдает в качестве результата два файла: sub_xxx и oof_xxx, представляющих собой предсказание для теста и OOF предсказание для трейна. Далее в модуле ансамбля из указанной директории загружаем пары предсказаний от всех моделей в два датафрейма — df_sub / df_oof. Ну а дальше уже смотрим на корреляции, отбираем лучшие, потом строим модели 2-го уровня над df_oof и применяем к df_sub.

  
  

  Иногда для поиска лучшего поднабора моделей хорошо заходит поиск генетическими алгоритмами (автор использует эту библиотеку), иногда — метод от Caruana. В простейших случаях прекрасно работают стандартные регрессии и scipy.optimize.

  
  

• Нейронные сети живут в отдельном модуле, автор использует keras в функциональном стиле, да, не так гибко как pytorch, но пока хватает. Опять же написаны универсальные функции для тренировки, инвариантные к типу сети.

  
  

Данный пайплайн был в очередной раз протестирован в недавнем соревновании от Home Credit, внимательное и аккуратное применение всех блоков и модулей принесло 94-е место и серебро.

Автор вообще готов высказать крамольную мысль, что для табличных данных и нормально сделанного пайплайна финальный сабмит на любом соревновании должен влетать в топ-100 лидерборда. Естественно есть исключения, но в целом данное утверждение, похоже, что верно.

Про командную работу

Тут не все так однозначно, решать Kaggle в команде или соло — во многом зависит от человека (и от команды), но мой совет для тех, кто только начинает — попробуйте начать соло. Почему? Попробую объяснить свою точку зрения:

• Во-первых вы поймете свои силы, увидите слабые места и, в целом, сможете оценить свой потенциал как DS практика.
• Во-вторых даже работая в команде (если только это не устоявшаяся команда с разделением ролей), от вас все-равно будут ждать готового законченного решения — то есть рабочие пайплайны у вас уже должны быть. ("Сабмит или не было") (С)
• Ну и в третьих, оптимально, когда уровень игроков в команде примерно одинаков (и достаточно высок), тогда можно научиться чему-нибудь действительно высокоуровнево-полезному ) В слабых командах (тут нет ничего уничижительного, я про уровень подготовки и опыт на Kaggle) imho очень сложно чему-нибудь научиться, лучше грызть форум и кернелы. Да, можно фармить медальки, но см. Выше про цели и пояс для поддержания штанов )

Полезные советы от капитана очевидность и обещанная карта грабель :)

Приведенные советы отражают опыт автора, не являются догмой, и могут (и должны) проверяться собственными экспериментами

• Всегда начинайте с построения грамотной валидации — не будет ее, все остальные усилия улетят в топку. Еще раз посмотрите на лидерборд Mercedes.

  
  

  Автор реально доволен тем, что в этом соревновании построил устойчивую схему кросс-валидации (3x10 фолдов), которая сохранила скор и принесла законное 42-е место )

  
  

• Если построена грамотная валидация — всегда доверяйте результатам вашей валидации. Если скор ваших моделей улучшается на валидации, но ухудшается на паблике — разумнее доверять валидации. При анализе просто считайте тот кусок данных, на котором считается паблик лидерборд еще одним фолдом. Вы же не хотите заоверфитить вашу модель на один фолд?

  
  

• Если модель и схема позволяет — всегда делайте OOF предсказания и сохраняйте рядом с моделью. На этапе ансамбля никогда не знаешь что выстрелит.

  
  

• Всегда сохраняйте рядом с результатом/OOF код для их получения. Неважно на гитхаб, локально, куда угодно. Два раза у меня получалось, что в ансамбле лучшая модель та, которая была сделана две недели назад "из коробки", и для которой не сохранилось кода. Боль.

  
  

• Забейте на подбор "правильного" сида для кросс-валидации, сам грешил этим сначала. Лучше выберите три любых и сделайте 3хN кросс-валидацию. Результат будет стабильнее и проще.

  
  

• Не гонитесь за количеством моделей в ансамбле — лучше меньше, но разнообразнее — разнообразнее по моделям, по предобработке, по датасетам. В худшем случае — по параметрам, например одно глубокое дерево с жесткой регуляризацией, одно неглубокое.

  
  

• Для отбора фич используйте shuffle / boruta / RFE, помните, что feature importance в различных tree-based моделях — это метрика в попугаях на мешок опилок.

  
  

• Личное мнение автора (может и не совпадать с мнением читателя) Bayesian optimization > random search > hyperopt для подбора гиперпараметров.

  
  

• Выложенный на паблик рвущий лидерборд кернел лучше обрабатывать так:

  
  
  • Есть время — смотрим что там нового и встраиваем себе
  • Меньше времени — переделываем его на нашу валидацию, делаем OOF — и пристегиваем к ансамблю
  • Совсем нет времени — тупо блендим с нашим лучшим решением и смотрим скор.
  
  

• Как выбирать два финальных сабмита — по интуиции, естественно. Ну а если серьезно, то обычно все практикуют следующие подходы:

  
  
  • Консервативный сабмит (на устойчивых моделях) / рискованный сабмит.
  • С лучшим скором на OОF / на паблик лидерборде
  
  

• Помните — все есть цифра и возможности ее обработки зависят только от вашего воображения. Используйте классификацию вместо регрессии, рассматривайте последовательности как картинку, и т.д.

  
  

Ну и напоследок:

• Вступайте в ods.ai :) общайтесь и получайте фан от DS и от жизни! )

Полезные ссылки

Общие

http://ods.ai/ — для тех, кто хочет присоединиться к лучшему DS коммьюнити :)
https://mlcourse.ai/ — сайт курса ods.ai
https://www.Kaggle.com/general/68205 — пост про курс на Kaggle

В целом еще очень рекомендую в том же режиме, что описан в статье, просмотреть цикл видео mltrainings — много интересных подходов и техник.

Видео

• очень хорошее видео про то как стать грандмастером :) от Павла Плескова (ppleskov)
• видео про hacking, нестандартный подход и mean target encoding на примере соревнования BNP Paribas от Станислава Семенова (stasg7)
• Еще одно видео со Станиславом "Чему учит Kaggle"

Курсы

Более подробно методы и подходы к решению задач на Kaggle можно узнать из второго курса специализации, "How to Win a Data Science Competition: Learn from Top Kagglers"

Внеклассное чтение:

• Laurae++, XGBoost/LightGBP parameters
• FastText — ембеддинги для текста от Facebook
• WordBatch/FTRL/FM-FTRL — набор библиотек от @anttip
• Еще одна реализация FTRL
• Bayesian Optimization — библиотека для подбора гиперпараметров
• Regularized Greedy Forest (RGF) library — еще один tree метод
• A Kaggler's Guide to Model Stacking in Practice
• ELI5 — прекрасная библиотека для визуализации весов моделей от Константина Лопухина (kostia)
• Feature selection: target permutations — и походите по ссылкам внутри
• Feature Importance Measures for Tree Models
• Feature selection with null importance
• Кратко про автоенкодеры
• Презентация на тему Kaggle на slideshare
• И еще одна
• И вообще там много всего интересного
• Winning solutions of kaggle competitions
• Data Science Glossary on Kaggle

Заключение

Тема Data Science в целом и соревновательный Data Science в частности, так же неисчерпаема, как и атом (С). В данной статье автор только слегка раскрыл тему прокачки практических скиллов используя соревновательные платформы. Если стало интересно — подключайтесь, осматривайтесь, копите опыт — и пишите свои статьи. Чем больше хорошего контента, тем всем нам будет лучше!

Предвосхищая вопросы — нет, пайплайны и библиотеки автора пока не выложены в свободный доступ.

Огромная благодарность коллегам из ods.ai: Владимиру Игловикову (ternaus), Юрию Кашницкому (yorko), Валерию Бабушкину (venheads), Алексею Пронкину (pronkin_alexey), Дмитрию Петрову (dmitry_petrov), Артуру Кузину (n01z3), а также всем, кто вычитывал статью перед публикацией, за правки и рецензии.

Отдельная благодарность Никите Завгородному (njz) — за финальную корректуру.

Спасибо за внимание, надеюсь эта статья будет кому-нибудь полезна.

Мой ник в Kaggle / ods.ai: kruegger