Конвейер — это описание рабочего процесса машинного обучения (ML), включая все "компоненты" в рабочем процессе и то, как эти компоненты соотносятся друг с другом в виде "графика".
В этой части III серии я расскажу вам о компонентах, которые нам нужны для конвейера машинного обучения, о том, как мы их стандартизировали и разработали многоразовые рабочие процессы для нескольких команд.
Случаи использования
- Обучение/экспериментирование с обучающим скриптом, набором входных данных и фиксированными гиперпараметрами
- Развертывание модели, обновление существующего развертывания новой моделью
- Оценка/валидация модели (моделей), обученной в описанном выше варианте использования (1), или предварительно обученной модели.
- Настройка гиперпараметров
- Дополнительное обучение
- Мониторинг модели
Давайте рассмотрим некоторые из этих вариантов использования и разберемся с задействованными компонентами.
Первый вариант использования — обучение модели
Этапы обучения (как показано на рисунке )
- Предоставление обучающих наборов данных и обучающего сценария
- Предоставление инфраструктуры с желаемыми конфигурациями, например. окр. переменные, гиперпараметры
- Обучите модель и регистрируйте метрики, параметры на сервере отслеживания, например. МЛФлоу
Как видите, есть три компонента, которые могут различаться в зависимости от эксперимента: -
— входные наборы данных
— сценарий обучения
— гиперпараметры.
Чтобы сделать рабочие процессы обучения воспроизводимыми и согласованными между запусками, нам нужно было зафиксировать вышеуказанные компоненты. Итак, мы решили управлять версиями наборов данных с помощью DVC вместо обычных систем S3/File, тогда как обучающие скрипты и гиперпараметры управляются с помощью Git.
В то же время мы не хотим, чтобы специалисты по данным сами предоставляли наборы данных и программировали. Следовательно, необходимо автоматизировать этапы предоставления данных и кода в самом конвейере.
Второй вариант использования — развертывание модели
Бесшовное развертывание модели действительно важно для быстрой обратной связи, и это этап, который не имеет ничего общего с специалистом по данным. Проще говоря, развертывание модели — это этап, на котором двоичный файл модели должен быть загружен в память поддерживающей инфраструктурой с установленными нужными библиотеками и представленными в виде API, и все это без необходимости ручных усилий.
Обычно для развертывания модели требуется:
- Файлы моделей — модель сериализуется в файлы .bin, .pkl или .zip и хранится в файловой системе/S3 и т. д.
- Wrapper — код для загрузки модели в память и вызова ее функций прогнозирования путем предоставления данных в ожидаемом формате.
- Дополнительные модули — эти модули/файлы Python используются кодом-оболочкой, например. управлять фреймворком данных, моделью загрузки и другими утилитами
- Пакеты — это стандартные библиотеки, используемые оболочкой. Например. трансформаторы, факел, NumPy и т. д.
Мы разработали конвейер развертывания таким образом, что четыре вышеуказанных компонента автоматически подбираются и встраиваются в исполняемый артефакт, который затем развертывается как REST API для использования другими службами.
- Клонируйте репозиторий, содержащий дескриптор развертывания и вышеупомянутые артефакты.
- Сборка — на этом этапе происходит сборка оболочки, модулей, пакетов Python и обученной модели в пакет развертывания.
- Сборка образа модели — на этом этапе берется пакет развертывания из приведенного выше, сшивается все вместе и запекается образ докера, который можно запускать где угодно, а также предоставляются стандартные конечные точки отдыха для запуска вывода по модели.
- Развертывание модели — на этом этапе используется Kubeflow KFServe для развертывания образа докера модели в качестве службы логического вывода и автоматически предоставляется модель как служба через балансировщик нагрузки.
Больше вариантов использования — я предпочитаю не делать это исчерпывающим, поэтому оставшиеся варианты использования должны быть подробно описаны в отдельной статье.
Конвейеры являются общими
Идея состоит в том, чтобы определить общие, настраиваемые и многократно используемые конвейеры, а затем предоставить их специалистам по обработке и анализу данных, предоставив различные параметры, например. Учебный репозиторий GitSHA, набор данных GitSHA для проверки DVC, набор данных для обучения, гиперпараметры тестового набора данных и т. д.
Кроме того, каждый из этапов этого конвейера выполняется подами Kubernetes, и для каждого этапа созданы образы докеров. Например, образ докера для клонирования наборов данных из DVC, еще один для запуска сценария обучения и т. д.
Хотя я понимаю, что это слишком много информации в слишком малом количестве контента, я считаю важным дать представление об экосистеме в целом и не вдаваться слишком глубоко.
Не стесняйтесь оставлять отзывы/задавать вопросы в комментариях ниже, и помогите мне сделать это более информативным.
В следующей части я познакомлю вас с Orchestrator для Kubeflow Pipelines, настройкой аутентификации (SSO) для Kubeflow и соберу Istio, Dex и Cognito.