Хабрахабр

Kaggle-подходы для CV в проде: внедрить нельзя выпилить

Среди дата сайнтистов ведется немало холиваров, и один из них касается соревновательного машинного обучения. Действительно ли успехи на 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, форум, кернелы.

Многие соревнования превратились в kernel driven development. A:
Ты упомянул “кернелы”, и к ним у меня есть отдельная претензия. Тем не менее, даже в соревнования по deep learning теперь можно получить какую-то медаль, почти не писав код. Я не стану заострять внимание на вырожденных случаях, когда золотая медаль могла достаться благодаря удачному запуску публичного скрипта. Можно взять несколько публичных решений, особо не разбираясь покрутить какие-то параметры, проверить себя на лидерборде, усреднить результаты и получить неплохую метрику.

попадание в топ 10% итогового рейтинга) показывали, что человек на что-то способен — нужно было как минимум самому написать нормальный пайплайн от начала и до конца, не допустить критических багов. Раньше даже умеренные успехи в “картиночных” соревнованиях (например, бронзовая медаль, т.е. Сейчас эти успехи девальвировались: Kaggle вовсю продвигает свою платформу кернелов, которые снижают порог входа и позволяют как-то экспериментировать без осознания, что к чему.

Это и есть уровень “я что-то там запустил, и оно обучилось”. N:
Бронзовая медаль никогда не котировалась. Понижение уровня входа за счет кернелов и наличие GPU в них создает конкуренцию и поднимает общий уровень знаний выше. Если год назад можно было получить золото с помощью ванильного Unet’a, то теперь без 5+ модификаций и трюков просто не обойтись. И это не так уж и плохо. Например, на aerial-Inria наши чуваки из ods.ai зашли с ноги и показали state of the art просто своими сильными пайплайнами по сегментации, наработанными на Kaggle. И эти фокусы работают не только на Kaggle, но и за его пределами. Это показывает применимость таких подходов и в реальной работе.

Обычно нет одного числа, которое показывает, что все пошло не так или, наоборот, все отлично. A:
Проблема в том, что в реальных задачах нет лидерборда. Часто есть несколько чисел, они противоречат друг другу, увязывать их в одну систему — тот еще вызов.

Они показывают объективный перфоманс алгоритма. N:
Но метрики так или иначе важны. Без алгоритмов с метриками выше некоторого юзабельного порога невозможно создавать сервисы на базе ML.

Бывает, что нужно дотащить метрику до какого-то гигиенического минимума, а дальнейшие улучшения “технической” метрики уже не очень соответствуют продуктовым улучшениям (пользователь не заметит эти +0. A:
Но только если они честно отражают состояние продукта, что не всегда так. 01 IoU), корреляция между метрикой и ощущениями пользователя теряется.

Не нужны искать “лики”, не нужно воспроизводить разметку и находить правильные ответы по хешам файлов. Кроме того, классические kaggle способы наращивать метрику неприменимы в обычной работе.

Надежная валидация и ансамбли жирных моделей

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

Kaggle решение обычно состоит из кучи моделей, и это невозможно тащить в прод. Другая вещь, за которую часто ругают кэгглеров – ансамбли. А чтобы победить необходим не просто ансамбль, а ансамбль разнообразных и сильных сингл моделей. Однако при этом забывают, что невозможно сделать сильное решение без сильных single моделей. Подход типа “намешаю всего подряд” никогда не дает приличный результат.

В рамках соревнования это будет одна архитектура, обученная на 5/10 фолдах, с развесистым енкодером, в инференсе можно ожидать test time augmentation. A:
Понятие “простой сингл модели” в Kaggle-тусовке и для продакшен-окружения могут разительно отличаться. По меркам конкурсов это действительно простое решение.

Например, у меня Kaggle-модели обычно занимают 100+ мегабайт, а в работе модели больше нескольких мегабайт часто даже не рассматриваются; аналогичная разбежка есть и в требованиях к скорости инференса. Но для продакшена часто нужны решения на пару порядков проще, особенно если речь идет о мобильных приложениях или IoT.

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

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

Данные, полученные при помощи псевдолейблинга, хоть и улучшают метрику, не так полезны, как ручная доразметка недостающих данных. A:
Псевдолейблинг бывает полезен, но в конкурсах его используют не от хорошей жизни — только из-за того, что доразмечать данные нельзя.

Мы берем существующие модели, смотрим, где они дают уверенные предсказания, эти семплы вместе с предсказаниями закидываем в наш датасет. Что из себя представляет псевдолейблинг? сейчас эти предсказания недостаточно хороши. При этом сложные для модели семплы остаются неразмеченными, т.к. Замкнутый круг!

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

О красоте кода и командной работе

A:
Еще одна проблема — качество кода и культура разработки. Kaggle не только не учит правильно писать код, но и подает много плохих примеров. Большая часть кернелов — плохо структурированный, нечитабельный и неэффективный код, который бездумно копируется. Некоторые популярные на Kaggle личности и вовсе практикуют выкладывание своего кода на Google Drive вместо репозитория.

Если много смотреть в плохой код, можно свыкнуться с мыслью, что так и должно быть. Людям хороши в unsupervised learning. Особенно это опасно для новичков, которых на Kaggle довольно много.

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

И ничто так не сплачивает людей, как общее дело, общая понятная цель. Зато Kaggle учит командному взаимодействию. Можно попробовать поучаствовать в соревнованиях с кучей разных людей, понетворкаться и развить soft-скиллы.

Хорошо, если там действительно есть какое-то разделение задач по ролям, конструктивное взаимодействие, и каждый вносит свою лепту. A:
Команды в стиле Kaggle тоже бывают очень разными. data science) так не делается уже очень давно. Тем не менее, команд, в которых каждый делает свой big ball of mud, а в последние дни соревнования все это неистово смешивается, тоже хватает, и ничему хорошему это тоже не учит — настоящая разработка софта (в т.ч.

Summary

Давайте подведем итог.

Несомненно, участие в соревнованиях дает свои бонусы, полезные в ежедневной работе: в первую очередь это умения быстро итерироваться, выжимать из данных все в рамках метрики и не стесняться использовать state of the art подходы.

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть