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

В таких задачах линейные и статистические модели, Random Forest и особенно градиентный бустинг по деревьям решений, или GBDT, дают сильную отправную точку и нередко оказываются итоговым выбором. LLM разумнее применять там, где существенная часть задачи выражена естественным языком: нужно извлечь факты из примечаний к отчётности, преобразовать вопрос в SQL, объединить таблицу с документами или объяснить уже рассчитанный результат.

Это не означает, что деревья универсально превосходят LLM. Прямых независимых сравнений современных LLM и хорошо настроенных GBDT на репрезентативном наборе реальных финансовых таблиц пока недостаточно. Практический вывод уже: LLM не следует считать автоматической заменой специализированного табличного pipeline.

Что именно сравнивается

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

Термин «классические модели» объединяет разные инструменты, которые нельзя считать взаимозаменяемыми:

  • линейная и логистическая регрессия полезны как простые, регуляризуемые и сравнительно прозрачные baseline;
  • ARIMA, ETS и родственные статистические методы предназначены прежде всего для временных рядов;
  • Random Forest и GBDT работают с табличными признаками и моделируют нелинейности и взаимодействия;
  • специализированные нейронные сети для таблиц или последовательностей относятся к глубокому обучению, но не обязательно являются LLM;
  • LLM обрабатывает таблицу как токенизированное представление – например, текст, JSON, Markdown или последовательность пар «столбец: значение».

Последнее различие принципиально. Для GBDT число в ячейке является числовым признаком. Для LLM оно первоначально является последовательностью токенов, если модель не вызывает отдельный калькулятор или исполняемый код.

Табличная классификация и регрессия при ограниченной выборке

Если задача сводится к отображению фиксированного набора признаков в вероятность, класс или число, GBDT обычно стоит проверять раньше LLM. Деревья естественно моделируют пороги, пропуски и нелинейные взаимодействия между финансовыми показателями. Для этого им не требуется превращать каждую строку в текстовый контекст.

На табличных наборах среднего размера tree-based методы часто превосходят нейронные сети даже без учёта скорости. Один известный benchmark рассматривал наборы примерно с 10 000 наблюдений и обнаружил устойчивое преимущество деревьев в этом режиме, одновременно показав, что результат зависит от характерных свойств табличных данных Why do tree-based models still outperform deep learning on tabular data?. Это не доказательство для любого финансового набора: вывод нельзя без проверки переносить на миллионы наблюдений, мультимодальные данные или задачи с большим объёмом текста.

Обзор применения LLM к таблицам также показывает неоднородную картину: результат зависит от модели, сериализации таблицы, промпта, fine-tuning, retrieval и конкретного датасета. В отдельных экспериментах более простой KNN с весами признаков от XGBoost превосходил LLM-подход Large Language Models on Tabular Data – A Survey. Поэтому для обычной feature-based классификации или регрессии преимущество LLM нужно демонстрировать, а не предполагать.

Классическая модель особенно привлекательна, если одновременно выполняются несколько условий:

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

При этом «классическая» не означает «только линейная». В эмпирическом исследовании прогнозирования доходностей деревья и нейронные сети учитывали нелинейные взаимодействия признаков и улучшали прогноз по сравнению с более простыми регрессионными спецификациями Empirical Asset Pricing via Machine Learning. Это исследование не сравнивало модели с LLM, но хорошо показывает широту специализированного инструментария.

Точная арифметика не должна зависеть от генерации

Расчёт коэффициента ликвидности, суммирование платежей, сортировка по доходности, применение порогового правила и построение бухгалтерской сверки – не задачи для вероятностной генерации. Если формула известна, правильный инструмент обычно SQL, Python, электронная таблица или проверяемый вычислительный граф.

Например, при оборотных активах 120 млн и краткосрочных обязательствах 80 млн коэффициент текущей ликвидности равен 1,5. Для получения результата не нужна обученная модель. LLM может распознать запрос и сформировать выражение 120 / 80, но само деление лучше выполнить детерминированным инструментом.

Токенизация чисел не обеспечивает языковой модели надёжного алгоритмического понимания арифметики. Обзор табличных LLM относит числовое рассуждение, масштаб таблиц и зависимость от способа представления к существенным ограничениям таких систем Large Language Models on Tabular Data – A Survey. Вызов калькулятора или Python заметно меняет архитектуру решения: сравнивать тогда следует не «LLM против GBDT», а две полные системы вместе с их инструментами, проверками и обработкой ошибок.

Финансовые временные ряды требуют временной модели оценки

Для прогноза цены, доходности, объёма, волатильности или денежного потока порядок наблюдений является частью задачи. Разумный набор baseline может включать наивный прогноз, ARIMA или ETS, регуляризованную регрессию и GBDT с лагами и скользящими статистиками. Transformer или LLM имеет смысл добавлять после них, а не вместо них.

В одном опубликованном сравнении на дневных данных шести американских акций за 2014–2024 годы ARIMA и Random Forest оставались конкурентоспособными, тогда как LSTM и Transformer не показывали стабильного преимущества для всех тикеров A Comparative Study of Transformer-Based and Classical Models for Financial Time-Series Forecasting. Область вывода узкая: горизонт составлял один торговый день, а исследование не устанавливает универсального превосходства ARIMA или Random Forest.

Гораздо важнее название архитектуры может оказаться способ проверки. Утечка данных, или leakage, возникает, когда при обучении или формировании признаков используется информация, которой не было в момент прогнозируемого решения. В финансовых данных это может быть отчётность, привязанная к концу квартала, но опубликованная позже, пересмотренное значение макроэкономического показателя или нормализация, рассчитанная по всей истории, включая тестовый период.

Случайное перемешивание строк обычно нарушает временную границу и способно завысить оценку backtest. Исследования утечки в финансовом тестировании показывают, что даже распространённые процедуры подготовки данных могут передавать модели информацию из будущего Information Leakage in Backtesting.

Вместо случайного разбиения нужен temporal split или walk-forward validation: модель обучается на доступном прошлом, проверяется на следующем временном интервале, затем граница сдвигается вперёд. Этот протокол не устраняет survivorship bias, задержки публикации, пересмотры данных, множественное тестирование и операционные издержки, но лучше воспроизводит реальный момент принятия решения.

Калибровка и устойчивость важнее одной метрики

Высокий AUC или низкий RMSE ещё не означают, что модель подходит для финансового решения.

Калибровка показывает, соответствует ли предсказанная вероятность наблюдаемой частоте события. Если среди заявок с прогнозом дефолта 10% дефолт происходит примерно в одном случае из десяти, модель калибрована в этой области. Для лимитов, резервов и решений с асимметричной стоимостью ошибок это может быть важнее небольшого прироста ranking-метрики.

Рассмотрим условный, не эмпирический пример. На walk-forward тесте логистическая регрессия получила AUROC 0,842, GBDT – 0,867, а LLM-предиктор – 0,869. Однако после калибровки Brier score у GBDT равен 0,076, а у LLM – 0,091; кроме того, LLM не укладывается в установленный бюджет задержки. Выбирать LLM только из-за прироста AUROC на 0,002 было бы необоснованно: система хуже оценивает абсолютный риск и не удовлетворяет эксплуатационному ограничению. Числа здесь лишь иллюстрируют логику выбора.

Нужно также проверять concept drift – изменение связи между признаками и целевой переменной во времени. Например, тот же коэффициент задолженности может иначе соотноситься с риском после изменения ставок или стандартов кредитования. Drift затрагивает и классические модели, и LLM; ни одна архитектура не устраняет необходимость мониторинга по временным периодам.

Аудит, воспроизводимость и стабильность схемы

Под интерпретируемостью следует понимать возможность проследить, почему модель выдала результат и какие входы на него повлияли. Коэффициенты линейной модели, правила преобразования признаков и feature attribution для GBDT обычно легче включить в контролируемый отчёт, чем свободно сформированный текст LLM. Но attribution показывает поведение модели, а не причинный эффект признака.

LLM добавляет дополнительные источники вариативности: шаблон промпта, порядок столбцов, способ обозначения пропусков, формат чисел, версия модели и параметры генерации. В экспериментах по пониманию таблиц качество менялось при перестановке строк и столбцов, транспонировании и изменении формата при сохранении той же информации Rethinking Tabular Data Understanding with Large Language Models. Эти результаты получены главным образом на задачах table understanding и не доказывают такое же ухудшение для каждого финансового набора. Они всё же показывают, что сериализация является частью модели и должна тестироваться как код.

Классические модели тоже не автоматически детерминированы: результат могут менять seed, параллельное обучение, версия библиотеки или порядок данных. Разница в том, что такой pipeline обычно проще зафиксировать, повторить и покрыть тестами.

Требование Когда преимущество чаще у классического pipeline Что требуется от LLM-системы
Точная арифметика Формулы исполняются напрямую в SQL или коде Вызов проверяемого инструмента, а не генерация числа
Фиксированная табличная схема GBDT или регрессия принимает типизированные признаки Стабильная сериализация и тесты на порядок, формат и пропуски
Калиброванный риск Доступны стандартные процедуры калибровки и диагностики Отдельный вероятностный выход и его временная проверка
Низкая задержка и массовый inference Компактная модель обрабатывает строки пакетно Нужны измерения токенов, кэширования и очередей
Аудит Проще версионировать признаки, параметры и расчёты Нужно сохранять промпт, контекст, версию модели и tool calls
Работа с текстом отчётности Требуется отдельный NLP-слой LLM может быть основной частью интерфейса или извлечения

Где LLM действительно добавляет ценность

Сильная область LLM начинается на границе таблицы и языка. Модель может:

  • преобразовать вопрос аналитика в SQL;
  • сопоставить формулировку из примечания к отчётности со столбцом аналитической витрины;
  • извлечь кандидаты на факты из filing для последующей проверки;
  • объяснить результат GBDT в терминах исходных показателей;
  • оркестрировать запросы к базе, Python-коду и документному поиску;
  • объединить числовую таблицу с описанием рисков, договорами или комментариями руководства.

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

Такое разделение особенно важно для регуляторной отчётности. Например, SEC публикует Financial Statement Data Sets с числовыми данными, извлечёнными из XBRL и приведёнными к плоскому формату для анализа между компаниями и периодами. Одновременно SEC предупреждает, что наборы не заменяют исходные filings, могут содержать ошибки представления и не включают все доступные метаданные Financial Statement Data Sets – SEC.gov. LLM может помочь найти и объяснить расхождение, но не должна превращать непроверенное извлечение в авторитетное число.

Практический порядок выбора

Сравнение стоит начинать не с архитектуры, а с момента решения и доступной тогда информации.

  1. Зафиксировать целевую переменную и временную границу. Для каждого признака должна быть известна дата фактической доступности, а не только отчётный период.
  2. Отделить вычисление от предсказания. Известные формулы выполняются детерминированно; модель используется только там, где нужно оценить неизвестную зависимость.
  3. Построить простые baseline. Наивный прогноз, регуляризованная регрессия, специализированная модель временного ряда и GBDT создают минимальный уровень, который более сложная система должна превзойти.
  4. Провести walk-forward проверку. Сравнивать нужно качество по периодам, калибровку, чувствительность к drift и метрики, связанные с ценой ошибок. Для торговых применений историческая точность сама по себе не доказывает прибыльность: нужны издержки и ограничения исполнения.
  5. Добавлять LLM ради конкретной функции. Основанием может быть измеримое улучшение после включения текста, удобный естественно-языковой интерфейс или сокращение ручной работы при сохранении проверяемого вычислительного слоя.
  6. Сравнивать полные системы. Если LLM использует retrieval, Python, SQL и fine-tuning, в оценку должны входить точность каждого компонента, задержка, стоимость, контроль доступа и обработка отказов.

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