Розробка комп'ютерного зору: де ламається пілот
Пілот розпізнавання рідко провалюється на самій моделі — він провалюється на переході в експлуатацію. На підготовленій вибірці метрики виглядають переконливо, а на живому потоці той самий алгоритм дає спрацьовування, які оператор перестає приймати. Далі починається доопрацювання без критерію готовності.
Перша причина — нерівномірне світло й геометрія сцени. Модель навчають на кадрах, знятих у зручних умовах, а в цеху освітлення змінюється за змінами, з'являються пересвіти й відблиски на металі та глянцевій упаковці.
Якщо розробка комп'ютерного зору не починається з оцінки камери, світла й стабільності ракурсу, точність просідає за незмінного коду.
Друга — рідкісний клас дефекту. Браку мало, він займає частки відсотка вибірки: середня точність за всіма класами залишається високою, а конкретно рідкісний клас система не ловить.
Його маскує загальна метрика, тому потрібен окремий вимір за кожним класом і план добору прикладів, а не просто зростання обсягу розмітки.
Третя — нестабільна розмітка. Поки критерій браку тримається в голові оператора, той самий кадр розмічається по-різному, і модель навчається на суперечностях.
Лікується це регламентом: опис класів, розбір спірних кадрів, повторна перевірка частини вибірки й контроль узгодженості між розмітниками.
Четверта — відсутність приймання на реальному потоці. Якщо заздалегідь не зафіксовано, яку частку пропусків і хибних спрацьовувань вважаємо прийнятною і як система поводиться при відмові, прийняти пілот нічим. Розбираємо, як це закривається на кожному етапі.
Ефект впровадження: контроль якості та розвантаження операторів
Метрики рахуємо до запуску, на пілотній вибірці кадрів з лінії: частка пропущеного браку, кількість хибних спрацьовувань за зміну, час розбору спірного кадру й скільки рішень оператор ухвалює вручну. Це чотири величини, за якими видно, чи працює система, — а не загальна «точність моделі» у звіті.
Після виведення в роботу частка пропущеного браку на контрольованих класах дефектів опускається нижче відсотка: модель дивиться 100% виробів, а не вибірково кожен десятий.
Хибні спрацьовування гасимо порогом упевненості й донавчанням на спірних кадрах — на зміну залишаються одиниці замість сотень, лінія не зупиняється на переперевірках.
Обчислення йдуть на прискорювачах NVIDIA: кадр обробляється швидше, ніж конвеєр видає наступний, тому темп лінії знижувати не доводиться. Розвантаження оператора — наслідок: більшість рішень ухвалює система, людина розбирає лише спірні кадри й підтверджує зміну.
Час розбору спірного кадру падає з хвилин до секунд: поруч лежать кадр, виділена зона дефекту й версія моделі, яка його винесла.
Стабільність якості дає не пік, а розкид: оператор наприкінці зміни реагує інакше, ніж на початку, модель — однаково, тому розбіжність між змінами й майданчиками скорочується.
Окремо ведемо журнал: які дефекти йдуть у пропуск, на яких матеріалах зростає частка спірних кадрів. Це готовий план донавчання й зрозуміла межа — що система контролює впевнено, а де рішення залишається за людиною.
Готові моделі, донавчання або навчання з нуля
До робочої моделі ведуть три шляхи, і вибір підходу визначається не модою, а даними: скільки розмічених прикладів є на руках, наскільки однорідна сцена і яку частку помилок замовник вважає допустимою.
Готова модель закриває задачу за лічені дні — але тільки якщо ваші класи й умови знімання збігаються з тими, на яких вона навчалася.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Готова модель | Класи й сцени збігаються з навчальним набором, типової точності достатньо | Не тягне нестандартний ракурс, рідкісний клас, свою модальність — потрібна перевірка на ваших кадрах |
| Донавчання моделі (перенесення навчання) | Свої класи, але дані того самого типу: та сама камера, освітлення, масштаб об'єкта | Потрібна розмітка тисяч кадрів; за сильної зміни умов знімання ознаки «замерзають» і якість не зростає |
| Навчання з нуля | Унікальна модальність: тепловізор, дефекти конкретного виробництва, нестандартний сенсор | Довгий цикл, великий обсяг розмітки, архітектура й валідація проєктуються з нуля |
Вибір підходу ми не робимо на око. Спершу проганяємо готову модель на кількох сотнях кадрів замовника й дивимося, де саме вона помиляється — на рідкісному класі, на пересвіті, на нічному зніманні.
Якщо типові кадри тримає впевнено, а розсипається лише на вашій специфіці — це перенесення навчання. Якщо ж схожих даних не існує в природі, говоримо прямо: готова модель не запрацює, потрібні архітектура й розмітка з нуля.
Шлях проєкту: постановка задачі, розмітка, навчання, приймання
Критерій придатності фіксуємо до першого рядка коду — інакше приймання перетворюється на спір про смаки. На кожному кроці є контрольна точка: поки її не пройдено, наступний не починається, і це помітно дешевше, ніж перенавчати модель на погано розмічених даних.
- Постановка задачі. Описуємо, що вважається подією на кадрі, в яких умовах працює камера і яку частку пропусків і хибних спрацьовувань вважаємо допустимою. Підсумок етапу — критерій придатності у вимірюваних величинах.
- Розмітка даних. Беремо реальні записи об'єкта, включно з важкими кадрами: ніч, дощ, перекриття, відблиски. Розмітка йде за письмовим регламентом, спірні випадки розбирає арбітр, п'яту частину кадрів перевіряє другий розмітник.
- Навчання моделі. Донавчаємо базову модель, окремо тримаємо відкладену вибірку, яка не бере участі в налаштуванні. Дивимося не на середню точність, а на рідкісні класи — зазвичай саме вони ламають експлуатацію.
- Валідація на потоці. Запускаємо модель у тіньовому режимі поряд з робочим процесом і звіряємо її рішення з фактом. Тут видно розбіжності лабораторних метрик із реальністю: зміна освітлення, зсув камери, новий тип об'єкта.
- Пороги й стійкість. Поріг спрацьовування добираємо під ціну помилки, описуємо поведінку при втраті кадру або недоступності камери — система має деградувати передбачувано.
- Приймання й передача. Прогін на контрольному відрізку, не використаному ні при навчанні, ні при налаштуванні, і звірка з критерієм придатності з першого кроку. Віддаємо модель, конфігурацію, регламент розмітки й порядок повернення до попередньої версії.
Комплект постачання: модель, розмітка, документація, регламенти
Комплект постачання збирається так, щоб команда замовника могла навчити, перевірити й замінити модель без нас.
Тому до нього входять не лише ваги, а й усі шари, від яких залежить відтворюваність результату: дані й правила їх розмітки, конфігурації навчання, права на роботу з відеопотоками й регламенти експлуатації.
- Навчена модель і контрольні точки — робочі ваги у форматі, який приймає ваш контур виконання, плюс проміжні знімки за етапами навчання: відкат на попередню версію займає хвилини, а не нову ітерацію збору даних.
- Набори даних і карта розмітки — вихідні та розмічені вибірки, опис класів, правила для пограничних і спірних об'єктів. Карта розмітки знімає головне джерело розбіжностей, коли до анотування підключаються нові люди.
- Відтворюваність навчання — конфігурації, зафіксовані версії залежностей, порядок перемішування й протокол контролю якості. Повторний запуск дає зіставну точність, а розбіжність пояснюється, а не списується на «магію».
- Схеми інтеграції — як модель вбудовується у відеопотік, де точки відмови, які затримки очікувані на кожній ділянці обробки кадру.
- Політики доступу до відео — хто і на якій підставі бачить потік і архів, строки зберігання, знеособлення, журналювання звернень до записів. Це ж знімає питання служби безпеки при передачі системи.
- Регламент експлуатації — що робити при падінні точності, як виводиться нова версія, хто ухвалює рішення про перенавчання, як фіксуються інциденти й деградація на зміні освітлення або сезоні.
- Комплект документації — інструкції для операторів і чергових, опис метрик якості, порядок приймання й передачі зміни, словник термінів предметної області.
Кейс контролю якості: система комп'ютерного зору на лінії
До впровадження
На лінії розливу полімерної упаковки контроль вели вибірково: оператор ВТК знімав кожну двадцяту тару й оглядав візуально. Пропуск дефектів сягав 7% — мікротріщини й неповний шов ішли на палетування й поверталися рекламаціями за партією. Хибні тривоги давали 15%: лінію зупиняли на переперевірку, випадав змінний темп.
Ітерації моделі та зміна схеми знімання
Перша версія на чотирьох тисячах кадрів знизила пропуск до 4%, але на рідкісних класах залишалася сліпою — менше сотні прикладів на весь набір.
Змінювали не модель, а знімання: бічна підсвітка під кутом до горловини, синхронізація камер із датчиком позиції, відсів змазаних кадрів, розмітка спірних випадків у CVAT з подвійною перевіркою інженером.
База зросла до 16 тисяч кадрів, рідкісні класи доповнили до трьох тисяч прикладів. Друга ітерація дала пропуск 1,2% і хибні 6%, третя — 0,9% і 1,8%: додали підтвердження за трьома послідовними кадрами, щоб одиничний відблиск на етикетці не йшов у брак.
Результат
Дефектну тару відводять за сигналом без зупинки конвеєра, оператор займається лише спірними випадками — їх менше двох відсотків.
Ваги й конфігурація версіонуються, відкат на попередню версію займає хвилини, а нові типи дефектів додавали в розмітку вже після запуску: перенавчання пройшло без змін в оптиці й механіці лінії.
Що робити, якщо камери вже стоять і є архів записів
Почати можна без заміни парку — питання лише в тому, чи вистачає поточних камер і записів під задачу.
Інвентаризація займає кілька днів: перевіряємо ракурси й стабільність кріплення, реальну глибину й повноту архіву, освітленість у потрібні години, запас пропускної здатності мережі.
Зазвичай частина камер дає придатний потік, а частину доводиться виключати з контуру — їхні кадри лише зашумлять навчання.
Далі вибираємо один із трьох сценаріїв старту: вони різняться терміном запуску й обсягом даних, який потрібен до першої робочої моделі.
| Варіант старту | Коли підходить | Обмеження |
|---|---|---|
| Навчання на архіві | Записи потрібних сцен є за кілька місяців, ракурс камер не змінювали | Якість залежить від стиснення й нічного знімання; рідкісні класи об'єктів доведеться добирати доопрацюванням |
| Дооснащення точок знімання | Архіву немає або ракурси не покривають зону інтересу | Довший запуск: монтаж, підсвітка, калібрування |
| Гібридна схема | Частину задач закривають поточні камери, частину — ні | Складніше налаштування й синхронізація подій між контурами |
При навчанні на архіві вибірку розмічаємо стратифіковано: день і ніч, будні й вихідні, сезон. Відкладену частину беремо з іншого періоду запису — інакше метрика на своїй же вибірці виявиться завищеною і в реальному контурі модель просяде.
Передобробку ведемо на відкритих бібліотеках, наприклад OpenCV, щоб не залежати від закритих ліцензій.
Гібридна схема найчастіше й виявляється робочою: наявні камери, сервер і канали перевикористовуються, а дооснащення йде точково — підсвітка або додатковий ракурс там, де модель недобирає точність.
Такий старт не зупиняє поточні процеси, а перші вимірювані результати з'являються на вже встановленому обладнанні.
Технічні сумніви: світло, розмітка, хибні спрацьовування
Кожен проєкт розпізнавання впирається в чотири речі: умови освітлення, якість розмітки, поріг спрацьовування й поведінку при збоях. Їх обговорюють до старту, бо саме вони визначають, скільки ручної перевірки залишиться оператору й як швидко система окупить впровадження.
Нижче — питання, які найчастіше ставлять технічні керівники перед оцінкою проєкту.
Що робити, якщо освітлення змінюється протягом зміни?
Ми не покладаємося на одну камеру й одне джерело світла. Сцену перевіряємо в найтемніших і найзасвіченіших умовах: контрове світло, відблиски від мокрої підлоги, частина зміни.
Якщо розкид яскравості великий, додаємо підсвітку в невидимому діапазоні й фіксуємо експозицію — модель бачить стабільну картинку, а не плаваючу.
Як зрозуміти, що розмітка якісна?
Розмітку ведемо за регламентом: спірні кадри йдуть на другу перевірку, а частка розбіжностей між розмітниками слугує метрикою якості.
Частину даних розмічаємо автоматично й перевіряємо вибірково — так швидше набирається обсяг під рідкісні класи, які зазвичай і провалюються на реальних сценах.
Як знижуєте хибні спрацьовування?
Поріг упевненості добираємо під ціну помилки: пропуск і хибна тривога коштують по-різному. Спірні кадри не викидаємо, а надсилаємо в донавчання — частка хибних тривог падає в міру накопичення даних.
Що відбувається при деградації моделі або збої камери?
Стежимо за дрейфом даних: якщо розподіл кадрів відходить від навчального, деградація моделі йде тихо, тому метрики рахуються і на контрольній вибірці, і на живому потоці.
При втраті камери система переходить у безпечний режим — фіксує подію, віддає оператору й не видає випадкових рішень.
Почнемо з вашої задачі: що надіслати для оцінки
Оцінка проєкту комп'ютерного зору впирається не в алгоритм, а в дані й умови знімання. Тому вихідні дані для оцінки ми збираємо однаково — за списком нижче. Якщо надішлете це, повернемося не із загальними словами, а зі схемою рішення й планом етапів.
- Відео або архів кадрів із майданчика: різні години, освітлення, погода, ракурси.
- Перелік об'єктів і подій: що потрібно знаходити, що вважаємо пропуском, а що — хибним спрацьовуванням.
- Умови знімання: тип камер, висота підвісу, зона огляду, чи є поворот і наближення.
- Що має відбуватися з подією: запис, сигнал оператору, команда суміжній системі.
- Де планується обробка: на об'єкті чи на ваших серверах, який доступ до відеопотоку є.
- Обмеження: вимоги до зберігання даних, приватність, зони, де знімання заборонено.
- Критерій приймання: за якою метрикою ви будете вважати систему робочою.
- Строки й етапність: чи є жорстка дата запуску і що має працювати першим.
Якщо частини даних немає — не страшно, ці відповіді уточнюємо на обговоренні задачі. Далі фіксуємо схему рішення, план етапів і обсяг робіт за кожним.
