Чому класифікація зображень ламається на реальних даних
Найчастіше запит звучить так: «модель на відкладеній вибірці показує майже ідеальну точність, а в роботі помиляється на половині об’єктів». Розбираємо, де саме ламається класифікація зображень і чому зміна архітектури на важчу нічого не виправляє.
Перше джерело відмов — розмітка датасету під лабораторні умови. Знімки робили в одному приміщенні, за одного світла й ракурсу, мітки проставляли за папками з вихідними файлами, без єдиного правила для спірних випадків.
У результаті модель вчить фон і артефакти зйомки, а не ознаку об’єкта: достатньо поміняти стіл або лампу, і точність просідає.
Другий — дисбаланс класів. Коли рідкісна категорія займає частки відсотка, загальна точність залишається високою просто тому, що модель впевнено передбачає частий клас.
Дивитися потрібно на повноту й точність за кожним класом і на матрицю помилок, інакше головний клас відмови не видно в жодній зведеній цифрі.
Третій — зміна умов зйомки: інша камера, освітлення, сезон, положення об’єкта в кадрі. Розподіл вхідних даних відходить від навчального, і модель бачить не те, на чому вчилася — навіть акуратно навчений ResNet або ViT тут не рятує.
Розбираємо, як це закривається: спочатку фіксуємо правила розмітки й перерозмічуємо спірні групи, потім вирівнюємо класи на рівні відбору прикладів, а не лише ваг, і тільки після цього навчаємо мережу.
Що дає навчена модель класифікації зображень
Навчена модель класифікації зображень перетворює потік знімків у рішення з числом. Точність моделі фіксується до запуску на контрольній вибірці — наборі кадрів, розмічених вручну й таких, що не брали участі в навчанні. Саме вона, а не результат на навчальному наборі, стає параметром приймання.
На потоці модель повертає мітку й впевненість, а поріг впевненості задає, яка частка рішень іде в автоматику. Усе, що нижче порога, потрапляє в ручне сортування: перегляд стає вибірковим замість суцільного, і оператор розбирає лише спірні кадри.
Частка помилок на контрольній вибірці відома заздалегідь, тому навантаження на зміну можна планувати, а не вгадувати за фактом.
Зникає й систематична помилка оператора: втома до кінця зміни й різне тлумачення спірних випадків більше не впливають на розмітку.
Модель відповідає однаково на першому й останньому кадрі потоку, затримка — частки секунди на зображення, тож вузьким місцем стає канал передавання, а не розпізнавання.
Що стає вимірюваним після запуску:
- частка кадрів, що йдуть в автоматику без участі людини;
- скорочення ручного перегляду за того самого обсягу потоку;
- частка помилок на контрольній вибірці з розбивкою за класами;
- час відгуку на кадр за потокової обробки.
Архітектуру підбираємо під характер даних, а не за замовчуванням: ResNet і споріднені сімейства по-різному тримають дрібні об’єкти, шум і розмиття — вибір підтверджуємо порівнянням на контрольній вибірці, а не загальною рекомендацією.
Підходи до навчання: власна мережа, донавчання чи готовий сервіс
Три варіанти різняться не «якістю», а обсягом вашої розмітки й тим, наскільки цільові класи близькі до того, що вже вміють відкриті моделі.
Навчання з нуля має сенс, коли зібрано десятки тисяч розмічених прикладів, а класи специфічні: дефекти на знімках, рідкісні текстури, медичні зображення. Якщо такої розмітки немає, спроба виростити мережу з нуля дає перенавчання й точність нижчу, ніж у готової архітектури.
Донавчання моделі на попередньо навченій архітектурі закриває більшість задач: згорткові сімейства стійкі на невеликих наборах, трансформерні виграють, коли класів багато й важливі дрібні деталі.
Готовий сервіс розпізнавання беруть під типові категорії — там, де не потрібен контроль над розміткою й донавчанням.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Навчання з нуля | власна розмітка від десятків тисяч прикладів, класи не схожі на публічні набори | довгий цикл, потрібен запас даних і обчислювальні ресурси, високий ризик перенавчання |
| Донавчання попередньо навченої архітектури | від кількох сотень розмічених прикладів, класи близькі до природних зображень | критична якість розмітки, точність падає при зміні камер або освітлення |
| Готовий сервіс розпізнавання | типові категорії, потрібен швидкий старт без власної інфраструктури | закритий набір класів, немає доступу до моделі, залежність від постачальника |
Ми зазвичай починаємо з донавчання й заміряємо точність на відкладеній вибірці: якщо її не вистачає, точково нарощуємо розмітку, а не змінюємо підхід цілком.
Як ми навчаємо та впроваджуємо модель: етапи робіт
Порядок етапів підпорядкований одному обмеженню: метрика якості та спосіб її підрахунку фіксуються до першого запуску навчання.
Якщо визначити їх після, будь-яке доопрацювання перетворюється на підгонку під конкретну вибірку — на потокових даних точність просідає, а пояснити причину вже неможливо.
- Аудит даних. Дивимося, що реально є: обсяг за класами, якість розмітки, дублікати, пошкоджені файли, дисбаланс і витоки між навчальною та перевірною частинами.
- Метрика якості. Беремо не «точність взагалі», а величину під ціну помилки: частку пропусків критичного класу, macro-F1 за перекосу класів, поріг спрацювання.
- Базова лінія. Проста модель або попередньо навчені ваги без донавчання — щоб знати планку, від якої відраховується приріст, і не сплутати його з ефектом передобробки.
- Навчання. Підбираємо архітектуру під задачу — згорткову (ResNet, EfficientNet) або трансформерну (ViT) — і режим: спочатку верхні шари, потім часткове розморожування, нормування входів, балансування класів, рання зупинка за валідацією.
- Відкладена вибірка. Фінальну перевірку ведемо на даних, що не брали участі ні в навчанні, ні в підборі параметрів, і за можливості — на знімку з іншого періоду.
- Аналіз помилок. Розбираємо матрицю помилок і найвпевненіші промахи: частина закривається дорозміткою й порогом, частина — зміною постановки задачі.
- Впровадження моделі. Сервіс передбачень, версіонування ваг, поріг впевненості й відмова від відповіді замість випадкової мітки, журналювання, контроль зміщення вхідних даних і регламент донавчання.
Артефакти навчання: ваги моделі, розмітка, регламент перенавчання
Після проєкту в замовника залишається не «навчена модель як чорна скринька», а комплект, який можна перевірити, донавчити й передати іншій команді. Нижче — що саме фіксується і в якому вигляді.
- Ваги моделі — навчені параметри із закріпленим списком класів і порогом впевненості, нижче якого модель чесно відмовляється від відповіді замість вгадування.
- Код навчання й запуску — читабельні скрипти підготовки даних, тренування й передбачень, без прихованих зовнішніх залежностей і ручних правок «на місці».
- Розмічений набір зображень — навчальна, валідаційна й тестова частини без перетинів між ними, щоб метрики не завищувалися через витік кадрів.
- Правила розмітки — як тлумачаться спірні кадри, перекриття й неоднозначні класи, який об’єкт вважається занадто дрібним для розмітки й що робити з кадрами без об’єкта.
- Звіт про якість — матриця помилок за класами: видно, де модель плутає сусідні категорії й яких даних для них не вистачає.
- Регламент перенавчання — тригери (падіння частки правильних відповідей на потоці, зміщення даних, поява нового класу), періодичність прогонів і відповідальні на боці замовника.
- Відтворюваний запуск — закріплені середовище, зерно випадковості та версії бібліотек: навчання повторюється однією командою й дає зіставний результат, а не «приблизно такий самий».
- Документація та передача — карта файлів і сховищ, порядок дій у разі збою, розбір рішення з інженерами замовника.
Такий комплект дає змогу розвивати модель власними силами або змінити підрядника без втрати напрацювань.
Кейс: контроль якості продукції на виробничій лінії
На лінії контроль якості тримався на вибірковому огляді: оператор знімав з конвеєра кожну десяту деталь і оцінював її очима. Дефект між перевірками йшов далі потоком і спливав на складанні — партію доводилося перебирати цілком, а причина збою на той момент губилася в статистиці. Розбираємо виробничий кейс: як контроль якості перевели на класифікацію зображень просто в потоці.
Розмітку будували не за студійними знімками, а за кадрами з лінії — з відблисками на металі, вібрацією конвеєра й різним освітленням між змінами.
Окремо розмітили межові випадки: подряпини глибиною в частки міліметра й допустимі сліди обробки, які не є браком — без них класифікатор спрацьовував би на нормі.
Модель навчили на сімействі EfficientNet, класи збалансували за частотою, а поріг рішення підібрали за кривою «пропуск — хибна тривога», а не за однією точністю.
Після запуску пропуск дефектів скоротився приблизно в шість разів, а хибні зупинки лінії впали до двох-трьох за зміну замість п’ятнадцяти-двадцяти. Перевірку проходить кожен виріб, а не вибірка, — частка оглянутої продукції зросла з 10% до 100%.
Зміні передали не лише модель: інтерфейс із вердиктом і підсвічуванням проблемної ділянки, налагоджуваний поріг чутливості й журнал спрацювань для розбору спірних кадрів.
Регламент оновлення описує, що робити при зміні партії сировини або ремонті освітлення: оператор позначає спірні кадри, і раз на кілька тижнів класифікатор донавчають на них. Так зниження браку тримається, а не відкочується через місяць.
Чим відрізняється донавчання від навчання моделі з нуля?
Донавчання — це перенесення знань: беремо мережу, яка вже навчилася на великому корпусі зображень, і адаптуємо її під свої класи.
Навчання з нуля починається з випадкових ваг, і мережі доводиться освоювати все одразу: і базові ознаки на кшталт контурів, текстур і градієнтів, і специфіку вашої задачі.
Коли даних мало — сотні або перші тисячі кадрів на клас, — донавчання майже завжди виграє. Ранні шари фіксують і не чіпають, навчають лише верхні та шар класифікації: модель сходиться за десятки епох, а ризик перенавчання на малій вибірці залишається керованим.
Умова одна — класи мають бути схожі на те, що мережа вже бачила: техніка, товари, документи, природні об’єкти.
Власна мережа потрібна, коли предметна область далека від звичайних фотографій: тепловізійні знімки, дефекти на металі, вузькоспеціальна зйомка. Перенесення знань тут тягне зміщення вихідного корпусу, і точність упирається в стелю.
Друга умова — даних достатньо, щоб модель не запам’ятала вибірку: зазвичай це десятки тисяч розмічених кадрів плюс помітний дисбаланс класів, який доводиться окремо балансувати.
Практичний критерій — обсяг і однорідність даних, вимоги до точності та вартість розмітки. За малого датасету починаємо з донавчання й лише потім поступово розморожуємо шари, якщо метрики перестали зростати.
Навчання з нуля без достатнього корпусу дає результат гірший за акуратно налаштоване перенесення знань, тому обидва варіанти ми порівнюємо на відкладеній вибірці й вибираємо той, що стійкіше тримається на контрольних даних.
Розбираємо технічні сумніви: якість, дані, підтримка
Перед стартом команда замовника ставить одні й ті самі інженерні питання: чи вистачить розмічених даних, що робити з рідкісними класами, як перевіряється стійкість і хто донавчає модель після передачі. Нижче — короткі відповіді про те, як це вирішується на практиці.
Чи вистачить наших даних для навчання?
Стартуємо від кількох сотень прикладів на клас: беремо попередньо навчені ваги й донавчаємо модель на вашому наборі. Валідацію збираємо стратифіковано, а нестачу даних закриваємо аугментаціями — і стежимо, де починається перенавчання.
Що робити при дисбалансі класів?
Комбінуємо ваги класів у функції втрат, пересемплювання рідкісних прикладів і підбір порога рішення. Якість рахуємо за precision і recall, плюс матриця помилок кожного класу — інакше рідкісний дефект розчиняється в загальній точності.
Як перевіряється стійкість моделі?
Тримаємо окремий набір знімків, зроблених в інших умовах: інше освітлення, ракурс, обладнання. Розрив між навчальною та перевірною вибіркою показує перенавчання раніше, ніж модель іде в роботу, і вказує проблемні класи.
Хто донавчає модель після передачі?
Передаємо ваги, конфігурацію навчання, маніфест датасету й скрипт запуску — донавчання на нових даних команда виконує власними силами. Супроводжуємо перші прогони, щоб додавання класу не ламало інші.
Розкажіть про задачу — повернемося з планом та оцінкою
Щоб оцінка проєкту спиралася на факти, а не на здогади, нам потрібен мінімум ввідних — зазвичай вистачає однієї розмови й пари файлів. Ці самі дані ляжуть в основу технічного завдання, тому зберемо їх один раз і без повторних питань.
- Опис процесу: звідки надходить зображення, хто і як ухвалює рішення за результатом моделі.
- Приклади знімків: кілька сотень кадрів із реальних умов, включно зі складними — змазаними, пересвіченими, з частково закритим об’єктом.
- Поточна розмітка: класи, обсяг набору, хто розмічав і за яким правилом, що робити зі спірними випадками.
- Вимоги до якості: яка частка помилок допустима й що дорожче — пропустити об’єкт чи позначити зайвий.
- Цільове середовище: сервер, камера на об’єкті або мобільний пристрій, обмеження за пам’яттю й часом відповіді.
- Доступи й дані: чи можна обробляти знімки на наших потужностях або їх потрібно тримати всередині вашого контуру.
- Що вже зроблено: поточний код, раніше навчені моделі та їхні метрики — щоб не починати з нуля.
Опишіть задачу — повернемося з планом робіт та оцінкою: етапи, що перевіряємо на кожному, який результат вважаємо прийманням. Якщо частину даних ще не зібрано, обговоримо задачу й підкажемо, що критично, а що можна доуточнити по ходу.
