Разработка пайплайна аугментации изображений для обучения CV-модели

Аугментация изображений: где ломается обучение на малой выборке

Обучение на малой выборке данных почти всегда выглядит одинаково: на нескольких сотнях размеченных кадров модель уверенно проходит обучение, а на отложенной части проваливается по редким классам. Формально ошибка падает, но растёт разрыв между поведением на знакомых и новых примерах — это и есть переобучение модели, при котором сеть запоминает конкретные кадры вместо признаков объекта.

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

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

Простая аугментация изображений сама по себе проблему не снимает. Случайные повороты, отражения и сдвиги плодят почти одинаковые кадры: модель запоминает фон, освещение и артефакты съёмки, а валидация, собранная из тех же съёмок, подтверждает эту иллюзию. Разбираем, как это закрывается — от правил отбора примеров и балансировки классов до контроля метрик по каждому классу отдельно.

Измеримый эффект: качество модели, сроки, трудозатраты

Метрики на отложенной выборке перестают «плавать»

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

Меньше ручной разметки на тот же объём данных

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

Устойчивость к искажениям вместо запоминания условий съёмки

Модель перестаёт опираться на конкретное освещение, ракурс или качество оптики, потому что видит эти вариации ещё на обучении. Отдельный набор с искажениями показывает: просадка при смене камеры, точки съёмки или времени суток заметно меньше, чем у модели, обученной на «чистых» кадрах.

Цикл проверки гипотез — часы вместо дней

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

Способы дополнения данных: сравнение подходов

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

Варианты и их границы

На практике берут два-три приёма и подбирают силу по контрольной выборке из реальных кадров. Если качество на ней падает при росте качества на дополненных данных — усиление перебор: геометрия и синтетика начинают подменять признаки объекта артефактами.

Этапы внедрения: от аудита данных до передачи команде

Аугментация начинается не с выбора библиотеки преобразований, а с вопроса, каких условий съёмки не хватает модели. Поэтому первый шаг — опись того, что уже лежит в датасете, а не код. Ниже порядок работы: каждый этап заканчивается артефактом, который можно проверить и передать дальше.

1. Аудит датасета. Смотрим распределение классов, дубликаты и почти-дубликаты, битые и пересвеченные кадры, расхождения в разметке между аннотаторами. На выходе — перечень дефектов и оценка, сколько кадров реально пригодно к обучению.
2. Схема подготовки данных и метрики. Фиксируем целевые метрики — точность и полноту по классам, долю ложных срабатываний — и описываем порядок: чтение, приведение размера, нормализация, разбиение на обучающую, валидационную и тестовую части.
3. Настройка и валидация преобразований. Подбираем геометрию, цвет, шум, имитацию освещения и погоды. Диапазоны задаём консервативно: преобразование не должно создавать объект, которого нет в разметке. Затем прогоняем каждое преобразование отдельно и в комбинации и сверяем, что метки пересчитываются корректно, а объект у границы кадра не теряется.
4. Проверка на контрольных наборах. Держим набор, который никогда не аугментируется, и набор сложных кадров — слабый свет, движение, перекрытия. Они показывают, помогает аугментация обобщению или просто маскирует переобучение.
5. Замер влияния на модель. Обучаем базовую и аугментированную версии в одинаковых условиях и сравниваем по метрикам и по устойчивости к смене условий съёмки. Выигрыш фиксируем числом, а не ощущением.
6. Передача и обучение команды. Отдаём конфигурации, скрипты запуска и журнал прогонов. Воспроизводимость экспериментов держится на том, что любой результат повторяется по зафиксированному набору параметров без ручных правок.

Конфигурации, схемы и регламенты: комплект передачи

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

• Конфигурация преобразований — файлы с наборами операций (повороты, кроп, изменение яркости и контраста, шум, размытие), диапазонами значений и вероятностями применения. Отдельный профиль под каждую задачу, чтобы усиление под детекцию не ломало разметку под классификацию.
• Схемы потоков данных — как снимок проходит путь от источника до готовой выборки: где разметка, где применяется аугментация, где отбраковка и что попадает в архив.
• Правила версионирования датасета — манифесты с контрольными суммами исходников и сгенерированных выборок, связка «версия датасета → версия модели → метрики». Любой эксперимент воспроизводится или откатывается.
• Регламент обновления данных — как добавляется новая порция снимков, с какой периодичностью прогоняется аугментация и по каким признакам принимается решение о переобучении.
• Правила контроля качества данных — фильтры на артефакты: размытые кадры, дубли, выбросы по яркости, нарушения разметки; пороги отбраковки и отчёт по распределению классов.
• Документация конвейера — порядок запуска, зависимости, точки расширения и разбор типовых сбоев с признаками, по которым их узнают.
• Тестовый набор с эталонным результатом — короткий срез, по которому проверяют, что окружение собрано верно и воспроизводит ожидаемый выход.

Кейс: обнаружение дефектов на производственной линии

Что было

Кейс компьютерного зрения на производственной линии: дефектов несколько типов, но микротрещины на кромке встречались примерно в 3 случаях из 1000 — редкий класс тонул в общем потоке снимков. Модель, обученная на исходном архиве, уверенно находила частые дефекты, а по редкому держала полноту 0,4-0,5. Цена ошибки двойная: пропущенная трещина уходила в отгрузку, а поток ложных срабатываний операторы перестали разбирать вручную — сигнал обесценился.

Что изменили

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

Затем порог срабатывания подобрали по кривой точности-полноты, а не «на глаз», и приёмку провели по регламенту, согласованному со службой качества в рамках процедур ISO 9001.

Что стало

Полнота по редкому классу поднялась с 0,5 до 0,93, доля пропущенных трещин сократилась более чем в семь раз. Ложные срабатывания на смену упали примерно с 40 до 6 — оператор снова смотрит на сигнал, а не игнорирует его. Переобучение шло на данных, где редкий класс представлен честно, поэтому на новых партиях качество не просело.

Чем отличается аугментация изображений на лету от предварительной?

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

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

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

Чаще выигрывает смешанный режим: тяжёлые преобразования — геометрия, вырезание фрагментов, наложение — считаются один раз и лежат рядом с оригиналом, а дешёвые — яркость, контраст, шум — применяются на лету. Разнообразие между эпохами сохраняется, дисковый след в разы меньше полного набора. Валидация при этом идёт без аугментации: только приведение размера и нормализация, иначе метрики несравнимы между запусками.

Критерий прост: политика ещё подбирается — работаем на лету; зафиксирована и обучение упирается в скорость ускорителя — собираем набор заранее. Библиотеки уровня Albumentations переключают режимы без переписывания кода.

Сомнения и ограничения: что уточняют перед стартом

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

Датасет уже собран и размечен — схему придётся переделывать?

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

Как понять, что преобразование не искажает класс?

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

Схему можно перенести на другую задачу?

Порядок работы, доли преобразований и контроль качества переносятся. Набор операций и диапазоны — нет: они зависят от того, что именно модель должна различать. На новой задаче повторяем замер и пересобираем правило, а не копируем конфигурацию.

Какие юридические ограничения учитываем?

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

Обсудим задачу и вернёмся с оценкой и планом

Постановка задачи для аугментации — это не «сделайте побольше картинок». Сначала нужно понять, какой класс объектов модель путает, чего не хватает в выборке и как мы договоримся измерять качество. Поэтому старт сотрудничества начинается не с договора, а с разбора вводных данных: так оценка проекта опирается на факты, а не на предположения.

Что описать или прислать, чтобы мы вернулись с планом:

• текущую выборку: объём, тип разметки, долю редких классов и типовые ошибки модели на отложенных примерах;
• 10–20 изображений, на которых модель ошибается чаще всего;
• целевую метрику и способ её замера — полнота по редкому классу, устойчивость к смене условий съёмки;
• ограничения контура: формат разметки, правила хранения данных, режим доступа к вашей инфраструктуре;
• условия съёмки и оборудование — от этого зависит, какие преобразования допустимы, а какие внесут искажения;
• режим приёмки: покадровая проверка, отчёт по метрикам или регулярные показы промежуточных результатов.

В ответ присылаем поэтапный план работ: очистка и разметка выборки, набор преобразований под ваш класс задач, контроль реалистичности синтетики, дообучение и сравнение с базовой моделью. У каждого этапа — критерий приёмки, чтобы результат был проверяемым, а не «на глаз».

Опишите задачу в удобном виде — вернёмся с оценкой сроков и планом работ.