Как мы участвовали в хакатоне от OpenData

в 16:41, , рубрики: data science, Linked data, open data, академический университет, анализ данных, Блог компании СПБАУ, кейс, машинное обучение, открытые данные, Хакатоны

Всем привет, в этой статье я хочу рассказать про Why So Serious Hack. Про то, что вообще нас туда привело, чем хакатоны в классическом понимании отличаются от хакатонов с контестом и что нам помогло выиграть.

image

Хакатон как контест

Давайте начнем с того, чем это мероприятие отличался от стандартного хакатона. На обычном хакатоне командам предлагается реализовать прототип некой идеи, на основе которой можно потом делать стартап.

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

Чем же это отличается от соревнования на kaggle, в таком случае? Тем, что важно не только добиться (или не добиться) лучшей точности, но и рассказать о проделанной работе: как исследовали данные, какие нашли интересные закономерности, почему было решено использовать те или иные алгоритмы.

Иногда еще интересна монетизация предложенного алгоритма: то есть зачем вообще в реальном мире могло понадобиться делать то, что было сделано. Поэтому, как советовали организаторы этого хакатона в пригласительном письме: “Не воспринимайте хакатон как соревнование по спортивному программированию. Несмотря на то, что творческие задания могут быть сформулированы очень конкретно, зачастую побеждают команды, вложившие душу в проект, переосмыслившие текст задания”. Думаю, нам удалось это сделать, и про это я тоже напишу.

Организация хакатона

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

Про сам хакатон мы узнали из ленты ВКонтакте, но несмотря на громкие заявления о том, что хакатон организовывают некое Открытое правительство, Университет ИТМО и Институт проблем правоприменения при Европейском университете, площадка была довольно маленькой, команд было тоже немного (5-6, насколько я помню).

Впрочем, также заявлялось, что стэк технологий хакатона это Linked Data, AI & ML. Про так называемые AI & ML все понятно: зашли деревья, а вот про Linked Data мы ничего не знали и интересно было попробовать, что же это такое. Так что мы собрались командой Академического Университета из пяти человек и решили принять участие.

Хакатон проходил на Васильевском острове, на базе университета ИТМО. Там неплохо (на мой взгляд и по сравнению с другими хакатонами) кормили: кушали мы в столовке ИТМО, где добрые хозяюшки рассказывали, с чем пирожки и салатики, которые можно взять. До столовки приходилось спускаться шесть этажей по крутым ступенькам старых петербургских домов, что позволяло размяться после часов, проведенных за ноутбуком. Но и на самой площадке был кофепоинт с фруктами и печеньками, за что тоже спасибо.

Кейс и решение

И давайте наконец к заданию, которое необходимо было выполнить. Вкратце, оно звучало так: предсказывать категорию риска предприятия по таким фичам как категория компании, ИНН, регион и так далее. Кстати, еще один плюсик в карму организаторов хакатона: проверка решения была организована через телеграм-бота (@WSSHackEvaluatorBot), который говорил только оценку засланного решения и место в общем зачете. Не было понятно, на каких местах остальные команды и с какими оценками. Такая вот интрига, не дающая расслабляться.

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

Так вот, когда видишь табличные данные, сразу думаешь, что вот есть стандартные способы их обрабатывать и фигачишь их. Конечно, это не взлетает. Данные нужно чистить и исправлять. Чистить надо было, например, случаи, когда в номере вместо цифры 0 была буква О, а исправлять случаи, когда длинная непонятная строчка вида “ЧАСТЬ 9 СТАТЬИ 9 ФЕДЕРАЛЬНОГО ЗАКОНА от 26.12.2008 N 294-ФЗ,2018-06-15<...>” означает на самом деле пожарную безопасность.

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

А теперь к самому интересному, к модели связанных данных (Linked Data), с которой мы познакомились на хакатоне. В самом начале, менторы сказали нам, что вот вам датасет, конечно, но скорее всего придется использовать открытые данные из других источников.

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

Возможно, тут возникнет вопрос, а как нам вообще пришло в голову добавлять именно эти фичи? Тут все просто. Во-первых, на хакатоне были менторы. И следующие мысли относятся вообще ко всем хакатонам.

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

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

Результаты

Впрочем, по точности предсказаний нас все-таки обошли классные ребята с мат-меха. Но презентация (опять же, по моему мнению) лучше была у нас. Но вы можете и сами прийти к этому или противоположному мнению, посмотрев доклады тут. Чуваки с мат-меха (red pandas) выступают первыми, мы (AU-Rocks) — вторыми.

Кстати, про названия: мы, выступая командой Академического Университета, всегда выбираем название команды с префиксом AU, red pandas делают похоже. Я считаю, это очень круто, когда приходишь на мероприятие, а там уже по названию команды можешь узнать знакомых людей, а они могут узнать тебя.

Так вот, обратно к презентациям. Мы выступили немного лучше, у ребят больше точность. Так что была такая интрига, кто же победит. И поскольку мы взяли приз, я считаю важным повторить мысль, которая и так часто высказывается в IT: даже самый классный проект или результат может быть не понят без хорошей презентации.

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

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

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

Пост написан совместно с avgaydashenko.

image

Автор: Rebryk

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js