Привет, Хабр!

Меня зовут Писарев Андрей, я руковожу отделом машинного обучения в департаменте технологий искусственного интеллекта. Мы с командой разрабатываем и внедряем ML-решения на производственных площадках компании различной направленности.

РУСАЛ – геораспределённая компания: десятки производственных площадок по всему миру. А дата-сайентистов в команде – единицы. Если бы для каждого объекта мы строили ML-продукт с нуля, мы бы не вывезли. Поэтому главный фокус этой статьи – не модель и не метрики, а типовой подход к разработке ИИ-продуктов, который позволяет одной командой закрывать много объектов. Печь спекания на Пикалевском глинозёмном заводе (ПГЛЗ) – это кейс, на котором я покажу, как подход работает вживую.

TL;DR: В РУСАЛе десятки предприятий по миру, а дата-сайентистов – единицы. Решение – системный подход к ML-продуктам на базе SinaraML и корпоративной ИИ-платформы. Показываю, как подход работает на конкретном кейсе – ML-сервис для управления 150-метровой печью спекания на ПГЛЗ. 3 месяца от PoC до закрытого тестирования. CatBoost: MAE = 225, R² = 0.48, RMSE = 330. Ожидаемый порядок экономического эффекта – десятки миллионов рублей в год.

• Проблема и подход

• Контекст: что за агрегат и где он стоит

• Бизнес-проблема

• DoR: приземление бизнес-хотелок завода

• PoC: проверка гипотезы

• Разработка MVP по типовому подходу

• Результаты и текущий статус

• Lessons learned

• Вопросы к сообществу

Проблема и подход

В компании десятки производственных площадок по миру, и почти на каждой есть задачи, где ML мог бы дать эффект: стабилизация процессов, снижение потерь, оптимизация режимов. А дата-сайентистов – единицы. Если бы для каждого объекта мы строили продукт с нуля (своя команда, своя инфраструктура, свой код), мы бы физически не вывезли даже десятой части желаемых проектов.

Решение – системный подход к разработке ML-продуктов на базе SinaraML Framework [definitive guide] и корпоративной ИИ-платформы РУСАЛа. Корпоративная платформа – это продвинутая версия SinaraML, развёрнутая on-premise: управление окружениями, версионирование пайплайнов, данных и экспериментов, вычислительное облако на GPU NVIDIA A100, облако хранения Apache Ozone объёмом около 0,5 Пбайт [Казарин И.В., РУСАЛ, 2025]. SinaraML – набор практик по организации разработки и эксплуатации ML-моделей в не-IT компаниях, где ресурсов и компетенций всегда меньше, чем в чистом IT.

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

Принцип 1. Согласование предметных областей через DoR: технолог + аналитик + DS + техлид. Промышленный ML требует перевода между языком процесса, языком бизнеса и языком реализации. Технолог знает процесс, но не формализует. DS формализует, но не знает процесс. Бизнес-аналитик переводит процесс и бизнес в требования. Техлид оценивает реализуемость: доступны ли данные, можно ли реализовать продукт на железе площадок, какие нужны бэк, фронт, интеграции. Эта четвёрка собирается на старте и заполняет Definition of Ready (DoR) – артефакт, который приземляет бизнес-хотелки завода и определяет готовность команды DS к работе.

Принцип 2. Типизация и унификация подхода к разработке ML-продукта. Любой новый ML-продукт начинается не с нуля, а с типовой архитектуры. Типовая архитектура – это то, от чего мы отталкиваемся в начале любого проекта и к чему стремимся; при общении с техлидом могут быть изменения. На берегу согласовывается датафлоу и фиксируется контракт Model Service ↔ бэкенд.

Принцип 3. Чёткое разделение ролей. Дев-команда – продюсер из источника данных в Kafka, консьюмер из Kafka в продукт, локальное хранилище, бэкенд, фронтенд. ML-инженеры – отвечают за платформу, выделяют ресурсы под новый проект. DS – данные, фичи, модель, Model Service и Model Monitoring. Руководитель проекта параллельно делает БТ и ТЗ – независимо от разработчиков.

Принцип 4. Типизация разработки Model Service. DS делает не «модель», а Model Service – стандартизованный артефакт, который проходит через типовой ML Pipeline с версионированием и data lineage, упаковывается через BentoML с REST API, подхватывается Model Monitoring для ловли дрейфа. Без Pipeline и Monitoring модель не переживает автора.

Принцип 5. Децентрализованная эксплуатация, централизованный контроль. Продукт работает автономно на производственной площадке: локальное хранилище, локальный Model Service, локальный UI оператора. Платформа – централизована: Long-term Storage и Model Monitoring в Москве. Связь – через корпоративную шину данных (КШД). Если связь с центром пропадёт, продукт продолжает работать; накопленные данные уходят позже.

Принцип 6. Масштабирование через типовые сценарии. Типизация – не только на уровне компонента, но и на уровне сценария. Один и тот же типовой сценарий (печь спекания нефелина) воспроизводится на N объектах с минимальной адаптацией (модель, фичи, пороги). На ПГЛЗ шесть однотипных печей спекания – то, что сделано для одной печи, тиражируется на остальные пять.

Дальше – кейс ПГЛЗ. Покажу, как эти шесть принципов легли на реальный объект.

Контекст: что за агрегат и где он стоит

ПГЛЗ – это завод, на котором есть цех спекания с шестью печами спекания нефелина. Печь спекания – вращающийся барабан длиной 150-170 метров. В него загружают нефелиновую шихту – смесь нефелинового концентрата (продукта обогащения апатит-нефелиновых руд Кольского полуострова) с известняком, а на выходе получают глинозёмный спек – сырьё для следующего передела, выщелачивания, где из него выделяют глинозём.

Глинозём (Al₂O₃) – ключевой продукт для производства алюминия: из него на электролизных заводах получают алюминий. Без глинозёма нет алюминия, поэтому стабильность его производства критична для всей цепочки.

Способ спекания нефелина для производства глинозёма в России применяется всего на двух заводах – Ачинском и Пикалевском. Большая часть мирового глинозёма производится из бокситов по способу Байера; спекание нефелина – советская разработка комплексной переработки сырья, не имеющая аналогов в мировой практике [Логинова И.В., Кырчиков А.В. Производство глинозёма. УрФУ, 2020]. ПГЛЗ – одна из двух российских площадок, где этот способ работает.

Процесс спекания нефелиновой шихты идёт при температуре 1250-1350 °C – это не плавка, а твердофазное спекание: материал должен пройти химические реакции, не превратившись в монолитный расплав. Упрощённо основная реакция выглядит так:

(Na, K)₂O·Al₂O₃·2SiO₂ + 4CaO → (Na, K)₂O·Al₂O₃ + 2(2CaO·SiO₂)

Слева – нефелин с известняком, справа – алюминат натрия/калия (полезная фаза, из которой потом извлекается глинозём) и двухкальциевый силикат (балластная фаза – отход производства, который идёт в шламохранилище). Цель процесса – получить максимальный выход полезной фазы.

Качество спека определяет эффективность следующего передела – выщелачивания. Оценивается оно по фазовому составу – числу от 0 до 1, которое характеризует качество спека с точки зрения его пригодности для выщелачивания. На практике для оператора это основной ориентир: чем ближе к 0.55, тем эффективнее работает следующий передел. На печи уже установлен «сенсор» – CV-модель (компьютерное зрение), которая по изображению спека оценивает его фазовый состав в реальном времени. Эту модель разработала и поддерживает отдельная команда; мы получаем от неё предикты как готовый поток данных.

Идеальный фазовый состав – около 0.55 (целевой интервал 0.50-0.60). Если спек «крепкий» (пережог, >0.60) – на выщелачивании часть глинозёма не извлекается и теряется со шламом. Если «слабый» (недожог, <0.50) – спек не до конца прошёл реакцию, тоже теряем глинозём. И то, и другое – прямые потери.

Управляет процессом агломератчик (оператор у пульта). Основной рычаг управления – обороты питателей пыли. Пыль, уловленная из отходящих газов печи, возвращается через питатели в факел горения, где работает как дополнительный теплоноситель. Физика процесса: выше обороты – сильнее дует, больше теплоносителя разносится по печи, температура размазывается – печь остывает. Ниже обороты – пыль концентрируется в районе факела, локальный нагрев – печь нагревается сильнее. Меняя обороты, оператор плавно управляет тепловым режимом зоны спекания без резких скачков.

Лабораторный анализ фазового состава делается редко и долго – для оперативного управления не подходит. Поэтому агломератчик ориентируется на показатели автоматизированной системы управления технологическим процессом (АСУТП) – температуры в зонах, расходы, давления и тому подобное, – предсказания CV-модели и визуальную оценку. Визуальная оценка – это не только цвет и структура спека на изображении, но и личный обход: агломератчик подходит к торцевой части печи и через специальное окошко наблюдает за процессом внутри.

Важная деталь для дальнейшего: на ПГЛЗ шесть однотипных печей спекания. То, что мы делаем для одной печи, в перспективе должно тиражироваться на остальные пять – без переписывания архитектуры.

Бизнес-проблема

На первый взгляд, всё работает: агломератчик у пульта, печь крутится, спек получается. Проблема в другом – разные смены работают по-разному. На одно и то же состояние печи разные агломератчики реагируют по-разному: один «гасит» обороты, другой «разгоняет», третий держит нейтралитет. Личные привычки, опыт, настроение, усталость – всё это входит в управление 150-метровой печью.

Отсюда две беды: - Нестабильность процесса. От смены к смене фазовый состав гуляет, выход глинозёма колеблется. - Зависимость от конкретных людей. Уйдёт опытный оператор – качество упадёт, пока новички не набьют руку.

Бизнес хочет устранить разброс между сменами и получить стабильный средний результат, не зависящий от того, кто стоит за пультом. Важно: речь не о замене оператора – агломератчик остаётся лицом, принимающим решение. Речь о советчике, который подсказывает «среднее» действие, согласованное с тем, как работает большинство опытных операторов. Это сознательный архитектурный выбор для промышленного объекта: модель не управляет процессом напрямую, она даёт рекомендацию; оператор принимает решение и несёт ответственность. Human-in-the-loop – не слабость, а требование безопасности.

DoR: приземление бизнес-хотелок завода

Стартовая точка любого ML-продукта в РУСАЛе – Definition of Ready (DoR). Это артефакт, который приземляет бизнес-хотелки завода и определяет готовность команды DS к работе. DoR – шаблон с блоками для описания ключевых элементов проекта и создаваемого продукта [Казарин И.В., РУСАЛ, 2025]:

1.          Регистрационная информация

2.          Основная проблема / целевая задача

3.          Ожидаемая ценность (эффект)

4.          Пользователи потенциального продукта

5.          Данные (источник / описание / ответственный)

DoR – это видение продукта, а не формальная спецификация. После принятия DoR команда DS идёт работать. Руководитель проекта параллельно делает бизнес-требования, техзадание и прочие документы – независимо от разработчиков. Если после принятия DoR требования к продукту меняются, оформляется запрос на изменение (ЗнИ) как приложение к DoR.

На основе DoR прорабатываются системные требования и проходят проверки гипотез. Концептуальный минимум формализации – ответы на три вопроса: Что? Зачем? Как?

В нашем кейсе на ПГЛЗ DoR финализирован под печь спекания: основная проблема – разброс между сменами, ожидаемая ценность – стабильный средний результат, пользователи – агломератчики, источники данных – АСУТП печи и предикты CV-модели. После финализации DoR стартовал PoC.

Принцип 1 в действии: четвёрка через DoR

DoR не заполняется одним человеком. На ПГЛЗ над ним работала четвёрка: технолог + бизнес-аналитик + DS + техлид.

•             Технолог – носитель экспертизы процесса. Знает, почему «печка не любит резких перепадов значений управляющего параметра», что такое «крепкий» и «слабый» спек на практике, какие действия операторов алогичны. Без технолога DoR – набор абстрактных хотелок.

•             Бизнес-аналитик – переводчик. Переводит язык процесса (технолог) и язык бизнеса (завод) в системные требования, которые DS и дев-команда могут понимать и проверять. Без аналитика либо модель решает не ту задачу, либо решает правильно, но непонятно для заказчика.

•             DS – отвечает за метрики, данные, техническую осуществимость модели. Определяет, какие данные нужны, какие метрики будут оценивать качество модели и продукта.

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

Четвёрка собирается на старте и работает до финализации DoR. После финализации DoR расходится по своим трекам, но остаётся точкой согласования при изменениях (через ЗнИ).

PoC: проверка гипотезы

PoC делается после финализации DoR, перед разработкой MVP. Цель PoC – проверить, что гипотеза из DoR вообще осуществима: на показаниях АСУТП и предиктах CV-модели возможно предсказывать изменение оборотов с приемлемой точностью. Один дата-сайентист, Jupyter-ноутбук, исторические данные за 6 месяцев.

Физика процесса и выбор подхода

У нас есть два пути построить модель: физико-химическая модель спекания или end-to-end ML на сырых данных. Физико-химическая модель – это моделирование кинетики реакций, тепломассопереноса, фазовых переходов в 150-метровой печи. Для промышленного предприятия такой путь слишком дорогой и долгий: разработка занимает годы, калибровка под конкретную печь – отдельный проект, а точности нужно не больше, чем у опытного оператора. End-to-end ML на показаниях АСУТП и предиктах CV-модели – быстрее и точности достаточно. Это сознательный выбор.

Факап с агрегацией CV-данных

Первое, с чем мы столкнулись – управляющие параметры (обороты питателей) практически не коррелировали с данными от CV-модели. Причина оказалась в том, что CV-данные, которые мы получили, были агрегированы до секундной дискретности, но вместо усреднения 20 кадров в секунду брался один кадр. Запросили сырые данные, провели агрегацию сами (усреднение по секунде) – корреляция появилась. Потеряли на это месяц. Вывод: всегда проверяйте, как именно агрегированы данные, которые вы получаете, – это не вопрос доверия к команде, а вопрос специфики вашей задачи.

Что выяснили по данным

После решения проблемы с агрегацией получилось, что окно истории в 60 минут достаточно для предсказания. Это эмпирическая величина, полученная по результатам PoC – могли бы взять и другой интервал, но час оказался рабочим. На вход модели подаётся история показаний АСУТП за последний час (с минутной дискретностью) и история предиктов CV-модели за последний час (исходно 20 кадров в секунду, агрегируется до секундной дискретности).

Модель

Для решения задачи выбрали CatBoost – градиентный бустинг на деревьях. Почему он: - Хорошо работает с табличными данными - Устойчив к выбросам (в промышленных данных их много) - Не требует масштабирования признаков - Интерпретируемость: feature importance позволяет объяснить оператору, какие именно параметры повлияли на рекомендацию. Для промышленного объекта это критично – оператор должен доверять модели, а доверие приходит через понимание, почему модель советует «повысить» или «понизить».

Модель смотрит на историю АСУТП и на историю CV-предиктов и рекомендует, на сколько изменить обороты, чтобы фаза вернулась в норму или не успела из неё выйти.

Метрики на тестовой выборке

Сравнивали три подхода:

Dummy – модель, которая всегда предсказывает среднее значение. Ridge – линейная регрессия с L2-регуляризацией.

CatBoost устойчиво превосходит оба базовых решения по всем трём метрикам. R² = 0.48 означает, что модель объясняет около половины вариации целевой переменной; MAE = 225 – средняя ошибка в оборотах; RMSE = 330 (больше MAE) говорит о том, что у модели есть редкие, но заметные промахи, что естественно для промышленных данных с выбросами.

Почему модель не рекомендует резких изменений

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

Почему такие метрики

R² = 0.48 – на первый взгляд немного, но для промышленной задачи это рабочий уровень. Причины:

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

•             Разные смены работают по-разному. В данных есть алогичные действия: на одно и то же состояние печи разные агломератчики реагируют по-разному. Модель это усредняет, что ограничивает потолок R².

•             Шум в данных с датчиков. Промышленные АСУТП дают зашумлённые показания, часть вариации физически не объяснима.

R² 0.4–0.6 – типичный диапазон для промышленных регрессионных ML-задач с обучением на действиях людей. Дальнейший рост метрики ожидается за счёт очистки обучающих данных от аномалий и расширения набора признаков.

Что означает «совпадение с оператором» – и чего не означает

Метрики модели на тестовой выборке показывают, что CatBoost научился воспроизводить устойчивый средний паттерн действий опытного оператора. Это метрика модели, не метрика продукта. Цель продукта – не «обыграть» оператора, а устранить разброс между сменами. Усреднённая модель убирает индивидуальное смещение каждого оператора и обеспечивает стабильный средний результат вне зависимости от того, кто конкретно стоит за пультом. Количественно это измеряется метриками продукта – удержание фазового состава в целевом интервале и снижение вариативности управления между сменами. Сейчас статистика копится, итоги будут отдельным постом.

Разработка MVP по типовому подходу

PoC подтвердил гипотезу. Дальше – разработка MVP по типовому подходу. Четыре принципа здесь работают вместе: типовая архитектура (Принцип 2), разделение ролей (Принцип 3), Model Service через Pipeline + Monitoring (Принцип 4), децентрализованная эксплуатация при централизованном контроле (Принцип 5).

Принцип 2: типовая архитектура + датафлоу + контракт

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

Что было на площадке до старта. Изначально на ПГЛЗ, кроме производственных систем, ничего ML-специфичного не было. В рамках развёртывания корпоративной шины данных (КШД) на площадке была подняла Kafka – корпоративный брокер сообщений Apache Kafka для передачи данных между промышленными площадками и корпоративным контуром [Казарин И.В., РУСАЛ, 2025]. От неё мы и отталкивались.

Датафлоу. Источники данных разные – на ПГЛЗ это АСУТП печи и CV-модель; на других площадках могут быть MES, SAP или иные корпоративные системы. Важно: дев-команда разбирается с источником данных, пишет продюсер, который забирает данные из источника, и кладёт в Kafka. Дальше DS забирает данные универсальным консьюмером из Kafka и начинает свою работу.

Ключевые компоненты типовой архитектуры:

•             Data Producer – продюсер, который собирает данные из источника (на ПГЛЗ – АСУТП печи) и кладёт в Kafka. Этот компонент – свой под каждый объект, потому что источники у разных объектов разные. Ответственность дев-команды.

•             Data Bus (Kafka) – корпоративная шина данных, переиспользуется. На ПГЛЗ мы подписались на топик с данными печи №1.

•             Консьюмер из Kafka в продукт – универсальный, читает поток данных из Kafka и складывает в локальное хранилище продукта. Ответственность дев-команды.

•             Локальное хранилище продукта (Main DB, PostgreSQL) – оперативная база на площадке для хранения текущего состояния, последних рекомендаций, истории взаимодействий оператора с системой. Ответственность дев-команды.

•             Long-term Storage – централизованное хранилище исторических данных, в Москве. Здесь лежит всё для переобучения модели и для Model Monitoring. Данные с ПГЛЗ текут сюда через Kafka. Ответственность ML-инженеров (платформа).

•             Model Service – микросервис с упакованной ML-моделью. Разворачивается на площадке. Принимает JSON с текущими показаниями и историей, возвращает рекомендацию в формате:

{
  "timestamp": "2025-07-24T14:32:00Z",
  "furnace_id": "PGLZ-1",
  "recommendation": {
    "sum_rpm_rec": 1250,
    "delta_rpm": 50
  }

•             Model Monitoring System – в Москве, читает X/Y/Y’ из Long-term Storage, считает дрейф. Ответственность DS. На ПГЛЗ мы только публикуем X/Y/Y’ в Kafka – дальше московский сервис всё считает сам.

•             UI (пользовательский интерфейс) – веб-интерфейс для оператора на площадке. Ответственность дев-команды (бэкенд + фронтенд).

Контракт Model Service ↔ бэкенд. На берегу фиксируется JSON-формат запроса и ответа между Model Service и бэкендом. Это единственная точка согласования между ML dev и Software dev. После фиксации контракта команды работают независимо – DS не пишет коннекторы, инженеры не лезут в модель. Контракт не меняется без согласования; если меняется – через ЗнИ к DoR.

Принцип 3: разделение ролей

На ПГЛЗ роли распределились так:

•             Дев-команда. Продюсер из источника (АСУТП) в Kafka, консьюмер из Kafka в продукт, локальное хранилище (Main DB), бэкенд, фронтенд UI.

•             ML-инженеры (платформа). Платформа – продвинутая корпоративная версия SinaraML – уже построена. Под новый проект ML-инженеры выделяют ресурсы на платформе: Long-term Storage, Kafka, вычислительные мощности. Не строят с нуля – выделяют.

•             DS. Данные, фичи, модель, Model Service, Model Monitoring. Вся ML-часть продукта – ответственность DS, включая мониторинг.

•             Руководитель проекта. Параллельно с разработкой делает БТ, ТЗ и прочие документы – независимо от разработчиков. Это важно: разработчики не ждут, пока РП закончит документацию; они работают по DoR.

Чёткое разделение позволяет параллельно вести несколько продуктов малым числом DS – каждый занят своей частью, никто не блокирует друг друга.

Принцип 4: Model Service через Pipeline + Monitoring

Ноутбук из PoC – это ещё не продукт. Принцип 4 требует, чтобы код из ноутбука был переписан в структурированный пайплайн, а модель упакована в Model Service.

Ноутбук → Pipeline. Код переписан в типовой ML Pipeline по SinaraML: data load → data preparation → model train → model eval → model test → build Model Image. Каждый шаг версионирован, data lineage отслеживается – можно воспроизвести любую версию модели от любой версии данных. Это базовое требование: если модель «сломается» через полгода, мы должны точно знать, на каких данных и каком коде её учили. Без Pipeline и Monitoring модель не переживает автора.

Model Service через BentoML. Модель упаковывается через BentoML с REST API. Это и есть артефакт ML dev процесса, который стыкуется с бэкендом по контракту. Model Service – не «модель в вакууме», а стандартизованный артефакт с пред-/постпроцессингом и JSON-интерфейсом.

Model Monitoring. Model Monitoring разрабатывает DS. Система следит за тремя типами данных: - X – входные показатели (дрейф распределений); - Y – рекомендации системы; - Y’ – фактические действия оператора (по изменению оборотов в АСУТП)

Продукт на ПГЛЗ работает автономно, но через Kafka передаёт X/Y/Y’ в Long-term Storage в Москве – оттуда Model Monitoring считает дрейф. На промышленном объекте дрейф – это не только изменение режима процесса. Это ещё и старение датчиков (показания плывут со временем), замена оборудования (новый питатель работает чуть иначе), смена сырья (другая партия нефелинового концентрата). Model Monitoring должен ловить всё это – иначе модель начнёт врать, а мы не поймём почему.

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

Принцип 5: децентрализованная эксплуатация, централизованный контроль

Архитектура выстроена по трёхуровневой схеме:

•             Device – АСУТП печи: датчики, контроллеры, источник сырых данных процесса.

•             Edge (площадка ПГЛЗ) – продукт, работающий автономно: продюсер из АСУТП в Kafka, консьюмер из Kafka в локальное хранилище, локальный Model Service, локальный UI оператора. Если связь с Москвой пропадёт, продукт продолжит работать – оператор будет видеть рекомендации, модель будет их выдавать.

•             Cloud (Москва) – централизованная платформа: Long-term Storage для исторических данных и переобучения, Model Monitoring для ловли дрейфа. Сюда же стекаются данные со всех площадок компании.

Связь между edge и cloud – через корпоративную шину данных (КШД). Данные текут в одну сторону (с площадки в центр), рекомендации и модель – в обе (модель обновляется в центре, разворачивается на площадке).

Как компоненты связаны. Data Producer опрашивает АСУТП раз в минуту и кладёт сырые показания в Kafka. Консьюмер читает их в локальное хранилище продукта (Main DB) – для оперативного UI. Параллельно те же данные через Kafka уходят в Long-term Storage в Москве – для переобучения и Model Monitoring. Model Service на площадке подписан на Kafka, при поступлении новой порции данных формирует рекомендацию и публикует её обратно в Kafka, откуда UI забирает её для оператора.

Если Model Service упадёт, данные не потеряются – они накопятся в Kafka и локальном хранилище. Когда сервис поднимется, он догонит очередь. Для промышленного объекта это критично: лучше пропустить пару рекомендаций, чем потерять историю процесса. А если связь с Москвой пропадёт – продукт на ПГЛЗ продолжит работать автономно на локальных данных; накопленные X/Y/Y’ уйдут в Long-term Storage, когда связь вернётся.

Сценарий работы.

1.          Генерация рекомендации. Модель опрашивает состояние печи раз в минуту и при выходе фазового состава за пределы целевого интервала формирует рекомендацию. Новая рекомендация не выдаётся, пока активна предыдущая или пока действует фриз после её выполнения.

2.          Реакция оператора. Получив рекомендацию, оператор может принять её (и тогда обороты меняются) или отклонить.

3.          Фриз после принятия. Как только факт выполнения рекомендации зафиксирован в АСУТП, система включает «фриз» длительностью 5 минут – в этот период новые рекомендации не формируются. Это даёт процессу время отреагировать на изменение управляющего воздействия и предотвращает серию навязчивых советов, пока печь ещё «переваривает» предыдущий шаг.

4.          Возобновление. После окончания фриза модель снова начинает оценивать состояние и при необходимости выдаёт следующую рекомендацию.

Принцип 6: тиражирование на типовые сценарии

На ПГЛЗ шесть однотипных печей спекания нефелина. То, что мы сделали для печи №1, должно тиражироваться на остальные пять – без переписывания архитектуры. Принцип 6 про это: типизация на уровне сценария, не только на уровне компонента. Один и тот же типовой сценарий (печь спекания нефелина) воспроизводится на N объектов с минимальной адаптацией.

Что переносится на новую печь, а что – нет

Только модель и точка подключения к источнику данных – новые. Всё остальное – переиспользуется. Это и есть смысл типизации: дата-сайентист ведёт параллельно несколько объектов, потому что инфраструктурная часть уже готова.

Пределы переносимости

Важно понимать: типизация – не «один код для всех», а «одна архитектура для всех». Переносимость не абсолютна:

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

•             Оборудование отличается. Печи разных годов выпуска, разные питатели, разные датчики – feature engineering может потребовать адаптации.

•             Режимы отличаются. Технологические карты на разных площадках свои – пороги срабатывания, целевые интервалы, частота рекомендаций настраиваются под объект.

•             Источники данных отличаются. На ПГЛЗ – АСУТП; на других площадках могут быть MES, SAP или иные системы. Data Producer адаптируется под конкретный источник.

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

Альтернатива: «зоопарк» систем

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

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

Результаты и текущий статус

Timeline: 3 месяца от старта PoC до закрытого тестирования.

Команда: - PoC: 1 дата-сайентист; - Продукт: кросс-функциональная команда (руководитель проекта, бизнес-аналитик, разработчики, ML-инженеры, представители заводов)

Текущий статус: продукт тестируется в закрытом контуре на первой печи ПГЛЗ. Система выдаёт рекомендации, операторы их видят в UI и принимают решения. Из Москвы через Model Monitoring наблюдаем за работой удалённо.

Метрики качества модели на тестовой выборке: - MAE по величине изменения: 225; - R²: 0.48; - RMSE: 330

Для сравнения – те же метрики у baseline-моделей (Dummy, Ridge) приведены в таблице выше.

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

Экономический эффект: на этапе PoC прямой расчёт не проводился (нет возможности верифицировать реакцию реальной печи на рекомендации модели). Ожидаемый порядок – десятки миллионов рублей в год за счёт удержания фазового состава в оптимальном интервале (~0.55) и снижения потерь глинозёма.

Lessons learned

Что сработало хорошо

DoR как стартовая точка. DoR приземлил бизнес-хотелки завода и дал команде DS чёткий сигнал: вот проблема, вот ценность, вот данные – можно работать. Без DoR команда бы разбиралась в требованиях недели.

Триада технолог + аналитик + DS. Технолог дал экспертизу процесса, аналитик перевёл в требования, DS проверил осуществимость. Без триады либо модель решала бы не ту задачу, либо решала правильно, но непонятно для заказчика.

Параллельная работа по DoR и БТ/ТЗ. РП делал БТ и ТЗ независимо от разработчиков – команда DS не ждала документации, а работала по DoR.

Чёткое разделение ролей. Дев-команда – продюсер, консьюмер, локальное хранилище, UI. ML-инженеры – выделили ресурсы на платформе. DS – модель, Model Service, Model Monitoring. Никто не лез в чужую область.

Переиспользование корпоративной шины данных. Kafka была поднята в рамках отдельного корпоративного проекта (КШД), и нам не пришлось строить её под каждый ML-продукт.

Централизация Long-term Storage и Monitoring в Москве. На площадке продукт работает автономно, а через Kafka передаёт данные для мониторинга и переобучения в центр.

CatBoost + explainability. Градиентный бустинг дал хорошее качество и feature importance – оператор видит, какие параметры повлияли на рекомендацию.

Архитектура «советчика». Модель не управляет процессом напрямую, оператор принимает решение. Human-in-the-loop – не слабость, а требование безопасности для промышленного объекта.

Что пошло не так

Данные от CV-команды. Потеряли месяц на поиск проблемы с агрегацией кадров: вместо усреднения 20 кадров в секунду брался один. Запросили сырые данные, провели агрегацию сами – корреляция появилась. Вывод: всегда проверяйте сырые данные, даже если вам говорят «это уже готово».

Алогичные действия операторов. В данных есть кейсы, когда операторы действуют противоречиво на одинаковые состояния печи. Модель это усредняет, но иногда выдаёт «странные» рекомендации. Работаем над фильтрацией аномалий в обучающих данных.

Что в планах

Улучшение метрик. Параллельно с эксплуатацией продолжаем работу над качеством модели: - Расширение набора признаков; - Эксперименты с архитектурой (добавление временных рядов); - Очистка обучающих данных от аномалий

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

Тиражирование. После успешного закрытого тестирования планируем развернуть систему на остальных 5 печах ПГЛЗ, затем – оценить применимость на других глинозёмных производствах компании. Не обещаем, что перенесётся «как есть» – специфика объектов разная, но фундамент (архитектура, пайплайн, мониторинг) переиспользуется.

Вместо заключения

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

Вопросы к сообществу

А как у вас в компании устроена разработка ML-продуктов для нескольких объектов?

Делитесь в комментариях – особенно интересно: - Делаете ли вы общую платформу под несколько ML-продуктов, или каждый продукт живёт сам по себе; - Как распределяете роли между дата-сайентистами, ML-инженерами и дев-командой; - Как решаете вопрос доверия операторов к рекомендациям ИИ на производстве; - Проводили ли переобучение моделей в проде и как с этим жили

Буду рад ответить на вопросы по архитектуре, модели и процессу внедрения!