Выводы из работы с данными из интернет-магазина товаров Google
Последние пару недель я работал с командой над конкурсом Kaggle, чтобы создать модель машинного обучения, которая может прогнозировать доход от электронной коммерции в онлайн-магазине товаров Google. Это были американские горки взлетов и падений, но я чувствовал, что ушел с большим пониманием того, как решать проблемы реального мира.
Анализ данных
С самого начала было очевидно, что у нас будут проблемы. Предоставленные данные относятся к сеансам, открытым на веб-сервере магазина. Любой, кто открыл этот файл, заметил бы, что это не совсем рай для машинного обучения - множество категориальных переменных, ряд столбцов - это файлы JSON, которые также заполнены категориальными переменными. Существовала лишь горстка золотых самородков числовых значений - просмотры страниц, просмотры и т. Д. Хотя моя команда могла бы попытаться создать сложный набор кодировок или фиктивных переменных, мы решили начать углубленный анализ, чтобы определить, какие из этих переменных полезные, а какие нет.
В реальных наборах данных вам придется запачкать руки - маловероятно, что вы получите чистый числовой фрейм данных на серебряном блюде.
Как только мы начали наш исследовательский анализ, нас осенило еще одно - в большинстве этих строк даже нет значений транзакций, что мы и должны были прогнозировать. Где транзакции? Оказывается, в 98,7% сеансов транзакции не совершались. Хотя эта проблема является проблемой регрессии, в ее основе лежит скрытая проблема классификации: можем ли мы определить, какие сеансы или пользователи совершали транзакции?
Разбери свои данные и пойми свою проблему - под капотом могут быть скрытые проблемы.
После того, как мы начали подбирать модели, моя команда и я обнаружили, что мы получали гораздо лучшие результаты, когда агрегировали на уровне пользователя, а не на уровне необработанного сеанса. Хотя я могу сказать, что многие другие пользователи Kaggle могли очень хорошо предсказывать на уровне сеанса, большая ценность была получена от агрегирования данных на уровне пользователя. В конце концов, интернет-магазин, вероятно, предпочтет понимать своих пользователей, а не их сеансы.
Чего хочет бизнес? Другой взгляд на обувь другого человека может изменить ход вашего проекта.
Подход к моделированию
Мы исследовали ряд подходов к моделированию. Во-первых, просто использовались методы регрессии, которые служили базой для сравнения.
Самым интересным выводом из этого проекта стало использование нами специального оценщика для создания модели стекирования. Создать собственный оценщик действительно довольно просто: если вы раньше писали класс на Python и использовали sklearn, у вас не должно возникнуть проблем. Посмотрите наш код на Github, если вам нужно с чего начать!
Одним из преимуществ пользовательского оценщика является то, что мы смогли использовать несколько интерпретируемых моделей, чтобы получить лучшую производительность, чем сами отдельные модели. Это позволило нам приблизиться к производительности сложной, менее интерпретируемой модели, но без ущерба для интерпретируемости. В конце концов, лучшая модель стекирования следовала приведенной ниже блок-схеме:
В конце концов, модель LightGBM имела лучшую предсказательную точность.
Спасибо Ziyu Fan, Yixin Sun и Xi Yang за отличную работу над этим проектом!
Вы можете проверить наш код на Github: https://github.com/ml-bestgroup/mlfinal