Анализ корзины рынка Instacart: часть 2 (FE и моделирование)

Это серия из 3 частей, посвященная тематическому исследованию, основанному на проблеме Kaggle.

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

Оглавление

  1. Стратегия моделирования
  2. Разработка функций
  3. Сгенерируйте обучающие и тестовые данные
  4. Тренировочные модели
  5. Создание файлов отправки
  6. Улучшить модель
  7. использованная литература

Стратегия моделирования

Стратегия: 1

Создать обучающие данные (используя Prior_orders_data )

  • Для каждого заказа в Prior_orders_data возьмите n-1 заказов каждого пользователя для разработки функций.
  • n-й порядок каждого пользователя будет использоваться для маркировки зависимой переменной, т.е. переупорядоченной.

пример : -

пусть у пользователя А есть 90 заказов в prior_orders_data.

  • построить функции, используя 89 заказов.
  • основываясь на этих функциях, мы пометим данные как reordered(0/1), если какой-либо из продуктов, которые он принес в 89 заказах, появился в его 90-м заказе.

Создать данные проверки (используя train_orders_data)

  • Теперь, когда наши обучающие данные сгенерированы с использованием prior_orders_data, мы можем использовать train_orders_data (который содержит 1 заказ на пользователя) для тестирования нашей обученной модели.
  • мы будем прогнозировать вероятность повторного заказа продукта, используя обученную модель, чтобы обеспечить точность.
  • Затем мы выберем наиболее вероятные продукты, вероятность повторного заказа которых была высокой и которые могут максимизировать F1-Score.
  • Для этого воспользуемся кодом оптимизации f1 от Faron.
  • проверьте фактическую оценку F1 и расчетную оценку F1. Это даст нам представление о том, насколько эффективна модель.

Создать тестовые данные (из orders.csv с eval ==’test’)

  • Добавляйте функции, основанные на обучающих данных, на основе заказов и пользователей.
  • Для каждого заказа и продукта предсказать, будет ли он переупорядочен (0/1)
  • Затем мы выберем наиболее вероятные продукты, вероятность повторного заказа которых была высокой и которые могут максимизировать F1-Score.
  • Мы будем использовать код оптимизации f1 от Faron, чтобы выбрать продукты, максимизирующие показатель f1.

Стратегия: 2

Создать обучающие данные (используя Prior_orders_data и train_orders_data)

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

Создать тестовые данные (из orders.csv с eval ==’test’)

  • Добавляйте функции, основанные на обучающих данных, на основе заказов и пользователей.
  • Для каждого заказа и продукта предсказать, будет ли он переупорядочен (0/1)
  • Затем мы выберем наиболее вероятные продукты, вероятность повторного заказа которых была высокой.

После обучения моделей с использованием обоих подходов стратегия 2 дала несколько лучшие результаты. Теперь мы приступим к стратегии 2.

Разработка функций

мы хотим предсказать, если ,

Пользователь A → купит продукт B → в своем следующем заказе C → повторный заказ (1/0) ?

Этот идентификатор будущего заказа получается из заказов на поезд и тестовых заказов в orders.csv.

Эта структура основана на ядре Симеона Коковидиса.

Создать только функции продукта

  • feat_1 : product_reorder_rate : Как часто продукт перезаказывался независимо от предпочтений пользователя?
  • feat_2 : medium_pos_incart : Средняя позиция товара в корзине?

следующие 3 значения рассчитываются на основе продукта

  • неорганический
  • isYogurt — проход
  • производство — отдел
  • isFrozen — отдел
  • isdairy — отдел
  • завтрак — отдел
  • issnack — отдел
  • isbeverage — отдел

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

feat_3 : p_reduced_feat_1 : столбец 1 из вывода NMF

feat_4 : p_reduced_feat_2 : столбец 2 из вывода NMF

feat_5 : p_reduced_feat_3 : столбец 3 из вывода NMF

feat_6 : aisle_reorder_rate : как часто продукт повторно заказывается из прохода, к которому этот продукт принадлежит

feat_7 :department_reorder_rate : как часто продукт повторно заказывается из отдела, к которому этот продукт принадлежит

Создать функции только для пользователей

  • feat_1 : user_reorder_rate : Какова средняя частота повторных заказов для заказов, размещенных пользователем?
  • feat_2 : user_unique_products : Каково количество различных продуктов, заказанных пользователем?
  • feat_3 : user_total_products : Количество всех товаров, заказанных пользователем?
  • feat_4 : user_avg_cart_size : Среднее количество товаров на заказ пользователя? = средний размер корзины ?
  • feat_5 : user_avg_days_between_orders : Среднее количество дней между двумя заказами пользователя?
  • feat_6 : user_reordered_products_ratio : количество повторно заказанных уникальных продуктов / количество заказанных уникальных продуктов

Создание пользовательских функций продукта

Теперь, когда мы создали функции только для продукта и только для пользователя, теперь мы будем создавать функции на основе того, как пользователь взаимодействует с продуктом.

  • feat_1: u_p_order_rate: Как часто пользователь заказывал продукт?
  • feat_2 : u_p_reorder_rate : Как часто пользователь повторно заказывал продукт?-
  • feat_3 : u_p_avg_position : Какова средняя позиция товара в корзине по заказам, размещенным пользователем?
  • feat_4 : u_p_orders_since_last : Сколько заказов было размещено с момента последнего заказа товара?
  • feat_5 : max_streak : количество заказов, в которых пользователь непрерывно приносил товар без промаха

Объединить вышеуказанные функции:

Теперь объедините эти независимые функции (только функции пользователя, функции только продукта и функции пользователя — продукта) → назовите это как merged_df.

Теперь этот кадр данных будет содержать функцию для всех возможных пар «пользователь — продукт», некоторые из которых будут использоваться в моделях обучения (с использованием заказов на поезд) и тестировании (с использованием тестовых заказов).

Разные функции

а. Особенности продукта в зависимости от времени

особенность : частота повторного заказа продукта в любое время дня

б. Характеристики продукта в зависимости от дня недели

особенность: Какова частота повторного заказа любого продукта в любой день недели?

в. Характеристики продукта на основе разницы между двумя заказами

характеристика: как часто товар перезаказывался с учетом разницы между 2 заказами (днями) и содержит товар.

д. Функция пользователя на основе разницы между двумя заказами

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

e. Пользователь — количество повторных заказов товара на основе разницы между двумя заказами

функция: как часто пользователь повторно заказывал товар с учетом разницы между двумя заказами (в днях).

Объединить все данные (лучшее в пандах)

Создание обучающих и тестовых данных

Этот код объединит merged_df (сверху) с данными заказов поездов,

аналогичным образом мы объединим тестовые данные с merged_df (см. выше), чтобы сгенерировать тестовые данные.

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

Как мы видим, у нас нет переупорядоченного столбца для тестовых данных (мы это предскажем).

Дополнительный шаг

прежде чем мы начнем обучать модели, мы уменьшим размер нашего фрейма данных (в настоящее время 3 ГБ) до 0,6 ГБ, изменив dtypes столбцов по умолчанию. Изменение dtype столбцов по сравнению со значением по умолчанию, т.е. int64/float64/object в их меньший диапазон уменьшил размер почти в 3 раза.

Пример — int64 → uint8 (для идентификатора отдела, идентификатора прохода)

Мы сохраняем этот файл в формате HDF5, так как сохранение в CSV после изменения dtypes возвращает dtypes к значениям по умолчанию.

Тренировочные модели

Это будет сравнительное исследование, основанное на различных подходах, и выбор наиболее эффективного из них. Для каждой модели мы определяем производительность на основе оценки kaggle и logloss.

Мы будем использовать 2 подхода для получения результатов,

а. Глобальный порог (0,18, 0,19, 0,2):

Эти глобальные пороговые значения выбираются на основе:

  • Специальный подход: загрузили много файлов отправки с разными пороговыми значениями и увидели, что после 0,2 балл F1- начал снижаться.
  • Использование стратегии 1, описанной выше: мы тестировали train_orders, чтобы получить глобальные пороговые значения

Как видно выше, среднее F1 — падает после порога вероятности 0,2. и самые высокие были 0,18, 0,19, 0,2

Для каждой модели мы создадим 3 результата (файлы отправки) для вышеуказанных пороговых значений.

Мы выберем только те продукты, чья прогнозируемая вероятность повторного заказа ≥ заданного порога, иначе нет.

б. Локальный порог ( F1 — максимизация)

Как описано в предыдущем посте, мы будем использовать реализацию F1-Maximization от Faron, так что каждый заказ будет иметь свой собственный локальный порог и выбирать те продукты, которые максимизируют F1-оценку.

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

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

Давайте обучим несколько моделей

Модель 1: логистическая регрессия

Потери журнала при проверке данных: 0,2550918280106341

Модель 2: дерево решений

Потери журнала при проверке данных: 0,2509911734828939

Модель 3: классификатор случайного леса

Проверочные данные:0,25187675305313206

Модель 4: многослойная модель персептрона

Точность обучения: 90,75 %
Точность проверки : 90,74 %
Логлосс данных проверки: 0,2513314122715033

Модель 5: классификатор XGBoost

Потери журнала при проверке данных: 0,24345293402046597

Мы видим, что hour_reorder_rate (одна из прочих функций) имеет наибольшее значение.

Модель 6: классификатор CatBoost

Потери журнала при проверке данных: 0,24300858358388394

Мы видим, что u_p_orders_since_last имеет наивысшее значение, которое, в отличие от xgb, было вторым последним.

Примечание.

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

Создать файлы отправки

позволяет генерировать файлы отправки (как для глобальных, так и для локальных порогов)

  • Функция globl_threshold_products → создает файлы отправки на основе глобальных порогов (0,18, 0,19, 0,20).
  • Функция getscores_on_testdata → создает файл отправки на основе локального порога, чтобы максимизировать F1-Score.

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

Сравнение моделей

Мы видим, что классификатор catboost на локальном пороге получил наивысший балл.

Улучшить модель

Мы можем немного улучшить модель Catboost.

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

Хотя этот шаг немного улучшает модель, он был достаточно значительным, чтобы упомянуть его здесь.

Давайте посмотрим, насколько улучшилась модель после того, как мы разделили наши обучающие данные на основе пользователей.

Это отмечает конец нашего этапа моделирования.

Следующий

использованная литература

  • Реализация Фарона F1-Максимизация, ядро.
  • Подход к проектированию обучающих данных от ядра Симеона Коковидиса.
  • Уменьшите размер вашего фрейма данных, refer.
  • NMF для уменьшения разреженности, ядро.
  • Catboost документация.
  • Курс Прикладной AI