Введение

В этой статье описывается мой завершающий проект, разработанный для программы наностепени инженера по машинному обучению от Udacity. Я разработал эту модель прогноза принятия предложения Starbucks, используя набор данных, который также используется в программе наностепени Data Scientist, но с другим подходом. Моя главная цель состояла в том, чтобы применить и продемонстрировать свое понимание инженерных концепций машинного обучения, используя несколько сервисов AWS, таких как S3, Lambda, IAM и, черт возьми, Sagemaker.

Обзор проекта

В качестве маркетинговой стратегии Starbucks постоянно рассылает предложения пользователям мобильного приложения. Тип предложения может значительно варьироваться от простой информационной рекламы до предложения «купи, получи» (BOGO). Поскольку не все клиенты получают разные предложения, в разном количестве и в разное время, не элементарно указать его эффективность или указать для каждого клиента, склонного принять предложение. Наша задача сосредоточена на развертывании модели машинного обучения в aws, которая указывает, склонен ли клиент принять предложение с учетом некоторых доступных данных.

Данные, предоставленные для этого проекта, состоят из 3 файлов json. Общий смысл и поля указаны выше:

портфолио.json: информация о 10 различных стратегиях предложения.

  • id (string) — id оффера
  • offer_type (string) — тип предложения т.е. BOGO, дисконтное, информационное
  • сложность (int) — минимальная сумма, необходимая для завершения предложения
  • вознаграждение (инт) — вознаграждение дается за выполнение предложения
  • duration (int) — время открытия оффера, в днях
  • каналы (список строк)

profile.json: демографические данные для каждого клиента.

  • age (int) — возраст клиента
  • стал_member_on (целое число) — дата, когда клиент создал учетную запись приложения.
  • гендер (str) — пол клиента («М», «Ж» и «О» для любого другого)
  • id (str) — идентификатор клиента
  • доход (float) — доход клиента

расшифровка.json: реестры событий для взаимодействия предложения или транзакции.

  • event (str) — описание записи (т. е. транзакция, полученное предложение, просмотренное предложение и т. д.)
  • person (str) — идентификатор клиента
  • time (int) — время в часах с начала теста. Данные начинаются в момент времени t=0
  • value — (словарь строк) — либо идентификатор предложения, либо сумма транзакции в зависимости от записи

Подготовка данных

портфолио

  • Проблем с целостностью не обнаружено;
  • «каналы» и «offer_type» были закодированы для лучшей совместимости с алгоритмами ML;
  • Информация об электронной почте удалена, поскольку присутствует во всех предложениях;
  • Некоторые столбцы были переименованы для ясности.

Профиль

  • Записи с выявленными отсутствующими данными/выбросами;
  • Некоторые столбцы были переименованы для ясности;
  • рассчитывается столбец «дни участников».
  • Пол закодирован.

Отсутствуют некоторые профильные данные как по доходу, так и по полу. Для проверки наличия выбросов использовались гистограммы. Поскольку количество выбросов в поле «Возраст» и регистров с отсутствующими данными было примерно 2 тысячи, я подозревал, что они одинаковые, что и оказалось.

Стенограмма

  • Набор данных расшифровки был изменен путем переименования столбца «человек» в «customer_id» для ясности.
  • Столбец «значение» был разделен на столбцы «offer_id» и «количество» для лучшей совместимости с алгоритмами машинного обучения.
  • Столбец «событие» был предварительно закодирован с использованием цикла for для создания новых столбцов для каждого уникального события.

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

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

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

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

Разработка модели

Метрики и базовая модель

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

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

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

Превзойти эталон

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

При точности и ROC AUC 78% XGBoost со всеми функциями моделирования считается удовлетворительным. Следующим шагом является подготовка среды для развертывания решения с помощью AWS.

Обучение и развертывание модели AWS Model.

Настройка данных в S3

Первым шагом в AWS было выполнение кода, который сначала запускался локально в созданном экземпляре ноутбука. Был выбран тип экземпляра ml.t3.medium. После этого данные обучения и тестирования были сохранены в экземпляре для отправки в корзину S3, созданную для этого проекта.

Улучшение модели с настройкой гиперпараметров.

Чтобы получить окончательную модель, которая работает лучше, чем модель с 0,78 ROC AUC, была выполнена настройка гиперпараметров с широким диапазоном параметров.

Настройка гиперпараметра может достичь значения почти 0,87 для нашей контрольной метрики, что подтверждает важность процесса.

Развертывание и тестирование

Последние шаги в Sagemaker заключались в обучении модели с лучшими гиперпараметрами, ее развертывании и последующем выводе для проверки конечной точки. Так как модель небольшая, для endpiont использовался экземпляр ml.t2.medium.

Для тестирования я жестко запрограммировал некоторые параметры и внес коррективы в формат csv для ввода в модель. Все попытки прогнозирования были успешными, и все результаты согласовывались с пониманием данных, полученным при первоначальном исследовании. (прогноз * 100))

Вывод с помощью лямбда

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

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

Наконец, реализация функции была выполнена с использованием двух файлов «lambda_function.py» и «inference.py», и тест прошел успешно, как показано выше.

Заключение

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

Начав с базовой модели с использованием дерева решений, я достиг контрольного показателя ROC AUC, равного 0,73. Окончательная модель превзошла эталонный показатель, достигнув значения 0,87, продемонстрировав улучшенную точность и показатель ROC AUC. Кроме того, модель была развернута в конечной точке, и к ней можно было получить доступ за пределами sagemeker с помощью лямбда-функции.

В целом, этот проект продемонстрировал мастерство инженера по машинному обучению AWS в использовании различных сервисов AWS, таких как Amazon SageMaker, S3, IAM и AWS Lambda, для создания комплексного решения. Использование методов машинного обучения в сочетании с эффективной предварительной обработкой данных и разработкой функций привело к созданию модели, которая обеспечивала точные прогнозы принятия предложений Starbucks.

Файлы и код из этих проектов доступны в этом репозитории GitHub.