Привет! Как и было обещано в предыдущем посте про Why So Serious Hack, мы подготовили следующий рассказ в этой серии. В этот раз речь пойдет про хакатон «Муниципальные мойры», который проводился 21-22 апреля Европейским университетом в Санкт-Петербурге.
Введение
Так совпало, что этот хакатон тоже был необычным и очень похожим на Why So Serious Hack. Но это неудивительно, учитывая что организаторы пересекались, а за техническую часть обоих мероприятий и вовсе отвечал один и тот же человек. Поэтому мы и решили написать о нем сейчас, пока свежи наши воспоминания о хакатоне, а ваши о предыдущем посте.
Но для тех, кто не читал предыдущую статью, повторюсь про формат таких соревнований. На них не нужно придумывать и реализовывать идею своего проекта. Вместо этого участникам соревнования задаются вопросы по анализу данных, с ответом на которые они должны выступить по истечению 24-48 часов.
Помимо вопросов, организаторы предоставляют данные, на которых предлагается обучать модели, предсказывающие те или иные целевые значения. Зная точность модели на закрытой тестовой выборке, можно проверять гипотезы относительно исходных данных. Это и помогает участникам понять, в какую сторону думать, и может подтвердить полученные выводы, при условии хорошей точности.
Качество своих моделей можно проверить с помощью проверяющей системы. Нет, не на kaggle, как многие из вас скорее всего предположили, а с помощью бота в telegram! А место в лидерборде не определяет победителя, а влияет на порядок выступления команд. Лучше скор — раньше презентация. Призовое место назначается жюри на основании глубины, качества, оригинальности и проработанности ответа команды на вопрос. Но об этом всем подробнее расскажу немного дальше.
Организация хакатона
Как и в прошлый раз, начнем с пары слов о том, как организовывался хакатон.
Мероприятие проходило в здании Европейского Университета. К сожалению, специально отведенных мест для ночевки не было, но поскольку хакатон длился 30 часов, то это не было большой проблемой. Полноценного питания на площадке тоже не было, однако организаторы предоставили комнату с чаем, кофе, пирогами и печеньками. Звучит это все не как описание топового хакатона, но зная текущую сложную сложившуюся ситуацию у ЕУСПб, им можно это все простить.
Призовой фонд составлял 100 000 руб, и его могла получить только одна команда.
Кейс и решение
Команда центра Res Publica ЕУСПб, организующая мероприятие, проводит исследование качества муниципального управления и его динамику в России с 2007 по 2018.
Так что участникам хакатона предстояло ответить на вопрос, от чего зависит ход карьеры глав городов и районов. Предполагается, что отставка главы муниципального образования — это показатель неэффективности его работы, а карьерное продвижение на вышестоящие уровни — наоборот. На наш взгляд, это логично и так должно быть на самом деле (спойлер: нет).
В качестве данных для предсказания карьерных траекторий чиновников, предлагалось использовать их биографических данные, а также различные показатели из базы данных муниципальных образований. Например, общее состояние дорог или число больниц.
У участников была история глав муниципалитетов за 18-летний период. Каждая запись в датасете рассказывала о состоянии карьеры главы в какой-то определенный год, а именно содержала следующие поля: год и регион работы, муниципальное образование, название должности, пол и возраст человека, уровень и сфера образования, текущее состояние карьеры и другие.
Данные были анонимизированы, но при желании, их можно было восстановить. Такое считалось за нарушение правил и каралось дисквалификацией.
Самым интересным полем здесь является состояние карьеры, так как именно это поле и нужно было предсказывать. Состояние карьеры главы описывается не только тремя значениями («назначили на должность», «работает», «уволили с должности»), которые было бы логично предположить, но куда более разнообразным и детальным набором. Например, глава МО мог уйти с должности по состоянию здоровья, или в связи с заведенным на него уголовным делом. Всего таких категорий было 13.
Типичный пример карьерной траектории главы:
Поскольку некоторые читатели предыдущего поста просили больше технических моментов, то мы расскажем немного и про них.
Сначала уточню, что нужно было предсказывать карьерные траектории не на будущие года, а для других кандидатов, живущих параллельно. Но на наш взгляд, это куда более скучная задача, чем предсказание будущего. Однако, правила устанавливает организатор.
Мы остановились на one-vs-rest модели, то есть когда для каждого класса мы строим отдельный классификатор. В качестве ответа для сэмпла выбираем тот класс, чья модель более уверена в принадлежности примера этому класса.
Немного поизучав данные, мы обратили внимание на периодичность появления категории “победа в выборах” в зависимости от года. На картинке хорошо видны пики в каждый пятый год. И это кажется довольно логичным, если большинство кандидатов часто выбирают на 5 следующих лет.
Далее, мы решили посмотреть, как распределены категории в зависимости от региона. Чтобы получить картинку ниже, мы сначала отнормировали все по столбцам, а потом по строкам.
Из хитмапы выше видно, что некоторые клетки сильно выделяются по сравнению с остальными. Например, в Республике Удмуртии должности устраняются сильно чаще, чем в других регионах. А в Ярославской области кандидаты часто переходят на другую работу.
Из-за наличия таких особенностей, мы решили добавить все эти признаки, то есть частоты классов по регионам. И это действительно помогло: взглянем на важность признаков в наших модельках и увидим, что частота играет самую важную роль.
Здесь приведены примеры для двух классов: переназначение и выход на пенсию, соответственно.
Еще из интересных технических моментов можно сказать про то, что дополнительная база с данными о муниципальных образованиях весила больше 30ГБ, поэтому можно было либо ее парсить, либо скачать на сервер, где бы хватало RAM для обработки.
Как я уже упомянул выше, тестирование проводилось с помощью специального бота в telegram. Участник отсылает ему свои ответы, а бот возвращает значение оценивающей метрики и позицию команды в таблице результатов. То есть результаты других команд никто не знает. Например, вот так это выглядело на этом соревновании:
Однако, если сильно захотеть, то можно немного схитрить, послав в систему не лучший свой результат и понять, насколько плотно команда снизу дышит вам в затылок.
Хочется упомянуть, почему у нас получается довольно маленькое значение F1 скора. Все дело в том, что у классов сильный дисбаланс. Одних очень много, других — мало. Поэтому предсказывая многие классы с хорошей точностью, а некоторые, которые встречаются в тесте всего пару раз, плохо, мы не получим впечатляющего значения метрики.
Кто-то может начать плеваться от того, мол почему бы не проводить такое соревнование на kaggle? Согласен, kaggle довольно приятная система. Однако тестирование с помощью бота выглядит не так пошло и обыденно, что придает соревнованию своей необычности.
И наверное, многие обратили внимание, что в хакатоне принимали участие всего 6 команд. И это очень грустно, ведь хакатон рекламировали в пабликах, разных чатах, но пришло всего около 20 участников. Так что победа не была особым челленджем, но поскольку мы пришли на него и получили определенный опыт, то почему бы о нем не рассказать?
Результаты
В конце хакатона были выступления команд. Мы презентовали свою работу первыми (слайды можно посмотреть тут). Из отрицательных моментов: жюри упомянуло, что рассказывали мы слишком техническим языком и некоторые термины были понятны только по контексту. Задумывайтесь об этом как при составлении слайдов, так и при репетиции речи.
Сразу же после рассказа, мы осознали одну важную ошибку. Несмотря на то, что победитель определяется не позицией на лидерборде, в этот раз мы почему-то слепо следовали цели: максимизировать скор, и потратили не очень много времени для составления полноценного ответа на вопрос: «Что же нужно делать, чтобы получить повышение?»
Жюри тоже считает, что не получила убедительного ответа, но судя по их отзыву, другие результаты тоже будут полезными. Кстати, это первый для нас хакатон, после которого попросили открыть доступ к коду и кратко описать решение и используемые признаки. Приятно, что результат может помочь кому-то в исследованиях этой области.
Как маленький и очевидный вывод, друзья: никогда не забывайте основную цель, которую преследуете, несмотря на уровень и масштабность мероприятия.
Пост написан совместно с avgaydashenko.
Автор: Yurii Rebryk
