Как мы участвовали в хакатоне по Data Science. Опыт команды «Япики»

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.
Мы — выпускники курса «Аналитик данных» в Яндекс.Практикуме — хотим рассказать о дебютном участии нашей команды «Япики» в онлайн-хакатоне Райффайзенбанка по Data Science. В статье мы поделимся своим первым опытом участия в подобного рода соревнованиях — расскажем о провалах, успехах и лайфхаках, которые помогли нам получить приз в номинации «Лучшее публичное решение».

Итоговое публичное решение команды доступно по ссылке.

Состав команды: Мадихан Агатанов, Арсен Бадоян, Оксана Головина, Анна Григорьева и Екатерина Илюшина.

Хакатон проходил в онлайн-формате с 24 по 26 сентября 2021 года при поддержке Russian Hackers.



Изначально на хакатон зарегистрировались 2177 человек, из которых участвовали 1510 человек. В общем счёте было 585 команд. На итоговом лидерборде отметились 371 команда — это те, кто сделал хотя бы один сабмит.

Чёткого распределения ролей в нашей команде не было. Роль капитана выпала Арсену. Он использовал демократический стиль управления командой. Многие идеи приходили спонтанно и сразу же запускались в работу, спорные — выносились на общее голосование. Дополнительным фактором стресса для части команды был выпускной проект Яндекс.Практикума, над которым они работали в то же время.

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

Задача хакатона и наши действия


Командам нужно было разработать алгоритм оценки стоимости коммерческой недвижимости. Банки выдают кредиты, в том числе под залог недвижимости. Для компании это страховка, а для клиента — возможность получить больше под меньший процент. Каждый объект залога оценивают: жилые — с помощью ИТ (например, SRG group или «Мобильного оценщика»), а вот коммерческие — вручную. Полноценный автоматизированный инструмент для оценки коммерческой недвижимости пока никто не анонсировал.

Сам хакатон состоял из двух частей: публичной (public score) и приватной (private score). Публичная часть состояла из открытой публикации решения для участия в отдельной номинации. По словам организаторов хакатона, мало кто открыто размещает свои решения: высок риск, что твои идеи будут использованы другими участниками для улучшения своих моделей. В итоге нас могли потеснить более сильные команды, которые получали весомое преимущество за счёт объединения или усреднения результатов нескольких решений.

До дедлайна публичной части оставалось чуть больше часа. На гитхабе было только несколько публичных решений, и мы входили в топ-10 в лидерборде по public score. Но всё могло измениться: в последнюю ночь хакатона большинство команд продолжали интенсивно работать и постоянно улучшали свои решения.

За час нам предстояло оформить решение в соответствии с правилами: код, сторонние датасеты, подробное описание в readme и краткий анонс в телеграм-чате хакатона. Мы распределили задачи и сконцентрировались на их выполнении: одна часть команды работала над описанием решения, другая — оформляла блок с EDA. Когда всё было готово, мы объединили обе части и загрузили наше решение. Нервы были на пределе, так как ещё возникали технические проблемы: Google Colab отказывался воспроизводить стандартные графики, библиотеки вступали в конфликт, у кого-то от перегрузки слетела anaconda. Ровно в 22:00 мы отправляем анонс нашего решения в чат. Организаторы хакатона решают продлить дедлайн публичной части до 22:30.

Одна часть команды, работавшая накануне допоздна над разведывательным анализом и baseline-решением, уходит отдыхать, а другая остаётся допиливать модель.

Утро было полно сюрпризов. За ночь наше решение на публичном ЛБ тихо сползает с 7-го до 53-го места. Оказалось, что наша идея с AutoML помогла многим командам значительно улучшить свои решения и дала прирост в скоре, а нам — дополнительные очки в конкурсе. Забегая вперёд, отметим, что команда BigSberBosses с моделью LightAutoML вошла в топ-10 на приватном лидерборде и заняла 9-е место. Кому-то оказались полезны датасеты со статистикой по населению и зарплатам, которые мы использовали для обогащения данных.

В итоге «Япики» получили приз в номинации «Лучшее публичное решение» — нам удалось обойти 23 кандидата!

Решение


Решение было представлено на основе LightAutoML. Дополнительно мы использовали следующие приёмы, часть из которых не вошла в финальное решение:

  • обогащение данных сторонними датасетами (население и средняя заработная плата по регионам);
  • преобразование строковых значений этажей в категории 0 и 1;
  • группировка населённых пунктов по численности населения и выделение столиц;
  • добавление возраста построек в качестве нового признака;
  • сокращение широты и долготы и создание нового признака путём объединения через «_»;
  • группировка по типам недвижимости и расчёт средней цены квадратного метра по группе в качестве новой фичи;
  • создание нового признака «среднее количество объектов на 100 м» из признаков типа «количество объектов в радиусе 1 км», «в радиусе 750 м», «в радиусе 500 м» и удаление лишних признаков;
  • использование различных метрик для оптимизации модели (лучший результат показала RMSLE);
  • работа с выбросами в предсказанных ценах («подрезка предикта»).

Ссылка на гит.

Обзор результатов приватного лидерборда


Загрузка в приватный лидерборд закончилась в 9:00 26 сентября. Результаты появились в 10:00.


Источник: приватный лидерборд хакатона Raifhack DS

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


Источник: приватный лидерборд хакатона Raifhack DS

Хакатон — серьёзное испытание для команд. К сожалению, не все дошли до финала.


Источник: слайд организаторов хакатона RaifhackD

Что мы сделали хорошо:

  • до начала соревнования нашли консультанта, который помог сориентироваться на старте и поддерживал всё время хакатона;
  • быстро нашли замену, когда один из участников команды принял решение отказаться от участия до старта;
  • сделали ставку на алгоритм LightAutoML, который уже на базовых настройках и с необработанным датасетом показал хороший скор по сравнению с baseline (рекомендуем хороший обучающий курс по LightAutoML);
  • воспользовались дополнительными мощностями — промокодом на облачные сервисы Selectel от организаторов хакатона;
  • активно следили за чатом хакатона, использовали идею корректирующего коэффициента для предикта (снизили риски переоценки объектов недвижимости);
  • смогли получить консультацию одного из соавторов LightAutoML Александра Рыжкова, потестили некоторые предложенные варианты генерации признаков;
  • использовали сторонние датасеты (данные по зарплате и населению городов), что дало ощутимый прирост скора — эта идея помогла другим командам усилить свои решения;
  • уделили внимание качеству оформления публичного ноутбука: пояснения в Markdown, чистый код, подробный readme;
  • вовремя приняли решение участвовать в номинации #лучшеепубличноерешение, хотя понимали риск того, что другие участники могут использовать наше решение и обойти нас на лидерборде.


Что мы сделали плохо:

  • работали без чёткого плана, больше полагаясь на мозговой штурм;
  • не разделили задачи заранее, поэтому на некоторых этапах участники могли дублировать друг друга (исправили этот момент к концу второго дня хакатона);
  • не подготовились заранее к публикации решения на гитхабе и в итоге едва успели к дедлайну;
  • не совсем грамотно распорядились временем: много сил ушло на EDA в пятницу, в то время как эффективнее было оставить ресурсы на ночь с субботы на воскресенье, когда решалась судьба лидерборда (в этот момент с 7–10-го места мы уехали в топ-50);
  • потратили много сил на попытки оптимизировать baseline-решение от организаторов — лучше сразу запускать свою модель и тюнить лучший вариант;
  • не было единой системы контроля решений — в конце оказалось сложно разобраться в обилии похожих файлов с одинаковыми названиями;
  • успели проверить не все идеи, которые озвучивались в команде;
  • из инструментов для командной работы использовали только чат в Telegram — туда же кидали ноутбуки, что затрудняло поиск нужной информации.

Небольшая статистика коммуникации в группе


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



В чате группы 2885 сообщений и 114 скриншотов. Было сделано восемь групповых созвонов, из которых один длился более двух часов подряд!

Тайминг работы команды


17 сентября (за неделю до хакатона)
17:00. Первый созвон с наставником, определение плана действий.

24 сентября
18:30. Начало хакатона.
19:15. Второй созвон команды, обсуждаем задачу, уходим делать разведывательный анализ данных.
20:07. Обогащаем данные с помощью датасетов с населением и зарплатами.

25 сентября
0:20. EDA готов, запустили baseline-модель.
0:55–3:00. Третий созвон, обсуждаем результаты EDA, совместно разбираем baseline, пробуем оптимизировать.
10:00. Четвёртый созвон, делимся результатами ночной работы.
11:20. Первые результаты: базовый алгоритм LightAutoML показывает скор на паблике лучше, чем baseline.
12:00. Мы на 7-м месте. Пятый созвон, обсуждаем кастомизацию LAMA.
15:30. Шестой созвон, участники в режиме онлайн настраивают подключение дополнительных мощностей от Selectel.
16:00. Седьмой созвон, обсуждаем feature engineering для улучшения качества модели.
17:30. На гитхаб загружено только одно публичное решение.
17:42. У одного из участников слетает anaconda.
18:06. Впервые высказывается предложение участвовать в публичной номинации, но пропадает в огромной массе сообщений чата.
18:36. Александр Рыжков, один из создателей LAMA, появляется в чате хакатона и предлагает идеи улучшения модели. Тестируем.
19:17. Команда принимает решение попробовать идею из публичного решения и «подрезать предикт».
19:46. Наше решение снова в топ-10.
20:17. Капитан команды предлагает участвовать в публичной номинации, голосуем.
20:30. Восьмой созвон, обсуждаем распределение задач по подготовке решения к публикации, параллельно продолжаем улучшать модель.
20:40. Мы на 7-м месте в топ-10.
22:00. Публикуем решение, едва успевая уложиться в дедлайн. По многочисленным просьбам спустя несколько минут организаторы объявляют о продлении дедлайна до 22:30. Команда утомлена, пробуем ещё несколько идей, в том числе работу с временными признаками. Уходим на отдых около полуночи.

26 сентября
Наше решение за ночь спустилось до 40-й позиции.
7:00. Часть команды уже не спит. В чате активно обсуждаются требования к оформлению решений — приближается дедлайн по приватному лидерборду.
8:30. Команда в сборе, ждём. Решение на 53-м месте.
8:50. Напряжение потихоньку спадает. Делимся впечатлениями, обсуждаем то, что не успели попробовать. Ждём публикацию private leader board.
9:30. Приватный лидерборд открывают с получасовой задержкой. Наше решение поднялось с 53-го места на паблике до 42-го на привате — это отличная новость. Значит, наша модель хорошо показала себя на тех данных, которые не видела, хотя чаще бывает наоборот.
16.00. Участвуем в награждении. Победа!

Выводы и рекомендации


Было круто! Такой быстрой прокачки опыта и знаний у нас ещё не было. Мы поработали командой в боевых условиях, создали и обучили эффективную модель для прогнозирования стоимости недвижимости. Это новый уровень, и останавливаться мы не собираемся.

Вот наши рекомендации для тех, кто впервые решился участвовать в хакатоне.

  1. Что нужно сделать каждому участнику в самом начале: оценить свои силы. Участие в хакатоне отнимает много сил и времени. Интенсивная подготовка и 100% времени на самом соревновании для созвонов, переписки и прочего. Если вы понимаете, что не можете (у вас работа, семья, другие задачи в этот период), скажите об этом перед хакатоном, а не в середине соревнования.
  2. В команде должен быть капитан. Вне зависимости от стиля управления решающее слово остаётся за ним.
  3. На плечи капитана ложатся все организационные вопросы, внешние контакты, решение конфликтных ситуаций. Капитан больше других вовлечён в координацию работы команды. Это отдельный и важный фронт работ.
  4. Ещё одна важная роль — отслеживание формальных требований к представленному решению: состав и формат файлов, дедлайны, источники, ссылки. На хакатоне одна из команд не вошла в топ-10 из-за несоблюдения формальных критериев.
  5. Желательно заранее распределять роли и задачи между участниками команды. Для этого нужны созвоны до начала хакатона.
  6. Нужно изучить задачу до начала хакатона и посмотреть примерные решения, заготовить шаблоны кода и презентации.
  7. Важно решить, какие инструменты вы будете использовать для взаимодействия участников, например Trello для задач, гитхаб или Google Colab для совместной работы, Google Team для созвонов.
  8. Параллельное решение задач быстрее, чем последовательное, но и риск ошибок выше.
  9. На хакатоне большинство решений будут стандартными. Если хотите привлечь внимание, реализуйте оригинальные идеи. Но не забывайте про классические подходы.
  10. Если во время соревнования не хватает времени или мощностей для реализации какой-то идеи, её можно озвучить для жюри, но в качестве следующего этапа, например, сказать, что планируете доработать функциональность в будущем.
  11. Во время хакатона случается всё: летят программы, ломается ноутбук, не хватает ресурсов. Имеет смысл подумать о подстраховке и проверить или установить все необходимые программы и библиотеки, одолжить дополнительный компьютер.
  12. Первая библиотека, которую нужно импортировать, — import this.

Хотим ещё раз поблагодарить организаторов хакатона за отличный боевой опыт! И всех, кто нам помогал советами в преодолении этого важного для нас челленджа!
Источник: https://habr.com/ru/company/yandex_praktikum/blog/582176/


Интересные статьи

Интересные статьи

Мы уже писали о том, как студенты нашей онлайн-магистратуры совмещают учёбу и работу, а сегодня, к началу потока флагманского курса по Data Science, делимся материалом об этом от Куен Тран, автора ста...
Автор этого руководства по карьере в области Data Science, с которым вы можете быть знакомы по нашему переводу о вдохновляющих портфолио, начал создавать свою собственную учебную программу на магистра...
Продолжаем изучать, как менторство на разных уровнях спасает жизни помогает в карьерном росте и решении рабочих задач. Спойлер: вне зависимости от уровня применения менто...
Всё чаще от клиентов поступают такие запросы: «Хотим как Amazon RDS, но дешевле»; «Хотим как RDS, но везде, в любой инфраструктуре». Чтобы реализовать подобное managed-решение на ...
Привет! Это наш первый релиз из дома. DataGrip и другие наши IDE с поддержкой баз данных теперь умеют больше. Читать дальше →