Зачем заводам машинное обучение

Как машинное обучение внедряется на промышленных предприятиях, кто в этом достиг наибольших успехов и какие примеры использования уже есть, мы узнали у Романа Чеботарёва. Роман — архитектор ML и директор по внедрению в компании «Цифра». Он 11 лет занимается внедрением умных технологий класса Machine Learning и Artificial Intelligence. Последние несколько лет Роман специализируется на ML/AI в промышленности.

Расскажите о своем профессиональном пути

Свой профессиональный путь я начал с машинного обучения (хотя тогда такой термин еще массово не использовался) для задач компьютерного зрения. Я разрабатывал различные модули для систем видеоаналитики: детекторы скоплений людей, детекторы дыма, счетчики объектов. Тогда еще они планировались как охранные системы будущего поколения — сейчас они используются повсеместно.

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

Потом серьезный интерес к машинному обучению начал формироваться со стороны промышленных предприятий. В какой-то момент я с партнерами решил организовать собственный стартап — Theta Data Solution. Мы сделали 6 проектов и больше 10 пилотов за год для промышленных предприятий, а потом нашу компанию приобрела компания «Цифра», где я сейчас работаю директором по внедрению в департаменте AI. По сравнению с первоначальной командой стартапа мы сильно расширились: сейчас в нашем AI-tribe (как мы себя называем) больше 30 человек.
Когда промышленность заинтересовалась машинным обучением?

Интерес существовал всегда, но готовность компаний вкладывать деньги в эти проекты, пусть и очень-очень вялая, появилась, по моим наблюдениям, в 2013-м. Более-менее стало возможно называть это трендом к 2016-му. Сейчас наступила фаза быстрого роста.

В чем специфика проектирования моделей машинного обучения для промышленных предприятий?

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

Это сказывается на том, как проектируются и эксплуатируются модели: они сильно «перекошены» в сторону того, чтобы меньше экспериментировать. Если, допустим, в финтехе или телекоме вы можете себе позволить на уровне какого-то подмножества клиентов сделать A/B-тесты и показать им принципиально другую рекламу, дать направленную скидку и т.п., то в промышленности инструментарий и возможности экспериментирования значительно уже. Если попытаться сформулировать особенности одной фразой — резких изменений в работе промышленной системы делать нельзя. Изменения будут носить очень небольшой и направленный характер. Мы будем вносить коррективы, смотреть, что происходит — и, если все идет удачно, стараться двигаться в этом направлении, но очень маленькими шажками. Это называется регуляризацией моделей машинного обучения (точнее, моделей управления) — в промышленности они очень зарегуляризованы на изменения. Таким образом минимизируется возможность дорогостоящей ошибки.

Вторая особенность в том, что модели машинного обучения (ML) нужно подружить с физикой и химией. Это оказывается достаточно непросто. Модели, построенной на данных, все равно, какая физика лежит за конкретным процессом — она просто улавливает закономерности между данными. Часто оказывается, что построенная модель оказывается абсолютно нефизична. Например, любой здравомыслящий человек понимает — и физика это подтверждает: если в системе отопления повысить температуру теплоносителя, в домах станет теплее при прочих равных обстоятельствах. А модель может выучить совершенно другую зависимость, иногда обратную. Придать больший вес косвенным факторам (перепады температур на улице, время суток и т.п.) и за счет этого выучить вроде бы правильное поведение, но использовав «неправильные» факторы.

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

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

Для ясности я часто ввожу такое понятие как «потратить данные». Когда вы чему-то учите модель, вы «тратите» данные (в том смысле, что любое их повторное использование при обучении является достаточно тонким моментом, есть риск «переобучения» — overfitting). Так вот мы не «тратим» данные на восстановление закономерностей и зависимостей, которые в общем виде уже и так известны благодаря ученым и технологам. Мы используем эти известные зависимости и «тратим» данные на то, чтобы уточнить характеристики, достроить неучтенные в физмоделях зависимости и построить в итоге модели, которые учитывают особенности каждого локального участка производства или даже единицы оборудования, зная, как оно в принципе работает.

В итоге мы получаем более качественные и устойчивые модели. Естественно, физические и химические модели процессов не всегда доступны или полны – на этот случай у нас в команде есть аналитики с опытом в соответствующих индустриях, кто мог бы построить для data scientist’ов соответствующие физические baseline-модели.

Кроме того, мы пробуем использовать подходы теории автоматического управления для принятия решений об оптимальных управляющих параметрах, которые нужно выставить на установке с учетом неизбежного лага во времени и вероятности, что рекомендация вообще не будет принята. Вообще, мы присматриваемся к Reinforcement Learning подходам, но пока получаемые законы управления (policy) получаются достаточно неустойчивыми в наших задачах. Но за объединением этих подходов точно лежит будущее. И это не только мое мнение.

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

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

22 ноября Роман станет модератором дискуссионной панели «AI и IoT: ожидание и реальность» на AI Conference. Подробности и программа мероприятия — на официальном сайте.

Как проходит работа по созданию цифровой модели производственного процесса?

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

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

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

Как часто при разработке модели и ее внедрении вам приходится выходить на реальное предприятие?

На площадке больше всего времени проводят бизнес-аналитики. Они всегда присутствуют в команде проекта, помимо data scientist’ов и data engineer’ов. Бизнес-аналитики описывают процессы, пишут правила и ограничения работы системы, и им нужно глубоко разбираться в том процессе, который предстоит, как нынче модно говорить «цифровизовать», точнее, простите, «диджитализировать». На площадке они выясняют определенные нюансы и понимают, где, как и что нужно реализовать, чтобы процесс работал: как обычно управляют процессом, как не управляют, о чем обычно не пишут в регламентах. Очень многие вещи можно узнать только в курилке, пообщавшись с местными работягами во время перерыва – как в действительности обстоят дела, где действительно стоит прилагать усилия и т. д. Задача аналитиков — вскрыть потребность, а об этом можно узнать только у реальных сотрудников, которые работают на местах, своими руками. Но тут есть специфика: те люди, которые работают своими руками, обычно живут далеко городов-миллионников. Иногда они вообще присутствуют вахтовым методом на месторождениях и карьерах. Поэтому нам и приходится ездить к ним в разные живописные места.

Самое далекое, куда вас заносило?

Мы были везде, от Мурманской области до Хабаровского края.

Часто ли бывает, что созданная виртуальная модель начинает сразу и без сюрпризов работать в реальных условиях?

Мы стараемся минимизировать все сюрпризы на этапе обследования, но при внедрении без них никогда не обходится. Сюрпризы можно разделить на несколько групп. Первая — естественно, айтишные и инфраструктурные. Для обновления моделей во времени нам важно иметь доступ к данным, чтобы что-то изменить, пофиксить, добавить. Но доступа к инфраструктуре может и не быть, если объект располагается где-то очень далеко, где связь организована, как мы говорим, «через расческу» или отсутствует вообще. Если об этом известно заранее, можно построить и отладить процесс, который будет обновлять модели самостоятельно, без вмешательства ее создателей. Это делается сейчас относительно несложно, у нас есть готовые технологии для этого — но тем не менее, хотелось бы знать заранее, что связи не будет. Как минимум, потому что это влияет на трудозатраты и стоимость проекта. Заказчики проекта чаще всего идут договариваться с айтишниками, когда проект уже близок к внедрению. Это характерно не только для промышленности, просто здесь это наиболее критично. От того, будет интернет или нет, сильно зависит архитектура решения, как я уже сказал ранее. И дело здесь не только в моделях.

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

Вспомните самый успешный и самый трудоемкий пример внедрения.

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

Трудоемких же примеров гораздо больше. К сожалению, наличие термина «диджитализация» в предварительных разговорах с заказчиком здесь часто является признаком того, что проект не будет успешным. Часто мы слышим: «Вы участвуете в нашем процессе цифровой трансформации, мы полностью все переделываем, поэтому вкрутите вот сюда вот ваш AI». При этом люди часто не понимают, что они должны решать задачи не при помощи машины, а сначала изменив процессы в своей компании на более соответствующие «диджитализации». Изменение процессов (или хотя бы их переосмысление) всегда должны быть первой фазой изменений при любой диджитализации или другой эволюции. У любого инструмента, в том числе у машинного обучения, есть границы применимости. Если процесс древний, неоптимальный, и что еще хуже – построенный полностью на консенсусе людей (нужно сесть нескольким людям и решить как поступить – такое часто бывает в производственной логистике, где сталкиваются производственники, логисты и коммерция), то никакое машинное обучение этого не исправит. И, напротив, иногда простейшие изменения в процессах (например, концепции «бережливого производства») позволяют достигнуть таких эффектов, которых никаким ML достигнуть нельзя. К сожалению, очень мало «трансформаторов» это понимают и работают в этом направлении. Хайпануть на внедрении AI, неважно для чего, оказывается более распространенной практикой.

Простой пример: стоит ректификационная колонна, в ней можно управлять скоростями подачи пара и флегмы. Если мы просто выдаем на экран рекомендации оператору — «дружище, крути эту ручку вот так» — то эффекта от системы, к сожалению, почти не будет. Человек в идеале должен остаться только для контроля, а непосредственное управление должно быть автоматическим. Такое изменение процесса по нашим очень консервативным оценкам дает улучшение в 3-4 раза. Я не за то, чтобы всех людей уволить и заменить на машины — просто даже небольшое изменение процесса с очень небольшими инвестициями дает гораздо больший эффект.

Многие проекты, про которые заявляется, что там внедрен AI, на деле выглядят так, уж простите за правду-матку: некоему дяде Васе на экране выводятся рекомендации, он на них смотрит и говорит «Да и черт с ним, может быть, завтра я поставлю так, как он хочет — а сегодня ничего не буду делать». Бывает очень жалко, что мощные крутые технологии разбиваются о процессы предприятия и людей, не готовых менять эти процессы. А вот если бы этому дяде Васе поставить KPI на выполнение рекомендаций системы. Или даже вообще без AI – поставить Васе KPI на удельный выход продукта к сырью, просто как бонус к з/п – вот тогда бывают по-настоящему серьезные эффекты. При условии, конечно, что дядю Васю нельзя заменить на контроллер, но это уже вопрос из другой плоскости.

Как на предприятиях обстоят дела со сбором данных и машинным обучением? Сколько из них пытаются идти в этом направлении?

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

Но нужно понимать, что в основном это системы, которые дают рекомендации человеку, а он уже принимает решение, делать что-то в соответствии с этими рекомендациями или нет, практически нет автоматического исполнения рекомендаций. Это безусловно стопор развития данных систем. В общем, это, конечно же, ни разу не «Индустрия 4.0», как это часто любят позиционировать в СМИ. Но переоснащение автоматикой требует больших капитальных затрат, так что пока радуемся тому, что есть.

Нам бы хотелось видеть процессы в компаниях более органическими: люди вначале собирают данные, а потом на их основе внедряют машинное обучение. На деле сначала возникает потребность что-то сделать на основе AI/ML, мы приходим к заказчику и понимаем, что нужные данные не собираются. Или они складываются в каком-то ужасном виде, так, что достать их невозможно — надо начинать проект по сбору данных. Лет 5-7 назад это было распространено в телекомах и банках повсеместно (сейчас уже нет) — сегодня те же проблемы у промышленности. Были проекты, которые отсрочивались на полгода — полтора года из-за отсутствия данных.

Это время, за которое внедряются датчики и системы сбора данных?

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

Мы считаем, что любой процесс, который еще на автоматизирован при помощи AI и ML, можно оптимизировать на 1-2%. Когда мы выбираем проект, мы анализируем: сколько в этой промышленности, в этом цеху тратится денег на сырье, на электроэнергию, на ремонты? Мы берем эту величину в деньгах и высчитываем от нее 1-2%. Если в денежном выражении это получается резонно, то мы занимаемся этим проектом.

Часто работаем по схеме success fee. Условно — внедрение проекта стоит 50 млн — разные интеграторы по рынку, допустим, называют вам примерно такую стоимость. Мы готовы сделать проект за 10 млн, но при этом мы хотим получать процент от экономии в ближайшие 2-3 года. В результате за счет этого в сумме может выходить в нашу сторону и 70-80 млн и даже больше — при условии, что заказчик также зарабатывает. Мы проводим пилотные фазы, видим, каких эффектов можем достичь, и готовы работать по такой схеме — получать платеж, который пропорционален достигнутому эффекту.

Какие стандартные типы задач AI решает на производстве?

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

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

Второй тип задач связан с необходимостью оптимизировать какой-то процесс. Разберем на примере с теплоэнергетикой, как наиболее понятном для широкого читателя. Мы можем управлять тепловыми режимами на источниках тепловой энергии (котельные, ТЭЦ и т. д.), при этом мы должны поддерживать определенный уровень температуры в разных помещениях: они находятся на разной удаленности, построены из разных материалов, различаются геодезией и вследствие этого по-разному охлаждаются окружающим воздухом. Как оптимально выстроить тепловые режимы в котельной или ТЭЦ, чтобы выдержать показатель уровня качества по отношению к конечному заказчику? Тут нужно определить основной показатель эффективности. Мы можем потратить суммарно меньше энергии на нагрев и перекачку теплоносителя, можем уменьшить количество жалоб от замерзших бабушек, можем сократить переменные затраты на нагрев, сократить тепловые потери или даже износ оборудования. Модель оптимизации можно сделать любую — только сообщите относительные приоритеты различных факторов. Этот выбор — самая большая проблема. Представьте себя владельцем теплоэнергетической компании. Сколько недовольных бабушек вы готовы обменять на то, что эта труба проживет на пару месяцев больше? Крайне непростой вопрос. Поэтому наши бизнес-аналитики работают в том числе над тем, что помогают свести все факторы к рублю как наиболее универсальной величине для измерений. После этого обычно становится понятно, над чем нужно работать и что оптимизировать.

Какие типы задач стало возможно решать совсем недавно благодаря усовершенствованию методов МО?

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

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

На самом деле, решения и рекомендации, которые выдаются системой, всегда в конечном счете эффективнее, чем те, что выдаются человеком. Иначе бы в нашем бизнесе просто не было смысла. Вот несколько примеров.

При производстве стали доменные печи потребляют энергии, как небольшой город. В зависимости от того, какого качества лом мы туда засыпаем, какого размера его куски, можно регулировать силу тока, который подается для нагрева печи. Управляя силой тока, можно значительно (а для промышленности 1-2% — это значительно) уменьшить затраты на электроэнергию.

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

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

Все производства в России единичны, и говорить, что мы где-то работаем, значит сразу вскрывать заказчика и нарушать NDA. Поэтому скажем так, что мы умеем делать такие же штуки для оптимизации производства минеральных удобрений, различных химических производств (не из нефтехимии). Из открытого — проект «Цифровой завод» для ПАО «Газпром нефть», подробности по которому легко гуглятся.