В этом посте описываются различные проблемы, которые обычно возникают при сравнении двух прогнозов с фактическими результатами. И расскажет о типе сложности, связанной с этим, и о том, насколько сложно может быть придумать единую метрику или число для сравнения двух прогнозов за период.

Рассмотрим гипотетическую ситуацию в вашей организации: вам нужно каждый день прогнозировать снятие наличных в банкомате, чтобы в зависимости от спроса и наличия наличных вы могли запланировать поездку и заполнить этот банкомат, чтобы избежать обналичивания.

Это общая проблема, с которой сталкивается каждый банк, и у каждого есть свое решение. Но ваша организация использует проприетарное решение какой-то компании, которое взимает X долларов в год в качестве лицензионных сборов, что слишком много для этого продукта.

Чтобы избежать больших затрат и зависимости этого продукта, компания решила заменить эту систему и хочет использовать инструменты или библиотеки с открытым исходным кодом.

Все идет нормально.

Вы начали разработку решения для всех банкоматов, используя библиотеки и инструменты с открытым исходным кодом. А через некоторое время вы разработали решение, которое хорошо масштабируется в распределенной среде и дает прогноз.

Теперь пришло время сравнить прогноз с фактическим, а также с существующими решениями, скажем, с данными за месяц. Это некоторые моменты, которые необходимо учитывать

  1. По какой метрике вы будете сравнивать результаты? будет ли это RMSE (среднеквадратичная ошибка), MAE (средняя абсолютная ошибка) или MAPE (средняя абсолютная ошибка в процентах).
  2. Теперь в течение нескольких дней ваша модель с открытым исходным кодом будет давать хорошие результаты с точки зрения метрики, которую вы, возможно, выбрали, но в то же время существующее решение будет давать лучшие результаты в течение нескольких дней. Как вместе вы можете сказать, какой из них лучше?
  3. Чтобы проверить надежность модели, сравните результаты особых мероприятий модели сына, таких как государственные праздники, новый год, государственные праздники США, Дивали, Рождество и т. Д., Потому что в эти дни обычно наблюдаются аномальные закономерности, и это хороший шанс увидеть, как вы модель ведет себя в этих экстремальных условиях.
  4. Можете ли вы разделить дни на пиковые дни, т.е. когда ваша проблема сильно влияет на рабочие и непиковые дни, и проверить производительность модели?
  5. Сколько недооцененных и сколько дополнительных прогнозов существует для каждой модели? Допустимы ли для бизнеса сверх прогнозы, а для вашей проблемы - отклонения от прогнозов?
  6. Если заниженное предсказание / завышенное предсказание приемлемо, то на какую величину?
  7. Как насчет случая, когда из-за одного или двух очень высокого или очень низкого прогноза метрика за весь месяц (например, MAPE) становится очень высокой, но если вы удалите эти выбросы из сравнений, прогноз будет близок к фактическому.

Предположим, вы дадите ответы на все вышеперечисленные вопросы, тогда как придумать одну метрику, которая объединяет все вышеперечисленные пункты?

Помните, что мы говорим это только для 1 банкомата. А как насчет того, что однажды мы рассмотрим, скажем, тысячи машин? А как насчет разных номиналов, таких как 5, 10 и 100 долларов, которые может иметь автомат.

Считайте себя деловым человеком, у которого есть полномочия принимать решение о выводе из эксплуатации существующего решения и начале использования разработанного вами решения. Прежде чем принимать какое-либо решение, вы хотите проверить, как новое решение в целом ведет себя по сравнению с фактическим и существующим решением, поскольку это связано с очень высоким риском, если вы принимаете решение без учета всех этих факторов.

Таким образом, суть здесь в том, что в этом типе сценария необходимо учитывать все эти типы вопросов, и очень трудно сказать о качестве прогноза, учитывая лишь некоторые из вышеперечисленных моментов. Но, опять же, становится еще труднее, когда вы начинаете учитывать все моменты, которые можно сказать о качестве прогноза.