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

TL;DR

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

Тема этого поста не столько о поиске лучшей модели для прогнозирования цен, сколько об использовании хранилища функций Feast и MLFlow для отслеживания проекта, рабочего процесса и регистрации модели для оптимизации и автоматизации сквозных операций. завершить жизненный цикл машинного обучения. Код доступен по адресу https://github.com/pahurlocker/crypto-price-prediction.

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

Краткое введение в Feast и MLFlow

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

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

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

От поиска данных к функциям модели

Подготовка данных и проектирование признаков — это первые шаги в жизненном цикле машинного обучения. Для начала нам сначала нужно извлечь исходные данные и сделать их доступными через наше хранилище функций. Ежедневные биткойн-данные извлекаются из API-интерфейсов Blockchain.com и Alpha Vantage и сохраняются в файлах паркета (код для этого находится в разделе data_producers). FileSource определяется для каждого файла паркета, чтобы сделать его доступным для Feast, как показано ниже. Обратите внимание, что для обоих источников файлов значение event_timestamp определено как поле timestamp_field, которое позже используется для объединения функций из разных источников с одной и той же меткой времени.

Для каждого FileSource создается FeatureView, содержащий схемы, которые будут использоваться для обучения модели и логического вывода. Сущности могут быть определены, если ваши данные имеют первичные ключи (например, идентификатор клиента, идентификатор транзакции и т. д.). Сущности используются в сочетании с метками времени для автоматического объединения данных и поиска в интернет-магазинах. В этом случае мы полагаемся исключительно на временную метку event_timestamp, чтобы объединить представления объектов вместе. Узнайте больше о представлениях объектов с сущностями и без них в документации Feast здесь.

FeatureService объединяет данные из двух определений FeatureView для поддержки обучения модели и логического вывода. Служба объектов обычно создается для каждой версии модели, что позволяет легко отслеживать функции, используемые каждой конкретной моделью. Определения FeatureView и FeatureService для этого проекта можно увидеть ниже.

Чтобы получить наши функции для обучения и вывода, мы используем get_historical_features из FeatureStore. При пакетной оценке функции извлекаются из офлайн-магазина тем же методом, что и при обучении (подробности см. в документах). В приведенном ниже коде (в разделе data_loaders) даты начала и окончания используются для определения диапазона дат для извлечения признаков. entity_df заполняется временными метками диапазона дат и передается в get_historical_features вместе с сервисом объектов, который определяет конкретные функции, которые будет использовать наша модель. Таким образом, для обоих используется один и тот же код извлечения признаков, нам просто нужно убедиться, что диапазон дат для обучения и вывода не перекрывается. Код также выполняет обучение, тестовое разделение для использования в обучении.

Команда для получения данных из внешних API приведена ниже (подробнее см. repo):

mlflow run . -e price-data-retrieve -P pull-data=True --env-manager=local

Команды для подготовки репозитория Feast приведены ниже (подробнее см. repo):

cd ./data/feature_repo
feast apply

Обучение модели с оптимизацией гиперпараметров

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

Интеграция обратного вызова Optuna/MLFlow используется, чтобы связать их вместе, читайте документы здесь. Обратите внимание на определение MLFlowCallback и @mlfc.track_in_mlflow() в целевой функции, используемой в приведенном ниже сокращенном коде оптимизатора. Вызов study.optimize передается обратному вызову mlfc, который автоматически фиксирует все ключевые метрики и параметры в отслеживании MLFlow. Существуют дополнительные метрики, параметры и модель для каждого запуска/испытания, которые явно перехватываются вызовами log_param, log_metric и log_model соответственно.

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

mlflow run . -P model_type='LSTM' -P n_trials=4 --env-manager=local --experiment-name="crypto-reg-experiment"

В приведенном ниже пользовательском интерфейсе MLFlow показаны сведения об одном запуске/пробной версии:

Регистрация модели и прогнозирование

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

В приведенном ниже коде используется MLFlowClient для подключения к серверу MLFlow, запроса результатов эксперимента для наименьшего MAPE, определения URI модели и регистрации модели под предоставленным именем модели (в данном случае биткойн-регрессия). Когда запускаются новые испытания и выбираются новые более эффективные модели для биткойн-регрессии, номер версии автоматически увеличивается. Позже я покажу, как мы получаем последнюю зарегистрированную модель и версию. Обратите внимание, что вы также можете сделать все это вручную в пользовательском интерфейсе MLFlow, но автоматизация в MLFlow действительно мощная!

Пользовательский интерфейс MLFlow теперь показывает зарегистрированную модель. Это лишь малая часть того, что можно сделать, например, вы также можете автоматизировать продвижение моделей в стадию или производство:

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

mlflow run . -e register-best-model -P model-name="bitcoin-regression" -P experiment-id="2" --env-manager=local

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

После извлечения и подготовки данных MLFlowClient используется для загрузки последней версии модели, как показано в приведенном ниже коде:

После загрузки последней версии модели данные масштабируются, выполняется прогнозирование, а результаты регистрируются в эксперименте как прогон. Для выполнения предсказания используется следующая команда (подробнее см. repo):

mlflow run . -e price-predict -P date-end="2023-01-02" -P registered-model-name="bitcoin-regression" -P timesteps=10 --env-manager=local

Заключение

Feast, MLFlow и Optuna, используемые вместе, действительно эффективны для управления функциями и моделями и оптимизации производительности моделей на протяжении всего жизненного цикла. Легко понять, как можно повысить производительность и воспроизводимость, когда вы начнете масштабировать команды, модели и функции данных. В этом посте Feast и MLFlow запускались локально, но они были разработаны для использования в крупномасштабных облачных средах. Их возможности упаковки и развертывания упрощают развертывание рабочих нагрузок на основе контейнеров. Они хорошо интегрируются в среду DevOps/MLOps, обеспечивая полную автоматизацию жизненного цикла машинного обучения. Вы также можете использовать своих облачных провайдеров и выбранные платформы данных (AWS, GCP, Azure, Databricks, Snowflake, Tecton и т. д.). Спасибо, что прочитали это, я, вероятно, рассмотрю аспекты развертывания в своем следующем посте из этой серии.