Привет, Хабр! Мы — DS-ы Павел Парфенов и Максим Шаланкин в команде Финтеха Big Data МТС. У нас много ML-моделей, которые нужно тестировать и внедрять в прод. Все это создает высокий темп разработки c кучей рутинных и ручных операций — от постановки задачи до продуктивизации и сопровождения модели. Мы смогли частично победить эту рутину с помощью drag and drop деплоя ML-моделей через web-интерфейс. В этой статье расскажем, что у него под капотом и какие функции в нем реализованы.

Бо́льшая часть нашей работы — это различные батчевые скоринги моделями градиентного бустинга. Деплой моделей — важный этап нашей работы. Чем меньше ручных операций и больше простых действий, тем меньше ошибок. Раньше мы деплоили модели через шаблон. Это ускоряло процесс, но не исключало всех возможных проблем:

• Сложных шаблонных процессов. Некоторым сотрудникам было трудно разобраться с процессом деплоя через шаблон. Ошибки возникали на разных этапах — от неправильной настройки конфигураций проекта или расписания скоринга модели и неоптимальных параметров скоринга до неверных версий библиотек. Из-за этого деплой мог занимать гораздо больше времени, чем планировалось.

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

• Неправильной настройки data quality и логирования данных. Правильная настройка data quality также занимала много времени, а новым сотрудникам это было особенно тяжело. Также важно было корректно логировать данные и результаты моделей.

По этим причинам мы решили избавиться от них с помощью web-интерфейса с функцией drag and drop. Этот подход позволил значительно упростить процесс для всех сотрудников, свести к минимуму ручные операции и, как результат, сократить количество ошибок и ускорить внедрение моделей в продакшн. Модели разворачиваются на выделенном сервере, а их скоринг запускается по расписанию.

Архитектура drag & drop: api + airflow

Перед стартом разработки собственного сервиса drag and drop мы искали готовые инструменты деплоя. Смотрели в сторону MLflow, Kubeflow и менее известных оркестраторов ML-моделей. Но все они в меньшей степени отвечали нашим требованиям гибкости и интегрируемости в существующую инфраструктуру. В итоге оттолкнулись в нашем архитектурном решении от внутренних инструментов МТС, в том числе для работы с airflow.

Архитектура нашего drag-and-drop-сервиса включает в себя backend, frontend, airflow и S3-хранилища:

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

Для корректной работы web мы создали api для постановки модели на автоматический скоринг, ее удаление и управление статусами скоринга.

В web-форме, помимо окна для выбора файла модели, есть дополнительные поля для заполнения и информирования пользователя:

• отчетный email пользователя для отправки ответов о скоринге модели;

• выбор расписания скоринга, чтобы задавать частоту скоринга;

• строка состояния скорингов пользователя: наблюдение за состоянием модели через web-интерфейс.

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

Общая структура объекта модели

Для унификации процесса деплоя и дальнейшей работы с моделями объект модели должен соответствовать заданному шаблону.

Стандартизация реализована через объект словаря в Python с заданными полями. Так проще настраивать и интегрировать модели в рабочий процесс. Объект модели содержит model pipeline, параметры для запуска скоринга и метаинформацию — например, почту пользователя. Model pipeline может включать в себя трансформации данных, модельные преобразования.

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

Подобные объекты хранятся в определенной структуре в облачном S3-хранилище и могут быть сгенерированы пользователями в ручном режиме в своих рабочих ipython notebooks или же в нашем автоматическом AutoML-сервисе. Мы обязательно расскажем про него в другой раз.

S3-хранилище на основе MinIO

Для хранения и управления моделями нужно использовать надежное хранилище данных. Объектное хранилище представляет собой дополнительный уровень абстракции над файловой системой и сервером, который предоставляет возможность управлять файлами и получать к ним доступ через API. Мы выбрали MinIO потому, что является одним из наиболее удобных решений для начала работы с объектным хранилищем: его легко развернуть, просто администрировать, и оно интуитивно понятно. MinIO также способен долгое время отвечать важным требованиям к доступности, масштабируемости и гибкости.

Из web-интерфейса dill-файлы сохраняются в MinIO, где у каждого пользователя есть своя директория с лимитами на активные модели. Это позволяет централизованно управлять моделями и ограничивать доступ к ним, обеспечивая безопасность и контроль над ресурсами.

Все объекты моделей должны быть проскорены вовремя, за это отвечает airflow dag.

Запуск в Apache Airflow

Для управления процессами батчевого скоринга по расписанию мы выбрали Apache Airflow. Для всех процессов есть один даг с фиксированными шагами, который запускается ежедневно и проверяет, какие модели из S3 надо проскорить.

Как выглядит логика нашего DAG Airflow:

• проверяем наличие моделей для скоринга на текущую дату;

• собираем список всех необходимых модельных признаков из всех моделей из пункта 1. Потом на актуальный срез данных собираем нужные нам фичи в базе данных;

• делаем итеративный инференс каждой моделью;

• проводим data-quality-проверку скоров;

• формируем отчет пользователю.

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

Инференс

Чтобы обеспечить эффективный процесс инференса, важно собрать все необходимые фичи в единую таблицу, по которой будет проходить скоринг. Это нужно, чтобы упростить и ускорить процесс обработки данных.

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

Инференс выполняется с помощью UDF-функции, которая позволяет распределенно применять модель к данным на кластере. Результаты записываются в единую таблицу скоров, что упрощает последующий анализ и оценку эффективности моделей.

Резюмируем: мы автоматически и централизованно записываем скоры для пользовательской модели. Дополнительно это позволяет осуществлять единую общую data-quality-проверку скоров.

Data-Quality-оценка

Управление большим количеством скорингов ML-моделей позволяет контролировать и анализировать модельные артефакты: данные, модельные характеристики (например, feature importance) и сами скоры. Работая с моделью, важно не только проскорить ее, но и оценить качество данных и самих предсказаний.

После каждого запуска модели мы оцениваем качество текущей и предыдущей партиции записанных скоров. Результаты сравниваются по метрикам, таким как PSI и adversarial validation score. Почитать про разные подходы к Data Quality можно в нашей прошлой статье.

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

Чего мы добились с помощью сервиса drag and drop

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

Управление деплоем модели в едином web-окне через Drag & Drop позволяет продуктивизировать модели через интерфейс, а создавать их можно в соседнем окне с функционалом autoML, практически покрывая весь цикл разработки ML-модели.

На этом у нас все. Если у вас появились вопросы, задавайте их в комментариях. В следующий раз расскажем о функциональности AutoML.