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

Я работаю над машинным обучением с третьего курса колледжа. Но в то время процесс всегда включал получение набора данных с Kaggle или какого-либо другого веб-сайта с открытым исходным кодом. Кроме того, эти модели/алгоритмы были либо в каком-то блокноте Jupyter, либо в скрипте Python, и не были развернуты на каком-то рабочем веб-сайте, это всегда был localhost.

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

Задачи включали сбор данных, очистку данных, анализ и визуализацию, выбор модели, оценку модели и, наконец, ее развертывание.

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

Постановка задачи, которую мы пытались решить, основывалась на контролируемом обучении.

1. Сбор данных. Данные играют важную роль в любой задаче машинного обучения. Проект, над которым я работал, требовал данных с Github. Поскольку Github API имеет почасовое ограничение скорости, мне нужно было убедиться, что ограничение скорости не превышено. Чтобы решить эту проблему, в скрипт Python была добавлена ​​пакетная обработка данных.

2. Очистка, анализ и визуализация данных. Данные из Github были в необработанном формате, с использованием панд для изменения данных для получения необходимых переменных и обработки отсутствующих данных. После того, как переменные были выбраны, я нашел их корреляцию с целевой переменной, визуализировал их с помощью тепловой карты, а затем принял решение об окончательных переменных решения.

Поскольку есть определенные строковые поля, используется One Hot Encoding. Чтобы удалить выбросы, я попробовал три разных метода: преобразование журнала, нормализацию данных и IQR. Судя по имеющимся у нас данным и изображениям с использованием boxplot, IQR работает лучше всего.

3. Выбор модели, обучение и тестирование. Проблема заключалась в контролируемом обучении, поэтому модель была выбрана на основе этого и включала настройку гиперпараметров. Для нормализации данных мы использовали разбиение на поезд-тест 80/20 и стандартный масштабатор. Достигнутая точность была достаточно хорошей для нашего варианта использования.

Это было все о разработке модели. Следующим шагом была интеграция модели с серверной частью.

1. Интеграция сбора данных: добавлен дополнительный проход к существующему сканеру в Golang для получения необходимых полей для модели. Таким образом, уже существующие функции не будут затронуты, а выборка данных модели станет независимой.

2. Решение о развертывании: Вес модели и стандартные масштабаторы были в формате bin. Помимо этого, во время обучения были созданы другие промежуточные файлы, которые состояли из определенных переменных, которые потребуются во время логического вывода.

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

1. AWS Sagemaker API для модели и S3 для хранения файлов

1. Хранение артефактов и файлов модели на S3.

Но так как у нас уже есть веса моделей в формате bin и нам нужен S3 для хранения промежуточных файлов, мы выбрали последнее.

3. Убедитесь, что модель регулярно обновляется: поскольку данные в реальном мире постоянно меняются, важно убедиться, что модель обновляется, чтобы избежать дрейфа данных. Чтобы решить эту проблему, я развернул хрон Kubernetes, который еженедельно обучал модель.

4. Интеграция с бэкэндом: Поскольку проект, над которым мы работали, был на Rails, я использовал Rescue-воркеров, которые помогали ставить задания в очередь, вызывать скрипты Python каждый раз, когда API срабатывает, и сохранять прогнозируемые значения в Elasticsearch.

Чему научились в процессе:

1. Машинное обучение нельзя измерить спринтами: Когда мне поставили задачу, мы создали Jira Ticket, и она выполнялась около трех месяцев. Через месяц стало ошеломительно видеть тикет в одном и том же состоянии, но со временем я понял, что в ML разработка и развертывание модели — это итеративный процесс, речь идет об экспериментах с разными подходами, оценке разных конвейеров, и вы не можете иметь конкретные результаты для каждого спринта.

2. Право собственности: Важно взять на себя ответственность за развертывание Модели. Когда мы создаем модель в Jupyter Notebook, это только первый шаг. Мы обязаны преобразовать эти ноутбуки в конвейер, который можно использовать в производстве и в то же время масштабировать, оценить различные методы развертывания, чтобы найти подходящий, и быть в курсе концепций разработки программного обеспечения.

3. Мониторинг: После того, как наша модель была недавно развернута, новые данные, которые когда-то поступали, имели некоторые нулевые значения, которые не обрабатывались в сценарии очистки данных. Наблюдая за еженедельным cron, я заметил неточность падения, которая помогла мне справиться с этим крайним случаем.

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

4. Ведение журнала во время логического вывода: Хорошо настроить систему логирования во время запросов API для модели/логического вывода, чтобы мы могли отслеживать количество времени, затраченное на очистку входящих данных, выборку необходимых переменных и, наконец, предоставление значения прогноза. Это помогает распознавать узкие места в конвейере.

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

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

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

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

Также опубликовано [здесь] (https://blog.shlokashah.com/experience-deploying-first-ml-model-to-production).