Что такое МЛОпс?

DevOps сочетается с данными и машинным обучением

Вам когда-нибудь нравилось что-то в Instagram, а затем почти сразу же появлялся соответствующий контент в вашей ленте? Или искать что-то в Google, а через несколько секунд получать спам с рекламой именно этой вещи? Это симптомы все более автоматизированного мира. За кулисами они являются результатом самых современных конвейеров MLOps. Мы рассмотрим MLOps и то, что нужно для эффективного развертывания моделей машинного обучения.

Мы начнем с обсуждения некоторых ключевых аспектов DevOps. Затем мы объясним, как внедрение данных и моделей нарушает стандартные методы. Это приводит к MLOps. Существующая практика, например конвейеры CI/CD, нуждается в корректировке. Вводятся новые практики, такие как непрерывное обучение. В конце мы обсудим MLOps в регулируемой среде и то, как это связано с интерпретируемостью модели.

DevOps

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

Конвейеры CI/CD

Все программное обеспечение должно быть разработано, тщательно протестировано и развернуто, прежде чем его можно будет использовать. DevOps пытается повысить эффективность этого процесса, создавая и автоматизируя конвейеры CI/CD. Непрерывная интеграция (CI) включает в себя процессы, связанные с разработкой программного обеспечения. Непрерывное развертывание/доставка (CD) включает в себя процессы, связанные с перемещением программного обеспечения в рабочую среду. Лучшие практики и культура заложены в управлении этими конвейерами.

Давайте рассмотрим, как мы справляемся с первым аспектом, непрерывной интеграцией. Как правило, это требует, чтобы разработчики регулярно отправляли изменения кода в удаленный репозиторий. Затем запускаются автоматические модульные и интеграционные тесты, чтобы немедленно выявить любые проблемы с кодом. DevOps определит рекомендации для реализации этих шагов. Мы реализуем их с помощью инструментов, таких как git для отправки изменений или junit для запуска модульных тестов. Чтобы это работало, должна существовать культура регулярной фиксации кода. Это то, что не является естественным для большинства людей.

Мониторинг

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

Коммуникация

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

MLOps = DevOps + данные + модели

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

Разработка данных и моделей

Без данных нет машинного обучения. Данные должны быть в нужном месте в нужное время. Для специалистов по данным это означает, что для обучения моделей должно быть достаточно исторических данных. Нам также понадобятся более свежие данные, чтобы делать прогнозы. В крайних случаях нам могут понадобиться данные в режиме реального времени. Инженеры данных должны управлять потоком данных в хранилищах данных. В MLOps это делается с помощью конвейеров данных CI/CD. Инженерам данных потребуются новые инструменты для их разработки.

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

Конвейер CI/CD

Модель может показаться загадочной, но после ее обучения она ничем не отличается от обычного кода. Это набор инструкций, которые будут принимать входные данные (то есть данные) и давать выходные данные (то есть прогнозы). После разработки мы можем отправить окончательную модель в основной конвейер CI/CD. Затем запускаются автоматические модульные тесты и интеграционные тесты, чтобы убедиться в отсутствии проблем с новой моделью.

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

Мониторинг

Для вычислительных ресурсов модели мониторинга аналогичны программному обеспечению для мониторинга. Нам нужно убедиться, что модель использует ЦП, ОЗУ, пропускную способность и дисковое пространство, как и ожидалось. Предсказания модели не должны создавать проблем с задержкой. Большинство этих проблем решается с помощью существующих методов DevOps. Мониторинг производительности с точки зрения точности модели ставит новые задачи.

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

Непрерывное обучение (КТ)

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

Это известно как непрерывное обучение. Здесь MLOps стремится не только автоматизировать развертывание моделей, но и обучать модели. Определенные события положат начало переделке модели. Это может быть связано с доступностью новых данных или ухудшением производительности модели. В этом случае конвейер CI/CD может выглядеть совсем иначе. Мы больше не просто развертываем код. Мы развертываем систему (т. е. конвейер машинного обучения), которая развертывает другой сервис (т. е. модель).

Коммуникация

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

Регулирование и интерпретируемость

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

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

Типы моделей, которые вы можете использовать, также можно регулировать. Это может повлиять на вашу способность автоматизировать процесс разработки модели. Это проще сделать с такими моделями, как XGBoost и случайные леса. Здесь вы можете автоматизировать процесс выбора модели, настроив гиперпараметры. В страховании или банковском деле вам может потребоваться использовать регрессию. Чтобы построить хорошую регрессионную модель, вам нужно будет выбрать лучший набор из 8–10 некоррелированных функций. Этот процесс сложнее автоматизировать, и мы подробно обсудим его в статье ниже.

Характеристики хорошей функции
Почему прогностическая способность — это еще не все при выборе функций моделиtowardsdatascience.com

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

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

Присоединяйтесь к Medium по моей реферальной ссылке — Конор О'Салливан
Как участник Medium, часть вашего членского взноса идет на авторов, которых вы читаете, и вы получаете полный доступ ко всем история…conorosullyds.medium.com

Твиттер | Ютуб | Информационный бюллетень — подпишитесь на БЕСПЛАТНЫЙ доступ к Курсу Python SHAP

Источники изображений

Все изображения мои собственные или взяты с www.flaticon.com. В случае последнего у меня есть Полная лицензия, как определено в их Премиум-плане.

Что такое МЛОпс?

DevOps сочетается с данными и машинным обучением

DevOps

Конвейеры CI/CD

Мониторинг

Коммуникация

MLOps = DevOps + данные + модели

Разработка данных и моделей

Конвейер CI/CD

Мониторинг

Непрерывное обучение (КТ)

Коммуникация

Регулирование и интерпретируемость

Рекомендации

Вопросы по теме