Привет, Хабр! Меня зовут Анастасия Белозерова, я тимлид исследовательской команды, работающей над продуктом Luna Line в VisionLabs (входит в MWS AI). Мы занимаемся созданием no-code-платформы для компьютерного зрения, которая позволяет пользователю (не программисту, а агроному, например) разметить данные, нажать на кнопку и получить идеально обученную CV-модель под свои рабочие задачи, даже если у него для этого данных всего-то 50 картинок.
Под катом — хроники наших экспериментов по поиску «универсального рецепта» для обучения моделей под задачи классификации. Публикация про сегментацию будет чуть позже. Расскажу, какие мы выдвигали гипотезы, как их проверяли относительно поиска универсального решения и почему пересмотрели методологию экспериментов при переходе от одной задачи к другой.
Кто желает не читать, а смотреть и слушать, вот тут лежит видеозапись моего доклада по этой теме на Митапе D﹥﹤Vision.
Но давайте сначала коротко расскажу о продукте.
О платформе
Luna Line — это платформа, которая помогает быстро обучать модели компьютерного зрения на малых датасетах. Она работает со всеми базовыми задачами:
— детекция,
— сегментация,
— классификация,
— текстовый запрос.
Путь пользователя выглядит примерно так:
Выбирает задачу из перечня выше → заливает свой датасет под эту задачу в платформу → размечает данные → нажимает кнопку «Обучить модель» → смотрит финальные метрики → если устраивает качество, создает API модели → получает эндпоинт, через который можно закидывать новые фотки и получать результаты распознавания.
Также пользователь может строить целые пайплайны из нейронных сетей. Что это значит на практике?
Например, мы можем обучить собственный детектор под любой интересующий нас объект. Пусть это будут хрюшки на ферме. К этому детектору мы можем подключить трекер — любой удобный, который подходит под задачу, и начать отслеживать перемещение хрюшек. Дальше можно использовать результаты этого этапа, чтобы подготовить вспомогательный датасет: например, вырезать кропы хрюшек из видео и разметить их по какому-нибудь дополнительному признаку, например цвету. Мы размечаем датасет, обучаем еще одну модель и добавляем ее в общий пайплайн.
Так и собирается цепочка из нескольких нейросетей, то есть полноценная видеоаналитика.
Области применения любые: можно выявлять пустые полки в магазинах, оценивать качество урожая, определять дефекты в производстве и еще 100500 сценариев на любой вкус.
Слишком вдаваться во внутреннее устройство платформы не буду. Если коротко: построена на базе опенсорсного ClearML, а сервинг моделей происходит через Triton. Остальное — смотрите на Рисунке 1.
Куда интереснее перечислить главные требования, которые мы закладывали в продукт:
1. Небольшое количество размеченных данных. Мы не можем требовать от пользователя тысячи размеченных картинок. Наш порог входа — от 50 изображений.
2. Экономия ресурсов. Мы хотим, чтобы клиенты могли разворачивать решения у себя в контуре на доступном железе.
3. Автоматизация. Пользователь не должен подбирать гиперпараметры. Он выбирает только желаемый размер модели (Small, Base, Large) и запускает процесс.
4. При всех вышеперечисленных условиях нам еще нужно, чтобы модели работали стабильно вне зависимости от домена или природы данных.
И на этой ноте переходим к главной теме статьи: как мы искали оптимальный рецепт обучения моделей классификации и сегментации.
Часть 1. Классификация
Мы выдвинули гипотезу, что вообще можно найти в среднем оптимальную конфигурацию обучения модели классификации, которая подошла бы сразу для всех доменов и зависела бы только от размера обучающей выборки. А следом — еще одну: в зависимости от размера выборки можно найти оптимальное семейство архитектур; подобрать из него оптимальные параметры для base-модели, а дальше взять из того же семейства small/large-модели и проскейлить для них число эпох.
Поясню, что значит «в среднем оптимальную конфигурацию для любых доменов». Это значит, что средняя точность обучения на разных доменах будет как можно больше, а разброс метрик при обучении на разных доменах — как можно меньше.
Ну и помним вышеперечисленные требования к продукту:
— Пользователь выбирает один из трех размеров моделей. Это определяет дизайн нашего эксперимента — нужна адаптивность под размер выборки.
— Мы не грузим пользователя сложными настройками. Соответственно, нам нужно, чтобы конфиги были насколько возможно универсальными. Мы не хотим, чтобы пользователь туда-сюда менял какие-то параметры и расширялось пространство для ошибки.
— Мы экономим деньги клиентов, так что 10 ГБ видеопамяти на обучение модели — наш потолок.
План наших поисков оптимального рецепта обучения был простой: готовим данные и инфраструктуру для экспериментов, определяем метрики, по которым будем оценивать модели, и проводим эксперименты.
Обо всем по порядку…
Подготовительный этап: бенчи и инфраструктура для экспериментов
Для бенчмарка мы сформировали 28 датасетов. Половина — опенсорсные, половина — собственные данные VisionLabs, собранные в рамках наших разноплановых проектов. Спектр доменов максимально широкий: классификация товаров, дефекты металла, болезни листьев, типы тканей, состояние дорожного покрытия, разновидности защитных перчаток и прочее.
Для каждого датасета мы зафиксировали валидационную и тестовую выборки. В обучающей выборке мы создали вложенные сабсеты размером 50, 100, 500, 1000, 5000 и 10 000 изображений. Это позволило нам симулировать поведение модели при разном объеме обучающих данных от пользователя. Мы предположили, что вряд ли пользователь захочет размечать более 10 тыс. картинок…
Далее мы настроили инфраструктуру для проведения экспериментов. В основе — единый проект для обучения моделей, полностью управляемый через конфигурационные файлы. Все результаты экспериментов логируются в ClearML. Туда же логируется и вся вспомогательная информация, в частности по потреблению VRAM во время обучения. Соответственно, мы оттуда по запросу можем выгружать нужную нам информацию, создавать таблицы с результатами и далее принимать решение о том, какой эксперимент у нас был лучшим.
Эксперименты
Он у нас состоит из трех этапов:
Выбор семейства моделей.
Подбор оптимальных параметров для базовой модели из семейства.
Адаптация конфигов для моделей побольше и поменьше из того же семейства.
Этап 1. Выбор семейства моделей
Мы взяли все популярные архитектуры, которые хорошо себя зарекомендовали в классификации — смотрите Таблицу 1. Старались выбирать семейства моделей так, чтобы у их «базовых» представителей было примерно 10 миллионов параметров и они укладывались в лимит по памяти. Вот такой комплект у нас получился:
Из этого списка мы выбирали семейство, которое будет стабильно хорошо работать на всех доменах без изменения гиперпараметров (кроме learning rate, который брали исходя из рекомендаций в статьях-первоисточниках, так как у всех разные оптимальные значения).
Для сравнения моделей вывели агрегированную метрику, состоящую из взвешенной суммы трех коэффициентов:
Средняя точность по 28 датасетам.
Стабильность (один минус коэффициент вариации). Мы штрафовали архитектуры, у которых точность сильно прыгала от домена к домену.
Штраф за превышение памяти.
Для того чтобы было удобно сравнивать разные конфиги между собой, ввели ранговую систему. Конфиги ранжируются по коэффициенту AGG_RANK:
AGG_RANK = 0.7 · mean(acc) + 0.25 · (1 − CV(acc)) + 0.05 · vram_coeff
Где vram_coeff=
1, if vram_usage_gb < 5
0.66, if 5 ≤ vram_usage_gb < 10
0.33, if 10 ≤ vram_usage_gb < 20
0, if vram_usage_gb ≥ 20
Если дельта значений AGG_RANK между двумя конфигами будет меньше 0.025, то оба конфига принадлежат одному рангу.
Мы прогнали более 1200 экспериментов и построили визуализации в виде HTML-таблиц, где по клику на датасет можно было перейти в ClearML и увидеть детали обучения. В таблице ниже — результаты по сапсету на 1000 картинок.
Главный вывод: на выборках до 5000 изображений безоговорочно лидируют RegNet’s; на выборках от 5000 изображений лучше переходить на ConvNeXt. Подтверждение смотрите на графике ниже:
При этом EfficientNet (моя любимая архитектура) показала себя хорошо, но уступила RegNet в стабильности на сверхмалых данных. Это был первый сюрприз: интуиция, основанная на опыте работы с большими датасетами, здесь не сработала.
По итогу мы выбрали два семейства моделей — RegNetY и ConvNeXt — в качестве победителей. Первый — для датасетов <5 тыс., второй — для >5 тыс. Выбранные модели мы назвали base, то есть средними по размеру и дефолтными для работы
Этап 2. Подбор гиперпараметров для base-модели
Далее нам нужно было научиться подбирать гиперпараметры в зависимости от размера выборки.
В целом мы пошли по классическому пути, но с несколькими важными нюансами. Сначала фиксируем пространство поиска: задаем диапазоны для ключевых параметров — количества эпох, learning rate и размера батча. Дальше просто случайно сэмплируем несколько комбинаций этих параметров. Для каждой такой «тройки» обучаем модель, считаем метрики и сохраняем все в историю экспериментов.
После этого подключаем более умный подбор: используем TPE (Tree-structured Parzen Estimator) — метод байесовской оптимизации, который по умолчанию применяется в Optuna. Если сказать проще, он смотрит на уже полученные результаты и предлагает новые комбинации гиперпараметров, которые с большей вероятностью дадут лучший результат. В классическом сценарии оптимизируется одна метрика, но мы пошли чуть дальше: одновременно учитывали две — хотели не только максимизировать качество, но и уменьшить разброс результатов между разными датасетами.
Дальше процесс итеративный: TPE предлагает новые наборы параметров, мы обучаем модели, собираем метрики и снова передаем их в оптимизацию. Так продолжаем, пока не набираем достаточно экспериментов, чтобы уверенно выбрать оптимальные значения.
Что мы обнаружили
Batch size = 8 оказался оптимальным для всех размеров датасетов и обеих архитектур. Это объяснимо: на маленьких данных большой батч просто не нужен. Learning rate, на самом деле, тоже не меняется. Он зависит только от архитектуры. Так как у нас есть переключение с RegNet-ов на ConvNeXt’s, мы можем переключаться и для Learning rate: для RegNet — 5e-4, для ConvNeXt — 5e-5.
Результаты подбора гиперпараметров для base-модели выглядят так:
batch_size = 8;
lr = 0.0005 if dataset_size < 5000 else 0.00005;
num_epochs = int(-4.44 * log(dataset_size) + 61.61)
Количество эпох — единственный параметр, который зависит от объема данных: чем больше данных, тем меньше эпох — смотрите график ниже.
Этап 3. Скейлинг: модели Small и Large
Мы планировали взять из семейств RegNet и ConvNeXt модели меньшего и большего размера и просто пропорционально изменить количество эпох, надеясь, что гиперпараметры останутся теми же.
Но тут нас ждал очередной сюрприз. Для RegNet (данные <5000): модели от 2 до 32 гигафлопс показали практически одинаковое качество на выборках до 1000 изображений. Разница была в пределах статистической погрешности. При этом более тяжелые модели требовали заметно больше памяти при обучении и инференсе. Следовательно, для small-моделей мы можем брать самые легкие RegNet, а base-модели в нашей классификации на деле являются large.
Для ConvNeXt (данные >5000): ситуация аналогичная. Прирост от увеличения модели до ConvNeXt Base был минимальным, а ресурсов требовалось непропорционально много.
Итог для продуктовой логики
Мы решили первоначальные base-модели на 10М считать large-моделями и сделали от них два шага назад: base теперь стали называться модельки меньше 10М, а small — еще меньше (самые легкие RegNet/ConvNeXt).
Мы провели более 9000 экспериментов. В итоге для классификации получили пайплайн, где единственная переменная — это размер датасета.
Саммари по нашим результатам смотрите на рисунке 8.
Практический кейс
Один из наших клиентов решал задачу классификации средств индивидуальной защиты — перчаток.
Интересно было сравнить наши выводы с актуальными исследованиями. Работа Battle of Backbones 2023 рекомендует для классификации ConvNeXt и Swin, но они тестировались на ImageNet (см. рисунок 10).
А вот вышедшая в 2025 году работа Which Backbone to Use как раз фокусировалась на файнтюнинге под разные домены на небольших выборках. И мы с удовлетворением обнаружили, что их выводы совпадают с нашими: RegNet и ConvNeXt — лучший выбор на многих доменах.
На самом деле по итогу мы остались не совсем довольны полученными результатами и выбранной методологией и перепридумали наш подход к бенчмаркингу, но об этом – в следующей части. Подписывайтесь, чтобы не пропустить продолжение.