В этой статье мы ответим на главные вопросы о новом явлении в мире IT ― MLOps, с чем придётся столкнуться тем, кто решил поставить работу с данными на поток и захочет применить на практике подход MLops.
На вопросы отвечают Head of Computer Vision EPAM Михаил Толмачев и Senior Data Solution Architect Евгений Кожевников. Михаил Толмачев отвечает за интеграцию продукта клиентов, он расскажет, какие задачи решает MLOps и когда он нужен. Евгений Кожевников занимается архитектурой дата-ориентированных проектов, он расскажет, как правильно выстроить взаимодействие между командами и с чего начать изучение MLOps.
Зачем же DevOps в машинном обучении? Как обычно: проще управлять ожиданиями, результатом, итерациями для клиентов; сравнивать итоги экспериментов; перепроверять гипотезы, внедрять разработки.
Конечно, все эти плюсы не возникают сами собой. Большие данные — хаос, а машинное обучение беспомощно без заданного направления. Как раз искусство MLOps — заставлять ML работать на себя. То есть привнести Operation в Machine Learning.
Это не так легко. В обычной enterprise-разработке ты пишешь программу и понимаешь, как строить CI/CD, как осуществлять поставку, какие есть варианты релиз-менеджмента. В Data Science мире ты пишешь программу, которая создаёт другие программы. MLOps приносит в этот процесс практики CI/CD, воспроизводимость, способы мониторинга результатов и контроля.
Главная задача MLOps ― это составить общее видение процесса поставки ML-продукта, для чего команда разрабатывает модель, какую она несёт бизнес-ценность, какие стоят KPI. Это позволяет отслеживать, как Data Science метрики могут влиять на бизнес.
Например, мы делаем систему инвентаризации складов с помощью компьютерного зрения. У Data Scientist есть много сложных метрик, но бизнес-заказчикам будет тяжело их понять, они будут ориентироваться на свои бизнес-метрики, например, точность количества товара. Связать метрики команды и заказчика, договориться, чтобы все с обеих сторон понимали, какие этапы есть в жизни продукта и как люди взаимодействуют — 80% задач в MLOps. А оставшиеся 20% — это технологии. Например, пайплайн, который после обучения модели производил бы анализ её работоспособности на различных ситуациях, чтобы автоматически развернуть.
Но здесь, как и в DevOps, есть несколько уровней зрелости автоматизации процессов. Первый ― это когда всё делается вручную, редкие релизы, нет CI и CD. Второй уровень, когда ML-пайплайн автоматизируемый, есть continuous training для моделей в производстве.
И третий, высший уровень вселенского разума — максимальная автоматизация, когда есть постоянный мониторинг на live data, вызывающий те или иные пайплайны, которые запукают новые циклы эксперимента.
Дальше только автоматизация Data Scientist. Кроме шуток: такое уже есть — AutoML. Но пока он делает автоматически только самую начальную работу.
Конечно, MLOps не панацея. Даже если стек технологий уже есть — нужна ещё взаимная договорённость команды. Если начать пользоваться устаканившейся облачной платформой, например Azure ML Studio, она не даст необходимого результата, потому что нужно обсудить: а как мы ведём эксперименты? мы бранчуемся от мастера? а как называть эти бранчи? по номеру тикета? а как модельки логировать? а как убедиться, что обученная модель соответствует тем или иным параметрам?
Особенно стоит учитывать важность справедливости (fairness) ML, важно, чтобы ML давала одинаковые выводы, не основываясь на предвзятостях, таких как пол, тональность кожи и прочее. Для этого часто нужно прикручивать дополнительные пайплайны.
В общем, совсем MLOps не похож на волшебную кнопку автоматизации: надо будет садиться, разбираться, думать, причем думать людям сразу из нескольких команд. Ну и с клиентами придётся общаться: зачем им машинное обучение («шатание табличек», как называется ML в народе), как они его видят, как будут им пользоваться.
MLOps ― это набор лучших практик, но универсального MLOps нет, в каждом случае подход будет отличаться. Поэтому работа начинается с команды Data science ― своего рода “художников”, которые придумывают ML-подход к решению задачи, какие алгоритмы использовать, как сгруппировать, обучить, как измерять их качество и т.д. На выходе получается, например Jupyter Notebook. Он может играть роль хорошей документации, с описанием, структурой, визуализацией, примерами и даёт четкое понимание всей команде, каким образом самообучающиеся алгоритмы решают бизнес-задачу.
Далее ML-инженер идёт к Data-инженерам, DevOps и договаривается, как превратить ноутбук в понятный ML-пайплайн, автоматизируемый, версионируемый, масштабируемый, с включением процессов обратной связи, мониторинга, отчётами. Каждый специалист может какую-то часть замкнуть на себе, например, на этапе подготовки данных использовать Spark. Системный инженер развернёт Kubeflow, чтобы автоматизированно запускать процессы обучения данных, выкатку новых версий этих алгоритмов. Разработчики придумают, как результаты этой модели интегрировать в платформу, будет ли это выгрузка предикшенов или же это будет сервис, который внутри себя будет содержать модель и по запросу отдавать какой-то ML-результат.
Сложная картина взаимодействия всего со всеми. Но когда уже вокруг продукта выстроился фреймворк, автоматизирован ML-пайплайн, мониторинг, интеграция, коммуникация становится проще, где-то её можно полностью автоматизровать так, что Data Scientist уже будут править не абстрактный ноутбук, а какие-то части автоматизированного пайпалайна уже в DSL этого ML-пайплайна.
На проектах разные люди из разных команд пытаются брать на себя эту роль. Где-то Data Scientist занимаются ML-инженерией. Иногда специалисты из числа Data-инженеров, DevOps или системных инженеров драйвят этот процесс. Но каждый из них смотрит на ситуацию со своей спецификой, поэтому нужен независимый третейский судья, который разрулил бы разногласия.
Поэтому возникла отдельная роль ― ML-инженер. Он нужен для того, чтобы был человек, который брал бы на себя ответственность за выстраивание автоматизации от начала до конца. Соответственно, в его интересах договориться с Data-, software-, системными инженерами, с Data Scientist — чтобы то, за что он ответственен, свершилось.
Далее, нужно в целом знать, как устроена современная инфраструктура: CI/CD, логирование экспериментов, как версионировать дата-сеты и окружение. В общем, понимать, чем занимается современный Data DevOps-инженер.
Важно хорошо представлять процесс разработки (в том числе жизненный цикл продукта Data Science) и работу вовлечённых в него команд: Data-инжиниринг, системный инжиниринг, Data Science, и прикладную часть ― разные варианты интеграции. То есть надо в целом понимать, как всё устроено в разных частях проекта.
Можно начать с любой платформы, посмотреть, какие задачи она решает, как она их решает. Для простоты можно взять реализацию от клауд-вендора ― SageMaker, Vertex AI или Azure ML. Облачные провайдеры удобнее, т.к. все дополнительные компоненты могут быть добавлены с помощью нескольких строчек кода, за счёт чего можно выстроить end-to-end MLOps внутри одной платформы. Они функционально похожи: один язык (Python API), термины, возможности. Документации выбранной ML-платформы хватит, чтобы погрузиться в контекст. А дальше можно смотреть конкретные альтернативы: разные Feature Store, движки ML-пайплайнов, реестр моделей. Есть сертификации от провайдеров, которые обобщают этот опыт в некий курс.
Open Source решения — это конструктор, каждая деталь которого что-то решает. И этот конструктор придётся собирать руками под конкретную задачу — причём детали должны не только подходить по функционалу, но и быть совместимыми между собой. Да, есть крупные компоненты, которые в себя включают несколько функций, тот же Kubeflow. Но такой Open Source платформы, которая бы закрывала сразу все потребности, нет. С точки зрения комплексности, документации cloud-решения более целостные.
Хотя и там не всё гладко ― cloud-вендоры стремятся к универсальности, но до end-to-end видения, генерализируемого, параметризированного и подходящего абсолютно всем как есть без доработаток, — до такого им далеко. Пока что не для любой задачи можно наконфигурировать себе какой-то стек на базе ML-сервисов — до такого ещё техника не дошла.
Все облачные провайдеры предоставляют похожий набор функций, стараются подтягиваться друг к другу, чтобы закрывать весь скоуп известных проблем в этой области. Такого, что в одном облачные провайдере что-то есть, а в другом вообще ни в каком виде нет — навскидку и не скажешь.
Трудности возникают, когда нужно мигрировать с одного техстека на другой. Очень много особенностей, которые диктует конкретный сервис. Одни и те же функциональные сервисы в разных облачных провайдерах могут иметь разный набор ограничений.
Есть курс специализация по диплёрнингу на «Курсере» от Andrew NG — корифея Deep Learning. Ну и книги по теме — берите любую, где есть MLOps в названии.
habr.com
На вопросы отвечают Head of Computer Vision EPAM Михаил Толмачев и Senior Data Solution Architect Евгений Кожевников. Михаил Толмачев отвечает за интеграцию продукта клиентов, он расскажет, какие задачи решает MLOps и когда он нужен. Евгений Кожевников занимается архитектурой дата-ориентированных проектов, он расскажет, как правильно выстроить взаимодействие между командами и с чего начать изучение MLOps.
Что такое MLOps?
Полагаю, что не нужно объяснять, кто такой DevOps и что такое машинное обучение. Новость в том, что с недавнего времени эти понятия совместились.Зачем же DevOps в машинном обучении? Как обычно: проще управлять ожиданиями, результатом, итерациями для клиентов; сравнивать итоги экспериментов; перепроверять гипотезы, внедрять разработки.
Конечно, все эти плюсы не возникают сами собой. Большие данные — хаос, а машинное обучение беспомощно без заданного направления. Как раз искусство MLOps — заставлять ML работать на себя. То есть привнести Operation в Machine Learning.
Это не так легко. В обычной enterprise-разработке ты пишешь программу и понимаешь, как строить CI/CD, как осуществлять поставку, какие есть варианты релиз-менеджмента. В Data Science мире ты пишешь программу, которая создаёт другие программы. MLOps приносит в этот процесс практики CI/CD, воспроизводимость, способы мониторинга результатов и контроля.
Главная задача MLOps ― это составить общее видение процесса поставки ML-продукта, для чего команда разрабатывает модель, какую она несёт бизнес-ценность, какие стоят KPI. Это позволяет отслеживать, как Data Science метрики могут влиять на бизнес.
Например, мы делаем систему инвентаризации складов с помощью компьютерного зрения. У Data Scientist есть много сложных метрик, но бизнес-заказчикам будет тяжело их понять, они будут ориентироваться на свои бизнес-метрики, например, точность количества товара. Связать метрики команды и заказчика, договориться, чтобы все с обеих сторон понимали, какие этапы есть в жизни продукта и как люди взаимодействуют — 80% задач в MLOps. А оставшиеся 20% — это технологии. Например, пайплайн, который после обучения модели производил бы анализ её работоспособности на различных ситуациях, чтобы автоматически развернуть.
Чем MLOps отличается от обычного DevOps-подхода
Если коротко, то в DS другой процесс. Задача Data Scientist в том, чтобы вывести результаты исследования в продакшен как можно быстрее. Например, есть бизнес-задача: металлурги хотят считать размер вкрапления руды в породе. В обычном девопсе можно просто выкатить клиенту версию, которую он сможет посмотреть. В Data Science идёт автоматизация других этапов, здесь большое внимание уделяется этапу исследования, нужно понять, какую бизнес-задачу нужно решить, как оценивать результат, какие есть данные, подготовить их, попробовать несколько моделей, посмотреть, какая эффективней, и потом итерациями это выкатывать.Но здесь, как и в DevOps, есть несколько уровней зрелости автоматизации процессов. Первый ― это когда всё делается вручную, редкие релизы, нет CI и CD. Второй уровень, когда ML-пайплайн автоматизируемый, есть continuous training для моделей в производстве.
И третий, высший уровень вселенского разума — максимальная автоматизация, когда есть постоянный мониторинг на live data, вызывающий те или иные пайплайны, которые запукают новые циклы эксперимента.
Дальше только автоматизация Data Scientist. Кроме шуток: такое уже есть — AutoML. Но пока он делает автоматически только самую начальную работу.
Для чего нужен MLOps
Главное заблуждение: сейчас мы возьмем данные и Data Scientist — и всё заработает.Конечно, MLOps не панацея. Даже если стек технологий уже есть — нужна ещё взаимная договорённость команды. Если начать пользоваться устаканившейся облачной платформой, например Azure ML Studio, она не даст необходимого результата, потому что нужно обсудить: а как мы ведём эксперименты? мы бранчуемся от мастера? а как называть эти бранчи? по номеру тикета? а как модельки логировать? а как убедиться, что обученная модель соответствует тем или иным параметрам?
Особенно стоит учитывать важность справедливости (fairness) ML, важно, чтобы ML давала одинаковые выводы, не основываясь на предвзятостях, таких как пол, тональность кожи и прочее. Для этого часто нужно прикручивать дополнительные пайплайны.
В общем, совсем MLOps не похож на волшебную кнопку автоматизации: надо будет садиться, разбираться, думать, причем думать людям сразу из нескольких команд. Ну и с клиентами придётся общаться: зачем им машинное обучение («шатание табличек», как называется ML в народе), как они его видят, как будут им пользоваться.
Взаимодействие с командой
MLOps — это про командную работу и взаимодействие разных команд. А как эти разные команды в одной компании должны взаимодействовать? И кто должен запускать этот процесс MLOps?MLOps ― это набор лучших практик, но универсального MLOps нет, в каждом случае подход будет отличаться. Поэтому работа начинается с команды Data science ― своего рода “художников”, которые придумывают ML-подход к решению задачи, какие алгоритмы использовать, как сгруппировать, обучить, как измерять их качество и т.д. На выходе получается, например Jupyter Notebook. Он может играть роль хорошей документации, с описанием, структурой, визуализацией, примерами и даёт четкое понимание всей команде, каким образом самообучающиеся алгоритмы решают бизнес-задачу.
Далее ML-инженер идёт к Data-инженерам, DevOps и договаривается, как превратить ноутбук в понятный ML-пайплайн, автоматизируемый, версионируемый, масштабируемый, с включением процессов обратной связи, мониторинга, отчётами. Каждый специалист может какую-то часть замкнуть на себе, например, на этапе подготовки данных использовать Spark. Системный инженер развернёт Kubeflow, чтобы автоматизированно запускать процессы обучения данных, выкатку новых версий этих алгоритмов. Разработчики придумают, как результаты этой модели интегрировать в платформу, будет ли это выгрузка предикшенов или же это будет сервис, который внутри себя будет содержать модель и по запросу отдавать какой-то ML-результат.
Сложная картина взаимодействия всего со всеми. Но когда уже вокруг продукта выстроился фреймворк, автоматизирован ML-пайплайн, мониторинг, интеграция, коммуникация становится проще, где-то её можно полностью автоматизровать так, что Data Scientist уже будут править не абстрактный ноутбук, а какие-то части автоматизированного пайпалайна уже в DSL этого ML-пайплайна.
На проектах разные люди из разных команд пытаются брать на себя эту роль. Где-то Data Scientist занимаются ML-инженерией. Иногда специалисты из числа Data-инженеров, DevOps или системных инженеров драйвят этот процесс. Но каждый из них смотрит на ситуацию со своей спецификой, поэтому нужен независимый третейский судья, который разрулил бы разногласия.
Поэтому возникла отдельная роль ― ML-инженер. Он нужен для того, чтобы был человек, который брал бы на себя ответственность за выстраивание автоматизации от начала до конца. Соответственно, в его интересах договориться с Data-, software-, системными инженерами, с Data Scientist — чтобы то, за что он ответственен, свершилось.
Как специалистам вникнуть в MLOps-практики
В первую очередь понадобится понимать, как работают все Data Scientist. Можно посмотреть методологию CRISP-DM — фазы проекта DS примерно совпадают.Далее, нужно в целом знать, как устроена современная инфраструктура: CI/CD, логирование экспериментов, как версионировать дата-сеты и окружение. В общем, понимать, чем занимается современный Data DevOps-инженер.
Важно хорошо представлять процесс разработки (в том числе жизненный цикл продукта Data Science) и работу вовлечённых в него команд: Data-инжиниринг, системный инжиниринг, Data Science, и прикладную часть ― разные варианты интеграции. То есть надо в целом понимать, как всё устроено в разных частях проекта.
Как выбрать платформу для MLOps?
К счастью, выбор велик — в наши дни только ленивый не строит свою платформу со своим видением. Есть опенсорс, типа MLflow, есть облачные решения, помогающие автоматизировать любую часть пайплайна.Можно начать с любой платформы, посмотреть, какие задачи она решает, как она их решает. Для простоты можно взять реализацию от клауд-вендора ― SageMaker, Vertex AI или Azure ML. Облачные провайдеры удобнее, т.к. все дополнительные компоненты могут быть добавлены с помощью нескольких строчек кода, за счёт чего можно выстроить end-to-end MLOps внутри одной платформы. Они функционально похожи: один язык (Python API), термины, возможности. Документации выбранной ML-платформы хватит, чтобы погрузиться в контекст. А дальше можно смотреть конкретные альтернативы: разные Feature Store, движки ML-пайплайнов, реестр моделей. Есть сертификации от провайдеров, которые обобщают этот опыт в некий курс.
Open Source решения — это конструктор, каждая деталь которого что-то решает. И этот конструктор придётся собирать руками под конкретную задачу — причём детали должны не только подходить по функционалу, но и быть совместимыми между собой. Да, есть крупные компоненты, которые в себя включают несколько функций, тот же Kubeflow. Но такой Open Source платформы, которая бы закрывала сразу все потребности, нет. С точки зрения комплексности, документации cloud-решения более целостные.
Хотя и там не всё гладко ― cloud-вендоры стремятся к универсальности, но до end-to-end видения, генерализируемого, параметризированного и подходящего абсолютно всем как есть без доработаток, — до такого им далеко. Пока что не для любой задачи можно наконфигурировать себе какой-то стек на базе ML-сервисов — до такого ещё техника не дошла.
Все облачные провайдеры предоставляют похожий набор функций, стараются подтягиваться друг к другу, чтобы закрывать весь скоуп известных проблем в этой области. Такого, что в одном облачные провайдере что-то есть, а в другом вообще ни в каком виде нет — навскидку и не скажешь.
Трудности возникают, когда нужно мигрировать с одного техстека на другой. Очень много особенностей, которые диктует конкретный сервис. Одни и те же функциональные сервисы в разных облачных провайдерах могут иметь разный набор ограничений.
Инструментарий MLOps-специалиста
- Любая Data Science “движуха” начинается с ML-песочницы, а чтобы её организовать, нужно как минимум представлять, как выглядит JupyterHub, как с ним работать, как делать данные доступными для него.
- Следующий шаг — dedicated computing cluster. Да, Data Scientists привыкли запускать вычисления локально, но в какой-то момент это превращается в трудоёмкий перебор наиболее эффективных параметров модели, который работает сутки — намного эффективнее это запустить где-то в параллели. Подойдут распределённые системы ― это может быть Kubernetes, а для оркестрации процессов — Airflow.
- Далее — система ML-пайплайнов. Их можно запускать на самом оркестраторе например на Dagster. В облаках, как правило, за ML-пайплайны отвечает отдельный сервис, например Sagemaker Pipelines.
- Если говорить про опенсорсные фреймворки, то можно посмотреть DVC, систему трекинга экспериментов, MLflow, Kubeflow. В какой-то степени выход моделей в производство реализуется этими же системами. Есть ряд Feature Store продуктов, например Feast.
- Хранилища данных, такие как объектные хранилища (Ceph, Minio), DWH или NoSQL. Данные в хранилища доставляются пайпланами, при этом ML-инженеру не обязательно уметь разрабатывать пайплайны, но важно понимать, как это работает. Для поставки данных Data Scientists можно использовать такие инструменты, как NiFi, Scrapy.
- По возможности посмотреть Data Science фреймворки. Тот же scikit-learn: туториалы позапускать, посмотреть, что они делают. Также туториалы на PyTorch, примерные хелловорды повыполнять — просто почувствовать, с чем придётся иметь дело.
Есть курс специализация по диплёрнингу на «Курсере» от Andrew NG — корифея Deep Learning. Ну и книги по теме — берите любую, где есть MLOps в названии.
Заключение
DevOps, MLOps, AIOps… Что дальше? Какие еще «...Ops» могут появиться? Как обогнать рынок, чтобы стать востребованным? Куда смотреть?- Тренд — квантовые вычисления, квантовые компьютеры. Какой-нибудь квантум-опс точно появится.
- Спейс-опс. В космосе есть ограничения: например, процессор 5 нанометров не поставишь, потому что расплавится. Используют более старые технологии, чтобы они поглощали на определённой длине волны космическое излучение. Будем надеяться, что с спейс-опсом у нас в стране рванёт: филиал SpaceX, блог SpaceX на Хабре, Илон Маск как спикер.
Что такое практики MLOps и как их запустить
В этой статье мы ответим на главные вопросы о новом явлении в мире IT ― MLOps, с чем придётся столкнуться тем, кто решил поставить работу с данными на поток и захочет применить на практике подход...
habr.com