Comments 21
Ничего особенного, но статья хорошая тем, что показывает, что для компании необязательно нанимать супер-дорогих специалистов с лейблом ML чтобы использовать это самое ML для пользы бизнеса. С современным уровнем развития библиотек достаточно «горящих глаз» и здравого смысла.
Почему решили обойти вниманием CatBoost?
Про предсказание условных «спинеров».
Это «нечто» из Китая, меньше Х в закупе без специальных категорий на которые нужны сертификаты. Отслеживать количество упоминаний с соцсетях (твиттер, инстаграмм). По тегам. Глобально и в РФ. Если начинает расти — будет и спрос.
Попутно — отслеживать частоту упоминаний товара в группах типа «товары из китая оптом».
Попутно — отслеживать содержимое таргетированной рекламы в ВК — а точнее количество объявлений с этим товаром.
Соответственно сначала будет расти частота в ИГ, потом объявления в соцсетях, потом товары из китая оптом — и вот здесь в какой-то момент — товар будет из каждого утюга и пора распродавать остатки и закрывать позицию.
Для более стабильной модели можно было бы собрать ансамбль из sdgr, lgb и xgb (удивительно, что, прочитав статью, не заметил фразы «Дальше обязательно будут и нейронные сети, и параметрические модели временных рядов, и все это в ансамбле.» — очень правильное направление).
Кстати, RandomForest и ExtraTrees очень удачно ложатся в ансамбль (тюнинг на скорость), хоть сами по себе и не дают достаточной точности, но дают вес в ансамбле.
LoghtGBM покорил наши расчетливые сердца
+ у нас категориальная фича была только одна
Что касается отслеживания соцсетей и поисковых запросов — именно над этим мы сейчас и работаем!
Хотелось бы еще почитать статью по интеграции сторонних алгоритмов МО (lgb, xgb) в спарк. Как фитить такие модели.
К примеру, нетрудно предсказать, что группа товаров в целом вырастет на 5%, но при этом каждый товар в группе может как упасть на 50%, так и вырасти на 150%.
Отсюда вывод: сложное и детальное прогнозирование на уровне конкретного товара — это бессмысленные затраты времени и вычислительных ресурсов. Но без прогноза по каждому товару тоже нельзя. Поэтому следует использовать какой-либо простой метод прогнозирования (даже не важно какой) на уровне конкретных товаров и принять со смирением, что прогноз будет сильно не точен (на уровне артикула).
При этом, категория вполне предсказуема даже при значительных пертурбациях. Обладает недельной и годовой сезонностью, трендом, эластичностью к скидке и т.п.
Только плюсы к вашему комментарию.
-Cложное и детальное прогнозирование на уровне конкретного товара — это бессмысленные затраты времени и вычислительных ресурсов.
-А можно нам другого дата-сайентиста?
однако разбиение одного заказа на 4 посылки (курьер #1 — тубус с картой, курьер #2 — 2соски & 2коробки овощного пюре, курьер #3 — 4коробки овощного пюре) и доставка 3-мя разными курьерами с одного склада
и факап сроков с извинениями и начислениями скидок
любое прогнозирование делает экономически недостаточно эффективным.
А в каком разрезе собиралась ошибка? товар-день? А на какой горизонт? Очень, очень хороший mae.
Также хотелось бы узнать больше про то, как прогнозируете новинки, в т.ч. новые категории товаров. Насколько падает точность в период промоактивности.
Мы дежурили, кто-то ночью, кто-то утром просыпался, 10 лучших параметров отсматривал, перезапускал или сохранял модель и ложился спать дальше.
Работодатель отобрал паспорта? ))
Если серьезно то очень интересная статья (спасибо!), сам сейчас перед выбором подхода.
Рассматриваю в том числе и градиентный бустинг над деревьями но смущает вот этот кусок из цитаты: Demand Forecasting 2: Machine Learning Approach
"Inspired by Kaggle kernels that achieved high scores on the leaderboards by encoding weekdays and months by the mean value of their respective period, we decided to try non-autoregressive models. In this approach, the average sales actually encode 3 kinds of information – day of the week, an item and a store. Thanks to that, one model could be trained for all the items and stores. Because the predictions are independent of each other, there’s no error to accumulate, regardless of the forecast length. On the other hand, this method cannot recognize long-term trends. It’s certainly not a universal approach, but it works well in this case, thanks to the very regular data. While it potentially gets rid of the error accumulation, it stands no chance of predicting spikes and other more complicated features."
Если я правильно понял то вы трендовую составляющую пытались учесть через расчетный наклон как дополнительный предиктор, но это очень грубо, вряд ли тренд в продажах идет линейно скорее на практике он кусочно-линеен, а еще чаще полиномы и кубические сплайны. Действительно ли хватило наклона для счастья?
А в момент предсказания передавали тот же наклон что и угловой коэффициент графика продаж товара за последние 7 дней в процессе тренировки? А если он был направлен на "солнце в зените" в тренировочных данных ограничивали ли его фактором насыщения спроса?
И еще вопрос: почему не рассматривали классические модели прогнозирования: Auto.Arima, ETS, Prophet от Facebook?
Если есть время и желание — прошу протестировать ваш вариант на похожей задаче на кагле
www.kaggle.com/c/competitive-data-science-predict-future-sales
Интересная статья, спасибо. Вопрос о поведении временного ряда можно дополнительно подкрепить информацией о показателе Хёрста. Данный показатель характеризует поведение ряда и говорит о том, сменит ли рост на обратное поведение ряд или останется неизменным. А для рядов очень зашумленных покажет показатель в районе 0.5, что говорит о неопределённости в поведении. Попробуйте как доп. фичу в модели.
«как научить алгоритм предсказывать продажи новых товаров»
А до сих пор, вы работали по отдельным товарам («конкретное зеленое платье») или группам товаров («зеленые платья»)? Ведь в случае сезонности товаров (конкретный SKU живет в течении полугода), как вы переносили информацию о продажах старых зеленых платьев на новые?
Небольшой инсайд — говорят в «Пятерочке» на тему прогноза сражались две команды с разными подходами (xgboost или какой-то еще буст) и классическая ARIMA (с миллионами независимых таймсериев). И победил ARIMA-подход.
Грубая оценка (пусть каждая фича это double, то есть 8 байт):
10 000 000 * 170 * 8 / 1024 / 1024 / 1024 ~ 12ГБ + параллельный gridsearch в 10 потоков это 120ГБ, что для локальной машины часто предел в части RAM. Ассортимент обычно растет, а значит будет увеличиваться и этот объем — вероятно через год могут начаться проблемы с этим, что думаешь на этот счет? Или как-то иначе это устроено? Не пробовали с диска читать или демонизировать ml-движок и слать примеры поштучно или батчами?
Как прогнозировать спрос и автоматизировать закупки с помощью machine learning: кейс Ozon