Подходы к тестированию моделей машинного обучения Amazon SageMaker

Переиздано Платоном

Читают: 0

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

Мы все ценим важность высококачественной и надежной модели машинного обучения (ML), например, при использовании автономного вождения или взаимодействии с Alexa. Модели машинного обучения также играют важную роль в менее очевидных случаях — они используются бизнес-приложениями, здравоохранением, финансовыми учреждениями, amazon.com, TurboTax и другими.

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

Есть несколько предписывающий руководства по MLOps, и в этом посте дается обзор процесса, которому вы можете следовать, и какие инструменты использовать для тестирования. Это основано на сотрудничестве между Постигать интуитивно и АВС. Мы работали вместе, чтобы реализовать рекомендации, изложенные в этом посте, на практике и в масштабе. Цель Intuit стать Экспертная платформа на основе ИИ сильно зависит от стратегии увеличения скорости разработки начальной модели, а также от тестирования новых версий.

Требования

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

Точность модели – Важно следить за метрик оценки модели, таких как точность, воспроизводимость и полнота, и убедитесь, что объективные метрики остаются относительно такими же или улучшаются с новой версией модели. В большинстве случаев развертывание новой версии модели не имеет смысла, если не улучшится опыт конечных пользователей.
Качество тестовых данных – Данные в непроизводственных средах, будь то смоделированные или копии на определенный момент времени, должны быть репрезентативными для данных, которые модель получит при полном развертывании, с точки зрения объема или распространения. В противном случае ваши процессы тестирования не будут репрезентативными, и ваша модель может вести себя иначе в производственной среде.
Важность функции и паритет – Важность функций в более новой версии модели должна быть сопоставима с более старой моделью, хотя могут быть введены новые функции. Это делается для того, чтобы модель не становилась предвзятой.
Тестирование бизнес-процессов – Важно, чтобы новая версия модели соответствовала вашим бизнес-целям в рамках приемлемых параметров. Например, одной из бизнес-метрик может быть то, что сквозная задержка для любой службы не должна превышать 100 миллисекунд, или стоимость размещения и переобучения конкретной модели не может превышать 10,000 XNUMX долларов США в год.
Цена – Простой подход к тестированию состоит в том, чтобы воспроизвести всю производственную среду в качестве тестовой среды. Это обычная практика в разработке программного обеспечения. Однако такой подход в случае моделей машинного обучения может не дать нужного ROI в зависимости от размера данных и может повлиять на модель с точки зрения бизнес-задачи, которую она решает.
Безопасность – Часто ожидается, что в тестовых средах будут образцы данных вместо реальных данных клиентов, и в результате правила обработки данных и соответствия могут быть менее строгими. Однако, как и в случае со стоимостью, если вы просто дублируете производственную среду в тестовую среду, вы можете создать риски безопасности и соответствия требованиям.
Масштабируемость магазина функций – Если организация решит не создавать отдельное тестовое хранилище функций из соображений стоимости или безопасности, то тестирование модели необходимо провести в производственном хранилище функций, что может вызвать проблемы с масштабируемостью, поскольку трафик удваивается в течение периода тестирования.
Производительность онлайн-модели – Онлайн-оценки отличаются от офлайн-оценок и могут быть важны в некоторых случаях, например в моделях рекомендаций, поскольку они измеряют удовлетворенность пользователей в реальном времени, а не воспринимаемую удовлетворенность. Трудно смоделировать реальные модели трафика в непроизводственной среде из-за сезонности или другого поведения пользователей, поэтому производительность онлайн-модели можно оценить только в рабочей среде.
Операционная производительность – По мере того, как модели становятся больше и все чаще развертываются децентрализованным образом на различном оборудовании, важно протестировать модель на желаемую операционную производительность, такую как задержка, частота ошибок и т. д.

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

Автономное тестирование модели

Целью этого этапа тестирования является проверка новых версий существующей модели с точки зрения точности. Это должно быть сделано в автономном режиме, чтобы не повлиять на какие-либо прогнозы в производственной системе, которые обслуживают прогнозы в реальном времени. Убедившись, что новая модель работает лучше для применимых показателей оценки, это тестирование решает проблему 1 (показатели точности модели). Кроме того, используя правильный набор данных, это тестирование может решить проблемы 2 и 3 (качество тестовых данных, важность функций и четность) с дополнительным преимуществом решения проблемы 5 (стоимость).

Этот этап выполняется в промежуточной среде.

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

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

В качестве дополнительного бонуса за счет интеграции Amazon SageMaker Уточнить при автономном тестировании модели вы можете проверить новую версию модели на предвзятость, а также сравнить атрибуцию функций с предыдущей версией модели. С помощью конвейеров вы можете организовать весь рабочий процесс таким образом, чтобы после обучения можно было выполнить шаг проверки качества для выполнения анализа метрик модели и важности функций. Эти показатели хранятся в Реестр моделей SageMaker для сравнения в следующем цикле обучения.

Интеграция и тестирование производительности

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

Это тестирование следует проводить в тестовой среде.

И интеграционное тестирование, и тестирование производительности должны выполняться отдельными командами с использованием конвейера MLOps. Для интеграционного тестирования мы рекомендуем проверенный метод поддержки функционально эквивалентной предпроизводственной среды и тестирования с несколькими различными полезными нагрузками. Рабочий процесс тестирования можно автоматизировать, как показано на этот семинар. Для тестирования производительности вы можете использовать Рекомендатор выводов Amazon SageMaker, который предлагает отличную отправную точку для определения того, какой тип экземпляра и сколько из этих экземпляров использовать. Для этого вам нужно будет использовать инструмент генератора нагрузки, такой как проекты с открытым исходным кодом. перфсайзмейкер и размер который разработала компания Intuit. Perfsizesagemaker позволяет автоматически тестировать конфигурации конечных точек модели с различными требованиями к полезной нагрузке, времени отклика и пиковым транзакциям в секунду. Он генерирует подробные результаты испытаний, в которых сравниваются различные версии моделей. Perfsize — это вспомогательный инструмент, который пробует различные конфигурации, учитывая только пиковое количество транзакций в секунду и ожидаемое время отклика.

A / B тестирования

Во многих случаях, когда требуется реакция пользователя на немедленный вывод модели, например, в приложениях электронной коммерции, функциональной оценки автономной модели недостаточно. В этих сценариях вам необходимо провести A/B-тестирование моделей в производственной среде, прежде чем принимать решение об обновлении моделей. A/B-тестирование также имеет свои риски, потому что может оказать реальное влияние на клиента. Этот метод тестирования служит окончательной проверкой производительности машинного обучения, облегченной проверкой инженерной работоспособности. Этот метод также решает проблемы 8 и 9 (производительность онлайн-модели и операционная эффективность).

A/B-тестирование должно выполняться в производственной среде.

С помощью SageMaker вы можете легко выполнять A/B-тестирование моделей машинного обучения, запустив несколько вариантов производства на конечной точке. Трафик можно перенаправлять на новую версию поэтапно, чтобы снизить риск того, что плохо работающая модель может иметь место в рабочей среде. Если результаты A/B-теста выглядят хорошо, трафик направляется на новую версию, в конечном итоге занимая более 100% трафика. Мы рекомендуем использовать ограничения развертывания для перехода от модели A к модели B. Для более подробного обсуждения A/B-тестирования с использованием Amazon персонализировать модели в качестве примера см. Использование A / B-тестирования для измерения эффективности рекомендаций, созданных Amazon Personalize.

Онлайн-тестирование модели

В этом сценарии новая версия модели значительно отличается от той, которая уже обслуживает живой трафик в рабочей среде, поэтому подход к автономному тестированию больше не подходит для определения эффективности новой версии модели. Наиболее заметной причиной этого является изменение функций, необходимых для создания прогноза, поэтому ранее записанные транзакции нельзя использовать для проверки модели. В этом сценарии мы рекомендуем использовать теневые развертывания. Теневые развертывания предлагают возможность развертывания теневого (или претендент) модели вместе с производством (или чемпион), которая в настоящее время выдает прогнозы. Это позволяет оценить, как теневая модель работает в рабочем трафике. Прогнозы теневой модели не передаются запрашивающему приложению; они регистрируются для автономной оценки. Используя теневой подход к тестированию, мы решаем проблемы 4, 5, 6 и 7 (тестирование бизнес-процессов, стоимость, безопасность и масштабируемость набора функций).

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

Этот метод тестирования новых версий модели следует использовать в крайнем случае, если все остальные методы не могут быть использованы. Мы рекомендуем его в крайнем случае, так как дуплексные вызовы к нескольким моделям создают дополнительную нагрузку на все нижестоящие службы в рабочей среде, что может привести к снижению производительности, а также к увеличению затрат в рабочей среде. Наиболее очевидное влияние это оказывает на уровень обслуживания функций. Для вариантов использования, которые совместно используют функции из общего пула физических данных, нам необходимо иметь возможность моделировать несколько вариантов использования, одновременно обращающихся к одной и той же таблице данных, чтобы убедиться, что перед переходом к рабочей среде не существует конкуренции за ресурсы. По возможности следует избегать дублирования запросов к хранилищу функций, а функции, необходимые для обеих версий модели, следует повторно использовать для второго вывода. Магазины функций на основе Amazon DynamoDB, созданный Intuit, может реализовать Ускоритель Amazon DynamoDB(DAX) для кэширования и предотвращения дублирования операций ввода-вывода в базе данных. Эти и другие варианты кэширования могут смягчить проблему 7 (масштабируемость хранилища функций).

Чтобы решить проблему 5 (стоимость), а также проблему 7, мы предлагаем использовать теневые развертывания для выборки входящего трафика. Это дает владельцам моделей еще один уровень контроля, чтобы свести к минимуму влияние на производственные системы.

Теневое развертывание должно быть встроено в Модель Монитор предложения так же, как обычные производственные развертывания, чтобы наблюдать за улучшениями версии-претендента.

Заключение

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

Об авторах

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

Шиваншу Упадхьяй является главным архитектором решений в группе AWS Business Development and Strategic Industries. В этой роли он помогает наиболее продвинутым пользователям AWS трансформировать свою отрасль, эффективно используя данные и искусственный интеллект.

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