Недавно завершилось соревнование «OneTwoTrip Contest» на платформе Boosters. Здесь представлено некоторое саммари результатов.
Концепция
Не смотря на то, что соревнования по анализу данных сейчас проводятся часто и на многих платформах, объективно пользы от них меньше, чем хотелось бы. Например, возьмём «пользу в виде обучения» (даже не будем трогать пользу для бизнес-заказчика, организатора и т.п.) Часто бывает много открытого кода (например, Kaggle-ноутбуки) и обсуждений в форумах. Однако они как-то упорядочиваются лишь лайками/качеством результата/популярностью, в них надо разбираться, и всё это изначально не учебные материалы. В идеале, после каждого соревнования надо иметь сборник рецептов: 1) как надо было делать, 2) как не надо было делать, хотя многие совершили эту ошибку, 3) что подходит для широкого класса подобных задач, 4) в чём специфика именно данной задачи. Есть много вариантов, как такие сборники составлять… здесь я представлю «лайтовый» — как его сделать организаторам, не напрягаясь, в виде опроса.
Чтобы в опросе приняло участие больше людей, вопросы должны быть необременительные и чёткие, их должно быть немного (также надо выдавать толстовки с символикой соревнования только прошедшим опрос ;). Чтобы от опроса была польза, он должен «делаться под задачу» (надо спрашивать о том, чему из данной задаче можно научиться).
Да, конечно, после соревнований мы ещё можем послушать выступления победителей или просто успешных участников (если они где-нибудь выступают). Это, конечно, большой плюс, но мы слышим только успешных (т.е. «как надо было делать») и не особо понимаем разницу между хорошими и плохими решениями.
Соревнование
Соревнование состояло из двух задач, здесь пойдёт речь лишь про первую — бинарную классификацию с функционалом качества ROC AUC и простыми табличными данными. Во второй было пять целевых переменных и, в некотором смысле, меньше данных, но, в целом, она не была сложнее более популярной первой. Все признаки были анонимизированы, но смысл почти всех легко угадывался (особенно благодаря активному чату, посмотреть и лайкнуть EDA-ноутбуки Ильи Свиридова можно здесь).
В турнирной таблице 372 участника, из них только 25 заполнили опрос . На рис. 1 показано распределение мест участников опроса.

Какой бустинг лучше
Очень хотелось проверить, соответствует ли авторское видение «хорошести» современных библиотек машинного обучения реальности. Вот одна из возможностей проверить — спросить, кто чем пользуется и насколько успешно.
Самая популярная библиотека для работы с табличными данными — LightGBM, см. рис. 2, с большим отрывом отстаёт XGBoost, не больше 20% опрошенных пытались возиться с другими реализациями бустинга и нейронными сетями. Забавно, что недавно появившийся NGBoost никого не заинтересовал (ну он и правда не впечатляет).

Популярность объясняется, в том числе, и качеством полученных решений (рис. 3) — лучшие модели строились с помощью LightGBM, все опрошенные, преодолевшие порог 0.71 AUC настраивали LightGBM или XGBoost.

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

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

Несколько моделей от первой тройки призёров:
lightgbm.LGBMClassifier(boosting_type='gbdt', learning_rate = 0.005, num_leaves = 31, bagging_fraction = 0.7, feature_fraction = 0.6, min_data = 200, nrounds = 1968)
Xgbclassifier(max_depth=6, learning_rate=0.007, n_estimators=3000, reg_lambda=5.5, reg_alpha=1.2)
lightgbm.LGBMClassifier(boosting_type='gbdt', learning_rate=0.35, min_data_in_leaf=898, n_estimators=200, reg_lambda=0.01, reg_alpha=1.4)
На рис. 6 показано, как делали локальную валидацию. В данных был признак «user_id» — номер пользователя, причём в тесте пользователи отличались от пользователей из обучения. Логично было проводить локальную валидацию так же, чтобы алгоритм ничего не знал о пользователях из валидационной выборки, но многие этим пренебрегли, также как и сохранением пропорций классов. Также очень мало людей делали многократную валидацию — когда каждый объект несколько раз попадает в валидационную выборку. Не все валидируются по фолдам, некоторые предпочитают случайные разбиения выборки.

Отбор признаков
Для оценки важности признаков большинство использует встроенные feature_importance (в тот же самый LightGBM), 20% вычисляют перестановочную важность (permutation importance), также 20% используют специальные библиотеки (типа SHAP), см. рис. 7.

60% респондентов автоматизировали генерацию признаков, например автоматически составляли алгебраические выражения над признаками, 88% — занимались ручной генерацией признаков. Понятно, что это не взаимоисключающие процессы. Изначально в задаче было 43 признака (на рис. 8 это соответствует тонкой чёрной линии). Уменьшение числа признаков оказалось плохой стратегией, у большинства из Top-10 число признаков около 100.

Занятость
Наконец, интересный вопрос — как много времени тратят на соревнование участники. На рис. 9 показана зависимость времени (в часах) от итогового места. Если каждый день выделять по 4 часа на соревнование, то получается, что довольно большой процент участников решали задачу больше 10 дней, а чуть меньше трети — почти месяц…

Спасибо всем, кто участвовал в опросе: аутсайдер, студент ММП, желающий работать в ДС, выпускник Нетологии, безработная преподавательница, ещё один безработный, хороший парень, падаван, KaggleMaster из Mail.Ru, новичок в соревнованиях, к.ф-м.н на удалённой работе, квант, биолог, участник с отрывом на LB, гусь на Кэгле, тот, кто только учится, скорингист для МФО, оверфиттер стекинга, энтузиаст, поклонник курса Эндрю Ына, гидродинамик, джун рабблса с матфака ВШЭ.
Звезда 🌟
Отличный пост. Спасибо. Действительно, очень интересно такую статистику по соревнованиям подсчитывать.