Аугментація зображень: де ламається навчання на малій вибірці
Навчання на малій вибірці даних майже завжди виглядає однаково: на кількох сотнях розмічених кадрів модель впевнено проходить навчання, а на відкладеній частині провалюється за рідкісними класами.
Формально помилка падає, але зростає розрив між поведінкою на знайомих і нових прикладах — це і є перенавчання моделі, за якого мережа запам'ятовує конкретні кадри замість ознак об'єкта.
Дисбаланс класів погіршує картину. Коли рідкісний клас займає частки відсотка прикладів, моделі вигідніше передбачати частий: загальна частка правильних відповідей зростає, а повнота за дефектом чи аномалією падає до нуля.
Метрики розходяться, і за зведеною цифрою не видно, що рішення не працює там, заради чого його збирали.
Ціна такого збою — не лише зіпсована ітерація. Підготовка датасету перетворюється на ручний конвеєр: розмітники не встигають за завданням, рідкісні випадки доводиться вишукувати вручну, а кожна наступна спроба поліпшити модель упирається в ті самі кілька сотень кадрів. Команда або зупиняє навчання, або випускає модель, яка пропускає половину значущих об'єктів.
Проста аугментація зображень сама по собі проблему не знімає. Випадкові повороти, віддзеркалення та зсуви плодять майже однакові кадри: модель запам'ятовує фон, освітлення й артефакти зйомки, а валідація, зібрана з тих самих зйомок, підтверджує цю ілюзію.
Розбираємо, як це закривається — від правил відбору прикладів і балансування класів до контролю метрик за кожним класом окремо.
Вимірюваний ефект: якість моделі, терміни, трудовитрати
Метрики на відкладеній вибірці перестають «плавати»
Політика доповнення даних задається явно: які повороти, масштаб, зсуви, зміни яскравості й контрасту, шум і розмиття допустимі для конкретного класу. Навчання йде на розширеному наборі, а перевірка — на відкладеному, який доповненням не чіпали.
Тому цифри відображають реальну якість моделі комп'ютерного зору, а не підгонку під навчальні приклади.
Менше ручної розмітки на той самий обсяг даних
Один розмічений кадр перетворюється на десятки коректних варіантів — рамки та маски перераховуються разом з геометрією зображення, а не малюються заново. Частка ручної розмітки падає, і час розмітників іде туди, де він справді потрібен: на рідкісні класи та пограничні випадки.
Стійкість до спотворень замість запам'ятовування умов зйомки
Модель перестає спиратися на конкретне освітлення, ракурс чи якість оптики, бо бачить ці варіації ще на навчанні. Окремий набір зі спотвореннями показує: просідання під час зміни камери, точки зйомки чи часу доби помітно менше, ніж у моделі, навченої на «чистих» кадрах.
Цикл перевірки гіпотез — години замість днів
Політика аугментації описується конфігурацією, а версія набору відтворювана: той самий експеримент повторюється з тим самим результатом. Порівняти дві стратегії доповнення й побачити різницю в метриках можна за одну ітерацію, а не за тиждень ручного перескладання набору даних.
Способи доповнення даних: порівняння підходів
Вибір прийому диктує не мода, а розрив між навчальною вибіркою і тим, що бачить камера в реальній роботі. Одні перетворення додають різноманітність майже без ризику, інші дають принципово нову інформацію — але потребують контролю розмітки та частки таких прикладів.
Варіанти та їхні межі
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Геометричні перетворення | об'єкт трапляється під різними ракурсами, а розмітка стійка до зсуву й повороту | дзеркалювання та обрізання ламають сенс: текст, символи, асиметричні деталі, об'єкти біля межі кадру |
| Кольорові спотворення | зйомка різною оптикою, мінливе освітлення й баланс білого | не допомагають, якщо об'єкт змінює форму або перекривається іншими |
| Шум і розмиття | слабке освітлення, рух у кадрі, стиснення під час передавання | маскують дефекти зйомки, але не замінюють реальні кадри; сильний шум з'їдає дрібні об'єкти |
| Змішування фрагментів | щільні сцени, багато об'єктів, дефіцит рідкісних класів | з'являються неприродні межі, модель гірше калібрується, потрібен відбір прикладів |
| Синтетичні приклади | рідкісний клас, дорогий або тривалий збір натури, потрібен точний контроль параметрів | розрив між синтетикою та реальністю, ризик перенавчання на артефакти генератора |
| Імітаційне моделювання сцени | потрібні рідкісні умови: ракурси, погода, взаємні перекриття об'єктів | висока вартість налаштування сцени й матеріалів, обов'язкова перевірка на реальних кадрах |
На практиці беруть два-три прийоми й добирають силу за контрольною вибіркою з реальних кадрів. Якщо якість на ній падає при зростанні якості на доповнених даних — підсилення перебір: геометрія та синтетика починають підміняти ознаки об'єкта артефактами.
Етапи впровадження: від аудиту даних до передачі команді
Аугментація починається не з вибору бібліотеки перетворень, а з питання, яких умов зйомки не вистачає моделі. Тому перший крок — опис того, що вже лежить у датасеті, а не код. Нижче порядок роботи: кожен етап закінчується артефактом, який можна перевірити й передати далі.
- Аудит датасету. Дивимося розподіл класів, дублікати й майже-дублікати, пошкоджені та пересвітлені кадри, розбіжності в розмітці між анотаторами. На виході — перелік дефектів та оцінка, скільки кадрів реально придатні до навчання.
- Схема підготовки даних і метрики. Фіксуємо цільові метрики — точність і повноту за класами, частку хибних спрацювань — і описуємо порядок: читання, приведення розміру, нормалізація, розбиття на навчальну, валідаційну та тестову частини.
- Налаштування й валідація перетворень. Добираємо геометрію, колір, шум, імітацію освітлення й погоди. Діапазони задаємо консервативно: перетворення не повинно створювати об'єкт, якого немає в розмітці. Потім проганяємо кожне перетворення окремо та в комбінації й звіряємо, що мітки перераховуються коректно, а об'єкт біля межі кадру не губиться.
- Перевірка на контрольних наборах. Тримаємо набір, який ніколи не аугментується, і набір складних кадрів — слабке світло, рух, перекриття. Вони показують, чи допомагає аугментація узагальненню, чи просто маскує перенавчання.
- Замір впливу на модель. Навчаємо базову та аугментовану версії в однакових умовах і порівнюємо за метриками та за стійкістю до зміни умов зйомки. Виграш фіксуємо числом, а не відчуттям.
- Передача й навчання команди. Віддаємо конфігурації, скрипти запуску та журнал прогонів. Відтворюваність експериментів тримається на тому, що будь-який результат повторюється за зафіксованим набором параметрів без ручних правок.
Конфігурації, схеми та регламенти: комплект передачі
Комплект передачі — не архів зі скриптами, а робоча документація, за якою інженер замовника сам відтворює збирання й змінює параметри без звернення до нас. Усе лежить поруч із кодом: окрема папка з конфігураціями, схеми потоків даних, правила версіонування та регламенти. Нижче — що саме залишається в команди після здачі етапу.
- Конфігурація перетворень — файли з наборами операцій (повороти, кроп, зміна яскравості й контрасту, шум, розмиття), діапазонами значень і ймовірностями застосування. Окремий профіль під кожне завдання, щоб підсилення під детекцію не ламало розмітку під класифікацію.
- Схеми потоків даних — як знімок проходить шлях від джерела до готової вибірки: де розмітка, де застосовується аугментація, де відбракування і що потрапляє в архів.
- Правила версіонування датасету — маніфести з контрольними сумами джерел і згенерованих вибірок, зв'язка «версія датасету → версія моделі → метрики». Будь-який експеримент відтворюється або відкочується.
- Регламент оновлення даних — як додається нова порція знімків, з якою періодичністю проганяється аугментація і за якими ознаками ухвалюється рішення про перенавчання.
- Правила контролю якості даних — фільтри на артефакти: розмиті кадри, дублі, викиди за яскравістю, порушення розмітки; пороги відбракування й звіт за розподілом класів.
- Документація конвеєра — порядок запуску, залежності, точки розширення та розбір типових збоїв з ознаками, за якими їх упізнають.
- Тестовий набір з еталонним результатом — короткий зріз, за яким перевіряють, що середовище зібрано правильно й відтворює очікуваний вихід.
Кейс: виявлення дефектів на виробничій лінії
Що було
Кейс комп'ютерного зору на виробничій лінії: дефектів кілька типів, але мікротріщини на кромці траплялися приблизно в 3 випадках із 1000 — рідкісний клас тонув у загальному потоці знімків.
Модель, навчена на вихідному архіві, впевнено знаходила часті дефекти, а за рідкісним тримала повноту 0,4-0,5. Ціна помилки подвійна: пропущена тріщина йшла у відвантаження, а потік хибних спрацювань оператори перестали розбирати вручну — сигнал знецінився.
Що змінили
Розмітку розібрали за типами й зібрали збалансовану вибірку: рідкісний клас доповнили керованою аугментацією зображень — поворотами й віддзеркаленнями в допустимих для кромки кутах, зміною контрасту й яскравості під різні зони освітлення цеху, зерном сенсора й локальними затемненнями.
Кожне перетворення перевіряли на фізичність: синтетика не повинна створювати картину, якої на лінії не буває, інакше модель вчиться на вигаданих ознаках і приріст залишається тільки у звіті.
Потім поріг спрацювання дібрали за кривою точності-повноти, а не «на око», і приймання провели за регламентом, узгодженим зі службою якості в межах процедур ISO 9001.
Що стало
Повнота за рідкісним класом піднялася з 0,5 до 0,93, частка пропущених тріщин скоротилася більш ніж у сім разів. Хибні спрацювання за зміну впали приблизно з 40 до 6 — оператор знову дивиться на сигнал, а не ігнорує його.
Перенавчання йшло на даних, де рідкісний клас представлено чесно, тому на нових партіях якість не просіла.
Чим відрізняється аугментація зображень на льоту від попередньої?
Аугментація на льоту застосовує перетворення до кожного батчу в момент навчання: та сама картинка в різних епохах виглядає по-різному, а набір фактично нескінченний.
Попереднє розширення — це заздалегідь зібраний набір: джерела один раз проходять через конвеєр перетворень, результат пишеться на диск і читається як звичайні дані.
Ключова розбіжність — обсяг зберігання даних. Попередній набір зростає кратно числу перетворень: десять варіантів на знімок перетворюють корпус на десять корпусів, плюс снапшоти під кожну версію політики, які тримають, поки йдуть порівняння.
За доповнення даних на льоту на диску залишаються тільки оригінали, а різноманітність задається конфігурацією.
Швидкість навчання залежить від балансу. На льоту підготовка лягає на процесор: якщо конвеєр читання не встигає за прискорювачем, епоха розтягується. За попереднього розширення епоха коротша, але правка політики означає повне перескладання набору.
Частіше виграє змішаний режим: важкі перетворення — геометрія, вирізання фрагментів, накладання — рахуються один раз і лежать поруч із оригіналом, а дешеві — яскравість, контраст, шум — застосовуються на льоту.
Різноманітність між епохами зберігається, дисковий слід у рази менший за повний набір. Валідація при цьому йде без аугментації: тільки приведення розміру та нормалізація, інакше метрики непорівнювані між запусками.
Критерій простий: політика ще добирається — працюємо на льоту; зафіксована й навчання упирається у швидкість прискорювача — збираємо набір заздалегідь. Бібліотеки рівня Albumentations перемикають режими без переписування коду.
Сумніви та обмеження: що уточнюють перед стартом
Перед стартом найчастіше уточнюють межі методу: що він бере на себе, а що залишається за командою даних. Нижче — питання, які виникають майже на кожному завданні з аугментації зображень, і наші відповіді без округлень.
Аугментація замінить ручну розмітку?
Ні. Вона розширює різноманітність усередині вже розмічених класів, але не створює прикладів того, чого у вибірці немає. Якщо клас не трапляється взагалі або розмічений суперечливо, жодне перетворення це не виправить — спочатку потрібна розмітка або добір кадрів.
Датасет уже зібрано й розмічено — схему доведеться переробляти?
Працюємо з тим, що є: інвентаризація, пошук дисбалансу та шумних міток, потім правило аугментації застосовується лише до навчальної частини.
Валідаційну й тестову вибірки залишаємо недоторканими, інакше метрика перестає відображати реальні дані й якість моделі на нових знімках падає непомітно.
Як зрозуміти, що перетворення не спотворює клас?
Частина операцій змінює сенс мітки: сильний поворот або обрізання забирає об'єкт за кадр, дзеркалювання ламає асиметричні класи, зсув відтінку плутає класи, що розрізняються кольором.
Кожне перетворення перевіряємо на представниках класу, а діапазони параметрів звужуємо за результатом — частка кадрів з утраченим об'єктом залишається в межах похибки розмітки.
Схему можна перенести на інше завдання?
Порядок роботи, частки перетворень і контроль якості переносяться. Набір операцій і діапазони — ні: вони залежать від того, що саме модель має розрізняти. На новому завданні повторюємо замір і перескладаємо правило, а не копіюємо конфігурацію.
Які юридичні обмеження враховуємо?
Аугментація не знімає умов ліцензії: похідне зображення залишається під тими самими обмеженнями, що й вихідне. Окремо перевіряємо кадри з людьми, персональні та медичні дані — під них потрібні законні підстави обробки. Синтетика теж не обходить заборону на використання закритого набору зображень.
Обговоримо завдання й повернемося з оцінкою та планом
Постановка завдання для аугментації — це не «зробіть побільше картинок». Спочатку потрібно зрозуміти, який клас об'єктів модель плутає, чого не вистачає у вибірці та як ми домовимось вимірювати якість.
Тому старт співпраці починається не з договору, а з розбору вхідних даних: так оцінка проєкту спирається на факти, а не на припущення.
Що описати або надіслати, щоб ми повернулися з планом:
- поточну вибірку: обсяг, тип розмітки, частку рідкісних класів і типові помилки моделі на відкладених прикладах;
- 10–20 зображень, на яких модель помиляється найчастіше;
- цільову метрику та спосіб її заміру — повнота за рідкісним класом, стійкість до зміни умов зйомки;
- обмеження контуру: формат розмітки, правила зберігання даних, режим доступу до вашої інфраструктури;
- умови зйомки та обладнання — від цього залежить, які перетворення допустимі, а які внесуть спотворення;
- режим приймання: покадрова перевірка, звіт за метриками або регулярні покази проміжних результатів.
У відповідь надсилаємо поетапний план робіт: очищення та розмітка вибірки, набір перетворень під ваш клас завдань, контроль реалістичності синтетики, донавчання й порівняння з базовою моделлю. У кожного етапу — критерій приймання, щоб результат був перевірюваним, а не «на око».
Опишіть завдання у зручному вигляді — повернемося з оцінкою термінів і планом робіт.
