ARANEA: оптимизации стратегий "Что? Где? Когда?" Часть № 1

 

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




Проще говоря, многие трейдеры и спекулянты начинают не с технического задания, не с гипотезы и не с критериев проверки, а сразу с кнопки оптимизировать. Потом появляется таблица с параметрами, красивая строка с лучшим результатом, график доходности и ощущение, что что-то найдено. Но часто найдено не торговое преимущество, а удачная подгонка под прошлый участок истории.
Поэтому первую статью серии хочу начать с самого простого вопроса: что именно мы оптимизируем. Эта серия написана для думающих людей, а не для тех, кто ищет волшебную настройку индикатора, секретный период EMA или одну кнопку сделать прибыльно. Здесь важны не только методы оптимизации, но и постановка вопроса.
Что оптимизируем: объект оптимизации Самая частая ошибка звучит примерно так: есть стратегия, нужно ее оптимизировать. На первый взгляд все понятно: есть правила, есть параметры, нужно найти лучшие значения. Но если начать задавать уточняющие вопросы, конструкция быстро рассыпается.

Что именно является стратегией: вход, выход, управление позицией, фильтр рынка, диапазон индикаторов или правило выбора результата? Мы сравниваем один лучший показатель или баланс нескольких показателей? Если индикаторов несколько, какой из них важнее? Что важнее в итоговом выборе: PnL, просадка, восстановление после просадки, стабильность сделок или устойчивость соседних параметров?

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

Что является объектом оптимизации

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


— `entry_rules` — точное условие входа в сделку, например формула свечи, уровня и направления;
— `exit_rules` — условия выхода из сделки, чтобы было понятно, где заканчивается идея входа и начинается закрытие позиции;
— `position_management` — правила ведения открытой позиции после входа: trailing, take-profit, stop, временное закрытие;
— `filters` — условия, которые разрешают или запрещают сделку до входа, например EMA-фильтр или фильтр рыночного режима;
— `indicator_ranges` — диапазоны индикаторов, которые реально сравниваются, а не абстрактная фраза подобрать EMA;
— `indicator_priority` — правило, какой индикатор важнее, если несколько фильтров дают разные сигналы;
— `risk_rules` — ограничения по просадке, стопу, серии убытков и минимальному числу сделок;
— `selection_metric` — показатель или формула `score`, по которой выбирается победитель среди вариантов.

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

Разница принципиальная. В первом случае можно сказать: я проверяю чувствительность стратегии к периоду EMA. Во втором случае нужно говорить: я строю карту вариантов стратегии и пытаюсь понять, какие классы решений вообще выживают. Если трейдер не различает эти уровни, он легко обманывает сам себя: думает, что нашел устойчивую стратегию, хотя на самом деле перебрал много степеней свободы и выбрал удачную комбинацию на прошлом участке данных.

Первый вопрос серии звучит так: что именно является объектом оптимизации? Ответ должен быть не хочу больше прибыли, а конкретный список правил, диапазонов, ограничений и критериев отбора.

Техническое задание начинается раньше кода

Представьте, что вы строите дом. Вы же не начнете стройку с вопроса: ИИ, напиши мне техническое задание на дом. Даже если спросите, вы не будете на `100%` слепо следовать первому ответу. Вы будете уточнять площадь, фундамент, материалы, нагрузку, климат, коммуникации, бюджет, сроки, риски, исполнителей и то, как дом потом будет использоваться.

С материалами то же самое. Нельзя просто сказать: постройте хороший дом. Хороший из чего? Для какого региона? На каком грунте? С какой крышей, теплоизоляцией и электрикой? Любая мелочь может потом превратиться в большую сумму. Или хуже — в потерю уже вложенных денег.

Со стратегией все так же, только цена ошибки для трейдера часто выше. Я искренне считаю, что для трейдера ТЗ алгоритма важнее, чем ТЗ на строительство дома. Дом хотя бы виден глазами. А переоптимизированная стратегия может выглядеть красиво в таблице, показывать отличный график и при этом быть полностью нежизнеспособной.

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

ТЗ — это не формальность для программиста. Это способ не обмануть самого себя. В нормальном ТЗ должны быть не только слова купить, когда EMA пересекла EMA, а границы объекта оптимизации:

— что считается сигналом — конкретная формула события, а не описание глазами на графике;
— какие индикаторы используются — полный набор индикаторов, которые участвуют в решении;
— какие диапазоны параметров у каждого индикатора — минимумы, максимумы и шаги перебора;
— как сравниваются несколько индикаторов — правило приоритета, если фильтры конфликтуют;
— что считается выходом — отдельное условие закрытия сделки, не смешанное с входом;
— как ведется позиция после входа — PM-логика, trailing, take, stop и временные правила;
— какие параметры можно менять — разрешенная область исследования;
— какие параметры нельзя трогать — фиксированная часть торговой идеи;
— как считается риск — просадка, стоп, серия убытков и минимальное число сделок;
— что является провалом — условия, при которых вариант отбрасывается независимо от PnL;
— что является приемлемым результатом — минимальные критерии, без которых вариант не проходит дальше;
— по каким признакам стратегия не допускается к торговле — жесткие ограничения до выбора победителя.

ТЗ не гарантирует прибыль. Но оно резко снижает вероятность того, что трейдер будет называть стратегией случайный набор условий, подобранный под прошлое. Без ТЗ оптимизация похожа на поиск ответа без вопроса: машина что-то посчитает, таблица что-то покажет, лучший результат обязательно найдется, но этот результат может не иметь торгового смысла.

Почему лучшая строка не является стратегией

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

Она не отвечает на вопросы, которые важнее самой строки:

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

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

Пример RED-BAR: часть ТЗ на вопрос что

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

Например, возьмем нашу стратегию `RED-BAR`. Этот пример я показывал и разбирал в видео: youtu.be/cTyJZ0mMrl8?si=6MB62urkMq-4ioUb

Если писать часть ТЗ, которая отвечает только на вопрос что оптимизируем, она должна выглядеть не как оптимизировать `RED-BAR`, а намного конкретнее. Такой пример лучше писать не одним длинным списком, а отдельными частями ТЗ, чтобы читатель видел, в какой части исследования находится каждое правило.

Часть ТЗ 1. Объект входа

В этой части спрашиваем: что является входом, а что входом не является. Для `RED-BAR` вход нужно писать формально, потому что без формулы легко начать называть входом все подряд: фильтр, PM, score или удачный участок истории.

Обозначения:
— `O` — цена открытия свечи;
— `C` — цена закрытия свечи;
— `L` — минимум свечи;
— `DayLow` — дневной минимум.

Условие входа `RED-BAR`:
— `O > C` — свеча красная, закрытие ниже открытия;
— `L < DayLow` — минимум свечи прокалывает дневной минимум;
— `C > DayLow` — закрытие возвращается выше дневного минимума.

То есть это не просто красная свеча около минимума. Это конкретная проверяемая логика: внутри свечи был прокол дневного минимума, но закрытие вернулось выше `DayLow`. Именно это является входом. Все остальное — фильтры, PM и метрики — не должны называться входом.

Часть ТЗ 2. EMA-фильтр

В этой части спрашиваем: какие EMA-условия разрешены и какие диапазоны сравниваются. Важно не написать проверить EMA, а указать, какие именно правила участвуют в исследовании и что с чем сравнивается.

Базовое сравнение:
— `Entry` — вход `RED-BAR` без EMA-фильтра, нужен как контрольная точка;
— `Entry + EMA_filter` — тот же вход, но сделка разрешается только при выполнении EMA-условия.

Одиночные EMA:
— `C < EMA(n)`, где `n = 10..100`, шаг `10` — проверяем вход ниже EMA и смотрим, помогает ли фильтр отбирать слабость;
— `C > EMA(n)`, где `n = 100..200`, шаг `10` — проверяем вход выше EMA и смотрим, не лучше ли работает другой контекст.

Парные EMA:
— `EMA_fast(a) < EMA_slow(b)` — контекст, где быстрая EMA ниже медленной;
— `EMA_fast(a) > EMA_slow(b)` — контекст, где быстрая EMA выше медленной;
— `a = 20..120`, шаг `10` — диапазон быстрой EMA;
— `b = 80..300`, шаг `10` — диапазон медленной EMA;
— `a < b` — ограничение, чтобы быстрая EMA действительно оставалась быстрой.

Что сравниваем:
— `Entry` против `Entry + C < EMA(n)` — помогает ли фильтр ниже EMA относительно чистого входа;
— `Entry` против `Entry + C > EMA(n)` — помогает ли фильтр выше EMA относительно чистого входа;
— одиночную EMA против пары EMA — нужен ли второй индикатор или он только добавляет свободу;
— короткие периоды против длинных — не является ли победа следствием слишком узкого периода;
— вклад EMA отдельно от PM — фильтр не должен маскировать слабость управления позицией.

Часть ТЗ 3. Управление позицией после входа

В этой части спрашиваем: каким правилом закрывается позиция после входа. Это отдельная часть ТЗ, потому что вход может быть один и тот же, а результат сделки полностью изменится из-за PM.

PM-семейства:
— `PercentTrailingPct` — stop и take в процентах, простой вариант управления через процентные границы;
— `ParabolicATRStopOnly` — parabolic ATR stop без take-profit, вариант с плавающим защитным выходом;
— `TrailingStopWithATRTake` — trailing stop плюс ATR take, сочетание защиты и целевого выхода по волатильности;
— `TrailingStopWithPercentTake` — trailing stop плюс percent take, сочетание trailing и фиксированной процентной цели;
— `TrailingStopOnly` — только trailing stop без take-profit, проверка сценария, где выход полностью ведется trailing-логикой.

Дополнительные временные выходы:
— `CloseAfter(t) if PnL < 0`, где `t = 10..60` минут, шаг `1` минута — закрываем сделку по времени, если она остается отрицательной;
— `CloseAfter(t) if PnL > 0`, где `t = 10..60` минут, шаг `1` минута — закрываем сделку по времени, если она уже положительная.

Таких вариантов может быть не пять и не двадцать. Можно добавить закрытие через `10..60` минут, разные шаги времени, разные условия по положительному или отрицательному результату, разные take и stop. В ТЗ важно не перечислить все фантазии, а зафиксировать, какие именно семейства и диапазоны разрешены в этом исследовании.

Часть ТЗ 4. Что ищем: метрики, веса и штрафы

В этой части спрашиваем: какой результат считаем лучшим. Не просто где PnL больше, а по какой функции качества выбираем победителя.



Наивный вариант выглядит так: `score = PnL`. Так делают многие. Это нормально как первая проверка, но этого мало: стратегия может показать красивый PnL, плохо восстанавливаться после просадки, иметь длинную серию убытков, зарабатывать одной случайной сделкой или держаться только на одном удачном участке рынка.

Для `RED-BAR` в ТЗ можно зафиксировать базовые 15 метрик поиска:

— `best_pnl` — ищем максимум итоговой прибыли;
— `best_winrate` — ищем максимальную долю прибыльных сделок;
— `best_max_win_streak` — смотрим, есть ли серии прибыльных сделок, а не только одиночный выброс;
— `best_max_loss_streak` — контролируем максимальную серию убыточных сделок, здесь меньше лучше;
— `best_gross_profit` — смотрим суммарную прибыль всех прибыльных сделок;
— `best_gross_loss_abs` — смотрим суммарный убыток всех убыточных сделок по модулю, здесь меньше лучше;
— `best_expectancy` — ищем математическое ожидание на сделку;
— `best_avg_win` — смотрим среднюю прибыльную сделку;
— `best_avg_loss` — смотрим среднюю убыточную сделку, здесь меньше по модулю лучше;
— `best_sqn` — смотрим качество системы через средний результат и разброс сделок;
— `best_profit_factor` — сравниваем валовую прибыль с валовым убытком;
— `best_recovery_factor` — смотрим, насколько прибыль перекрывает максимальную просадку;
— `best_recovery_fix_factor` — смотрим восстановление через более жесткую фиксированную оценку просадки или риска;
— `best_income_per_bar` — смотрим доход на бар, чтобы понимать эффективность времени в позиции;
— `best_payoff_ratio` — сравниваем среднюю прибыльную сделку со средней убыточной.

Метрики нельзя просто сложить как попало. `PnL`, `WinRate`, `RecoveryFactor`, серия убытков и доход на бар живут в разных единицах измерения. Поэтому в ТЗ нужно писать не только список метрик, но и веса.

Вес — это важность метрики в итоговом выборе. Формально это можно записать так: `score = w_pnl * norm(PnL) + w_recovery * norm(RecoveryFactor) + w_profit_factor * norm(ProfitFactor) + w_expectancy * norm(Expectancy) + w_sqn * norm(SQN) + w_income_per_bar * norm(IncomePerBar) — penalties`.

В этой формуле:

— `w_pnl`, `w_recovery`, `w_profit_factor` и остальные `w` — веса метрик, то есть их влияние на итоговый выбор;
— `norm(...)` — приведение метрики к сопоставимому масштабу, например от `0` до `1`;
— сумма основных весов обычно равна `1`, чтобы было видно, как распределяется приоритет;
— если `w_pnl = 0.50`, половина решения отдана итоговой прибыли;
— если `w_recovery = 0.25`, восстановление после просадки влияет на выбор на четверть;
— если вес метрики равен `0`, эта метрика не участвует в выборе победителя.

Пример более честного правила выбора: `score = 0.25 * norm(PnL) + 0.20 * norm(RecoveryFactor) + 0.15 * norm(ProfitFactor) + 0.10 * norm(Expectancy) + 0.10 * norm(SQN) + 0.10 * norm(IncomePerBar) + 0.05 * norm(WinRate) + 0.05 * norm(PayoffRatio) — penalties`.

Штрафы — это отдельные вычитания из `score` за опасные свойства варианта. Они нужны, потому что высокая прибыль не должна автоматически перекрывать плохую просадку, огромный стоп или серию убытков.

Примеры штрафов:

— `penalty_drawdown` — штраф, если `MaxDrawdown > 15%`;
— `penalty_loss_streak` — штраф, если `MaxLossStreak > 5`;
— `penalty_trades` — штраф, если `TradesCount < 3`;
— `penalty_stop` — штраф, если `MaxStopLoss > 12%`;
— `penalty_neighbors` — штраф, если рядом с найденными параметрами нет устойчивых соседних результатов.

Формально штрафы можно записать так: `penalties = p_dd * over(MaxDrawdown, 15%) + p_loss_streak * over(MaxLossStreak, 5) + p_trades * under(TradesCount, 3) + p_stop * over(MaxStopLoss, 12%) + p_neighbors * NoStableNeighbors`.

В этой формуле:

— `over(value, limit)` дает штраф только за превышение лимита;
— `under(value, limit)` дает штраф только если значение ниже минимума;
— `p_dd`, `p_loss_streak`, `p_trades`, `p_stop`, `p_neighbors` — веса штрафов;
— `NoStableNeighbors = 1`, если устойчивых соседей нет, и `0`, если они есть.

Так в ТЗ появляется нормальный ответ на вопрос что ищем. Мы ищем не просто максимальный PnL, а вариант, который зарабатывает, восстанавливается после просадки, не разваливается серией убытков, не держится на одной случайной сделке и проходит ограничения по риску.

Часть ТЗ 5. Разделение вкладов

В этой части спрашиваем: что нельзя смешивать в одну кучу при анализе результата. Даже если после прогона победил один вариант, нужно понимать, что именно победило.

Разделяем вклад:
— сам факт входа `RED-BAR` — проверяем, есть ли смысл у события входа без дополнительных украшений;
— фильтр EMA — смотрим, добавляет ли он качество или просто отрезает неудобный участок истории;
— контекст дневного минимума `DayLow` — понимаем, что вход строится вокруг конкретного уровня;
— PM, который ведет сделку после входа — не позволяем выходу подменить качество входа;
— итоговый `score`, веса метрик и штрафы — отдельно проверяем, не выбрала ли метрика красивый, но опасный вариант.

Даже в таком небольшом фрагменте видно, что вариантов может быть не `5` и не `20`, а сотни и тысячи. Каждый фильтр, каждый диапазон EMA, каждый PM и каждый временной выход умножается на остальные решения. Поэтому в ТЗ нужно писать не проверить EMA и не подобрать выход, а конкретно: какие правила, какие диапазоны, какие условия закрытия и что именно сравниваем.

Если этого нет в ТЗ, потом невозможно честно сказать, что именно улучшило результат. Может оказаться, что сама идея `RED-BAR` слабая, но один EMA-фильтр временно красиво отрезал плохой участок. Или наоборот: вход сильный, а EMA-фильтр только уменьшил количество сделок и случайно поднял итоговый показатель.

Итог
Вот это и есть ответ на вопрос что. Мы не оптимизируем абстрактную стратегию. Мы оптимизируем конкретный набор решений вокруг `RED-BAR`: вход, фильтры, индикаторные диапазоны, управление позицией, риск, веса метрик, штрафы и правило выбора результата.

Когда понятно, что именно мы сравниваем, появляется следующий вопрос: где это сравнивать. Один и тот же набор правил может выглядеть сильным в одном месте и полностью развалиться в другом. Об этом будет следующая статья — `Где оптимизируем`.