Навчання моделей часових рядів: 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 або власний розрахунок — опишіть, які ознаки й горизонти важливі, і ми повернемося з планом переходу й оцінкою строків.