1. Среднее время жизни сделок / горизонт

Внутридневной, краткосрочный. Горизонт измеряется в свечах (не в абсолютном времени), а таймфрейм всегда минутный, поэтому 1 свеча = 1 минута.

1. Среднее время жизни сделок / горизонт

Внутридневной, краткосрочный. Горизонт измеряется в свечах (не в абсолютном времени), а таймфрейм всегда минутный, поэтому 1 свеча = 1 минута.

— В генерируемых системах длину сделки сверху ограничивает ген MaxDurationCandles ∈ {60, 120, 240, 480, 960, 1920} свечей — то есть 1 / 2 / 4 / 8 / 16 / 32 часа (жёсткий предел ×1.5, дефолт — 8 часов). Но это верхняя граница: большинство сделок закрывается заметно раньше по trailing-стопу.
— Живой пример (бот на Bybit, 9 719 закрытых сделок): медиана удержания ~1 час, среднее ~4.6 ч (среднее перекошено редкими многодневными «хвостами»). 55% сделок закрываются за час, 87% — за 4 часа, 95% — за ~14 часов.

Итог: скальпинг-внутридневной диапазон, максимум ~1–2 суток.

2. 640 бинарных признаков — это «кусочки стратегии»? Вход и выход собираются независимо?

Не совсем. ~636–640 бинарных флагов — это словарь только для условий ВХОДА (бинарные предикаты состояния рынка, вычисленные из 19 индикаторов: RSI, ATR, MACD, Bollinger, ADX, DeepExtremum и т.д.). Стратегия = подмножество этих флагов, объединённых по AND-логике, как правило входа.

Выход флаги не использует вообще. Это отдельный параметрический механизм trailing-стопа: 5 дискретных параметров (начальный стоп, макс. длительность, шаг сужения, закрытие на конце дня / выходных) — всего 2520 комбинаций.

Вход и выход эволюционируют раздельно (скрещивание и мутация обрабатывают флаги и exit-параметры отдельно), но оцениваются всегда вместе — PnL сделки зависит и от входа, и от выхода, отдельно «вход без выхода» не измерить.

3. TOPSIS и HRP «с очисткой» — про то, что попадёт в портфель? Есть кластеризация по корреляции?

Да, это отбор в боевой портфель, в два модуля:

— Селектор (индивидуальный отбор): фильтрация (Sharpe OOS, покрытие инструментов, число сделок, защита от переобучения по decay IS→OOS, сложность) → ранжирование (TOPSIS или взвешенная сумма) → дедупликация по схожести флагов (Jaccard) → диверсификация (лимит алгоритмов на инструмент, баланс бирж) → корреляционный фильтр (убирает более слабого из пары с высокой корреляцией equity-кривых).
— Комбинатор (портфель): HRP (Hierarchical Risk Parity, Лопес де Прадо) — да, тут кластеризация по корреляции присутствует по построению: корреляционная матрица → расстояние → иерархическая кластеризация (дендрограмма) → квазидиагонализация → рекурсивное деление весов по обратной дисперсии. Плюс Score-Weighted HRP — веса домножаются на качество системы.

4. Минутный ТФ — все стратегии только на нём, или это база для старших ТФ?

Только минутка (M1), везде. Загрузка данных жёстко на 1m (Binance interval=1m, MOEX M1), enriched-данные и весь конвейер Loader→Researcher→Trader — на M1. Механизма агрегации 1m→старшие ТФ в коде нет — минутка не база для построения старших, а единственный используемый таймфрейм. Живой бот тоже на M1 (tf=1min).

5. Части стратегии используют один индикатор — расчёты готовятся заранее или считаются заново при переборе?

Заранее, полностью. Индикаторы считаются один раз в Загрузчике и сохраняются как упакованные битовые флаги в Parquet-файлы в S3 (640 флагов в ulong[], 80 байт на свечу). Генетический поиск индикаторы не пересчитывает вообще — воркер читает готовые флаги один раз на задачу и для каждой особи генома гоняет по ним побитовые маски (AND). Никакого пересчёта формул в переборе нет, плюс внутрипроцессный кеш (одна загрузка на файл). Проблема «дублирующихся расчётов одного индикатора» тут в принципе не возникает.

6. Воркер тянет историю из БД — успевает ли БД отдавать на множество воркеров?

Историю воркер берёт не из SQL, а из S3 (Parquet). SQL-сервер историю не отдаёт вообще — он используется только для координации (атомарный захват одного задания, один короткий UPDATE на задачу) и каталога флагов (один SELECT на процесс, кешируется). Каждый под грузит свою историю из S3 один раз за всю задачу (не на эпоху и не на генома). Поэтому БД — не узкое место при десятках-сотнях воркеров; потенциальное узкое место (если возникнет) — это S3 при холодном старте пода, а не SQL. Масштаб — до ~120 подов (KEDA).