Разработка торговой стратегии на ИИ: что это на самом деле включает

«Сделаете мне ИИ-стратегию?» — вопрос, который мы получаем еженедельно. Ответ «да», а полезная часть ответа — что именно содержится в этом предложении, потому что модель составляет процентов десять.

Ниже весь конвейер в том виде, в каком мы его строим, по порядку и со сценарием провала на каждом шаге.

1. Решить, что вы предсказываете

До сбора любых данных цель должна быть конкретной, измеримой и торгуемой величиной. «Пойдёт ли вверх» такой величиной не является. Настоящие цели выглядят так:

• Направление средней цены на горизонте N секунд при условии, что ход превышает издержки.
• Максимальный благоприятный ход внутри горизонта — насколько далеко цена уйдёт в вашу сторону, прежде чем пойдёт против.
• Максимальный неблагоприятный ход — используется для размера стопа, а не входа.
• Вероятность того, что движение истощилось, — это другой вопрос, чем направление.

Наш микроструктурный движок предсказывает три из них отдельными головами модели: направление, MFE и MAE. Предсказание одного направления говорит, куда идти, и ничего не говорит о том, сколько рисковать, — это половина стратегии.

2. Собирать данные до того, как они понадобятся

Этот шаг пропускают, и потом из этого не выбраться. Данные микроструктуры недоступны задним числом в том разрешении, которое имеет значение. Если вам нужны снимки L2-стакана, поток тейкеров и ликвидации на разрешении событий — вы должны были их записывать.

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

3. Признаки и проблема честности

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

Наша модель разворота использует 59 признаков четырёх семейств: структура эпизода (сколько ног прошло движение, как долго, глубочайший откат), контекст старшего таймфрейма, фон BTC и ликвидность инструмента. Автоматический аудит пересчитывает каждый на обрезанном ряде и нашёл три настоящие утечки — все оказались ошибками выравнивания при склейке фандинга и открытого интереса с рядом баров.

# Каждый признак проходит это, прежде чем попасть в модель.
for name, fn in FEATURES.items():
    full    = fn(df)                      # обычный конвейер
    partial = fn(df.iloc[:t + 1])         # будущее физически отсутствует
    if not close_enough(full.iloc[t], partial.iloc[-1]):
        raise LeakError(name)             # не предупреждение, а падение сборки

4. Валидация, которая не льстит

Случайная кросс-валидация на упорядоченных во времени данных даёт красивые бессмысленные числа. Честный вариант — walk-forward с purge и embargo: обучающие образцы, чьи окна меток перекрываются с валидационной выборкой, удаляются, плюс запас после неё под автокорреляцию.

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

5. Фильтр по матожиданию

Именно этот шаг отделяет модель от стратегии. Предсказание — это не сделка. Модель выдаёт число; стратегия решает, положительно ли матожидание действия после комиссий, слиппеджа и задержек.

def should_trade(pred, book, cfg):
    edge = pred.direction_conf * pred.expected_mfe      # что рассчитываем забрать
    cost = (cfg.fee_in + cfg.fee_out
            + slippage_estimate(book, size)
            + expected_funding(cfg.hold_periods))
    if edge <= cost * cfg.margin:
        return None                                     # большинство предсказаний кончается здесь
    size = kelly_fraction(pred, cfg) * cfg.equity
    return Intent(size=size, stop=pred.expected_mae * cfg.stop_k)

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

6. Деплой — отдельная дисциплина

Модель, работающая в ноутбуке, и модель, работающая в боевом цикле, — разные артефакты. У реалтайм-пути есть требования, которых у исследовательского кода нет:

• Ограниченная предсказуемая задержка инференса — никаких сюрпризов с аллокациями на горячем пути.
• Вычисление признаков, идентичное обучению. Тонкое расхождение между research- и production-кодом признаков — самая частая причина модели, которая «работала в бэктесте».
• Версионирование, чтобы знать, какая модель произвела какую сделку.
• Путь отката, не требующий деплоя.
• Мониторинг распределения предсказаний, а не только P&L.

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

Что мы будем и чего не будем утверждать

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

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

Если у вас есть данные и гипотеза, честный первый проект — не бот. Это фаза сбора и purged-бэктест: самый дешёвый способ выяснить, стоит ли бота строить вообще.