Типичные ошибки при внедрении машинного зрения в ОТК и как их избежать

Разбор восьми ошибок, на которых чаще всего спотыкаются пилоты vision-контроля: от разрешения без привязки к дефекту и нестабильного света до отсутствия критериев приёмки и реакции на вердикт.

Типичные ошибки при внедрении машинного зрения в ОТК

Пилоты машинного зрения проваливаются предсказуемо. Причина почти никогда не в том, что нейросеть слабая — а в решениях, принятых до её обучения: не так поставили свет, купили камеру по мегапикселям, не описали, что считать браком. Итог одинаков: система формально работает, но на приёмке выясняется, что проверить её нечем, а на линии она либо пропускает брак, либо забраковывает годное. Ниже — восемь ошибок с конкретными сценариями отказа и тем, что сделать вместо. Материал дополняет базовый разбор компьютерного зрения в ОТК и ТЗ на систему технического зрения.

1. Разрешение выбрали по мегапикселям, а не по дефекту

Самая частая ошибка на входе. Камеру берут по числу мегапикселей, хотя решает не оно, а число пикселей на минимальный дефект. Простое правило: дефект должен занимать хотя бы несколько пикселей, а надёжно — порядка трёх-пяти пикселей в минимальном измерении, иначе алгоритм примет его за шум или блик при любом сенсоре.

Сценарий отказа: берут камеру 12 Мп на конвейер шириной 400 мм, радуются разрешению, а дефект 0,2 мм в таком поле зрения занимает меньше пикселя и не детектируется в принципе. Замена камеры на 20 Мп ничего не меняет — проблема в поле зрения, а не в сенсоре.

Что сделать: считать в обратную сторону. От минимального размера дефекта и требуемого поля зрения вычисляют нужную плотность пикселей на миллиметр, и уже она задаёт сенсор и оптику. Если требуемое разрешение недостижимо одной камерой — поле зрения дробят на несколько камер. Связка размер дефекта, поле зрения, сенсор разобрана в гайде как выбрать промышленную камеру.

2. Свет поставили в последнюю очередь

Освещение — не аксессуар, а половина системы. Нестабильный или бликующий свет даёт плавающий фон, и модель, обученная днём, ошибается вечером, когда в цех попадает солнце или включают другой светильник.

Сценарий отказа: пилот отлично отработал на настройке в 14:00, а к вечерней смене процент ложных срабатываний вырос вдвое — оказалось, солнце из окна под низким углом даёт блик на глянцевой детали, которого не было днём. Модель считает блик дефектом.

Что сделать: проектировать свет вместе с камерой, а не после. Выбирают тип подсветки под задачу (направленная, рассеянная, коаксиальная, тёмное поле), угол, защиту от внешней засветки — короб, шторы, поляризацию. Проверяют повторяемость сцены в разные смены и время суток, а не только в момент настройки. Разбор типов и геометрии — в гайде освещение для машинного зрения.

3. Собрали мало реальных дефектов и не заложили синтетику

Классический supervised-детектор требует сотен примеров каждого типа дефекта, а зрелая линия за год копит лишь десятки фотографий редкого брака. При запуске новой детали брак первые недели держится в районе долей процента, и отдельный тип дефекта может не встретиться ни разу за месяцы.

Сценарий отказа: пилот стартует, данных на редкий, но критичный дефект нет, проект встаёт на сборе датасета на неопределённый срок — линия работает, а система не обучается, потому что ждать естественного накопления брака можно кварталами.

Что сделать: заложить решение заранее. В план вносят накопление данных, привлечение контролёра ОТК к разметке и генеративный синтез недостающих дефектов. Что синтетика реально даёт по данным 2024–2026 годов и где поставщики округляют цифры — разобрано в гайде синтетические данные для контроля качества.

4. Задали единый порог точности вместо раздельных FAR и FRR

Требование точность 99% маскирует главную опасность — пропуск редкого брака. Представьте линию, где годных деталей 998 из 1000. Система, которая всегда говорит годная, ошибётся лишь на двух деталях из тысячи и покажет точность 99,8% — при том что не поймала ни одного дефекта и абсолютно бесполезна.

Что сделать: задавать раздельно и оба как максимум. Пропуск дефекта (FRR, escape rate) — доля брака, ошибочно признанного годным: например, не более 0,5% пропущенных дефектов класса A. Ложная отбраковка (FAR) — доля годных, отправленных в брак: слишком строгая система выбрасывает годное и убивает свою же окупаемость. Только раздельные пороги дают приёмке инструмент отличить рабочую систему от нерабочей.

5. Разметку отдали разметчикам общего профиля

Отличить пять визуально похожих типов скола способен обученный контролёр ОТК, а не разметчик с биржи. Разметка общего профиля даёт грязный датасет, на котором модель учится не тому.

Сценарий отказа: разметчик, не знающий детали, путает допустимую технологическую риску с трещиной и размечает их одинаково. Модель, обученная на таком датасете, либо забраковывает годное с рисками, либо пропускает трещины — и переучить её без пересборки разметки невозможно.

Что сделать: вести разметку по дефектам силами эксперта производства, а разметчикам общего профиля оставлять только простые однозначные классы. Это медленнее и дороже на входе, но иначе весь дальнейший результат стоит на песке: модель не бывает точнее своих меток.

6. Не описали поведение системы при отказе

Что делает линия, если камера или вычислитель недоступны? Если ответа нет в проекте, система по умолчанию пропускает весь поток как годный — худший из возможных сценариев, брак уезжает клиенту незамеченным именно в тот момент, когда контроль отключился.

Сценарий отказа: перегрелся вычислитель, инференс завис, конвейер продолжает идти, и полчаса продукции уходит без всякого контроля с отметкой годно по умолчанию. Обнаруживается это только по претензии.

Что сделать: описать поведение при отказе явно — остановка линии или сигнал оператору с переводом на ручной контроль, но никогда молчаливый пропуск. Отказ самой камеры или вычислителя должен детектироваться watchdog-ом, а не маскироваться последним нормальным кадром.

7. Система только сигналит, но не влияет на процесс

Экран с подсветкой дефекта не меняет ничего — оператор всё так же устаёт и пропускает, а к концу смены просто перестаёт смотреть на монитор. Vision окупается, только когда вердикт влияет на процесс.

Что сделать: проектировать реакцию на решение с самого начала — физическая отбраковка пневмотолкателем или стрелкой, остановка линии, запись в MES с прослеживаемостью каждой детали. Для записи в MES заранее согласуют протокол и поля: идентификатор детали, класс дефекта, время, изображение. Как связать вердикт с цеховыми системами — в гайде интеграция AI в MES/SCADA.

8. Запускали сразу на всю номенклатуру

Попытка охватить все детали и все дефекты одним пилотом растягивает проект и размывает ответственность: когда что-то не работает, непонятно, на какой детали и каком дефекте искать причину.

Что сделать: начинать с одной линии и ограниченной номенклатуры. Пилот проверяет гипотезу и даёт реальные FAR/FRR на вашем браке; масштабирование — уже инженерная задача с известными цифрами, а не эксперимент. Такой поэтапный порядок совпадает с логикой внедрения ИИ без остановки производства.

Мини-кейс: во что обходится ошибка на входе

Условный, но типичный расклад. Линия розлива, поток 120 деталей в минуту, критичный дефект — скол горлышка от 0,3 мм. На старте взяли камеру по принципу побольше мегапикселей и поставили свет как получилось. Первые две недели система показывала отличные метрики на дневной настройке, а на приёмке в вечернюю смену процент ложных отбраковок вырос вдвое из-за блика от заходящего солнца. Плюс камера с широким полем зрения давала на скол 0,3 мм меньше двух пикселей — часть сколов уходила как годные. Итог: месяц на пересъёмку датасета при исправленном свете и замену оптики на два узла вместо одного. Всё это закрывалось на этапе проекта расчётом плотности пикселей на дефект и коробом от засветки — до закупки, а не после.

Быстрый чеклист до старта

Перед запуском пилота пройдите список из восьми ошибок как вопросы: посчитали ли плотность пикселей на минимальный дефект; спроектирован ли свет вместе с камерой и защищён ли от внешней засветки; есть ли план на редкие дефекты и синтетику; заданы ли раздельные максимумы FAR и FRR с приёмочной выборкой; ведёт ли разметку эксперт ОТК; описано ли поведение при отказе; влияет ли вердикт на процесс, а не только на экран; ограничен ли пилот одной линией. Пустой ответ на любой пункт — это будущая доработка, которую дешевле закрыть сейчас, на бумаге.

Что это значит для внедрения на вашей линии

Семь из восьми ошибок закладываются до обучения модели — в оптике, свете, данных и критериях, и дешевле всего они правятся на бумаге, до закупки. Если прогнать проект по этому списку перед стартом, большая часть будущих доработок закрывается заранее, а пилот из бесконечной шлифовки превращается в проверяемую гипотезу. С формулировкой критериев приёмки и оценкой, что из этого применимо к вашей детали, помогаем на старте работы.

Данные нашего каталога Zavod.dev

Чтобы прикинуть бюджет на камеры и оптику ещё до КП, ниже — реальные данные нашего каталога машинного зрения Zavod.dev на момент публикации: 16 596 позиций, из них 12 160 (73%) в наличии, медианная цена 4 891 ₽. Ошибка выбора железа обходится дороже самого железа, поэтому цифры — ориентир, а не финальная смета.

Каталог Zavod.dev · камер машинного зрения · снимок на 03.07.2026
Позиций в каталоге16 596
В наличии12 160 (73%)
Медианная цена4 891 ₽
Диапазон массового сегмента (25–75%)1 914 – 14 884 ₽
Топ-производители по числу позицийOPT Machine Vision (2 990), Hikrobot (2 278), Allied Vision (1 298)
Открыть раздел в каталоге Zavod.dev →

Частые вопросы

Почему камера с высоким разрешением всё равно пропускает мелкие дефекты?
Разрешение сенсора решает не всё: важно число пикселей на минимальный дефект. Если дефект занимает меньше нескольких пикселей в кадре, алгоритм примет его за шум при любом числе мегапикселей. Считать нужно от размера дефекта и поля зрения, а не от паспорта камеры.
Чем опасен единый порог точности вместо раздельных FAR и FRR?
Единый порог маскирует пропуск редкого брака. Система, верно классифицирующая массовый поток годных, но пропускающая весь редкий дефект, покажет высокую точность и будет бесполезна. FAR и FRR задают раздельно и оба как максимум.
Почему нельзя запускать пилот сразу на всю номенклатуру?
Охват всех деталей и дефектов одним пилотом растягивает проект и размывает ответственность. Начинают с одной линии: пилот проверяет гипотезу и даёт реальные FAR/FRR на вашем браке, а масштабирование становится инженерной задачей с известными цифрами.
Что будет, если не описать поведение системы при отказе камеры?
По умолчанию система пропустит весь поток как годный, и брак уедет клиенту незамеченным. Поведение при отказе описывают явно: остановка линии или сигнал оператору, но никогда молчаливый пропуск.
Можно ли отдать разметку дефектов разметчикам общего профиля?
Нет. Различить визуально похожие типы дефекта способен обученный контролёр ОТК, а не разметчик с биржи. Разметка общего профиля даёт грязный датасет, на котором модель учится не тому, и портит весь дальнейший результат.