Как бустануть метрики на DL-проекте?

Жека Никитин

Всем привет, хочу начать неделю с рейтинга штук, которые чаще всего существенно докидывают по метрикам в DL-проектах. Основано на моём личном опыте, по факту ваш индивидуальный рейтинг, конечно, будет зависеть от специфики проекта, зрелости организации, сложности домена и данных.

1️⃣ Исправление ошибок в данных

Управление качеством данных - отдельная дисциплина, которой посвящены книги и конференции. При этом инвестировать уйму сил в обеспечение близкого к стопроцентному уровня качества данных не всегда является лучшим решением, особенно в стартапах на ранних этапах развития продукта. Тем не менее, на любом этапе жизненно важным является визуальный анализ данных, как сырых, так и поступающих непосредственно в сетку. Сколько раз отсмотр данных глазами помогал прокачать метрики - я уж и не вспомню. Например, однажды оказалось, что разметка флипнута горизонтально относительно изображения в 5 процентах датасета. Сетки достаточно робастны к такому шуму, и в целом обучение шло успешно и докатывалось до вменяемых метрик. Тем не менее, фикс этой проблемы моментально позволил добиться нехилого прироста по всем метрикам.

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

2️⃣ Исправление ошибок в коде

Стандартная проблема DL - сетки багуют “по-тихому”. Об этом уже написано много статей, но менее актуальным это не стало. Код может выполняться, сетка докатываться до неплохих метрик, но какой-то незаметный баг в коде не позволяет полностью раскрыть потенциал сети. Простой пример - в нашей системе трекинга экспериментов мы склонировали эксперимент, созданный очень давно. С тех пор система вышла из беты, и старые эксперименты больше не поддерживались. В итоге, все наши новые эксперименты запускались с дефолтными гиперпараметрами, даже если мы их меняли в интерфейсе. Заметили мы это достаточно быстро, потому что метрики абсолютно разных экспериментов были подозрительно похожи =)

Что тут можно посоветовать? Самый простой совет - писать тесты не только на инференс-код, но и на трейн-луп. К сожалению, все кейсы тестами не покроешь, поэтому важно также:

📌 обеспечивать репродуцируемость экспериментов - без этого можно сойти с ума при дебаггинге

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

3️⃣ Смена ML-постановки задачи

Подход радикальный, но бывают случаи, когда без него не обойтись. Например, наша система по маммографии начиналась как простая классификационная сетка с ответом норма/патология. Достаточно быстро стало понятно, что такой подход подходит только для MVP, и для дальнейшего улучшения качества нужно переходить на детекцию. Ещё через какое-то время стало ясно, что переход на инстанс-сегментацию обеспечит дополнительный супервижн, который позволит поднять качество, хоть сама бизнес-задача сегментации и не требует. В общем, всегда стоит помнить, что к решению одной и той же задачи есть много кардинально разных подходов с точки зрения ML/DL. Кстати, у Антона Мальцева есть хороший видос на эту тему.

4️⃣ Твики разных частей архитектуры сетки

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

5️⃣ Подобранные под задачу аугментации

Часто видел, что берут какой-то стандартный набор аугментаций и пихают его в любую задачу без понимания зачем, что, почему. Например, в некоторых задачах стандартные флип или поворот только ухудшат итоговую работу системы. Очень важно смотреть глазами на результаты работы аугментации и регулировать их параметры, подбирать экспериментальным путём нужный уровень интенсивности. Можно работать и с “расписанием” аугментаций, то есть, на каком этапе обучения какую интенсивность нужно использовать. Ну и наконец часто можно придумать хитрые клёвые аугментации именно под свой домен, которые позволят улучшить работу системы на редких и сложных кейсах.

6️⃣ Постпроцессинг предсказаний

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

7️⃣ Качественный претрейн

На эту тему написано уже очень много - к вашим услугам и разные виды SSL, претрейн на псевдо-разметке, претрейн на другом домене, претрейн на слабой разметке и многое другое. Это действительно часто позволяет улучшить метрики и ускорить сходимость, особенно в low-data режимах.

Делите своими любимыми трюканами в комментариях, и всем хорошей рабочей недели!