MLOps: создание цепочек непрерывного обучения и доставки

Что вы узнаете

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

Обзор истоков и целей движения MLOps;
Введение в несколько ключевых концепций MLOps;
Учебное пособие по настройке конвейера машинного обучения непрерывного обучения / непрерывной доставки (CT / CD) с помощью действий GitHub и облачных функций Google.

Раздел руководства предназначен для использования бесплатных (или почти бесплатных) сервисов, поэтому выполнение инструкций должно стоить вам не более нескольких копеек. Если вы работаете над MVP и вам нужна определенная инфраструктура машинного обучения, но вы хотите избежать затрат и технических накладных расходов, связанных с развертыванием AWS SageMaker или Azure ML, этот пример также может оказаться полезным. Наконец, если вы заинтересованы в понимании того, как учебник сочетается друг с другом, чтобы выполнять его от начала до конца, вам следует проверить предыдущий пост в этой серии о развертывании облегченных моделей машинного обучения в качестве бессерверных функций.

Как всегда, для тех, кто хочет застрять в коде, просмотрите файл рабочих процессов GitHub (.github/workflows/pipeline.yml) здесь:

markdouthwaite / serverless-scikit-learn-demo
Репозиторий, содержащий демонстрационный код для развертывания облегченного конвейера машинного обучения на основе Scikit-Learn, моделирующего сердечные заболевания… github.com

Если вы знаете, что такое ML Ops, и просто хотите следовать руководству, пропустите его.

Что такое MLOps?

Примерно за последнее десятилетие движение, широко известное как «DevOps», приобрело значительных профессиональных последователей в мире разработки программного обеспечения, при этом большое количество специальных ролей DevOps возникло в командах разработчиков по всему миру. Мотивация для этого движения состоит в том, чтобы объединить аспекты разработки программного обеспечения (Dev) с элементами операционной деятельности (Ops) программного обеспечения с целью ускорения доставки надежного, работающего программного обеспечения на постоянной основе.

Основное внимание сторонников движения DevOps уделяется созданию и поддержке конвейеров непрерывной интеграции и непрерывной доставки (CI / CD). На практике хорошо спроектированные и четко реализованные конвейеры CI / CD предлагают командам, использующим их, возможность непрерывно изменять свою программную систему, чтобы (в принципе) значительно сократить время окупаемости новых программных исправлений и функций, одновременно сводя к минимуму риск обратная сторона от ошибок и сбоев, связанных с выпуском этих исправлений и функций. Команды, использующие зрелые реализации этого механизма доставки, часто выпускают обновления ежечасно (или быстрее!) С возможностью быстрого и чистого отката изменений, если они вносят ошибку (хотя большинство из этих следует где-то обнаруживать в конвейере).

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

Как это связано с машинным обучением?

В этот момент вы вполне можете подумать: «Это все хорошо, но как это связано с машинным обучением?». Подобно успешным коммерческим программным продуктам, успешные коммерческие проекты машинного обучения (ML) требуют, чтобы пользователи сервиса ML доверяли достоверности и стабильности услуги, которые они потребляют. Важно отметить, что это должно происходить на постоянной основе - возможно, в течение многих лет.

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

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

Вот где приходит на помощь MLOps. Это зарождающееся движение можно рассматривать как надмножество DevOps-движения: оно направлено на ускорение предоставления надежного, работающего программного обеспечения ML на постоянной основе. Поэтому он занимается конвейерами CI / CD во многом так же, как DevOps, но также добавляет конкретные варианты этих проблем CI / CD. В частности, к этому добавлена концепция непрерывного обучения (CT). Что такое КТ, спросите вы?

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

Начиная

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

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

Это признание привело к расцвету экосистемы вокруг многих проблем, описанных выше. Каждый месяц появляются новые инструменты и платформы, специально предназначенные для решения задач ML / MLOps. Как и в случае с более широкой экосистемой разработки программного обеспечения, инструментальная цепочка машинного обучения превращается в товар: барьеры для входа (стоимость, опыт) постепенно снижаются, а рынок становится более конкурентоспособным. Для тех из вас, кто хочет начать работу с MLOps (или ML в целом), это становится очень захватывающим временем для участия: вы можете пройти долгий путь к тому, чтобы «Готовые к производству» трубопроводы ML по очень низкой цене. Вот как.

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

Хорошо, пора приступить к уроку!

Представленный здесь конвейер машинного обучения построен с использованием GitHub Actions - инструмента автоматизации рабочего процесса GitHub. Если вы зарегистрируетесь в учетной записи GitHub, вы получите доступ к этой функции бесплатно. Существуют ограничения на использование и ресурсы (как и следовало ожидать), но они удивительно щедры в качестве бесплатного предложения. Если вы можете сделать свои модели относительно легкими, вы можете создать небольшой продукт поверх бесплатного предложения, так что для тех из вас, у кого есть интересные идеи MVP, это может быть отличным местом для начала. Кроме того, если бесплатные ресурсы вас не устраивают, вы также можете создавать« самостоятельные действия».

Итак, что будет делать представленный здесь пример конвейера? Конвейер будет базовым конвейером CT / CD, построенным на примере бессерверного машинного обучения, который обсуждался в предыдущем посте. Если вы еще не читали, стоит проверить:

Бессерверное машинное обучение: масштабное развертывание облегченных моделей
Внедрение моделей машинного обучения« в производство в виде масштабируемых API может оказаться сложной задачей. В этом посте рассматривается один из вариантов создания модели… todatascience.com » e

В частности, трубопровод будет:

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

Кроме того, вы увидите, как можно запланировать выполнение этого рабочего процесса на регулярной основе как cron задание (снова с помощью GitHub Actions).

Прежде чем вы начнете

Если вы хотите запустить конвейер (и пример кода), вам необходимо зарегистрировать учетную запись Google Cloud. На момент написания на ваш счет будет добавлено 300 долларов США. Это больше, чем покрывает расходы на запуск кода, описанного в этом руководстве (в любом случае, это будет практически бесплатно!). Вы можете узнать больше здесь:

Уровень бесплатного пользования GCP - бесплатные расширенные пробные версии и всегда бесплатно | Google Cloud
Более 20 бесплатных продуктов Получите бесплатный практический опыт работы с популярными продуктами, включая Compute Engine и Cloud Storage, вплоть до… cloud.google.com

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

GCP_PROJECT_ID - уникальный идентификатор проекта Google Cloud. Вы можете найти свой идентификатор проекта в Google Cloud Console. Google предоставляет документ для поиска этого значения, если вы не уверены.
GCP_SA_KEY - ключ учетной записи службы (SA). Это безопасный ключ, который дает доступ к определенным облачным сервисам в вашем проекте. В этом примере для простоты вы будете использовать SA по умолчанию с повышенными привилегиями. На практике вам следует подумать о создании SA с ограниченными привилегиями. Вам нужно будет создать новый ключ для вашей SA и скопировать его в качестве секрета на GitHub. Опять же: У Google есть подробный документ о том, как сгенерировать этот ключ.

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

После их настройки вам нужно будет активировать Google Cloud Build, Cloud Functions и Cloud Storage API. Для этого просто просмотрите левую панель навигации в Google Cloud Console и выберите соответствующие облачные сервисы. Если соответствующий API не активирован, вам будет предоставлена возможность активировать его, когда вы нажмете на услугу.

Наконец, в приведенном ниже определении конвейера вам нужно будет указать уникальное имя сегмента в вашем облачном хранилище Google. В примере определения конвейера (ниже) используется имя pipeline-example. Вы должны заменить это имя своей собственной корзины после разветвления, но до попытки запустить пример. Кроме того, вы захотите загрузить набор данных datasets/default.csv из репозитория в {your-bucket-name}/heart-disease/dataset.csv.

Теперь, хорошо это или плохо, настало время для YAML - языка облака.

Определение трубопровода

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

0. Настройка и планирование работ

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

В случае push конвейер будет запускаться каждый раз, когда вы обновляете ветку master репозитория (конкретные ветки могут быть перечислены в поле branches). Практически это означает, что каждый раз, когда вы объединяете изменение кода в репозитории с master, конвейер будет повторно обучать модель и повторно развертывать ее. Это может быть полезно для немедленного распространения изменений кода в действующую службу машинного обучения.

Для триггера schedule вы просто устанавливаете cron расписание, по которому будет работать ваш конвейер. Другими словами: фиксированное расписание, по которому будет работать ваш конвейер. Приведенный ниже пример значения будет запускать конвейер каждое утро буднего дня в 08:00. Если вы не знаете, как настроить cron расписание, вот отличный интерактивный редактор, с которым вы можете поиграть.

name: Train and Deploy

on:
  push:
    branches:
      - master
  schedule:
    - cron:  '0 8 * * MON-FRI'

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

1. Настройка среды

Теперь о скучном, но очень важном шаге. Ключ train определяет имя шага. Здесь у вас разовая работа. В нем вы должны определить виртуальную машину, на которой вы собираетесь запускать свое задание (runs-on). В этом случае в примере используется ubuntu-latest. Затем вы определяете каждый из steps в задании.

Сначала запускается actions/checkout@v2. Это запускает действие checkout, предоставленное GitHub. Это клонирует и проверяет ветку по умолчанию (обычно master) вашего репозитория.

Затем задание устанавливает gcloud инструмент командной строки. На этом шаге используется действие, предоставляемое Google Cloud, чтобы немного облегчить вашу жизнь. Это позволяет на последующих этапах получить доступ к инструментам командной строки gcloud и gsutils. Вы будете использовать их позже, чтобы загружать / выгружать данные из / в Google Cloud и повторно развертывать API вашей модели.

После этого у вас есть два связанных с Python шага. Первый устанавливает базовую среду Python 3.7. Второй устанавливает все зависимости, которые у вас есть в файле верхнего уровня requirements.txt. И с этим ваша работа настроена для правильного запуска вашего конвейера. Теперь самое интересное.

train:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2

    - name: Setup GCP client
      uses: GoogleCloudPlatform/github-actions/setup-gcloud@master
      with:
        version: '290.0.1'
        project_id: ${{ secrets.GCP_PROJECT_ID }}
        service_account_key: ${{ secrets.GCP_SA_KEY }}
        export_default_credentials: true
    
    - name: Set up Python
      uses: actions/setup-python@v2
      with:
        python-version: 3.7
    
    - name: Install Python dependencies
      run: |
        python -m pip install --upgrade pip
        pip install -r requirements.txt

Обратите внимание, что клавиша run позволяет выполнять команды в оболочке виртуальной машины - в данном случае оболочке Ubuntu по умолчанию.

2. Скачать набор данных

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

- name: Download the latest dataset
      run: |
        gsutil cp gs://pipeline-example/heart-disease/dataset.csv datasets/default.csv

Вы увидите, что на этом шаге используется gsutil, Утилита командной строки Cloud Storage от Google. Это позволяет копировать файлы в Google Cloud и из него. Простой!

3. Обучите и оцените модель.

Теперь, когда задание загрузило последний набор данных, пора запустить основное учебное задание. В данном случае это идентично примеру, приведенному в предыдущем руководстве Serverless ML.

- name: Run training task
      run: |
        python steps/train.py --path=datasets/default.csv

В качестве бонуса сценарий steps/train.py записывает следующие метаданные и показатели в путь artifacts/metrics.json. Как вы увидите, это тоже загружается в Google Cloud, чтобы вы могли видеть, как производительность модели (и продолжительность обучения) меняется с течением времени. Это может очень пригодиться!

metrics = dict(
    elapsed = end - start,
    acc = acc,
    val_acc = val_acc,
    roc_auc = roc_auc,
    timestamp = datetime.now().strftime(TIMESTAMP_FMT)
)

Вновь обученная модель записывается в artifacts/pipeline.joblib. Это также будет загружено в Google Cloud для архивирования.

4. Загрузить модель и показатели.

Следующим шагом будет размещение вашей новой модели и показателей в Google Cloud Storage. Вы увидите, что конвейер загружает три файла:

latest.joblib - «последняя» версия модели. Это будет самая последняя «действительная» модель, созданная конвейером.
${{ env.GITHUB_RUN_ID }}.joblib - Заархивированная версия указанной выше модели (идентифицируется уникальным идентификатором запуска GitHub, который ее создал).
metrics/${{ env.GITHUB_RUN_ID }}.json - заархивированная версия показателей указанной выше модели (идентифицируется уникальным идентификатором запуска GitHub, который ее создал). Их можно упорядочить по дате создания, чтобы получить временной ряд, показывающий производительность модели во времени.

- name: Upload new model and associated metrics
      run: |
        gsutil cp artifacts/pipeline.joblib gs://pipeline-example/heart-disease/models/latest.joblib
        gsutil cp artifacts/pipeline.joblib gs://pipeline-example/heart-disease/models/${{ env.GITHUB_RUN_ID }}.joblib
        gsutil cp artifacts/metrics.json gs://pipeline-example/heart-disease/models/metrics/${{ env.GITHUB_RUN_ID }}.joblib

Теперь у вас есть новая модель, некоторые показатели и все это аккуратно заархивировано в Google Cloud Storage.

5. Повторно развернуть облачную функцию

Наконец, когда все сделано, пришло время повторно использовать вашу последнюю модель.

- name: Deploy model as Cloud Function
      run: | 
        gcloud functions deploy heart-disease --entry-point=predict_handler --runtime=python37 --project=${{ secrets.GCP_PROJECT_ID }} --allow-unauthenticated --trigger-http

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

Заканчивать

И это все. Если ваш конвейер завершится успешно, вы увидите красивый длинный список зеленых галочек для каждого успешного шага.

Теперь у вас есть автоматизированный конвейер для загрузки новых данных, переобучения модели, архивирования новой модели и ее показателей, а затем повторного развертывания API вашей модели по фиксированному графику. Довольно круто, а?

Следующие шаги

Это всего лишь доработка машинного обучения для младенцев. Вы можете многое сделать, чтобы сделать его более сложным. Некоторые исходные идеи могут быть такими:

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

Если у вас возникнут проблемы с работой примера, свяжитесь с нами!

дальнейшее чтение

Если вы хотите узнать больше о MLOps, вот несколько ссылок, которые могут вас заинтересовать:

Первоначально опубликовано на https://mark.douthwaite.io.