Кто и как управляет разработкой ML-моделей + опыт ПГК

Привет, Хабр! Меня зовут Павел Куницын, и я главный специалист по анализу данных и МО в ПГК Диджитал. Согласно различным исследованиям, от 46 до 90% моделей машинного обучения не выходит в прод. Всему виной отсутствие должного контроля за их созданием, а также проблемы менеджмента команд разработки и data science.

Решить эту проблему способен MLOps. С учетом того, что на Хабре есть базовые материалы по теме, расскажу о том, как бизнес и сообщество подходят к стандартизации разработки моделей. Также расскажу про свод базовых рекомендаций для повышения качества ML-систем, который сформулировали мы в ПГК.

Зачем нужен MLOps — очень коротко

Разработка моделей машинного обучения отличается от разработки привычных сервисов. Во-первых, на качестве их работы отражаются любые изменения в данных. Мы в ПГК занимаемся логистикой и используем МО для предсказания объемов грузоперевозок между железнодорожными станциями. Так, если модель, предсказывающая загрузку вагонов, была обучена на данных одного региона, а потом получила данные из другого, то точность и релевантность построенного ей прогноза будет ниже. Чтобы модель работала корректно, её нужно регулярно обновлять: следить за качеством данных и тем, насколько они соответствуют решаемым задачам.

Во-вторых, разработка ML-моделей представляет собой междисциплинарную деятельность — в ней принимают участие разные команды. Сперва дата-сайентисты проводят эксперименты и обучают модель, затем разработчики интегрируют её с корпоративными системами, а DevOps’ы настраивают окружение. Работа в таком формате стала классической в MLOps и в целом привычна для ИТ-специалистов, однако оркестровка процессов все еще представляет сложности для менеджеров.

Решить проблему помогает MLOps — набор практик и инструментов для автоматизации и управления жизненным циклом систем машинного обучения. Он ускоряет развертывание моделей и помогает всем участникам — от руководителей до дата-сайентистов — работать эффективнее. Цель MLOps — сделать процесс разработки и развертывания моделей более предсказуемым, стабильным и масштабируемым. Как правило, MLOps помогает командам автоматизировать рутинные задачи, связанные с подготовкой данных, управлять версиями моделей, масштабировать обучение и развертывание моделей. Мы решили обсудить тему, в том числе чтобы сделать MLOps чуточку доступнее для управленцев.

«Бардак» в индустрии

Машинное обучение остаётся одной из горячих тем в ИТ. Буквально каждую неделю стартапы и корпорации выпускают новые продукты на базе систем ИИ в надежде захватить кусочек рынка, стоимость которого оценивается в 40–120 млрд долларов. Но разброс в оценках подобных масштабов сродни гаданию на кофейной гуще. И этот факт неизбежно отражается на сфере MLOps, ведь хайп вокруг технологий зачастую приводит к завышенным ожиданиям относительно простоты их внедрения.

Сфера MLOps относительно молодая, поэтому каждая компания хочет закрепить за собой влияние. Привычные решения получают новые названия — бизнес вводит собственные термины, стремясь оставить след в истории. Так, в MLOps каждый новый инструмент неизбежно превращается в «магазин» или «витрину»: сначала появились магазины моделей и признаков, теперь — витрины метрик и бенчмарков. Как отмечает инженер Михаил Эрик в статье MLOps Is a Mess, компании с энтузиазмом придумывают синонимы к привычному словосочетанию «база данных».

Еще одна проблема заключается в том, что в индустрии до сих пор нет устоявшихся подходов к менеджменту и оркестровке внутрикомандных процессов. Еще в 2015 году инженеры Google отметили, что разработка моделей — лишь небольшая часть машинного обучения. Релевантная инфраструктура невероятно обширна и включает инструментарий для сбора данных и их верификации, извлечения признаков, мониторинга — покрывает десятки других процессов. Иными словами, компоненты MLOps широко известны, однако границы между ними до сих пор формируются.

Наконец, разногласия есть даже на уровне базовых смыслов. Можно встретить мнение, что MLOps — это очередной баззворд, обозначающий Data Engineering. Да, обе области связаны со сбором и обработкой данных, но MLOps охватывает гораздо большую область знаний. Здесь важную роль играет поддержка инфраструктуры, работа с моделями, их масштабирование, оптимизация под GPU, настройка CI/CD-процессов. Получается, MLOps требует не только инженерных навыков.

Проработка лучших практик

MLOps пока находится в состоянии некоторого хаоса, но первые шаги к стандартизации уже есть: компании публикуют свои how-to’s, обмениваются опытом. Так, немецкое консалтинговое агентство INNOQ (в частности, их подразделение Data and AI) опубликовало свод лучших практик MLOps. В организации предлагают рассматривать работу с моделями машинного обучения как часть CI/CD-пайплайна и выделяют три ключевые фазы. Первая посвящена анализу данных и бизнес-задач, которые необходимо решить с их помощью. На этом этапе компания предлагает идентифицировать целевую аудиторию и определить дальнейшие этапы разработки.

Вторая — фаза проектирования, в рамках которой отбирают необходимые для обучения модели данные и выделяют требования. Они помогают спроектировать архитектуру ML-приложения и тестовый фреймворк. Третья фаза подразумевает построение proof-of-concept модели и её подготовку к продакшену. На этом этапе интеллектуальный алгоритм совершенствуют для выдачи стабильных результатов.

Крупные поставщики программного обеспечения и облачные провайдеры также выкладывают чек-листы для подготовки инфраструктуры и процессов к внедрению практик MLOps. Похожие рекомендации от членов комьюнити можно найти и на GitHub. Как правило, они сводятся к необходимости вести практическое внедрение MLOps по двум направлениям:

• Организационному. Предполагает развитие корпоративной культуры, проведение обучающих тренингов и объединение DevOps-инженеров и дата-сайентистов в команду с четким разделением ответственности.

• Техническому. Внедрение DevOps-инструментов для автоматизации процессов разработки, тестирования и интеграции сводов данных, моделей и кода.

Кроме чек-листов и гайдов, в открытом доступе можно найти open source решения для построения пайплайна MLOps. Примером может быть курируемый список профильного инструментария Awesome MLOps. В нем есть не только сравнительные обзоры, но и литература. Например, для менеджеров может быть интересно свежее издание «Implementing MLOps in the Enterprise» от O’Reilly. Её авторы делают акцент на подходе production-first; не столько на разработке моделей, сколько на построении CI/CD-пайплайна. Другой пример — книга «Reliable Machine Learning», которая фокусируется на управлении командой разработчиков и лучших практиках MLOps.

Как с MLOps работаем мы

Мы в ПГК используем машинное обучение, чтобы упростить работу сотрудников. Например, наш «Оптимизатор ремонтов» помогает планировать ремонт вагонов и выбирать депо с оптимальной стоимостью. Для разработчиков мы создали Python-класс MLExperimentManager — он помогает с автоматизацией загрузки данных и оценкой качества моделей. С ростом пула интеллектуальных инструментов у нас появилась потребность тщательно контролировать создание моделей, чтобы гарантировать качество ML-решений. Мы подготовили обобщенный свод правил и рекомендаций по тому, как разрабатывать модели. Поделюсь ключевыми тезисами:

1. Разработка ML-системы сопровождается документацией

В проектной базе знаний мы сформировали шаблоны карточек модели и проекта, в которых дата-сайентисты отражают:

• Решаемую проблему;

• Подход к решению и алгоритм;

• Методологию оценки качества;

• Использованные данные и их источники;

• Использованные инструменты (например, Airflow или MLflow).

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

2. Интерфейс модели изолирован от других систем

Наиболее подходящими архитектурными решениями для деплоя моделей у нас стали микросервисы и Python-пакеты. Такой подход помог повысить прозрачность в разработке, сократить время на проверку гипотез и снизить нагрузку на других специалистов, так как «выкатка» моделей перешла в ведение дата-сайентистов.

3. Алгоритм является частью пайплайна

Дробление процесса работы модели (загрузка данных, обработка, прогноз) упростило отладку, позволило параллелизировать задачи между коллегами и увеличить качество решений за счет специализации. А еще ML-система предусматривает возможность автоматической подстановки актуальных данных для переобучения.

4. Ведется журнал экспериментов

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

5. Жизненный цикл модели покрывается тестами

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

6. Для продуктивной модели настроен мониторинг

Для проектов, прошедших стадию пилота, мы стараемся следить за:

• Данными (аномалии, распределения и так далее);

• Запросами к модели;

• Прогнозами модели;

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

• Доступностью и производительностью системы.

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

Наш чек-лист

В общем виде описанные в нашем базовом подходе идеи можно представить в формате чек-листа и опираться на него при построении собственного пайплайна:

1. Алгоритм, данные, архитектура модели четко задокументированы

2. Разработана и задокументирована методология оценки качества модели

3. Определен инструментарий

4. Модель является частью пайплайна

5. Ведется контроль версий кода, данных, результатов экспериментов

6. Ведется журнал экспериментов

7. Налажено тестирование всего жизненного цикла алгоритма

8. Реализована возможность автоматического переобучения

9. Настроен сбор входных данных, прогнозов и факта в проде

10. Настроен мониторинг производительности и качества