Наша платформа ML Ops значительно сокращает время разработки. Вот как.

Введение

Представьте, что в вашей организации есть хорошо функционирующая команда специалистов по обработке и анализу данных. Однако вы замечаете, что все большая и большая часть времени ваших специалистов по обработке и анализу данных тратится на развертывание и обслуживание модели в производственной среде. Кроме того, вы видите, что все больше инцидентов возникает из-за снижения производительности модели (например, из-за дрейфа данных), что требует от ваших специалистов по данным больше драгоценного времени для исправления. Это время, которое вы могли бы потратить на создание новых моделей и изучение новых вариантов использования. Каково решение? Автоматизация повторяющихся и трудоемких задач с помощью платформы Machine Learning Operations (ML Ops).

Так что же такое операции машинного обучения?

Термин операции машинного обучения описывает весь процесс создания и публикации моделей науки о данных. С платформой Machine Learning Operations цель состоит в том, чтобы стандартизировать и автоматизировать как можно больше шагов при создании моделей науки о данных и доведении их результатов до заинтересованных сторон.

Около 2 лет назад наша группа по обработке и анализу данных заметила первые признаки потери времени на разработку моделей обслуживания и мониторинга в производственной среде. Таким образом, мы начали наш путь к хорошо работающей платформе ML Ops. Мы начали с первоначального списка вопросов:

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

Проработав этот список вопросов, мы остановились на ACEmaker, нашей оболочке Python для AWS Sagemaker, которую мы используем для разработки, развертывания и обслуживания наших моделей машинного обучения. Он назван в честь нашей команды специалистов по обработке и анализу данных, Аналитического центра передового опыта (ACE). В этом блоге мы расскажем вам о том, почему мы решили создать ACEmaker, как он работает и что думают об этой платформе специалисты по данным из ACE.

Что нам нужно для развертывания и поддержки моделей машинного обучения в производственной среде?

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

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

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

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

На этапе Сопровождение мы хотим иметь возможность отслеживать производительность модели. Распределяются ли данные, которые мы используем для логического вывода, аналогично данным, которые мы использовали для обучения модели? Получаем ли мы аналогичную производительность модели или модель со временем работает хуже? Можем ли мы создать автоматические триггеры, указывающие, когда пора переобучить модель? Можем ли мы также увидеть, как модель пришла к предсказанию с помощью объяснимого ИИ?

Какая платформа может помочь нам достичь этих целей?

В наши дни существует множество решений для машинного обучения. Мы поэкспериментировали с некоторыми из них и в итоге решили использовать AWS SageMaker. Мы уже использовали AWS для хранения данных и наше предыдущее решение для развертывания модели, созданное по индивидуальному заказу, и нам понравилось, что оно очень гибкое и позволяет нам настраивать его в соответствии с нашими потребностями.

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

Хотя SageMaker предоставляет множество хороших инструментов, которые улучшают наш рабочий процесс обработки данных, мы столкнулись с заминкой: для того, чтобы все это заработало, по-прежнему требовалось много кода! Кроме того, для наших вариантов использования большая часть кода была шаблонной и могла быть автоматизирована. Поэтому мы решили разработать собственный стек на основе SageMaker, который позволит нам дополнительно автоматизировать и улучшить рабочий процесс обработки данных. В 2021 и 2022 годах мы начали работать над нашим решением. Введите: платформа ACE ML Ops.

Платформа ACE ML Ops состоит из двух частей: «внешней» части, называемой ACEmaker, и «внутренней» части, называемой стеком платформы.

Интерфейс: ACEmaker

Чтобы облегчить процесс разработки, обучения, развертывания и мониторинга модели, мы создали оболочку для SageMaker. Поскольку мы в основном используем Python для всей работы по обработке и анализу данных в ACE, мы создали эту оболочку в виде пакета Python. Он абстрагирует большую часть шаблонного кода, который вам обычно приходится писать для использования Sagemaker.

При использовании ACEmaker наши специалисты по данным разбивают свой код на отдельные функции, которые следуют ключевым частям рабочего процесса обработки данных: извлечение данных, обработка данных, проверка данных, обучение модели, настройка модели и вывод. Это позволяет выполнять каждую часть в контейнере. Другими словами, каждая часть разделена кодом и независимо запускается в Sagemaker через контейнеры Docker. Чтобы проверить это во время разработки, мы используем скрипт Python с именем run_components.py, с помощью которого вы можете вызывать каждую из функций. Вы указываете имя функции, какие у нее требования к пакету и (при необходимости) какой тип экземпляра вы хотите использовать.

def preprocess_data(traffic_df): 

    """Go through several preprocessing steps and return a train and test set 

    Returns: 
        dict: containing a train set and a test set as pd.DataFrames (values)  
              and their respective names (keys) 
    """ 

    traffic_df = clean_traffic_data(traffic_df)
    traffic_df = filter_frequencies(traffic_df) 
    traffic_df = create_target(traffic_df) 
    traffic_df = filter_traffic_data(traffic_df) 
    traffic_df = create_features(traffic_df) 
    traffic_df = clean_column_names(traffic_df) 
    train, test, val = train_test_split(traffic_df) 
      
    return {'train': train, 'test': test, 'val': val} 

## In run_components.py; used during testing 

# Preprocessing 
processing_step = project.data_processing(
                              'functions/data_processing.py:preprocess_data', 
                              input_data='s3://xxxxxxx/xx/output', 
                              run_mode='cloud', 
                              instance_type='ml.m4.10xlarge', 
                              requirements=['pandas==1.5.0', 'numpy==1.23.3', 
                                            'scipy==1.9.1', 'pytz==2022.4']) 

После того, как вы успешно закончили написание кода для различных шагов, вы можете превратить свои компоненты в конвейер. Вы делаете это, создавая файл .yml, описывающий, как будет выглядеть конвейер. Это очень похоже на run_components.py, но в формате .yml. Этот файл YAML используется для репликации конвейера в среде preprod (а затем и в prod).

## In pipeline_config.yml, used during automatic deployment 
## As you can see, very similar to the python version, just in YAML format 
## Here we show the processing step, of course have more steps
## Each step is chained to each other in a specific order to make it work

pipeline-steps: 
    ... 
    processing-step: 
        type: "Data processing" 
        function: "functions/data_processing.py:preprocess_data" 
        input_data:
          - extract-step.output_data_location 
        requirements: 
          - "pandas==1.5.0" 
          - "numpy==1.23.3" 
          - "scipy==1.9.1" 
          - "pytz==2022.4" 
        instance_type: "ml.m4.10xlarge" 
    ...

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

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

Серверная часть: стек платформы ACE

Как следует из названия, стек платформы — это наше решение «инфраструктура как код» для создания и обслуживания серверной части AWS, в которой разрабатываются, обучаются, развертываются и обслуживаются наши модели. Проще говоря: эта часть содержит код, который используется для сборки и настройки наших ресурсов в облаке. Помимо работы с AWS, мы также используем GitLab как для управления версиями, так и для CI/CD. Стек платформы содержит код, благодаря которому наша среда GitLab работает с AWS через GitLab Runner. Подробнее об этом позже, давайте сначала поговорим о создании облачных ресурсов.

CDK

Мы используем AWS CDK (Cloud Development Kit) для создания инфраструктурной части нашей облачной платформы. Это означает указание, какие ресурсы (такие как хранилище или вычислительные ресурсы) нам нужны и как их нужно настроить. Он также включает в себя настройку необходимых прав и политик, чтобы убедиться, что все в безопасности. Мы используем CDK, импортируя его как пакет в Python и импортируя готовые конструкции, которые представляют собой готовые комбинации ресурсов в AWS. У вас есть разные уровни конструкций, каждый со своими возможностями настройки. Вы можете использовать это, например, для автоматического создания корзины S3, ограничивая при этом объем необходимых настроек. Взгляните, например, на следующий фрагмент кода:

from aws_cdk import App 
from stacks.s3_object_lambda_stack import S3ObjectLambdaStack 

app = App() 
S3ObjectLambdaStack(app, "S3ObjectLambdaExample") 
app.synth() 

# (code snippet from https://github.com/aws-samples/aws-cdk-examples/)

Как видите, для создания новой корзины S3 требуется всего несколько строк кода. Если вы хотите что-то изменить в конфигурации, вы просто меняете код и повторно развертываете его с помощью командной строки. Об остальном позаботится AWS. Легко, верно?

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

Итак, из чего именно состоит бэкэнд? И как мы используем CDK для его сборки? Мы будем следовать четырем этапам разработки, упомянутым ранее, начиная с этапа Дизайн.

Начнем с SageMaker Studio. Это среда, в которой специалисты по данным могут взаимодействовать с AWS SageMaker. Проще говоря, это IDE для машинного обучения в облаке. Это принимает форму расширенной лабораторной среды Jupyter. В SageMaker специалисты по обработке и анализу данных могут писать код в Jupyter Notebooks, получать доступ к реестру моделей, проверять, успешно ли выполнялись конвейеры их моделей, и многое другое. Именно здесь наши специалисты по данным импортируют ACEmaker и пишут свой код для обработки данных. Мы также только что завершили интеграцию Visual Studio Code Server в Sagemaker Studio в качестве альтернативной среды разработки, что показывает, почему важно выбрать гибкую платформу для создания инструментов ML Ops.

Чтобы облегчить обучение и тестирование моделей, разработанных в SageMaker Studio, мы используем SageMaker Pipelines и SageMaker Experiments. Sagemaker Pipelines автоматизирует этапы рабочего процесса машинного обучения, такие как загрузка и преобразование данных, передавая их в модель для обучения и настройки гиперпараметров. Мы используем код, написанный в ACEmaker, для дальнейшей автоматизации этого процесса путем автоматического создания конвейеров. После создания этих конвейеров мы можем использовать их для экспериментов с различными типами моделей, функциями данных и т. д., просто изменяя код, отправляя его и перезапуская конвейер. SageMaker автоматически отслеживает эти эксперименты, позволяя нам анализировать наши эксперименты структурированным образом и как можно быстрее получать лучшую модель. После выполнения этого шага модель регистрируется в реестре моделей, что позволяет нам отслеживать все готовые модели.

После того, как мы закончили экспериментировать с различными моделями и нашли лучшую конфигурацию модели, пришло время развернуть ее в среде разработки! Мы используем Lambdas для создания конечных точек SageMaker, шлюзов API и расписания мониторинга модели, и все это основано на настройках, установленных в исходном коде ACEmaker.

Затем мы можем мониторить модель и конвейер обслуживания в SageMaker Studio с помощью SageMaker Monitoring. Мы можем просматривать журналы через CloudWatch.

После того, как мы будем довольны моделью в нашей среде разработки, мы можем автоматически развернуть модель в preprod. Это делается простым нажатием кнопки в среде GitLab. Затем будут воссозданы конвейеры, обучена последняя модель и зарегистрирована в реестре моделей SageMaker (после утверждения специалистом по данным) и, наконец, созданы конечные точки. Затем мы можем проверить, работает ли конечная точка модели с системами наших заинтересованных сторон, и, если все в порядке, выполнить повторное развертывание в нашей производственной среде с помощью того же процесса.

GitLab

Как упоминалось пару раз ранее, мы используем GitLab для нашего контроля версий и CI/CD. Для взаимодействия с AWS из нашей среды GitLab мы используем GitLab Runners. Это приложения, которые могут выполнять конвейерные задания GitLab в нашей среде AWS. Мы используем их для запуска команд CDK для (повторного) развертывания определенных частей нашей среды на основе изменений, внесенных в код. Эти команды CDK запускаются в AWS исполнителем GitLab в экземпляре EC2. Итак, все, что нужно сделать специалисту по данным или инженеру, — это нажать кнопку в GitLab, а об остальном позаботится бегун.

Что думают наши специалисты по данным?

В ANWB мы прилагаем все усилия, чтобы информировать наших членов о состоянии движения на дорогах Нидерландов (ссылка для справки). Как правило, мы сообщаем о текущих пробках, включая ожидаемые задержки. Мы также заранее советуем, когда ожидаются редкие обстоятельства, например, суровые погодные условия в ближайшие дни.

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

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

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

Кое что для тебя?

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

Авторы: Рамон Пьетернелла (специалист по данным, инженер по машинному обучению) и Прашанд Рамесар (специалист по данным).