Специализация всё ещё ключевой фактор точности прогноза?

Всем привет! Меня зовут Андрей Бугаенко,  и в этой статье я расскажу, почему мы в Московской бирже считаем, что AutoML-подход, основанный на интеллектуальном выборе моделей и признаков (на примере MOEX_AutoML), эффективнее современных LLM в задачах численного прогнозирования.

Актуальной задачей любой компании является прогнозирование бизнес-метрик. Прогнозирование используется для различных финансовых задач, в том числе, например, для бизнес-планирования или финансовой аналитической отчетности.  Эмпирические данные и практика ранее всегда показывали непосредственное превосходство специализированных ML-моделей над любыми LLM (Large Language Models) при решении задач прогнозирования количественных показателей. Но за последнее время были выпущены ChatGPT-5, Claude Sonnet 4, GLM 4.5, GROK-4, Gemmini 2.5 Pro и, возможно современные LLM уже превзошли качество прогнозирования ML-моделями, полученными, например, с помощью ML. 

Правда у LLM есть определённые архитектурные ограничения в обработке числовых данных. Ведь превосходство определялось не только фундаментальными различиями в архитектурных подходах, а в первую очередь, тем, что у ML (и как результатов работы AutoML) веса целевым видом оптимизированы под конкретные метрики качества прогноза — такие, как RMSE, MAE, MAPE и т.д. На каждом этапе AutoML-конвейера — от первичного выбора типа модели до фичеселекшена и финальной тонкой настройки гиперпараметров — методы целенаправленно формируют аппроксимационную функцию, строго ориентированную на минимизацию целевой бизнес-ошибки, именно той, которую мы выбрали для решаемой задачи.

В противоположность этому, языковые модели, даже в своих наиболее совершенных реализациях и даже в специализированных формах, остаются инструментами универсального класса, изначально спроектированными для генерации и семантического анализа текстовой информации. Обращаю внимание! Не числовой, а именно текстовой. При работе с числовыми рядами они становятся заложниками базовых принципов своей архитектуры, которая для работы с числами изначально не предназначена. И главная (а кто-то считает, что и единственная) такая причина – это токенизация числовых данных, т.е. разбиение непрерывных числовых последовательностей на дискретные токены, которые разрушает их математическую целостность и внутренние структурные взаимосвязи. То есть LLM в своём “цифровом мозге” не понимает понятие цифры, а воспринимает её как токен.

Оттуда же вытекает проблема дискретного представления. Короче, токенизация не способна адекватно отразить непрерывность, шкалирование и относительное расстояние между значениями, присущие количественным данным. Семантическое расстояние между токенами "100" и "101" в LLM часто оказывается больше, чем, например, между "100" и "999", что противоречит математической реальности.

Ну и ещё беда с потерей математических отношений. Тут проблема в том, что модель утрачивает способность к корректному восприятию и использованию фундаментальных математических операций и отношений между числовыми значениями. То есть LLM может выкатить вам гениальную аналитику, но накосячить в элементарном “2*2=4”.

А давайте мы более правильно напишем промт, засунем много чего в RAG и ИИ (LLM) начнёт у нас гениально считать)))

Если простыми словами, то так оно не летает и не взлетит. Попытки адаптации, такие как оптимизация промптов или изменение форматов представления числовых данных (например, бинирование, строковое представление с разделителями), не устраняют базовую несовместимость парадигм. LLM продолжают оперировать символами, а точнее их токенами (контекстными ассоциациями) в рамках дискретного семантического пространства, а не в континууме математических значений. Как мы не будем стараться переписывать промт, LLM не перестанет воспринимать число как токен. С подключением RAG (Retrieval-Augmented Generation) та же история, он способен лишь расширить информационный контекст, доступный модели, добавить информации, но он не решает фундаментальной проблемы архитектурной неадекватности LLM для числовой обработки. Механизм внутреннего представления и преобразования данных в LLM остается неизменным, следовательно, числовые последовательности не приобретают естественную математическую структуру на уровне модели. Запихни мы хоть сотни петабайтов контекста в RAG, это ничего не изменит.  Но, даже если мы заморочимся и зафайнтюним (читать: используем продвинутые техники пост-обучения (fine-tuning) ?), например LoRA, FullFT, AdapterT, то всё равно этого окажется недостаточно для эффективного устранения разрыва между задачами свободной текстовой генерации и точного численного прогнозирования, требующего строгой оптимизации под метрики ошибок.

Однако, существуют специализированные LLM для прогнозирования. Возможно, это выход?

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

TimeGPT (Nixtla): Проприетарная модель для прогноза временных рядов. Получить к ней свободный доступ и потестить очень сложно, но обзоры на неё неплохие.

Chronos (Chronos-Transformer) – модель на интересном подходе, преобразующим числовые значения временных рядов в дискретные токены через масштабирование и квантование. Обучение стандартных трансформерных архитектур (например, T5) ведется с использованием кросс-энтропийной функции потерь. Интересно что метод совсем минимально модифицирует исходные модели и применяет стратегии аугментации данных. В обзорах имеет высокую точность zero-shot прогнозирования на незнакомых данных, способен обучаться на разнородных источниках, имеет единую предобученную модель. Теперь минусы. Ограниченная точность при моделировании экспоненциальных трендов, потенциальные потери информации при квантовании, чувствительность к выбору масштабирования для рядов с экстремальными значениями. Это информация из статьи [1] по Chronos, но когда я сам тестировал, то заметил сильную чувствительность к выбросам, но при этом, как ни парадоксально, слабое улавливание изменения тренда [1],[2].

Informer имеет архитектуру, оптимизированную для прогнозирования длинных временных рядов (Long Sequence Time-Series Forecasting - LSTF). Фишка модели — в применении подхода ProbSparse Self-Attention, который снижает вычислительную сложность стандартного внимания за счет выбора только наиболее информативных ("доминирующих") запросов. Кроме того, он иерархически сжимает промежуточные представления, уменьшая объем памяти (“дистилирует внимание”). Также переработан генеративный декодер, который предсказывает всю выходную последовательность за один шаг, исключая пошаговое декодирование и значительно ускоряя вывод. Это всё делает возможным эффективную обработку экстремально длинных последовательностей (до 720 точек). Но, в этом и его слабость — на меньших датасетах требует адаптации [3],[4].

FEDformer (Frequency Enhanced Decomposed Transformer) – LLM с  гибридным подходом, комбинирующий трендово-сезонное разложение ряда и трансформер, работающий в частотной области (на основе выборки компонент Фурье). Модель умеет разделять глобальные закономерности (тренд, сезонность), а также имеет высокую согласованность с исходным распределением данных. Однако, платим мы здесь сложностью настройки [5],[6].

PatchTST (Time Series Transformer with Patchification). Интересная модель включающая в себя две фишки два инновационных принципа. Во-первых, производится сегментация исходного временного ряда на перекрывающиеся подпоследовательности (патчи) вместо отдельных точек, что снижает вычислительную сложность (патчификация). Во-вторых, производится независимая обработка каналов, т.е. каждый одномерный ряд (канал) обрабатывается независимо с общими весами модели, улучшая адаптивность к разнородным данным. Эти фишки подходы позволяют методу показать лучшее результаты в долгосрочном прогнозировании и способность анализировать расширенные исторические окна. Однако, (это уже не из статьи о методе [7], а из опыта тестирования) метод очень плохо учитывает связи одномерных рядов, на которые раскладывает тренд [7],[8].

Time-Series Pre-trained BERT (TSP-BERT) Модель, применяющая подходы предобучения BERT к данным временных рядов.

А как выглядят современные AutoML-фреймворки?

Современные платформы автоматизированного машинного обучения (AutoML) эволюционно разделились на два стратегических класса, определяющих их универсальность и область применимости.

Первый тип — фреймворки с глубоким подбором гиперпараметров (HPO-centric), который концентрирует вычислительные ресурсы на экстремально детальном поиске оптимальных гиперпараметров для ограниченного набора мощных, но фиксированных алгоритмов (чаще всего на основе градиентного бустинга: LightGBM, XGBoost, CatBoost). Примеры: H2O Driverless AI [10], оптимизированные конвейеры на базе фреймворков типа Optuna [11],[12] или Scikit-Optimize (BayesSearch)[13],[14], или LAMA от Сбера [9].

Второй тип — фреймворки с интеллектуальным выбором модели и признаков (Model/Feature Selection-centric), которые фокусируют ресурсы на автоматизированном подборе наиболее подходящего типа модели (например, решающее дерево, SVM, линейная или логистическая регрессия, ансамбли, нейросети) и релевантных признаков (фичей). Методы настройки гиперпараметров используются сравнительно простые (ограниченный гридсёрч, случайный поиск, простые градиентные методы). Примеры: TPOT [15], FLAML [16]. Сюда же относится фреймворк MOEX_AutoML.

Аргументация в пользу универсальности Model/Feature Selection-centric AutoML

Главный месседж ключевой тезис заключается в том, что подход, специализирующийся на интеллектуальном выборе метода (типа модели) и признаков, обладает принципиально более высокой универсальностью для решения разнородных бизнес-задач по сравнению с HPO-centric подходами. Сила этого подхода - в способности адаптироваться к природе данных, а не только в тонкой настройке одного, пусть и мощного, алгоритма. Да, на датасетах с большим числом наблюдений, где идеально “ложится” бустинг, HPO-centric подход может показать более точный результат . Но на множестве реальных задач, особенно с нестандартными, шумными или небольшими выборками, он просто не сможет работать - выдаст ошибку или переобучится. В то время как подход, основанный на выборе метода и признаков, стабильно срабатывает даже на “грязных” данных с выбросами, скачками и перепадами тренда.

Аргумент к вышесказанному - реальность корпоративных данных характеризуется крайним разнообразием.

Метрики абсолютно различны (“вверх”, “вниз”, “коридор”), с разным числом точек (от нескольких до миллиардов). Все они имеют разные свойства данных: дисперсия, шум, неполнота, разнородность признаков (числовые, категориальные, временные, текстовые), наличие мультиколлинеарности и гетероскедастичности.

Жесткая фиксация на одном-двух алгоритмах (например, градиентном бустинге), даже с идеально подобранными гиперпараметрами, неизбежно приводит к субоптимальным неудовлетворительным результатам при столкновении с задачей, для которой базовый алгоритм априорно не оптимален (например, линейно разделимые данные, строгие монотонные зависимости, малые размерности). Методо-ориентированный AutoML, активно исследующий пространство принципиально разных алгоритмов, с существенно большей вероятностью найдет адекватную базовую модель, соответствующую специфической структуре данных.

Критическая важность для малых датасетов

Это преимущество становится особенно критичным при работе с небольшими объемами данных. А ведь в финансах очень часто бывает, что данные помесячные только недавно начинают собирать, и число точек может насчитывать только пару десятков. В этом случае в HPO-centric подходах неминуемо будет переобучение. Нужно понимать, что исчерпывающий поиск в высокоразмерном пространстве гиперпараметров сложных моделей (типа XGBoost) требует значительного объема данных для обучения и валидации. На малых датасетах такой поиск крайне склонен к переобучению. Если базовый алгоритм AutoML (например, бустинг) не соответствует структуре данных, никакая тонкая настройка гиперпараметров не компенсирует эту фундаментальную несовместимость.

Теперь про MOEX_AutoML

Фреймворк MOEX_AutoML представляет собой комплексное решение, воплощающее принципы методо- (модельно-) ориентированного AutoML.

Фреймворк реализован в трех формах, обеспечивающих гибкость использования:

• Внутренняя Python-библиотека: для интеграции в скрипты и кастомные пайплайны разработчиками по pip install moex_automl  (только внутри Московской биржи)

• Через DAG-и в AirFlow: для организации регулярных (ежедневных, еженедельных) прогнозных расчетов

• No-code платформа: веб-интерфейс для бизнес-аналитиков и предметных экспертов без необходимости навыков программирования

Алгоритмическая структура фреймворка включает следующие ключевые этапы (рис.1):

1)    Разделение данных: исходная выборка делится на обучающую, валидационную и тестовую части. Тестовая часть (её объём — это гиперпараметр, по умолчанию равный периоду прогноза) удаляется для финальной оценки. Тестовая часть служит исключительно для объективной оценки итоговой точности. Валидационная часть используется для подбора модели и гиперпараметров. Обучающая часть используется для обучения (спасибо, кэп?)

2)    Задание пользовательских настроек: пользователь определяет ключевые параметры задачи (целевая переменная, горизонт прогноза, метрика качества и т.д.)

3)    Генерация признаков (Feature Engineering) — автоматическое создание разнообразных групп признаков:

• Авторегрессионные лаги целевой переменной

• Дифференциалы (разности) авторегрессионных лагов

• Календарные фичи: дамми-переменные для дня недели, месяца, сезона, выходного/праздничного дня, времени суток (день/ночь)

• Статистические фичи: скользящие окна (min, max, mean, std, median) для целевой и экзогенных переменных

• Экзогенные переменные (включая категориальные): числовые добавляются as is, категориальные : кодируются One-Hot Encoding при малом числе уникальных значений, Label Encoding или Target Encoding - при большом

• Событийные фичи: пользователь может задать "ключевые даты", кодируемые дамми-переменной (0 - до даты, 1 - после даты)

4)    Первичный отбор моделей (Model Selection ): на сгенерированном наборе признаков выполняется прогон широкого спектра ML-методов (детали будут ниже). Для каждого метода тестируется 5-11 вариантов значений ключевых гиперпараметров (центрированных вокруг дефолтовых значений). Важная особенность: MOEX_AutoML может включать в качестве "кандидатов" и другие AutoML-решения HPO-centric типа, реализуя концепцию "AutoML поверх AutoML". Тщательно проверяется, также (если был задан такой гиперпараметр) точность стекинга различных комбинаций моделей. Отбор лучших кандидатов (индивидуальных моделей или стекингов) происходит на основе многократной кросс-валидации скользящим окном (по 1 шагу). Метрика отбора выбирается пользователем (MAPE, SMAPE, MSE, RMSE, R2)

5)    Фиксация лучшего метода/стекинга и гиперпараметров: метод (или стекинг) и его гиперпараметры, показавшие наилучший результат на валидации по выбранной метрике, запоминаются

6)    Отбор значимых признаков (Feature Selection): при зафиксированных методе и гиперпараметрах (из шага 5) запускается несколько алгоритмов фичеселекшена. Каждый селектор выбирает подмножество признаков, которое он считает значимым. Затем оценивается, какой из наборов признаков (отобранных разными селекторами) дает лучший результат на валидации (по целевой метрике). Этот оптимальный набор признаков запоминается (про фичеселекторы будет ниже)

7)    Отбор модели на отобранных признаках: этап 4 повторяется, но на вход подаются не все исходные признаки, а только отобранные на шаге 6. Цель - найти лучшую модель (или стекинг) уже на редуцированном, наиболее информативном наборе фичей. Отобранный на этом шаге метод запоминается

8)    Построение прогноза: финализированная модель (из шага 7) с ее гиперпараметрами и отобранным набором признаков (из шага 6) используется для построения прогноза на тестовом периоде

9) Оценка и интерпретация: на тестовой выборке оценивается итоговая точность прогноза. Результаты прогноза, ключевые метрики и промт (описание процесса) могут быть направлены в LLM для генерации аналитического отчета (интерпретация, выводы)

Реализация и UX MOEX_AutoML. Пользовательский сценарий (UX) в no-code интерфейсе (Рис.2):

1)    Загрузка данных: пользователь загружает датасет (файл или подключение к БД)

2)    Базовые настройки, которые указывает пользователь:

• Столбец с датой/временем

• Столбец с целевой переменной (таргетом)

• Горизонт прогнозирования

• Доля тестовой выборки

3)    Выбор экзогенных переменных: пользователь задает перечень дополнительных переменных, которые могут влиять на таргет

4)    Выбор режима работы:

• Easy: Минимальное время расчета, тестируется ограниченный набор моделей и признаков (баланс в пользу скорости).

• Standard: Баланс между скоростью и точностью

• Precise: Максимальная точность, тестируется максимальное число моделей, признаков и их комбинаций (требует значительных ресурсов и времени)

5)    Дополнительные настройки моделей:

• Использовать только экзогенные переменные: Отключает автоматическую генерацию фичей (лаги, статистики, дамми на календарь и т.д.)

• Использовать комбинации моделей: Разрешает алгоритму рассматривать стекинг моделей

• Только интерпретируемые модели: Исключает из рассмотрения модели-"черные ящики" (нейросети, сложные ансамбли), оставляя линейные модели, деревья малой глубины, Lasso и т.д. (Это экономит время, если бизнес-аналитик не доверяет интерпретации Shap)

• Целевая метрика для выбора: MAPE, SMAPE, MSE, RMSE, R²

• Добавление важных дат: Пользователь может указать даты значимых событий, которые будут преобразованы в дамми-фичи (шаг 3)
  

  6)    Результаты. Пользователь получает:

• Название лучшего ML-метода (или стекинга) и его гиперпараметры

• Список отобранных значимых признаков

• Значения прогноза для тестового и будущего периодов.

• Точность (выбранную метрику) по всем протестированным методам (ранжированный список)

• График фактических значений и прогноза

• Уравнение модели (если выбраны только интерпретируемые модели)

Методы отбора признаков в MOEX_AutoML

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

SelectKBest: Основан на унивариантных статистических тестах (ANOVA F-value для регрессии, хи-квадрат для классификации). Ранжирует признаки по силе их индивидуальной связи с целевой переменной (p-value) и выбирает топ-K. Очень хорошо работает на данных с высокой размерностью, но чувствителен к мультиколлинеарности.

Sequential Feature Selector (SFS): Итеративно добавляет (Forward SFS) или удаляет (Backward SFS) признаки на основе их влияния на производительность конкретной модели-оценщика. Учитывает взаимосвязь признаков в модели, но  много ресурсов кушает.

Boruta (Wrapper/Embedded Hybrid): Основан на идее "теневых признаков". Создает случайные перестановки (тени) исходных признаков. Обучает ансамбль (обычно Random Forest) на расширенном наборе (оригинальные фичи + тени). Признак считается значимым, если его важность стабильно превышает максимальную важность среди его "теней" на заданном уровне статистической значимости. Выявляет нелинейные зависимости, при этом оставаясь устойчивым к шуму, но очень очень много ресурсов кушает.

BoostARoota (Embedded Method): Адаптирует алгоритмы градиентного бустинга (XGBoost, LightGBM, CatBoost) для отбора признаков. Обучает бустер, после чего ранжируеет признаки, вычисляет порог отсечения и отсекает всё что ниже порога. Дальше повторяет процесс итеративно. Хорошо учитывает взаимодействия признаков, но чувствителен к настройкам.

Выбор моделей в MOEX_AutoML

Фреймворк включает широкий спектр алгоритмов машинного обучения, покрывающих различные типы данных и задач. В этом главная идея, чтобы общий набор методов покрывал максимальный диапазон задач. Что есть в “арсенале”:

• Линейные модели с регуляризацией: ElasticNet (L1+L2), Lasso (L1), Ridge (L2), LassoLars (эффективен при разреженности), BayesianRidge (байесовский подход, устойчив к коллинеарности), SGDRegressor (стохастический градиент, масштабируемость), OrthogonalMatchingPursuit (разреженные решения)

• Регрессоры, устойчивые к выбросам: TheilSenRegressor, RANSACRegressor

• Методы на основе ближайших соседей: KNeighborsRegressor.

• Деревья решений и ансамбли: DecisionTreeRegressor, RandomForestRegressor, GradientBoostingRegressor (GBM), AdaBoostRegressor (с базовыми оценщиками ElasticNet или DecisionTree), ExtraTreesRegressor

• Оптимизированные градиентные бустинги: LightGBM, CatBoost (эффективен с категориальными фичами)

• Методы опорных векторов: SVR (устойчив к выбросам)

• Нейронные сети: MLPRegressor (классический многослойный перцептрон)

• Методы для потоковых данных: PassiveAggressiveRegressor

• Вероятностные модели: GaussianProcessRegressor (учет априорной информации, плохая масштабируемость)

• Специфические регрессоры: ARDRegression (регрессор с автоматической релевантностью), IsotonicRegression (регрессор с монотонной аппроксимацией)

• Модели временных рядов: SARIMAX (учет сезонности и экзогенных переменных). Вообще модель ARIMA используется как бэнчмаркинг к MOEX_AutoML, но SARIMAX мы всё-равно включаем.

Также в планах периодически включать в инструмент новые методы, и HPO-AutoML-ли

Эмпирическая валидация: Сравнительный анализ эффективности: MOEX_AutoML VS ИИ LLM

Теперь же давайте на практике посмотрим действительно ли AutoML MOEX_AutoML лучше LLM методов. Для оценки были сгенерированы 1150 MOC-датасетов искусственных датасетов. Из них (1023 – это различные датасеты взятые из открытых источников и их комбинации, 127 – различные математические функции и их комбинации).

Для тестирования на MOC-данных были взяты следующие модели:

• Базовые популярные LLM: DeepSeek-r1, ChatGPT-o3, ChatGPT-4.1, GLM 4.5, Gemmini 2.5 Pro, Llama 4, Grok-4, Qwen -3 -235B, Claude Sonnet 4, Qwen-3-32B, YandexGPT-5, GigaChat max, Gemma-3, Mistral medium 3. Модели тестировались либо на открытых источниках [17] либо на сайтах самих моделей

• Специализированные LLM: PatchTST, Informer, FEDformer, Cronos.

• Непосредственно сам MOEX_AutoML

• Модели для бэнчмарка. Линейная авторегрессия с лагом -1. Наивный метод flat, по которому последний имеющийся факт прогнозируется фиксированным значением

Результаты даны по двум метрикам:

• MAPE: средняя абсолютная процентная ошибка на датасетах (чем меньше, тем лучше).

• SCPORE: нормализованная интегральная метрика, где 100% соответствует лучшему результату по MAPE из всех моделей в конкретном тесте, а 0% — худшему. Усредняется по всем датасетам.

Ключевые результаты(табл. 1):

1 место. MOEX_AutoML: MAPE = 11%, SCPORE = 100%. Демонстрирует абсолютное лидерство, подтверждая эффективность автоматизированного подбора моделей, признаков и ансамблирования.

2 место. PatchTST: MAPE = 21%, SCPORE = 82%. Лучший результат среди специализированных временных архитектур, но с существенным отрывом (10 п.п. по MAPE) от AutoML.

3 место. Линейная авторегрессия ? : MAPE=23% , SCPORE = 79%. Ирония в том, что простая линейная регрессия обошла крутые многомиллиардные LLM-ки.

4-6 место. Informer, FEDformer, Cronos: MAPE ~23-25%, SCPORE ~75-78%. Показывают схожий, достаточно высокий уровень точности, превосходящий базовые методы.

7-11 место. Универсальные LLM (DeepSeek-r1, ChatGPT-4.1, GLM 4.5, ChatGPT-o3, Gemmini 2.5 Pro): MAPE = 28-35%, SCPORE = 56-70%. Все результаты существенно хуже AutoML и профильных LLM для TS. Даже лучшая LLM (DeepSeek-r1: MAPE~28%, SCORE=70%) уступают Линейной регрессии.

12 место. Наивный метод (Flat): Показывает результат (MAPE=36%, SCPORE=54%) и вот, что совсем печально – это лучше целого ряда LLM,  подчеркивая проблему базовой неадаптированности LLM к числовому прогнозу.

13-20 место. Универсальные LLM (Llama 4, Grok-4, Qwen -3 -235B, Claude Sonnet 4, Qwen-3-32B, YandexGPT-5, GigaChat max, Gemma-3): MAPE = 36-44%, SCPORE = 38-54%. Обучение моделей явно не предполагало их использование для TS прогнозов.

21 место. Mistral medium 3: MAPE = 65%, SCPORE = 0%. Вот это не знаю как объяснить, но Mistral реально выдавала какую-то дичь.

Табл.1. Результаты тестирования моделей на MOC-данных

Тестирование на реальных данных Московской биржи

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

Выводы сделайте сами, но результаты по сути аналогичны результатам теста на MOC-данных (табл.2).

Табл.2. Результаты тестирования моделей на реальных данных

Заключение и практические рекомендации

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

• AutoML в целом и MOEX_AutoML в частности лучше решает задачи прогнозирования TS, чем самые дорогие LLM. Их ключевое преимущество — строгая ориентация на минимизацию целевой ошибки (RMSE, MAE, MAPE) через автоматизированный подбор модели, гиперпараметров, признаков, идеально адаптированные к специфике данных и задачи.

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

• Потенциал специализированных LLM для TS: специализированные архитектуры, адаптирующие трансформеры для временных рядов (Chronos, PatchTST, Informer, FEDformer), показывают многообещающие результаты, особенно в режиме zero-shot и на длинных последовательностях. Однако их точность все еще существенно уступает правильно настроенным AutoML-конвейерам на широком спектре задач.

• Преимущество Model/Feature Selection-centric AutoML: подход, фокусирующийся на интеллектуальном выборе типа модели и признаков, доказал свою принципиально более высокую универсальность и эффективность, особенно на малых датасетах и разнородных задачах, по сравнению с подходом, заточенным только на тонкую настройку гиперпараметров фиксированных алгоритмов.

• Фреймворк MOEX_AutoML показал себя как передовой и универсальный инструмент для прогноза TS, превосходящий самые TOP-овые LLM.

Список источников:

[1] https://arxiv.org/abs/2403.07815

[2] https://github.com/Kurt232/Chronos_LLM

[3] https://arxiv.org/abs/2012.07436

[4] https://github.com/zhouhaoyi/Informer2020

[5] https://arxiv.org/abs/2201.12740

[6] https://github.com/MAZiqing/FEDformer

[7] https://arxiv.org/abs/2211.14730

[8] https://github.com/yuqinie98/PatchTST

[9] https://github.com/sberbank-ai-lab/LightAutoML

[10] https://h2o.ai/platform/ai-cloud/make/h2o-driverless-ai/

[11] https://optuna.org/

[12] https://github.com/scikit-optimize/scikit-optimize

[13] https://scikit-optimize.github.io/stable/

[14] https://github.com/scikit-optimize/scikit-optimize

[15] https://epistasislab.github.io/tpot/latest/

[16] https://microsoft.github.io/FLAML/

[17] https://openrouter.ai