Главная / Блог / Компьютерное зрение / Типичные ошибки при обучении моделей зрения

Типичные ошибки при обучении моделей зрения

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

Почему ошибки почти всегда в данных

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

Ниже мы разберём ошибки по этапам проекта: от постановки задачи до запуска. Для каждой даём признаки, по которым её можно заметить, и что с ней делать.

Ошибки постановки задачи

Размытое определение классов

Если два человека по-разному ответят на вопрос «что считать объектом этого класса?», модель получит противоречивые примеры. Типичные случаи: считать ли деталь с небольшой царапиной браком, относить ли частично видимый предмет к классу, учитывать ли отражение объекта в стекле.

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

Задача не соответствует реальным условиям

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

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

Ошибки данных

Утечка между обучением и валидацией

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

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

Ошибки в разметке

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

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

Дисбаланс классов

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

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

Смещение выборки

Все примеры одного класса сняты на одном фоне, а другого класса на другом. Модель выучит фон вместо объекта. Классический пример из публикаций: классификатор «волк или собака», который на деле определял снег на заднем плане.

Признак: резкая потеря качества при смене фона или освещения. Решение: разнообразить фоны и условия для всех классов поровну, проверять модель методами интерпретации, например картами внимания.

Слишком мало разнообразия при большом количестве кадров

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

Ошибки обучения

Неудачные аугментации

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

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

Неправильная скорость обучения и сроки

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

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

Игнорирование предобученных весов

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

Решение: начинать с предобученных весов, на первых эпохах замораживать часть слоёв, затем размораживать и снижать скорость.

Ошибки оценки

Единственная цифра метрики

Смотреть только на общий mAP — значит не видеть слабых классов, мелких объектов и конкретных сценариев отказа. Нужны метрики по классам, по размерам и по условиям съёмки.

Подгонка под валидацию

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

Игнорирование порога уверенности

Модель выдаёт вероятности, а в продакшене нужен конкретный порог. Метрики, посчитанные при одном пороге, и поведение системы при другом могут сильно различаться. Порог подбирают по кривой precision-recall с учётом цены каждого типа ошибки. Разбор этих понятий — в статье Метрики детекции: mAP, IoU, precision и recall без путаницы.

Ошибки перехода в продакшен

Разный препроцессинг. При обучении изображения нормализуются и меняют размер одним способом, а в сервисе другим: другая интерполяция, другой порядок каналов, другое соотношение сторон. Модель получает данные «не того вида». Это одна из самых частых причин необъяснимого падения качества.
Отсутствие мониторинга. Через несколько месяцев камеру сдвинули, поменяли освещение или партию продукции, и качество тихо деградирует. Нужен мониторинг распределения предсказаний и регулярная переразметка небольшой выборки.
Нет процесса дообучения. Модель воспринимают как разовый артефакт. На деле это живой компонент, которому нужны новые данные и переобучение.
Игнорирование задержки. Модель отлично работает в ноутбуке, но не успевает за потоком. О задачах запуска на ограниченном железе мы писали в статье о компьютерном зрении на edge-устройствах.

Чек-лист перед запуском обучения

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

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

Часть перечисленных проблем снимается на уровне источника данных. Синтетические датасеты не имеют ошибок разметки, позволяют точно контролировать баланс классов и разнообразие условий и дают нужное количество редких случаев. Если хотите проверить, как это будет работать на вашей задаче, напишите на [email protected]: тестовый датасет предоставляется по запросу.

Нужен датасет под вашу задачу?

Подготовим тестовую партию изображений с разметкой, чтобы вы могли проверить подход на своей модели. Напишите на [email protected] или оставьте заявку.