Розмітка датасетів Computer Vision із прелейблінгом і контролем якості

Розмітка даних для комп'ютерного зору: вузькі місця

Модель показує на валідації mAP під 0.9 і впевнена повнота (recall) за рідкісними класами, а в роботі пропускає дефекти на новому освітленні й плутає схожі категорії.

Причина зазвичай не в архітектурі: вибірки зібрані одним підрядником за однією інструкцією, а в продакшні надходять кадри з іншої камери, іншого сезону та іншої зміни. Якість розмітки на валідації тримається рівно тому, що в ній немає тих межових випадків, де розмітник помилявся.

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

Додатково накопичуються помилки розмітки — обрізані або зсунуті рамки, загублені дрібні об'єкти, мітки на фоні, різні визначення класу в різних виконавців при IoU 0.3–0.5. Ані loss, ані метрики такі дефекти не ловлять: модель вивчає шум як закономірність.

Галузеві оцінки сходяться: до трьох чвертей часу в проєктах комп'ютерного зору йде не на навчання, а на підготовку, прелейблінг і переперевірку даних — за даними AI Index.

Пропущена помилка розмітки коштує дорожче на етапі впровадження, ніж на етапі збору: розбираємо, як це закривається дисципліною процесу, а не розширенням вибірки.

Що дає прелейблінг і контроль якості на потоці

Прелейблінг — це попередня розмітка кадру моделлю до того, як його побачить оператор: детектор ставить рамки та класи, трекер протягує об'єкти між сусідніми кадрами. Оператор не малює з нуля, а підтверджує або править.

Розмітку ведемо в CVAT із власними розширеннями під прелейблінг і перевірку — тому обидва ефекти нижче вимірюються на кожному проєкті, а не залишаються обіцянкою.

Прелейблінг: у скільки разів падає обсяг ручної роботи

На відео трекінг знімає з оператора рутинну протяжку об'єктів між кадрами — залишається правка меж на зміні сцени та контроль появи нових об'єктів.

На статичних кадрах детектор попередньо заповнює рамки з класами, і оператор працює в режимі підтвердження, а не розмітки з чистого аркуша. У прелейблу є поріг впевненості: нижче нього об'єкт іде як «невпевнений», вище — потрапляє у вибіркову перевірку.

Це скорочує ручну роботу не «в середньому», а передбачувано: частка кадрів, що йдуть на повну правку, падає в рази, а розкид якості між виконавцями звужується, бо правила інтерпретації задає модель, а не кожен розмітник по-своєму.

Наскрізний контроль якості та розбір спірних кадрів

Кадр проходить не одну вичитку, а ланцюжок: автоперевірка геометрії та класів → вибіркова перехресна перевірка → розбір спірних випадків окремим складом.

Спірні кадри не «згладжуються» більшістю голосів, а йдуть у чергу з еталонним рішенням — воно стає правилом для схожих ситуацій і фіксується в інструкції.

Контроль якості розмітки дає вимірюваний результат: частка правок після вичитки падає від ітерації до ітерації, а метрика моделі на відкладеній вибірці перестає стрибати між перенавчаннями.

Порівняння режимів розмітки даних: штат, підрядник, гібрид

Вибір виконавця розмітки вирішує не питання ціни, а питання класу об'єктів і обсягу потоку. Власний штат розмітників тримає спірні класи та правки інструкції під контролем, але погано переносить піки: найм і навчання тривають тижні, а між проєктами люди простоюють.

Розмітка даних підрядником закриває пікове навантаження і приносить готові регламенти контролю якості, зате кожна правка інструкції йде через цикл погодження. Гібридна схема розмітки залишає ядро та приймання в себе, а масовий обсяг віддає зовнішній команді.

Обмеження за типами об'єктів

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

Що змінюється при зростанні обсягу кадрів

На потоці в рази зростає частка пропущених об'єктів і подвійних рамок — вузьким місцем стає контроль якості, а не сама розмітка.

Гібрид переживає цей перелом легше: прелейблінг знімає рутину, вибіркова перевірка ловить розбіжності, а згода між розмітниками показує, коли інструкцію час переписати.

Як влаштований процес: аудит, схема, пілот, передача

Процес будуємо так, щоб розмітка не перетворювалася на чорну скриньку: на кожному етапі залишається перевірюваний артефакт і метрика якості. Так видно, на якому кроці який результат з'являється.

1. Аудит вихідного набору. Склад кадрів, умови зйомки, дублікати, частка кадрів без цільових об'єктів, биті вивантаження.
2. Схема класів і атрибутів. Список класів, версія схеми, правила для межових випадків: перекриття, частково видимі об'єкти, відблиски.
3. Попередня розмітка моделлю. Чернетку від мережі розмітник править вручну — прохід прискорюється в рази, але контроль залишається.
4. Контроль якості. Перехресна перевірка спірних кадрів, метрика згоди між виконавцями, розбір розбіжностей з оновленням інструкції.
5. Пілотна партія. Невеликий зріз проходимо повністю і рахуємо частку помилок — за нею правимо інструкцію до старту основного обсягу.
6. Приймання та передача. Вивантаження у форматі, який приймає ваша модель, реєстр версій, інструкції, навчання вашої команди.

Що показує аудит вихідного набору

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

Як влаштовані приймання та навчання команди замовника

На прийманні вибірково перевіряємо партію за тими самими правилами, що й виконавці, і показуємо розбіжності. Потім передаємо документацію зі схеми класів і розбираємо з вашою командою, як приймати наступні партії самостійно.

Комплект постачання: схеми, регламенти, документація

Розмітка без документації живе до першої зміни виконавця: нова людина трактує класи по-своєму, і датасет починає розходитися з вихідною схемою.

Тому комплект постачання — не архів із файлами, а набір документів, за якими наступна команда розмітників або ваш інженер відтворюють ту саму розмітку без нас.

Інструкція розмітника та правила розв'язання спірних випадків

Інструкція розмітника — робочий документ під конкретну схему, а не загальний гайд: для кожного класу прописано порядок дій, граничні приклади та типові помилки з візуальними еталонами.

Спірні випадки не вирішуються на місці — розмітник ставить флаг на об'єкт, арбітр фіксує рішення в журналі, і воно входить до наступної ревізії інструкції.

• Схема розмітки та атрибутів — ієрархія класів, типи геометрії, обов'язкові та опціональні ознаки, правила перекриттів і мінімальний розмір об'єкта.
• Інструкція розмітника — алгоритм для кожного класу, візуальні еталони, розбір типових помилок.
• Регламент контролю якості — частка повторної перевірки, поріг згоди між розмітниками, правило відправлення завдання на перерозмітку.
• Правила розв'язання спірних випадків — рівні ескалації, роль арбітра, журнал ухвалених рішень.
• Документація з розмітки — формати вивантаження, словник класів, історія версій схеми.
• Перевірний набір для приймання нових виконавців і звіт про якість: які класи дають основну частку помилок і як показник змінюється від ітерації до ітерації.

Кейс: як пілот знизив частку переробок на перевірці

Клієнт надавав потік записів із камер: нічні сцени, перекриття, об'єкти на межі кадру. Розмітку вели в CVAT силами розподіленої команди — інструкція на двадцять сторінок, приймання останнім рівнем.

Стабільно 16–18% кадрів поверталися на переробку, середній час на кадр тримався близько 40 секунд, і датасет зростав повільніше, ніж вимагав графік навчання.

Що саме змінили в процесі та чому це спрацювало

Прибрали ручне малювання «з нуля»: модель передрозмітки, навчена на вже прийнятих кадрах, віддає анотатору готові рамки, а він їх править. Найдовший етап — пошук меж об'єкта — зник, і час на кадр упав до 12–15 секунд.

Контроль якості перенесли з партії на кадр. Спірні випадки — перекриття, розмиття, об'єкт на межі — йдуть в окрему чергу з явно описаним критерієм рішення, тому повторно перевіряється не весь датасет, а 6–8% вибірки.

Інструкцію замінили коротким чек-лістом з еталонними прикладами: розбіжності між анотаторами скоротилися.

Підсумок за метриками: частка переробок — з 17% до 4%, час на кадр — з 40 до 14 секунд, обсяг повторних перевірок менший утричі.

Метрики якості розмітки — узгодженість перевіряльників і частка кадрів, прийнятих з першого разу — знімаємо на кожній поставці, тому зростання обсягу не розмиває якість.

Чим прелейблінг відрізняється від анотації з нуля?

Прелейблінг і ручна анотація приводять до одного результату — коректні рамки, маски або ключові точки на кадрі, — але йдуть до нього по-різному.

За автоматичної передрозмітки модель ставить чернові рамки, а анотатор їх підтверджує, зсуває або видаляє; за розмітки з нуля оператор малює кожен об'єкт сам. Різниця проявляється у трудовитратах на кадр і в тому, як поводиться якість на щільних сценах.

На практиці підходи комбінують: передрозмітка закриває основний обсяг, ручна перевірка — класи з високою ціною помилки.

Межа визначається заміром на вибірці: якщо анотатор править менше третини рамок, автоматична передрозмітка окупається, якщо більше — модель протягує свої помилки в датасет, і на цьому класі дешевше повернутися до розмітки з нуля.

Коли потрібна ручна перевірка? Там, де об'єкт перекривається фоном або сусідніми об'єктами, де клас візуально не відрізнити від близького і де помилка коштує дорого: медицина, дефектоскопія, облік транспорту.

Тут контроль суцільний, плюс замір узгодженості між анотаторами — однакові випадки повинні отримувати однакову мітку, інакше модель вивчить суперечність.

Технічні сумніви: якість, строки, доступи

Перед стартом технічна сторона викликає більше питань, ніж ціна. Нижче — п'ять сумнівів, які найчастіше виринають на погодженні, і відповіді без загальних слів: вони спираються на регламент приймання і на те, як влаштована перевірка розмітки.

Скільки часу займе розмітка?

Строк залежить від щільності об'єктів на кадрі та кількості класів. Першу партію розмічаємо із заміром фактичного виробітку — далі прогноз будується за реальною швидкістю, а не за нормативом.

Як передати зображення?

Робочих схем три: вивантаження в наше сховище, розмітка на вашій інфраструктурі, доступ через захищений канал із рольовою моделлю. Персональні дані знеособлюємо на вході, права відкликаємо після здачі.

У нас уже є частково розмічений набір

Проводимо інвентаризацію: звіряємо схему класів, шукаємо конфлікти та дублі, добудовуємо відсутні кадри і приводимо все до одного формату — COCO, YOLO або Pascal VOC.

Чи можна перевикористати розмітку?

Так. Таксономія класів і правила залишаються активом: наступний проєкт стартує не з нуля — схема готова, частина кадрів приходить із попередньою розміткою, перевірка йде лише за спірними зонами.

Обговоримо задачу: з чого почати і що знадобиться

Щоб повернутися з оцінкою проєкту розмітки, а не із загальними формулюваннями, нам потрібен мінімум стартових матеріалів. Оцінка тримається на трьох величинах: скільки даних, за якими правилами їх розмічати і як перевіряти результат. Чим повніший вхід, тим точніший обсяг розмітки й строки — і тим менше переробок на етапі здачі.

• Приклад сирих даних — 200–500 файлів із реального потоку, а не відібрані «вдалі» кадри: на них видно шум, дублікати, биті файли та рідкісні класи.
• Список класів об'єктів і правила анотації: що вважаємо окремим об'єктом, як розмічаємо перекриття, обрізані об'єкти та спірні випадки, який мінімальний розмір об'єкта враховуємо.
• Очікуваний обсяг розмітки: кількість кадрів і об'єктів, частка кадрів під суцільну перевірку, чи потрібна розмітка з нуля або достатньо передрозмітки моделі з дорозміткою оператором.
• Вимоги до вивантаження: структура каталогів, формат анотацій, розбиття на вибірки і те, як результат потрапить у навчання моделі.
• Критерії приймання та метрики якості: допустима частка помилок на вибірці, згода між розмітниками, порядок перерозмітки спірних прикладів і обробки зауважень замовника.
• Матеріали минулих ітерацій, якщо вони є: старі анотації, журнал правок, відомі проблемні класи — це знімає окремий цикл калібрування.

Опишіть задачу і додайте те, що вже є, — повернемося з оцінкою та планом робіт: етапи, строки, склад команди й точки контролю якості на кожному кроці.