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

Обучение YOLO на собственном датасете: пошаговый разбор

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

Почему именно YOLO

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

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

Шаг 1. Подготовка структуры датасета

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

Типичная структура каталогов выглядит так:

папка images с подпапками train, val, test;
папка labels с зеркальной структурой подпапок;
файл конфигурации в формате YAML с путями и списком классов.

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

Шаг 2. Разделение данных

Кадры нужно разделить на обучающую, проверочную и тестовую части. Типичные пропорции — семьдесят, пятнадцать и пятнадцать процентов, но важнее принцип разделения, а не цифры.

Как не испортить оценку

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

Шаг 3. Выбор размера модели и входного разрешения

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

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

Ситуация	Что делать с разрешением
Объекты крупные, больше пятой части кадра	Небольшое разрешение, ускорение
Объекты средние	Стандартное разрешение модели
Объекты мелкие, видны плохо	Увеличить разрешение или нарезать кадр
Сильно вытянутый кадр, например панорама	Сохранять пропорции, не сжимать до квадрата

Шаг 4. Предобученные веса и первый запуск

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

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

Контрольный список первого запуска

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

Шаг 5. Основное обучение и гиперпараметры

Для основного запуска полезно знать, какие параметры действительно влияют на результат.

Число эпох. Для небольших наборов хватает от пятидесяти до ста пятидесяти. Включите раннюю остановку, чтобы не гонять обучение после выхода на плато.
Размер пакета. Больше — стабильнее, но упирается в память. Можно накапливать градиенты.
Скорость обучения. Значения по умолчанию обычно разумны. Менять стоит, если потери скачут или не снижаются.
Аугментации. Мозаика, сдвиги, масштаб, цветовые сдвиги. Для небольших наборов они спасают от переобучения. Для задач, где зеркальное отражение меняет смысл, отключайте отражения.
Замораживание слоёв. На очень малых наборах полезно сначала заморозить часть слоёв, а затем разморозить.

Если данных мало, а редкие классы почти не представлены, подумайте об аугментации набора: вставке объектов в новые фоны и расширении вариативности. Мы делаем это в рамках услуги по аугментации датасетов.

Шаг 6. Чтение метрик и разбор ошибок

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

Что смотреть помимо среднего значения

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

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

Как вести эксперименты, чтобы не запутаться

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

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

Шаг 7. Подбор порога и пост-обработка

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

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

Шаг 8. Экспорт и развёртывание

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

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

Типичные сбои и их причины

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

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

Что в итоге

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

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

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