"Хроники нагрева"

Привет, сегодня отправимся в Череповец :)

Хочу рассказать историю про то, почему формулировка бизнес-задачи не всегда полностью описывает реальную проблему, и почему в индустриальных CV-проектах так важно разбираться в процессе, а не только реализовывать запрос.

Кейс из реального производства: автоматическая выдача слябов из печей.
Для справки: что есть сляб - толстая стальная заготовка, являющаяся полупродуктом для производства листовой и рулонной стали

Исходный запрос звучал вполне разумно: “Необходимо понимать, есть ли сляб на рольганге, чтобы избежать столкновений и аварий”. Вы можете видеть результат столкновения и это в лучшем исполнении - в худшем случаи повредим оборудование.

На первый взгляд — типичная задача компьютерного зрения:

детектировать объект ➡️ передать сигнал ➡️ готово

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

Процесс оказался значительно сложнее:

__1. несколько печей
2. длинная линия перемещения
3. автоматический режим работы
4. датчики и лазерные барьеры, которые иногда ошибаются из-за дыма, пламени или условий эксплуатации
5. и высокая цена ошибки — простои и аварийные ситуации
__
Операторы уже давно научились с этим жить: если сигнал выглядит сомнительно — они смотрят на камеры и принимают решение вручную. Но в автоматическом режиме такая логика перестаёт работать так же надёжно.

В этот момент стало важно сделать шаг в сторону и задать вопрос: а какую проблему мы на самом деле хотим решить?

В реальности задача была не столько в том, чтобы “увидеть сляб”, сколько в том, чтобы:

__1. понимать логику движения заготовок
2. учитывать направление, остановки и возвраты
3. корректно работать в моменты, когда объект временно не виден
4. и при этом укладываться в жёсткие требования по времени реакции__

В результате решение превратилось не просто в модель, а в систему:

__1. лёгкий и быстрый детектор слябов
2. продуманная логика состояний
3. учёт движения и взаимного влияния печей
4. работа в сложной сетевой архитектуре
5. и дополнительный контроль перекрытия камер кранами с помощью оценки глубины, без специальных depth-камер__ (хотите узнать подробности? 🙃 )

Интересный момент: изначально бизнесу было важно сократить задержку реакции. Мы пробовали разные подходы — в том числе классические CV-методы и анализ визуальных признаков. Они давали сигнал, но не всегда достаточно устойчивый для промышленного использования.

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

Главный вывод из этого кейса, пожалуй, такой:

бизнес-запрос — это отправная точка, а не готовая постановка задачи компьютерного зрения: если не разобраться в процессе, можно сделать технически правильную, но мало полезную систему

Часто вас будут просить “детектировать”, “классифицировать”, “улучшить метрику”. Но настоящая ценность появляется тогда, когда вы помогаете уточнить саму задачу и сделать решение действительно работающим.