РУСАЛ - системный подход к ИИ-продуктам в промышленности, практический кейс, Андрей Писарев
Андрей Писарев, руководитель направления машинного обучения, Русал. Конференция TAdviser «Цифровые технологии в промышленности: практика и кейсы» 2026.
Направление и постановка проблемы
Изложение открывается с обозначения зоны ответственности: команда занимается разработкой, внедрением и сопровождением продуктов с искусственным интеллектом на производственных площадках РУСАЛа, специализируясь именно на обработке табличных данных — отдельно оговаривается, что направления компьютерного зрения и генеративного искусственного интеллекта относятся к другим отделам компании. Ключевой структурной проблемой промышленного применения ИИ называется фундаментальный дисбаланс: проектов и производственных площадок в РУСАЛе много, тогда как специалистов, способных разрабатывать такие продукты, всегда будет мало — это прямо характеризуется как аксиома, связанная со спецификой промышленного производства. Организация отдельной команды под каждую площадку признаётся заведомо неэффективным путём, что и подтолкнуло к выработке системного видения разработки продуктов, состоящего из шести взаимосвязанных принципов, раскрываемых далее на примере конкретного проекта.
Производственный контекст: печь спекания Пикалёвского глинозёмного завода
В качестве иллюстрации выбран Пикалёвский глинозёмный завод (ПГЛЗ), расположенный в Ленинградской области и занимающийся производством глинозёма. В производственной цепочке — от нефелиновой шихты через спекание и выщелачивание до транспортировки глинозёма на алюминиевые заводы для последующего электролиза — рассматриваемый проект охватывает именно этап преобразования нефелиновой шихты в спек, происходящий во вращающихся печах спекания длиной 150–170 метров. Управление печью осуществляется через подачу топливно-воздушной смеси: увеличение подачи воздуха охлаждает печь, уменьшение — усиливает нагрев в районе факела. Основная технологическая сложность заключается в постоянном изменении химического состава входного сырья, из-за чего управляющие параметры печи необходимо своевременно корректировать вручную, чтобы избежать получения слабого либо чрезмерно крепкого спека и связанных с этим производственных потерь. Задача бизнеса сформулирована поэтапно: в перспективе — полная автоматизация процесса, а на первом этапе — создание системы-советчика, заранее рекомендующей операторам изменение управляющих параметров.
Definition of Ready как отправная точка проекта
Первый из принципов — фиксация видения продукта в артефакте Definition of Ready. Команда встречается с минимальным составом заинтересованных лиц (как правило, порядка четырёх ролей, иногда с участием руководителя проекта), в ходе обсуждения фиксируются бизнес-требования именно в том виде, в котором результат видит производство, а также часть системных требований. Принципиальный момент — формальные документы вроде технического задания оформляются параллельно и не блокируют начало работы: команда сразу переходит к проверке гипотез.
Проверка гипотезы и переход к MVP
На этапе проверки концепции гипотеза формулировалась просто: можно ли по показаниям АСУ ТП и данным компьютерного зрения с приемлемой точностью заранее предсказывать изменение оборотов питателя — то есть управляющего параметра печи. Несмотря на возникавшие сложности, гипотеза была подтверждена за один месяц силами одного сотрудника на основе полугодичной выгрузки исторических данных, после чего проект перешёл в стадию MVP с заранее согласованным типовым видом продукта.
Типовая архитектура и разделение зон ответственности
На этапе MVP демонстрируется несколько принципов одновременно. Типовая архитектура решения состоит из источника данных, хранилища, самого продукта и системы мониторинга, при этом зоны ответственности чётко разграничены: источником выступают данные АСУ ТП предприятия в сочетании с данными видеоаналитики; инфраструктурная часть отвечает за передачу данных в Kafka; команда разработки отвечает за бэкенд и фронтенд; команда дата-сайентистов — за обработку данных, построение прогноза и мониторинг. Отдельно выделяется принцип Edge Cloud: ядро ML-продукта физически размещается непосредственно на производственной площадке в Ленинградской области, тогда как долгосрочное хранение данных вынесено в московский дата-центр, что обеспечивает возможность удалённого наблюдения за работой модели, её переобучения и исправления ошибок. Модель поставляется как образ в рамках микросервисной архитектуры через Nexus и интегрируется командой разработки на основе заранее согласованного контракта входных и выходных данных.
Human-in-the-Loop как обязательное условие
Особое значение придаётся принципу участия человека в контуре принятия решений. Принципиально важным называется то, что система не вносит никаких изменений непосредственно в промышленные системы-источники — передача данных является строго однонаправленной, продукт никак не воздействует на производственные процессы напрямую. Обратная связь реализована через интерфейс, доступный оператору на пульте управления: он видит визуализацию процесса спекания вместе с конкретной рекомендацией — например, указанием понизить скорость — и может согласиться либо не согласиться с советом системы; в случае несогласия информация сохраняется для последующего разбора причин. Отдельно отмечается, что именно такие случаи расхождения с рекомендациями, наряду с обнаруживаемыми в данных аномалиями, часто вскрывают слабую документированность реальных технологических процессов: по факту процесс может работать иначе, чем это описано, и подобные несостыковки выявляются только через анализ данных и последующие уточнения непосредственно на производстве.
Тиражирование решения
Завершающий принцип — тиражирование типового сценария на другие однотипные объекты. Продемонстрированное решение было реализовано для одной из шести печей Пикалёвского завода; при этом разработка первой версии заняла около месяца, тогда как тиражирование решения на следующую печь потребовало порядка недели — за счёт сохранения архитектуры и точечной донастройки под специфику конкретного агрегата (различия в датчиках или отдельных особенностях процесса). Помимо оставшихся печей завода, обозначен план тиражирования решения на другой глинозёмный завод в Красноярском крае, работающий по схожей технологии, с перспективой дальнейшей отработки качества управления печью на основе цифрового двойника.
Результаты и практические сложности внедрения
В качестве итоговой оценки указывается, что путь от старта проверки концепции до первого закрытого решения занял около трёх месяцев и был реализован силами одного специалиста по данным при поддержке кросс-функциональной команды — технического лидера, бэкенд-разработчиков, бизнес-аналитика и активно вовлечённых представителей производства. Отмечается, что итоговая метрика качества модели оказалась не столь высокой, как ожидалось, по двум основным причинам: нелогичные действия операторов, когда, например, печь неожиданно нагревали сильнее, хотя логика подсказывала обратное, а также ограниченность обучающей выборки — данные видеоаналитики появились лишь с начала текущего года, и по мере накопления этого массива метрики модели ожидаемо будут улучшаться. Отдельно упоминается техническая сложность, отнявшая около месяца: первоначально не удавалось найти связь между управляющими параметрами и показаниями CV-модели, а причина оказалась в некорректной агрегации данных — после перехода на использование необработанных, неагрегированных данных проблема была устранена.
Масштаб применения подхода
Завершается изложение констатацией общего результата: разработанная архитектура советчика уже работает в промышленной эксплуатации и собирает активную обратную связь от операторов, а сам типовой подход подтвердил свою эффективность на практике. Формулируется итоговый тезис: несмотря на крайне ограниченный состав команды, количество ведущихся проектов уже исчисляется несколькими десятками, что становится возможным именно благодаря системности и повторяемости применяемого подхода.
Профессиональные выводы
Центральный аналитический тезис заключается в том, что структурная нехватка ИИ-специалистов в промышленности решается не наращиванием штата, а стандартизацией самого процесса разработки: типовая архитектура, чёткое распределение зон ответственности и единый контракт между источником данных, инфраструктурой и продуктом позволяют РУСАЛу многократно тиражировать однажды выстроенное решение при минимальных дополнительных затратах — сокращение сроков внедрения с месяца до недели при переносе решения на новую печь является количественным подтверждением этого тезиса.
Второй значимый вывод касается роли человека в системе: принципиальный отказ от прямого воздействия ИИ-продукта на промышленные системы и сохранение за оператором права принятия финального решения формируют модель осторожного, поэтапного доверия к автоматизации — от полностью ручного управления к советующей системе как промежуточному и более реалистичному шагу перед возможной автоматизацией в будущем.
Третий вывод отражает практическую ценность обратной связи как инструмента диагностики самого производства, а не только модели: случаи несогласия оператора с рекомендацией и аномалии в данных систематически используются для выявления пробелов в документированности технологических процессов — то есть ИИ-система выполняет попутно ещё и функцию верификации реального, а не описанного на бумаге, порядка работы оборудования.
Наконец, показательным является соотношение вложенных ресурсов и результата: сравнительно небольшая команда, работающая по единым принципам, оказывается способной вести проект как в производстве, так и параллельно тиражировать его на десятки объектов — что указывает на выбранную методологию скорее как на организационную, а не сугубо технологическую инновацию, применимую значительно шире отдельно взятого кейса печей спекания.
