Как стать автором
Обновить

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

Уровень сложностиСредний
Время на прочтение6 мин
Количество просмотров4.9K

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


Риск быть задавленным: как мы начали

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

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

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

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

Как мы решили проблему

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

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

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

Для реализации задачи мы использовали модифицированную и дообученную версию YOLO. Этот алгоритм хорошо зарекомендовал себя в задачах детекции объектов в реальном времени. Именно на YOLO мы начали закладывать базис Системы, которая будет учитывать:

  • Нестандартные сценарии (специфические коробки в кадре, погодные аномалии)

  • Технические ограничения оборудования заказчика

  • Допустимый уровень ложных срабатываний (не более 10% по согласованию)

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

Проблемы и решения

Каждый проект имеет свои подводные камни, и этот не стал исключением. Вот основные трудности, с которыми мы столкнулись, и как их преодолели.

1. Доступы: первый круг ада

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

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

  • Программы для работы с токеном поддерживали только Windows, а у большинства разработчиков были Linux или MacOS.

  • Токен был физическим, а команда находилась в разных регионах.

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

2. Бюрократия: второй круг ада

Для продолжения работ нам нужно было:

  • Открыть порты.

  • Получить доступ по SSH и VNC.

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

3. Непонимание возможностей нейросетей

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

Например, требования часто противоречили друг другу, и нам приходилось тратить время на их согласование.

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

  •  Визуализировать архитектуру системы в PowerPoint

  •  Проводить ликбезы по основам CV

  •  Переводить технические требования на язык бизнес-процессов

Масштаб проблемы был настолько большой, что мы прямо способствовали созданию Центра компетенций на стороне заказчика. На сегодняшний день у них есть свой ML-отдел, который ставит нам задачи. Инвестировали в промышленность страны! 

4. Ложные срабатывания

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

5.Кадровый "марафон"

За 2.5 года реализации проекта:

  • 3 смены руководителей проектов на нашей стороне

  • Частичная смена контактных лиц у заказчика

  • Появление Центра компетенций со стороны Заказчика

Результат: Сбор требований превратился в многоуровневый квест с постоянными переигрываниями условий.


Итоги проекта в цифрах

Параметр

Требование

Результат

TPR

≥90%

93%

FPR

≤10%

5%

Тестирование: 1000 кадров + 6 месяцев промышленной эксплуатации

Для оценки работы системы мы использовали следующие метрики:

  • TPR (истинно-положительное определение аварийной ситуации) — не менее 90%.

  • FPR (ложноположительное определение) — не более 10%.

Наш результат:

  • TPR (True Positive Rate) = 0.93

  • FPR (False Positive Rate) = 0.05

Тестирование проводилось на 1000 кадрах.

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

  • Времени суток (4 категории: утро/день/вечер/ночь)

  • Погодным условиям (сухо/дождь/туман)

  • Типам препятствий (7 классов включая динамические объекты).

Специальные случаи (34 кадра) содержали артефакты вроде 2-метровых вёдер или баннеров — их использовали для калибровки устойчивости модели. Проверка проводилась через трёхэтапную валидацию с перекрёстным контролем аннотаций.

Также мы подключились к объекту в реальном времени и провели тесты непосредственно в условиях рабочей зоны, где организовали интерактивные сценарии и смотрели по детекциям как отрабатывает система. Провели тесты во всех сменах (утро, день, вечер, ночь), чтобы охватить разные уровни освещения и загруженности. Практическая проверка дала результаты — зафиксировали снижение конфликтных ситуаций между людьми и техникой на 10% уже в первые сутки тестов.

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

Итоги проекта в опыте

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

Несмотря на:

  • Осознанное решение заказчика не предоставлять статистику по предотвращенным авариям (по требованию HR-департамента)

  • 18-месячную отложенность платежей

  • Несовершенство оборудования на объекте 

Система доказала жизнеспособность концепции — сейчас её масштабируют на более чем 100+ объектах компании заказчика.

Заключение

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

Если вы хотите узнать, как нейросети могут улучшить безопасность и производительность на вашем предприятии, запросите кейс-стади по адресу r.fedorov@neuro-core.ru .

Теги:
Хабы:
Всего голосов 14: ↑6 и ↓80
Комментарии29

Публикации

Работа

Ближайшие события