Чому сегментація зображень ламається на реальних даних
Модель, яка на публічному наборі на кшталт COCO віддає охайні маски, на виробничих знімках провалюється за цілими класами. Причина зазвичай не в архітектурі: у відкритій розмітці класи збалансовані, світло рівне, об'єкти знято з однієї точки.
Реальні дані приходять із різних цехів і з різних камер — із відблисками, пилом, перекриттями, — і середня метрика за вибіркою залишається пристойною, поки рідкісний клас не йде в нуль.
Джерел втрат чотири, і вони складаються. Незбалансовані класи: якщо дефект займає частки відсотка пікселів, базова функція втрат просто ігнорує його — потрібні ваги класів, таргетні аугментації та стратифікована перевірка, інакше модель «учиться» передбачати фон.
Дрейф даних між партіями: зміна камери, освітлення або сезону зміщує розподіл кольорів і контрасту, і точність просідає на нових поставках, хоча на відкладеній вибірці з попередньої партії все стабільно.
Далі — якість розмітки та шум на знімках. Різні анотатори по-різному трактують межу дефекту, полігони «гуляють» на кілька пікселів, а частина об'єктів взагалі пропущена — модель відтворює цю невизначеність як помилку.
Сенсорний шум, пересвіт від лампи та змаз від руху додають хибні спрацьовування на текстурах. Найсильніше це б'є по помилках на межах об'єктів: маска формально є, але контур розмитий, і будь-яка метрика площі або лінійного розміру вважається невірно.
Розбираємо, як це закривається: стратифікація вибірки, консенсус-розмітка, контроль дрейфу та постобробка контурів.
Вимірюваний ефект: точність, швидкість конвеєра, ручна перевірка
Що змінюється насамперед — частка кадрів, які людина зобов'язана переглянути очима. До впровадження маска будується, але поріг упевненості виставлений із запасом, тому на перевірку йде помітна частина потоку, включно із явно порожніми областями.
Після калібрування порога за розміченою контрольною вибіркою на ручний догляд залишається лише спірний клас: вихід за довірчий інтервал, рідкісні об'єкти, знімки, де маска зачіпає межу зони інтересу.
Частка ручної перевірки падає з десятків відсотків до одиниць, і окремо контролюється, що пропуски при цьому не зростають.
Друга метрика — стабільність якості на нових даних. Ми дивимося результат не лише на відкладеній вибірці, а й на партіях, знятих в інших умовах: інше освітлення, інша камера, зміщений ракурс, інша щільність об'єктів у кадрі.
Якщо розкид між партіями вкладається в узгоджений допуск, конвеєр готовий до потоку; якщо ні — додаємо приклади проблемного класу, дообучаємо та переперевіряємо заново, а не підкручуємо поріг вручну.
Швидкість обробки партії визначається не лише самою моделлю, а й обв'язкою навколо неї: передобробка, нарізка великих знімків на фрагменти, агрегація масок і постобробка меж.
Тут виграш дає відмова від зайвих проходів — наприклад, легка модель відсіює порожні фрагменти, і важка працює лише там, де є що сегментувати. Партія, яка раніше оброблялася годинами, вкладається в хвилини, причому час на кадр перестає залежати від його насиченості.
Повторюваність результату — те, що замовник перевіряє першим під час приймання.
Один і той самий знімок за одного й того самого набору ваг і налаштувань дає одну й ту саму маску, а кожна версія моделі та її параметри фіксуються в журналі: видно, чим оброблено конкретний кадр і що зміниться під час відкату.
Без цього метрики нічого не значать — покращення на нових даних неможливо відрізнити від випадкового розкиду. Тому цифри щодо точності, швидкості та частки ручної перевірки ми здаємо разом із відтворюваним протоколом прогону, а не окремим звітом.
Режими сегментації зображень: попіксельний, об'єктний, панорамний
Режим розбору сцени фіксує три речі одразу: архітектуру моделі, формат розмітки та метрику приймання. Обраний під модну архітектуру, а не під задачу, він змушує перорозмічати корпус і перенавчати модель. Тому режим визначаємо до першого рядка розмітки.
| Режим | Що потрапляє в маску | Коли підходить | Обмеження |
|---|---|---|---|
| Попіксельна класифікація | кожен піксель віднесено до класу, об'єкти одного класу злиті в область | контроль площ і дефектів: частка пошкодженої поверхні, зони рослинності | не розділяє об'єкти, що стоять впритул — вони зливаються в одну область |
| Розділення об'єктів | окрема маска на кожен екземпляр, зокрема всередині одного класу | підрахунок штук: деталі на конвеєрі, клітини, транспорт, одиниці товару | більше часу анотатора на кадр, складніше щільні сцени з перекриттям |
| Панорамний розбір сцени | усі об'єкти окремо плюс фон як окремий клас | автономний рух, робототехніка, розбір вулиці, де важливий і фон, і кожен об'єкт | найдорожчий корпус розмітки, помилка на будь-якому шарі класів тягне решту |
Схема класів виводиться з режиму: класи не перетинаються за змістом, рідкісні стани краще виносити окремо, ніж звалювати в «інше». Режими сумісні за даними — попіксельна збирається об'єднанням об'єктних масок за класом, панорамна додає шар фону. Розширення задачі не вимагає розмічати корпус з нуля.
Етапи впровадження: від аудиту даних до передачі моделі
Порядок етапів тут не формальність. Якщо пропустити аудит даних або зафіксувати схему класів уже після першої розмітки, помилки спливуть на навченій моделі, а частину масок доведеться викинути й розмічати заново.
Тому робота йде від розбору даних до передачі, і на кожному кроці залишається перевірюваний артефакт.
- Аудит набору даних. Дивимося, що вже відзнято й розмічено: покриття сценаріїв, дублікати, кадри без об'єктів, дисбаланс класів. На виході — звіт із рішенням, які сцени дозняти, а яку розмітку переробити.
- Схема класів і правила розмітки. Фіксуємо ієрархію класів, що вважається окремим об'єктом, як розмічати перекриття та межі. Правила записуємо текстом: без них різні розмітники дадуть різні маски на одному й тому самому кадрі.
- Складання навчального контуру. Навчання з розширенням набору під реальні умови зйомки — світло, ракурс, часткові перекриття. Дані та ваги версіонуємо, щоб будь-яку ітерацію можна було порівняти з попередньою.
- Перевірка на відкладеній вибірці. Рахуємо метрики за кожним класом окремо, а не середнє за моделлю: рідкісний клас не повинен розчинятися в загальній точності.
- Перевірка на реальних партіях. Проганяємо рішення на кадрах з робочих камер, яких модель не бачила, розбираємо помилки й додаємо складні випадки назад у навчання.
- Передача рішення. Віддаємо ваги, конфігурацію схеми класів, інструкцію з дообучення та метрики на контрольному наборі — команда веде модель далі сама.
Артефакти передачі: конфігурації, схеми класів, регламенти
Поки рішення працює в нашій інфраструктурі, його поведінка тримається на людях, які його збирали. Передача — це момент, коли все, що жило в голові інженера, стає файлами у вашому репозиторії. Нижче — мінімальний комплект, без якого супровід перетворюється на залежність від підрядника.
- Конфігурація конвеєра: файли параметрів передобробки, масштабування, спотворень кадру та порогів спрацьовування моделі — з поясненням, які значення змінювалися під задачу і чому.
- Схема класів: словник масок з описом, що вважається межею об'єкта, а що фоном, і як трактуються спірні випадки на стику класів.
- Інструкція з розмітки: правила анотування з прикладами складних кадрів, критерії приймання та список перевірок для нових анотаторів.
- Регламент дообучення: коли запускається перенавчання, на яких даних, як перевіряється, що якість не погіршилася за рідкісними класами.
- Контрольний набір кадрів: еталонні маски, які проганяються перед публікацією кожної нової версії моделі.
- Документація рішення: схема конвеєра, точки підключення до ваших систем і порядок відкату на попередню версію.
- Журнал експериментів: які підходи перевірялися і чому від них відмовилися, щоб не проходити цей шлях заново.
Такий комплект дає змогу вашій команді змінювати модель без нас: правити розмітку, дообучати на нових кадрах, відкочувати версію. Опишіть задачу — повернемося з оцінкою та планом передачі.
Кейс: відбраковування на лінії — метрики до і після впровадження
До автоматизації контроль якості на лінії тримався на людях: контролер знімав з конвеєра кожну двадцяту одиницю й оглядав вручну.
До третьої години зміни увага падала, а напливи клею, зміщені етикетки та розриви шва на темному пакуванні проходили повз — партія з дефектом їхала замовнику, далі повернення й повторне пересортування всієї партії.
Що змінили
На виході лінії поставили камеру й навчили модель сегментації на розмітці реальних знімків (PyTorch). Семантична розмітка відокремлює пакування від фону та стрічки транспортера, поекземплярна — обводить межі кожного дефекту, тому відблиск на плівці не плутається з розривом шва.
Поріг спрацьовування підбирали за кривою помилок: важливіше було не пропустити дефект, але й не зупиняти лінію хибними спрацьовуваннями. Відбраковування дефектів відбувається прямо в потоці, скидання в брак синхронізовано з відвідним механізмом.
Метрики до і після
- Зниження пропусків: близько 8% браку йшло до споживача за ручної вибірки — стало менше 1% на відкладеній вибірці знімків.
- Хибні спрацьовування: 4% → 1,5% після калібрування порога й заміни підсвічування на розсіяне.
- Покриття: замість одного знімка з двадцяти перевіряється 100% потоку, швидкість конвеєра не знижується.
- Переналагодження на новий типорозмір пакування: дообучення на кількох сотнях розмічених знімків замість переписування правил контролю.
Чим відрізняється семантична розмітка від розділення об'єктів?
Семантична розмітка присвоює клас кожному пікселю, але не розрізняє екземпляри: три автомобілі в кадрі зливаються в одну пляму класу «автомобіль».
Розділення об'єктів додає другий рівень — ідентифікатор екземпляра, тому сусідні об'єкти одного класу залишаються роздільними, і їх можна порахувати. Різниця проявляється саме на межах об'єктів.
У семантиці піксель на стику двох класів — конфлікт міток, який вирішується пріоритетом класу або арбітражем за впевненістю моделі.
У підході з розділенням об'єктів та сама точка вирішує іншу задачу: якому екземпляру вона належить, і тут працюють морфологія маски, згладжування контурів і придушення перекривних масок.
Одна й та сама помилка на межі дає різний клас дефекту: розмиту кромку проти склеєних або розрізаних об'єктів.
Звідси вимога до схеми класів. Для розділення об'єктів класи мають бути плоскими та взаємовиключними, а фізичні накладення — людина на мотоциклі, провід перед фасадом — вирішуються шарами та порядком відрисовки.
Перетинні класи в семантиці живуть спокійно, але кожне накладення потрібно описати правилом пріоритету: інакше сусідні розмітники трактують стик по-різному, і розходження між ними напряму з'їдає точність моделі.
Вибір диктує задача. Потрібна площа класу — дорога, рослинність, дефект покриття — беремо семантичну розмітку: розмітка дешевша, навчання стійкіше до рідкісних класів. Потрібні кількість, розмір і траєкторія кожного об'єкта — беремо розділення.
Суміщений варіант зберігає обидва шари в одному наборі, наприклад у форматі COCO: фон іде семантикою, об'єкти — масками з ідентифікаторами.
Технічні сумніви: обмеження, підтримка, дообучення
Сумніви перед стартом рідко стосуються архітектури — частіше вони про дані та експлуатацію: чи вистачить прикладів на рідкісний клас, що робити з уже накопиченою розміткою за іншою схемою і хто дообучає модель, коли з'являються нові знімки. Нижче — прямі відповіді на три таких питання.
Загальний принцип: вимоги до даних фіксуємо до розмітки — мінімальна площа об'єкта, правила перекриттів, як позначати неоднозначні кадри. Тоді спірні випадки вирішує протокол, а не смак конкретного розмітника.
Рідкісний клас — одиниці об'єктів на весь набір. Модель його взагалі побачить?
Розділяємо вибірку за класами, а не за кадрами цілком, і додаємо в навчання перевагу рідкісного класу у функції втрат.
Упевненість щодо нього виставляємо окремим порогом, а метрики рахуємо за кожним класом, а не середнім числом: загальна частка правильних рішень маскує провал на рідкісному.
Якщо об'єктів менше десятків, чесніше спочатку прототип — іноді дешевше знайти клас правилом постобробки, ніж збирати під нього дані.
Розмітка вже є, але схема інша
Схему переносимо програмно: контури переводимо в маски, вкладені та перетинні області розводимо за пріоритетом класів, занадто дрібні об'єкти відкидаємо за порогом площі.
Якщо у вас розмічали прямокутниками, частину масок відновлюємо передрозміткою моделі й домальовуємо руками — це швидше, ніж починати з нуля. Після конвертації проганяємо контроль: частка об'єктів без класу, конфліктні мітки, кадри без жодної області.
Дообучати доведеться своїми силами — що для цього потрібно
Передаємо відтворюваний сценарій навчання й перевірки: конфігурацію, розбиття на набори, версіонування розмітки та ваг, щоб будь-який результат можна було відкотити. Дообучення запускається на нових даних із домішкою старих — інакше модель втрачає раніше вивчені класи.
Підтримка рішення зводиться до спостереження за часткою невпевнених передбачень і дрейфом вхідних даних: зростання цієї частки — сигнал, що пора дорозмічати й перенавчати.
Обговоримо задачу: що надіслати для точної оцінки
Точність оцінки в сегментації тримається не на обсязі вибірки, а на тому, наскільки однозначно описані класи, крайові випадки та потрібна якість. Нижче — що надіслати, щоб ми повернулися з планом етапів, строками та схемою класів, а не із загальними формулюваннями.
- Постановка задачі — що має бути на виході: одна маска на клас, окремі об'єкти чи розмітка сцени цілком, і як результат використовується далі.
- Вхідні дані — 20–50 знімків у вихідному вигляді, включно з найнезручнішими: слабке світло, перекриття, шум, рідко вживані класи.
- Розмітка — чи є вона, у якому форматі (PNG-маски, полігони, готовий набір), хто розмічав і наскільки узгоджені спірні об'єкти.
- Схема класів — перелік класів, їхня ієрархія та правила для неоднозначних випадків: перекриття, часткова видимість, об'єкти біля межі кадру.
- Вимоги до якості — прийнятна метрика (IoU, Dice) і класи, де важлива точність меж, а де достатньо грубого контуру.
- Умови запуску — де рахується модель: сервер, камера, мобільний пристрій; скільки кадрів на добу і який час обробки допустимий.
- Поточний процес — чим задача вирішується зараз і на якому обсязі ручний етап перестає справлятися.
Із цього складається план робіт: підготовка даних, навчання, перевірка на відкладеній вибірці, впровадження в поточний процес. Оцінка строків і схема класів приходять разом із планом — за ними видно межі етапів і те, що ми вважаємо результатом на кожному з них.
