жизненный цикл модели машинного обучения

Жизненный цикл ML-модели

Всем привет! Меня зовут Максим, и в Ситимобил я занимаюсь машинным обучением. Сегодня я расскажу вам, как мы разрабатываем устойчивые ML-модели в суровых условиях изменчивого мира.

Зачем моделям нужен жизненный цикл

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

Представим, что модель уже разработана, метрика на out of time выборке (отложенной во времени) нас устраивает, и мы выкатываем модель в production. Получаем положительный результат в первый месяц работы, но потом качество сильно падает. Сколько нужно ждать, прежде чем предпринимать какие-либо действия в отношении модели? Стоит ли сразу же пытаться актуализировать её или же подождать, так как через день-два метрики снова станут стабильными? В идеальном мире ответ должен быть до развёртывания в production. И жизненный цикл поможет нам ответить на этот и другие вопросы по работе модели.

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

Принципы разработки жизненного цикла модели

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

Какие параметры нужно учитывать, чтобы оценить жизненный цикл:

периодичность переобучения модели;

необходимый объём обучающей выборки;

поведение целевой метрики во времени в стабильных и экстремальных условиях;

как учитывать различные смещения целевой переменной и модельных признаков;

прочие вопросы, характерные для отрасли применения модели.

Рассмотрим отдельно каждый из этих пунктов.

Периодичность переобучения модели

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

Так мы сможем оценить потенциальное ухудшение качества модели во времени и принять решение о частоте её переобучения.

Оценка объема обучающей выборки

По аналогии с изменением объёма тестовых данных мы можем менять объём обучающей выборки. Мотивация может быть разная:

на небольшом промежутке времени на обучающей выборке модель может переобучиться;

в распределении целевой переменной есть сезонность;

модель вносит смещение в распределение целевой переменной;

объёма данных может быть недостаточно для выявления ключевых зависимостей.

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

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

Изменение распределения целевой переменной

Часто бывает так, что поведение целевой переменной нестабильно во времени. Ещё больше нестабильности вносит тот факт, что модель прямо влияет на её распределение (в нашем примере).

Здесь видно, как зона распределения условной целевой переменной постепенно увеличивается с течением времени. Это означает, что применение ML-модели в новой области, которой не было в обучающей выборке, может быть непредсказуемо.

Частично эту проблему должно решать правило частоты переобучения модели. Но ещё на этапе моделирования мы можем оценить влияние нестабильного поведения предсказываемой переменной на целевую метрику. Для этого нужно провести симуляцию, в которой мы искусственно будем уменьшать или увеличивать на n% баланс положительного класса. Таким образом мы сможем сделать выводы о стабильности нашего жизненного цикла при нетипичном изменении (таком, которого не было в обучающей выборке) целевой переменной.

Прочие отраслевые вопросы

Самый простой пример: а что будет, если бизнес нашей компании вырастет на 20 % за n дней? Останется ли наш алгоритм стабильным, если завтра все входные признаки для модели увеличатся или уменьшатся на 20 %?

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

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

Мы разработали правила жизненного цикла, что дальше?

Вот мы и получили набор правил работы ML-модели. Половина дела сделана, осталось запустить жизненный цикл в production и мониторить его работу.

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

Источник

«Быть Insight-Driven»: продвинутая аналитика и управление жизненным циклом моделей машинного обучения

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

В чем суть Insight-Driven подхода

Многие специалисты достаточно давно говорят про важность Data-Driven, что в целом, конечно, абсолютно правильно, ведь этот поход предполагает принятие повышение эффективности управленческих решений за счет анализа данных, а не только интуиции и личного опыта руководства. Аналитики Forrester отмечают, что компании, опирающиеся в своей деятельности на анализ данных, растут в среднем на 30% быстрее конкурентов.

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

Чаще всего, когда речь идет о работе с данными, большинство специалистов подразумевают в первую очередь структурированную информацию внутри компании, однако, не так давно мы рассказывали о том, почему около 80% потенциально доступных данных бизнес в подавляющем большинстве вообще не использует. Insight-Driven как раз создает основу для того, чтобы дополнить картину внешней неструктурированной информацией, а также результатами интерпретации данных для поиска неявных зависимостей между ними.

DevOps + DataOps + ModelOps

В основе Insight-Driven лежат практики DevOps, DataOps и ModelOps. Поговорим о том, почему сочетание именно этих практик способно обеспечить полноценную реализацию подхода.

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

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

Внедрение Insight-Driven подхода в компании — нетривиальная задача. Но для тех, кто все-таки хотел бы начать работу с ним, мы расскажем, как это можно сделать.

Поиск и подготовка данных

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

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

Поиск источников и анализ данных. Когда цели и направления для поиска данных определены, наступает время анализа источников. На этот и последующий этапы разработки интеллектуальных сценариев, которые касаются подготовки уходит 70–80% бюджетов компаний при реализации. Дело в том, что качество дата-сета влияет на точность проектируемых моделей машинного обучения. Но необходимая информация часто бывает «разбросана» по различным системам — может лежать в реляционных базах данных, таких как MS SQL, Oracle, PostgreSQL, на платформе Hadoop и многих других источниках. И на этом этапе необходимо понять, где есть релевантные данные и как их собрать.

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

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

Трансформация данных. Следующий шаг — непосредственная работа с данными, которые должны решить поставленные задачи. Для этого данные очищают: проверяют, дедуплицируют, заполняют пробелы. Упростить этот процесс можно с помощью flow-based programming. В этом случае мы имеем дело с последовательностью операций — пайплайном. Его выход можно направить в графический интерфейс или другую систему для последующей работы. Здесь обработчики данных собирают как конструктор (и в зависимости от сценария). Это может быть периодическая или стриминговая обработка, либо REST-сервис.

Концепция flow-based programming подходит для решения широкого спектра задач: от прогноза продаж и оценки качества обслуживания до поиска причин оттока клиентов. Для поиска и подготовки данных в SAP есть два инструмента. Первый — SAP Data Intelligence для специалистов по анализу данных. В отличие от аналогичных платформ это решение работает с распределенными данными и не требует их централизации — дает единую среду для реализации, публикации, интеграции, масштабирования и поддержки моделей. Второе инструмент — SAP Agile Data Preparation — небольшой сервис для подготовки данных, ориентированный на аналитиков и бизнес-пользователей. У него простой интерфейс, который помогает собрать дата-сет, отфильтровать, обработать и сопоставить информацию. Её можно опубликовать в витрину для передачи Self-Service BI — системам самообслуживания для создания аналитических сценариев (они не требуют глубоких знаний в области data science).

Создание моделей

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

Исследование и прототипирование. На текущий момент доступно множество тематических фреймворков и библиотек. Лидируют по частоте использования TensorFlow и PyTorch, популярность которого за прошедший год выросла на 243%. Платформа SAP позволяет задействовать любой из таких фреймворков и может гибко дополняться библиотеками, такими как CatBoost от «Яндекса», LightGBM от Microsoft, scikit-learn и pandas. Еще можно использовать HANA DataFrame в библиотеке hanaml. Этот API мимикрирует под pandas, а HANA позволяет обрабатывать большие объемы данных с помощью «ленивых вычислений».

Для прототипирования моделей мы предлагаем Jupyter Lab. Это — инструмент с открытым исходным кодом для data-science специалистов. Мы встроили его в экосистему SAP, параллельно расширив функциональность. Jupyter Lab работает в платформе Data Intelligence и за счет встроенной библиотеки sapdi может подключаться к любым источникам данных, подключенных на предыдущих шагах, мониторить эксперименты и метрики качества для их дальнейшего анализа.

Отдельно стоит отметить, что блокноты, датасеты, пайплайны обучения и инференса, а также сервисы для деплоя моделей должны быть консистентны. Для объединения всех этих объектов используют ML-сценарий (версионируемый объект).

Обучение моделей. Существует два варианта работы с ML-сценариями. Есть модели, которые вообще не нужно обучать. Например, в SAP Data Intelligence мы предлагаем системы распознавания лиц, автоматического перевода, OCR (optical character recognition) и другие. Все они работают «из коробки». С другой стороны — есть те модели, которые необходимо обучать и продуктивизировать. Это обучение может происходить как в самом кластере Data Intelligence, так и на внешних вычислительных ресурсах, которые подключаются только на время вычислений.

«Под капотом» в SAP Data Intelligence — платформа Kubernetes, поэтому все операторы привязаны к docker-контейнерам. Для работы с моделью достаточно описать docker-файл и привязать к нему тэги для используемых библиотек и версий.

Другой способ создания моделей — с помощью AutoML. Это автоматизированные системы МО. Такие инструменты разрабатывают H2O, Microsoft, Google и др. В этом направлении работают и в MIT. Но инженеры университета не фокусируются на встраивании и продуктивизации. В SAP также есть AutoML-система, которая делает упор на быстрый результат. Она работает в HANA и имеет прямой доступ к данным — их не нужно куда-то перемещать и модифицировать. Сейчас мы разрабатываем решение, которое фокусируется на качестве моделей — о релизе объявим позже.

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

Переиспользование компонентов на базе операторов в SAP Data Hub

Но версионировать и обновлять модели нужно еще и по мере выхода свежих алгоритмов и обновлений аппаратных компонентов. Их внедрение может повысить точность и качество используемых в работе моделей.

Insight-Driven для роста бизнеса

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

Узнайте больше о построении концепции Insight-Driven в нашей библиотеке полезных материалов по управлению данными, куда мы собрали видео, полезные брошюры и триал-доступы к системам SAP.

Источник

млопс: управление моделями, развертывание, журналы преобразований и мониторинг с помощью Машинное обучение Azure

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

Что собой представляет MLOps?

Управление машинным обучением (MLOps) основано на принципах и методиках DevOps, повышающих эффективность рабочих процессов. Например, непрерывная интеграция, поставка и развертывание. MLOps применяет эти принципы к процессу машинного обучения для следующего:

Машинное обучение Azure предоставляет следующие возможности MLOps:

Дополнительные сведения о MLOps см. в разделе DevOps — Машинное обучение (MLOps).

Создание воспроизводимых конвейеров машинного обучения

Используйте конвейеры машин из Машинного обучения Azure, чтобы объединить все шаги, связанные с процессом обучения модели.

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

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

Создание повторно используемых программных сред

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

Среды описывают зависимости PIP и Conda для проектов и могут использоваться как для обучения, так и для развертывания моделей. Дополнительные сведения см. в разделе Что такое среды машинного обучения Azure.

Регистрация, создание пакетов и развертывание моделей из любого места

Регистрация и отслеживание моделей машинного обучения

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

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

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

Можно также зарегистрировать модель, обученную вне машинного обучения Azure.

Удалить зарегистрированную модель нельзя, если она используется в любом активном развертывании. Дополнительные сведения см. в разделе «Регистрация модели» статьи Развертывание моделей с помощью Службы машинного обучения Azure.

При использовании параметра «Фильтровать по Tags » на странице «Модели» в Студии машинного обучения Azure вместо использования TagName : TagValue клиентам следует использовать TagName=TagValue (без пробела)

Профилирование моделей

Машинное обучение Azure поможет вам понять требования к ЦП и памяти службы, которая будет создана при развертывании модели. Профилирование проверяет службу, которая выполняет модель, и возвращает такие сведения, как загрузка ЦП, использование памяти и задержка ответа. Оно также предоставляет рекомендации по ЦП и памяти на основе использования ресурсов. Дополнительные сведения см. в разделе «Профилирование» раздела Развертывание моделей.

Модели упаковки и отладки

Перед развертыванием модели в рабочей среде она упаковывается в образ DOCKER. В большинстве случаев создание изображений происходит автоматически в фоновом режиме во время развертывания. Образ можно указать вручную.

При возникновении проблем с развертыванием можно выполнить развертывание в локальной среде разработки для устранения неполадок и отладки.

Преобразование и оптимизация моделей

Преобразование модели для открытия обмена нейронными сетями (ONNX) может повысить производительность. В среднем преобразование в ONNX может привести к увеличению производительности в 2 раза.

Дополнительные сведения об ONNX с Машинное обучение Azure см. в статье Создание и ускорение моделей ML.

Использование моделей

Обученные модели машинного обучения развертываются как веб-службы в облаке или локально. В развертываниях используются ЦП, GPU или программируемые для полей массивы шлюзов (FPGA). Модели также можно использовать из Power BI.

При использовании модели в качестве веб-службы вы предоставляете следующие элементы:

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

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

Пакетная оценка

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

Веб-службы в режиме реального времени

Вы можете использовать модели в веб-службах со следующими целевыми объектами вычислений:

Чтобы развернуть модель как веб-службу, необходимо предоставить следующие элементы:

Для получения дополнительных сведений см. раздел Модели развертывания.

Управляемое развертывание

При развертывании в службе Azure Kubernetes можно использовать управляемый выпуск, чтобы включить следующие сценарии:

Analytics

Microsoft Power BI поддерживает использование моделей машинного обучения для аналитики данных. Дополнительные сведения см. в статьеИнтеграция Машинного обучения Azure в Power BI (предварительная версия).

Сбор данных управления, необходимых для сбора комплексного жизненного цикла машинного обучения

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

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

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

Уведомлять, автоматизировать и оповещать о событиях в жизненном цикле машинного обучения

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

Мониторинг проблем процессов и машинного обучения

Мониторинг позволяет понять, какие данные отправляются в модель и какие прогнозы она возвращает.

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

Переобучение модели на новых данных

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

Нет универсального ответа на «Разделы справки узнать, следует ли переучить?» Однако ранее обсуждаемые средства для событий и мониторинга Azure ML являются хорошими отправными точками для автоматизации. После того как вы решили переучить, вам нужно:

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

Автоматизация жизненного цикла машинного обучения

Вы можете использовать GitHub и Azure Pipelines для создания процесса непрерывной интеграции, который обучает модель. В типичном сценарии, когда анализ данных проверяет изменение в репозитории Git для проекта, конвейер Azure начнет обучающий запуск. Затем результаты выполнения можно просмотреть, чтобы увидеть характеристики производительности обученной модели. Также можно создать конвейер, который развертывает модель как веб-службу.

Расширение машинного обучения Azure упрощает работу с Azure Pipelines. Он предоставляет следующие усовершенствования Azure Pipelines:

Дополнительные сведения об использовании Azure Pipelines с Машинным обучением Azure см. по следующим ссылкам:

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

Дальнейшие действия

Дополнительные сведения см. в следующих ресурсах:

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

Источник