Почему производителю машин мало «поставить ИИ»

Итальянская Rayonics International проектирует и выпускает машины для контроля качества пищевой продукции, в том числе решения с рентгеновской инспекцией. У малого производителя есть сразу несколько возможных направлений для ИИ: следить за корректной работой установленного оборудования, анализировать накопленные данные машин, заранее замечать признаки неисправности. Перечень звучит убедительно, но проекты с разными данными и рисками нельзя складывать в одну закупку «платформы искусственного интеллекта».

Разбор хаба EXPAND описывает работу с Rayonics в 2024–2025 годах. Компания получила обучение сотрудников, исследование осуществимости и технологическую дорожную карту. Один прикладной результат — созданная edge-модель для мониторинга корректной работы установленной инспекционной машины. На дату описания она была готова к полевому испытанию. Это не сообщение о подтверждённой работе на всех объектах клиентов, сокращении брака или экономии сервисных выездов: таких показателей источник не публикует.

Что именно было сделано

Проект разделил неопределённость на несколько частей. Сотрудники прошли основы ИИ, разработчики — практический курс Python; параллельно специалисты оценили данные, которые можно собирать с установленных машин для будущего предиктивного обслуживания. Отдельно изучили возможность анализа качества с моделью на edge-уровне — то есть рядом с оборудованием. В конце был составлен план внедрения с возможными направлениями развития продукта.

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

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

Где нужен локальный контур

Edge-подход имеет смысл, когда решение должно появляться около линии, доступ в сеть непостоянен или передавать сырые производственные данные наружу нежелательно. Это не делает локальную модель автоматически безопасной и дешёвой. На площадке всё равно нужны питание, совместимый вычислитель, контроль версий модели, защищённое обновление и журнал решения. Если модель только советует технику, можно начать в режиме наблюдения; если она остановит линию или изменит параметры оборудования, требования к испытаниям и ручному подтверждению заметно выше.

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

Чем проверять модель в поле

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

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

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

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

Экономика: стоимость результата, а не демо

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

Модельный расчёт, не результат Rayonics: допустим, десять машин требуют по одному внеплановому сервисному разбору в месяц, каждый обходится в 6 000 рублей с учётом работы и простоя. Потенциальный месячный резерв — 60 000 рублей. Если модель предотвращает лишь четверть таких случаев, валовый эффект составит 15 000 рублей до затрат на разработку, оборудование и поддержки. При цене сопровождения выше этого значения проект не окупается только за счёт выездов; возможно, его нужно обосновывать снижением брака или отказов, но такие выгоды следует измерить отдельно. Все числа здесь — допущения для демонстрации метода, а не показатели компании.

Следующий шаг без дорогого эксперимента

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

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