Попытка нанять персональную команду дата-сайентистов под каждый производственный агрегат — проверенный способ сжечь бюджет и гарантированно сорвать сроки внедрения. В тяжелой промышленности задач для машинного обучения хватает на каждом переделе: от стабилизации технологических режимов до сокращения сырьевых потерь. Однако масштабировать заказную разработку на десятки геораспределенных площадок силами штучных специалистов невозможно физически. Руководитель отдела машинного обучения в департаменте технологий искусственного интеллекта РУСАЛа Андрей Писарев описал прагматичный выход из кадрового тупика: вместо кастомных проектов под каждый завод запускается конвейер типовых модулей.
Конвейер вместо штучной разработки
Когда предприятий десятки по всему миру, а профильных специалистов в штате единицы, классическая заказная разработка неизбежно терпит крах. Единственный способ охватить объекты без раздувания ФОТ — перевести создание ML-сервисов на стандартизированную платформенную основу. В РУСАЛе этот процесс выстроили на базе фреймворка SinaraML и собственной on-premise инфраструктуры, которая включает вычислительные мощности на графических процессорах NVIDIA A100 и распределенное хранилище Apache Ozone объемом около 0,5 Пбайт (по данным И.В. Казарина из РУСАЛа за 2025 год).
Жизненный цикл продукта начинается не с написания кода, а с жесткого распределения зон ответственности между четырьмя ключевыми ролями: технологом агрегата, бизнес-аналитиком, дата-сайентистом и техлидом. Требования фиксируют в едином документе готовности к разработке (Definition of Ready, DoR). Это позволяет на старте отсечь нереализуемые запросы цехов и трезво оценить состояние датчиков на месте.
«Если бы для каждого объекта мы строили ML-продукт с нуля, мы бы не вывезли».
После утверждения DoR роли в проекте четко разделяются. Разработчики готовят интеграции с брокером сообщений Kafka, локальные базы данных и интерфейсы, ML-инженеры распределяют ресурсы платформы, а дата-сайентисты отвечают за данные, фичи и сам стандартизированный сервис. Руководитель проекта параллельно упаковывает бизнес-требования и техническое задание, не отвлекая инженерную команду от архитектуры.
Автономия на площадке и единый контроль
Создаваемый алгоритм оформляется как типовой артефакт Model Service с версионированием, происхождением данных (data lineage) и упаковкой через инструмент BentoML с REST API. Чтобы защитить решение от деградации качества прогнозов, модуль сразу подключается к системе мониторинга дрейфа данных (Model Monitoring). Без этой инженерной обвязки любая модель превращается в тыкву сразу после увольнения ее автора.
Архитектура решения строится по принципу локальной автономности: на конкретном заводе разворачиваются собственное хранилище, локальный Model Service и рабочий интерфейс оператора. Связь с центральной платформой в Москве, где сосредоточены долгосрочное хранилище (Long-term Storage) и центральный мониторинг, поддерживается через корпоративную шину данных (КШД). Если сетевое соединение с центром обрывается, локальный сервис продолжает управлять агрегатом, а накопленная телеметрия уходит в Москву позже, после восстановления канала связи.
Готовый сценарий масштабируется на родственные участки без переписывания кодовой базы. Алгоритм для 150-метровой печи спекания нефелина на Пикалевском глиноземном заводе (ПГЛЗ) потребовал лишь минимальной калибровки порогов и фичей, после чего его подготовили к тиражированию на остальные пять аналогичных печей площадки.
Кейс ПГЛЗ демонстрирует реальную экономику промышленного ML: переход от проверки концепции (PoC) до закрытого тестирования модели CatBoost (MAE = 225, R² = 0.48, RMSE = 330) занял 3 месяца, а ожидаемый экономический эффект исчисляется десятками миллионов рублей в год. Для топ-менеджмента это наглядный урок: масштабирование ИИ в индустрии упирается не в бесконечный найм дата-сайентистов, а в дисциплину платформенных стандартов и модульную архитектуру.