Компьютерное зрение в продакшене: пошаговый кейс внедрения от POC до production

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

Шаг 0: Постановка бизнес-задачи и оценка осуществимости. Запрос от производства: автоматизировать визуальный контроль качества сварных швов. Человек-оператор устает, субъективен, пропускает мелкие дефекты. Цель: снизить процент брака на 15% в течение года. Первым делом аналитики и ML-инженеры провели аудит данных: существуют ли размеченные изображения дефектов? Оказалось, что есть архив фото с маркировкой «брак»/«норма», но без точной локализации дефектов. Был оценен бюджет на разметку и необходимые вычислительные ресурсы. Критическим фактором стало освещение и стабильность положения деталей на конвейере — без решения этих инфраструктурных вопросов любая модель была бы бесполезна.

Шаг 1: Сбор данных и инфраструктурная подготовка. Прежде чем писать код модели, команда занялась «железом». Были установлены промышленные камеры с постоянным, защищенным от бликов освещением. Разработано простое крепление для стабильной съемки. Для сбора данных запустили конвейер в тестовом режиме, собирая изображения как штатных, так и специально внесенных дефектных изделий. Важный лайфхак: параллельно со сбором сырых данных сразу начали разрабатывать конвейер их предобработки (автоматическая обрезка, нормализация освещенности, аугментация), упаковывая его в Docker-контейнер. Это заложило основу для будущего MLOps.

Шаг 2: Разработка и валидация прототипа (POC). Имея набор в несколько тысяч размеченных изображений, команда приступила к моделированию. Вместо того чтобы сходу тренировать тяжелую нейросеть с нуля, выбрали стратегию трансферного обучения на основе предобученной модели EfficientDet для детекции объектов. POC преследовал четкую цель: доказать, что точность (mAP) модели превышает порог в 85% на отложенной тестовой выборке и работает быстрее, чем 100 мс на выбранной инференс-железке (NVIDIA Jetson). Достижение этих метрик стало формальным критерием для перехода к следующей фазе.

Шаг 3: Проектирование production-архитектуры. POC-модель — это скрипт на ноутбуке. Продакшен-система — это отказоустойчивый сервис. Архитектура была спроектирована как микросервис на Python (FastAPI), который получает изображение с камеры через брокер сообщений (Apache Kafka), выполняет инференс, возвращает результат (координаты дефекта, класс, уверенность) и сохраняет его вместе с метаданными в базу (PostgreSQL). Отдельно был создан сервис для переобучения модели на новых данных. Ключевое решение: использование Triton Inference Server для эффективного обслуживания модели, что дало возможность версионирования моделей и батчинга запросов.

Шаг 4: Развертывание и мониторинг. Модель и все сервисы были упакованы в Docker-контейнеры и развернуты в Kubernetes-кластере на edge-устройстве (Jetson) прямо в цеху. Внедрение CI/CD пайплайна для ML (с использованием GitLab CI и DVC) позволило автоматически переобучать и переразвертывать модель при поступлении новых размеченных данных. Была внедрена система мониторинга, отслеживающая не только технические метрики (задержка, загрузка GPU), но и дрейф данных (Data Drift): статистика распределения входных пикселей сравнивалась с распределением во время обучения. Резкое изменение могло сигнализировать о поломке освещения или смене материала.

Шаг 5: Интеграция с бизнес-процессом и итеративное улучшение. Самый важный этап. Система не работала в вакууме. Результаты детекции в реальном времени передавались в SCADA-систему цеха. При обнаружении критического дефекта конвейер автоматически останавливался. Для оператора был создан простой веб-интерфейс с возможностью проверить спорные случаи (low confidence predictions) и скорректировать разметку. Эти коррекции автоматически попадали в тренировочный набор. Таким образом, система начала самообучаться в процессе эксплуатации. Через 3 месяца после запуска был достигнут целевой показатель — снижение брака на 18%.

Ключевые выводы и lessons learned. Во-первых, успех на 50% зависит от качества и стабильности входных данных, что решается инфраструктурными инвестициями. Во-вторых, production-решение — это в первую очередь надежная и наблюдаемая программная система, а потом уже ML-модель. В-третьих, необходимо с первого дня закладывать механизм обратной связи от пользователей (операторов) для постоянного улучшения модели. Наконец, важно считать TCO (Total Cost of Ownership): затраты на edge-железо, электроэнергию и обслуживание не должны превышать экономию от снижения брака.

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