К настоящему времени все, должно быть, видели документ THE MLOps.

«Операции машинного обучения (MLOPs): обзор, определение и архитектура»

Доминик Кройцбергер, Никлас Кюль, Себастьян Хиршль

Качественный товар. Если вы еще не читали ее, обязательно сделайте это.

Авторы дают исчерпывающий обзор:

  • Что такое МЛОпс,
  • Принципы и компоненты экосистемы MLOps,
  • Люди/роли, участвующие в выполнении MLOps,
  • Архитектура MLOps и рабочий процесс, которые есть у многих команд.

Они решают уродливую проблему в каноническом движении MLOps: как все эти компоненты стека MLOps на самом деле соотносятся друг с другом и работают вместе?

В этой статье я делюсь тем, как наша реальность как компании, производящей инструменты для MLOps, и мои личные взгляды на MLOps согласуются (и не совпадают) с ней. Многое из того, о чем я буду говорить здесь, я уже вижу сегодня. Некоторые из них — мои ставки на 3–4 года.

Просто чтобы вы знали, откуда я родом:

  • У меня большой опыт разработки программного обеспечения (15+ лет в программном обеспечении). Пережил революцию DevOps. Пришел на ОД с софта.
  • Основал две успешные компании по предоставлению программного обеспечения.
  • Основал neptune.ai, модульный компонент MLOps для хранилища метаданных машинного обучения, также известный как трекер экспериментов + реестр моделей.
  • Я руковожу продуктом и смотрю, что делают пользователи, клиенты и другие поставщики в этом уголке рынка.
  • Большинство наших клиентов используют ML/MLOPs в разумных масштабах, а НЕ в гипермасштабах крупных технологических компаний FAANG.

Если вам нужен TLDR, вот он:

  • MLOps является частью DevOps. Не форк:
    – Команда MLOps должна состоять из инженера DevOps, инженера по программному обеспечению для серверной части, специалиста по данным и обычных программистов. Я не вижу, какую особую роль здесь будут играть инженеры машинного обучения и MLOps.
    — Мы должны выстроить циклы обратной связи (обзоры, утверждения) вокруг CI/CD, специфичные для машинного обучения.
  • Нам нужен как автоматизированный непрерывный мониторинг, так и периодические ручные проверки.
  • Будет только один тип хранилища метаданных машинного обучения(сначала модель), а не три.
  • Компонент оркестровки рабочего процесса на самом деле состоит из двух вещей: инструментов выполнения рабочего процесса и среды разработки конвейера.
  • Нам не нужен реестр моделей. Во всяком случае, это должен быть плагин для репозиториев артефактов.
  • Инструменты мониторинга моделей будут объединены со стеком мониторинга DevOps. Вероятно, раньше, чем вы думаете.

Хорошо, позвольте мне объяснить.

MLOps является частью DevOps. Не вилка.

Во-первых, здорово говорить о компонентах стека MLOps и MLOps, но, в конце концов, мы все просто поставляем здесь программное обеспечение.

Особый тип программного обеспечения с ML в нем, но, тем не менее, программное обеспечение.

Нам следует подумать о том, как подключиться к уже существующим и зрелым практикам, стекам и командам DevOps. Но большая часть того, что мы делаем в MLOps, — это создание вещей, которые уже существуют в DevOps, и добавление к ним штампа MLOps.

Когда компании добавляют модели машинного обучения к своим продуктам/услугам, что-то уже есть.

Это что-то — обычные процессы доставки программного обеспечения и стек инструментов DevOps.

На самом деле почти никто не начинает с нуля.

И, в конце концов, я не вижу мира, в котором стеки MLOps и DevOps соседствуют друг с другом и не являются одним стеком.

Я имею в виду, если вы согласны со мной в том, что «ML — это просто особый тип программного обеспечения», то MLOps — это просто особый тип DevOps.

Итак, разобраться в архитектуре и принципах MLOps — это здорово, но мне интересно, как это связано с расширением уже существующих принципов, процессов и стеков инструментов DevOps.

Состав команды Production ML

Давайте перенесем это обсуждение «MLOps — это часть DevOps» на структуру команды.

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

  • Кто-то, кто отвечает за надежность доставки программного обеспечения :)
  • Мы создаем продукты, поэтому должна быть четкая связь между продуктом и конечными пользователями.
  • Нам нужны люди, которые создают части продукта, специфичные для машинного обучения.
  • Нам нужны люди, которые создают части продукта, не относящиеся к машинному обучению.

Отлично, теперь, кто эти люди?

Я думаю, что команда будет выглядеть примерно так:

  • Надежность доставки программного обеспечения: инженеры DevOps и SRE (DevOps vs SRE здесь)
  • Программное обеспечение для машинного обучения: инженеры-программисты и специалисты по данным
  • Программное обеспечение, не связанное с ML: инженеры-программисты
  • Продукт: специалисты по продукту и эксперты в предметной области

Подождите, а где инженер MLOps?

Как насчет ML-инженера?

Позволь мне объяснить.

Инженер MLOps — это просто инженер DevOps

Это может быть немного экстремально, но я не вижу в этой команде особой роли инженера MLOps.

Инженер MLOps сегодня является либо инженером ML (создание программного обеспечения для ML), либо инженером DevOps. Здесь нет ничего особенного.

Должны ли мы называть инженера DevOps, который в основном занимается доставкой программного обеспечения на основе ML, инженером MLOps?

Я имею в виду, если вы действительно хотите, мы можем, но я не думаю, что нам нужна здесь новая роль. Это просто DevOps eng.

В любом случае, нам определенно нужен этот человек в команде.

Теперь, где вещи становятся интересными для меня здесь.

Специалист по данным против инженера машинного обучения против инженера-программиста бэкенда

Итак, во-первых, в чем реальная разница между специалистом по данным, инженером по машинному обучению, инженером-программистом и исследователем по машинному обучению?

Сегодня я вижу это так.

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

Инженеры-программисты хорошо разбираются в программном обеспечении и менее опытны в машинном обучении.

Специалисты по данным и инженеры по машинному обучению находятся где-то посередине.

Но это сегодня или даже вчера.

И есть несколько факторов, которые очень быстро изменят эту картину:

  • Потребности бизнеса
  • Зрелость образования ML

Давайте сначала поговорим о потребностях бизнеса.

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

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

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

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

Хорошо, значит, инженеры машинного обучения нам будут нужны больше, чем специалисты по данным, верно?

Не так быстро.

Давайте поговорим об образовании в области информатики.

Когда я изучал CS, у меня был один семестр ML. Сегодня в той же программе в 4 раза больше контента машинного обучения.

Я считаю, что упаковка/создание/развертывание заурядной модели машинного обучения станет общеизвестным делом для разработчиков бэкенда.

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

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

Итак, учитывая, что:

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

Я считаю, что текущие роли в команде машинного обучения будут развиваться:

  • Тяжелая роль машинного обучения - › специалист по обработке и анализу данных
  • Роль, связанная с программным обеспечением - › Инженер-программист бэкэнда

Итак, кто должен работать над специфическими для машинного обучения частями продукта?

Я считаю, что вам всегда будут нужны как специалисты по обработке данных, так и инженеры, работающие с программным обеспечением.

Инженеры по серверному программному обеспечению упакуют эти модели и «опубликуют» их в производственных конвейерах, которыми управляют инженеры DevOps.

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

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

Почему?

Потому что модели терпят неудачу.

И когда они выходят из строя, их трудно отладить и понять основную причину.

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

Но даже если часть модели машинного обучения работает «как положено», продукт, основанный на машинном обучении, может дать сбой.

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

Эксперты в предметной области

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

Особенно в МЛ. Особенно, когда вы не можете по-настоящему оценить свою модель без вас или эксперта в предметной области, взглянувшего на результаты.

И похоже, что эти профильные эксперты (SME) участвуют в процессах MLOps чаще, чем вы думаете.

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

ЧТО? Это было большим сюрпризом, поэтому мы посмотрели.

Оказывается, команды хотят, чтобы SME активно участвовали в ручной оценке/тестировании.

Команды в компаниях, специализирующихся на продуктах, ориентированных на ИИ, особенно хотят, чтобы их малые и средние предприятия участвовали в цикле разработки модели.

Это хорошо.

Не все можно протестировать/оценить с помощью такой метрики, как AUC или R2. Иногда людям просто нужно проверить, улучшились ли вещи, а не только показатели.

Эта система MLOps с участием человека на самом деле довольно распространена среди наших пользователей:

Таким образом, эта конструкция с участием человека делает настоящую автоматизацию невозможной, верно?

Это плохо, да?

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

У нас есть отдел обеспечения качества (QA) или исследователи пользователей, которые вручную тестируют и устраняют проблемы.

Это происходит поверх автоматических тестов. Так что не "или-или", а "и то и другое".

Но SME определенно присутствуют в (ручных) петлях обратной связи MLOps.

Принципы и составляющие: в чем отличие от DevOps

Мне очень понравилось то, что сделали авторы статьи THE MLOps.

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

Они переходят в компоненты (инструменты), которые позже решают разные задачи.

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

Инструменты являются временными. Принципы вечны. Так сказать.

И, как мне кажется, некоторые из ключевых принципов MLOps отсутствуют, а некоторые другие должны быть «упакованы» по-другому.

Что еще более важно, некоторые из этих вещей не являются «настоящим MLOps», а на самом деле являются просто вещами DevOps.

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

Это наша добавленная стоимость к текущему ландшафту. Не изобретать велосипед и не ставить на нем штамп MLOps.

Итак, давайте погрузимся.

Принципы

Таким образом, CI/CD, управление версиями, совместная работа, воспроизводимость и непрерывный мониторинг — это то, что вы также имеете в DevOps. И многие вещи, которые мы делаем в машинном обучении, на самом деле вполне подпадают под это.

Давайте углубимся в эти нюансы.

CI/CD + CT/CE + петли обратной связи

Если мы говорим, что MLOps — это просто DevOps + «кое-что», то CI/CD — это основной принцип.

С CI/CD вы получаете автоматически запускаемые тесты, утверждения, обзоры, циклы обратной связи и многое другое.

С MLOps приходят CT (непрерывное обучение/тестирование) и CE (непрерывная оценка), которые необходимы для чистого процесса MLOps.

Это отдельные принципы?

Нет, они являются частью одного и того же принципа.

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

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

А оценка/тестирование просто, ну, тестирование?

Что в нем такого особенного?

Возможно, это ручной осмотр новых моделей.

Это очень похоже на просмотр и утверждение запроса на включение путем просмотра различий и проверки того, что (часто) пройдены автоматические тесты.

Различия между не только кодом, но и моделями/наборами данных/результатами. Но все равно дифф.

Затем вы утверждаете, и он попадает в производство.

Я действительно не понимаю, почему CT/CE не является просто частью CI/CD. Если не в названии, то хотя бы в их объединении в принцип.

Механизм проверки и утверждения через CI/CD работает очень хорошо.

Мы не должны встраивать совершенно новые механизмы утверждения моделей в инструменты MLOps.

Мы должны интегрировать CI/CD в как можно больше циклов обратной связи. Точно так же, как люди делают с QA и тестированием в обычной разработке программного обеспечения.

Оркестрация рабочих процессов и разработка пайплайнов

Когда мы говорим об организации рабочего процесса в ML, мы обычно смешиваем две вещи.

Одним из них является планирование, выполнение, повторные попытки и кэширование. Что мы делаем, чтобы убедиться, что конвейер машинного обучения работает правильно. Это классический вариант использования DevOps. Ничего нового.

Но здесь есть нечто особенное: возможность легко создавать конвейеры машинного обучения.

Конвейерная разработка?

Ага.

При создании интеграции с Кедро мы узнали об этом различии.

Kedro прямо заявляет, что они представляют собой основу для конвейерной разработки, а НЕ оркестровки рабочего процесса. Они говорят:

«Мы сосредоточены на другой проблеме, которая представляет собой процесс создания конвейеров, а не их запуск, планирование и мониторинг».

Вы можете использовать разные бэкэнд-раннеры (такие как Airflow, Kubeflow, Argo, Prefect), но вы можете создавать их в одном фреймворке.

Конвейерная разработка — это уровень взаимодействия с разработчиками (DevEx) поверх оркестраторов, предназначенный для случаев использования в науке о данных. Это упрощает совместную работу над этими конвейерами.

Совместная работа и повторное использование пайплайнов разными командами были теми причинами, по которым был создан Kedro.

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

Управление версиями и отслеживание/регистрация метаданных машинного обучения

Это не два отдельных принципа, а фактически части одного.

Мы потратили тысячи часов, разговаривая с пользователями/покупателями/потенциальными клиентами об этом.

И знаете, чему мы научились?

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

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

Они часто взаимозаменяемо используют управление версиями и отслеживание.

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

Ты хочешь знать:

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

Только тогда можно говорить о воспроизводимости и прослеживаемости.

И поэтому в ML нам нужно это «управление версиями +», которое в основном представляет собой управление версиями не только артефакта модели, но и всего, что его окружает (метаданные).

Так что, возможно, принцип «управления версиями» должен быть просто более широким «управление версиями ML» или «управление версиями +», которое также включает отслеживание/запись.

Отладка, проверка и сравнение модели (отсутствует)

«Отладка, проверка и сравнение» моделей машинного обучения, экспериментов и запусков конвейера — это отсутствующий принцип в статье MLOps.

Авторы говорили о вещах, связанных с управлением версиями, отслеживанием и мониторингом, но принцип, который, как мы видим, нужен людям, не был упомянут:

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

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

Когда модели терпят неудачу в производстве, вы не можете сразу понять из журналов, что произошло (в большинстве случаев).

Вам нужно смотреть, проверять, отлаживать и сравнивать версии моделей.

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

Но что произойдет позже, когда эти созданные вручную модели попадут в конвейеры переобучения?

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

Особенно, когда дела идут не так, как планировалось, и новая версия модели на самом деле не лучше старой.

И эти сравнения и проверки выполняются вручную.

Автоматизированный непрерывный мониторинг (+ ручная периодическая проверка)

Так что я за автоматизацию.

Автоматизация рутинных задач. Автоматизация модульных тестов. Автоматизация проверки работоспособности.

И когда мы говорим о непрерывном мониторинге, это в основном автоматизированный мониторинг различных проверок работоспособности ML.

Прежде чем сделать это, вам нужно ответить на два вопроса:

  • Что, как вы знаете, может пойти не так, и можете ли вы настроить проверки работоспособности для этого?
  • Есть ли у вас реальная необходимость настраивать эти проверки работоспособности?

Да, многим командам на самом деле не нужен мониторинг производственной модели.

Я имею в виду, вы можете осматривать вещи вручную раз в неделю. Найдите проблемы, о которых вы не знали. Узнайте больше о своей проблеме.

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

«Исследователи считают, что смещение распределения очень важно, но проблемы с производительностью модели, возникающие из-за естественного сдвига распределения, внезапно исчезают после переобучения». — Шрея Шанкар

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

Хорошо, но некоторым командам это нужно, 100%.

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

Но даже в этом случае вам нужно время от времени вручную проверять/отлаживать/сравнивать свои модели.

Чтобы узнать что-то новое, чего вы не знали о своей системе машинного обучения.

Тихие ошибки, которые не может уловить ни одна метрика.

Я думаю, это был длинный способ сказать, что:

Вам нужен не только непрерывный мониторинг, но и ручная периодическая проверка.

Управление данными

Управление данными в ML — важный и гораздо более масштабный процесс, чем просто контроль версий.

У вас есть маркировка данных, просмотр, исследование, сравнение, подготовка и совместная работа над наборами данных.

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

Кроме того, в зависимости от того, насколько быстро меняются ваши производственные данные или как вам нужно настроить наборы данных для оценки и тестовые наборы, ваши потребности в данных будут определять остальную часть вашего стека. Например, если вам нужно очень часто переобучаться, вам может не понадобиться компонент мониторинга моделей, или если вы решаете только задачи CV, вам может не понадобиться Feature Store и т.д.

Сотрудничество

Когда авторы говорят о сотрудничестве, они говорят:

«Сотрудничество P5. Сотрудничество обеспечивает возможность совместной работы над данными, моделью и кодом».

И они показывают, что это сотрудничество (P5) происходит в репозитории исходного кода:

Это далеко от реальности, которую мы наблюдаем.

Сотрудничество также происходит с:

  • Эксперименты и итерации построения модели
  • Аннотации данных, очистка, совместное использование наборов данных и функций
  • Конвейерная разработка и повторное использование/передача
  • Проверка/утверждение CI/CD
  • Петли обратной связи «человек в цикле» с экспертами в предметной области
  • Передача моделей
  • Обработка проблем с моделями в производстве и общение с передовой (пользователи, специалисты по продукту, эксперты в предметной области) и создатели моделей

И, чтобы быть ясным, я не думаю, что мы, как сообщество MLOps, делаем здесь хорошую работу.

Совместная работа в репозиториях исходного кода — хорошее начало, но она не решает и половины проблем совместной работы в MLOps.

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

Компоненты

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

Но есть несколько лишних вещей и нюансов к существующим ИМХО.

  • Конвейерная разработка
  • Управление данными
  • Хранилище метаданных ML (да, я знаю, я предвзят, но я верю, что, в отличие от программного обеспечения, эксперименты, отладка и ручная проверка играют центральную роль в ML)
  • Мониторинг моделей как плагин к мониторингу приложений
  • Нет необходимости в реестре моделей (да)

Исполнители рабочих процессов и среды разработки рабочих процессов

Как мы уже говорили об этом в принципе, у нас есть две подкатегории компонентов оркестровки рабочего процесса:

  • Инструменты оркестровки/выполнения рабочих процессов
  • Конвейерные среды разработки

Первый заключается в том, чтобы убедиться, что конвейер работает правильно и эффективно. В этом вам помогут такие инструменты, как Prefect, Argo и Kubeflow.

Второй касается devex создания и повторного использования пайплайнов. В эту категорию попадают такие фреймворки, как Kedro, ZenML и Metaflow.

Управление данными

Что этот компонент (или набор компонентов) в идеале должен решать:

  • Маркировка данных
  • Подготовка функций
  • Управление функциями
  • Управление версиями набора данных
  • Обзоры и сравнение наборов данных

Сегодня кажется, что это делается либо с помощью собственного решения, либо с помощью набора инструментов:

Должны ли они быть объединены в одну «сквозную платформу управления данными» или решены с помощью лучших в своем классе модульных и совместимых компонентов?

Я не знаю.

Но я считаю, что сотрудничество между пользователями этих разных частей очень важно.

Особенно сейчас, в этом более ориентированном на данные мире MLOps. И тем более, когда эти наборы данных просматривают эксперты в предметной области.

И ни один инструмент/платформа/стек сегодня не справляется со своей задачей.

Хранилище метаданных машинного обучения (только одно)

В статье хранилища метаданных ML упоминаются в трех контекстах, и неясно, говорим ли мы об одном компоненте или о нескольких. Авторы говорят о:

  • Хранилище метаданных ML, настроенное рядом с компонентом Experimentation
  • Хранилище метаданных машинного обучения, настроенное с помощью Workflow Orchestration
  • Хранилище метаданных машинного обучения, настроенное с помощью реестра моделей

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

  • «воспроизводимость»
  • «отладка, сравнение, проверка»
  • «управление версиями+» (управление версиями + отслеживание/регистрация метаданных машинного обучения), которое включает метаданные/результаты любых тестов и оценок на разных этапах (например, проверки работоспособности и результаты тестов кандидатов на выпуск модели перед тем, как они попадут в реестр моделей)

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

  1. Хранилище метаданных машинного обучения, настроенное рядом с компонентом "Эксперимент"

Это довольно легко. Может быть, потому что я постоянно слышу об этом в Нептуне.

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

Вы хотите иметь возможность воспроизвести результаты и иметь версии готовых к производству моделей.

Вы хотите «следить» за конфигурациями и результатами эксперимента/запуска, параметрами, метриками, кривыми обучения, диагностическими диаграммами, объяснениями и примерами прогнозов.

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

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

«Отслеживание экспериментов» кажется отличным названием, когда речь идет об экспериментах.

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

Я думаю, что хранилище метаданных машинного обучения — это более подходящее название, потому что оно отражает суть этого компонента. Упростите "регистрацию, хранение, сравнение, организацию, поиск, визуализацию и совместное использование метаданных модели машинного обучения". .

Хорошо, объяснил одно хранилище метаданных машинного обучения. Еще два впереди.

2. Хранилище метаданных машинного обучения, настроенное с помощью Workflow Orchestration

Это интересно, так как есть две отдельные задачи, которые люди хотят решить с помощью этого: связанное с машинным обучением (сравнение, отладка) и связанное с программным обеспечением/инфраструктурой (кэширование, эффективное выполнение, мониторинг использования оборудования). .

Из того, что я вижу среди наших пользователей, эти две задачи решаются двумя разными типами инструментов:

  • Люди решают задачи, связанные с машинным обучением, используя собственные решения или интегрируясь с внешними средствами отслеживания экспериментов. Они хотят, чтобы результаты повторного обучения находились там же, где и результаты экспериментов. Имеет смысл, поскольку вы хотите сравнить/проверить/отладить их.
  • Работа, связанная с программным обеспечением/инфраструктурой, выполняется либо компонентами оркестратора, либо традиционными программными инструментами, такими как Grafana, Datadog и т. д.

Подождите, так не должно ли хранилище метаданных ML, настроенное рядом с инструментом оркестрации рабочих процессов, собирать все метаданные о выполнении конвейера, включая часть, относящуюся к ML?

Может быть, так и должно быть.

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

Они отлично справляются с другими вещами, такими как:

  • кэширование промежуточных результатов,
  • повторная попытка на основе флагов выполнения,
  • распределение выполнения по доступным ресурсам
  • досрочное прекращение выполнения

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

Итак, если люди используют средство отслеживания экспериментов (или хранилище метаданных машинного обучения, ориентированное на запуск/модель) для материалов, связанных с машинным обучением, что должно произойти с этим другим хранилищем метаданных машинного обучения, ориентированным на конвейер/исполнение?

Это должно быть просто частью оркестратора рабочего процесса. И это часто так.

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

Хорошо, давайте поговорим о третьем.

3. Хранилище метаданных машинного обучения, настроенное с помощью реестра моделей

Цитирую газету:

«Другое хранилище метаданных может быть настроено в реестре модели для отслеживания и регистрации метаданных каждого задания обучения (например, даты и времени обучения, продолжительности и т. д.), включая метаданные для конкретной модели — например, используемые параметры и результирующую производительность. метрики, происхождение модели: используемые данные и код»

Итак, почти все, что здесь перечислено, регистрируется в трекере экспериментов.

Что там обычно не регистрируется? Вероятно:

  • Результаты предварительных тестов, журналы переобучения, оценки, инициированные CI/CD.
  • Информация о том, как модель была упакована.
  • Информация о том, когда модель была утверждена/переведена между стадиями (стадия/производство/архив).

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

Все, что не работает, например временные метки перехода между этапами, сохраняется в таких местах, как Github Actions, Dockerhub, Artifactory или инструменты CI/CD.

Я не думаю, что осталось что-то записывать в специальное «хранилище метаданных ML, настроенное рядом с реестром моделей».

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

В этом так много смысла:

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

Но нет необходимости в другом хранилище метаданных машинного обучения.

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

Хорошо, раз уж мы заговорили о «реестре моделей», мне нужно обсудить еще кое-что.

Реестр моделей. Нам это вообще нужно?

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

В то же время, если бы вы спросили меня, есть ли необходимость в реестре моделей в MLOps/DevOps в долгосрочной перспективе, я бы сказал: «Нет!».

Для нас «реестр моделей» — это способ сообщить пользователям и сообществу, что наше хранилище метаданных машинного обучения является подходящим компонентом стека инструментов для хранения и управления метаданными машинного обучения о ваших производственных моделях.

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

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

Не подойдет ли какой-нибудь реестр артефактов, например Docker Hub или JFrog Artifactory?

Разве вы не хотите просто поместить упакованную модель в диаграмму Helm в Kubernetes и на этом закончить?

Конечно, нужны ссылки на историю создания модели или результаты опытных испытаний.

Вы хотите убедиться, что схема ввода-вывода новой модели соответствует ожидаемой.

Вы хотите утверждать модели в том же месте, где вы можете сравнить предыдущие/новые.

Но все эти вещи на самом деле не «живут» в компоненте реестра новой модели, не так ли?

В основном они используются в конвейерах CI/CD, реестре докеров, инструментах мониторинга производственной модели или средствах отслеживания экспериментов.

Их нет в блестящем новом компоненте MLOps, называемом реестром моделей.

Вы можете решить это с хорошо интегрированным:

  • Циклы обратной связи CI/CD, которые включают ручное одобрение и кнопки развертывания (посмотрите, как это делают CircleCI или GitLab).
  • + Инструмент упаковки модели (чтобы получить развертываемый пакет)
  • + Реестр контейнеров/артефактов (чтобы было место с готовыми моделями)
  • + Хранилище метаданных машинного обучения (чтобы получить полную историю построения модели)

Верно?

Могу ли я объяснить своим друзьям DevOps необходимость отдельного инструмента для реестра моделей?

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

Но не потому ли, что у них нет полного понимания того, что предлагают инструменты DevOps?

Я думаю, что это может быть.

И, по правде говоря, у некоторых команд есть собственное решение для реестра моделей, которое представляет собой лишь тонкий слой поверх всех этих инструментов.

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

Мониторинг модели. Подожди, какой?

«Мониторинг моделей» берет верх, когда дело доходит до самого расплывчатого и запутанного названия в пространстве MLOps («хранилище метаданных ML» заняло второе место, кстати).

«Модельный мониторинг» означает шесть разных вещей для трех разных людей.

Мы поговорили с командами, которые означали:

  • (1) Мониторинг производительности модели в рабочей среде: посмотрите, снижается ли производительность модели со временем, и вам следует повторно обучить ее.
  • (2) Мониторинг распределения входных/выходных данных модели: наблюдайте, изменяется ли распределение входных данных, функций или распределения прогнозов с течением времени.
  • (3) Мониторинг обучения и повторного обучения модели:просматривайте кривые обучения, распределение предсказаний обученной модели или матрицу путаницы во время обучения и повторного обучения.
  • (4) Мониторинг оценки и тестирования модели: регистрируйте показатели, диаграммы, прогнозы и другие метаданные для автоматизированных конвейеров оценки или тестирования.
  • (5) Мониторинг показателей инфраструктуры: смотрите, сколько процессорного/графического процессора или памяти используют ваши модели во время обучения и логических выводов.
  • (6) Мониторинг конвейеров CI/CD для машинного обучения. Просматривайте оценки заданий конвейера CI/CD и визуально сравнивайте их.

Например:

  • Neptune делает (3) и (4) очень хорошо, (5) просто нормально (работает над этим), но мы видели, как команды использовали его также для (6)
  • Prometheus + Grafana действительно хороши в (5), но люди используют их для (1) и (2)
  • Whylabs или Arize AI действительно хороши в (1) и (2)

Поскольку я верю, что MLOps будет просто расширением DevOps, нам нужно понять, какое место в MLOps сегодня и в будущем занимают инструменты наблюдения за программным обеспечением, такие как Datadog, Grafana, NewRelic и ELK (Elastic, Logstash, Kibana).

Кроме того, некоторые части по своей сути не являются непрерывными и неавтоматическими. Например, сравнение/проверка/отладка моделей. В нем участвуют эксперты в предметной области и специалисты по данным. Я не понимаю, как это становится непрерывным и автоматическим.

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

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

Так что, возможно, следующее разделение сделает вещи более очевидными:

  • Наблюдаемость и мониторинг производственной модели (WhyLabs, Arize)
  • Мониторинг обучения, переобучения, оценки и тестирования модели (MLflow, Neptune)
  • Мониторинг инфраструктуры и приложений (Grafana, Datadog)

Мне бы очень хотелось узнать, что руководители Datadog и Arize AI думают о своем месте в DevOps/MLOps в долгосрочной перспективе.

Является ли обнаружение дрейфа просто «плагином» для стека мониторинга приложений? Я не знаю, но это кажется разумным, на самом деле.

Заключительные мысли и открытые вызовы

Если есть что-то, что я хочу, чтобы вы вынесли из этой статьи, так это это.

Мы не должны думать о том, как создать стек MLOps с нуля.

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

Авторы говорят:

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

…

Особенно роли, связанные с этими действиями, должны быть ориентированы на продукт при разработке продуктов ML».

Я думаю, нам нужен еще больший сдвиг мышления:

Модели машинного обучения – › продукты машинного обучения – › программные продукты, использующие машинное обучение – › просто еще один программный продукт

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

Я не понимаю, почему ML является здесь особой снежинкой в ​​​​долгосрочной перспективе. Я действительно не знаю.

Но даже если посмотреть на представленный стек MLOps, какая прагматичная версия v1 этого действительно понадобится 99% команд?

Авторы опросили специалистов по машинному обучению из компаний с более чем 6500 сотрудников. Большинство компаний, занимающихся машинным обучением в продакшене, не такие. И стек MLOps намного проще для большинства команд.

Особенно те, кто занимается ML/MLOPs в разумных масштабах.

Они выбирают, может быть, 1 или 2 компонента, в которых они углубляются, а для остальных у них есть супер базовые вещи.

Или вообще ничего.

Вам не нужно:

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

На самом деле нет.

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

В какой-то момент они могут увеличить свой стек MLOps до того, что мы видим в этой статье.

Или пойти на конференцию DevOps и понять, что они должны просто расширять стек DevOps;)

Я иногда делюсь своими мыслями о ландшафте ML и MLOps в моем профиле Linkedin. Не стесняйтесь следовать за мной там, если это интересная тема для вас. Кроме того, свяжитесь, если вы хотите поговорить об этом.