Комментарии 23
Как ни обучай модели, они все равно прогнозируют по принципу "завтра будет так как сегодня или вчера". Это все равно полезно, но можно ли, например, предсказать "черный вторник"?
Нельзя предсказывать хвосты распределений. Нет такой математики. Хвосты обычно оцениваются через призму рисковых моделей.
Не очень понял Ваш коммент. Хвост распределения - это ближайшее прошлое или ближайшее будущее (раз его можно или нельзя предсказывать)? А математика есть любая. Вопрос - в надежности предсказания.
Хвост распределения — это не будущее или прошлое, а редкие события, например вероятность цунами, землетрясения или извержения вулкана. Вот тут «завтра будет как вчера» вообще не работает, т.к. на кануне события тоже будет «как вчера». И математики, которая может сказать, что завтра вероятность такого события больше чем сегодня и чем послезавтра банально нет и не предвидится.
Сезонность тоже неплохо прогнозируется. То бишь, не только "как сегодня или вчера", но и с учетом, как было в этом периоде в прошлые годы.
Риски же прогнозируются через их математическое ожидание.
Сезонность "спрогнозировать" просто - зимой холоднее, чем летом, днем теплее, чем ночью, люди больше работают днем, чем ночью (с поправкой на временной пояс), поэтому днем больше транзакций и т.п. И скорее всего, так и будет повторяться, с точность до форс-мажора.
А вот насчет мат ожидания риска можно поподробней? Хотя бы в осях. Как известно, мат ожидания может просто не быть, если соответствующий интеграл расходится.
Хотя по Вашим ответам на комменты вижу, что скорее это - не Ваша тема. У Вас, скорее, обеспечение тех поддержки (в широком смысле).
Так сезонность пропускной способности участков железных дорог Вы не спрогнозируете. Где то выше загрузка летом, где-то - зимой. Ремонты на Кубани начинают уже в марте, а на БАМ - с июня.
Мат. ожидание рассчитывается при кластеризации событий. Модели обучаются не всеми фактам, а только признанными "нормальным" на основании ряда аналитик. "Ненормальные" - разбиваются на кластеры. На основании количества "нормальных" и "ненормальных" событий уже несложно посчитать мат. ожидание того, в какой кластер попадет событие.
Подробней описать не могу, так как получится уже совсем другая тема и объем намного больший этой статьи. Только методика прогнозирования, без уточнения алгоритмов, листов на 100.
Наверное, все-таки не мат ожидание, а распределение вероятностей? В смысле с какой вероятностью будет попадание в какой кластер.
Так было бы, если бы кластеризация была в разрезе тех же аналитик, по которым формируются разные временные серии. Но это далеко не так.
В рамках теории нечетких множеств сумма функций принадлежности вроде может быть больше 1 (а также меньше). Но боюсь, что Вы опять скажате, что это не то. Тогда интересно было бы получить ссылку на пример.
В моем случае риски планируется через подачу излишка порожняка на станции и количество вагонов в предварительных заявках операторам. То есть, мне надо посчитать сколько порожняка нужно иметь доступным для подачи и когда. Отсюда и математическое ожидание.
Интересно, но как-то не очень понятно изложено. Я правильно понял, что у вас есть 2*10^6 временны'х рядов (какой длины - не понял) и вы для каждого ряда строите несколько моделей, выбираете из них лучшую и потом делаете прогноз на 8 недель? Ну и какой метод (ARIMA или что-то еще) показывает себя лучше? Правильно я понял, что ряды независимы, так что с распараллеливанием никаких принципиальных проблем нет? Технические детали реализации, честно говоря, не очень интересны, т.к. воспроизводить такие вычисления вряд ли кто-то тут станет.
свыше двух с половиной миллионов прогнозов вычисляются
Эти два миллиона надо еще умножить на число методов, вероятно?
Так цель статьи была не рассказать о самом прогнозировании по миллионам временных серий, а показать, как особенности PostgreSQL позволяют решать эту задачу существенно эффективней и дешевле, чем средства MS SQL или даже Spark (терабайты по сети гонять медленней, чем в оперативке).
Да, для каждого из 2.5 миллионов временных рядов выполняется прогнозирование на 2-8 недель (параметризируемо). Собственно говоря именно из-за обилия параметров, влияющих на количество временных серий и фильтрацию фактов, и не получилось просто дообучать модели свежими данными.
Ну и какой метод (ARIMA или что-то еще) показывает себя лучше?
Зависит от временного ряда. На длинных временных рядах в лидерах ARIMA и нейронная сеть, примерно поровну. На средних - явно лидирует ARIMA. На коротких - ARIMA начинает иногда проигрывать уже ETS (экспоненциальному сглаживанию), HW (модель Хольта-Винтера) или даже простейшим методам (медиане, среднему между 0.25. и 0.75 перцентилем, наивному прогнозу между 0.25. и 0.75 перцентилем).
Эти два миллиона надо еще умножить на число методов, вероятно?
Почти. Еще плюс два-четыре. Сначала фильтром Калмана заполняются пропуски, что уже требует обучения ARIMA. Затем делается прогноз без учета факта за последние N недель (где N - требуемое количество недель прогноза). Выполняется вычисление прогноза по каждой модели и сверяется с фактом за эти N недель. После чего уже выигравшая модель обучается по полной временной серии. Если результат прогноза вышел за пределы 0.05 и 0.95 перцентиля, то прогноз бракуется и обучается всей временной серией уже следующая по качеству кроссвалидации модель.В редких случаях, возможен аналогичный переход уже к третьей по очереди модели. Глубже не видел.
В планах увеличить глубину кроссвалидации для оценки сезонности. Тогда количество расчетов существенно возрастет.
Спасибо за ответ, очень интересно. Почитал также другие ветки, стало еще интереснее. "Модели обучаются не всеми фактам, а только признанными нормальным" - т.е. вы сначала как-то отделяете сигнал от шума и исключаете outliers, так? Согласен с другим комментатором, что распределение вероятностей было бы более информативным, чем мат.ожидание, особенно если вам надо создавать резерв ресурсов (вагонов) с заданной наперед вероятностью, что ресурсов хватит. Я, конечно, не знаю достоверно, но предполагаю, что тут запросто может быть распределение с "черными лебедями".
как-то отделяете сигнал от шума и исключаете outliers, так?
Не совсем так. У меня же на входе результат трекинга вагонов не только с временем и их местоположением, но и с множеством других аналитик. Например, если вагон выехал из пункта А в пункт Б и посередине в пункте С была операция бросания, отцепа или перевода в неисправный парк, то я и без математических методов могу забраковать все события с этим вагоном до отправления с пункта С после бросания или отцепа. Хотя, конечно, это не отменяет выявления нештатной ситуации с вагоном просто по его длительной задержке на промежуточной станции.
распределение вероятностей было бы более информативным, чем мат.ожидание, особенно если вам надо создавать резерв ресурсов (вагонов) с заданной наперед вероятностью
Распределение вероятностей, естественно, тоже есть, так как на его основе считается мат. ожидание - насколько выгодно заключать конкретный контракт. Резерв порожняка - тоже деньги. Бизнес волнует рентабельность. Для ряда грузоотправителей по условиям договора и ПСДЦ может оказаться нерентабельным вообще резерв порожняка иметь. Выгодней оформить накладные на подачу только после того, как что-то случилось.
МГУА не пробовали?
Добрый день
У Питона тоже есть автоарима, но скорость расчетов существенно выше (по крайней мере была в 2020-2021, как сейчас - уже не скажу) с разницей примерно +- минута против 1-2 сек у R на 1 ts. Кстати, реализованы алгоритмы по разному, потому как Арима питона, хоть и дольше по времени но скор показывала ощутимо выше чем арима на R
Про prophet кстати упоминания не увидел. Его частенько ставят в пару к ариме - для выбора лучшей модельки
Еще вопрос про масштабируемость и 100500 моделек, подскажите, вариант с "запихнуть все в df и скормить бустингам" наверняка же рассматривали. Подскажите - почему решили, в итоге, в пользу описанного в статье варианта?
У Питона
У Python в PostgrSQL, к сожалению, до сих пор есть неустранимый недостаток - он не может быть безопасным (не иметь прав доступа ни к чему на сервере), как R. Поэтому использовать хранимые процедуры на Python для продуктивного сервера PostgreSQL пока слишком рискованно.
Про prophet кстати упоминания не увидел. Его частенько ставят в пару к ариме - для выбора лучшей модельки
Так auto.arima, и есть обертка над arima, выбирающая лучшую модель с учетом заданных ограничений.
запихнуть все
Как только начинается "запихнуть", то это сразу переливание терабайтов по сети, о чем я писал. Вся прелесть решения как раз в том, что если данные и копируются, то только в оперативке одного сервера.
Публикации
Как обучить миллионы моделей прогнозирования временными сериями