Введение в MLOps: 3 процесса, которые должен внедрить бизнес

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

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

Обучение модели

На этапе обучения модели MLOps помогает с воспроизводимостью и автоматизирует обучение и оценку модели. Две концепции, важные для обучения модели, — это отслеживание экспериментов и конвейеры обучения. Отслеживание экспериментов относится к структурированному способу, с помощью которого специалисты по данным определяют факторы, влияющие на производительность модели, сравнивают результаты и выбирают оптимальную версию. Это особенно важно в MLOps для оценки. Есть много инструментов, которые команды MLOps могут использовать для отслеживания экспериментов. SDT предоставляет автоматизированный комплексный инструмент создания и оптимизации моделей под названием CobiOps как часть Облачной экосистемы SDT для обучения моделей в режиме plug-and-play в повседневных промышленных приложениях. Другие популярные инструменты, такие как MLflow, предлагают ручное A/B-тестирование моделей и подробное отслеживание экспериментов для разработчиков.

Однако отслеживание экспериментов не решает всех проблем, возникающих при обучении моделей (например, ручных ошибок). Конвейеры обучения работают, позволяя преобразовать и сопоставить последовательность данных вместе в модели, которую можно протестировать и оценить для достижения результата; таким образом, в основном это помогает автоматизировать рабочие процессы машинного обучения. Автоматизация процессов сбора и очистки данных помогает снизить риск человеческих ошибок. Кроме того, команды MLOps извлекают выгоду из конвейеров машинного обучения, чтобы ускорить разработку и ввод в эксплуатацию. Итак, подведем итог: отслеживание экспериментов может помочь в автоматизации оценки модели, а конвейеры обучения — в автоматизации обучения модели.

Развертывание

Последним шагом в использовании обучения модели машинного обучения является развертывание разработанной модели в производственной среде. Развертывание модели, пожалуй, самая сложная часть MLOps. Первое решение о развертывании модели, которое, скорее всего, примут компании, — это разработка «стратегии обслуживания модели», другими словами, компании должны подумать о том, как модель будет делать прогнозы.

Типы модельного обслуживания

Обслуживание моделей относится к тому, как обслуживать модели, обученные с помощью машинного обучения. Одна из его проблем заключается в том, что компании, внедряющие машинное обучение, вероятно, используют две разные группы, которые выполняют разные обязанности по обучению моделей и обслуживанию моделей. Это также означает, что они используют разные инструменты и имеют разные задачи. Тем не менее, поскольку эти команды объединяются в инженеры по машинному обучению, важно быть знакомым с различными типами стратегий развертывания, необходимых для MLOps. Методы обслуживания, с которыми лучше всего должны быть знакомы разработчики MLOps, — это автономное обслуживание, онлайн-модель как услуга и периферийное развертывание.

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

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

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

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

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

Самым большим недостатком онлайн-обслуживания являются затраты на передачу данных и ресурсы облачных вычислений. Онлайн-обслуживание в режиме реального времени обычно относится к передаче данных с частотой менее минуты (иногда до 5 минут в зависимости от сложности или необходимости), что экспоненциально увеличивает скорость передачи данных; затраты также зависят от того, используете ли вы сотовую сеть LTE или LoRa. Облачные ресурсы должны работать непрерывно. Поскольку облачные сервисы, такие как AWS, обычно выставляют счета за количество ресурсов X минут использования, этот тип развертывания трудно масштабировать с экономической точки зрения. В качестве альтернативы, автономное обслуживание может передавать один раз в день и требовать большого количества облачных ресурсов только в течение нескольких часов в день.

Первичная разработка отказывается от общедоступных серверов, например тех, которые используются для обслуживания в автономном и онлайн-режиме, и переносит обработку/вычисления модели с сервера на периферию. Реальное периферийное развертывание моделей машинного обучения в настоящее время очень ограничено из-за истории низкой доступности оборудования. Тем не менее, предпринимаются шаги к массовому периферийному развертыванию, а граничные вычисления и периферийный ИИ считаются одними из самых популярных приложений IoT по версии Gartner в 2022 году.

SDT предоставляет полную платформу HaaS (аппаратное обеспечение как услуга) для MLOps, локально устанавливая и объединяя в сеть SDT ECN и NodeQ — пограничные компьютеры обработки и устройства сбора данных, которые могут подключаться к большинству промышленных и устаревших машин. В сочетании с программным обеспечением для машинного обучения SDT CobiOps каждый сайт может быть преобразован в MLOps для периферийной разработки для значительной экономии средств и операций. Другие компании обеспечивают поддержку граничных платформ MLOps, предлагая только программные пакеты, такие как TensorFlow JS от Google для SDK для вывода моделей.

Мониторинг модели

Мониторинг помогает специалистам по данным обнаруживать изменения в поведении модели. После развертывания модели в рабочей среде требуется мониторинг, чтобы убедиться, что модель продолжает работать должным образом. Рассмотрим типичные метрики DevOps, которые необходимо проверить и решить, если они превысят определенный порог: унитизация ЦП, память, использование сети и другие. Мониторинг моделей помогает командам MLOps заранее выявлять потенциальные проблемы и сокращать время простоя.

Мониторинг моделей на этом не заканчивается. Команды MLOps также должны убедиться, что прогнозы модели не устаревают. Однако, если производительность модели ухудшается, команда может запустить конвейер обучения и переобучить модель на новых данных. В последние годы появилось множество платформ мониторинга моделей машинного обучения, включая Amazon SageMaker, Qaludo и Neptune. К концу 2022 года SDT также выпустит инструмент мониторинга и управления инфраструктурой DevOps, который может работать вместе с CobiOps для обеспечения обратной связи с моделью.

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

Заключение

Большинство организаций борются за внедрение, управление и развертывание моделей машинного обучения в масштабе, что приводит к появлению MLOps, которые охватывают все этапы программного обеспечения ML с момента его создания. Хотя в этом блоге мы коснулись только поверхности MLOps, как растущей дисциплины важно понимать, как команды могут объединяться для решения проблем с моделями ML. MLOps.org предлагает дополнительные ресурсы на GitHub, чтобы продолжить изучение этой новой области. Следите за блогами SDT для будущих блогов по теме!

Узнайте больше о разработках SDT в области машинного обучения в блоге SDT Naver или подпишитесь на нашу SDT LinkedIn, чтобы быть в курсе предстоящих выпусков наших продуктов.

Об авторе: Карен — страстный блоггер, посвященный технологиям B2B. Во время учебы в Технологическом институте Джорджии Карен впервые заинтересовалась кибербезопасностью и с тех пор работала в нескольких компаниях, занимающихся безопасностью и облачными технологиями, в качестве глобального маркетолога. Когда она не пишет внештатно, Карен любит исследовать новые кулинарные тенденции.