Почему детекция объектов на YOLOv8 ломается в проде
Детектор уверенно проходит валидацию, а через месяц эксплуатации детекция на изображениях начинает пропускать объекты, которые раньше находила. Дело обычно не в весах: меняется сам вход — освещение, ракурс, новая камера, загрязнение оптики, другой угол обзора. Метрики на отложенной выборке при этом не двигаются, расхождение всплывает только на живом потоке.
Смена условий съёмки сдвигает статистику признаков, и редкие классы страдают первыми: их в разметке единицы, поэтому небольшое смещение уводит уверенность ниже рабочего порога. YOLOv8 держит качество внутри того распределения, на котором обучался, а частые категории в кадре доминируют — усреднённая метрика остаётся красивой, пока пропуски объектов уже не видит оператор.
Дрейф данных добавляет своё: состав объектов в потоке меняется, а разметку обновляют редко, поэтому деградация детектора проявляется уже после запуска. Слабая валидация прячет это до последнего — один общий скор не показывает, где просело качество детекции: на ночных кадрах, на мелких объектах, на дальнем плане.
Цена ошибки в детекции объектов — пропущенный дефект на линии, нераспознанный номер, потерянный инцидент в потоке. Модель формально работает, но процесс на неё уже не опирается. Разбираем, как это закрывается: раздельные метрики по классам и подгруппам, контроль дрейфа входа и регламент дообучения.
Эффект внедрения: скорость обработки, точность, устойчивость
До внедрения детектора массив изображений разбирали выборочно: оператор просматривал часть кадров, остальное уходило в архив непроверенным. При потоке в несколько тысяч кадров в сутки выборочный контроль давал долю пропусков порядка 15–20% — объект находили на этапе, когда исправлять уже дорого, а причину искали по журналам вручную.
После запуска модели на YOLOv8 разбор идёт сплошным потоком. Накопленный за месяц архив разбирается за ночь вместо недель ручной работы, новые кадры попадают в очередь с задержкой в секунды, а не часы. Скорость обработки изображений перестаёт быть узким местом — им становится только пропускная способность канала загрузки.
Точность детекции растёт не «сама по себе», а из калибровки порога уверенности на данных заказчика. Мы размечаем спорные кадры, дообучаем модель на реальных условиях съёмки и задаём пороги отдельно для каждого класса объектов. Доля ложных срабатываний падает в разы: оператор перестаёт закрывать однотипные ложные тревоги, и освободившееся внимание уходит на реальные случаи.
Устойчивость детектора проверяем на сдвигах, которые ломают лабораторные метрики: смена освещения, сезон, новый ракурс камеры, частичное перекрытие объекта. Класс отказов «модель молчит на незнакомом кадре» превращается в отказ «модель сомневается» — такие кадры уходят в очередь ручной проверки, а не теряются. Долю ручных досмотров и долю пропусков видно на панели мониторинга, поэтому деградацию ловим до того, как она станет проблемой.
Работаем на открытом стеке вокруг Ultralytics: заказчик не привязан к одному поставщику и сохраняет контроль над моделью, разметкой и порогами.
Режимы работы детектора: пакетный, потоковый, на устройстве
Режим работы определяется не моделью, а тем, откуда приходят кадры и что происходит с результатом. Одна и та же актуальная ветка YOLO в пакетном, потоковом и локальном запуске даёт разную задержку, разную нагрузку на вычислитель и разные требования к каналу связи. Поэтому сначала фиксируем сценарий, потом выбираем режим и только затем настраиваем модель.
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Пакетная обработка изображений | архив съёмки, инвентаризация, разбор снимков с дрона — тысячи файлов за один прогон | результат приходит с задержкой, реакция в реальном времени невозможна, нужен дисковый буфер и очередь заданий |
| Потоковая обработка видео | видеонаблюдение, контроль линии, подсчёт объектов в кадре | требуется стабильный канал, чувствительность к смене освещения и ракурса, обработка идёт не по каждому кадру |
| Детекция на устройстве | камера или промышленный контроллер на объекте, требования к приватности | модель урезают под память и нагрев, точность ниже серверной, обновление весов идёт вручную |
В пакетном режиме главный рычаг — группировка кадров и единое разрешение: пропускная способность растёт в разы, а порядок обработки задаётся приоритетом очереди. В потоковом настраивают шаг пропуска кадров, порог уверенности и связывание объектов между кадрами, иначе один объект считается многократно. Детекция на устройстве решает работу без сети: события пишутся локально, а на сервер уходят при появлении канала — потери кадров при обрыве связи не происходит.
Режимы комбинируются: устройство фильтрует поток, сервер перепроверяет спорные кадры, а накопленная разметка уходит в пакетную дообучающую выборку. Мы проходим по вашему сценарию и говорим, какой режим выдержит нагрузку, а какой упрётся в канал или в память устройства.
Этапы работы: от аудита данных до передачи модели
Качество детектора определяется не выбранной архитектурой, а данными и порядком работ. Мы разбиваем проект на этапы так, чтобы каждый следующий опирался на проверенный результат предыдущего: ошибка в разметке, обнаруженная после обучения, обходится в недели переделок.
- Аудит набора данных. Смотрим, что уже есть: классы и их баланс, дубли, битые кадры, разброс условий съёмки — свет, ракурс, фон. На выходе — отчёт о том, каких сценариев не хватает и какой объём кадров нужно добрать.
- Схема решения и критерии приёмки. Фиксируем, что считаем ошибкой — пропуск объекта или ложное срабатывание, — и на какой метрике договариваемся о результате. Это защищает от споров на финале.
- Разметка изображений. Регламент под конкретные классы, перекрёстная проверка спорных кадров, контроль доли пропущенных объектов в обучающей части.
- Обучение и дообучение. Стартуем с предобученной модели YOLOv8, подбираем аугментации под реальные условия съёмки, затем дообучаем на добавленных данных до выхода на целевую метрику.
- Приёмка на отложенной выборке. Проверяем на кадрах, не участвовавших в обучении: другая смена, камера, время суток. Это показывает устойчивость, а не запоминание обучающего набора.
- Передача модели. Отдаём веса, конфигурацию вывода, пороги срабатывания, скрипты прогона и документацию по дообучению на новых данных.
После передачи ваша команда может дообучать модель самостоятельно — регламент и скрипты входят в комплект. Когда объём данных вырастет, вернёмся с оценкой расширения.
Комплект поставки: конфигурации, схемы, регламенты
Комплект поставки — это не папка с весами модели, а набор артефактов, по которым ваша команда сможет сама запустить систему, обновить её под новые условия съёмки и передать сопровождение другому инженеру без нас. Ниже — что именно фиксируется в репозитории и документации к моменту сдачи.
- Конфигурация модели — файлы настроек с размером входа, порогами уверенности и подавления пересечений, списком классов и привязкой к конкретной ветке весов: один и тот же прогон даёт воспроизводимый результат на тестовом наборе.
- Схема интеграции — поток данных от камеры или хранилища до модели и обратно, с точками отказа, буферизацией кадров, форматами обмена (изображение, координаты рамок, метки, уверенность) и поведением при недоступности источника.
- Регламент переобучения — периодичность, требования к новой разметке, критерии приёмки версии и условия отката на предыдущую, если точность по классам просела.
- Документация на систему — описание архитектуры, схема развёртывания, инструкции по запуску, диагностике и типовым сбоям, включая разбор ложных срабатываний.
- Политики доступа к данным — роли, разграничение прав на исходные кадры и разметку, сроки хранения, правила обезличивания перед выгрузкой во внешний контур.
- Скрипты контроля качества — расчёт точности и полноты по классам, набор эталонных кадров, журнал прогонов: после любого изменения видно, стало лучше или хуже.
- Зафиксированное окружение — зависимости и контейнеры сборки с точными версиями, чтобы развёртывание на вашем контуре не превращалось в подбор библиотек.
Передача идёт с приёмкой: прогоняем эталонный набор вместе с вашим инженером, показываем метрики по каждому классу и отвечаем по любому пункту списка — система не должна остаться чёрным ящиком, зависящим от подрядчика.
Кейс: сократили пропуски объектов и время разбора архива
Как было
Оператор вручную просматривал архив за смену и отмечал нужные события в журнале. На плотном потоке это давало 18–22% пропусков, а на мелких и частично перекрытых объектах доля ошибок росла: глаз устаёт, контекст между кадрами теряется. Полный разбор смены занимал 6–8 часов — запись устаревала раньше, чем её успевали посмотреть.
Что изменили
Разметили поток по классам и дообучили детектор на базе YOLOv8 на реальных кадрах объекта, включая ночные и смазанные. Поверх модели поставили постобработку: связывание кадров в цепочки, отдельные пороги уверенности для каждого класса и геометрический отсев ложных рамок. Прогон сделали пакетным — обрабатывается очередь кадров, а не кадр за кадром.
Что стало
Доля пропусков упала до 3–4%, ложные срабатывания сократились примерно втрое, и оператор проверяет отобранные окна вместо всего массива. Разбор смены занимает 40–50 минут вместо 6–8 часов. Порог уверенности настраивается по каждому классу отдельно, поэтому чувствительность поднимается без роста ложных срабатываний — на практике это дало больше, чем прирост точности самой модели.
Чем YOLOv8 отличается от других семейств детекторов
Семейства детекторов различаются тем, как они ищут объект на кадре, и от этого зависят их сильные стороны. Одностадийные модели — YOLOv8, SSD, RetinaNet — выдают рамки и классы за один проход, поэтому держат поток с камер без накопления задержки. Двухстадийные схемы (Faster R-CNN) сначала предлагают области-кандидаты, а затем уточняют их: выигрывают на мелких и перекрывающихся объектах, но обрабатывают кадр заметно дольше.
Отдельная ветка — детекторы на трансформерах (DETR и наследники). Они устойчивее в плотных сценах, где объекты стоят вплотную, и меньше зависят от ручной настройки постобработки, но требуют большего объёма размеченных данных и более длительного обучения.
YOLOv8 даёт преимущество там, где критична скорость на потоке: видеонаблюдение, контроль выкладки товара, подсчёт транспорта, работа на периферийном устройстве без сервера. Модель быстро дообучается на небольшом наборе размеченных кадров, предсказуемо ведёт себя по задержке и закрывает большинство задач, где объект занимает заметную часть кадра.
Другое семейство разумнее брать, когда приоритет — качество на сложных данных: микрообъекты, дефекты на крупных снимках, сильные перекрытия, высокая цена пропуска. Здесь двухстадийная или трансформерная сборка нередко обходит YOLOv8 по полноте, а скорость уходит на второй план.
Есть и третий путь — не обучать новую модель, а дообучить уже развёрнутую, если её классы близки к вашей задаче. Мы сравниваем варианты на ваших кадрах: полнота и точность по классам, задержка на целевом оборудовании, объём разметки, который потребуется. Семейство подбираем под задачу, а не по привычке.
Технические сомнения: разметка, дообучение, работа в закрытом контуре
Разметка, дообучение и работа без внешней сети — вопросы, которые всплывают до старта, а не после. Ниже — короткие ответы по ним на примере проектов детекции объектов с моделью YOLOv8.
Сколько кадров нужно разметить и можно ли перенести готовую разметку?
Объём зависит от числа классов и разнообразия сцен: обычно несколько сотен кадров на класс, причём добираем сложные примеры, а не случайные. Готовую разметку переносим — конвертируем из распространённых форматов и сверяем на контрольной выборке; для внутреннего формата пишем конвертер отдельно. Качество держим перекрёстной проверкой: часть кадров размечают двое, расхождения разбираем до начала обучения.
Как модель ведёт себя на ночных, засвеченных, размытых кадрах?
Так, как её научили: если в выборке нет ночи, дождя, бликов и мелких объектов, ошибки будут именно на них. Поэтому собираем тест-наборы по условиям съёмки и считаем метрики отдельно по каждой подгруппе — видно, где провал, а не только среднюю цифру. При обучении подаём искажения и шум, чтобы модель не разваливалась на нестандартном кадре.
Можно ли развернуть систему в закрытом контуре?
Да. Обучение и вывод идут на вашем оборудовании: веса, зависимости и обновления доставляются через внутренний реестр, наружу не уходит ни кадр, ни метка. Для полностью изолированного контура готовим переносимый комплект для установки вручную и проверяем его на вашем стенде.
Что происходит с дообучением на своих данных после запуска?
Кадры, где модель ошиблась или сработала неуверенно, попадают в очередь на разметку, затем — в дообучение. Версии весов нумеруем, откат к предыдущей — одна команда. Механику передаём вашей команде вместе с инструкциями, чтобы цикл обновления не зависел от нас.
Обсудим задачу: что прислать для оценки и плана
Чтобы оценка проекта детекции опиралась на факты, а план работ — на реальные условия, не нужен весь архив данных. Достаточно выборки и описания ограничений. Ниже — что прислать для обсуждения задачи.
- выборку 50–200 файлов — изображения или короткие видео, включая сложные кадры: плохое освещение, перекрытия, мелкие объекты;
- список целевых классов и правила разметки: что считаем обнаружением и нужна ли рамка вокруг объекта;
- условия съёмки: ракурсы камер, дистанцию, движение — от этого зависит, хватит ли модели семейства YOLO актуальной ветки или понадобится дообучение на ваших данных;
- где считается вывод модели: сервер с ускорителем, облако или устройство на объекте, и какая задержка обработки кадра допустима;
- точку интеграции: куда уходит событие — в веб-сервис, очередь сообщений или действующую систему — и в каком виде;
- требования к качеству: допустимую долю пропусков и ложных срабатываний и свой размеченный набор для приёмочной проверки;
- ограничения по данным: можно ли выносить кадры за периметр и нужна ли работа полностью на вашем оборудовании.
С этим набором мы возвращаемся с оценкой сроков и планом работ по этапам: проверка данных и разметки, базовый прогон, дообучение под ваши классы, интеграция и приёмка на согласованных метриках. Если часть данных ещё не готова — начнём с того, что есть, чтобы оценка всё равно была предметной.
