Чому детекція об'єктів на 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 актуальної гілки або знадобиться донавчання на ваших даних;
- де обчислюється вивід моделі: сервер із прискорювачем, хмара або пристрій на об'єкті, і яка затримка обробки кадру допустима;
- точку інтеграції: куди надходить подія — у вебсервіс, чергу повідомлень або чинну систему — і в якому вигляді;
- вимоги до якості: допустиму частку пропусків і хибних спрацювань та свій розмічений набір для приймальної перевірки;
- обмеження щодо даних: чи можна виносити кадри за периметр і чи потрібна робота повністю на вашому обладнанні.
Із цим набором ми повертаємося з оцінкою строків і планом робіт за етапами: перевірка даних і розмітки, базовий прогін, донавчання під ваші класи, інтеграція та приймання на узгоджених метриках. Якщо частина даних ще не готова — почнемо з того, що є, щоб оцінка все одно була предметною.
