Введение в «Not so Simple ML Framework»
В серии постов я хочу представить ML Framework (на основе Python), достаточно хороший, чтобы быть готовым к работе, но в то же время простой. Фреймворк включает в себя все, от проекта Data Science до проекта API, обслуживающего запросы (отвечающего за процесс CD).
Кто мог сделать нас из этого
Фреймворк подойдет команде среднего размера или команде с низким уровнем инженерной поддержки данных. Я сам не Data Scientist, я помогаю командам Data Science настраивать свои пайплайны/рабочие процессы, как, можно сказать, инженер ML/Data. Поэтому в следующих постах я не буду описывать как готовить/обучать/моделировать/оценивать/и т.д. модели машинного обучения, но и как подготовить ваш проект к производству.
Почему
Цель фреймворка — иметь надлежащую основу для ваших рабочих процессов и конвейеров машинного обучения, которую вы могли бы легко расширить самостоятельно. Например, в API я специально не буду использовать Nginx в качестве веб-сервера, как я уже говорил выше, фреймворк простой. Это не означает, что вы не можете добавить его, если вам это нужно, это просто еще один строительный блок.
Альтернативы
Несколько слов о том, почему я решил написать собственный фреймворк вместо использования чего-то вроде решения Tensorflow/Serving или PyTorch или даже фреймворка с открытым исходным кодом/коммерческого машинного обучения. Первый ответ, который вы получаете от архитектора при построении какой-то системы — «это зависит». На мой взгляд, пользовательское решение обычно быстрее начать использовать, и вы можете легче адаптировать свои текущие процессы к нему, чем к какой-то более крупной системе/фреймворку. Кроме того, части, которые «просто» обслуживают запросы API, обычно не очень хорошо настраиваются, или время, чтобы понять и внести изменения, слишком велико.
Пайплайн использования фреймворка
- Проект по науке о данных: проект, в котором вы структурируете свой код, связанный с машинным обучением (здесь я использую PyCharm в качестве IDE)
- Мы упаковываем наш код моделирования и загружаем его на сервер (позже мы проверим доступные варианты).
- Загружаем нашу сериализованную (например, маринованную) модель. Модель обучена и готова к использованию API
- Проект API (Flask) будет использовать пакет моделирования
- Мы отправляем проект API в наш репозиторий (GitLab, GitHub и т. д.), поэтому наш конвейер CD (т. е. непрерывная доставка) будет запущен.
- После успешных этапов сборки, тестирования, развертывания у нас есть наш контейнер Docker с API в кластере (или любой другой среде выполнения)
- API загрузит сериализованный файл модели из хранилища (например, S3, корзина Google) при запуске службы.
Важные вещи, которые также будут описаны в следующих постах:
- Автообновление модели/пакета
- Управление пакетами (через pipenv)
- Тестирование: модуль, API, для автообновления
- Пакет утилит, который используется между наукой о данных и проектами API.
Большинство компонентов — это просто строительные блоки, которые вы можете заменить чем-то другим по вашему выбору, например, вы можете использовать простой файл requirements.txt вместо pipenv или продолжить работу без CD-конвейера и так далее.
Что будет дальше
В следующих статьях я покажу более подробную информацию о каждой части фреймворка. Вы можете взять фреймворк полностью или частично, использовать свои части там, где вам удобно, потому что все это индивидуально, а большинство частей опциональны.
