Этапы внедрения ML-моделей на предприятиях

Этапы

Перед внедрением ML в продуктивные системы необходимо определить, что за процесс мы планируем «оптимизировать», какие данные/система у нас есть для этого, и приблизительно оценить возможные эффекты от реализации проекта. Для этого нужно сформировать список гипотез, которые могут быть интересны компании, и выбрать идею с самым большим потенциалом.

Следующий шаг — проверка гипотезы (Proof of Concept, PoC), или пилотный проект. За 1–2 месяца мы оцениваем жизнеспособность идеи. С помощью PoC можно либо оперативно определить существующие ограничения (как в данных, так и в процессах) и вовремя отказаться от идеи, либо за короткий срок увидеть результат и убедиться в целесообразности полноценного внедрения.

В случае успеха пилота переходим к реализации проекта. Ключевая особенность внедрений в области DS — их циклическая природа. Успех достигается за счет прохождения нескольких итераций по так называемому циклу Data Science (см. рис. 2): анализ бизнес-процесса, прототипирование моделей и тестирование. Также необходимо тщательно выбрать и согласовать с заказчиком метрики оценки качества моделей. Важно, чтобы технические метрики коррелировали с бизнес-метриками, достижение последних, по сути, является главной целью проекта.

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

Таким образом, процесс внедрения включает несколько шагов:

1. Формирование и приоритизация списка идей.
2. Пилотирование.
3. Проектное внедрение.
4. Мониторинг и обновление моделей.

Рассмотрим эти пункты.

Формирование списка идей

На пути к цифровой трансформации большинство компаний задаются вопросом, где и как искать концепт для проектов Data Science. Кто-то для решения этой проблемы нанимает Chief Digital Transformation Officer — человека, отвечающего за все цифровые преобразования в компании и знающего, где стоит внедрять модели ML и предиктивной аналитики.

Если такого человека на предприятии нет, помогут сессии Design Thinking с представителями всех «слоев» компании: технологами, инженерами, ИТ-специалистами и топ-менеджерами. Только в таком составе можно получить максимально полную картину основных бизнес-процессов и выяснить, где же «болит» сильнее всего. В результате подобных сессий формируется список идей (или инициатив), которые нужно тщательно отфильтровать и приоритизировать. В зависимости от области оптимизируемого бизнес-процесса (HR, финансы, производство и т.д.) отбираются основные факторы, по которым будет идти отсев потенциально полезных гипотез. Учитываются реализуемость каждой идеи (насколько быстро ее можно осуществить, да и можно ли вообще) и потенциальный экономический эффект (оценка эффекта от внедрения и его сравнение со стоимостью проекта). А вот опираться на хайп точно не стоит. Не всегда нужно решать задачи с помощью модных методов (скажем, нейросетей или методов обучения с подкреплением). В большинстве случаев это кратно увеличит сроки и стоимость проекта, а ценность такого решения вряд ли будет выше по сравнению с использованием классических подходов.

Для одного крупного металлургического завода мы вместе со специалистами предприятия составили список из 33 идей и инициатив. Это были как предложения по оптимизации основных технологических процессов (рекомендательные системы для повышения качества и снижения стоимости стали), так и идеи, связанные с безопасностью (чат-бот для информирования руководителей о нахождении сотрудников в опасной зоне), финансами (автоматическое выравнивание банковских транзакций) и др. После проработки каждой идеи и отсева остались 3 инициативы. Мы выбрали одну — с самым большим потенциалом — и приступили к пилотированию.

Пилотирование

Предположим, мы нашли идею, реализация которой повысит качество продукции. Что делать дальше? Скорее собирать команду, закупать железо, нанимать специалистов по Data Science!

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

Чтобы избежать этого, необходимо пилотирование. Именно на этом этапе изучаются бизнес-процессы, составляется карта ИТ-ландшафта, проводится ревизия накопленных данных и выполняется оценка их качества.

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

Предположим, мы прогнозируем продажи товара повседневного спроса. С точки зрения ML это задача регрессии. То есть выходом модели является число — количество проданного товара в будущем. Метрика оценки качества моделей регрессии — абсолютное или квадратичное отклонение прогноза от фактического значения. Но что даст эта цифра директору магазина? Мы знаем стоимость хранения товара на складе (если наш прогноз оказался больше факта) и стоимость самого товара (упущенная выгода, если мы спрогнозировали меньше, чем продали на самом деле). На основе этих данных можно рассчитать ошибку модели в деньгах и сравнить ее с прогнозами существующих у заказчика решений или расчетами специалистов, планирующих закупки. С одним из наших клиентов-ритейлеров мы таким образом выбрали метрику оценки качества предиктивного сервиса и снизили ошибку в рублях на 5%. Для розничных продаж это очень много.

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

На основе подобных базовых моделей можно оценить потенциальный бизнес-эффект и принять решение о переводе пилота в статус «боевого проекта».

Проектное внедрение

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

Для того чтобы разработка ML-алгоритма не блокировала работу остальных членов проектной команды, необходимо как можно скорее создать первую версию модели и передать ее программистам. Точность модели на данном этапе не играет роли, главное — как можно быстрее построить сценарий end-2-end и отладить интеграцию.

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

На одном проекте мы встраивали нейронные сети для распознавания образов в процессы и, соответственно, в ИТ-контур компании. Первое, что мы сделали, — оценили, как в существующей ИТ-инфраструктуре можно запускать нейронные сети. Это позволило не только выбрать продуктивную среду, но и определить, какими библиотеками прототипирования могут пользоваться Data Scientists. В результате перенос каждой новой версии модели в продуктивный контур был практически бесшовным и сэкономил команде время и силы.

Как уже упоминалось выше, процесс разработки и внедрения ML-моделей подчиняется циклу анализа данных (см. рис. 2). Поэтому важно, чтобы методология ведения проекта также была гибкой и устойчивой к серьезным изменениям как задач, так и основных целей внедрения. Наиболее подходящие Agile-методологии — Scrum, Kanban или их гибрид.

Мониторинг и обновление моделей

После внедрения ML-моделей проект завершается. Снова нет! Мир не стоит на месте, бизнес трансформируется: меняются входные данные (новый поставщик сырья, другие датчики и т.д.), бизнес-процессы, курс доллара… И с каждым подобным изменением качество внедренных интеллектуальных сервисов снижается. Это естественная деградация моделей. Чтобы алгоритмами можно было пользоваться и дальше, необходимо периодически их актуализировать. Для этого в функционал разрабатываемой системы включают сервис мониторинга качества моделей. В случае негативных изменений он сигнализирует пользователям о проблеме и с их разрешения обновляет (дообучает) алгоритм.

Если процесс «старения» моделей может занимать несколько месяцев, а в редких случаях и лет, то выход из строя важного для прогноза датчика может произойти и на следующий день после сдачи проекта. Здесь поможет внедрение продуктов класса Data Quality Monitoring (DQM). Они отслеживают качество самих данных, используемых моделями, чтобы они не сильно отклонялись от исторического диапазона. При детектировании проблем с данными DQM сообщает пользователю, что прогнозам ML-алгоритма сейчас доверять не стоит, и указывает на проблемные места.