Зображення статті
## Проблема: чому ручний контроль якості не масштабується
На більшості виробничих підприємств контроль якості досі здійснюється людьми. Контролер дивиться на деталь, оцінює її за набором параметрів і приймає рішення: годна чи ні. Ця система має фундаментальні обмеження:
**Людська втома:** через 4–6 годин монотонної роботи точність інспектора падає на 15–25%. На нічних змінах — ще більше.
**Суб'єктивність:** різні інспектори по-різному оцінюють граничні випадки. Один пропустить невелике подряпання, інший — відбракує.
**Швидкість:** людина здатна перевірити 200–400 деталей на годину. Сучасні конвеєри виробляють тисячі.
**Задокументованість:** людський інспектор не залишає автоматичного запису кожного рішення.
Комп'ютерний зір (Computer Vision, CV) усуває всі ці обмеження. Але впровадження потребує ретельного підходу.
## Кейс: виробник металевих кріплень
Розглянемо реальний проєкт (назва змінена): виробник промислових кріплень у Харківській області, виробництво 50 000 одиниць на добу, рівень браку до впровадження — 3.2%, що при такому обсязі давало 1 600 дефектних деталей щодня.
**Типи дефектів:**
- Тріщини (20% від загального браку)
- Неправильна різьба (35%)
- Подряпини глибше 0.3 мм (25%)
- Неправильна геометрія (20%)
**Вимоги до системи:**
- Швидкість: мінімум 3 000 деталей на годину (з запасом)
- Точність: не більше 0.1% пропущеного браку
- Хибні спрацьовування: не більше 2% (втрата годних деталей)
## Вибір архітектури моделі
### Класифікація чи детекція?
Перше рішення: чи потрібно лише визначити, чи є дефект (класифікація), чи й локалізувати його (детекція)?
Для більшості задач контролю якості достатньо класифікації: «годна/брак». Але якщо потрібно визначити тип і розташування дефекту для зворотного зв'язку в технологічний процес — потрібна детекція.
У нашому кейсі обрали двоетапний підхід:
1. Класифікатор «годна/брак» для швидкого відсіву
2. Детектор (YOLO v8) для класифікації типу дефекту і накопичення статистики
### Вибір backbone-мережі
**EfficientNet:** відмінний баланс точності і швидкості. Підходить для більшості задач класифікації.
**ResNet-50:** надійний класик, добре підходить для transfer learning. Менш ефективний ніж EfficientNet, але краще вивчений.
**YOLO v8:** стандарт для детекції об'єктів у реальному часі. YOLO v8n (nano) дає ~200 FPS на GPU, що перекриває вимоги конвеєра.
**Вибір у нашому кейсі:** EfficientNet-B3 для першого етапу, YOLO v8s для другого.
## Збір і розмітка даних
### Скільки даних потрібно?
Це найчастіше запитання при старті CV-проєктів. Загальна відповідь: чим більше, тим краще. Але практичні орієнтири:
- **Мінімум для класифікації:** 500–1 000 зображень кожного класу
- **Достатньо:** 2 000–5 000 на клас
- **Ідеально:** 10 000+ на клас
Ключова проблема контролю якості: дефектів значно менше, ніж годних деталей. При рівні браку 3% на 1 000 зображень тільки 30 — дефектні. Цього катастрофічно мало.
**Рішення:**
- **Цілеспрямований збір:** змусити операторів фотографувати кожен виявлений дефект протягом 1–2 місяців
- **Аугментація:** поворот, відображення, зміна яскравості для штучного збільшення датасету
- **Synthetic data:** генерація синтетичних дефектів на зображеннях годних деталей
### Розмітка
Для класифікації достатньо підпису «годна/брак». Для детекції потрібні bounding boxes.
**Інструменти розмітки:**
- Label Studio (відкритий код, самохостинг)
- CVAT (підходить для команд)
- Roboflow (SaaS, з автоматичними інструментами)
**Оцінка якості розмітки:** залучіть двох анотаторів і вимірюйте inter-annotator agreement. При значенні нижче 0.8 (Cohen's kappa) — переглядайте інструкції розмітки.
## Навчання і валідація
### Train/Validation/Test split
При малому датасеті (менш ніж 5 000 зображень) використовуйте k-fold cross-validation замість стандартного розбиття 70/15/15.
**Важливо:** тестова вибірка має бути зібрана в інший час або на іншій партії, ніж тренувальна. Інакше ви оцінюєте здатність запам'ятовувати, а не узагальнювати.
### Метрики для виробничого контролю якості
MAPE і accuracy — не ті метрики. Для виробничого контролю важливі:
- **Recall по дефектах (Sensitivity):** частка виявленого браку. Наша ціль: 99.9%
- **Precision по дефектах:** частка правильно класифікованих позитивних спрацьовувань
- **False Negative Rate:** пропущений брак — найдорожча помилка
**Операційна точка:** обирається з ROC-кривої залежно від асиметрії вартостей помилок. Зазвичай поріг класифікатора зміщують у бік вищого Recall ціною вищого FP Rate.
### Результати навчання
Після 5 000 прикладів (з аугментацією до 15 000) і тонкого налаштування EfficientNet-B3:
- Recall по дефектах: 99.7%
- False Positive Rate: 1.8%
- Inference time: 12 мс на зображення
## Інтеграція з конвеєром
### Апаратне рішення
**Камери:** промислові монохромні камери з роздільною здатністю 5 МП (IDS uEye або Basler). Монохром дає вищу чутливість і не вносить кольорових артефактів.
**Підсвічування:** критичний компонент! Кутове підсвічування (dark field illumination) робить тріщини і подряпини видимими, яких не видно при прямому освітленні.
**Обчислення:** NVIDIA Jetson AGX Xavier — компактний, достатньо потужний для YOLO v8s.
**Механічний відбраковувач:** пневматичний відхилювач на конвеєрі за 200 мс після камери.
### Програмна інтеграція
Система підключається до SCADA-системи підприємства через OPC-UA протокол. Кожне рішення записується в базу даних з: timestamp, зображенням, передбачуваним класом, confidence score, ідентифікатором партії.
## Результати після 6 місяців роботи
**Ключові метрики:**
- Рівень браку, що потрапив до замовника: знижено з 3.2% до 0.4%
- Витрати на ручний контроль: скорочено на 70% (4 інспектори з 6 переведені на інші позиції)
- Швидкість обробки: 4 200 деталей на годину (проти 1 800 при ручному контролі)
- Хибні спрацьовування в production: 2.1% (близько до цілі 2%)
**Окупність:** при вартості системи 320 000 грн і щомісячній економії 85 000 грн (зарплати + менші рекламації) — ROI досягнуто за 14 місяців.
## Типові помилки при впровадженні CV для QC
**Помилка 1: Недооцінка ролі освітлення.** 40% проблем з точністю CV-систем — це освітлення, не алгоритм. Вкладайте в правильне підсвічування.
**Помилка 2: Навчання на «ідеальних» умовах.** Якщо навчальні дані зібрані тільки вдень, система деградуватиме ночі або при зміні освітленості.
**Помилка 3: Ігнорування дрейфу.** Зміна матеріалу постачальника, нова партія кріплень — усе це може змінити розподіл вхідних даних і знизити точність. Потрібен моніторинг.
**Помилка 4: Відсутність людського контролю граничних випадків.** Для confidence score нижче порогу (наприклад 0.7) — скеровувати деталь на ручну перевірку, а не приймати автоматичне рішення.
Комп'ютерний зір для контролю якості — одна з найбільш зрілих і передбачуваних застосувань ML у промисловості. При правильному підході окупність досягається за 12–18 місяців, а скорочення браку на 60–80% є реалістичною метою.
Стаття в розробці. Підпишіться щоб отримати сповіщення.
Написати нам →#computer vision#виробництво#контроль якості#YOLO
ДК
Дарина Кравченко
Команда CodeNest
Практикуючий ML-інженер. Спеціалізується на побудові виробничих AI-систем для бізнесу.
🤖
Готові автоматизувати ваш бізнес?
Обговоримо ваш проєкт і запропонуємо оптимальне рішення. Безкоштовна консультація без зобов'язань.