Модели ML для тестирования AB — Шаблоны развертывания расширенных моделей

Этот контент изначально был размещен на https://www.qwak.com

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

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

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

Понимание последовательности реализации модели

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

• Сбор и подготовка данных
• Составление списка моделей архитектуры и обучение
• Тестирование и оценка
• Развертывание и мониторинг‍

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

Сбор и подготовка данных

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

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

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

Отбор моделей архитектуры и обучение

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

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

Тестирование, оценка и мониторинг.

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

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

Развертывание и мониторинг

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

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

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

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

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

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

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

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

Развертывание теневой модели

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

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

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

‍

Тестирование теневой модели используется, когда нет необходимости в A/B-тестировании. Архитекторы используют этот шаблон, когда им требуется проверка модели на полных пользовательских данных перед переключением. Недостатком этого шаблона является использование ресурсов. Поскольку все данные проходят через обе модели, этот шаблон обычно требует почти вдвое больше ресурсов, используемых стратегией одной модели. Можно попытаться оптимизировать использование ресурсов, найдя этапы, которые можно запускать часто. Например, некоторые части предварительной обработки обычно можно выполнить один раз.

Тестирование взвешенной модели разделения трафика

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

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

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

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

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

Тестирование модели разделения трафика на основе правил

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

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

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

Заключение

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

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

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

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

Посмотреть Qwak можно здесь.