Осмысление больших данных

Безопасное развертывание моделей машинного обучения в производство

Лучшие практики CI / CD для безболезненного развертывания моделей и версий машинного обучения

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

ML так же сложен, как и оркестровка различных инструментов

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

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

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

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

  • Реестр моделей. Развернутая модель может принимать различные формы: сериализацию конкретных объектов, например, pickle, или форматы сериализации между технологиями, такие как PMML. Обычно эти файлы хранятся в реестре на основе общего файлового хранилища (S3, GCS,…), в репозитории стандартной версии (git) или в специальной службе, такой как реестр моделей MLFlow.
  • Уровень обслуживания: это фактическая служба прогнозирования. Такие уровни могут быть встроены вместе с бизнес-логикой приложения, основанного на прогнозах модели, или могут быть отделены, чтобы действовать как служба прогнозирования, не связанная с поддерживаемыми ею бизнес-процессами. В обоих случаях основная функция заключается в извлечении соответствующих прогнозов в соответствии с новыми входящими запросами с использованием моделей из реестра моделей. Такой сервис может работать как в пакетном, так и в потоковом режиме.
  • Сбор меток: процесс сбора достоверной информации о случаях контролируемого обучения. Это можно сделать вручную, автоматически или с использованием смешанного подхода, например активного обучения.
  • Мониторинг: централизованная служба, которая отслеживает весь процесс и состояние ваших живых моделей, от качества входных данных, которые поступают на обслуживание, до собранных меток для обнаружения отклонений, смещений или проблем с целостностью.

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

1. Отсутствие автоматизации

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

2. Множество заинтересованных сторон

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

3. Гипердинамизм реальных данных.

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

4. Тихие отказы моделей машинного обучения по сравнению с традиционным ИТ-мониторингом.

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

CI ֿֿֿ / CD для ML в производстве

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

Новую версию модели следует рассматривать и рассматривать как программный артефакт

Для создания новой модели требуется набор модульных и интеграционных тестов, чтобы убедиться, что новая «кандидатная» модель действительна до того, как она будет зафиксирована в реестре моделей. Но в сфере машинного обучения CI - это не только тестирование и проверка кода и компонентов, но также тестирование и проверка данных, схем данных и качества моделей. Хотя в центре внимания CI является поддержка действительных баз кода и артефактов модулей, перед созданием новых артефактов для каждого модуля процесс CD обрабатывает этап фактического развертывания артефактов (в нашем случае новой версии модели) в производстве.

Лучшие практики для фазы CI

Вот некоторые из основных передовых практик для фазы CI, которые влияют на безопасное развертывание реализаций модели / новой версии:

Проверка данных

Модели переобучаются / производятся с использованием исторических данных. Чтобы модель была актуальной в производственной среде, набор обучающих данных должен адекватно отражать распределение данных, которое в настоящее время появляется в производственной среде. Это позволит избежать систематической ошибки выбора или просто несоответствия. Для этого еще до запуска конвейера обучения следует протестировать распределение обучающего набора, чтобы убедиться, что оно подходит для задачи. На этом этапе решение для мониторинга можно использовать для предоставления подробных отчетов о распределении последних производственных кейсов, а с помощью инструментов тестирования данных, таких как deequ или TDDA, этот тип ограничений проверки данных может быть автоматически добавлен к процесс CI.

Проверка качества модели

При выполнении конвейера обучения и перед отправкой новой модели в качестве модели «кандидата» в реестр убедитесь, что новый процесс обучения проходит проверку на соответствие требованиям.

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

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

Тестовые примеры - устойчивость к предположениям о производственных данных

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

Модель стресс-теста

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

Лучшие практики для фазы компакт-диска

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

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

Такая модель онлайн-оценки может включать несколько основных стратегий:

Оценка тени

Оценка теней (или часто называемая «темным запуском») - очень интуитивно понятная и безопасная стратегия. В теневом режиме новая модель добавляется в реестр как «модель-кандидат». Любой новый запрос прогнозирования определяется как версиями модели, той, которая в настоящее время используется в производстве, так и новой версией кандидата в теневом режиме.

В теневом режиме новая версия тестируется с использованием нового потока производственных данных, но используются и возвращаются пользователю / компании только прогнозы последней версии «производственной модели».

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

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

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

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

Такой тест должен подтвердить, что производительность новой версии имеет требуемый размер эффекта, также известный как разница между двумя метриками производительности версии при определенной статистической мощности, также известный как вероятность правильного определения эффекта при его наличии. Например: если последняя версия имела уровень точности 91% на прошлой неделе, новая версия-кандидат должна иметь размер эффекта 0 или более, поэтому новый уровень точности будет не менее 91%.

Общий уровень эффективности - не единственный показатель, на который следует обращать внимание

Однако перед продвижением модели могут быть важны дополнительные факторы, которые необходимо отслеживать: стабильность производительности, то есть определение отклонения в ежедневной производительности в нашем последнем примере или проверка ограничений производительности для конкретной подгруппы. Например. модель должна иметь уровень точности 95%, по крайней мере, для наших «VIP-клиентов. Когда сбор этикеток требует времени или может отсутствовать полностью, можно использовать другие ключевые показатели эффективности для тестирования новой модели в качестве показателя ее качества, например: в сценариях использования утверждения ссуды, где такие циклы обратной связи могут длиться более 3–6 месяцев. В этих случаях может использоваться уровень корреляции между предсказаниями двух версий, поскольку новая версия должна иметь относительно высокий уровень корреляции по сравнению со своей предшественницей. Другой вариант - протестировать уровень сдвига распределения в производственных данных относительно их обучающего набора данных, чтобы убедиться, что новая версия была обучена на соответствующем наборе данных относительно текущего производственного распределения.

Помимо всех преимуществ, теневое оценивание имеет ограничения и лишь частично практично. Это то, что мы проанализируем ниже, а также рассмотрим альтернативные решения.

Оценка A / B

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

В настройке A / B как текущая последняя версия, так и новая версия-кандидат, которые могут упоминаться как модель A / «контрольная» группа и модель B / «группа лечения», фактически активны в производстве. Каждый новый запрос направляется одной из моделей в соответствии с определенной логикой, и только выбранная модель используется для прогнозирования.

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

Успех этого метода во многом зависит от способности правильно и тщательно разбивать группы A / B-тестирования.

Хорошая практика заключается в том, чтобы сделать случайную выборку для определенной части, чтобы получить «лечение», то есть прогноз на основе новой версии. Например, в случае использования рекомендации фильма любой новый запрос должен иметь X (например, 10%) шанс быть обслуженным новой версией модели, пока тест не будет завершен. Обычно фактор воздействия относительно низок, поскольку эта стратегия фактически «раскрывает» новую модель еще до того, как будут завершены качественные тесты.

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

Многорукий бандит

Многорукий бандит (MAB) на самом деле является более «динамичным» видом экспериментов с A / B-тестами, но также более сложным для измерения и работы. Это классическое обучение с подкреплением, при котором человек пытается «исследовать» (пробовать новую версию модели), одновременно «эксплуатируя» и оптимизируя определенные ключевые показатели эффективности. Такая конфигурация основана на реализации компромисса исследования / эксплуатации внутри службы мониторинга. Трафик динамически распределяется между двумя (или более) версиями в соответствии с собранным KPI производительности или другими прокси, как описано ранее.

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

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

Преимущества мониторинга для безопасного развертывания

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

Безопасное развертывание моделей - это мониторинг согласованности всех частей инфраструктуры машинного обучения вместе

Ниже мы можем увидеть безопасную поставку новой версии (V2, отмеченную синей точкой), обеспечивающую улучшенную производительность ROC AUC в производстве.

Если заглянуть дальше, работоспособность ваших моделей в производстве также требует тщательной стратегии переподготовки на основе данных. В то время как парадигмы CI / CD рассматривают что и как при развертывании новых моделей, когда охватывается парадигмой CT (непрерывного обучения). Об этом и пойдет речь в следующем посте моего коллеги Or Itzahary, так что следите за обновлениями!

От CI / CD до CT (непрерывное обучение). CT - это новое свойство, уникальное для систем машинного обучения, которое связано с автоматическим переобучением и обслуживанием моделей

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

Хочу поблагодарить своих коллег Перл Либерман, Ор Ицахари и Ори Коэн за их проницательные комментарии и идеи.

Орен Разон является соучредителем и техническим директором superwise.ai, компании, которая наделяет группы специалистов по обработке и анализу данных и операционным группам видимостью и контролем для масштабирования своей деятельности в области ИИ с помощью передовой платформы мониторинга машинного обучения. Орен - опытный специалист по машинному обучению, который руководит крупномасштабными операциями по машинному обучению в стартапах и на предприятиях за последние 15 лет и консультирует его.

Я всегда ищу повод, чтобы прочитать, написать, поговорить и поделиться идеями по темам MLOps.