Чому сегментація зображень ламається на реальних даних
Сегментація зображень ламається не на тестовій вибірці, а на реальному потоці кадрів.
Модель, яка на підготовлених даних дає рівні контури, у роботі починає рвати маски: межі тремтять від кадру до кадру, усередині об'єкта з'являються дірки, а рідкісний клас об'єктів узагалі зникає з передбачення.
Перша причина — нестабільне знімання. Світло змінюється від зміни до зміни, камера зміщується на кілька градусів, об'єкт надходить під іншим кутом, а шум у кадрі зростає: відблиски, пил на оптиці, змаз від руху.
Модель вчиться не на об'єкті, а на умовах знімання, і за нового освітлення впевнено розмічає тіні замість дефекту.
Друга — неоднорідна розмітка масок. Поки анотатори працюють за різними правилами, один обводить зовнішній контур, інший — внутрішній, спірні пікселі йдуть у фон. Модель усереднює суперечності й віддає розмиту межу там, де потрібна точність до пікселя.
Третій шар — рідкісний клас об'єктів. Коли прикладів одиниці, а фон домінує, модель вивчає частотний розподіл і передбачає більшість. Помилка спливає там, де за маскою вже ухвалюється рішення: відбраковування партії, підрахунок площі дефекту, контроль геометрії.
Оператор перестає довіряти системі й повертає ручну перевірку — виграш від автоматизації з'їдається. Розбираємо, як це закривається: від протоколу знімання та регламенту розмітки до перевірки на навмисно складних кадрах.
Що змінюється після впровадження: ефекти та метрики
Перший вимірюваний ефект — частка кадрів, що йдуть на ручну перевірку. До впровадження оператор переглядає майже весь потік, після — лише спірні випадки, зазвичай 10–20% кадрів. Його час іде на порубіжні ситуації, де модель не впевнена, а не на механічний перегляд усього архіву.
Точність моделі вважаємо не однією цифрою, а за класами дефектів: окремо повнота — частка реальних дефектів, які знайшли, — і окремо частка хибних спрацювань.
Пропущений дефект дорожчий за зайву тривогу, тому пороги для критичних класів зміщуємо в бік чутливості, а межі об'єктів уточнюємо другою моделлю на кшталт SAM: маска не «пливе» на кадрах із низьким контрастом.
Швидкість обробки кадру видно за двома режимами. Пакетний розбирає архів за хвилини замість годин, потоковий устигає за камерою на лінії — і вузьким місцем стає не мережа, а постобробка масок і логіка відбраковування.
Окремо перевіряємо стійкість до зміни умов знімання: інше освітлення, нова оптика, зміщений ракурс, змінена партія сировини.
Метрика тут — просідання якості на відкладеній вибірці з нових кадрів; якщо воно вище за обумовлене, дообучаємо модель на 5–10% свіжих прикладів і проганяємо перевірку заново.
Кількість пропущених дефектів і частка ручної перевірки живуть не у звіті на здачі, а в постійному порівнянні: еталонний набір кадрів проганяється за кожного оновлення моделі, і регрес видно до викочування на лінію.
Порівняння підходів: готова модель, дообучення, власна архітектура
Вибір між трьома режимами визначає не розмір вибірки, а те, наскільки цільові об'єкти відрізняються від того, що модель уже бачила.
Попередньо навчена модель — Segment Anything та її аналоги — дає робочу маску майже без розмітки, поки класи об'єктів універсальні: люди, транспорт, дорожнє покриття, будівлі.
Щойно з'являються вузькі класи — дефекти зварного шва, конкретні типи тканин, стадії стиглості плоду — якість падає: межі «пливуть», модель упевнено виділяє не те.
Дообучення на власних даних закриває цей розрив, але впирається в контурну розмітку: піксельні маски розмічаються в рази повільніше за рамки й потребують узгодження того, що вважати межею об'єкта.
Власна архітектура виправдана рідко — коли є жорсткі вимоги до швидкості на пристрої, нестандартні вхідні канали або потрібно вбудувати предметну логіку прямо в модель.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Попередньо навчена модель | Класи об'єктів універсальні, розмітки немає або мало | Не розрізняє вузькі класи, слабкий контроль над межами |
| Дообучення на власних даних | Є сотні контурно розмічених кадрів, класи специфічні | Дорога розмітка, потрібен контроль дрейфу за зміни знімання |
| Власна архітектура | Жорсткі вимоги до швидкості, нестандартні канали, предметна логіка | Довше впроваджується, складніше підтримувати й оновлювати |
На практиці ми починаємо з попередньо навченої моделі та дообучення — це дає перший робочий результат на десятках розмічених кадрів.
Власну схему й вибір архітектури пропонуємо лише тоді, коли можемо показати, що саме вони дають порівняно з дообученням: виграш за швидкістю або стійкість до нестандартного входу. Опишіть задачу — повернемося з оцінкою обсягу розмітки та планом.
Етапи роботи: від аудиту даних до передачі моделі
Сегментація на старті впирається в дані, а не в архітектуру: вибір між U-Net, SegFormer і підходом на основі SAM — питання останнього кроку.
Розмітка та метрики вирішують, чи буде модель придатна в роботі, тому проєкт іде фіксованою послідовністю, де кожен етап закривається артефактом, який можна перевірити.
-
Розбір задачі та метрик. Фіксуємо, що вважається об'єктом на знімку: класи, межі, мінімальний розмір значущої області. Домовляємося про цільову метрику — IoU та Dice за кожним класом окремо, а не одне усереднене число.
-
Аудит даних. Дивимося фактичний корпус: скільки кадрів, як їх знято, які класи рідкісні, де дублі та биті файли. Підсумок — звіт із чесною оцінкою, чи вистачає даних і що потрібно добрати.
-
Схема розмітки та підготовка набору. Пишемо інструкцію для анотаторів із порубіжними випадками, вводимо перехресну перевірку частини масок і автоперевірки на порожні та вироджені області.
Дані ділимо за сценаріями знімання, щоб кадри однієї серії не потрапили і в навчання, і в перевірку.
-
Навчання та контроль. Підбираємо архітектуру й роздільну здатність під задачу, стежимо за перенавчанням, зберігаємо контрольні точки. Проміжні метрики дивимося не лише середні, а й за рідкісними класами.
-
Перевірка на відкладеній вибірці. Фінальна оцінка йде на тесті, який не брав участі ні в навчанні, ні в підборі параметрів. До метрик додаємо розбір найгірших прикладів — де модель плутає класи й чому.
-
Передача моделі та навчання команди. Віддаємо ваги у форматі для інференсу, препроцесинг, правила версіонування та скрипт відтворення. Показуємо, як дообучити модель на нових даних і як помічати падіння якості.
Що ви отримуєте на руки: розмітка, ваги, документація
Модель, яка добре працює на демонстраційних прикладах, і модель, яку можна експлуатувати, — різні речі. Різниця в тому, що після приймання залишається на руках: відтворюваний набір даних, ваги, до яких прив'язані конкретні метрики, і правила, за якими рішення оновлюється без нас. Тому здаємо не «навчену мережу», а комплект, де кожен артефакт можна перевірити й перезібрати.
- Розмічений набір даних — маски за всіма цільовими класами в єдиному форматі, з фіксованим поділом на навчання, валідацію та відкладений контроль. Розмітка версіонується: видно, які області правилися, ким і на якій підставі, а метрика будь-якої версії моделі відтворюється на тому самому зрізі даних.
- Навчені ваги моделі — підсумкові та контрольні точки навчання разом із конфігурацією, за якої їх отримано: архітектура (U-Net, SegFormer, SAM-підхід — під задачу), схема аугментацій, параметри навчання, фіксація випадковості. Запуск повторюється й дає зіставний результат.
- Версії розмітки — журнал змін із причиною правок і зв'язком «версія даних → метрика». Це дає змогу відрізнити покращення моделі від покращення розмітки й не перенавчатися на помилках анотаторів.
- Схема конвеєра — передобробка, нарізання великих зображень на фрагменти з перекриттям і зворотним складанням, постобробка масок (фільтрація дрібних областей, згладжування меж), формат виходу під вашу систему.
- Регламент контролю якості — метрика згоди між розмітниками (IoU за класами) і частка спірних пікселів; маска йде на переперевірку, якщо розходження вище за поріг, а не «на око».
- Регламент перенавчання — тригери (падіння метрики на новому домені, дрейф знімання, новий клас об'єктів), порядок дій, хто ухвалює рішення про викочування і як валідується нова версія перед заміною поточної.
- Документація щодо моделі — картка моделі з даними навчання, межами застосовності, відомими класами помилок, інструкцією запуску та відкату на попередні ваги.
- Скрипти навчання та оцінки — відтворюваний запуск на вашій інфраструктурі, щоб перенавчання не перетворювалося на разовий проєкт.
Кейс: контроль дефектів на виробничій лінії
На ділянці контроль дефектів тримався на операторах: з потоку перевірялася лише вибірка кадрів, решта йшла у відвантаження.
До кінця зміни увага падає, і дрібні подряпини, вм'ятини та непровар по кромці спливали вже на вхідному контролі в замовника — це переробка партії, повторна логістика та простій лінії.
Спочатку розмітили кілька тисяч кадрів з реальної лінії, потім навчили сегментаційну модель на базі SAM і дообучили її під чотири класи дефектів, відділивши їх від допустимих слідів обробки.
Прогін моделі поставили в потік камери: рішення ухвалюється до переходу деталі на наступну операцію, а не на фінальному прийманні.
Метрики до і після
| Метрика | До | Після |
|---|---|---|
| Частка кадрів із ручною перевіркою | вибірка, близько третини потоку | весь потік, оператор дивиться лише спірні кадри |
| Пропущений дефект у відвантаженні | поодинокі випадки щозміни | розбирається на ділянці, до наступної операції |
| Склад дефектів | ловилися здебільшого великі | дрібні подряпини та непровар кромки теж під контролем |
| Хибні спрацювання | не відстежувалися | поріг підібрано так, щоб лінія не зупинялася |
Поріг упевненості налаштували окремо: порубіжний кадр модель позначає як спірний і віддає оператору, лінія через нього не зупиняється.
Це прибрало головну причину, через яку суцільний контроль раніше не приживався — потік хибних спрацювань, після якого оператори перестають довіряти системі.
Дообучення на нових кадрах іде тим самим контуром: розмітка, перевірка на відкладеній вибірці, заміна ваг після підтвердження метрик.
Чим сегментація зображень відрізняється від детекції об'єктів?
Детекція відповідає на питання «де об'єкт»: модель повертає прямокутник із координатами та клас. Сегментація відповідає на питання «які саме пікселі належать об'єкту»: на виході маска розміром з вихідний кадр, де кожному пікселю присвоєно клас або мітку фону.
Рамка завжди захоплює фон і не розділяє об'єкти, які перекриваються або торкаються один одного. Для обліку цього достатньо: виявили, порахували, відправили на перевірку.
Але коли потрібно виміряти площу дефекту, відділити листя від ґрунту або вирізати предмет за контуром, прямокутник дає похибку, яку потім нічим виправити — маска будується за реальною межею.
Різниця у витратах праці проявляється на розмітці. Рамка — секунди на об'єкт, маску малюють хвилинами, а вимоги до узгодженості анотаторів вищі: спірні пікселі на межі розмивають навчання.
Замовник платить за цю складність лише тоді, коли підсумкове рішення справді використовує піксельну точність.
Рамки беруть для підрахунку та відстеження об'єктів, пошуку за каталогом, сигналізації про появу об'єкта в кадрі. Маски — для медичних знімків, дефектоскопії, аерофотознімання, вирізання фону та будь-яких розрахунків площі й форми.
На практиці це не взаємовиключний вибір: детектор пропонує регіони, а модель сегментації (U-Net, SegFormer і споріднені архітектури) уточнює межі всередині них. Гібридна схема знижує обсяг дорогої розмітки й тримає точність на піксельному рівні там, де вона потрібна.
Технічні сумніви перед стартом проєкту
Інженери замовника ставлять схожі питання, і майже всі вони про процес, а не про архітектуру: скільки даних готувати, як зловити перенавчання, що залишиться всередині периметра. Нижче — короткі відповіді, з яких починається технічна частина обговорення.
Скільки зображень потрібно розмітити?
Обсяг вважаємо від числа класів і різноманітності сцен, а не від розміру архіву. Спочатку невеликий набір і базова модель, потім розбір помилок на відкладеній вибірці — і прицільна розмітка провальних сцен. Точність меж об'єктів впливає на результат сильніше, ніж кількість кадрів.
Як зрозуміти, що модель перенавчилася?
Тримаємо відкладену вибірку, зібрану за іншими знімальними днями: розходження метрик на навчанні та на ній — сигнал зупинитися, підсилити регуляризацію й добрати рідкісні сцени. Перенавчена модель упевнено помиляється на нових кадрах, тому приймання робимо лише на них.
Що робити, коли кадри застаріють?
Зміна оптики, світла або ракурсу — звичайна причина падіння якості. Закладаємо дообучення: свіжі кадри з ручною правкою повертають модель до попередніх метрик без повного перезбирання. Розмітку та ваги зберігаємо так, щоб відкат на попередню версію займав один запуск.
Чи можна запустити рішення на нашому обладнанні?
Так: передаємо конфігурацію навчання, ваги та скрипти підготовки розмітки, ваші інженери розгортають усе в себе. Кадри не покидають периметр, за потреби навчання йде на ізольованому стенді без зовнішнього доступу.
Обговоримо задачу та повернемося з оцінкою і планом
Щоб оцінка проєкту спиралася на факти, а не на припущення, для старту потрібні приклади реальних знімків, перелік класів і вимоги до точності.
За ними ми відтворюємо розмітку на невеликій вибірці й перевіряємо, чи віддільна цільова область від фону — часто вже тут видно, що частина класів нерозрізненна без зміни умов знімання.
У відповідь надсилаємо розбір задачі, склад робіт, схему перевірки якості та план робіт із точками узгодження. Пілотний запуск іде на обмеженому наборі даних: метрики вважаємо на ваших знімках, і рішення про повний обсяг ухвалюється за ними, а не за обіцянками.
- Що потрібно від вас: 100–300 знімків на кожен сценарій знімання, експерт для перевірки спірних випадків, доступ до середовища розгортання.
- Розбір задачі: тип сегментації — бінарна, багатокласова, за екземплярами — і формат результату: маски, полігони, площі об'єктів.
- Склад робіт: розмітка набору даних, навчання та порівняння архітектур, постобробка масок, вбудовування моделі у ваш процес.
- Схема перевірки якості: відкладена вибірка, частка правильних пікселів і перетин передбачених масок з еталоном, окремий контроль на рідкісних класах.
- Пілотний запуск: навчання на частині даних і замір метрик на реальних знімках; критерії приймання фіксуємо до початку робіт.
- План робіт: етапи, строки, точки узгодження та відповідальний з кожного боку. План передачі: ваги моделі, конфігурації запуску, інструкція з дообучення на нових даних.
Опишіть задачу — повернемося з оцінкою та планом.
