Конвейер — это описание рабочего процесса машинного обучения (ML), включая все "компоненты" в рабочем процессе и то, как эти компоненты соотносятся друг с другом в виде "графика".

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

Случаи использования

  1. Обучение/экспериментирование с обучающим скриптом, набором входных данных и фиксированными гиперпараметрами
  2. Развертывание модели, обновление существующего развертывания новой моделью
  3. Оценка/валидация модели (моделей), обученной в описанном выше варианте использования (1), или предварительно обученной модели.
  4. Настройка гиперпараметров
  5. Дополнительное обучение
  6. Мониторинг модели

Давайте рассмотрим некоторые из этих вариантов использования и разберемся с задействованными компонентами.

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

Этапы обучения (как показано на рисунке )

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

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

Чтобы сделать рабочие процессы обучения воспроизводимыми и согласованными между запусками, нам нужно было зафиксировать вышеуказанные компоненты. Итак, мы решили управлять версиями наборов данных с помощью DVC вместо обычных систем S3/File, тогда как обучающие скрипты и гиперпараметры управляются с помощью Git.

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

Второй вариант использования — развертывание модели

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

Обычно для развертывания модели требуется:

  1. Файлы моделей — модель сериализуется в файлы .bin, .pkl или .zip и хранится в файловой системе/S3 и т. д.
  2. Wrapper — код для загрузки модели в память и вызова ее функций прогнозирования путем предоставления данных в ожидаемом формате.
  3. Дополнительные модули — эти модули/файлы Python используются кодом-оболочкой, например. управлять фреймворком данных, моделью загрузки и другими утилитами
  4. Пакеты — это стандартные библиотеки, используемые оболочкой. Например. трансформаторы, факел, NumPy и т. д.

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

  1. Клонируйте репозиторий, содержащий дескриптор развертывания и вышеупомянутые артефакты.
  2. Сборка — на этом этапе происходит сборка оболочки, модулей, пакетов Python и обученной модели в пакет развертывания.
  3. Сборка образа модели — на этом этапе берется пакет развертывания из приведенного выше, сшивается все вместе и запекается образ докера, который можно запускать где угодно, а также предоставляются стандартные конечные точки отдыха для запуска вывода по модели.
  4. Развертывание модели — на этом этапе используется Kubeflow KFServe для развертывания образа докера модели в качестве службы логического вывода и автоматически предоставляется модель как служба через балансировщик нагрузки.

Больше вариантов использования — я предпочитаю не делать это исчерпывающим, поэтому оставшиеся варианты использования должны быть подробно описаны в отдельной статье.

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

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

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

Не стесняйтесь оставлять отзывы/задавать вопросы в комментариях ниже, и помогите мне сделать это более информативным.

В следующей части я познакомлю вас с Orchestrator для Kubeflow Pipelines, настройкой аутентификации (SSO) для Kubeflow и соберу Istio, Dex и Cognito.