Comments 22
Спасибо за статью.
Ничего особенного, но статья хорошая тем, что показывает, что для компании необязательно нанимать супер-дорогих специалистов с лейблом ML чтобы использовать это самое ML для пользы бизнеса. С современным уровнем развития библиотек достаточно «горящих глаз» и здравого смысла.
Почему решили обойти вниманием CatBoost?
Про предсказание условных «спинеров».
Это «нечто» из Китая, меньше Х в закупе без специальных категорий на которые нужны сертификаты. Отслеживать количество упоминаний с соцсетях (твиттер, инстаграмм). По тегам. Глобально и в РФ. Если начинает расти — будет и спрос.
Попутно — отслеживать частоту упоминаний товара в группах типа «товары из китая оптом».
Попутно — отслеживать содержимое таргетированной рекламы в ВК — а точнее количество объявлений с этим товаром.
Соответственно сначала будет расти частота в ИГ, потом объявления в соцсетях, потом товары из китая оптом — и вот здесь в какой-то момент — товар будет из каждого утюга и пора распродавать остатки и закрывать позицию.
Ничего особенного, но статья хорошая тем, что показывает, что для компании необязательно нанимать супер-дорогих специалистов с лейблом ML чтобы использовать это самое ML для пользы бизнеса. С современным уровнем развития библиотек достаточно «горящих глаз» и здравого смысла.
Почему решили обойти вниманием CatBoost?
Про предсказание условных «спинеров».
Это «нечто» из Китая, меньше Х в закупе без специальных категорий на которые нужны сертификаты. Отслеживать количество упоминаний с соцсетях (твиттер, инстаграмм). По тегам. Глобально и в РФ. Если начинает расти — будет и спрос.
Попутно — отслеживать частоту упоминаний товара в группах типа «товары из китая оптом».
Попутно — отслеживать содержимое таргетированной рекламы в ВК — а точнее количество объявлений с этим товаром.
Соответственно сначала будет расти частота в ИГ, потом объявления в соцсетях, потом товары из китая оптом — и вот здесь в какой-то момент — товар будет из каждого утюга и пора распродавать остатки и закрывать позицию.
Имея совсем небольшой опыт работы с CatBoost, могу сказать, что 15 млн товаров со 170 «фичами» будут обсчитываться довольно продолжительное время и на подобных задачах (timeseries +-) LightGBM показывает себя немного лучше и более устойчив к «оверфитингу».
Для более стабильной модели можно было бы собрать ансамбль из sdgr, lgb и xgb (удивительно, что, прочитав статью, не заметил фразы «Дальше обязательно будут и нейронные сети, и параметрические модели временных рядов, и все это в ансамбле.» — очень правильное направление).
Кстати, RandomForest и ExtraTrees очень удачно ложатся в ансамбль (тюнинг на скорость), хоть сами по себе и не дают достаточной точности, но дают вес в ансамбле.
Для более стабильной модели можно было бы собрать ансамбль из sdgr, lgb и xgb (удивительно, что, прочитав статью, не заметил фразы «Дальше обязательно будут и нейронные сети, и параметрические модели временных рядов, и все это в ансамбле.» — очень правильное направление).
Кстати, RandomForest и ExtraTrees очень удачно ложатся в ансамбль (тюнинг на скорость), хоть сами по себе и не дают достаточной точности, но дают вес в ансамбле.
Сейчас как раз в процессе обучение самых разнородных моделей с амбициями составить из них «разнородный» ансамбль! Более того, хотим попилить товары на кластеры по «характеру» продаж и для каждого кластера выбрать свои топ-3 или больше моделей.
LoghtGBM покорил наши расчетливые сердца
LoghtGBM покорил наши расчетливые сердца
Я бы еще предложил сделать правильный «скейлинг» «фич» — так как метрики часто в разных плоскостях и кластеризацию по уровню продаж (там где это возможно) с уходом в rmse. RMSE будет иногда лучшей метрикой, чем MAE, так как покажет частотные ошибки с большой разницей реальных продаж с предсказанием.
С CatBoost возились довольно долго, но заставить работать быстро так и не получилось.
+ у нас категориальная фича была только одна
Что касается отслеживания соцсетей и поисковых запросов — именно над этим мы сейчас и работаем!
+ у нас категориальная фича была только одна
Что касается отслеживания соцсетей и поисковых запросов — именно над этим мы сейчас и работаем!
На счет соц. сетей — очень рекомендую www.babelstreet.com — много сетей, глубокий анализ текста и не только текста, «ленивые запросы» итд. (дорого)))
Спасибо за материал.
Хотелось бы еще почитать статью по интеграции сторонних алгоритмов МО (lgb, xgb) в спарк. Как фитить такие модели.
Хотелось бы еще почитать статью по интеграции сторонних алгоритмов МО (lgb, xgb) в спарк. Как фитить такие модели.
Есть общеизвестный факт для прогнозирования экономических показателей (в т.ч. и для продаж): чем более детальней и сложнее прогнозирование, тем менее будет точен прогноз.
К примеру, нетрудно предсказать, что группа товаров в целом вырастет на 5%, но при этом каждый товар в группе может как упасть на 50%, так и вырасти на 150%.
Отсюда вывод: сложное и детальное прогнозирование на уровне конкретного товара — это бессмысленные затраты времени и вычислительных ресурсов. Но без прогноза по каждому товару тоже нельзя. Поэтому следует использовать какой-либо простой метод прогнозирования (даже не важно какой) на уровне конкретных товаров и принять со смирением, что прогноз будет сильно не точен (на уровне артикула).
К примеру, нетрудно предсказать, что группа товаров в целом вырастет на 5%, но при этом каждый товар в группе может как упасть на 50%, так и вырасти на 150%.
Отсюда вывод: сложное и детальное прогнозирование на уровне конкретного товара — это бессмысленные затраты времени и вычислительных ресурсов. Но без прогноза по каждому товару тоже нельзя. Поэтому следует использовать какой-либо простой метод прогнозирования (даже не важно какой) на уровне конкретных товаров и принять со смирением, что прогноз будет сильно не точен (на уровне артикула).
А еще сюда же крайне изменчивая реакция на скидку, новинки и вывод позиций, взаимное влияние акций на товары-конкуренты и наоборот товары, дополняющие друг друга в корзине и т.п.
При этом, категория вполне предсказуема даже при значительных пертурбациях. Обладает недельной и годовой сезонностью, трендом, эластичностью к скидке и т.п.
Только плюсы к вашему комментарию.
При этом, категория вполне предсказуема даже при значительных пертурбациях. Обладает недельной и годовой сезонностью, трендом, эластичностью к скидке и т.п.
Только плюсы к вашему комментарию.
-Cложное и детальное прогнозирование на уровне конкретного товара — это бессмысленные затраты времени и вычислительных ресурсов.
-А можно нам другого дата-сайентиста?
это всё выглядит прекрасно, наукообразно и положительно влияет на инвесторов,
однако разбиение одного заказа на 4 посылки (курьер #1 — тубус с картой, курьер #2 — 2соски & 2коробки овощного пюре, курьер #3 — 4коробки овощного пюре) и доставка 3-мя разными курьерами с одного склада
и факап сроков с извинениями и начислениями скидок
любое прогнозирование делает экономически недостаточно эффективным.
однако разбиение одного заказа на 4 посылки (курьер #1 — тубус с картой, курьер #2 — 2соски & 2коробки овощного пюре, курьер #3 — 4коробки овощного пюре) и доставка 3-мя разными курьерами с одного склада
и факап сроков с извинениями и начислениями скидок
любое прогнозирование делает экономически недостаточно эффективным.
Спасибо за статью.
А в каком разрезе собиралась ошибка? товар-день? А на какой горизонт? Очень, очень хороший mae.
Также хотелось бы узнать больше про то, как прогнозируете новинки, в т.ч. новые категории товаров. Насколько падает точность в период промоактивности.
А в каком разрезе собиралась ошибка? товар-день? А на какой горизонт? Очень, очень хороший 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?
У вас же time series. LSTM или хотябы SARIMAX почему сразу не пробовали? Я все понимаю, вы сделали CV time_series, но сами классификаторы у вас таковы, что без заранее приготовленных фич связанных с сезонностью — они не взлетят.
Мое скромное мнение, что прогноз продаж — это не классический вариант time series. Невозможно предсказать ARIMA моделью продажи например новых товаров. Также невозможно делать хоть сколько нибудь точный прогноз на «сильно разряженных» данных. Классический ARIMA подход хорошо подходит для плотных потоков данных и желательно одного типа.
Если есть время и желание — прошу протестировать ваш вариант на похожей задаче на кагле
www.kaggle.com/c/competitive-data-science-predict-future-sales
Если есть время и желание — прошу протестировать ваш вариант на похожей задаче на кагле
www.kaggle.com/c/competitive-data-science-predict-future-sales
Интересная статья, спасибо. Вопрос о поведении временного ряда можно дополнительно подкрепить информацией о показателе Хёрста. Данный показатель характеризует поведение ряда и говорит о том, сменит ли рост на обратное поведение ряд или останется неизменным. А для рядов очень зашумленных покажет показатель в районе 0.5, что говорит о неопределённости в поведении. Попробуйте как доп. фичу в модели.
«как научить алгоритм предсказывать продажи новых товаров»
А до сих пор, вы работали по отдельным товарам («конкретное зеленое платье») или группам товаров («зеленые платья»)? Ведь в случае сезонности товаров (конкретный SKU живет в течении полугода), как вы переносили информацию о продажах старых зеленых платьев на новые?
Небольшой инсайд — говорят в «Пятерочке» на тему прогноза сражались две команды с разными подходами (xgboost или какой-то еще буст) и классическая ARIMA (с миллионами независимых таймсериев). И победил ARIMA-подход.
Спасибо за статью, было интересно! Правильно ли я понял, что собранный спарком датафрейм в конце делает toPandas() на какой-то локальный сервер (а точнее на драйвер спарка, кстати сервер в кластере или в сторонке?), где с ним уже работают модели? Видел про 10кк строк и 170 столбцов — так понял, что это как раз размер этого датафрейма.
Грубая оценка (пусть каждая фича это double, то есть 8 байт):
10 000 000 * 170 * 8 / 1024 / 1024 / 1024 ~ 12ГБ + параллельный gridsearch в 10 потоков это 120ГБ, что для локальной машины часто предел в части RAM. Ассортимент обычно растет, а значит будет увеличиваться и этот объем — вероятно через год могут начаться проблемы с этим, что думаешь на этот счет? Или как-то иначе это устроено? Не пробовали с диска читать или демонизировать ml-движок и слать примеры поштучно или батчами?
Грубая оценка (пусть каждая фича это double, то есть 8 байт):
10 000 000 * 170 * 8 / 1024 / 1024 / 1024 ~ 12ГБ + параллельный gridsearch в 10 потоков это 120ГБ, что для локальной машины часто предел в части RAM. Ассортимент обычно растет, а значит будет увеличиваться и этот объем — вероятно через год могут начаться проблемы с этим, что думаешь на этот счет? Или как-то иначе это устроено? Не пробовали с диска читать или демонизировать ml-движок и слать примеры поштучно или батчами?
Александр, здравствуйте.
Было немного странно читать эту статью, потому что вы пытаетесь делать то, что не надо делать, и не делаете то, что делать надо. И это в такой махине, как Озон. Но, ладно.
Вы пытаетесь создать оракула типа Ванги, или Нострадамуса, в то время как вам нужно просто вовремя подвозить снаряды (логистика появилась исторически из военной сферы, да).
Цель вашей системы — эффективное (определим это ниже) управление товарными запасами в точках хранения товаров.
Цель Озона — обеспечить наличие товара на складе для Покупателей (по приемлемой цене, конечно). Это один из важнейших показателей, о котором вы пишите в статье, как о боли (остатки товара падают в ноль, и Озон теряет продажи этого товара неделями), но, возможно, не отслеживаете его в явном виде, или не ставите в приоритет над 170 другими метриками.
Но если склад забить товаром до потолка, то либо у коммерсов закончится оборотка (это вторая боль, о которой вы пишите), либо склад обрушится, как на видосе, гуляющем недавно в соцсетях. Поэтому уравновешивающий показатель к «наличию» — оборачиваемость товарного запаса.
Таким образом, для эффективного управления запасами, вся система должна бы делать следующее: обеспечивать непрерывное наличие товара на складе, поддерживая его высокую оборачиваемость. Делов-то.
Подсказка для матмодели (если вам будет не лениво её делать): в цикле оборачиваемости нужно учитывать 1) товар в заявках поставщику, 2) товар в дороге, 3) свободный остаток на складе. Соответственно, цикл оборачиваемости товара растянется на время, равное «от заявки до отгрузки товара поставщиком»+«доставка от поставщика до приходования на складе Озона»+«лежание на складе до момента продажи». Если товар отгружается по предоплате, то цикл оборачиваемости денег будет от «оплаты поставщику» до «получения денег от Покупателя», но сократится пропорционально % маржи с продажи. Оборотные средства = цена закупки единицы * скорость продаж (штук в день) * цикл оборачиваемости денег в днях.
Коммерсы захотят сократить количество оборотки (это ж боль). Для этого
1) ищем поставщиков с коротким сроком поставки, а не с самой низкой ценой. Работаем с поставщиками на сокращение цикла поставки (это человечки в штат, которых можно купить вместо новых кластеров — сорри)
2) Выбираем по возможности более скоростной транспорт от поставщика — самолёт может быть лучше чем пароход, даже если он дороже
3) Не формируем больших партий отгрузки (это растягивает ожидание и увеличит оборотку)
4) Держим на складе запас не в штуках, а в днях продаж (о, пригодится статистика продаж). Чем меньше держим запаса на складе, тем короче цикл оборачиваемости товарного запаса, тем меньше оборотки нам надо. Но слишком мало держать нельзя, потому что из за неопределённости у поставщиков и в спросе начнут возникать стокауты. Смотрим дальше.
Про наличие (его же тоже надо поддерживать, иначе — боль). Точнее требуемый товарный запас по каждому SKU в каждой точке хранения считается вашей IT системой по незамысловатой методике, описанной в книжках. Ну, или можно за копейки купить готовое и обкатанное ПО (не моё, но могу порекомендовать разные) которое можно развернуть на ваших серверах. Целевой запас при этом будет динамически изменяться на основании фактического спроса по данной SKU в данной точке хранения. Спрос упал — система сократит целевой запас. Спрос вырос — система увеличит целевой запас.
Так же система будет обладать двумя магическими свойствами — устойчивостью к сбоям у поставщиков, в транспорте (тот самый рандом, который вы закладывали в модель), и колебаний спроса (да, тут ваши механизмы предсказаний существенно улучшат реакцию системы, но им понадобится меньше параметров, и обучение будет занимать гораздо меньше вычислительных ресурсов и времени), и заранее предупреждать о возникающих проблемах с наличием товара, так, что в большинстве случаев у закупщиков будет время на устранение этих проблем.
Буду рад про это всё пообщаться. Если захотите, меня можно найти тут (в LI я редко хожу). Могу рассказать с кейсами (в цифрах — с показателями оборачиваемости складских запасов, с показателями наличия товаров, с показателями по оборотным средствам) как это работает, где взять подробную информацию, куда пойти учиться и какое ПО есть готовое. Думаю это ПО потянет ваше количество SKU, но даже если нет, то для хайлоада у вас естьХалк Хек ;)
PS Если поставщик фарфоровых стоматологов отгружает товар по расписанию раз в неделю, а фарфоровые стоматологи продаются примерно раз в пару месяцев, то есть смысл держать двух стоматологов на складе. Тогда если один стоматолог ушел со склада, вы его тут же перезаказываете поставщику, а до очередной поставки у вас с высокой вероятностью будет второй стоматолог в наличии. Даже если купят второго стоматолога, вероятность третьей продажи низкооборачиваемого стоматолога за оставшееся до поставки время исчезающе мала. То есть потеря маржи из-за стокаута для третьего покупателя крайне маловероятна. Два «фарфоровых стоматолога» на складе — это минимальный сток для подобных низкооборачиваемых позиций.
PPS Если поставщик отгружает товар на отсрочке платежа, то достаточно иметь отсрочку на период цикла оборачиваемости денег — тогда Озону на товар этого поставщика не понадобится своя оборотка.
Успехов.
Было немного странно читать эту статью, потому что вы пытаетесь делать то, что не надо делать, и не делаете то, что делать надо. И это в такой махине, как Озон. Но, ладно.
Вы пытаетесь создать оракула типа Ванги, или Нострадамуса, в то время как вам нужно просто вовремя подвозить снаряды (логистика появилась исторически из военной сферы, да).
Цель вашей системы — эффективное (определим это ниже) управление товарными запасами в точках хранения товаров.
Цель Озона — обеспечить наличие товара на складе для Покупателей (по приемлемой цене, конечно). Это один из важнейших показателей, о котором вы пишите в статье, как о боли (остатки товара падают в ноль, и Озон теряет продажи этого товара неделями), но, возможно, не отслеживаете его в явном виде, или не ставите в приоритет над 170 другими метриками.
Но если склад забить товаром до потолка, то либо у коммерсов закончится оборотка (это вторая боль, о которой вы пишите), либо склад обрушится, как на видосе, гуляющем недавно в соцсетях. Поэтому уравновешивающий показатель к «наличию» — оборачиваемость товарного запаса.
Таким образом, для эффективного управления запасами, вся система должна бы делать следующее: обеспечивать непрерывное наличие товара на складе, поддерживая его высокую оборачиваемость. Делов-то.
Подсказка для матмодели (если вам будет не лениво её делать): в цикле оборачиваемости нужно учитывать 1) товар в заявках поставщику, 2) товар в дороге, 3) свободный остаток на складе. Соответственно, цикл оборачиваемости товара растянется на время, равное «от заявки до отгрузки товара поставщиком»+«доставка от поставщика до приходования на складе Озона»+«лежание на складе до момента продажи». Если товар отгружается по предоплате, то цикл оборачиваемости денег будет от «оплаты поставщику» до «получения денег от Покупателя», но сократится пропорционально % маржи с продажи. Оборотные средства = цена закупки единицы * скорость продаж (штук в день) * цикл оборачиваемости денег в днях.
Коммерсы захотят сократить количество оборотки (это ж боль). Для этого
1) ищем поставщиков с коротким сроком поставки, а не с самой низкой ценой. Работаем с поставщиками на сокращение цикла поставки (это человечки в штат, которых можно купить вместо новых кластеров — сорри)
2) Выбираем по возможности более скоростной транспорт от поставщика — самолёт может быть лучше чем пароход, даже если он дороже
3) Не формируем больших партий отгрузки (это растягивает ожидание и увеличит оборотку)
4) Держим на складе запас не в штуках, а в днях продаж (о, пригодится статистика продаж). Чем меньше держим запаса на складе, тем короче цикл оборачиваемости товарного запаса, тем меньше оборотки нам надо. Но слишком мало держать нельзя, потому что из за неопределённости у поставщиков и в спросе начнут возникать стокауты. Смотрим дальше.
Про наличие (его же тоже надо поддерживать, иначе — боль). Точнее требуемый товарный запас по каждому SKU в каждой точке хранения считается вашей IT системой по незамысловатой методике, описанной в книжках. Ну, или можно за копейки купить готовое и обкатанное ПО (не моё, но могу порекомендовать разные) которое можно развернуть на ваших серверах. Целевой запас при этом будет динамически изменяться на основании фактического спроса по данной SKU в данной точке хранения. Спрос упал — система сократит целевой запас. Спрос вырос — система увеличит целевой запас.
Так же система будет обладать двумя магическими свойствами — устойчивостью к сбоям у поставщиков, в транспорте (тот самый рандом, который вы закладывали в модель), и колебаний спроса (да, тут ваши механизмы предсказаний существенно улучшат реакцию системы, но им понадобится меньше параметров, и обучение будет занимать гораздо меньше вычислительных ресурсов и времени), и заранее предупреждать о возникающих проблемах с наличием товара, так, что в большинстве случаев у закупщиков будет время на устранение этих проблем.
Буду рад про это всё пообщаться. Если захотите, меня можно найти тут (в LI я редко хожу). Могу рассказать с кейсами (в цифрах — с показателями оборачиваемости складских запасов, с показателями наличия товаров, с показателями по оборотным средствам) как это работает, где взять подробную информацию, куда пойти учиться и какое ПО есть готовое. Думаю это ПО потянет ваше количество SKU, но даже если нет, то для хайлоада у вас есть
PS Если поставщик фарфоровых стоматологов отгружает товар по расписанию раз в неделю, а фарфоровые стоматологи продаются примерно раз в пару месяцев, то есть смысл держать двух стоматологов на складе. Тогда если один стоматолог ушел со склада, вы его тут же перезаказываете поставщику, а до очередной поставки у вас с высокой вероятностью будет второй стоматолог в наличии. Даже если купят второго стоматолога, вероятность третьей продажи низкооборачиваемого стоматолога за оставшееся до поставки время исчезающе мала. То есть потеря маржи из-за стокаута для третьего покупателя крайне маловероятна. Два «фарфоровых стоматолога» на складе — это минимальный сток для подобных низкооборачиваемых позиций.
PPS Если поставщик отгружает товар на отсрочке платежа, то достаточно иметь отсрочку на период цикла оборачиваемости денег — тогда Озону на товар этого поставщика не понадобится своя оборотка.
Успехов.
Sign up to leave a comment.
Как прогнозировать спрос и автоматизировать закупки с помощью machine learning: кейс Ozon