Среди дата сайнтистов ведется немало холиваров, и один из них касается соревновательного машинного обучения. Действительно ли успехи на Kaggle показывают способности специалиста решать типичные рабочие задачи? Арсений arseny_info (R&D Team Lead @ WANNABY, Kaggle Master, далее в тексте A.) и Артур n01z3 (Head of Computer Vision @ X5 Retail Group, Kaggle Grandmaster, далее в тексте N.) отмасштабировали холивар на новый уровень: вместо очередного обсуждения в чате взяли микрофоны и устроили публичное обсуждение на митапе, по мотивам которого и родилась эта статья.
Метрики, кернелы, лидерборд
A:
Хочется начать с ожидаемого аргумента о том, что Kaggle не учит самому важному в работе типичного дата сайнтиста — постановке задачи. Правильно поставленная задача уже содержит в себе половину решения, и зачастую именно эта половина оказывается самой сложной, а уже закодить какую-то модельку и обучить ее — сильно проще. Kaggle же предлагает задачу из идеального мира — данные готовы, метрика готова, бери да обучай.
Удивительно, что даже с этим возникают проблемы. Нетрудно найти множество примеров, когда “кэгглеры” оказываются сбиты с толку, увидев незнакомую/непонятную метрику.
N:
Да, в этом суть кэггла. Организаторы подумали, формализовали задачу, собрали датасет и определили метрику. Но если у человека есть зачатки критического , то первое о чем он подумает – почему решили, что выбранная метрика или предложенный таргет оптимальны. Сильные участники нередко сами переопределяют задачу и придумывают более удачный таргет.
И когда разобрались с метрикой, определили таргет и собрали данные, то оптимизация метрики – это то, что кэгглеры делают лучше всего. После каждого соревнования заказчик может с большой долей уверенности считать, что участники показали “потолок” для идеального алгоритма топовым скором. И чтобы этого добиться, кэгглеры пробуют много разнообразных подходов и идей, валидируя их быстрыми итерациями.
Этот подход непосредственно конвертируются в успешную работу над реальными задачами. Более того, опытные кэгглеры могут сразу интуитивно или из прошлого опыта выбрать список идей, которые стоит попробовать в первую очередь, чтобы получить максимальный профит. И тут на помощь приходят весь арсенал kaggle-сообщества: статьи, slack, форум, кернелы.
A:
Ты упомянул “кернелы”, и к ним у меня есть отдельная претензия. Многие соревнования превратились в kernel driven development. Я не стану заострять внимание на вырожденных случаях, когда золотая медаль могла достаться благодаря удачному запуску публичного скрипта. Тем не менее, даже в соревнования по deep learning теперь можно получить какую-то медаль, почти не писав код. Можно взять несколько публичных решений, особо не разбираясь покрутить какие-то параметры, проверить себя на лидерборде, усреднить результаты и получить неплохую метрику.
Раньше даже умеренные успехи в “картиночных” соревнованиях (например, бронзовая медаль, т.е. попадание в топ 10% итогового рейтинга) показывали, что человек на что-то способен — нужно было как минимум самому написать нормальный пайплайн от начала и до конца, не допустить критических багов. Сейчас эти успехи девальвировались: Kaggle вовсю продвигает свою платформу кернелов, которые снижают порог входа и позволяют как-то экспериментировать без осознания, что к чему.
N:
Бронзовая медаль никогда не котировалась. Это и есть уровень “я что-то там запустил, и оно обучилось”. И это не так уж и плохо. Понижение уровня входа за счет кернелов и наличие GPU в них создает конкуренцию и поднимает общий уровень знаний выше. Если год назад можно было получить золото с помощью ванильного Unet’a, то теперь без 5+ модификаций и трюков просто не обойтись. И эти фокусы работают не только на Kaggle, но и за его пределами. Например, на aerial-Inria наши чуваки из ods.ai зашли с ноги и показали state of the art просто своими сильными пайплайнами по сегментации, наработанными на Kaggle. Это показывает применимость таких подходов и в реальной работе.
A:
Проблема в том, что в реальных задачах нет лидерборда. Обычно нет одного числа, которое показывает, что все пошло не так или, наоборот, все отлично. Часто есть несколько чисел, они противоречат друг другу, увязывать их в одну систему — тот еще вызов.
N:
Но метрики так или иначе важны. Они показывают объективный перфоманс алгоритма. Без алгоритмов с метриками выше некоторого юзабельного порога невозможно создавать сервисы на базе ML.
A:
Но только если они честно отражают состояние продукта, что не всегда так. Бывает, что нужно дотащить метрику до какого-то гигиенического минимума, а дальнейшие улучшения “технической” метрики уже не очень соответствуют продуктовым улучшениям (пользователь не заметит эти +0.01 IoU), корреляция между метрикой и ощущениями пользователя теряется.
Кроме того, классические kaggle способы наращивать метрику неприменимы в обычной работе. Не нужны искать “лики”, не нужно воспроизводить разметку и находить правильные ответы по хешам файлов.
Надежная валидация и ансамбли жирных моделей
N:
Kaggle учит правильно валидироваться, в том числе из-за наличия ликов. Нужно очень четко отдавать себе отчет, за счет чего улучшился скор на лидерборде. Также необходимо построить репрезентативную локальную валидацию, которая отражает прайват часть лидерборда или распределение данных в продакшене, если речь про реальную работу.
Другая вещь, за которую часто ругают кэгглеров – ансамбли. Kaggle решение обычно состоит из кучи моделей, и это невозможно тащить в прод. Однако при этом забывают, что невозможно сделать сильное решение без сильных single моделей. А чтобы победить необходим не просто ансамбль, а ансамбль разнообразных и сильных сингл моделей. Подход типа “намешаю всего подряд” никогда не дает приличный результат.
A:
Понятие “простой сингл модели” в Kaggle-тусовке и для продакшен-окружения могут разительно отличаться. В рамках соревнования это будет одна архитектура, обученная на 5/10 фолдах, с развесистым енкодером, в инференсе можно ожидать test time augmentation. По меркам конкурсов это действительно простое решение.
Но для продакшена часто нужны решения на пару порядков проще, особенно если речь идет о мобильных приложениях или IoT. Например, у меня Kaggle-модели обычно занимают 100+ мегабайт, а в работе модели больше нескольких мегабайт часто даже не рассматриваются; аналогичная разбежка есть и в требованиях к скорости инференса.
N:
Однако если дата сайнтист умеет обучить тяжелую сетку, то все те же приемы подходят и для обучения легковесных моделей. В первом приближении можно взять просто аналогичную сетку полегче или mobile версию той же архитектур. Квантизация весов и прунинг за пределами компетенций кэгглеров – тут спору нет. Но это уже очень специфичные навыки, которые далеко не всегда остро необходимы в проде.
Зато куда более частая ситуация в реальных задачах, что есть маленький (как у тебя в штанах) размеченный датасет и либо большая часть неразмеченных данных, либо непрерывных поток новых данных. И тут как нельзя лучше подходит умение сварить большой и точный ансамбль. С его помощью можно сделать псевдолейблинг или дистилляцию, чтобы обучить легковесную модель. Увеличение датасета таким образом гарантированно улучшит перфоманс любой модели.
A:
Псевдолейблинг бывает полезен, но в конкурсах его используют не от хорошей жизни — только из-за того, что доразмечать данные нельзя. Данные, полученные при помощи псевдолейблинга, хоть и улучшают метрику, не так полезны, как ручная доразметка недостающих данных.
Что из себя представляет псевдолейблинг? Мы берем существующие модели, смотрим, где они дают уверенные предсказания, эти семплы вместе с предсказаниями закидываем в наш датасет. При этом сложные для модели семплы остаются неразмеченными, т.к. сейчас эти предсказания недостаточно хороши. Замкнутый круг!
На практике гораздо полезнее найти те семплы, которые заставляют сеть выдавать неуверенные предсказания, и доразметить именно их. Это требует много ручного труда, но эффект того стоит.
О красоте кода и командной работе
A:
Еще одна проблема — качество кода и культура разработки. Kaggle не только не учит правильно писать код, но и подает много плохих примеров. Большая часть кернелов — плохо структурированный, нечитабельный и неэффективный код, который бездумно копируется. Некоторые популярные на Kaggle личности и вовсе практикуют выкладывание своего кода на Google Drive вместо репозитория.
Людям хороши в unsupervised learning. Если много смотреть в плохой код, можно свыкнуться с мыслью, что так и должно быть. Особенно это опасно для новичков, которых на Kaggle довольно много.
N:
Качество кода — спорная вещь на кэггле, я согласен. Однако я встречал и людей, которые писали очень достойные пайплайны, которые могли переиспользоваться и для других задач. Но это скорее исключение: в пылу борьбы качество кода приносится в жертву в пользу быстрых проверок новых идей, особенно ближе к концу соревнования.
Зато Kaggle учит командному взаимодействию. И ничто так не сплачивает людей, как общее дело, общая понятная цель. Можно попробовать поучаствовать в соревнованиях с кучей разных людей, понетворкаться и развить soft-скиллы.
A:
Команды в стиле Kaggle тоже бывают очень разными. Хорошо, если там действительно есть какое-то разделение задач по ролям, конструктивное взаимодействие, и каждый вносит свою лепту. Тем не менее, команд, в которых каждый делает свой big ball of mud, а в последние дни соревнования все это неистово смешивается, тоже хватает, и ничему хорошему это тоже не учит — настоящая разработка софта (в т.ч. data science) так не делается уже очень давно.
Summary
Давайте подведем итог.
Несомненно, участие в соревнованиях дает свои бонусы, полезные в ежедневной работе: в первую очередь это умения быстро итерироваться, выжимать из данных все в рамках метрики и не стесняться использовать state of the art подходы.
С другой стороны, злоупотребление Kaggle-подходами часто ведет к неоптимальному нечитабельному коду, сомнительным приоритетам в работе и некоторой зашоренности.
Впрочем, любой дата сайнтист знает, что для успешного создания ансамбля нужно комбинировать разнообразные модели. Так и в команде стоит комбинировать людей с разными наборами навыков, и один или двое опытных кэгглеров будут полезны практически любой команде.
Автор: Арсений Кравченко
