В этом посте описываются различные проблемы, которые обычно возникают при сравнении двух прогнозов с фактическими результатами. И расскажет о типе сложности, связанной с этим, и о том, насколько сложно может быть придумать единую метрику или число для сравнения двух прогнозов за период.
Рассмотрим гипотетическую ситуацию в вашей организации: вам нужно каждый день прогнозировать снятие наличных в банкомате, чтобы в зависимости от спроса и наличия наличных вы могли запланировать поездку и заполнить этот банкомат, чтобы избежать обналичивания.
Это общая проблема, с которой сталкивается каждый банк, и у каждого есть свое решение. Но ваша организация использует проприетарное решение какой-то компании, которое взимает X долларов в год в качестве лицензионных сборов, что слишком много для этого продукта.
Чтобы избежать больших затрат и зависимости этого продукта, компания решила заменить эту систему и хочет использовать инструменты или библиотеки с открытым исходным кодом.
Все идет нормально.
Вы начали разработку решения для всех банкоматов, используя библиотеки и инструменты с открытым исходным кодом. А через некоторое время вы разработали решение, которое хорошо масштабируется в распределенной среде и дает прогноз.
Теперь пришло время сравнить прогноз с фактическим, а также с существующими решениями, скажем, с данными за месяц. Это некоторые моменты, которые необходимо учитывать
- По какой метрике вы будете сравнивать результаты? будет ли это RMSE (среднеквадратичная ошибка), MAE (средняя абсолютная ошибка) или MAPE (средняя абсолютная ошибка в процентах).
- Теперь в течение нескольких дней ваша модель с открытым исходным кодом будет давать хорошие результаты с точки зрения метрики, которую вы, возможно, выбрали, но в то же время существующее решение будет давать лучшие результаты в течение нескольких дней. Как вместе вы можете сказать, какой из них лучше?
- Чтобы проверить надежность модели, сравните результаты особых мероприятий модели сына, таких как государственные праздники, новый год, государственные праздники США, Дивали, Рождество и т. Д., Потому что в эти дни обычно наблюдаются аномальные закономерности, и это хороший шанс увидеть, как вы модель ведет себя в этих экстремальных условиях.
- Можете ли вы разделить дни на пиковые дни, т.е. когда ваша проблема сильно влияет на рабочие и непиковые дни, и проверить производительность модели?
- Сколько недооцененных и сколько дополнительных прогнозов существует для каждой модели? Допустимы ли для бизнеса сверх прогнозы, а для вашей проблемы - отклонения от прогнозов?
- Если заниженное предсказание / завышенное предсказание приемлемо, то на какую величину?
- Как насчет случая, когда из-за одного или двух очень высокого или очень низкого прогноза метрика за весь месяц (например, MAPE) становится очень высокой, но если вы удалите эти выбросы из сравнений, прогноз будет близок к фактическому.
Предположим, вы дадите ответы на все вышеперечисленные вопросы, тогда как придумать одну метрику, которая объединяет все вышеперечисленные пункты?
Помните, что мы говорим это только для 1 банкомата. А как насчет того, что однажды мы рассмотрим, скажем, тысячи машин? А как насчет разных номиналов, таких как 5, 10 и 100 долларов, которые может иметь автомат.
Считайте себя деловым человеком, у которого есть полномочия принимать решение о выводе из эксплуатации существующего решения и начале использования разработанного вами решения. Прежде чем принимать какое-либо решение, вы хотите проверить, как новое решение в целом ведет себя по сравнению с фактическим и существующим решением, поскольку это связано с очень высоким риском, если вы принимаете решение без учета всех этих факторов.
Таким образом, суть здесь в том, что в этом типе сценария необходимо учитывать все эти типы вопросов, и очень трудно сказать о качестве прогноза, учитывая лишь некоторые из вышеперечисленных моментов. Но, опять же, становится еще труднее, когда вы начинаете учитывать все моменты, которые можно сказать о качестве прогноза.