Обучение моделей временных рядов: Prophet, NeuralProphet, TimesFM

Обучение Prophet: где ломается прогноз и почему

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

Первое — дыры. Пропущенные сутки, выпавший канал сбора, склейка двух выгрузок: ряд теряет равномерность, и тренд строится по изломанной линии. Обучение Prophet нужно предварять явным правилом приведения к равномерной сетке — что считать нулём, что остановкой, что выбросом. Молчаливая интерполяция прячет проблему до первого прогноза.

Второе — смена режима. Новый тариф, перезапуск промо, изменённый процесс: история до и после описывает разное поведение, а модель усредняет периоды и не попадает ни в один. Точки перелома задают явно, а окно истории ограничивают, чтобы старый режим не тянул тренд назад.

Третье — неразмеченные события. Акция, релиз, сбой, если их не вынести регрессорами или календарём, оседают в остатке и раздувают интервал. Четвёртое — неверный горизонт: длиннее периода, на котором сезонность устойчива, он расширяет интервалы до бесполезных.

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

Что даёт корректная модель: эффект в метриках и отказах

Качество модели видно на ретроспективной проверке по скользящему окну, а не на одной контрольной точке. Модель обучается только на прошлых данных, предсказывает следующий интервал, а ошибка усредняется по MAE, MAPE и SMAPE. Результат сверяем с сезонным наивным прогнозом: если модель его не бьёт, режим сезонности или регрессоры заданы неверно.

Устойчивость к выбросам закладывается на этапе обучения. Праздники, распродажи и разовые сбои описываются отдельными регрессорами, а не вырезаются из истории — тогда всплеск помечается как событие и не тянет за собой базовый тренд. В Prophet чувствительность к точкам изменения тренда задаётся априорно: выше гибкость — быстрее подстройка, но и выше риск поймать шум вместо сигнала.

Горизонт планирования определяет требования к данным. Ошибка растёт с каждым шагом вперёд, поэтому точность прогноза фиксируется отдельно на коротком и на длинном горизонте: для недельного планирования и для квартального нужны разные наборы регрессоров. Практический показатель — доля периодов, закрытых автоматически, когда прогноз попал в доверительный интервал и ручной разбор не потребовался.

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

Обучение Prophet и альтернативы: сравнение подходов

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

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

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

Этапы работы: от аудита ряда до передачи модели

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

1. Аудит и подготовка ряда: проверяем частоту, пропуски, выбросы, смену режимов и календарь праздников. Пропуски закрываем интерполяцией, аномалии не удаляем молча, а помечаем отдельными событиями.
2. Выбор схемы валидации: последний отрезок ряда откладываем и не показываем модели, чтобы оценка была честной. Для сезонных данных горизонт задаём кратным периоду.
3. Подбор параметров модели: перебираем сезонность, тренд, точки изменения и сглаживание на обучающем отрезке, контролируя результат на промежуточном.
4. Обучение: запускаем обучение Prophet на полном подготовленном ряде и сохраняем артефакт вместе с конфигурацией — воспроизводимость важнее одного удачного прогона.
5. Валидация на отложенном периоде: считаем ошибку по горизонтам, смотрим, где модель теряет точность, и возвращаемся к параметрам, если расхождение растёт.
6. Передача модели заказчику: отдаём код, конфигурации, метрики и регламент переобучения, проводим разбор с вашей командой, чтобы запуск не зависел от нас.

Дальше модель живёт в вашем контуре: переобучение по расписанию или по падению точности ниже согласованного порога.

Что передаём на руки: артефакты, конфигурации, регламенты

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

• Конфигурация модели: гиперпараметры, сезонности, список внешних регрессоров, окно валидации и горизонт прогноза — в файле, из которого прогон воспроизводится один в один.
• Схема подготовки данных: как из сырых выгрузок собирается обучающая выборка, как обрабатываются пропуски, выбросы и смена тарифных планов внутри истории.
• Разметка событий: календарь праздников, акций и аварий — чтобы модель не списывала разовый всплеск на сезонность и не тянула его в прогноз.
• Регламент переобучения: периодичность, триггеры по метрике, порядок прогона и обязательная сверка с наивным прогнозом перед выкладкой новой версии.
• Документация модели: входы и выходы, допустимый горизонт, границы применимости, известные слабые места и причины прежних отклонений.
• Мониторинг качества прогноза: метрики на скользящем окне, сравнение с базовой линией, оповещение при выходе ошибки за порог.
• Правила сопровождения и откат: версионирование моделей и данных, порядок возврата на предыдущую версию, если новая ведёт себя хуже.

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

Кейс: как сократили ошибку прогноза на реальном ряде

Планировали недельный спрос на ряде с двумя сезонными пиками и рваным графиком промо. Базовая модель сглаживала праздничные всплески: перенос выходных и предпраздничные отгрузки уходили в остаток, а ошибка накапливалась к концу квартала. Доля периодов, где промах превышал допустимый порог, доходила до 38%, а планировщики правили прогноз вручную около 60 раз за цикл — это два дня работы на каждый пересчёт.

Что изменили

Праздники и переносы выходных вынесли в отдельные признаки-регрессоры, вместо одной годовой кривой оставили недельную и годовую сезонность, а промо-всплески — во внешних факторах. Основной моделью обучили Prophet, для рядов с сильной зависимостью от прошлых значений — NeuralProphet, а на холодном старте, где истории мало, брали быстрый ориентир от TimesFM. Качество мерили скользящей кросс-валидацией по сезонным срезам, а не по одному последнему месяцу.

Что получили

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

Оставшиеся 11% — в основном разовые акции, которых не было в истории; их ведём отдельным списком исключений, который планировщик подтверждает руками. Регламент переобучения — раз в месяц плюс внеплановый запуск при смене ассортимента.

Технические сомнения: пропуски, режимы, дообучение

Перед пилотом по обучению Prophet инженерные сомнения обычно одни и те же: сколько истории подавать на вход, что делать с пропусками, как размечать события и можно ли обновлять модель без полной пересборки. Ниже — короткие ответы на каждое.

Что делать с пропусками в данных?

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

Как размечать календарные события?

Праздники, промо, релизы и аварии подаём отдельными регрессорами, а не прячем внутрь сезонности — иначе разовый скачок размазывается по всему году. Разметка хранится таблицей дат и весов и правится без изменения кода.

Можно ли дообучить модель без полной пересборки?

Да: Prophet принимает новые точки к уже обученной модели, NeuralProphet продолжает обучение с текущих весов. Полный пересбор запускаем при смене режима ряда — изменилась структура сезонности, появился крупный новый регрессор или данные ушли в другой масштаб. Решение фиксируется метриками на отложенном участке, а не на глаз.

Обсудим вашу задачу: присылайте ряд и требования

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

• Ряд в машиночитаемом виде — CSV или Parquet, метка времени с часовым поясом, фиксированный шаг, явно помеченные пропуски и простои. Пустое значение и ноль — не одно и то же.
• Глубина истории — минимум два-три полных сезонных цикла. Для недельной и годовой сезонности это разные горизонты, и они определяют, что вообще можно выучить.
• Горизонт и частота прогноза — на сколько шагов вперёд, как часто пересчитываем, нужен ли один срез или распределение с квантилями.
• Внешние факторы — календарь и праздники, акции, погода, ремонты. Ключевое: что известно на момент прогноза, а что появляется только постфактум.
• События, ломающие ряд — сбои, переезды учёта, смена методики. Их стоит отметить: часть выбросов вырезаем, часть оставляем как сигнал.
• Критерий приёмки — метрика (симметричная ошибка, ошибка на квантиле) и порог, при котором модель считаем рабочей, плюс правило поведения при его выходе.
• Как прогноз встраивается в ваш контур — пересчёт по расписанию или расчёт по запросу, куда отдаём результат и с какой задержкой.

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

Что делать, если ряд уже прогнозируется другим инструментом

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

Отдельно переносим всё, что модель знает помимо самого ряда: календарь праздников и переносов, промо-периоды, регрессоры, правила обработки пропусков и выбросов. Если перенести только колонку значений, новая схема проиграет — но не из-за алгоритма, а из-за потерянных признаков и разной предобработки.

Компромиссный путь — вести две модели параллельно: текущая остаётся рабочей, новая считается в теневом режиме и не влияет на решения. Через несколько циклов прогнозирования сравниваем ошибку по горизонтам и по группам рядов, смотрим, где расхождение системное, а где шум. Так переход опирается на накопленную статистику, а не на единственный удачный прогон.

Контур переключения оставляем обратимым: текущее решение сохраняется целиком, выбор модели задаётся настройкой, а не правкой кода. Это позволяет откатиться за один шаг, если качество на живых данных окажется хуже. Если у вас уже работает Prophet или собственный расчёт — опишите, какие признаки и горизонты важны, и мы вернёмся с планом перехода и оценкой сроков.