Расширенный жизненный цикл MLOps
Машинное обучение является исследовательским и основано на данных [1]. Речь идет об извлечении шаблонов из данных и повторном применении этих шаблонов к новым данным. Если все пойдет хорошо, вы получите хорошие прогнозы. Исследовательская часть заключается в поиске правильных закономерностей для данных, относительно которых вы собираетесь делать прогнозы.
Когда данные плохо структурированы или предсказуемы, жизненный цикл MLOps может сильно отличаться от обычного DevOps. Затем мы видим ряд методов, специально нацеленных на MLOps, emerge** (рис. 1**).
Рис. 1. Изображение предоставлено Seldon/CC BY-SA 4.0.
Давайте рассмотрим каждый этап по очереди. Мы рассмотрим методы, которые работают, и посмотрим, что нужно MLOps для мотивации каждого из них.
обучение
Обучение заключается в том, чтобы найти лучшие шаблоны для извлечения из обучающих данных. Мы инкапсулируем эти шаблоны в модели. Параметры тренировочного прогона можно регулировать для получения различных моделей. Инкапсуляция лучших паттернов в модели является исследовательской** (рис. 2**).
Рисунок 2: Образ через лицензию Seldon/CC BY-SA 4.0
Чтобы изучить параметры наилучшей модели, имеет смысл запустить несколько заданий параллельно. Это происходит в размещенной учебной среде, на которой работает профессиональная обучающая платформа. Затем необходимо выбрать и упаковать лучшую модель для развертывания.
Данные — важная причина, по которой эти платформы размещаются, а не работают на ноутбуке специалиста по данным. Объем данных может быть большим. Данные редко готовы для обучения модели с самого начала. Это означает, что для этого требуется большая подготовительная работа. Это может занять много времени и аппаратных ресурсов. Также может потребоваться отслеживание операций подготовки по причинам управления и повторяемости.
развертывать
После того, как мы выбрали новую модель, нам нужно выяснить, как заставить ее работать. Это означает определение того, действительно ли она лучше, чем версия, которая уже работает. Он может работать лучше на обучающих данных, но данные в реальном времени могут отличаться** (рис. 3**).
Рисунок 3: Изображение предоставлено: лицензия Seldon/CC BY-SA 4.0
Стратегия развертывания MLOps имеет тенденцию быть осторожной. Трафик может быть разделен между новыми и старыми шаблонами и отслеживаться в течение определенного периода времени (с помощью A/B-тестирования или канареечного тестирования). Или трафик можно реплицировать, чтобы новая модель могла получать запросы, но просто отслеживать свои ответы вместо использования (теневое развертывание). Затем, только когда новая модель докажет свою эффективность, она будет продвигаться.
Нам нужно знать, что модель выполняется безопасно, чтобы обобщить ее. Это означает, что развертывание требует поддержки мониторинга. Мы также можем обнаружить, что при развертывании может потребоваться поддержка механизма обратной связи для оптимального мониторинга. Иногда модель делает правильный или неправильный прогноз, например, выберет ли клиент рекомендацию. Чтобы воспользоваться этим, нам нужен механизм обратной связи.
Продвинутым случаем сегментации трафика для оптимизации является использование многоруких бандитов. В многоруких бандитах трафик сегментируется непрерывно регулируемым образом. Самая эффективная модель получает большую часть трафика, остальные модели получают небольшой процент трафика. Это обрабатывается алгоритмическим маршрутизатором в графе вывода. Если данные изменятся позже, плохо работающая модель может превратиться в доминирующую модель.
Развертывание может быть тесно связано с мониторингом. Таким образом, инструменты развертывания, такие как Seldon, не только поддерживают функции этапа развертывания, но также интегрируют требования MLOps этапа мониторинга.
монитор
Мониторинг точности модели возможен только при наличии обратной связи. Это хороший пример функции мониторинга, требующей функции фазы развертывания. В некоторых случаях ключевой метрикой может быть точность в реальном времени, в других случаях более важными могут быть пользовательские бизнес-метрики. Но это только часть мониторинга.
Рисунок 4: Изображение предоставлено: лицензия Seldon / CC BY-SA 4.0
Обратная сторона мониторинга машинного обучения заключается в том, чтобы понять, почему модель работает хорошо или плохо. Это требует понимания данных.
Одной из основных причин снижения производительности модели являются изменения данных в реальном времени. Если распределение данных отклоняется от обучающих данных, производительность будет снижаться. Это называется дрейфом данных или дрейфом концепции.
Даже если общее распределение согласуется с данными обучения, некоторые прогнозы все равно могут быть ошибочными. Это может произойти, если некоторые отдельные точки данных выходят за пределы распределения. В ситуациях, когда прогнозы должны быть всеобъемлющими и надежными, эти выбросы могут нанести ущерб.
Для полного понимания того, почему модель делает определенный прогноз, может потребоваться изучение того, как модель делает прогнозы, а не только входных данных. Методы интерпретации могут выявить ключевые закономерности, от которых зависят прогнозы модели, и сообщить нам, какие закономерности применимы к конкретному случаю. Достижение такого уровня понимания само по себе является проблемой науки о данных.
Существуют различные способы достижения расширенного мониторинга. В Seldon мы активно используем асинхронную регистрацию запросов. Зарегистрированные запросы могут быть отправлены в компонент детектора для отслеживания дрейфа или выбросов. Запросы также можно сохранять для последующего анализа, например интерпретации.
Понимание жизненного цикла MLOps
Есть много вещей, которые мы здесь не рассмотрели в процессе отработки проекта MLOps. Мы не говорили об оценках, расписании или составе команды. Мы даже не добрались до сути ящика с инструментами [2]. Надеюсь, мы достигли понимания ключевых мотивов.
Мы научились понимать жизненный цикл MLOps с точки зрения набора требований. Мы видели, что ML — это извлечение шаблонов из данных и повторное применение этих шаблонов. Данные могут быть непредсказуемыми, что может означать, что мы должны работать осторожно и отслеживать на уровне данных, а не только ошибки.
Ссылки и литература
[1] hacker noon.com/why-is-generation EVO…
The postNext Level Automationappeared first onDevOps Conference.