Как MLOps повлияет на роль специалистов по данным

За последние несколько десятилетий я стал свидетелем значительных сдвигов как в функциях инженеров-программистов, так и в методах создания работающего программного обеспечения. Сегодня мне любопытно, как роль ученых данных будет развиваться в течение следующего десятилетия. В этой статье будет рассмотрено, как эта роль будет развиваться, и это основано исключительно на моем личном опыте в качестве руководителя инженерного отдела, архитектора и инженера-программиста в прошлом, а также на моем недавнем опыте начинающего специалиста по данным в магистратуре. Программа Data Science (MDS) в Университете Британской Колумбии. Я надеюсь, что читатели найдут эту статью познавательной и интересной.

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

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

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

Какие культурные нормы, обычаи и ресурсы необходимы для этого?

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

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

Жизнь до DevOps?

Я видел, как многочисленные методы доставки программного обеспечения и продуктов принимали различные формы и названия, от Быстрой разработки приложений (1990–2010 гг.) до Гибкого и экстремального программирования (1997 г. по настоящее время) и, наконец, DevOps (2008 г. по настоящее время). который развился из Agile и роста программного обеспечения как услуги (SaaS).

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

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

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

Переход от одной фазы к другой был четко определен и понятен; с другой стороны, возвращение на два или более шага назад не было четко определено и представляло собой проблему. Например, если вы работали инженером-испытателем и поняли, что программное обеспечение не удовлетворяет требованиям клиента, то вернуться к архитекторам или руководству продукта (которые определили требования) с обратной связью и пересмотреть требования было непростой задачей. Управление изменениями было еще более сложным процессом, и помимо, как вы уже догадались, «отдела» в него входили собственные специалисты. Весь процесс работал исходя из предположения, что исходные данные для каждой фазы были идеальными, а «специалисты» на каждой фазе специализировались еще дальше.

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

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

Знакомство с DevOps

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

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

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

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

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

Они были разработаны с нуля с целью обеспечения простоты развертывания, мониторинга, отладки, обновления и эксплуатации. Эти компоненты программного обеспечения являются не просто целями проектирования или предложениями, которые были записаны в проектной документации высокого уровня; скорее, это фундаментальные дисциплины, которые естественным образом поддерживаются тем фактом, что разработчики также являются операторами сервиса. Угадайте, что произойдет, если он выйдет из строя при недостаточном количестве точек регистрации или мониторинга в системе? Вся команда заинтересована в обновлении программного обеспечения, чтобы они могли не только исправить проблему, но и иметь соответствующую регистрацию и возможность наблюдения, чтобы иметь возможность устранять аналогичные проблемы в будущем и избегать боли, связанной с отсутствием достаточного количества сигналов для нейтрализации. проблема, пока она все еще возникает в производстве.

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

Введение в MLOps

MLOps, что означает «операции машинного обучения», родился на пересечении DevOps, Data Engineering и ML. Хотя концептуально это сопоставимо с DevOps, выполнение MLOps отличается от DevOps двумя способами:

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

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

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

Пять мифов о MLOps

Все дело в модели. Модели не существуют сами по себе; скорее, они встроены в уже существующие программные системы. Они не являются конечным продуктом; скорее, конечный продукт — это услуга, полезная для клиента. Услуги, требующие интерпретации мира (зрение, звук, речь или НЛП), предсказания, обнаружения, рекомендации или оптимизации, являются примерами типов услуг, подпадающих под сферу применения машинного обучения.
Вы можете легко перейти от разработки/лаборатории к работе. Масштаб производственных сред значительно отличается от масштабов сред разработки и лабораторных установок. Это связано с тем, что узкие места в системе не будут видны разработчикам, пока они работают в лабораторной среде.
Когда ваша модель будет успешно развернута, ваша работа будет завершена. Это аналогично утверждению, что работа инженера-программиста завершается, когда приложение скомпилировано и успешно проходит все тесты. На самом деле они только начали свой путь, потому что большая часть времени инженера-программиста тратится на поддержку существующих программ, а не на создание новых.
Нас интересует только один показатель — точность. Ну, точность важна только при выборе и обучении модели; однако модель машинного обучения не существует изолированно; конечный продукт — это услуга, и существует слишком много других показателей, которые важнее точности, таких как качество услуги, доступность, задержка и т. д.
Все дело в разработке, вам не нужно разбираться в модели. В этой конкретной области специалисты по данным должны обучать не только себя, но и своих коллег по agile-команде, чтобы глубже понять модель, а также различные точки соприкосновения, которые необходимо тщательно контролировать и контролировать.

Млопс вызовы

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

Из-за экспериментального характера работыспециалисты по данным должны вносить коррективы в различные функции, включая гиперпараметры, параметры и модели, а также отслеживать и управлять как данными, так и кодом. базы для получения воспроизводимых результатов.
Трудность воспроизводимости является прямым результатом того факта, что необходимо учитывать большее количество переменных.
Автоматическое развертывание моделей затруднено, потому что мы не можем просто развернуть модель машинного обучения, обученную в автономном режиме, например, в качестве службы прогнозирования. Это представляет собой проблему. Это не так просто, как развертывание новых версий микросервисов, как мы сейчас делаем в крупномасштабных приложениях SaaS.
Производительность моделей машинного обучения, которые уже находятся в производстве, может пострадать не только из-за неоптимального кодирования, но и из-за постоянного изменения профилей данных. Нужно подготовиться к тому, что модели более подвержены износу, чем традиционные программные системы. У вас должен быть контур обратной связи, способный подавать соответствующие сигналы в случае необходимости вмешательства оператора, переобучения или тонкой настройки или требуется полная смена модели.
Не ожидается, что только инженеры-программисты составят гибридную группу, которая потребуется для создания и развертывания моделей в рабочей среде. Специалисты по данным или исследователи машинного обучения обычно включаются в команду, работающую над проектом машинного обучения. Эти люди уделяют большое внимание исследовательскому анализу данных, разработке моделей и экспериментам. Есть вероятность, что они не являются опытными инженерами-программистами, способными разрабатывать сервисы производственного уровня, и MLOps должны заполнить этот пробел.

Конвейеры машинного обучения + MLOps

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

(Данные) Как обеспечить безопасный доступ к данным.
(Модель) Как сделать инженерную модель воспроизводимой.
(Данные+модель) Как отслеживать, записывать и сравнивать эксперименты.
(Модель) Как обслуживать модели масштабируемым, надежным и эффективным способом.
(Модель) Как внедрить модели в производство и сделать переход от разработки к производству плавным.
(Данные+Модель+Развертывание) Как проводить тестирование на каждом этапе конвейера.
(Модель + Развертывание) Как отслеживать модель в производстве в поисках ключевых сигналов.
(Внедрение) Как сделать инфраструктуру эластичной и простой в развертывании, масштабировании, масштабировании и демонтаже (Инфраструктура как код).
(Данные+Модель+Развертывание) Как версионировать все артефакты, а не только код.
(Данные+Модель+Развертывание) Как добиться полностью автоматизированной непрерывной интеграции и управляемой доставки.

Итак, что это значит для специалистов по данным?

Специалисты по данным будут нести ответственность не только за анализ данных и построение модели, удовлетворяющей требованиям (ранние этапы), но также за развертывание и поддержку модели в производственной среде, а также за все операционные аспекты и не только исследовательский анализ данных (EDA), проектирование признаков и обучение моделей.

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

Недопустимо, чтобы группы машинного обучения и инженеры работали независимо друг от друга в разрозненных условиях. Ожидается, что специалисты по данным должны хорошо понимать не только «Что» и «Почему», но и «Как». Для них будет становиться все более важным также давать ответы на вопросы «как». Важные вопросы, которые следует задать, включают: «Почему они выбрали эту модель?» и «Какие данные им нужны для обучения модели?». Возможность отвечать на такие вопросы, как «Как мы можем сделать конвейеры воспроизводимыми?» и «Как мы можем упростить развертывание и обновление?», станет важной. через некоторое время.

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

Резюме и заключительные мысли

Точно так же, как роль инженера-программиста претерпела значительные изменения за последнее десятилетие в результате подъема DevOps, я считаю, что работа специалистов по обработке и анализу данных со временем изменится и будет охватывать более широкий круг обязанностей, чем на данный момент это так.
Специалисты по данным должны использовать MLOps для расширения своих карьерных возможностей, а не только для очистки данных, споров и обучения моделей.
Независимо от того, как развивается роль специалистов по данным, это захватывающее время для специалистов по данным, потому что приложения машинного обучения демонстрируют способность решать проблемы, которые ранее считались неразрешимыми.
Лично мне не терпится применить на практике то, чему я научился на программе Masters of Data Science в Университете Британской Колумбии, а также то, что я узнал из опыта в области разработки программного обеспечения и услуг.