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

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

Традиционный подход

Наиболее распространенная практика, которую я видел в различных проектах и ​​организациях, как правило, такова:

Для проведения всех экспериментов, необходимых для исследования данных, настройки модели, инструменты или платформы, такие как Jupyter Notebook, блокноты Databricks и другие, используются специалистами по обработке и анализу данных после того, как модель обучена, преобразована с правильными параметрами и сохранена в виде артефакта (например, pickle), код фиксируется в репозитории git, и начинается работа по обработке данных.

с этого момента инженер данных должен:

  • Создайте конвейер данных, создав сценарии обучения и автоматизации (train.py и predict.py).
  • Разработайте стратегию развертывания, например архитектуру микросервисов с различными сервисами: вывод, подготовка данных…
  • Создайте конвейер CI/CD с правильными тестами автоматизации на основе машинного обучения.
  • Мониторинг проектной модели для отслеживания изменений концепций
  • Подберите аппаратное обеспечение, необходимое для проведения логического вывода и обучения.

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

Новый подход

Идея этого поста — продемонстрировать пример упрощенного развертывания и обучения машинному обучению с использованием комбинации двух платформ машинного обучения: Kedro и cortex.dev с минимальным объемом кода.

Что такое Кедро? Kedro — это платформа Python с открытым исходным кодом для создания воспроизводимого, поддерживаемого и модульного кода для обработки данных. Он заимствует концепции из разработки программного обеспечения и применяет их к коду машинного обучения; прикладные концепции включают модульность, разделение задач и управление версиями.

Что такое Cortex? Cortex — это платформа с открытым исходным кодом для крупномасштабных рабочих нагрузок логического вывода. Она имеет следующие возможности: Поддерживает развертывание TensorFlow, PyTorch и других моделей в виде API-интерфейсов в реальном времени или пакетных операций.
Обеспечивает высокую доступность с зонами доступности и автоматическим перезапуском экземпляров.< br /> Выполняет вывод на инстансах по запросу или спотовых инстансах с резервными копиями по запросу.
Автоматическое масштабирование для обработки производственных рабочих нагрузок с поддержкой избыточного выделения ресурсов.

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

  • Перенесите построение конвейера данных на сторону науки о данных (кедро)
  • Параметризация обучения модели с помощью внешних входных данных, таких как: разделение данных обучения/тестирования, используемые алгоритмы, скорость обучения, эпохи (кедро)
  • Познакомить с понятием узлы, конвейеры и каталоги данных (кедро).
  • Стандартизация выходных/входных данных узлов и сохранение результатов (кедро)
  • Гарантия масштабируемости и воспроизводимости: легко повторно использовать узлы и конвейеры для новых источников данных для создания моделей, специфичных для аналогичного бизнес-подразделения (кедро).
  • Проектирование и создание инфраструктуры логических выводов (кора головного мозга)
  • Гибкость для создания конечных точек пакетного или реального времени API ( cortex )
  • упростить управление зависимостями ( cortex & kedro )

новая архитектура будет выглядеть примерно так:

Одной из особенностей Kedro является разбиение шагов ML на узлы и пайплайны, как правило, существует

Конвейер Data Engineering: для обработки данных, извлечения признаков, нормализации, кодирования…

Конвейер Data Science: разделение данных на обучающие и тестовые наборы, разработка моделей, оценка

Cortex, с другой стороны, заботится о создании и развертывании модели, созданной конвейером Kedro, с использованием оператора cortex. Он создает кластер kubernetes либо в AWS, либо в GCP, используя простой файл описания инфраструктуры:

region: us-east-1
instance_type: t2.medium
min_instances: 5
max_instances: 10
spot: true

он также создает балансировщик нагрузки для распределения выводов по всем узлам кластера и шлюз API для обслуживания ответов API.

Пример: продолжительность поездки на такси в Нью-Йорке.

Я буду использовать набор данных kaggle, который имеет следующую структуру данных:

мы стремимся создать модель, которая будет прогнозировать продолжительность поездки на основе других входных данных, таких как дата посадки, место посадки (долгота-широта), место высадки и т. д.

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

Создание узлов и конвейеров

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

в нашем случае узел будет представлять такие задачи, как:

  • извлечение признаков: час дня, день месяца, месяц года
  • Разделить данные: обучающие и тестовые наборы
  • train model: обучение с использованием lightgbm
  • оценка модели: расчет показателей

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

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

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

ny_cab_trip_duration_kedro_training$ Kedro run
2021-01-19 19:35:43,309 - kedro.io.data_catalog - INFO - Loading data from `trips_train` (CSVDataSet)...
2021-01-19 19:35:46,316 - kedro.pipeline.node - INFO - Running node: extract_features: extract_features([trips_train]) -> [extract_features]
2021-01-19 19:36:24,834 - numexpr.utils - INFO - Note: NumExpr detected 12 cores but "NUMEXPR_MAX_THREADS" not set, so enforcing safe limit of 8.
2021-01-19 19:36:24,834 - numexpr.utils - INFO - NumExpr defaulting to 8 threads.
2021-01-19 19:39:27,635 - kedro.io.data_catalog - INFO - Saving data

Это запустит все узлы, описанные выше, и сгенерирует файл модели:

Развертывание модели с помощью Cortex

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

  • Создайте кластер облачного развертывания
  • Разверните модель

Создайте облачный кластер Kubernetes:

$cortex cluster  up -c  basic-cluster.yaml --aws-key AKIA3KH6IPR6WOSYNHVU --aws-secret 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
￮ creating a new s3 bucket: cortex-6a2d11117c ✓
￮ creating a new cloudwatch log group: cortex ✓
￮ creating cloudwatch dashboard: cortex ✓
￮ creating api gateway: cortex ✓
￮ spinning up the cluster (this will take about 15 minutes) ...

В конце выполнения:

[✔]  EKS cluster "cortex" in "us-east-1" region is ready
￮ updating cluster configuration ✓
￮ configuring networking (this might take a few minutes) ✓
￮ configuring autoscaling ✓
￮ configuring logging ✓
￮ configuring metrics ✓
￮ starting operator ✓
￮ waiting for load balancers ............................................................................ ✓
￮ downloading docker images ✓
cortex is ready!
operator:          a1bcbfeb26cef442e92bbcd0daffbf42-01a64d913ebbf7b6.elb.us-east-1.amazonaws.com
api load balancer: a8e87f75709de4e96bbc3871b8ef9ceb-a6ec41dfe22e0c12.elb.us-east-1.amazonaws.com
api gateway:       https://g06o0hssmj.execute-api.us-east-1.amazonaws.com

Развертывание модели

Примечание. Я скопировал модель, созданную конвейером Kedro, в S3 в s3://cortex-6a2d11117c/tmp/.

Сначала мы создаем описательный YAML модели:

- name: trip-estimator
  kind: RealtimeAPI
  predictor:
    type: python
    path: predictor.py
    config:
      model: s3://cortex-6a2d11117c/tmp/
  monitoring:
    model_type: regression

Развернуть его так же просто, как:

cortex-trip-estimator$ cortex deploy trip_estimator.yaml
using aws environment
updating trip-estimator (RealtimeAPI)
cortex get                  (show api statuses)
cortex get trip-estimator   (show api info)
cortex logs trip-estimator  (stream api logs)

Чтобы убедиться, что API развернут:

cortex get
env   realtime api     status   up-to-date   requested   last update   avg request   2XX
aws   trip-estimator   live     1            1           12m16s        -             -

Использование API

Я создал небольшой скрипт для тестирования API:

import requests
endpoint = "https://g06o0hssmj.execute-api.us-east-1.amazonaws.com/trip-estimator"
payload = {
    "input1":2.0,
    "input2":6.0,
    "input3":-73.96147155761719,
    "input5":40.774391174316406,
    "input6":-73.9537124633789,
    "input7":40.77536010742188,
    "input8":0.6621858468807331,
    "input9":0.007819358973817251,
    "input10":0.007788946222373263,
    "input11":6.0,
    "input12":23.0,
    "input13":33.0,
    "input14":0.0,
    "input15":3.0,
    "input16":0.0,
    "input17":0.0
}
prediction = requests.post(endpoint, payload)
trip_duration = str(prediction.content,'utf-8')
print("Trip duration is : ", trip_duration)

Запустите скрипт:

python consume.py

и вуаля!

cortex-trip-estimator$ python consume.py
Trip duration is :  5.252568735167378

Вывод

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

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