Плоские прогнозы
Статистическое прогнозирование — это контринтуитивная наука. Это уже говорилось ранее, но мы собираемся ещё раз подчеркнуть этот момент.
Часто к нам обращаются за поддержкой, потому что только что загрузили данные в Lokad, и полученные прогнозы оказываются плоскими. Другими словами, прогнозируемые значения постоянны для всех будущих периодов. Например: постоянные значения продаж на ближайшие 6 месяцев, если речь идет о прогнозах ежемесячных продаж на 6 месяцев вперёд.
Очевидно, что бизнес-продажи в течение следующих 6 месяцев не могут быть абсолютно плоскими, так почему же Lokad продолжает выдавать такие бессмысленные результаты?
Ну, мы точно знаем, что бизнес изменится (хоть немного) в течение следующих шести месяцев. В этом нет сомнений. Однако проблема в том, как можно составить прогноз, максимально приближенный к этим будущим изменениям? Если мы идем по статистическому пути, нам понадобится статистическая модель для прогнозов.
Проблема в том, что нам нужна хорошая модель прогнозирования; и фундаментальное правило статистического прогнозирования гласит, что чем сложнее модель, тем больше данных необходимо для обеспечения ее надежности. Модели, выдающие разные прогнозы для каждого шага вперед, однозначно сложнее, чем те, что выдают одно и то же значение для всех шагов.
С другой стороны, можно сказать, что более сложные модели также менее надежны при использовании ограниченных наборов данных, что означает, что их применение, скорее всего, приведет к снижению общей точности прогнозирования в определенных ситуациях.
Возвращаясь к ситуации, когда люди жалуются на плоские прогнозы, обычно происходит следующее: данные, только что загруженные, либо очень короткие (например, всего 3 месяца ежемесячной истории), либо очень разреженные (например, в eCommerce, где для каждого продукта всего несколько продаж). В таких случаях Lokad часто выдает плоские прогнозы.
Это не баг, это функция повышения точности.
Комментарии читателей (6)
Привет, Йохан, эффективное представление временных рядов в реляционных базах данных — дело довольно сложное. Короче говоря, всё сильно зависит от длины рассматриваемых временных рядов. Поэтому я сомневаюсь, что в этой области существует что-то близкое к «отраслевому стандарту». С другой стороны, для исходного кода всё очень зависит от длины и количества рассматриваемых временных рядов. Надеюсь, это поможет.
Joannes Vermorel (7 лет назад)
Мы работаем над проектом, связанным с временными рядами, с типичным определением временного ряда и наблюдениями. Можете ли вы помочь с следующим:
- Существует ли у вас структура, соответствующая отраслевому стандарту, для определения временных рядов и соответствующих наблюдений с точки зрения дизайна БД.
- Какова будет лучшая практика в отношении кода, представляющего временной ряд, например, [Level 1].[Level 2].[Номер последовательности].[Версия].
Любые рекомендации и помощь будут оценены.
Johan Strydom (7 лет назад)
Привет, Изи, это интересная идея :-) Я думал о подобном «нападении» с самого начала, хотя на нашем сайте об этом не так раскричено. По сути, для этого вам нужно очень точно знать данные, которые ваш объект отправляет в Lokad. Затем вам также необходимо точно знать тип корреляций, на который мы обращаем внимание. Простые сдвиги временных рядов не являются «естественными» в реальных бизнес-данных. Наконец, это обойдется вам в деньги, так как мы не доверяем данным от неплательщиков. Что касается наших техник, мы используем сложную смесь различных моделей, среди которых есть и известные классические. Эта тема, безусловно, немного чувствительна для нас, но я постараюсь позже опубликовать не слишком подробный обзор. Следует отметить, что она еще находится в стремительном развитии.
Joannes Vermorel (9 лет назад)
Так если я загружу неверные данные, тщательно разработанные для корреляции с поставщиком/партнером, который, как я знаю, использует ваш продукт, я смогу испортить его результаты? Это интересно, и, кажется, сделать это довольно просто! Было бы неплохо узнать больше о техниках, которые вы используете (например, ARIMA, ANN и т.д.).
9 лет назад
Привет, Стивен, Хорошая точка зрения. Основная проблема здесь в том, что пользователь может захотеть не только сами прогнозы, но и обоснование их, или, по крайней мере, комментарий. В будущем мы, вероятно, постараемся улучшить клиентские приложения Lokad с автоматическими рекомендациями, которые будут «комментировать» прогнозы, предоставляемые Lokad.
Joannes Vermorel (9 лет назад)
Привет, Joannes, Как вы думаете, является ли это полезной обратной связью от пользователя с точки зрения описания того, что ожидает пользователь? Возможно, можно было бы ограничить возможность выполнения задачи прогнозирования на несколько месяцев, скажем, на 3, и если данных больше, им давали бы предупреждение о влиянии на точность прогноза. Думаю, это также может зависеть от доступности исторических данных, так что, возможно, найдется способ соотнести их, не уверен. Также, с точки зрения пользователей, даже если технически правильнее вернуть им плоские прогнозы, их можно каким-то образом уведомить об этом случае и/или дать возможность принять их или согласиться на более упрощенный результат?
Stephen (9 лет назад)