Перейти до змісту
Кейси

Комп'ютерний зір для контролю якості: як скоротити брак на 60%

18 квітня 2025 р.·12 хв читання·Дарина Кравченко
Зображення статті
## Проблема: чому ручний контроль якості не масштабується На більшості виробничих підприємств контроль якості досі здійснюється людьми. Контролер дивиться на деталь, оцінює її за набором параметрів і приймає рішення: годна чи ні. Ця система має фундаментальні обмеження: **Людська втома:** через 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-систем для бізнесу.

🤖

Готові автоматизувати ваш бізнес?

Обговоримо ваш проєкт і запропонуємо оптимальне рішення. Безкоштовна консультація без зобов'язань.

Схожі статті

Впровадити ML у вашому бізнесі?

Від безкоштовної консультації до production-рішення. Обговоримо вашу задачу.