ML в финансах: где он действительно полезен

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

Где ML действительно работает

Эти задачи объединяет общее свойство: много наблюдений, относительно высокое отношение сигнала к шуму и устойчивая структура зависимостей, которая не меняется кардинально от месяца к месяцу.

• Прогноз спроса и денежных потоков. Сложная сезонность, календарные эффекты, влияние цены и промо — там, где линейная модель уже слишком груба, градиентный бустинг по табличным признакам обычно даёт ощутимый прирост точности.
• Прогноз оттока (churn). Поведенческие признаки на большом потоке событий хорошо разделяют уходящих и остающихся клиентов; задача почти всегда сводится к классификации с явной бизнес-ценой ошибки.
• Кредитный скоринг и ранжирование. Десятки и сотни признаков, большая обучающая выборка, понятный целевой признак (дефолт). Здесь ML — отраслевой стандарт, но с жёстким требованием интерпретируемости (об этом ниже).
• Антифрод и детекция аномалий. Редкие события в большом потоке транзакций; модель работает как фильтр первого уровня, повышающий нагрузку ровно там, где она оправдана.
• Оптимизация запасов. Прогноз спроса плюс модель неопределённости напрямую конвертируются в страховые запасы и точки заказа.
• NLP по отчётности и документам. Извлечение фактов из раскрытий, новостей и договоров, классификация тональности, разметка рисков — там, где раньше работал только ручной разбор.

Где ML не работает или опасен

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

Прямой прогноз цен ликвидных активов

Это самая частая и самая дорогая ошибка. Доходности ликвидных активов имеют крайне низкое отношение сигнала к шуму: предсказуемая компонента, если и есть, исчисляется долями процента дисперсии. Ряды нестационарны — режим волатильности, корреляции и сами зависимости меняются. На таких данных гибкая модель с тысячами параметров почти гарантированно переобучается: она запоминает шум конкретного исторического окна и выдаёт его за закономерность. Чем выше ёмкость модели, тем убедительнее выглядит бэктест и тем меньше он говорит о будущем. Это не значит, что ML бесполезен в инвестициях; он работает на задачах рядом — оценка риска, исполнение, классификация режимов, — но прямой прогноз цены «в лоб» остаётся демонстрацией чаще, чем рабочим инструментом.

«Чёрный ящик» там, где нужна объяснимость

Если решение модели влияет на капитал, резервы или отказ клиенту, его придётся объяснять — риск-функции, внутреннему контролю, регулятору. Модель, которая не умеет объяснить отдельное решение, в таком контуре непригодна независимо от точности. Цена ошибки и требование защищаемости часто перевешивают несколько процентов качества.

Утечка данных — главная причина обманчивых бэктестов

Когда модель показывает выдающееся качество на исторических данных и рассыпается в продакшене, причина почти всегда одна: утечка данных (data leakage). Это ситуация, когда в обучающие признаки попадает информация, которая в момент реального прогноза ещё недоступна. Модель «подсматривает» будущее и честно его воспроизводит на отложенной выборке — а в эксплуатации этого будущего просто нет.

Типовые источники утечки на финансовых временных рядах:

• Заглядывание вперёд (look-ahead). Признак рассчитан по данным, которые на момент прогноза ещё не были известны: финальная (а не первая) публикация макропоказателя, цена закрытия в признаке для прогноза этого же дня, агрегат, посчитанный по всему ряду целиком.
• Препроцессинг до разбиения. Масштабирование, импутация пропусков или отбор признаков, выполненные на полном наборе до деления на train/test, переносят статистику теста в обучение.
• Перекрытие меток. Если целевой признак считается на горизонте в несколько периодов, соседние наблюдения обучающей и тестовой выборок разделяют общие будущие точки.

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

Кросс-валидация для временных рядов

Стандартный k-fold для временных рядов некорректен. Он перемешивает наблюдения и кладёт в обучение точки, которые по времени идут после тестовых. Модель обучается на будущем, чтобы предсказать прошлое — ровно та самая утечка, только встроенная в схему оценки. Любой временной порядок при этом разрушается.

Корректные схемы сохраняют направление времени:

• Walk-forward (расширяющееся или скользящее окно). Обучаемся на прошлом, проверяемся на следующем отрезке, сдвигаемся вперёд и повторяем. Так оценка повторяет реальный режим эксплуатации.
• Purged / embargoed CV. Когда метка считается на горизонте, между обучением и тестом удаляют (purge) перекрывающиеся наблюдения и добавляют «эмбарго» — буфер после теста, чтобы автокорреляция не протекала обратно в обучение.

В scikit-learn базовый walk-forward даёт TimeSeriesSplit: он гарантирует, что тестовый фолд всегда строго позже обучающего. Минимальный исполнимый пример сравнивает честную и нечестную схемы на синтетическом ряде — числа здесь иллюстративные, данные сгенерированы для наглядности.

# Walk-forward валидация vs. ошибочный k-fold на временном ряде.
# Данные синтетические, числа иллюстративные.
import numpy as np
from sklearn.model_selection import TimeSeriesSplit, KFold, cross_val_score
from sklearn.ensemble import GradientBoostingRegressor

rng = np.random.default_rng(0)
n = 600

# Ряд с трендом, сезонностью и автокоррелированным шумом.
t = np.arange(n)
season = np.sin(2 * np.pi * t / 30)
noise = np.cumsum(rng.normal(0, 0.3, n))
y = 0.01 * t + season + noise

# Признаки — только лаги (известны на момент прогноза).
def make_lags(series, lags=(1, 2, 3, 7, 14)):
    X = np.column_stack([np.roll(series, k) for k in lags])
    return X[max(lags):], series[max(lags):]

X, target = make_lags(y)
model = GradientBoostingRegressor(random_state=0)

# ВЕРНО: время сохраняется, тест всегда строго позже обучения.
tscv = TimeSeriesSplit(n_splits=5)
ok = cross_val_score(model, X, target, cv=tscv,
                     scoring="neg_root_mean_squared_error")

# НЕВЕРНО: k-fold перемешивает время — утечка из будущего в прошлое.
kf = KFold(n_splits=5, shuffle=True, random_state=0)
leak = cross_val_score(model, X, target, cv=kf,
                       scoring="neg_root_mean_squared_error")

print("walk-forward RMSE:", round(-ok.mean(), 3))
print("k-fold RMSE (оптимистично):", round(-leak.mean(), 3))
# k-fold почти всегда «лучше» — и именно поэтому ему нельзя верить.

Ручная альтернатива — расширяющееся окно: на каждом шаге обучаемся на y[:i], прогнозируем y[i], затем сдвигаем границу. Логика та же, что у TimeSeriesSplit, но при необходимости сюда добавляют purge и эмбарго для меток с горизонтом.

Метрики: почему accuracy обманчива

На антифроде и в большинстве задач с редкими событиями accuracy бесполезна. Если мошеннических транзакций условно 0,5%, модель, всегда отвечающая «не мошенничество», получит около 99,5% точности — и не поймает ни одного случая. Доля верных ответов вознаграждает игнорирование редкого класса.

На несбалансированных классах смотрят на другое:

• Precision — какая доля сработок действительно мошенничество (цена ложных тревог и ручного разбора).
• Recall — какую долю реального мошенничества модель поймала (цена пропуска).
• PR-AUC (площадь под кривой precision-recall) — устойчивее ROC-AUC при сильном дисбалансе, потому что не «маскируется» огромным числом верных отрицаний.

Выбор порога — это бизнес-решение о соотношении цены пропуска и цены ложной тревоги, а не технический дефолт 0.5. Для задач регрессии действует то же требование честности: качество измеряют out-of-sample (на данных, которых модель не видела), а не in-sample. Хорошая подгонка на обучении не говорит ни о чём — её всегда можно довести до идеала, увеличив сложность модели.

Объяснимость как требование, а не опция

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

• Глобальная важность признаков показывает, на что модель опирается в целом, и помогает поймать признак-утечку: если в топе оказывается переменная, которой в момент прогноза быть не должно, это сигнал тревоги, а не успеха.
• SHAP раскладывает отдельный прогноз на вклады признаков на основе теоретико-игрового подхода (значения Шепли). Это даёт объяснение уровня «почему именно этому заявителю отказано», которое можно показать риск-функции.

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

Production против демо

Главное различие между демонстрацией и рабочей системой — не качество на отложенной выборке, а способность удерживать его во времени. Модель в ноутбуке статична; реальность — нет.

• Дрейф данных (data drift). Распределение входных признаков и сама зависимость «признаки → цель» меняются: новый продукт, смена поведения клиентов, экономический режим. Модель, обученная на прошлом, постепенно теряет точность даже без единой ошибки в коде.
• Мониторинг. Нужно непрерывно отслеживать и качество прогнозов, и распределения входов — деградация часто видна по сдвигу признаков раньше, чем по упавшей метрике.
• Переобучение по расписанию. Регламент обновления на свежих данных с обязательной валидацией перед выкаткой — иначе модель просто стареет.
• Фиче-стор (feature store). Единый источник признаков для обучения и для онлайн-прогноза. Если признак в проде считается иначе, чем при обучении (training-serving skew), это тихая утечка наоборот — модель в бою получает не те данные, на которых училась.

Без этого контура — мониторинга, переобучения, согласованных признаков — даже хорошая модель деградирует. MLOps здесь не «инженерная роскошь», а условие того, что результат вообще доживёт до пользы.

Задача → подходит ли ML → почему

Где чаще лучше классика

Если данных мало, важна интерпретация и цена ошибки очень высока, классическая регрессия, эконометрика или rule-based подход часто выигрывают по совокупной стоимости владения. Для финансовой команды важно не только качество, но и способность защищать модель перед риск-функцией, внутренним контролем и руководством. Baseline из простой модели обязателен: без него нельзя доказать, что сложная модель действительно лучше, а не просто дороже.

Что должен получить бизнес

На выходе у бизнеса должно быть три вещи: модель с понятной метрикой качества, честно измеренной out-of-sample; материалы для принятия решения с явным блоком ограничений; и план внедрения с мониторингом и владельцем на стороне клиента. Если есть только Jupyter-ноутбук и графики, проект ещё не готов к реальной эксплуатации.

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