В качестве моей первой статьи на Medium в качестве инженера-программиста с опытом работы в области машинного обучения (ML) и искусственного интеллекта (AI) с самого начала мне было ясно, что моя первая публикация должна быть о MLOps. Путешествуя назад во времени, нам нужно вернуться к истокам DevOps, чтобы понять, как MLOps является расширением DevOps, добавляя в смесь активы машинного обучения. На самом деле, в мире, который меняется все более быстрыми темпами, важность DevOps в командах разработчиков программного обеспечения значительно возросла. Он представляет собой организационный подход к управлению жизненным циклом приложений и упрощает процесс создания, тестирования и развертывания нового кода в производственной среде. Другими словами, DevOps представляет собой культурное движение, направленное на расширение сотрудничества, коммуникации и прозрачности между инженерными, операционными и бизнес-группами SW.

Однако как насчет компаний, создающих современные приложения с использованием машинного обучения? Применительно к компаниям, в которых машинное обучение является ядром стека продуктов, внедрение этого станет неизбежным в последующие годы. Эндрю Н.Г. сравнил традиционное программное обеспечение с командами разработчиков программного обеспечения ИИ в своем кратком чате о MLOps и своем ориентированном на данные подходе к проблеме, который заключается в сосредоточении внимания на наборах данных для повышения точности системы ИИ/МО.

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

Более глубокий взгляд на MLOps

MLOps можно рассматривать как DevOps для машинного обучения. Рассмотрим следующее замечание от SIG MLOps:

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

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

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

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

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

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

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

Сила автоматизации

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

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

  1. Сбор данных
  2. Интерпретация и подготовка данных
  3. Разработка функций
  4. Выбор функции
  5. Обучение модели
  6. Оценка модели
  7. Развертывание модели
  8. Обслуживание моделей, мониторинг и обслуживание

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

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

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

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

Почему это так важно?

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

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

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

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

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

Мы все знаем, что ИИ по-прежнему является техническим модным словечком, широко используемым сегодня более десяти лет назад. В связи с этим мы можем показать, что текущая актуальная и актуальная статистика о внедрении ИИ, учитывая влияние года пандемии COVID-19, опрос McKinsey утверждает, что использование ИИ в бизнесе повлияло на а также более продвинутые методы, обеспечивающие организационные сдвиги на всех уровнях компании. На той же странице внедрение ИИ составило 57% по сравнению с 45% в 2020 году. Что касается MLOps, рынок растет как на дрожжах, как показано в отчете Cognilytica, в котором прогнозируется экспоненциальный рост инструментов MLOps для достигнет 125 миллиардов долларов США к 2025 году.

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

Я в производстве, и что теперь?

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

Однако после того, как это произошло, какие шаги необходимо предпринять дальше? Важно понимать, что проекты машинного обучения не статичны. Классическое программное обеспечение создается для удовлетворения определенных требований. После развертывания (в производстве) программное обеспечение не развивается. С другой стороны, модели машинного обучения калибруются на основе объективной оценки данного набора данных (или нескольких наборов данных), выполняя требования или спецификации X. Таким образом, производительность меняется при изменении данных.

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

Еще один аспект, который следует учитывать, несмотря на то, что модели доступны в рабочей среде, что позволило бы нам написать полную статью, — это Управление моделями или управление процессами машинного обучения. Это представляет собой еще один строительный блок MLOps, который подразумевает итеративную проверку на всех этапах на соответствие CCPA/GDPR. Бизнес должен постоянно пытаться найти потенциальные новые проверки предвзятости, справедливости и объяснимости, прежде чем внедрять модели ML в производство. В официальном документе Европейской комиссии Об искусственном интеллекте — европейский подход к совершенству и доверию» указаны потенциальные риски и преимущества использования ИИ.

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

Текущий статус решений

В то время как 2012–2015 годы были годами взрыва образов и видений и вспышек НЛП в 2019–2020 годах, 2021–2022 годы — это годы MLOps. С точки зрения производства, с 2018 года докеризированный стек машинного обучения стал популярным. Одно из основных происходящих изменений заключается в том, что в дополнение к существующим в отрасли решениям с закрытым исходным кодом, которые предлагают привлекательные услуги для малых и средних компаний, разрабатываются и приобретают достаточную зрелость решения с открытым исходным кодом. Благодаря таким крупным компаниям, как Netflix или Airbnb, они открывают свои решения MLOps с помощью Metaflow и Apache Airflow.

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

На рисунке выше представлен интерактивный альбомный вид от Linux Foundation здесь. Альтернативный ландшафтный вид — от MLReef здесь. Также Чип Хьюен обладает возвышенной исчерпывающей проработкой ландшафта и доступными инструментами ее. Важно помнить, что большинство платформ MLOps не обеспечивают панацею для полного жизненного цикла. Поэтому выбор инструментов должен быть тщательно продуман с учетом сильных и слабых сторон инженерных групп и инфраструктуры.

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

  • Среды Data Pipeline ETL (Extract Transform Load): наиболее зрелые решения хорошо известны, например Apache Airflow и Luigi, где целью является реальная наука о данных. Две платформы охватывают все управление рабочим процессом, включая планировщик, пакетные задания и даже пользовательский интерфейс.
  • Обучение модели: здесь преобладают типичные фреймворки AI/DL. Наиболее широко используемые, хорошо зарекомендовавшие себя в отрасли, то есть Tensorflow, Pytorch и Apache MXNet. Для более сложных требований есть альтернативы, такие как Хоровод, который плавно добавляет распределенное обучение.
  • Обслуживание моделей. Отделение обслуживания моделей от клиентского приложения — стандартная процедура для работы с моделями машинного обучения в производственной среде. Tensorflow Serving является предпочтительным подходом для развертывания только Tensorflow, а BentoML представляет собой простой в использовании подход с несколькими фреймворками. Triton Inference Server, с другой стороны, представляет собой альтернативу, предназначенную для инфраструктур на основе ЦП и ГП, облака, центра обработки данных или даже периферии.
  • Совместимость моделей: ONNX и MMdnn, как межплатформенные решения, предоставляющие инструменты преобразования между разными форматами. Первый также является открытым форматом обмена нейронной сетью.
  • Версии моделей и данных. Когда дело доходит до экспериментов с машинным обучением, крайне важно иметь инструменты для версий артефактов, включая, помимо прочего, модели, наборы данных и эксперименты. Основными инструментами здесь являются DVC, MLFlow и lakeFS.
  • Отслеживание экспериментов: MLFlow, имеет необходимые компоненты для логирования, версий кода, метрик и т. д.

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

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

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

Стартапам необходимо раскрыть потенциал ИИ, чтобы создать сильную культуру вокруг этой дисциплины. Не случайно отчет Algorithmia 2021 Enterprise ML Trends показывает, что организационное согласование является наиболее существенным пробелом в достижении зрелости AI/ML. В конце концов, чтобы идти в ногу со скоростью инноваций конкурентов с этими практиками и культурой, это станет требованием для компаний, которые применяют ML в производстве. Другими словами, развитие культуры сотрудничества будет означать лучшее понимание проблем, которые необходимо решить, что приведет к лучшему выбору адекватного инструмента MLOps… до тех пор, пока это то, что вам нужно. Нет сомнений в том, что MLOps, если все сделано правильно, может значительно ускорить время выхода на рынок.

Наконец, в следующих постах, связанных с MLOps, я создам комплексное решение, используя одно из наиболее актуальных решений с открытым исходным кодом, то есть Kubeflow/MLflow.

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

Исследования

Статьи

Книги

Отличные списки