Instacart - американская компания, предоставляющая услуги по доставке продуктов и самовывозу. Компания работает в США и Канаде. В отличие от другого веб-сайта электронной коммерции, на котором товары продаются напрямую от продавца к покупателю. Instacart позволяет пользователям покупать продукты у участвующих поставщиков. И этот шоппинг делает личный покупатель.
Задача. Задача состоит в том, чтобы построить модель, которая предсказывает, закажет пользователь товар снова или нет.
Оглавление
- Бизнес-проблема
- Обзор данных
- Зачем нужен подход ML?
- Как подойти к проблеме?
- Какая метрика используется?
- EDA
- Функциональная инженерия
- Моделирование
- Важность функции
- Развертывание с использованием Flask
- Вывод
- использованная литература
1. бизнес-проблема
Instacart cart - американская компания, занимающаяся доставкой продуктов в США и Канаду. Как и в обычном продуктовом магазине, у этой платформы есть постоянные клиенты, которые часто совершают покупки на этой платформе. Таким образом, основная цель этой проблемы заключается в том, какие продукты пользователь будет покупать снова на основе предыдущих заказов, когда он / она снова посетит платформу.
2.Обзор данных
Есть 6 файлов csv, которые можно скачать с конкурса kaggle. Приведенная выше диаграмма дает краткий обзор наборов данных, которые мы позволили обсудить по каждому набору данных.
aisles.csv: здесь aisle_id - это первичный ключ, проход - это имя прохода - это соответствующее имя прохода.
Department.csv: Первичный ключ - Department_id, а Department - соответствующее название отдела.
products.csv: здесь product_id - это первичный ключ, а product_name - соответствующее название продукта. В том же файле у нас будут aisle_id и department_id, которые говорят, к какому проходу и отделу принадлежит соответствующий продукт.
Prior_orders.csv: этот файл содержит все детали предыдущей транзакции. order_id и product_id - это оба внешних ключа. Столбцы add_to_cart_order показывают, добавлен ли конкретный продукт в корзину или нет. При повторном заказе указывается, был ли произведен повторный заказ товара.
orders.csv: этот файл состоит из разных столбцов, давайте будем идти по очереди. order_id - это первичный ключ, а user_id - это внешний ключ .order_number представляет собой количество заказов пользователя. order_dow показывает, в какой день размещается конкретный заказ, и его значение варьируется от 0 до 6, то есть с воскресенья по субботу. order_hour_day показывает, в какой час был размещен заказ, и варьируется от 0 до 24 часов в день. days_since_prior_order он говорит, через сколько дней заказывается товар, и колеблется от 0 до 30, то есть в месяц. eval_set говорит, принадлежит ли данная строка к обучающим, тестовым или предыдущим данным.
train_order.csv: он похож на файл prior_orders.csv, и эти данные мы используем для обучения модели.
3. Зачем нужен подход машинного обучения?
Например, возьмем случай, если человек заказал 26 товаров, например, a, b, c - - - z, поэтому, основываясь на предыдущих заказах, в следующий раз, когда нам нужно будет рекомендовать ему товар
, мы можем случайным образом предложить ему товары на основе его предыдущих orders, давайте рассмотрим сценарий
Если он заказал товар a 25 раз, b 24 раза, c 23 раза d 22 раза, e 24 раза x, y, z 1 раз в следующий раз, когда нам нужно будет предложить ему товары a, b, c, d, e с высшим приоритетом, а не x, y, z, поэтому мы не можем выбирать элементы случайным образом, поэтому нам нужен подход ML для этого примера.
Чтобы пользователь мог получить рекомендации по продукту на основе его последних N заказов, нам необходимо соблюдать закономерности и генерировать правила, которые будут давать рекомендации с высокой вероятностью. Поскольку у нас есть более 3 миллионов точек данных, нам необходимо автоматизировать этот процесс обучения, и с помощью машинного обучения мы можем добиться этого, чтобы давать вероятностные прогнозы. Машинное обучение лучше работает с большими наборами данных и генерирует правила на основе шаблонов, извлеченных из функций.
Другой альтернативой может быть система, основанная на правилах, которая работает лучше всего, когда мы знаем правила. Но очень сложно создавать правила, просматривая все выборки данных вручную и разбираясь в закономерностях. Это не может гарантировать высокую предсказательную силу
4. Как подойти к проблеме?
Таким образом, на основе истории заказов и пользовательских предпочтений продукта нам нужно предсказать, можно ли переупорядочить продукт или нет. Так что это скорее проблема бинарной классификации.
5. Какая метрика используется?
В качестве задачи классификации мы идем на счет f1. Причина, по которой мы стремимся к оценке f1, заключается в том, что мы должны убедиться, что у нас очень мало ложноположительных случаев.
6.EDA
Большая часть EDA выполняется с использованием гистограмм, так что неспециалисту будет легко понять ее.
Таким образом, мы видим, что бананы являются наиболее часто заказываемым продуктом, за ними следуют органическая клубника и молодой шпинат. Таким образом, пользователь с большей вероятностью будет заказывать бананы, органическую клубнику и молодой шпинат.
Как видите, около 42% заказов выполняется утром, то есть с 6:00 до 12:00. И меньше всего заказов делается ранним утром, то есть с 01:00 до 5:00. Поскольку большинство людей покупают продукты утром и после полудня.
Точнее, большинство заказов размещается с 10 до 17 часов. 10-й час дня - это пиковое время, а 3-й час, т. Е. 3 часа ночи, на платформе меньше всего заказов.
Почти 20% заказов размещаются в нулевой день, то есть в воскресенье. Таким образом, люди с большей вероятностью будут покупать продукты по воскресеньям, поскольку это праздник для большинства людей, что имеет смысл.
Около 50% заказов и повторных заказов осуществляется в первую неделю месяца. Поскольку большинство людей получают зарплату в первую неделю месяца, это имеет смысл.
Заказ против повторного заказа
Вероятность повторного заказа почти 60% товаров повышается.
Чтобы узнать больше о EDA, вы можете следить за EDA.ipynb, о котором я упоминал в репозитории git в конце блога. Я не хочу утомлять людей все большим количеством материалов EDA.
7. особенности инженерии
Это самая сложная часть всего тематического исследования. Чем лучше мы разрабатываем функции, тем лучше получаем результаты. Поэтому в этом блоге я упоминаю несколько методов разработки функций.
а) пользовательские функции:
user_reorder_rate: здесь мы рассчитали частоту повторного заказа пользователя, то есть total_reorders / total_orders для каждого пользователя
no_unique_products_user: Общее количество уникальных, заказанных пользователем
avg_cart_size: средний размер корзины пользователя, когда пользователь посещает платформу.
avg_days_between_orders: среднее количество дней перерыва между двумя заказами
reorder_rate_f15: скорость повторного заказа пользователя за первые 15 дней месяца
reorder_rate_l15: частота повторных заказов пользователей за последние 15 дней месяца
б) особенности продукта для пользователей:
user_product_reorder_rate: ни разу пользователь не заказал продукт / ни разу пользователь не разместил заказ.
user_product_avg_position: средняя позиция товара в корзине по заказам, размещенным пользователем.
в) особенности продукта
product_reorder_rate: ни разу товар не переупорядочивался
dept_reorder_rate: ни разу не переупорядочивали отдел
aisle_reorder_rate: ни разу не меняли порядок прохода
г) прочие особенности:
order_hour_of_day_rate: в какой час размещается наибольшее количество заказов.
dow_rate: в какой день размещается больше всего заказов.
word2vec: мы реализовали функцию word2vec для названия продукта, названия отдела и названия прохода, используя spacy и PCA. Эта особенность используется для повышения рейтинга f1score.
Подобным образом я создал около 70 функций, описывающих, что каждая функция в блоге скучна и сложна для других техник разработки функций, которые вы можете использовать в файле featureization_2-Copy1.ipynb.
8. Моделирование
Я обучил 3 модели, то есть классификатор LGBM, классификатор SGD и дерево решений. По которым мы получили лучшие результаты по LGBM Classifier. Здесь лучшие результаты означают улучшение публичных и частных оценок f1score после того, как мы отправим CSV-файл с результатами на kaggle. Вы можете увидеть обучающую часть в файле modelling_part1-Copy1.ipynb.
9. Важность особенности
Итак, как я упоминал ранее, я создал около 70 функций, поэтому мне могут не потребоваться все функции, чтобы получить наилучшую классификацию для окончательного вывода. Поэтому я использовал классификатор LGBM, чтобы получить важные функции.
Из всех функций наивысший приоритет имеет порядок user_product_since_last, за которым следуют user_id, user_product_reorder_rate.
Причина важности функции заключается в том, что когда мы развертываем модель для производства, если на картинке появляются новые точки запроса, вычисление всех 70 функций для новой точки запроса занимает много времени, поэтому, задавая важность функции, мы можем выбрать 10–15 лучших функций с этим особенности, мы можем более точно предсказать результат. Таким образом, вычисление 70 функций для новой точки запроса и прогнозирование результата, вычисление 15 функций для одной и той же точки запроса и прогнозирование результата будут одинаковыми, поэтому, чтобы сэкономить время и уменьшить время задержки системы, мы обращаем внимание на важность функций.
Вы можете увидеть важность функции в файле modelling_part1-Copy1.ipynb. Когда я развернул модель на локальном хосте, я взял все функции, если мы перейдем к облачному хостингу, мы можем выбрать только 15 лучших функций и обучить новую модель этим функциям и использовать то же самое для развертывания.
10. Развертывание с помощью Flask
Поскольку я обнаружил, что классификатор LGBM работает лучше всего, я использовал его для окончательного производства, то есть для развертывания на локальном хосте с использованием фляги. Вы можете увидеть часть хостинга в файле hosting.ipynb.
11. Заключение
Итак, наконец, с этим тематическим исследованием я натолкнулся на полную цепочку обработки данных, то есть получение данных, выполнение EDA, манипулирование данными, разработку функций, подготовку данных для обучения, обучение модели и развертывание модели.
12. Ссылки
Правило ассоциации - извлечение знаний с помощью анализа рыночной корзины
Чтобы проверить всю работу, вы можете посетить мой репозиторий git
Вы можете связаться со мной через linkedin
