Это первая часть из двух частей, в которых я пытаюсь обобщить некоторые из моих представлений о параллелях между DevOps и MLOps.
Когда я впервые начал заниматься MLOps, мне пришлось очень долго учиться. Одна из вещей, которые помогли мне подняться, - это посмотреть на параллели с DevOps. Если у вас есть опыт разработки программного обеспечения, это один из самых простых способов понять, почему существует MLOps.
В DevOps вы объединяете элементы программирования, тестирования и эксплуатации при разработке программного обеспечения. Цель состоит в том, чтобы взять то, что часто является разрозненными процессами, и переработать их в логический и последовательный процесс, который может продвигаться вперед с минимальными сбоями.
MLOps преследует аналогичные цели. Вы пытаетесь построить оптимизированный процесс, связывающий воедино разрозненные части жизненного цикла машинного обучения. Часто между проектированием, разработкой модели и операциями есть пробелы, поэтому вы хотите унифицировать это, объединив прием данных, оценку, развертывание, а также обучение и повторное обучение модели. Как и в случае с DevOps, цель состоит в том, чтобы создать единый согласованный процесс, над которым все работают.
Без MLOps внедрение моделей машинного обучения в производство обычно означает использование одного из двух подходов:
- Специалист по анализу данных должен носить множество шляп и делать все, от очистки данных и выбора правильной модели до настройки кластера Kubernetes и работающей инфраструктуры.
- В качестве альтернативы специалист по данным может вручную передать свою модель инженеру по машинному обучению.
Пока все похоже. Но есть несколько ключевых отличий:
01 Эксперименты
Одно из самых больших различий между MLOps и DevOps - это степень свободы, которую вы можете экспериментировать и тестировать, чтобы увидеть, какой подход дает лучший результат. В проектах машинного обучения специалисты по обработке данных обычно пробуют один подход к решению проблемы, а через несколько дней тестируют другой. Вы можете повозиться с несколькими в течение нескольких недель или даже месяцев.
Традиционная разработка программного обеспечения также включает в себя некоторые эксперименты, но эксперименты, как правило, короткие и часто проводятся отдельно от основного проекта. Вы нечасто увидите, как разработчик вложил недельную работу в определенное направление, решит, что это не совсем правильно, а затем бросит это в поисках другого пути.
02 Данные по сравнению с кодом
Еще одно ключевое отличие состоит в том, что в MLOps задействованы данные, а в DevOps вы в основном заботитесь о коде. Проект DevOps может включать данные, но основные рабочие потоки связаны с правильным программированием.
Методы и процессы управления кодом и данными очень разные. Хотя в MLOps задействован код, если вы сложите код, необходимый для проекта ML, со всеми необходимыми данными, он, вероятно, составит долю одного процента.
Мы подробнее рассмотрим различия во второй части блога. Чтобы получить представление о первой части, мы поговорили с Дэмианом Брэди, консультантом по облачным DevOps в Microsoft Australia, чтобы узнать его мнение о сравнении этих двух наборов практик. Он говорит, что на высоком уровне они могут выглядеть очень похожими, но если вы углубитесь, то увидите важные различия.
[Смотрите исходное видео здесь]
Чем MLOps отличается от DevOps?
Дамиан Брэди: «С точки зрения высокого уровня это почти одно и то же. DevOps - это передача какого-то решения из вашей головы в руки людей и обеспечение его ценности и эффективности.
‘В этом смысле MLOps - то же самое. Неважно, это небольшой фрагмент кода, обновление базы данных или прогностическая модель. Он отличается некоторыми аспектами того, как вы на самом деле попадаете в цель, и процессами, задействованными в создании этой модели, а затем в ее развертывании. Тем не менее, концептуально я не думаю, что это так уж и отличается.
‘Одна из опасностей модных словечек заключается в том, что люди могут чрезмерно упрощать и говорить:« О, это DevOps, и поэтому мы можем использовать инструменты и процессы, которые мы уже знаем. Возможно, вы просто примените gitflow к проекту машинного обучения и CI, чтобы каждый раз, когда кто-то меняет код, вы просто выполняете обучающий прогон, а затем развертываете его в рабочей среде.
‘У вас должны быть действительно глубокие карманы, если вы собираетесь это делать. Вы должны знать, где есть ограничения ».
Конечно, если копнуть глубже, можно заметить практические различия, говорит он, особенно между машинным обучением и традиционной разработкой программного обеспечения.
«Каденция определенно различается между традиционным программным обеспечением и проектами машинного обучения; гораздо больше экспериментов - по крайней мере, на начальном этапе.
«Необходимость проверять то, что вы производите, в сравнении с реальным миром, прежде чем вы действительно узнаете, будет ли это работать должным образом, - это более важно в машинном обучении и прогнозном моделировании, чем в традиционном программном обеспечении.
«Если вы думаете о создании традиционного программного обеспечения, вы можете довольно хорошо его протестировать - даже передать его в отдел контроля качества и проделать все такое, прежде чем отправлять его в производство. Если это не сработает, как ожидалось, во многих организациях просто скажут: «Что ж, мы выполнили все эти требования. Он выполняет то, что должен делать в производственной среде, и люди его используют, поэтому мы будем его повторять ».
Я не думаю, что он всегда может сказать это с помощью машинного обучения. Результат, которого вы ищете, является лучшим результатом того, что вы создали, поэтому вам нужно что-то действительно имеющее законную ценность для конечного пользователя, а не то, что ставит галочку в поле ».
Сообщество MLOps - это место, куда любой может прийти и получить представление о текущей экосистеме. Чтобы узнать больше, зайдите на Slack, youtube или подкасты и присоединитесь к беседе.
