MLflow в производстве в HelpShift

                    Deepak Ahire¹ and Shyam Shinde²
1. Software Engineer, Helpshift AI, Pune, India. 
   Email: [email protected]. ORCID: 0000-0002-9174-0797
2. Engineering Manager, Helpshift AI, Pune, India.

Введение

Существует множество блогов, в которых рассказывается о том, как подключиться или интегрировать MLflow в конвейеры машинного обучения. Но цель этого блога — поделиться нашим опытом обучения по внедрению MLflow как части нашего конвейера производственного машинного обучения. Мы начали с внедрения флагманской функции HelpShift — «Умные намерения» [1–5] в MLflow.

В этом блоге мы обсудили —

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

Уместное и лаконичное утверждение: «Машинное обучение — это машинное обучение на 10% и инженерное дело на 90%», — говорит профессор Хьюен в своем курсе Stanford CS329S [6]. Совершенные модели не могут быть построены за одну ночь. Это повторяющийся процесс! И, следовательно, вам нужны инструменты, которые помогут вам управлять жизненным циклом машинного обучения ваших моделей. Это наша история, надеюсь, она вам понравится….

Почему Млфлоу?

Нашим основным требованием было решить проблему управления версиями. До интеграции MLflow у нас была собственная система управления версиями моделей, тесно связанная с AWS S3. Путь корзины S3 для хранения/доступа к нашим моделям был привязан к бизнес-сущностям и в конечном итоге стал специфичным для каждой функции после внедрения новых функций.

В рамках нашего POC нашим первым предпочтением было выбрать платформу(и)/инструмент(ы) с открытым исходным кодом, которая наилучшим образом соответствует нашему варианту использования. Среди них наиболее близкими оказались DVC и MLflow. DVC был больше ориентирован на инструмент командной строки без пользовательского интерфейса. Он оптимизирует модель и хранилище метаданных, сохраняя различия, как и GIT. Мы обнаружили, что он лучше всего подходит для хранения достаточно больших моделей размером около 5 ГБ. Но у нас в Helpshift есть легкие и малогабаритные модели.

В дополнение к этим у нас также были следующие требования —

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

Именно здесь в игру вступил MLflow, и мы начали с POC.

ПОС

Для POC мы начали с простого проекта и проверили, удовлетворяются ли все наши требования, и поняли, что MLflow позаботится обо всем, предоставив легкие и надежные API. Затем мы запустили POC на нашем производственном конвейере машинного обучения. Во время POC мы узнали следующее:

Составьте список ожиданий от инженеров и специалистов по данным в вашей команде.
POC даст вам четкое представление об оценке времени, необходимого для завершения проекта.
Поскольку вы завершили работу над инструментом MLflow, самое время обратиться к вашей команде DevOps для настройки инфраструктуры MLflow.

Утверждение POC членами нашей команды открыло двери для окончательной интеграции.

Окончательная интеграция

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

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

После интеграции наступает грандиозная задача по переносу наших моделей.

Миграция производственных моделей ИИ

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

Ранее мы хранили (или версионировали) наши модели в корзине AWS S3. Вот почему возникла необходимость перенести все эти модели и соответствующие метаданные из S3 в MLflow. При переносе данных на новую платформу нашим главным приоритетом было сохранение всех данных. С точки зрения специалиста по данным, вся история модели имеет решающее значение, поскольку он может анализировать/отслеживать тенденции метрик и гиперпараметров и предоставлять обратную связь нашим клиентам/агентам (которые предоставляют обучающие данные) для получения более качественных данных.

Чтобы убедиться, что миграция выполняется правильно, и получить четкое представление о том, как выглядит формат ваших производственных данных, было бы очень полезно 1–2 пробных запуска средства миграции. Это также даст вам четкое представление о том, сколько времени потребуется для окончательного запуска вашей миграции, и поможет вам лучше спланировать сроки выпуска и взаимодействие между командами. Эти пробные прогоны также станут окончательной проверкой настройки вашей производственной инфраструктуры MLflow, чтобы проверить, все ли на месте, насколько надежны API-интерфейсы MLflow и какую нагрузку они могут выдержать. Основные выводы:

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

В следующем разделе мы рассмотрим, как мы обслуживаем запросы клиентов.

Вывод

Мы загружаем последние обученные модели на наши узлы вывода, отправляя запросы на сервер отслеживания MLflow. Как следует из названия, наша служба логического вывода развернута на этих узлах.

Перед загрузкой моделей с помощью API загрузки MLflow нам нужно выполнить поиск только тех моделей, которые должны быть загружены на основе некоторых критериев. Для поиска моделей мы использовали поисковый API MLflow — search_registered_models(). API возвращает список интересующих нас моделей с разбивкой на страницы, и этот список затем передается в API загрузки.

Служба логического вывода обрабатывает запросы конечного пользователя, используя загруженные модели, и возвращает ответ.

Сюрприз в день релиза!

Как бы вы ни заботились, производство вас удивит! Всякий раз, когда вы работаете с недавно растущими библиотеками/пакетами с открытым исходным кодом, убедитесь, что у вас также есть практика чтения более длинной документации, сохранения того, что вы узнали, и понимания кодовой базы библиотеки. Как обсуждалось ранее, для поиска моделей мы использовали функцию search_registered_models(). «max_results»является одним из параметров этой функции. Теперь проблема в том, что этот параметр имеет значение по умолчанию, равное 100, и является необязательным параметром, как вы можете видеть на следующем изображении —

Проблема заключалась в том, что мы по какой-то причине пропустили использование этого параметра в нашем коде. А в день релиза, после канареечного релиза, мы заметили, что загружалось всего несколько моделей (т. е. первые 100 моделей). Чтобы получить список всех необходимых моделей (всего > 100), мы реализовали следующий цикл —

# List of required models to be downloaded
list_of_all_models = {}

# Number of models we want in a single call to MLFlow
# Tune this parameter as per your use case
number_of_models_in_one_batch = 100 

list_of_all_models = mlflow_client.search_registered_models(f"tags.model_type='smart_intent_model'",
                                                             max_results=number_of_models_in_one_batch)
last_token = list_of_all_models.token

while last_token is not None:
        
    next_batch_of_models = mlflow_client.search_registered_models(f"tags.model_type='smart_intent_model'",
                                                                    max_results=number_of_models_in_one_batch,
                                                                    page_token=last_token)
    for new_model in next_batch_of_models:
        list_of_all_models.append(new_model)

    last_token = next_batch_of_models.token

Затем этот список_всех_моделей был передан в API загрузки.

Влияние

Полная прозрачность всех версий моделей, соответствующих параметров, показателей производительности и наборов данных клиентоориентированных моделей в несколько кликов, полностью в браузере.
Оптимизирует процесс управления версиями моделей для различных моделей машинного обучения, необходимых для различных вариантов использования в бизнесе.
Устраняет необходимость создавать и поддерживать собственную модель и систему управления версиями метаданных.
Это позволяет нам отслеживать все потоки выполнения служб (конвейер построения моделей), которые отвечают за создание моделей с использованием пользовательских функций тегов. Если что-то пойдет не так в производственной среде, разработчики сразу и точно узнают, в чем проблема.
Теперь мы также отслеживаем (логируем) время выполнения разных этапов построения модели. Это создает мгновенную видимость и возможность оптимизировать конкретный(е) этап(ы).
Исследователи данных могут легко перемещаться между различными версиями моделей и наборами данных, используемыми для построения этих моделей. Это значительно экономит их время и усилия и дает им возможность анализировать и сравнивать данные.
Специалисты по данным могут в любое время следить за тем, что происходит в производственной среде, как часто наши клиенты используют эту функцию и насколько эффективно они ее используют.
MLflow устраняет необходимость прямого доступа к данным через рабочие корзины AWS, выступающие в качестве унифицированного уровня доступа к данным.
Теги уровня модели позволяют нам напрямую переходить к моделям на основе их доменов и имен, а также позволяют нам просматривать всю их историю.
Панель экспериментов сама по себе является инструментом наблюдения за моделью, к которому можно получить мгновенный доступ без какой-либо обработки данных.

Планы на будущее

MLflow предоставляет функциональные возможности для настройки этапа версии модели. Это — «Нет», «Постановка», «Производство» и «Архив». В основном мы использовали — «Staging» и «Production». Этап любой версии любой модели можно редактировать одним щелчком мыши или с помощью вызова REST API.

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

Взгляд на нашу приборную панель

Рецензенты

1. Utkarsh Dighe, Software Engineer II, Helpshift AI, Pune, India.

Цитирование (формат Bibtex)

 @misc{ahire_shinde_2022,
 title={MLflow in production at HelpShift},
 url={https://medium.com/helpshift-engineering/you-will-start-writing-more-at-work-after-reading-this-post-be9aa95db78f},
 journal={Medium}, publisher={helpshift-engineering},
 author={Ahire, Deepak and Shinde, Shyam},
 year={2022}, month={Nov}}