Задача, с которой пришел заказчик

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

Заказчику нужна всего одна цифра — доля оранжевой фракции. Для предприятия эта фракция самая интересная по составу, остальные классы имеют второстепенное значения. Эту цифру нужно предоставлять в режиме 24/7, без расхождений между сменами.

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

Что было ДО

Визуальную оценку фракциям давал геолог: смотрел на конвейер и писал в журнал что-то вида:

«80% оранжевой, 10% серой, 10% розовой».

Если на смене было несколько геологов, их оценки усредняли, что само по себе негативно сказывалось на точности.

Объективной валидации не существовало. Двух операторов одновременно на один участок не выводили, потому перекрёстных проверок не было. Еще одна проблема: ночная смена, которая вообще могла не предоставить эти цифры, в интервале 22:00–06:00 в журнале зачастую было пусто. Этот факт и был основной мотивацией заказчика для внедрения системы машинного зрения, которая может покрыть все 24 часа и не пропустить ключевую для заказчика фракцию.

Почему пороговая фильтрация по цвету не подошла

Первоначально тестировли HSV-пороги. На статичных снимках с равномерной подсветкой это давало понятные маски. На реальном конвейере — нет, поскольку поверхность кусков неоднородная, между классами по оттенку есть пересечения: серо-белая фракция в загрязнённой части по пикселю не отличается от пыли на оранжевой. Задача — instance segmentation, не семантическая. Один крупный камень и пять мелких одинаковой суммарной площади дают одну и ту же пиксельную долю класса, но это разный гранулометрический состав с разным поведением в обогащении.

Разметка: слишком дорого

Один кадр содержит от 100 до 900 камней. Формы неправильные, грани острые, между соседними камнями зазоров часто нет — куски лежат вплотную или с наклоном друг на друга.

• Полностью ручная полигональная разметка одного кадра занимала около часа.

• Для тренировочного набора на 500+ кадрах это означало 500+ часов работы разметчика — за пределами бюджета проекта.

• Встроенные AI-инструменты CVAT— Magic Wand и Intelligent Scissors не дают классов — только геометрию контура.

• На острых гранях контур уходил в сторону, соседние камни без видимого зазора стягивались в один полигон. Размеченный результат приходилось перерисовывать вручную — быстрее было разметить с нуля.

SAM2 для разметки

Помог Segment Anything Model 2 в режиме автоматической сегментации. SAM2 проходит по всему кадру и выдаёт маски всех найденных объектов в zero-shot. Качество границ: пиксельное, классов модель не знает.

Пайплайн получился такой:

1. Прогон SAM2 в everything-режиме по кадру.

2. Конвертация масок в полигоны, импорт в CVAT.

3. Ручная работа разметчика: присвоение классов, удаление лишнего, склейка разорванных масок.

Время на разметку кадра сократилось до 15–20 минут. В бюджет укладывались. 

Что казалось логичным, но мы не сделали

Логика подсказывала: нужно фильтровать выход SAM2 — отбрасывать маски ниже минимальной площади, проверять компактность, выкидывать тени по контрасту с фоном. Но мы это не делали.

На конвейере много “мелочи”: куски 5–10 мм, пыль, крошка. Это та же руда, и в общем составе она тоже считается. Если ставить фильтр по площади, “мелочь” выпадает целиком и доли по классам поплывут. Фракция пыли у разных партий разная.

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

Дисбаланс классов и подмешивание данных

Первая итерация сборки датасета — случайные кадры с конвейера. На ~200 кадрах оранжевая фракция занимала почти весь объём аннотаций. Серо-белой фракции было умеренно. Розовой — меньше 5% от общего числа объектов. Модель, обученная на этом, розовую руду либо пропускала, либо относила к оранжевой: на границе оттенков они близки, и при таком дисбалансе сеть выгоднее всегда ставить оранжевый.

Что с этим сделали?

1. Попросили заказчика инсценировать кадры с преобладанием розовой. Конвейер останавливали, на чистую ленту партиями выкладывали отобранную розовую руду, запускали ленту, снимали той же камерой при той же подсветке. Так доля розовой во вторичной выборке поднялась примерно до 25%. Это уже не реальное распределение с площадки, это управляемое подмешивание. Но без него класс не учился вообще.

2. “Розовому” классу подняли вес в функции потерь — штраф за пропущенный или неверно классифицированный розовый камень стал выше. Recall по розовому вырос, но на переходных оттенках между оранжевым и розовым сеть начала смещаться в сторону розового.

3. С пограничными случаями отдельного протокола разметки не выработали. Был ведущий разметки, который теоретически мог пересматривать спорные кадры, но валидация шла выборочно. Решение разметчиков по умолчанию: относить спорный камень к оранжевой, потому что она статистически преобладает и ошибка в её сторону меньше всего смещает итоговую долю по абсолютной величине. Это не самый чистый подход, но альтернатива — выработка письменного гайда по 15–20 категориям пограничных оттенков — на таком датасете не имела смысла.

Перекрытия и частичный объём

Камни на ленте лежат с перекрытием. Нижний кусок виден частично — треть, четверть, иногда меньше. Достраивать форму под перекрытием модель не умеет, и закладывать это в постобработку не стали.

В задаче нужна доля по цвету, не точный объём отдельного камня. При перекрытии модель “режет” нижний камень по контуру верхнего и считает по видимой маске. В статистику идёт частичный объём пропорционально видимой площади.

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

Финальная модель — YOLO-seg.

Датасет на момент релиза составлял 600–800 кадров с разметкой. Маски, которые рисует обученная YOLO, заметно грубее, чем у SAM2: углы скруглены, мелкие выступы и вогнутости пропускаются. Для пиксельной точности этого мало. Для подсчёта доли по классам — достаточно, потому что итоговая метрика интегрирует по большому числу объектов в кадре и грубость контура отдельной маски почти не влияет на агрегат.

Инференс ~10 мс на кадр (GPU, batch=1). Камера даёт 25 fps, обработка успевает с тройным запасом. Edge-инференс на самом конвейере не понадобился — поток шёл на сервер по локалке.

Альтернативы, которые рассматривались:

• Mask R-CNN: качество масок выше, латентность ~100 мс, разметка дороже из-за отсутствия удобной интеграции с SAM2-пайплайном.

• U-Net + постобработка: семантика без instance, для подсчёта по объектам не подходит.

• SAM2 в проде: ~300 мс на кадр, классов не выдаёт, для применения в реальном времени не годится, классификатор пришлось бы прикручивать сверху.

YOLO — компромисс между качеством, ценой разметки и временем инференса.

Особенности валидации

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

Заказчик отбирал камни заранее: например, 60 оранжевых, 20 серо-белых, 10 розовых, известный состав. Эту партию выкладывали на чистую ленту, конвейер запускали, модель выдавала JSON.

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

С чем модель не справилась

Модуль пишет JSON с долями по трём фракциям каждые N секунд, без перерывов. Ночные смены больше не требуют оператора на визуальную оценку. Один и тот же кадр каждый раз даёт одинаковый результат — ранее такой повторяемости не было.

С чем модель не справляется (здесь по-прежнему нужен человек):

• Модель не считает абсолютный объём отдельного камня. В статистику идёт видимая часть.

• На пограничных оттенках между оранжевой и розовой даёт систематический сдвиг в сторону, заданную взвешенным лоссом.

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

• Не реагирует на дрейф входа. Если на конвейер придёт партия из нового карьера с другим распределением цветов или сторонним материалом — модель продолжит классифицировать по своим трём классам. Контроль дрейфа делает человек по выходному химическому анализу.

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

Если сталкивались с похожей задачей — разметкой плотно лежащих объектов или instance segmentation на промышленном потоке — интересно сравнить, как решали слипание и редкие классы. Приглашаем обсудить!