На сколько показывает мой опыт, который также описан в статье, все ровно да наоборот:
Тяжело предсказывать спрос на отдельно взятый товар, гораздо легче на спрос по группе товаров или даже по сети в целом (в моем случае я описал предсказание дневного количества чеков по всей сети с высоким уровнем точности, данные можно посмотреть в статье).
Вы неправильно поняли мой поинт. Вы говорите о предсказаниях для групп товаров, а я говорю о том, что предсказания нужны для каждого товара в отдельности, поскольку как supplies management, так и dynamic pricing в конечном итоге делаются на уровне товаров.
Я пробовал предсказывать спрос как в штуках, так и по сумме продаж по группам товаров и все выходило гораздо лучше, чем по индивидуальному товару, как на уровне дней, так и на более продолжительных масштабах времени (дальше месяца не смотрел потому что данных мало).
Опять таки, суть замечания была не в этом. Вы говорите о предсказании с большим шагом (например, недельные предсказания, которые вы делали во второй части), а я говорю о предсказании на несколько шагов, которое, опять таки, как раз и нужно ретейлерам. В вашем же примере, если у товара срок годности 5 дней, то вам нужен не прогноз на день вперёд или на неделю вперёд, а, вероятнее всего, daily prediction примерно на пять дней.
Потому что предсказание +-50% (например) от факта продаж сводит на нет всю адекватность системы установления цены соразмерно ожидаемому спросу. Если систематически ошибаться в предсказании и достаточно сильно, то какой смысл в таких рекомендациях? Поэтому, я не говорю, что само по себе значение 0.4 плохо, я говорю лишь о том, что оно не достаточно.
Так, может, вам надо было MAPE мерять, а не R^2? Объясните мне, как вы по значению R^2_adj=0.4 сделали вывод о качестве предсказания, если оно практически не интерпретируемо? И даже по MAPE как бы вы делали вывод, если вы не задали себе нужные значения метрик?
Не знаю, с чего вы это взяли, графики построены, включая всю историю для визуального восприятия информации. Обучение происходило на тренировочной части, затем обученная модель предсказывала спрос на тестовой выборке. После этого обучения никакого не происходило.
По нескольким строчкам кода судить о чем то не совсем корректно (вы же не знаете что там в неопубликованной части кода).
Я и не говорил про обучение на тестовой части. Я говорил про тюнинг гиперпараметров, который вы, очевидно, делали на тестовой части, потому что отдельной валидационной у вас просто не было. Простите, что кидаю ссылки на видео из курсов по ML, но объяснять самому у меня плохо получается.
Эти два фактора несут разную информацию, потому что в исследуемом товаре 5л, а в «CERESIT СТ 17» – 10 литров
Занимательная арифметика.
x — цена товара
y — цена CERESIT
f1 = x / y
f2 = (x/5) / (y/10) = x*2 / y
f2 = 2*f1
Если вычисления выше верны, то эта фича добавляет ноль новой информации в модель.
Возможно метод был действительно экстравагантен, однако, на тот момент, когда я использовал грубое отсечение факторов таким вот образом, мне было необходимо понять, какие товары-соседы из группы вообще стоит учитывать, а какие нет (их было много и очень много, поэтому один плюс, другой минус, не меняло бы картины в целом, поскольку по факту внутри группы очень мало продаж товаров было коррелировано – это я смотрел, но это не вошло в статью).
Дело в том, что это не экстравагантно, а не вполне корректно. Ещё раз повторю, что бустинг и LSTM — это модели абсолютно разной природы, и с фичами они работают по-разному. То же самое и с отбором фич по скоррелированности продаж, который вы упомянули: полагаться на корреляцию при отборе признаков для таких сложных моделей нельзя.
Гиперболизированный пример.
Ваша целевая переменная — y.
У вас есть признак
f1 = abs(y)
Корреляция околонулевая, а между тем f1 — идеальный предиктор y.
Какой именно прирост вы увидели (в деньгах, в штуках?)
В выручке и прибыли в сводной таблице, очевидно. У вас выручка в 2016 была на 28% больше, чем за год до этого, а в 2017 (с моделью) — на 13%.
А ведь именно выручка или прибыль в конечном итоге являлась для вас оптимизируемой бизнес-метрикой.
Насчет промаха в предсказании спроса: про оверфит я уже ответил, что ни заглядывания в будущее, ни обучения на тестовой выборке не было.
Вы путаете data leakage и overfitting. То, что у вас модель хорошо работает на трейне и отвратительно в продакшене — это симптом оверфита по определению.
2018 год, но люди всё равно продолжают упорно использовать ВКонтакте как файлообменник, несмотря на то, что в инструкциях по написанию статей на хабре чёрным по белому написано заливать фото на хабрасторедж.
Главная проблема этой работы в том, что когда вы создавали модель, вы работали с одним конкретным рядом. Затюнить модель так, чтобы она более-менее хорошо предсказывала спрос на один товар, можно. Но на практике ретейлеру обычно нужно предсказывать спрос сразу на все товары, а вот тут сложные модели типа бустингов и сетей становится куда сложнее настраивать, а также появляется необходимость в более сложном feature engineering (например, нельзя сделать dummy-переменные под конкретные акции, потому что у каждого товара может быть свой набор скидок в разные моменты времени, которые комбинируются произвольным образом, и приходится из этих данных строить какие-то новые, более общие фичи). Кроме того, редко ретейлеру реально нужно предсказывать спрос на день вперёд для менеджмента закупок, да и для оптимизации цен это, наверное, не вполне корректно. Поэтому я, честно говоря, сомневаюсь в том, насколько построенная модель способна принести пользу заказчику в реальной жизни (помимо того, что она в целом демонстрирует практическую жизнеспособность работы с price elasticity с помощью ML-алгоритмов). Также есть несколько более мелких деталей, которые меня смущают:
Сделал я это в расчете на то, что XGBoost поможет мне отбросить множество ненужных факторов (это происходит автоматически), и уже оставшиеся использовать для LSTM модели.
Почему вы считаете, что так корректно делать? Деревянные модели работают с признаками совсем не так, как сети. Фичи, которые бустингу показались полезными, могут не взлететь в сети, и наоборот. И уж точно фичи, подаваемые на вход бустингу, надо обрабатывать совсем не так, как фичи, подаваемые на вход сети.
Наилучший результат, которого я смог добиться, используя greed search выглядит следующим образом
Наверное, всё же grid search.
Итоговые результаты поубавили мою веру в успех, потому что результат R^2-adj 0.4 означал только то, что система предсказания не сможет предсказывать спрос на следующий день достаточно хорошо, а рекомендация на цену будет мало отличаться от системы «пальцем в небо».
Вообще-то нет, такое значение нельзя интерпретировать подобным образом для временного ряда, и, пожалуй, вообще нельзя говорить, хороший это показатель или плохой, не сравнив с хотя бы какими-то примитивными бейзлайновыми моделями.
После этого я, уже традиционно, использовал XGBoost, чтобы отсечь прочие не значимые факторы. В последствии я дополнительно отсек еще несколько факторов, на основе LSTM модели, просто поочередно исключая факторы, обучая модель заново и сравнивая результаты.
Если вы делали это, валидируясь на той же части датасета, которую вы называете тестовой (а судя по графикам и коду, вы это делали), поздравляю — вы оверфитнулись.
Соотношение цены за килограмм исследуемого товара и грунтовки CERESIT СТ 17 10 л.;
Соотношение цены исследуемого товара и товара и грунтовки CERESIT СТ 17 10 л;
Разве вторая фича не получается из первой линейным преобразованием?
Итоговая LSTM модель была написана с использованием Keras, включала в себя 2 скрытых слоя (25 и 20 нейронов соответственно), и активатор – сигмоиду.
С одной стороны, сигмоида на конце — это удобно. С другой стороны, таким образом вы практически лишаете модель возможности экстраполировать, что довольно важно для построения кривой эластичности, не так ли?
В итоге мы получаем двоякую картину: совершенно не реалистичные предсказания по объему продаж, но, при этом, сугубо положительные результаты по экономическим показателям (как по прибыли, так и выручке).
Позволю себе не согласиться. Если сравнить даже 2016 и 2015 годы, можно увидеть огромный естественный прирост (очевидно, связанный с тем, что ретейлер работает в плюс и расширяется), так что ваш эксперимент абсолютно не показателен и, вполне вероятно, мог не принести повышения прибыли (во всяком случае, ваши данные этого не подтверждают).
Кроме того, то, насколько сильно ваша модель ошибалась в предсказаниях (намного сильнее, чем на тестовой части датасета), ещё раз свидетельствует о том, о чём я писал выше — настраивая параметры под тестовую часть, вы сильно заоверфитились.
В целом, вроде и хороший пример использования ML в бизнесе, но при этом недочётов столько, что результаты вызывают огромное сомнение.
Лично меня не напрягает перемешивание русского текста с английским, но:
если изначально дать собственные обозначения, кто-то потом может не связать их с общераспространёнными терминами в других местах
Можно не давать собственные обозначения. Я же выше привёл общепринятые, в общем-то (кроме разве что instance segmentation, где перевод не особо устоявшийся).
Спасибо за статью. Отличный обзорный материал!
Хотелось бы отметить одну вещь насчет терминологии:
не приходилось встречать переводы их названий даже в русскоязычных источниках, поэтому на английском, чтобы не создавать путаницу
Но вы же даже дальше сами называете некоторые из них на русском.
Классификация, семантическая сегментация, детекция (локализация) объектов, сегментация объектов.
Это вы неправильно интерпретируете текст статьи.
Даже тут я не понимаю, как можно было сделать те выводы, которые вы сделали. А уж в оригинальных постах такого тем более не найти.
Каждый герой управляется одним отдельным инстансом сети.
я говорил о том, что ботам «помогли» выучить некоторое наперед заданное поведение.
Нет, вы дословно сказали, что «разводка на лайны тоже осуществляется насильно», хотя по факту это просто было добавлено в cost function (как, наверняка, и ещё огромное количество других игровых элементов).
Это написано в разделе про эксплоринг. Нет никакого повода полагать, что это происходит как-то иначе. Но окей, быть может, я понял неверно.
Там написано:
We hardcode item and skill builds (originally written for our scripted baseline), and choose which of the builds to use at random. Courier
Мы хардкодим айтембилды и скиллбилды (это изначально было реализовано в рамках нашего заскриптованного бейзлайна) и случайным образом выбираем, какой из билдов использовать.
В интервью же разработчик говорил, что сейчас это заскриптовано, и они хотят в ближайшее время это устранить. Если бы это использовалось только во время обучения, зачем бы это надо было устранять? Так что как раз таки нет никакого повода полагать, что это происходит именно так, как вы описали.
Если в сеть вносятся какие-то априорные знания о задаче, то это уже ничего не демонстрирует.
Кхм, как бы feature engineering никто не отменял даже для нейросетей.
Это делается для эксплоринга, при тренировке, чтобы боты смогли научиться играть с конкретными осмысленными билдами, а не перебирали их рандомно. Непосредственно в игре, естественно, никаких предопределенных билдов нет.
Пруфы? В блоге написано про рандомный выбор среди заскриптованных билдов. То же самое озвучивал на стриме разработчик из OpenAI и говорил, что это одна из вещей, от которых они хотят избавиться в ближайшее время.
Опять же — это тоже делается только в тренировочных играх, чтобы боты больше наиграли с адекватными расстановками по лайнам и потом повторяли это «закрепленное поведение» уже сами.
Эээ, ну да, во время игры никаких cost function уже нет. Вернитесь к исходному аргументу: вы говорили, что лайнапы захардкожены, и боты по линиям разводятся насильно. Я же просто сказал вам, что это не так, и лейнинг является trainable параметром. Другое дело, что в него вносятся некие priors в виде того, что изначально боты распределяются по линиям, а потом уже решают, надо ли менять это.
Вы постоянно говорите про архитектуру, но основная проблема в том, что архитектура не статична. Нейросеть — это контейнер, аналоговый вычислитель эмулированный на ПК, если грубо.
Вообще-то она как раз статична. Не статичны веса.
Если очень грубо, то полноценный запуск всего цикла енва -> обс -> агент -> акт на каждый кадр это тоже самое, что если бы для вас останавливали время 30 раз в секунду.
Останавливали время 30 раз в секунду… на одну тридцатую секунды. Не забывайте, что ботам надо успеть отреагировать.
даже настолько простой, практически на коленке собранный способен демонстрировать практически неоспоримое преимущество перед людьми
Надеюсь, вы осознаёте, что это не «простой, на коленке собранный ИИ», а state-of-the-art в современном machine learning?
Абуз курьера был не в том, что боты идеально быстро закупались и клали в неё предметы, а в том, что они безостановочно носили пятью курьерами себе предметы на регенерацию, принося их прямо в замесе и тут же восстанавливая себе здоровье и ману.
Во-первых, с одним курьером они бы банально не могли обеспечить себе такую интенсивность принесения предметов (можно обратить внимание, что большую часть времени было задействовано 1-3 курьера сразу). Во-вторых, с уязвимыми курьерами боты бы не смогли так беспечно носить эту регенерацию в моменты столкновения с игроками.
Тут есть еще один немаловажный момент, на реддите в теме про ограничения дообсуждались до того, что использование Bottle по общему времени обучения превышает _все_ что сделали боты до этого в три раза. То есть обучение использовать одну вещь сложнее, чем обучение 5 ботов разнести 6к ммр солянку в рандом драфте.
Это настолько жёсткое преувеличение, что тут даже говорить нечего.
Возможно, даже ограничение на курьеров сложнее, чем на ботл (из-за того, что боты научились весьма неадекватно абузить наличие пяти неуязвимых курьеров).
Так и сборки — тоже не скриптинг, это просто способ показать сети, что «так можно», чтобы она вслепую не тыкалась миллион лет, подбирая осмысленные варианты наугад.
Сборки — это скриптинг. Читайте внимательнее — ботам даётся несколько айтембилдов / скиллбилдов, и они выбирают случайный. ML никаким образом в этом не участвует.
С лайнапами ситуация другая — ботам дают выбранные лайны и включают это в функцию потерь таким образом, чтобы боты меняли линии только тогда, когда это реально выгодно.
Речь просто о том что, получается, боты не на 100% сами все узнают, а получают некоторую внешнюю информацию о том, как играть
«можно собрать такой-то билд по итемам», «можно качать скиллы в таком-то порядке», «можно играть вот такой вот стратегией с расстановкой по лайнам».
Что, вобщем-то, нарушает чистоту эксперимента.
Чем это нарушает чистоту эксперимента? Machine learning — это не про blackbox. Вносить знания о домене в модель — это нормально.
Я надеюсь, вы в курсе, что Git как раз не докачивает диффы, а делает снепшоты файлов?
Как можно привести альтернативный пример, если всё, что вы написали — сплошная вода без каких-либо реальных результатов и метрик?
>Отмазываюсь тем, что наши цели куда выше, чем это
Вы неправильно поняли мой поинт. Вы говорите о предсказаниях для групп товаров, а я говорю о том, что предсказания нужны для каждого товара в отдельности, поскольку как supplies management, так и dynamic pricing в конечном итоге делаются на уровне товаров.
Опять таки, суть замечания была не в этом. Вы говорите о предсказании с большим шагом (например, недельные предсказания, которые вы делали во второй части), а я говорю о предсказании на несколько шагов, которое, опять таки, как раз и нужно ретейлерам. В вашем же примере, если у товара срок годности 5 дней, то вам нужен не прогноз на день вперёд или на неделю вперёд, а, вероятнее всего, daily prediction примерно на пять дней.
Так, может, вам надо было MAPE мерять, а не R^2? Объясните мне, как вы по значению R^2_adj=0.4 сделали вывод о качестве предсказания, если оно практически не интерпретируемо? И даже по MAPE как бы вы делали вывод, если вы не задали себе нужные значения метрик?
Я и не говорил про обучение на тестовой части. Я говорил про тюнинг гиперпараметров, который вы, очевидно, делали на тестовой части, потому что отдельной валидационной у вас просто не было. Простите, что кидаю ссылки на видео из курсов по ML, но объяснять самому у меня плохо получается.
y — цена CERESIT
f1 = x / y
f2 = (x/5) / (y/10) = x*2 / y
f2 = 2*f1
Если вычисления выше верны, то эта фича добавляет ноль новой информации в модель.
Дело в том, что это не экстравагантно, а не вполне корректно. Ещё раз повторю, что бустинг и LSTM — это модели абсолютно разной природы, и с фичами они работают по-разному. То же самое и с отбором фич по скоррелированности продаж, который вы упомянули: полагаться на корреляцию при отборе признаков для таких сложных моделей нельзя.
У вас есть признак
f1 = abs(y)
Корреляция околонулевая, а между тем f1 — идеальный предиктор y.
В выручке и прибыли в сводной таблице, очевидно. У вас выручка в 2016 была на 28% больше, чем за год до этого, а в 2017 (с моделью) — на 13%.
А ведь именно выручка или прибыль в конечном итоге являлась для вас оптимизируемой бизнес-метрикой.
Вы путаете data leakage и overfitting. То, что у вас модель хорошо работает на трейне и отвратительно в продакшене — это симптом оверфита по определению.
Главная проблема этой работы в том, что когда вы создавали модель, вы работали с одним конкретным рядом. Затюнить модель так, чтобы она более-менее хорошо предсказывала спрос на один товар, можно. Но на практике ретейлеру обычно нужно предсказывать спрос сразу на все товары, а вот тут сложные модели типа бустингов и сетей становится куда сложнее настраивать, а также появляется необходимость в более сложном feature engineering (например, нельзя сделать dummy-переменные под конкретные акции, потому что у каждого товара может быть свой набор скидок в разные моменты времени, которые комбинируются произвольным образом, и приходится из этих данных строить какие-то новые, более общие фичи). Кроме того, редко ретейлеру реально нужно предсказывать спрос на день вперёд для менеджмента закупок, да и для оптимизации цен это, наверное, не вполне корректно. Поэтому я, честно говоря, сомневаюсь в том, насколько построенная модель способна принести пользу заказчику в реальной жизни (помимо того, что она в целом демонстрирует практическую жизнеспособность работы с price elasticity с помощью ML-алгоритмов). Также есть несколько более мелких деталей, которые меня смущают:
Почему вы считаете, что так корректно делать? Деревянные модели работают с признаками совсем не так, как сети. Фичи, которые бустингу показались полезными, могут не взлететь в сети, и наоборот. И уж точно фичи, подаваемые на вход бустингу, надо обрабатывать совсем не так, как фичи, подаваемые на вход сети.
Наверное, всё же grid search.
Вообще-то нет, такое значение нельзя интерпретировать подобным образом для временного ряда, и, пожалуй, вообще нельзя говорить, хороший это показатель или плохой, не сравнив с хотя бы какими-то примитивными бейзлайновыми моделями.
Если вы делали это, валидируясь на той же части датасета, которую вы называете тестовой (а судя по графикам и коду, вы это делали), поздравляю — вы оверфитнулись.
Разве вторая фича не получается из первой линейным преобразованием?
С одной стороны, сигмоида на конце — это удобно. С другой стороны, таким образом вы практически лишаете модель возможности экстраполировать, что довольно важно для построения кривой эластичности, не так ли?
Позволю себе не согласиться. Если сравнить даже 2016 и 2015 годы, можно увидеть огромный естественный прирост (очевидно, связанный с тем, что ретейлер работает в плюс и расширяется), так что ваш эксперимент абсолютно не показателен и, вполне вероятно, мог не принести повышения прибыли (во всяком случае, ваши данные этого не подтверждают).
Кроме того, то, насколько сильно ваша модель ошибалась в предсказаниях (намного сильнее, чем на тестовой части датасета), ещё раз свидетельствует о том, о чём я писал выше — настраивая параметры под тестовую часть, вы сильно заоверфитились.
В целом, вроде и хороший пример использования ML в бизнесе, но при этом недочётов столько, что результаты вызывают огромное сомнение.
Можно не давать собственные обозначения. Я же выше привёл общепринятые, в общем-то (кроме разве что instance segmentation, где перевод не особо устоявшийся).
Учёные, занимающиеся машинным обучением, о сильном ИИ как раз и не говорят. О нём разглагольствуют в основном «визионеры» искусственного интеллекта.
Потому что это статьи про слабый искусственный интеллект, которым машинное обучение и является.
Хотелось бы отметить одну вещь насчет терминологии:
Но вы же даже дальше сами называете некоторые из них на русском.
Классификация, семантическая сегментация, детекция (локализация) объектов, сегментация объектов.
Это вы неправильно интерпретируете текст статьи.
Даже тут я не понимаю, как можно было сделать те выводы, которые вы сделали. А уж в оригинальных постах такого тем более не найти.
Каждый герой управляется одним отдельным инстансом сети.
Достаточно просто открыть блогпосты OpenAI.
Интервью, которое было между картами бейзлайн-матча.
Так с тем же успехом можно сказать, что боты вообще скриптованные. Ведь всё их обучение по большому счёту упирается в удачный reward для обучения.
Нет, вы дословно сказали, что «разводка на лайны тоже осуществляется насильно», хотя по факту это просто было добавлено в cost function (как, наверняка, и ещё огромное количество других игровых элементов).
Там написано:
В интервью же разработчик говорил, что сейчас это заскриптовано, и они хотят в ближайшее время это устранить. Если бы это использовалось только во время обучения, зачем бы это надо было устранять? Так что как раз таки нет никакого повода полагать, что это происходит именно так, как вы описали.
Кхм, как бы feature engineering никто не отменял даже для нейросетей.
Пруфы? В блоге написано про рандомный выбор среди заскриптованных билдов. То же самое озвучивал на стриме разработчик из OpenAI и говорил, что это одна из вещей, от которых они хотят избавиться в ближайшее время.
Эээ, ну да, во время игры никаких cost function уже нет. Вернитесь к исходному аргументу: вы говорили, что лайнапы захардкожены, и боты по линиям разводятся насильно. Я же просто сказал вам, что это не так, и лейнинг является trainable параметром. Другое дело, что в него вносятся некие priors в виде того, что изначально боты распределяются по линиям, а потом уже решают, надо ли менять это.
Вообще-то она как раз статична. Не статичны веса.
Останавливали время 30 раз в секунду… на одну тридцатую секунды. Не забывайте, что ботам надо успеть отреагировать.
Надеюсь, вы осознаёте, что это не «простой, на коленке собранный ИИ», а state-of-the-art в современном machine learning?
Во-первых, с одним курьером они бы банально не могли обеспечить себе такую интенсивность принесения предметов (можно обратить внимание, что большую часть времени было задействовано 1-3 курьера сразу). Во-вторых, с уязвимыми курьерами боты бы не смогли так беспечно носить эту регенерацию в моменты столкновения с игроками.
Это настолько жёсткое преувеличение, что тут даже говорить нечего.
Возможно, даже ограничение на курьеров сложнее, чем на ботл (из-за того, что боты научились весьма неадекватно абузить наличие пяти неуязвимых курьеров).
Сборки — это скриптинг. Читайте внимательнее — ботам даётся несколько айтембилдов / скиллбилдов, и они выбирают случайный. ML никаким образом в этом не участвует.
С лайнапами ситуация другая — ботам дают выбранные лайны и включают это в функцию потерь таким образом, чтобы боты меняли линии только тогда, когда это реально выгодно.
Чем это нарушает чистоту эксперимента? Machine learning — это не про blackbox. Вносить знания о домене в модель — это нормально.