Всем привет! Добро пожаловать обратно в серию MLOps. Здесь я буду продолжать загружать свои заметки по специализации Machine Learning Engineering for Production, предлагаемой DeepLearning.AI на Coursera. В настоящее время мы проходим первый курс Введение в машинное обучение в производстве, который преподает легенда, сам Эндрю Нг, где мы получаем обзор каждого из шагов, связанных с производственной средой. .

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

Во-первых, давайте рассмотрим некоторые из наиболее распространенных проблем, возникающих во время развертывания.

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

Дрейф концепций/Дрейф данных: (статистическая проблема)

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

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

  • Является ли система системой прогнозирования в реальном времени или это пакетный процесс, который выполняется в одночасье?
  • Он работает в облаке или на устройстве Edge?
  • Сколько ресурсов использует полный сервис?
  • Какова задержка и пропускная способность (QPS) службы?
  • Ведение журнала для анализа и просмотра.
  • Вопросы безопасности и конфиденциальности.

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

Шаблоны развертывания

В зависимости от варианта использования у нас есть разные шаблоны для разных этапов развертывания. Некоторые из сценариев развертывания:

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

Но во всех случаях мы видим нижеследующие ключевые идеи:

  1. Постепенное увеличение трафика с мониторингом после получения доказательств того, что система работает. (Канарейка)
  2. Сделать возможным откат к предыдущим версиям.

Некоторые распространенные шаблоны развертывания:

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

  • Типичный шаблон развертывания в этом случае называется развертыванием Canary, когда мы сначала развертываем небольшую часть (5%) трафика и постепенно наращиваем трафик.
  • Другой тип шаблона развертывания называется система развертывания Blue-Green, в которой мы параллельно используем как старые версии, так и новую версию модели, а маршрутизатор переключается со старой версии на последнюю версию. Это делает откат очень простым.

Также рекомендуется рассматривать развертывание с точки зрения степеней автоматизации. Где система постепенно меняется от

Только человек → Режим тени → Помощь ИИ для людей → Частичная автоматизация (на основе достоверности модели) → Полная автоматизация

Многие приложения проходят эти уровни, а некоторые останавливаются на таких этапах, как помощь ИИ или частичная автоматизация, которые в совокупности называются системами Human-in-the-loop.

Мониторинг системы машинного обучения

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

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

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

Есть 3 основные категории, на которые обычно классифицируются метрики.

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

  • Используемая память
  • Задержка
  • пропускная способность
  • Загрузка сервера и т. д.,

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

  • Сред. входной объем
  • Сред. длина ввода
  • Доля входных пропущенных значений и т. д.,

Выходные метрики: метрики, которые отслеживают выходные данные, предоставляемые системами, например,

  • Количество возвратов null
  • Количество раз, когда пользователь повторяет поиск
  • Количество раз, когда пользователь переключается на другой режим ввода данных в систему для получения лучших результатов.
  • Рейтинг кликов (CTR)

⚠️ Примечание.
 –
Входные и выходные показатели в основном зависят от приложения.
 – Подобно обучению модели, процесс развертывания и мониторинга также является итеративным. Сначала мы развертываем и настраиваем панели мониторинга. Затем мы отслеживаем производительность w.r.t. пользователей с последующим анализом производительности системы и внесением соответствующих изменений по результатам.

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

Мониторинг производственного конвейера

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

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

Таким образом, вход в систему распознавания речи зависит от производительности модуля VAD.

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

Показатели для мониторинга:

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

Как быстро меняются эти показатели?

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

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

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



Примечания по MLOps – 1: Жизненный цикл машинного обучения
Мое путешествие по «специализации MLOps
от DeepLearning.AI. В этой статье описывается жизненный цикл машинного обучения вместе с…akhiltvsn.medium.com»