LLM не корисні для прогнозування часових рядів: що означає NeurIPS 2024 для ШІ у фінансах

Ця стаття з'явилася у моєму списку для читання, оскільки вона прямо ставить під сумнів хвилю робіт із прогнозування часових рядів на основі LLM за 2023–2024 роки. Оскільки Bean Labs розглядає можливість прогнозування залишків на рахунках та грошових потоків з реєстрів Beancount, питання про те, чи використовувати універсальні LLM, чи спеціалізовані числові моделі, не є суто академічним. Результат доповіді Spotlight на NeurIPS 2024 від Тана та співавторів — це наче холодний душ.

Про статтю

Стаття «Чи справді мовні моделі корисні для прогнозування часових рядів?» (Are Language Models Actually Useful for Time Series Forecasting?) Міньтяня Тана, Майка Меррілла, Вінаяка Гупти, Тіма Альтхоффа та Томаса Хартвігсена (arXiv:2406.16964, NeurIPS 2024 Spotlight) аналізує три популярні методи прогнозування на основі LLM: OneFitsAll (GPT-2 із замороженою увагою та патчінгом), Time-LLM (LLaMA з перепрограмуванням патчів) та CALF (GPT-2 з адаптерами LoRA та крос-модальним узгодженням). Питання полягає в тому, чи погіршує продуктивність видалення або заміна компонента LLM. У 13 тестах відповідь майже завжди «ні» — і часто версії без LLM працюють краще.

Ключові ідеї

• Версії без LLM перевершують Time-LLM у 26 з 26 випадків за метриками на 13 наборах даних, CALF — у 22 з 26, а OneFitsAll — у 19 з 26. LLM частіше заважає, ніж допомагає.
• Time-LLM має 6642 млн параметрів і потребує 3003 хвилини для навчання на наборі даних Weather; версія без LLM (тільки механізм уваги) з 0,245 млн параметрів навчається за 2,17 хвилини — це приблизно в 1383 рази швидше при такій самій або кращій точності.
• Випадково ініціалізовані LLM перевершують попередньо навчені у 8 з 11 порівнянь наборів даних, що означає, що ваги, навчені на текстах, загалом негативно впливають на результат.
• В умовах навчання на кількох прикладах (few-shot, 10% даних), Time-LLM та версія без LLM виграють у 8 з 16 випадків кожна — статистично вони не відрізняються, що спростовує аргумент про few-shot можливості як причину використання LLM.
• Перемішування всієї послідовності часових рядів однаково погіршує результати як моделей на основі LLM, так і моделей лише з механізмом уваги. Це свідчить про те, що жодна з архітектур не вловлює надійно послідовну часову структуру.
• Простий базовий рівень PAttn (патчінг плюс один шар механізму уваги) відповідає результатам повноцінних методів LLM на різних наборах даних, при цьому вартість виводу (inference) на порядки нижча.

Що підтверджується, а що ні

Дизайн абляційного дослідження є ґрунтовним: автори замінюють лише компонент LLM, залишаючи все інше (патчінг, нормалізацію, «голови» моделі) незмінним, тому порівняння є чистим. Код відкритий. Проти факту щодо обчислень — прискорення в 1383 рази без втрати точності — важко щось заперечити для будь-якого реального сценарію використання.

Стаття залишає відкритим питання, чому LLM не допомагають. Експеримент із перемішуванням показує, що моделі не можуть відрізнити впорядковані в часі серії від перемішаних — але ця проблема характерна і для абляцій, а не тільки для LLM. Невдача може бути глибшою властивістю того, як трансформери на основі патчів обробляють часові ряди, а не специфічним недоліком мовних моделей. Автори натякають на це, але не досліджують детально.

Обсяг дослідження також обмежений. Усі три методи використовують заморожені або злегка адаптовані LLM 2022–2023 років (GPT-2, LLaMA-7B). Моделі, спеціально створені для часових рядів — Chronos, TimesFM — по-іншому токенізують числові дані і не були розглянуті. Скептик може обґрунтовано стверджувати, що критика стосується конкретного шаблону проєктування (адаптація архітектур NLP без змін), а не LLM для числових даних загалом.

Чому це важливо для фінансового ШІ

Для завдань прогнозування Beancount — передбачення балансу на наступний місяць, оцінка річних податкових зобов'язань, виявлення розривів у грошових потоках — ця стаття рішуче схиляє до використання легких спеціалізованих числових моделей. Розрив в обчисленнях не є теоретичним: агент, що виконує прогнози на основі особистого реєстру, не може дозволити собі накладні витрати на вивід Time-LLM.

Є й більш серйозний висновок. Результати щодо послідовної структури свідчать про те, що будь-який агент, який сприймає записи реєстру як токени та очікує від моделі розуміння часового порядку лише з контексту, стоїть на хиткому ґрунті. Якщо модель не відрізняє перемішані дані від впорядкованих, зіставлення часових паттернів потрібно розробляти явно — через позиційне кодування, розкладання на тренд та сезонність або спеціалізовану архітектуру — а не сподіватися, що це з'явиться саме собою завдяки попередньому навчанню.

Але є ризик надмірного узагальнення. Критика Тана та ін. стосується саме чисельної екстраполяції. LLM все ще приносять реальну користь, коли завдання пов'язане з природною мовою — пояснення аномалій, відповіді на запитання типу «чому мої витрати на продукти зросли в березні», аудит описових приміток у реєстрі. Помилкою було б ототожнювати твердження «LLM не можуть екстраполювати часові ряди» з «LLM не можуть міркувати про фінанси». Це різні речі, і Bean Labs потребує обох цих можливостей.

Що почитати далі

• TimesFM: «A decoder-only foundation model for time-series forecasting» (Das et al., ICML 2024, arXiv:2310.10688) — модель від Google на 200 млн параметрів, попередньо навчена на 100 млрд реальних часових точок; створена спеціально для прогнозування, а не адаптована з NLP, що є прямою перевіркою того, чи проблема в LLM, чи в шаблоні адаптації.
• Chronos: «Learning the Language of Time Series» (Ansari et al., TMLR 2024, arXiv:2403.07815) — підхід Amazon до токенізації числових значень у дискретний словник та навчання моделей на основі T5 з нуля на часових рядах; за духом ближче до PatchTST, ніж до прогнозистів на базі GPT, і досягає сильних zero-shot результатів у 42 тестах.
• PatchTST: «A Time Series is Worth 64 Words» (Nie et al., ICLR 2023, arXiv:2211.14730) — дизайн із патчінгом та незалежністю каналів, який лежить в основі більшості оболонок LLM, проаналізованих у цій статті; розуміння цього проєкту допомагає з'ясувати, який саме компонент виконує основну роботу в OneFitsAll та Time-LLM.