alexeyroslyakov

alexeyroslyakov

Привет. Меня зовут Алексей. Помогаю внедрять Ai решения. Рассказываю о бизнесе, факапах, личных вызовах и путешествиях. Мой тг-канал: https://t.me/roslyakovgo
На Пикабу
180 рейтинг 6 подписчиков 0 подписок 4 поста 1 в горячем
2

Все хотят модный ИИ. Но почти никто не понимает, куда его воткнуть на производстве

Последние пару лет ИИ на производстве стал чем‑то вроде обязательного пункта повестки. Про него говорят собственники, его ждут от команд, его упоминают в стратегиях «на будущее». Часто – с молчаливым ожиданием, что ИИ сам по себе наведет порядок: ускорит процессы, сократит ручной труд, сделает бизнес более управляемым.

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

Эта статья – о том, как на самом деле выглядит работа с ИИ на производстве. Не как модный эксперимент, а как управленческий подход. Мы разберем один реальный производственный кейс и покажем, почему ИИ начинает работать только тогда, когда перестает быть самоцелью.

Как выглядел запрос клиента

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

Разговор начался с осторожным интересом и сомнением:

«Давайте подумаем, где мы можем внедрить ИИ, чтобы он дал результат».

За этой формулировкой стояло вполне понятное состояние. С одной стороны – ощущение, что бизнес упирается в потолок эффективности. С другой – непонимание, за что именно хвататься.

На старте ни собственник, ни команда не могли четко сформулировать:

– какие конкретные проблемы должен решить ИИ;
– где компания реально теряет деньги или время;
– какие решения сейчас принимаются скорее «по опыту», чем на основе системы.

При этом внутреннее напряжение уже накапливалось. Много ручных операций. Сильная зависимость от отдельных людей и их экспертизы. Разные подразделения опираются на разные цифры. Эффект от изменений часто становится понятен слишком поздно – когда что-то исправлять уже дорого или сложно.

В такой точке ИИ выглядит почти спасением. «Он же должен уметь считать, подсказывать, автоматизировать». Именно с этим ощущением клиент и пришел.

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

Почему нельзя начинать с ИИ

На старте кажется, что все и так понятно: где‑то много ручного труда, где‑то не хватает прозрачности, где‑то люди перегружены. Хочется сразу идти в решения.

Но в реальности у каждого блока своя картина происходящего. Производство видит одни узкие места. Финансы – другие. Коммерция – третьи. Если в этот момент начинать внедрять ИИ точечно, под запрос одного отдела, результат почти всегда получается локальным и плохо масштабируемым.

Поэтому в этом проекте мы принципиально не начинали с технологий.

Что мы сделали вместо этого

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

Первым шагом стали разговоры с руководителями всех ключевых блоков: производства, финансов, КБ, коммерции, логистики. Не презентации и не сбор идей «что можно автоматизировать», а подробный разбор реальной управленческой рутины.

Мы спрашивали:

– какие решения вы принимаете регулярно;
– где уходит больше всего ручного времени;
– в каких местах вы понимаете результат слишком поздно;
– где бизнес держится не на системе, а на конкретных людях.

Эти разговоры быстро показали: запрос на ИИ – это следствие, а не причина. Основные проблемы лежат в несогласованных данных, ручных пересчетах, разрывах между подразделениями.

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

Дальше мы собрали собственника и всю управленческую команду на стратегическую сессию. Цель была не в том, чтобы придумать решения, а в том, чтобы впервые посмотреть на проблемное поле целиком – одной командой. Проговорить, подтвердить, приоритизировать и соотнести с тем, каким бизнес должен стать через несколько лет.

Именно здесь обычно и становится понятно, зачем вообще нужны такие сессии, если «и так все ясно». Пока проблемы не названы и не согласованы вместе, любые технологии лечат симптомы, а не причины.

По итогам сессии команда неожиданно поймала себя на странном ощущении. Они шли на встречу с ожиданием, что два часа будут говорить про ИИ – возможности, инструменты, «фокусы». А вместо этого почти все время ушло на спокойный и местами даже нудный разбор узких мест компании: где решения принимаются вручную, где данные не сходятся, где бизнес держится на людях, а не на системе. В этот момент стало особенно ясно, что проблема была не в отсутствии ИИ, а в отсутствии общей картины.

Где ИИ действительно дал эффект (а где – нет)

Когда проблемное поле было согласовано, а приоритеты расставлены, разговор про ИИ резко изменился. Он перестал быть абстрактным и стал прикладным.

Выяснилось, что значительная часть проблем вообще не требует ИИ. Где-то достаточно упростить процесс. Где-то – договориться о единых правилах расчета. Где-то – убрать ручные исключения.

ИИ появился только в тех точках, где:

– есть повторяющаяся операция;
– задействовано несколько человек;
– цена ошибки ощутима;
– автоматизация дает понятный экономический эффект.

Один из таких примеров – склад.

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

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

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

Важно, что в других блоках ИИ сознательно не внедряли. Потому что сначала нужно было привести в порядок данные, логику расчетов и саму управленческую модель. Без этого любые «умные» инструменты не дали бы устойчивого результата.

Почему так сработает не у всех

После подобных историй часто возникает желание повторить: «значит, нам тоже нужен ИИ».

Но здесь важно быть честными. ИИ не станет волшебной палочкой, если:

– процессы нестабильны;
– данные противоречат друг другу;
– решения все равно принимаются по ощущениям;
– бизнес не понимает, какие проблемы для него критичны.

В такой ситуации ИИ либо не даст эффекта, либо создаст новые точки сложности.

Как работать с ИИ, чтобы он действительно давал эффект

Рабочий подход почти всегда начинается не с технологий, а с управления:

  1. Понять, какие решения в бизнесе реально влияют на деньги.

  2. Разобраться, где эти решения принимаются вслепую или с запозданием.

  3. Навести порядок в процессах и данных.

  4. И только потом использовать ИИ – там, где он дает измеримый результат.

Именно такой подход мы и называем цифровой стратегией.

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

Поэтому цифровая стратегия – это не просто выбор технологий. Это честный разговор о том, как компания принимает решения и где она теряет эффективность. Иногда в этом разговоре ИИ оказывается полезным инструментом. Иногда – нет. И это нормально.

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

Если вам сейчас тоже кажется, что «ИИ вроде бы нужен, но непонятно зачем и куда», возможно, стоит начать не с технологий, а с этого разговора.

Показать полностью 5
7

Как мы ускорили видеоаналитику в шесть раз и не купили ни одной новой видеокарты

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

Но у этой магии есть обратная сторона — она очень прожорливая. Видеопотоки нужно прогонять через нейросети, и на больших данных даже мощные сервера начинают задыхаться. Особенно если система собрана «из коробки» и не оптимизирована.

Проблема клиента

С такой ситуацией к нам и пришёл клиент. У него уже стояла система видеоаналитики: несколько десятков камер, подключённых к серверу с GPU. Всё вроде бы работало, но слишком медленно. За тридцать секунд система успевала обработать всего четыре видеопотока.

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

Первое решение, которое обсуждали у клиента, было максимально простое: «давайте купим ещё одну видеокарту». Казалось бы, логично: больше железа — больше мощности. Но стоимость оборудования в такой конфигурации была бы сравнима с ценой небольшой машины, и это только начало расходов. К железу пришлось бы докупать софт, поддерживать инфраструктуру, а эффект при этом не гарантирован.

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

С чего начали

Мы всегда начинаем с диагностики. Сели и посмотрели, как именно устроен процесс. Выяснилось, что система работала «по накатанной»:

  • каждый видеопоток подавался в нейросеть отдельно,

  • обработка шла строго по очереди,

  • процессор и видеокарта работали не синхронно и большую часть времени простаивали.

Отдельная история была с разрешением входных кадров. В сеть загонялись изображения 640×480. Для бытовой камеры это кажется скромным размером, но для нейросети это лишние пиксели. Сеть честно пыталась их проглотить, только толку от этого не было. Людей в кадре это не делало «более узнаваемыми», зато ресурсы уходили в никуда.

Почему уменьшение разрешения — не страшно

Один из мифов видеоаналитики: «чем выше качество изображения, тем лучше результат». На самом деле это не всегда так. В задачах распознавания людей важны крупные контуры, движения, ключевые признаки. Увеличение разрешения до абсурда лишь добавляет лишние детали — плитка на полу, трещины на стенах, мелкие артефакты, которые для задачи не имеют никакого значения.

Мы начали постепенно уменьшать размер входных кадров. Эксперименты показали, что оптимальная точка — примерно 416×256. Это почти в полтора раза меньше исходного, но качество распознавания людей сохранилось. Зато скорость обработки резко выросла.

Параллельная обработка и балансировка

Следующим шагом было изменение самой логики работы. Если раньше система напоминала кассу в магазине, где очередь из десяти человек обслуживает один кассир, то мы сделали так, чтобы работало сразу несколько касс. Видео стали обрабатываться параллельно, и сразу загрузка ресурсов выросла в разы.

Здесь важно было грамотно распределить задачи между CPU и GPU. До оптимизации они работали несогласованно: GPU простаивал, пока процессор готовил данные, а процессор ждал, пока GPU «пережёвывает» ролик. Мы сделали так, чтобы GPU занимался инференсом, пока новые фреймы готовятся на CPU. Теперь оба ресурса загружены равномерно.

Результат

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

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

Что это показало

Опыт с этим проектом стал для нас хорошей иллюстрацией нескольких важных принципов.

Во-первых, в работе с нейросетями не всегда выигрывает максимальное разрешение. Иногда лишние пиксели только мешают.

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

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

Итог

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

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

Показать полностью 4
6

Продолжение истории: блики, цифры и немного дзена

На заводах ИИ мы внедрять умеем, а нормального кота сгенерить не смогли. Штош

На заводах ИИ мы внедрять умеем, а нормального кота сгенерить не смогли. Штош

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

Про “чёрный короб”

Да, идея хорошая и часто действительно спасает.
Но у нас было три метра конвейера, по которому летят зеркальные листы со скоростью 2 м/с.
А пыль, тепло, вибрации и необходимость обслуживать оптику делают «чёрный ящик» скорее лабораторным решением, чем промышленным.

Про поляризацию и металл

«Поляризаторы на металле не работают!» — писали вы.
И вы… почти правы.
На идеально зеркальной поверхности эффект действительно слабый.
Но на загрязнённых, частично матовых и неидеальных листах он даёт до 15–20 dB подавления бликов.
Не магия — просто физика, немного геометрии и много проб и ошибок.

Про “дешёвого человека с глазами”

Мы тоже любим людей с глазами. И даже работаем вместе.

Система не заменяет оператора — она отсекает рутину, где глаз устаёт, а блик обманывает.
Раньше контролёр тратил на проверку одного листа около 6–8 секунд и при этом пропускал до 10–12% микродефектов.

Теперь камера справляется за 1.2 секунды, а доля спорных случаев, которые уходят на ручную проверку, не превышает 3–5%.
Вместо бесконечного «вглядывания в зеркало» оператор теперь проверяет только то, где нейросеть не уверена — и делает это в разы быстрее.

Так что не «человек против машины», а человек + машина против скуки и брака.

Про “азов фотографии”

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

Про “всё равно не автономно”

Справедливое замечание.
Промышленное CV пока действительно не живёт без инженеров — но и не должно.
Как и любая сложная система, оно развивается итерационно: данные → обучение → адаптация → стабильность.
Главное, что теперь инженеры на линии решают не “почему камера не видит”, а “как улучшить метрики”.

На сладкое

Теперь точно знаем, что идеальных данных не бывает, что FTP живёт дольше всех,
и что на заводе «хорошее освещение» — это инженерное чудо, а не кнопка в настройках.

Спасибо всем, кто спорил, шутил и предлагал решения — ваши комменты были лучшим продолжением истории, чем любой отчёт по внедрению❤️

Больше живых кейсов моя команда разбирает в новом ТГ-канале https://t.me/brains2up
Подписывайтесь, если хотите чаще читать про настоящий ИИ.

Показать полностью
85

Как мы внедряли CV на заводе — и выживали1

Всем привет! Меня зовут Алексей, я руковожу компанией, которая занимается разработкой с применением ИИ-технологий. Сам я  тоже погружен в разработку, но больше доверяю это своей команде – нам удалось собрать команду классных профи. Истории из нашей совместной работы я и планирую рассказывать в своем блоге.

Cегодня делюсь историей одного из наших разработчиков – о внедрении компьютерного зрения на реальном производстве.

Первый день на линии выглядел почти комично. Стоим втроём в касках, над конвейером — новая промышленная камера с глобальным затвором (5 Мп, FOV ~0,6 м), а под ней со скоростью 2 м/с уезжают листы с зеркальным блеском. Оператор рядом фыркает:

— «Ну и где твои умные нейросети? Вон же царапина!»

На экране вместо царапины — пересвеченный до насыщения белый блик: без перекрёстной поляризации и со слишком длинной выдержкой он превращается в «идеальный» объект для детектора. Алгоритм радостно машет флажком: «дефект!». Таких ложных срабатываний за смену набегало сотни; настоящие микротрещины и сколы тонули в засветках и смазе.

С этого момента стало ясно: впереди не «проект на пару недель», а марафон, где придётся бороться не только с кодом, но и с реальностью цеха — вибрациями, пылью, бликами и древним MES, говорящим по OPC/Modbus.

Зачем всё это

Один крупный производственный заказчик (линия резки листового материала: зеркальная поверхность, скорость ~2 м/с) решил автоматизировать контроль дефектов.

Раньше инспекция была ручной — оператор просматривал каждый лист.

Как мы внедряли CV на заводе — и выживали

На старте задача выглядела так:

  • Ставим камеру над линией: Basler ace2, 5 Мп, глобальный затвор; C‑mount 12 мм; FOV ≈ 600 мм; аппаратный триггер от энкодера; экспозиция 30–50 мкс; импульсный LED 630 нм с перекрёстной поляризацией.

  • Режем изображение на тайлы: 1024×1024 px с overlap 20%; deskew по кромке листа; маска бликов.

  • Детектим дефекты: царапины, пузыри, перекос, сколы (15 базовых классов); модель YOLOv5m, инференс FP16 (ONNX Runtime).

  • Возвращаем результаты в MES/SCADA: JSON → XML/FTP (атомарный rename) с переходом на OPC UA; координаты дефектов в мм, sheet_id, статус OK/NOK.

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

Сюрприз №1: Светит, но не туда

Проблема: освещение и блики

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

Как мы внедряли CV на заводе — и выживали

Что сделали

  • Свет и поляризация: заменили направленные прожекторы на диффузный купольный/низкоугловой свет под ~45°; поставили линейные поляризаторы на источник и анализатор на объектив под 90° (подавление бликов до ~15–20 dB). Перешли на узкополосные LED 625–660 нм.

  • Экспозиция и синхронизация: включили строб с импульсом 30–50 мкс под триггер энкодера; глобальный затвор, постоянный токовый драйвер без 50/60 Гц мерцания. Отключили автоэкспозицию/автогейн/автобаланс; гамма = 1.0, фиксированный gain.

  • Экраны и окклюзии: установили матовые чёрные экраны по бортам и над камерой, убрали паразитные отражения от рам и кромок.

  • Онлайн-мониторинг яркости: ввели контроль доли насыщенных пикселей (P255) и динамического диапазона; кадры с P255 > 0.5% автоматически помечаются и не идут в инференс; гистограммы логируются.

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

Сюрприз №2: Камера не дружит с резкостью

Проблема: микровибрации и автофокус

Камера стояла над станком, всё казалось стабильным. Но каждые 30–40 секунд появлялась дрожь, тонкие дефекты «смазывались». Причина — микровибрации от привода/роликов (≈25–35 Гц) и отсутствие автофокуса при фиксированном рабочем расстоянии.

Как мы внедряли CV на заводе — и выживали

Что сделали

  • Механика/крепёж: вынесли камеру на жёсткий кронштейн с виброизоляторами (fₙ ≈ 9–12 Гц, демпферы Shore A 30–40), отвязали от корпуса станка, добавили массу и развязку кабелей. Резонансные пики выше 60 Гц подавлены, передача вибраций < 0.3.

  • Фокус: настроили фикс‑фокус на рабочее расстояние по slanted‑edge (MTF50 вырос с ~0.28 до ~0.36 cyc/px), зафиксировали кольцо (lock‑screw) и метки положения; регламент пересмотра при смене температуры/света.

  • Экспозиция: привязали экспозицию к стробу 30–50 мкс — при 2 м/с смаз ≤ 0.1 мм.

  • IMU‑контроль: поставили 6DoF‑датчик (1 кГц); логируем события при |ω|RMS > 0.8°/с или Δугла > 0.05° за 200 мс; при срабатывании помечаем кадры и уведомляем оператора.

  • Онлайн‑метрика резкости: Tenengrad/Laplacian в ROI; кадры ниже τ исключаются из инференса или запрашивается повтор.

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

Сюрприз №3: один тайл — два дефекта и половина чужого листа

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

Что сделали

  • Маркеры и привязка к движению: наклеили ретрорефлективные метки по краям ленты; считывание в NIR (850 нм) с аппаратным триггером от энкодера (5k PPR). Детектируем leading edge и боковые кромки; дрожание меток < 0.5 мм.

  • Лидар + фотодатчики: ToF-лидар 1 кГц для контроля lateral offset, три фотошторки по ширине для детекта перекрытия/наличия листа. События уходят в PLC и в CV-пайплайн; допуск смещения ±3 мм, время реакции < 5 мс.

  • Динамический тайлинг и дескью:

    • грубая сегментация листа: Sobel/Canny → вероятностный Hough → RANSAC-линии кромок;

    • вычисляем гомографию и выполняем deskew; сетка тайлов якорится к кромке, а не к «сырому» кадру;

    • при перекрытии строим маску «серой зоны» вдоль шва (15–25 px): увеличиваем overlap, нежёстко понижаем вес предсказаний в NMS, логику объединения делаем по sheet_id;

    • если уверенность кромки < τ, включаем fallback: двойной overlap + предупреждение оператору.

  • Слежение за листом: sheet_id по импульсам энкодера; пересборка карты дефектов в координатах линии, чтобы MES получал стабильные ROI.

Вывод: физическое позиционирование нужно дублировать алгоритмами CV. У «железа» иногда свои планы, поэтому привязка к энкодеру, маркеры, лидар и дескью — обязательны для стабильного тайлинга и корректной агрегации предсказаний.

Сюрприз №4: Модель любит однотипные дефекты, а у нас каждый раз сюрприз

Проблема: разнообразие артефактов

Обучались на 15 классах дефектов. В проде всплыли неожиданные: пятна клея, отпечатки перчаток, стружка, насекомые, следы чистки и др. За первый месяц зафиксировали 37 новых типов, отсутствовавших в трейне.

Как мы внедряли CV на заводе — и выживали

Что сделали

  • Активное выявление «неизвестных» (OOD): отправляем в разметку тайлы при низкой уверенности (conf < τ), высокой энтропии, а также при расхождении ансамбля и классического CV; дополнили energy-score по логитам и расстоянием Махаланобиса в признаковом пространстве.

  • Еженедельная разметка и инкрементальное обучение: выгружаем 8–12k «неопознанных» тайлов/нед. в LabelStudio (κ ≥ 0.82), дообучаем с rehearsal (30% старых данных), частично замораживаем backbone, применяем дистилляцию знаний и калибровку температурой.

  • Гибридная схема CV + эвристики:

    • насекомые — временной фильтр (median-of-3 + оптический поток), отбрасываем движущиеся артефакты;

    • клей — NIR/поляризация, порог по отношению каналов (NIR/R) и по спектру блика;

    • отпечатки перчаток — частотные признаки (Габоры/FFT «гребёнки»);

    • стружка — вытянутость/эксцентриситет (elongation > 6), тонкие высококонтрастные компоненты.

  • Управление таксономией: «прочее/ nuisance» как буферный класс; промоутим в полноценный класс при ≥200 размеченных примеров и precision ≥ 0.7 на валидации. Зоны с низкой уверенностью помечаем в UI для ручной проверки.

Вывод: CV — это не «обучил и забыл», а непрерывный цикл. Активный OOD-поток, регулярная разметка и инкрементальное обучение с гибридными эвристиками дают управляемость при появлении новых артефактов без деградации по базовым дефектам.

Сюрприз №5: API-интеграция с MES — это уже не про CV, но боль

Проблема: древняя MES-система

Документации нет. REST/GraphQL нет. Только XML-файлы по FTP, которые MES опрашивает раз в несколько секунд. Частые проблемы: частичные чтения, дубликаты, «зависшие» файлы, непредсказуемые задержки.

Что сделали

  • Прокси-адаптер JSON→XML + надёжная файловая шина

    • CV выдаёт JSON с sheet_id, ts, speed, списком дефектов (bbox в мм, класс, уверенность).

    • Адаптер формирует XML по согласованной схеме, пишет атомарно: сначала в outbox/*.xml.part, затем rename в *.xml; после чтения MES кладёт *.ack.

    • Каталоги: outbox/ → processing/ → done/, ошибки в error/ с ретраем (экспоненциальная задержка, максимум 5 попыток), дедуп по sheet_id.

    • Кодировка UTF‑8 (без BOM), CRLF по требованию MES. Имя файла: INS_L1_20250912T101532Z_123456.xml.

  • Мониторинг и SLA для FTP-интеграции

    • Тайм-аут чтения: если через 30 с нет *.ack — алерт (Prometheus/Alertmanager → Teams/Slack), автоперекладка файла в processing/ не повторяется до разборки инцидента.

    • Метрики: end-to-end задержка (CV→MES), число «подвисших» файлов, ретраи, доля дубликатов, размер очереди. Трассировка по sheet_id.

    • Безопасность: при возможности SFTP; иначе FTPS (TLS), учётка с минимальными правами и chroot.

  • Переход на OPC UA через 2 месяца

    • Клиентский режим: сессия к серверу MES, SecurityMode=SignAndEncrypt, Policy=Basic256Sha256, keepalive 10 с, автопереподключение.

    • Узлы: ns=2;s=estralin/Sheet/{sheet_id}/Result, .../Defects (массив структур с bbox в мм и классом). Семплирование 100–200 мс, очередь 128, подтверждение обработкой статуса.

    • Фолбэк: при недоступности OPC UA — автоматический возврат на файловую шину, чтобы не терять данные

Вывод: интеграции — это отдельный проект. Согласуйте протоколы/схемы и SLA с IT-заказчика до старта, закладывайте атомарность, дедуп, мониторинг и фолбэк-канал; при возможности переходите на OPC UA с шифрованием.

Технологии и стек

  • Камера: Basler ace2 (GigE, mono, global shutter, 5 MP @ 60 fps), C‑mount фикс-объектив 12 мм (F/4), FOV ≈ 600 мм, масштаб ≈ 0.20 мм/пкс. Аппаратный триггер от энкодера 5k PPR, экспозиция 30–50 мкс, строб узкополосного LED 630 нм с перекрёстной поляризацией; гамма 1.0, фиксированный gain.

  • Модели: YOLOv5m (тайлы 1024×1024, overlap 20%), препроцессинг OpenCV (deskew по Sobel/Hough, CLAHE, маска бликов). Инференс ONNX Runtime CUDA/FP16; p50 7.8 мс/тайл, p95 11.2 мс/тайл (RTX A2000). Итог по листу p95 < 90 мс при 2 м/с. Качество: mAP50 0.96, F1 0.91, FPR 3.1% на холдауте.

  • Разметка: LabelStudio, экспорт COCO/YOLO; двойная валидация, κ=0.84; гайдлайны по классам/границам; класс «nuisance/прочее» для OOD до промоушена.

  • Интеграция: Python FastAPI (/infer, /healthz) → JSON; адаптер JSON→XML с атомарным rename и *.ack для legacy-FTP; основная шина — OPC UA (SecurityMode=SignAndEncrypt, Basic256Sha256), узлы ns=2;s=estralin/Sheet/{id}/Defects. Фолбэк на файловый канал.

  • Мониторинг: Prometheus + Grafana. Метрики: p95/p99 инференса, очередь, GPU util/mem, доля клиппинга (P255), FPR/recall по сменам, OOD rate, задержка CV→MES/OPC. Алерты по таймаутам ACK (>30 с), росту FPR, падению FPS/энкодера.

  • Деплой: On‑prem, Docker (Compose), NVIDIA Container Toolkit, закрепление версий драйверов/библиотек, healthchecks, автоперезапуск, локальный inference (latency‑critical), офлайн‑буферизация результатов и ретраи.

Финальные цифры

Хотелось показать таблицей, поэтому просто скриншот

Хотелось показать таблицей, поэтому просто скриншот

Что мы поняли

Оглядываясь назад, понимаем: часть проблем мы могли предсказать. Вот несколько инсайтов, которые пригодятся тем, кто только собирается внедрять CV на производстве.

Как мы внедряли CV на заводе — и выживали

Не верить в «идеальные данные»

  • Пыль/блики/вибрации — норма. Введите авто‑контроль качества кадров: P255 ≤ 0.5%, средняя яркость в окне [90;160], резкость (Tenengrad) > τ, доля «горячих» пикселей ≤ 0.05%.

  • Мониторьте дрейф окружения: деградация света (−5…−8%/мес), смещение экспозиции, рост шума; алерты и напоминания на очистку оптики каждые 8 ч или при падении SNR < 24 dB.

  • Реплицируйте «грязную реальность» в данных: еженедельно добавляйте 5–10% свежих OOD‑тайлов, аугментации под бликами/смазом/пылью; калибровка порогов раз в смену.


    Закладывать бюджет на «внезапности»

  • Резерв времени: +20–30% к срокам на интеграции/железо; бюджет: +10–15% на запасные части (камеры, БП, драйверы света, кабели).

  • Операционные SLO: p95 инференса < 100 мс/тайл, p95 CV→MES < 1.2 с, потери данных 0, дедуп по sheet_id, MTTR инцидента интеграции ≤ 15 мин.

  • Дежурство и плейбуки: on‑call 24/7 для линии, сценарии на «камера/энкодер/свет/OPC/FTP упал», фолбэк на файловую шину, офлайн‑буфер ≥ 24 ч.


    Общаться с технарями на месте

  • Совместно с цехом: выбор света/крепежа/экранирования, допустимые окна простоя, точки триггера от энкодера, маршруты кабелей, HSE‑требования.

  • Протоколировать фактические допуски: биение ленты, скорость, виброфон (целевой < 0.2 g), реальные ограничения на экспозицию/строб.

  • Формализовать SAT/UAT: чек‑листы по классам дефектов, выборки на 1–2 смены, критерии приёмки (precision/recall/FPR), график регламентных чисток и перекалибровок.

Напоследок

Компьютерное зрение в промышленности — меньше про «красоту модели» и больше про свет, крепёж, синхронизацию и протоколы. Если идёте в прод, готовьтесь к реальному миру — тому, где рядом со Stack Overflow открыта вкладка «как дернуть автофокус через Modbus» и список запасных кабелей на складе.

Показать полностью 6
Отличная работа, все прочитано!

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества