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

В первой версии модель управляла одной позицией:

где . Отрицательное значение означает short, положительное значение означает long, значение около нуля означает отсутствие активной позиции.

В портфельной версии модель выдаёт уже не одну позицию, а сырой сигнал по каждому активу:

Здесь ещё не финальный вес портфеля. Это score по активу : знак отвечает за направление, модуль отвечает за силу сигнала.

Дальше эти сигналы превращаются в относительные long/short веса портфеля. Например, через рыночно-нейтральную проекцию:

где это число активов, это заданный общий gross exposure портфеля, а это финальный вес актива .

Например, если , то сумма абсолютных весов портфеля будет около 100%.

После такой нормализации положительные веса становятся long-позициями, отрицательные веса становятся short-позициями, а общий размер портфеля остаётся контролируемым.

Портфельная доходность считается уже по всей корзине активов:

где это доходность актива на шаге .

Дальше учитываются комиссии, проскальзывание и стоимость ребалансировки:

То есть не исчезает, он просто перестаёт быть финальной позицией. В single-asset версии он сразу задавал позицию, а в портфельной версии он даёт сырой сигнал по каждому активу. Финальные веса появляются уже после портфельной нормализации.

Если интересно, такую версию можно реализовать довольно прямо: заменить single-asset head на multi-asset score head, добавить слой нормализации весов и считать уже portfolio-level PnL / Sharpe с учётом комиссий, проскальзывания и оборота.

По OHLCV, я не исхожу из того, что эти данные детерминированно определяют будущее. Гипотеза слабее: в них могут существовать локальные статистические зависимости и режимные асимметрии, которые проверяются только эмпирически. Объёмы здесь не "магический предиктор", а прокси ликвидности и интенсивности движения. Два положительных held-out квартала это сигнал к дальнейшей проверке, не закрытый вопрос.

Для технического обсуждения - GitHub Issues: github.com/YuriyKolesnikov/diffquant

Наши исследования схожих задач привели нас к выводу, что языковые модели как агентный подход наиболее эффективны в гибридной архитектуре, где взаимодействуют квантовые модели и ИИ-агенты.

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

Вы абсолютно правы, CCXT в некоторых режимах агрегирует сделки, из-за чего поле num_trades может отличаться от нативных значений Binance. Поэтому для точных исследований я всегда рекомендую использовать оригинальные данные напрямую из Binance Futures API. Один из самых удобных способов — через библиотеку python-binance (https://github.com/sammchardy/python-binance, устанавливается через pip install python-binance). Важно учитывать, что библиотека неофициальная (Binance её напрямую не поддерживает), но это самый используемый и функциональный инструмент в сообществе.

Минимальный пример получения минутных свечей по фьючерсам:

import datetime as dt
from binance.client import Client, BaseClient
from binance.enums import HistoricalKlinesType

symbol = "*USDT"
start_dt = dt.datetime(..., tzinfo=dt.timezone.utc)
end_dt = dt.datetime(..., tzinfo=dt.timezone.utc)

klines_type = HistoricalKlinesType.FUTURES
interval = BaseClient.KLINE_INTERVAL_1MINUTE

client = Client()

data = client.futures_klines(
    klines_type=klines_type,
    symbol=symbol,
    interval=interval,
    startTime=int(start_dt.timestamp() * 1000),
    endTime=int(end_dt.timestamp() * 1000),
)

client.close_connection()

Чтобы окончательно снять сомнения, я ещё раз вручную проверил через официальный API Binance и сравнил с локальной базой проекта. Все данные полностью совпали. Для прозрачности привожу три последовательные котировки (14:45, 14:46, 14:47 UTC), включая ту, которая вызвала вопрос:

=== Raw quotes ===

[1746456240000, '0.2720500', '0.2728000', '0.2712000', '0.2726500', '110004', 1746456299999, '29917.2349400', 557, '51011', '13887.8376800', '0']
[1746456300000, '0.2724100', '0.2732700', '0.2718400', '0.2721300', '99912', 1746456359999, '27229.3868100', 464, '41200', '11236.2752000', '0']
[1746456360000, '0.2723500', '0.2726500', '0.2719900', '0.2724700', '49486', 1746456419999, '13476.6411000', 349, '24452', '6662.0162200', '0']

=== Human-readable ===

[Date: 2025-05-05  Time: 14:45:00] Open=0.272050, High=0.272800, Low=0.271200, Close=0.272650, Volume=110004.00, Num Trades=557
[Date: 2025-05-05  Time: 14:46:00] Open=0.272410, High=0.273270, Low=0.271840, Close=0.272130, Volume=99912.00, Num Trades=464
[Date: 2025-05-05  Time: 14:47:00] Open=0.272350, High=0.272650, Low=0.271990, Close=0.272470, Volume=49486.00, Num Trades=349

Таким образом, в бэктесте использовались именно «чистые» данные Binance Futures API, без сторонней агрегации.

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

Подготовка данных для обучения в данном случае не является сложной задачей — вся логика и структура уже подробно описаны в статье. Реализацию data layer я оставил на усмотрение исследователей, чтобы было пространство для творчества.
Вы можете написать свой data layer под разные площадки (Binance, Bybit, OKX и др.) и тем самым реально прокачать свои навыки.

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

Что касается стакана.
Глубина заявок критична в HFT и субсекундных стратегиях, где важна микроструктура рынка. Для минутных моделей, как описано в статье, достаточно OHLCV и при желании тиковых данных, а расширенный стакан добавляет сложность и не всегда даёт прирост качества.

Что касается влияния дополнительных фич — на практике классические индикаторы теханализа (RSI, скользящие и т.п.), построенные на основе тех же ценовых рядов, редко дают прирост качества. Современные нейросетевые архитектуры уже умеют извлекать локальные и глобальные паттерны непосредственно из «сырых» OHLCV-данных. Тем не менее, я сторонник экспериментальной проверки: при грамотном комбинировании технических индикаторов и feature engineering вполне возможен прирост точности или устойчивости. Важно не ограничиваться минутными свечами, а рассматривать другие источники данных — например тиковые потоки.

Что касается volume_weighted_average — здесь речь идёт о VWAP (Volume Weighted Average Price). В идеальном случае это считается на тиковом уровне по формуле:

В нашем случае доступны только минутные OHLCV-свечи, поэтому применяется упрощённый вариант — усреднение по (Open, High, Low, Close). Это приближение, которое позволяет хотя бы частично сохранить информацию о «средней цене сделки» в рамках свечи. Если у вас есть доступ к тиковым данным, всегда стоит использовать точный расчёт.

По поводу мониторинга: агент онлайн отслеживает все активные фьючерсные контракты Binance Futures со статусом TRADING. На текущий момент (30.08.2025) это 521 тикер. Действительно, прибыльные возможности возникают преимущественно на волатильных рынках, но фильтрация делается уже на этапе обработки сигналов. Ошибочные входы случаются — их стоимость контролируется встроенным риск-менеджментом. Это обязательный элемент любой продакшен-системы: ошибки неизбежны, но важно, чтобы они стоили кратно меньше, чем приносят прибыльные сделки.

avg_volatility = mean( |Close[i+10] - Close[i]| / Close[i] for i in [t-90 .. t-10] )

Это гарантирует, что волатильность рассчитывается только на 90-минутном предшествующем участке, без захвата импульсного окна.

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

Что касается отбора локальных окон — в проекте предусмотрена гибкая конфигурация: можно менять длину исторического контекста, длительность торговой сессии и набор используемых каналов данных.
Однако сам процесс первичного формирования датасетов (например, под другие биржи или иные условия) действительно остаётся на стороне исследователя: описанная в статье логика легко переносится и может быть реализована в отдельном data layer.

Теперь про 10-минутное окно. Оно не входит в предшествующее 90-минутное окно «тишины». Алгоритм работает так:

1. Сначала скользящим окном ищется 10-минутный отрезок с изменением цены ≥ 5%.

2. Если условие выполняется — мы берём 90 минут, предшествующих началу этого окна, и проверяем их на отсутствие сильных движений (контрастность).

3. Только если обе проверки пройдены — событие фиксируется как сигнал, и формируется финальная 150-минутная сессия (90 мин до + 60 мин после).

Псевдокод:

for each index t in close_prices:
    # проверяем 10-минутное окно на сильный импульс
    change = (Close[t+10] - Close[t]) / Close[t]
    if |change| >= MinAbsChange:

        # считаем среднюю волатильность за 90 минут до начала этого окна
        avg_volatility = mean( |Close[i+10] - Close[i]| / Close[i] for i in [t-90 .. t] )

        if avg_volatility * ContrastCoeff < |change|:
            record signal at time (t+10)

Таким образом, итоговое окно состоит из 90 минут контекста (без резких движений), за которыми следует 60-минутная торговая сессия, начинающаяся сразу после обнаруженного импульса.

Направления для экспериментов:

1. Порог волатильности: ниже — больше сигналов и выше чувствительность, но больше шума; выше — сигналы реже, но чище.

2. Окно волатильности: короче — реакция быстрее, но больше ложных входов; длиннее — меньше шум, но медленнее реакция.

3. Длина сессии: короче — чаще сброс контекста; длиннее — больше истории, полезно для трендов.

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

Команда:

python get_info_from_optuna.py configs/alpha.py --n-best-trials 10

Все результаты автоматически сохраняются в той же папке рядом с файлом исследования: output/cfg_name/optuna_cfg_optimization_results/ —> как best_<N>_trials_<metric>.txt и .csv.

Я не делаю сессионную нормализацию по окну 150 минут. Per-канальные mean/std считаются один раз только по train-сету, фиксируются и применяются к любому наблюдению на val / test / backtest / онлайне. Каждое состояние в момент времени строится каузально из последних минут до ; будущие данные в расчёт не попадают.

Разберем по пунктам:

• Никакой “150-минутной” z-нормализации. Статистики нормализации не считаются «по текущей сессии» и не знают о её пост-сигнальной части. Это базовый продакшн-паттерн: единое масштабирование, замороженное на train.

• Кауза соблюдена. Сначала формирую историческое окно до , затем apply_normalization(...) применяет train-статистики, и только после этого добавляются экстра данные (позиция, unrealized PnL, elapsed/remaining time, one-hot история действий).

• “В реальной торговле таких данных не получить”. Это неверная предпосылка, как раз наоборот: в онлайне используются предварительно посчитанные train-статистики, а не «динамические» stats по текущему окну. Это исключает дрейф масштабирования и исключает leakage.

• Про “отрезание первых 90 минут”. Резать ни в коем случае ничего не надо: stats не считаются по индивидуальному 150-минутному эпизоду в принципе. Даже если искусственно пересчитать mean/std только по первым 90 минутам каждой сессии и перегнать оценку, разница в метриках окажется в пределах статистического шума; выигрыша от такой «локальной» нормализации нет, а стабильность хуже.

• RL ≠ SL. Здесь нет таргетов как в обучение с учителем (возможно именно этот момент вашего опыта в SL пробудил в вас сомнения), которые можно «подсмотреть». Агент видит только историю до , получает reward каузально по шагам, а нормализация выполняет сугубо инженерную функцию — стабилизацию входов под фиксированные train-масштабы.

Дополнительно: для онлайна именно такая схема (фиксированные train‑stats) и применяется в индустрии: она устойчива и корректно переносится в продакшн‑поток без «онлайн‑оценок будущего».

Агент не “покупает по цене из прошлого” — момент принятия решения и входа синхронизированы. Проскальзывание моделирует разрыв между последней сделкой и лучшим bid/ask на момент исполнения, что даёт усреднённо реалистичный результат без необходимости хранения L2/L3 данных.

В реальном исполнении система использует отдельный Execution Layer, который работает по логике, исключающей описанные вами риски:

• Подключение к Binance Futures WebSocket через ThreadedWebsocketManager для получения ценовых данных в режиме высокой частоты.

• Фиксация решения агента о входе → поиск лучшей цены в стакане для лимитного ордера.

• Если лимитный ордер не исполняется в заданный временной интервал — ордер отменяется (_clean_orders()), чтобы избежать входа по невыгодной цене.

• Возможность переключения на рыночный ордер для гарантированного входа, если торговая логика в конкретной стратегии это предусматривает.

Пример кода Execution Layer:

# Инициализация WebSocket
self._web_socket = ThreadedWebsocketManager(
  api_key=cfg.BINANCE_API, 
  api_secret=cfg.BINANCE_SECRET, 
  testnet=cfg.USE_TESTNET
)

# Подписка на поток котировок
self._web_socket.start_kline_futures_socket(
    callback=self._get_update_event_by_stream(ticker),
    symbol=ticker_name,
    interval=KLINE_INTERVAL
)

# Логика ордера
# ...
self._clean_orders()
position_values, prices = self._get_position_values_and_prices(req_pos)
# …выставление нового лимитного ордера по лучшей цене

Таким образом:

• В backtest мы моделируем немедленное исполнение по рынку с параметрами, отражающими усреднённые издержки Binance Futures.

• В боевой системе Execution Layer обеспечивает динамическое размещение и отзыв лимитных ордеров в реальном времени, либо немедленное исполнение по рынку.

• Проблема «зависших» ордеров или исполнения по цене, которая уже ушла, в системе не существует.

Это полноценный инженерный контур исполнения, а не теоретическая модель.

Вопрос “что будет делать агент” в подобных случаях имеет конкретный ответ — он либо обновляет лимитный ордер по лучшей цене, либо отказывается от сделки, либо входит по рынку в зависимости от заложенной политики риска.

Вертикальная пунктирная линия — это момент фиксации высоковолатильного импульса по процедуре, описанной в разделе «Данные» статьи. До этого момента агент не торгует.

В проекте используются минутные котировки OHLCV. Полная свеча за минуту загружается сразу после её закрытия.

Дальнейший алгоритм:

1. Минута закрылась → в систему поступает её OHLCV.

2. Формируется входное состояние из последних N минут истории (в зависимости от конфигурации).

3. Агент принимает решение.

4. При открытии позиции исполнение моделируется по цене закрытия этой же минуты с учётом параметров среды: slippage ±0.05% и taker-fee 0.04%.

В данном примере сигнал был зафиксирован 2025-01-10 08:56 UTC (индекс 10 на оси времени). Вход в позицию происходит по цене закрытия минуты возникновения сигнала ≈ 0.65, скорректированной на проскальзывание и комиссию. Дальнейшее движение до ~0.78 относится уже к последующим минутам удержания позиции.

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

Этот проект не относится к категории «установил и начал зарабатывать». Он изначально задумывался как исследовательская платформа, которая имитирует реальную торговлю с учётом всех ключевых факторов: комиссий, проскальзываний, ограниченной наблюдаемости и меняющихся рыночных условий.

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

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