Этот сайт лучше всего просматривать в современном браузере с включённым JavaScript.

Нелинейный торговый Brain для MQL5

Dmitry

Задача: собрать из готовых модулей боевую архитектуру на 2026 год.

Я бы строил её вокруг regime-gated Mixture of Experts + прогноз распределения MAE/MFE + отдельный execution veto.

Линейный score можно оставить как диагностический baseline. Главный мозг должен понимать взаимодействия признаков и контекст. Для твоей задачи базовый production-движок я бы делал на GBDT (LightGBM/CatBoost) + ONNX, а нейросетевой анализ последовательности стакана добавлял отдельным экспертом только после накопления качественной L2-истории.

ТЗ: нелинейный торговый Brain для MQL5

1. Общая концепция

Система работает в два этапа:

Haos / внешний быстрый осциллятор

↓

создаёт TradeCandidate

↓

Brain

↓

определяет:

состояние рынка;
качество конкретного сигнала;
наличие continuation / absorption / noise;
ожидаемый MAE;
ожидаемый MFE;
вероятность быстрого follow-through;
качество исполнения;
разрешение сделки;
допустимый SL;
целевой TP.

Главный принцип:

Haos отвечает за момент возникновения идеи сделки.
Brain отвечает за вопрос, стоит ли эту конкретную идею торговать.

—

2. Архитектура Brain

                  HAOS TRIGGER
                       |
                       v
              +----------------+
              | TradeCandidate |
              +----------------+
                       |
                       v
              FEATURE SNAPSHOT
                       |
        +--------------+--------------+
        |              |              |
        v              v              v
   STRUCTURE       VOLATILITY      MOMENTUM
        |              |              |
        +--------------+--------------+
                       |
                       v
                  ORDER FLOW
                       |
                       v
              EFFORT vs RESULT
                       |
                       v
                REGIME GATE
                       |
          +------------+------------+
          |            |            |
          v            v            v
    CONTINUATION   ABSORPTION      NOISE
       EXPERT        EXPERT        / SKIP
          |            |
          +------+-----+
                 |
                 v
           MAE/MFE MODELS
                 |
                 v
          EXECUTION FILTER
                 |
                 v
           DECISION POLICY
                 |
        TRADE / WAIT / REJECT

—

3. Первый уровень: TradeCandidate

Brain запускается только после появления триггера Haos.

На каждом триггере создать объект:

struct TradeCandidate
{
   ulong    time_msc;
   int      direction;       // +1 LONG, -1 SHORT
   double   entry_price;
   double   atr0;
   int      haos_signal_id;
};

Модель должна обучаться именно на событиях Haos.

Не следует обучать её на каждом баре рынка, поскольку задача Brain:

оценить качество уже возникшего торгового сигнала.

—

4. Нормализация направления

Большинство признаков привести к направлению предполагаемой сделки.

Для LONG:

direction = +1

Для SHORT:

direction = -1

Пример:

directional_delta = raw_delta * direction

directional_price_move =
(price_now - price_start) * direction

Тогда:

+ значение = подтверждает сделку
- значение = работает против сделки

Это позволяет основной модели понимать LONG и SHORT в общем пространстве признаков.

При обнаружении устойчивой статистической асимметрии LONG/SHORT оставить возможность использовать два отдельных Expert Model.

—

5. Ось №1. STRUCTURE

Использовать уже существующие модули KDE / Market Profile / S1-R1.

Минимальный набор:

distance_KDE_node
distance_HVN
distance_LVN

distance_S1
distance_R1

distance_next_support
distance_next_resistance

room_in_signal_direction

position_inside_value_area
position_relative_POC

level_strength

number_of_level_tests

distance_to_structure / ATR

Особенно важный признак:

STRUCTURAL_ROOM

Он показывает свободное пространство перед сигналом.

Пример:

Haos LONG
+ сильный импульс
+ positive delta
+ через 2 тика находится мощный R1

Haos LONG
+ тот же импульс
+ та же delta
+ ближайшее сопротивление через 1.3 ATR

должны восприниматься Brain как совершенно разные состояния.

—

6. Ось №2. VOLATILITY / ENERGY

Использовать:

Higuchi FD short
Higuchi FD medium

ATR short
ATR medium

ATR_short / ATR_long

ATR percentile

ATR compression

realized volatility

volatility acceleration

volatility of volatility

Очень полезный признак:

COMPRESSION_RELEASE

Он должен показывать переход:

compression -> expansion

Именно этот переход часто намного полезнее абсолютного ATR.

Higuchi FD желательно считать минимум на двух окнах.

Таким образом Brain сможет различать:

локальный тренд внутри общего шума

реальное изменение структуры движения.

—

7. Ось №3. MOMENTUM

Использовать Haos как часть контекста после возникновения самого триггера.

Признаки:

Haos amplitude
Haos slope
Haos acceleration

distance_from_zero
cross_strength
time_since_cross

spectral_slope

price_velocity
price_acceleration

impulse_duration
impulse_distance

momentum persistence

Особенно полезно хранить:

Haos[t]
Haos slope
Haos acceleration

Поскольку одинаковое значение Haos при ускорении и затухании имеет разный смысл.

—

8. Ось №4. EXECUTION / MICROSTRUCTURE

Основные признаки:

aggressive_buy_volume
aggressive_sell_volume

delta
delta_zscore

cumulative_delta

delta_acceleration

trade_intensity

OFI

bid_ask_imbalance_L1
bid_ask_imbalance_L3
bid_ask_imbalance_L5

microprice_distance

spread

spread_zscore

queue_depletion

queue_replenishment

sweep_volume

sweep_levels

large_trade_intensity

Считать признаки минимум на нескольких горизонтах.

Например:

250 ms
1 sec
3 sec
10 sec

Для более медленной торговли эти интервалы должны задаваться параметрами.

—

9. Effort vs Result

Это должен быть отдельный модуль Brain.

Effort

Пример:

Effort =
signed aggressive volume /
median aggressive volume

Дополнительно:

delta_zscore
trade_intensity_zscore
sweep_volume_zscore

Result

Result =
directional_price_displacement / ATR0

и дополнительный вариант:

ResultTicks =
directional_price_displacement / TickSize

—

10. Market Efficiency

Ввести:

EFFICIENCY =
Result / (abs(Effort) + epsilon)

Высокий Effort + высокий Result:

CONTINUATION

Высокий Effort + почти отсутствующий Result:

ABSORPTION

—

11. Absorption Engine

Абсорбция должна иметь отдельное состояние.

Признаки:

high aggressive volume
high delta
low price displacement
structural level nearby
replenishment
repeated executions
failure to progress
queue persistence

Состояния:

enum ENUM_FLOW_STATE
{
   FLOW_NORMAL,
   FLOW_CONTINUATION,
   FLOW_ABSORPTION,
   FLOW_EXHAUSTION,
   FLOW_UNKNOWN
};

Критически важное правило:

ABSORPTION

не превращать в обычный отрицательный коэффициент score.

При подтверждённой абсорбции:

continuation model -> BLOCK

После этого событие можно передать:

ReversalExpert

При этом ReversalExpert должен иметь собственную статистически проверенную логику входа.

Автоматически переворачивать LONG в SHORT запрещено.

—

12. Regime Gate

Перед основной моделью должен работать классификатор режима.

Выход:

P_CONTINUATION
P_ABSORPTION
P_MEAN_REVERSION
P_NOISE

Например:

0.71 continuation
0.12 absorption
0.05 mean-reversion
0.12 noise

Использовать soft probabilities.

Это лучше жёсткого:

TREND = true

—

13. Рекомендуемая модель Regime Gate

Основной вариант:

LightGBM / CatBoost

Небольшая модель.

Примерно:

20-50 основных признаков

HMM / Markov Switching можно использовать как дополнительный индикатор режима.

Основным Brain я бы HMM не делал из-за:

инерционности;
чувствительности к предположениям распределения;
нестабильности состояния около transitions.

Полезнее передать HMM-state как ещё один признак GBDT.

—

14. Mixture of Experts

После Regime Gate использовать отдельные модели.

Минимум:

ContinuationExpert
Absorption/ReversalExpert

Опционально:

BreakoutExpert
MeanReversionExpert

Каждый Expert видит один и тот же FeatureVector, однако обучается на своей рыночной среде.

Финальный прогноз:

P = Σ P(regime_i) * Expert_i(X)

Можно использовать и hard routing при очень высокой вероятности режима.

Например:

P_absorption > 0.80

↓

ContinuationExpert disabled

—

15. Главный Target

Бинарный:

WIN / LOSS

оставить только вспомогательной метрикой.

Основные targets должны быть другими.

Для каждого TradeCandidate записывать будущую траекторию цены за горизонт H.

—

16. MFE

MFE = maximum favorable excursion

Сохранять:

MFE_ticks
MFE_ATR

—

17. MAE

MAE = maximum adverse excursion

Сохранять:

MAE_ticks
MAE_ATR

Важно:

MAE/MFE сначала хранить в тиках и единицах ATR на момент сигнала.

Это устраняет зависимость обучающей выборки от заранее выбранного стопа.

—

18. First Passage Targets

Дополнительно создать классификационные targets.

Например:

P(MFE >= 0.5 ATR before MAE >= 0.25 ATR)

P(MFE >= 1 ATR before MAE >= 0.5 ATR)

P(MFE >= 1.5 ATR before MAE >= 0.5 ATR)

После выбора базового R:

P(+1R before -0.25R)

P(+1R before -0.5R)

P(+2R before -0.5R)

Это значительно информативнее общего WIN.

—

19. Ideal Entry Target

Отдельно создать:

INSTANT_FOLLOWTHROUGH

Например:

1,
если MFE >= 1R
раньше, чем MAE >= 0.25R

Именно эта модель будет находить твои:

зоны почти нулевого сопротивления.

—

20. Quantile Models MAE/MFE

Использовать Quantile Regression.

Создать отдельные модели:

MFE

MFE_Q20
MFE_Q50
MFE_Q80

MAE

MAE_Q50
MAE_Q80
MAE_Q90

Тогда Brain сможет сказать:

Expected MFE median = 1.6 ATR

80% MAE quantile = 0.28 ATR

90% MAE quantile = 0.42 ATR

Это намного полезнее:

вероятность WIN = 61%

—

21. Финальный ML stack

Production версия:

MODEL 1
RegimeClassifier

MODEL 2
ContinuationProbability

MODEL 3
ReversalProbability

MODEL 4
InstantFollowThrough

MODEL 5
MFE_Q20

MODEL 6
MFE_Q50

MODEL 7
MFE_Q80

MODEL 8
MAE_Q50

MODEL 9
MAE_Q80

MODEL 10
MAE_Q90

10 небольших GBDT работают достаточно быстро.

При необходимости часть моделей можно объединить.

—

22. Decision Engine

Вход разрешается только после выполнения нескольких условий.

Пример:

P_success >= P_MIN

MFE_Q20 >= MIN_MFE

MAE_Q80 <= MAX_MAE

MFE_Q50 / MAE_Q80 >= MIN_ASYMMETRY

ExecutionScore >= MIN_EXECUTION

DriftScore <= MAX_DRIFT

AbsorptionAgainstTrade == false

—

23. Asymmetry Score

Ввести:

ASYMMETRY =
MFE_Q50 /
(MAE_Q80 + epsilon)

Например:

MFE_Q50 = 1.7R
MAE_Q80 = 0.32R

Asymmetry = 5.31

Такой сигнал потенциально намного интереснее:

WinRate = 75%
MFE = 0.6R
MAE = 0.8R

—

24. Expected Utility

Дополнительно считать:

ExpectedUtility =
expected_reward
- expected_risk
- spread
- commission
- expected_slippage
- uncertainty_penalty

Все расходы привести к R.

Например:

EV_R = +0.31R

Trade разрешать при:

EV_R > EV_MIN

—

25. Dynamic Stop

После получения MAE:

SL =
MAE_Q80 + safety_buffer

с ограничениями:

SL_MIN <= SL <= SL_MAX

Можно сравнивать с ближайшей структурой.

Например:

SL_ML
SL_STRUCTURE

и использовать отдельный RiskPolicy.

—

26. Dynamic Target

Аналогично:

TP =
MFE_Q50

либо более консервативно:

MFE_Q20

в зависимости от режима.

Continuation может позволять:

TP = MFE_Q50-MFE_Q80

Mean Reversion использовать более консервативный выход.

—

27. Uncertainty

Brain должен уметь отвечать:

I DON'T KNOW

Нужен:

UncertaintyScore

Минимальный вариант:

disagreement нескольких моделей;
расстояние текущих признаков от training distribution;
экстремальные значения признаков;
недостаточная статистика текущего режима.

Если:

OOD = true

результат:

NO TRADE

—

28. Concept Drift

Рынок меняется.

Нужен DriftMonitor.

Отслеживать:

prediction calibration
MAE distribution
MFE distribution
feature distributions
win probability residual
execution/slippage

Рекомендуется CUSUM / change-point detector на residuals модели.

При сильном drift:

MODEL_DEGRADED

и повышение порога входа либо полная остановка Brain.

—

29. Feature interactions

GBDT сам умеет находить нелинейные взаимодействия.

При этом несколько экономически понятных interaction features стоит передавать непосредственно:

Delta × DistanceToLevel

Effort / Result

HaosStrength × StructuralRoom

Momentum × HiguchiFD

Compression × ImpulseStrength

OFI × StructuralRoom

AggressiveVolume × Replenishment

Не требуется создавать сотни произведений признаков.

—

30. Основной ML алгоритм

Для первой production-версии:

GBDT

Предпочтение:

LightGBM
или
CatBoost

Причины:

идеально подходят для tabular features;
хорошо ловят нелинейные взаимодействия;
работают с разными масштабами;
относительно устойчивы;
быстро обучаются;
быстро исполняются;
легко проводить feature importance / SHAP;
подходят для небольших и средних датасетов.

—

31. Deep Learning слой

Добавлять после накопления качественной L2 последовательности.

Отдельный:

MicrostructureSequenceExpert

Вход:

последние N snapshots стакана
+
последние N trades

Архитектура:

TCN / 1D CNN

или небольшой:

Temporal Transformer

Выход:

P_continuation
P_absorption
P_adverse_selection

Его результат передать основному GBDT/Stacking Engine.

Для первой production-версии Transformer не требуется.

—

32. Итоговый ensemble

Версия Brain 2:

Tabular GBDT
      +
Microstructure Sequence Model
      +
Regime Gate
      |
      v
Calibrator / Meta Model

Последний слой очень небольшой:

logistic regression
или
small GBDT

Он объединяет прогнозы экспертов.

—

33. Что не использовать как основной Brain

Не делать главным механизмом:

weighted score

Также на первом этапе не использовать:

reinforcement learning
large Transformer
LSTM на всём подряд
генетическую оптимизацию сотен коэффициентов

Иначе риск получить красивый backtest при слабом out-of-sample резко возрастает.

RL можно исследовать позднее для исполнения и управления позицией.

—

34. Сбор Dataset

Каждый Haos trigger = одна training event.

В момент t0 сохранить:

event_id
timestamp
symbol
direction

весь FeatureVector

market regime

spread
price
ATR0

model_version
feature_version

После истечения H вычислить:

MAE
MFE
time_to_MFE
time_to_MAE

first barrier reached

instant_followthrough

cost adjusted result

—

35. Multi-Horizon labels

Рекомендую минимум три горизонта:

H_FAST
H_MAIN
H_SLOW

Конкретные значения задаются параметрами стратегии.

Например:

5 sec
30 sec
120 sec

для очень быстрой торговли.

Для баровой системы можно использовать:

1 bar
3 bars
10 bars

Поскольку predictive power Order Flow сильно зависит от горизонта. Исследования микроструктуры также показывают horizon-dependent и regime-dependent поведение order-flow imbalance. (arXiv)

—

36. Train / Validation

Запрещён:

Random Train/Test Split

Использовать:

Walk Forward

Пример:

TRAIN
Jan-Apr

VALIDATION
May

TEST
June

затем:

TRAIN
Feb-May

VALIDATION
June

TEST
July

—

37. Purging

Haos signals часто пересекаются по времени.

Если:

Trade A label horizon

пересекается с:

Trade B

обычная cross validation создаёт leakage.

Поэтому реализовать:

Purged Walk Forward
+
Embargo

Размер embargo минимум соответствует максимальному label horizon.

—

38. Probability Calibration

После обучения:

P = 0.70

должно приблизительно означать:

около 70% подобных событий заканчиваются заданным исходом.

Использовать out-of-fold calibration:

Isotonic Regression

при большом числе наблюдений.

При меньшей выборке:

Platt Scaling

—

39. Метрики

Оптимизировать систему по набору:

Expected R / trade

Median MAE

MAE Q90

Median MFE

MFE Q20

MFE / MAE asymmetry

Profit Factor

Max Drawdown

Tail Loss

Calibration Error

Brier Score

trade frequency

cost sensitivity

WinRate использовать дополнительной статистикой.

—

40. Stress Testing

Обязательно проверять:

spread × 1.5
spread × 2

slippage +1 tick
slippage +2 ticks

entry delay

missing ticks

missing DOM updates

extreme volatility

opening/closing sessions

news spikes

Если edge исчезает от одного дополнительного тика slippage, модель считать непригодной для production.

—

41. MQL5 структура

Предлагаемая архитектура классов:

CTriggerEngine

CFeatureEngine
    CStructureFeatures
    CVolatilityFeatures
    CMomentumFeatures
    COrderFlowFeatures

CEffortResultEngine

CRegimeEngine

CBrainModel

CUncertaintyEngine

CDriftMonitor

CRiskPolicy

CExecutionFilter

CTradeEngine

CEventLogger

—

42. Event flow MQL5

OnTick()

Обновлять:

tick features
delta
trade intensity
velocity
Haos

При появлении Haos:

CreateTradeCandidate()
BuildFeatureVector()
EvaluateBrain()

—

OnBookEvent()

Только быстрые операции:

MarketBookGet()
update L2 buffer
update imbalance
update replenishment
update queue statistics

Тяжёлые расчёты внутри OnBookEvent() запрещены.

Причина особенно важна для MT5: BookEvent может идти очень быстро, а MarketBookGet() возвращает актуальное состояние на момент вызова. Платформа прямо предупреждает, что получить гарантированно все уникальные состояния стакана невозможно. (MQL5)

—

43. Ring Buffer

Для ticks:

TickRingBuffer

Для стакана:

BookRingBuffer

С временными метками:

time_msc

Все microstructure features вычислять относительно этих буферов.

—

44. DOM Recorder

Создать отдельный режим:

MODE_RECORD

Он записывает:

timestamp_msc

Bid/Ask
Last

top N DOM levels

volumes

tick trades

flags

spread

Рекомендуемая глубина:

TOP 10

или

TOP 20

уровней.

—

45. Причина собственного DOM Recorder

MetaTrader хранит историю тиков, включая возможность CopyTicksRange(), однако исторический Depth of Market терминал не хранит. DOM доступен онлайн и отсутствует в обычном Strategy Tester. (MQL5)

Следовательно, для честного backtest:

собственный DOM recorder
        ↓
binary files
        ↓
Replay Engine
        ↓
Strategy Tester

—

46. DOM Replay Engine

Реализовать класс:

CDOMReplay

который читает сохранённые snapshots по:

time_msc

В tester:

LiveMarketBook

заменяется:

RecordedMarketBook

FeatureEngine при этом должен использовать один интерфейс.

То есть:

IDataFeed
   |
   + LiveFeed
   |
   + ReplayFeed

Все формулы признаков должны быть абсолютно одинаковыми live/replay.

—

47. Режимы деградации

Предусмотреть:

FULL_L2
TICK_ONLY
PRICE_ONLY

Для каждого режима использовать подходящую модель.

Если DOM отсутствует, нельзя просто передавать:

imbalance = 0

поскольку ноль является реальным значением признака.

Следует переключить модель:

Brain_FULL_L2.onnx

Brain_TICK.onnx

Brain_PRICE.onnx

либо передавать полноценную missingness mask.

—

48. Python Training Pipeline

MQL5:

сбор данных
+
live inference

Python:

dataset preparation
feature diagnostics
training
walk-forward
calibration
SHAP
model comparison
stress testing
ONNX export

Схема:

MQL5 Recorder
    ↓
Raw Dataset
    ↓
Python
    ↓
Event Dataset
    ↓
Walk Forward
    ↓
GBDT Models
    ↓
Calibration
    ↓
ONNX
    ↓
MQL5

MQL5 официально позволяет обучать модель во внешней среде, экспортировать её в ONNX и выполнять модель непосредственно в терминале. (MQL5)

—

49. Online inference

В EA:

BrainResult result = brain.Evaluate(features);

Результат:

struct BrainResult
{
   double p_continuation;
   double p_reversal;
   double p_followthrough;

   double mfe_q20;
   double mfe_q50;
   double mfe_q80;

   double mae_q50;
   double mae_q80;
   double mae_q90;

   double asymmetry;

   double uncertainty;
   double drift_score;

   int    regime;
   bool   absorption;

   bool   allow_trade;
   int    reject_reason;
};

—

50. Reject Reason

Каждое отклонение сделки обязательно логировать.

Например:

101 LOW_PROBABILITY
102 HIGH_MAE
103 LOW_MFE
104 LOW_ASYMMETRY

201 ABSORPTION
202 STRUCTURAL_BLOCK

301 BAD_SPREAD
302 BAD_LIQUIDITY

401 MODEL_UNCERTAINTY
402 OUT_OF_DISTRIBUTION
403 MODEL_DRIFT

Это критически важно для последующего исследования Brain.

—

51. Logging

Логировать абсолютно каждый Haos signal:

TAKEN

и:

REJECTED

Для rejected сигналов всё равно посчитать будущие:

MFE
MAE

Иначе через несколько месяцев возникнет selection bias и невозможно будет понять, правильно ли Brain блокировал сделки.

—

52. Model Versioning

Каждая модель должна иметь:

MODEL_VERSION
FEATURE_VERSION
TRAIN_FROM
TRAIN_TO
MODEL_HASH

В trade log записывать версию модели.

—

53. Feature parity test

Обязательный unit test.

Для одного и того же market snapshot:

Python features

MQL5 features

должны совпадать.

Допустимая погрешность задаётся для каждого типа признака.

Если feature parity нарушена, live-модель использовать запрещено.

—

54. Lookahead protection

Все признаки вычисляются строго из данных:

time <= t0

Labels:

time > t0

В коде разделить:

FeatureBuilder

LabelBuilder

LabelBuilder никогда не используется в live EA.

—

55. Acceptance Criteria

Первая версия считается готовой, когда выполнены:

Haos создаёт TradeCandidate.
FeatureVector фиксируется строго в t0.
Все четыре оси признаков работают.
Effort vs Result работает.
Absorption может жёстко блокировать continuation.
RegimeGate выдаёт вероятности режимов.
GBDT прогнозирует качество кандидата.
MAE/MFE quantile models работают.
DecisionEngine использует asymmetry.
В расчёт включены spread/slippage/commission.
Все принятые и отклонённые сигналы логируются.
Есть полноценный walk-forward.
Есть purging/embargo.
Есть probability calibration.
Есть stress test.
Есть OOD/uncertainty control.
Есть model versioning.
ONNX работает внутри MT5.
Python/MQL5 feature parity подтверждена.
При ошибке Brain EA переходит в NO_TRADE.

—

56. Порядок разработки

PHASE 1

Создать единый:

FeatureVector

и Event Logger.

—

PHASE 2

Создать Dataset Builder:

Haos event
+
features at t0
+
future MAE/MFE

—

PHASE 3

Обучить первый:

GBDT Meta Model

без DOM sequence network.

—

PHASE 4

Добавить:

Regime Gate
+
Continuation Expert
+
Absorption Expert

—

PHASE 5

Добавить:

MAE/MFE Quantile Models

—

PHASE 6

Перевести DecisionEngine с:

Score

на:

Probability
+
MAE
+
MFE
+
Asymmetry
+
Execution
+
Uncertainty

—

PHASE 7

Создать:

DOM Recorder
+
DOM Replay

—

PHASE 8

Провести полноценный:

Walk Forward
+
Stress Test
+
Ablation Test

—

PHASE 9

Если L2 history показывает дополнительный edge, создать:

MicrostructureSequenceExpert

на TCN/1D-CNN или небольшом Temporal Transformer.

—

57. Ablation Test

Очень важный этап.

Последовательно проверить:

Haos only

Haos + Structure

+ Volatility

+ Momentum

+ Order Flow

+ Effort/Result

+ Regime Gate

+ MAE/MFE

+ Sequence Expert

Для каждого этапа сравнить:

EV
Drawdown
MAE
MFE
Asymmetry
Trade count
stability across periods

Так станет понятно, какой модуль реально приносит edge.

—

58. Финальная production-архитектура

Я бы стремился к следующей системе:

                 HAOS
                   |
                   v
             TradeCandidate
                   |
                   v
         40-70 quality features
                   |
                   v
          Effort vs Result
                   |
                   v
             Regime Gate
                   |
       +-----------+-----------+
       |                       |
       v                       v
Continuation Expert      Reversal Expert
       |                       |
       +-----------+-----------+
                   |
                   v
            MAE/MFE Models
                   |
                   v
        Uncertainty / Drift
                   |
                   v
           Execution Veto
                   |
                   v
             ASYMMETRY
                   |
                   v
             DECISION

Именно эту архитектуру рекомендую считать Brain 1.0 production.

После накопления качественной L2 истории:

Brain 2.0 =
Brain 1.0
+
Microstructure Sequence Expert

Что здесь самое важное

Я бы не пытался сразу кормить одной огромной модели все 150-300 индикаторов, даже если они у тебя уже написаны. Сначала 40-70 хороших признаков, распределённых по твоим четырём осям. Затем ablation покажет, что действительно добавляет информацию.

И я бы сделал центральной целью модели вот эту величину:
[ P(MFE \ge T; before; MAE \ge S \mid X) ]

плюс:
[ Q_{20/50/80}(MFE),\qquad Q_{50/80/90}(MAE) ]
То есть мозг отвечает не «сделка хорошая на 73 балла», а примерно так:

Continuation 81%
MFE median = 1.84R
MFE Q20 = 1.12R
MAE Q80 = 0.31R
MAE Q90 = 0.47R
Asymmetry = 5.9
Absorption = 6%
Execution = OK
Trade = ALLOW

Вот это уже действительно качественно другой класс фильтра.

Ещё один момент по footprint/L2: MT5 позволяет подписываться на стакан через MarketBookAdd() и получать его через MarketBookGet(), но DOM доступен только для инструментов/брокеров, которые его реально поставляют. Причём MQL5 предупреждает, что при очень быстрых обновлениях OnBookEvent не гарантирует получение каждого уникального состояния книги. Поэтому recorder надо делать максимально лёгким. (MQL5)

И мой выбор алгоритмов для первой боевой версии: Haos trigger → GBDT Regime Gate → GBDT Experts → Quantile GBDT MAE/MFE → calibrated decision → execution veto. ONNX позволяет всё это исполнять непосредственно в MT5, без Python в боевом контуре. (MQL5)

А стандартный conformal prediction я пока не делал бы главным фильтром неопределённости: свежий обзор 2026 года отдельно подчёркивает проблему временной зависимости и нарушения exchangeability для time series. Его можно добавить позже в адаптированном online-варианте. (arXiv)

Следующим шагом я бы уже спроектировал конкретный FeatureVector v1 примерно из 50 признаков, прямо по именам переменных для MQL5, с формулами каждого признака и указанием, какие 15-20 из них считать ядром Brain, а какие оставить вторым эшелоном. Это как раз превратит архитектуру выше в непосредственное задание программисту.

Dmitry

1. Самая интересная находка: готовая microstructure-библиотека прямо на MQL5

gregorian-09/mqt-microstructure. Это фактически набор готовых .mqh классов для MT5 под тик-анализ. MIT license. В репозитории уже есть сбор тиков, Tick Rule/Lee-Ready, CVD, VPIN, Kyle Lambda, Amihud, realized volatility, volume profile, regime detector, tick aggregator и исторический player. (GitHub)

mqt-microstructure на GitHub

Для нашей версии без стакана я бы забрал оттуда:

Модуль	Берём сейчас	Для чего
`CMqtTickCollector`	✅	буфер реальных тиков
`CMqtTickRule`	✅	направление тиков
`CMqtLeeReady`	✅*	агрессор buy/sell
`CMqtCumulativeVolumeDelta`	✅*	тик-дельта
`CMqtVPIN`	✅*	токсичность/дисбаланс потока
`CMqtKyleLambda`	✅	Effort → Result
`CMqtAmihudIlliquidity`	✅	сопротивление движению
`CMqtRealizedVolatility`	✅	энергия
`CMqtMicrostructureNoise`	✅	шум
`CMqtTradeDuration`	✅	интенсивность тиков
`CMqtIntensityEstimator`	✅	скорость потока
`CMqtVolumeProfile`	✅*	структура
`CMqtTickAggregator`	✅	tick/volume bars
`CMqtRegimeDetector`	изучить	regime feature
DOM depth	❌	позже
Book resiliency	❌	позже
depth imbalance	❌	позже
настоящий book OFI	❌	позже

Звёздочка означает: качество зависит от того, что твой брокер реально пишет в историю тиков.

—

2. Причём реальные тики MT5 дают нам больше, чем просто цену

MqlTick хранит:

bid
ask
last
volume
volume_real
time_msc
flags

и среди flags существуют:

TICK_FLAG_BUY
TICK_FLAG_SELL
TICK_FLAG_LAST
TICK_FLAG_VOLUME
TICK_FLAG_BID
TICK_FLAG_ASK

То есть если брокер/биржа передаёт торговые тики с BUY/SELL flags, у нас потенциально уже есть историческая классификация сделок без стакана. (MQL5)

И Strategy Tester при режиме Every tick based on real ticks действительно использует брокерскую тик-базу; CopyTicks() позволяет получать историю даже за пределами текущего кеша тестера. (MQL5)

Это надо проверить первым делом

Попроси программиста сделать простой анализатор истории:

Total ticks
Trade ticks
Bid ticks
Ask ticks
Last ticks
Volume ticks
BUY flags
SELL flags
volume_real > 0
last > 0

Например:

EURUSD
ticks                 18,521,441
last ticks                     0
buy/sell flags                 0

FORTS futures
ticks                 32,830,221
last ticks             8,302,151
buy flags              4,102,881
sell flags             4,199,270

Во втором случае возможности Brain будут намного богаче.

—

3. Если BUY/SELL отсутствуют — это всё равно нормально

Тогда используем Tick Rule.

Готовая реализация есть сразу в нескольких открытых проектах.

У mlfinpy формально:

[
b_t =
\begin{cases}
b_{t-1},&\Delta p_t=0\
sign(\Delta p_t),&\Delta p_t\neq0
\end{cases}
]

И дальше строится cumulative tick/volume imbalance. Там уже реализованы tick bars, volume bars и information-driven imbalance bars. (GitHub)

mlfinpy на GitHub

Это как раз хорошо подходит под твою ситуацию.

—

4. Самая интересная замена Order Flow без стакана

Я бы не пытался имитировать DOM.

Вместо него делаем Tick Microstructure Axis:

TICKS
  │
  ├── Tick direction
  ├── Signed volume
  ├── Tick imbalance
  ├── CVD
  ├── VPIN
  ├── Tick intensity
  ├── Price velocity
  ├── Kyle lambda
  ├── Amihud
  ├── Spread
  ├── Bid/Ask dynamics
  └── Effort / Result

И вот тут есть ещё хороший готовый референс: fin-stream.

Он уже реализует из одного потока тиков:

Amihud;
Kyle lambda;
Roll spread;
bid-ask bounce.

Причём Kyle считается как зависимость изменения цены от signed volume. (GitHub)

fin-stream на GitHub

Код Rust нам напрямую не нужен. Формулы и архитектуру можно взять оттуда, а исполнение использовать готовое MQL5 из mqt-microstructure.

—

5. Triple Barrier / Meta-labeling — готовое есть

Тут писать самим почти ничего не надо.

Вариант №1 — FinMLKit

Это, пожалуй, сейчас один из самых интересных открытых проектов именно под нашу архитектуру.

Есть:

raw trades;
volume profile;
footprints;
HVN/LVN/POC;
CUSUM;
Triple Barrier;
Meta Labeling;
concurrency weights;
return attribution weights;
tick/volume/information driven data structures. (GitHub)

FinMLKit на GitHub

Причём концептуально он очень близок к тому Brain, который мы обсуждаем.

Я бы использовал его как основу Python research pipeline.

—

6. Ещё одна готовая база — RiskLabAI

RiskLabAI.py уже содержит:

tick/volume/dollar bars;
imbalance bars;
run bars;
Triple Barrier;
Meta Labeling;
trend scanning;
sample weights;
Purged K-Fold;
Combinatorial Purged CV;
Walk Forward;
feature importance. (GitHub)

RiskLabAI.py

Для нашего проекта особенно важны:

Triple Barrier
Meta Labeling
Purged CV
Embargo
Sample uniqueness

Это я бы практически целиком перенёс в research pipeline.

—

7. Для MAE/MFE нашёл практически готовый labeler

Вот неожиданно подходящий проект:

Broker Data Collector для MT5.

Он уже делает post-event enrichment:

MFE
MAE
MFE ATR
MAE ATR
Future High
Future Low
Bars To High
Bars To Low
Target Hit
Stop Hit
Reward Risk Achieved
Future Return ATR

и специально разделяет будущие labels от decision-time признаков для защиты от leakage. (GitHub)

Broker Data Collector

Но там логика в основном баровая.

Нам нужно сделать то же самое по ticks.

То есть:

Haos trigger
      ↓
entry tick t0
      ↓
scan real ticks t0...tH
      ↓
MFE
MAE
time_MFE
time_MAE
PT_before_SL
MAE_before_MFE

Это небольшой объём работы.

—

8. Higuchi FD тоже уже готов

Есть маленькая открытая реализация именно оригинального алгоритма Higuchi для одномерного временного ряда, включая C-версию. (GitHub)

HiguchiFractalDimension

Нам даже Python не нужен в production.

Алгоритм компактный, поэтому MQL5-программист спокойно переносит формулу в:

CHiguchiFD

и считает:

HFD_32
HFD_64
HFD_128

или на подобранных окнах.

—

9. Regime / structural break

Тут хороший готовый эталон — ruptures.

Библиотека зрелая, около 2k stars, BSD license; реализует PELT, Binary Segmentation и целый набор change-point методов. (GitHub)

ruptures на GitHub

Например:

rpt.Pelt(model="rbf")

находит structural breaks. (GitHub)

Но здесь важный нюанс:

я не стал бы запускать ruptures внутри торгового Brain.

Использовать его следует для исследования:

какие состояния рынка существуют
        ↓
какие признаки меняются при переходах
        ↓
обучаем causal RegimeGate

Потому что большая часть ruptures ориентирована на offline segmentation.

—

10. А вот это почти готовый шаблон именно нашего Brain → MT5

MetaQuotes буквально несколько недель назад опубликовал пример Python AutoML → MQL5 EA → ONNX.

Там:

формируется сигнал;
рассчитываются features;
сделка маркируется profit/loss;
сравниваются:
- LightGBM,
- XGBoost,
- CatBoost,
- Random Forest;
лучшая модель экспортируется в ONNX;
EA получает вероятность качества исходного сигнала;
модель работает непосредственно в Strategy Tester и live EA. (MQL5)

Это практически та же архитектурная задача, которую решаем мы, только у них исходный сигнал EMA crossover, а у тебя:

Haos

И labels у нас будут гораздо правильнее:

MAE / MFE / first passage

вместо обычного Profit/Loss.

Готовый пример AutoML → ONNX → MQL5

Я обязательно дал бы этот проект программисту как reference implementation.

—

Что я в итоге предлагаю собрать

Не искать один огромный готовый «AI trading system».

Берём лучшие части из нескольких проектов.

MQL5

Основой:

mqt-microstructure

Из него:

TickCollector
TickRule
Aggressor classification
CVD
VPIN
Kyle
Amihud
Realized Volatility
Noise
Intensity
Volume Profile
Tick Aggregator

твои:

Haos
KDE
S1/R1
Higuchi
Spectral
ATR

—

Python

Основой:

FinMLKit
+
RiskLabAI/mlfinpy

Оттуда:

Triple Barrier
Meta Labeling
Purging
Embargo
Sample weights
Walk Forward
Feature importance
Imbalance bars

—

ML

Берём подход из последнего примера MetaQuotes:

LightGBM
XGBoost
CatBoost
RF
      ↓
walk-forward comparison
      ↓
best model
      ↓
ONNX
      ↓
MQL5

(MQL5)

—

И я бы даже немного изменил нашу предыдущую архитектуру

На первом этапе Regime Mixture of Experts пока не нужен.

Сначала построить один качественный meta-model:

                     HAOS
                       │
                       ▼
                TradeCandidate
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
   STRUCTURE        ENERGY        MOMENTUM
        │              │              │
        └──────────────┼──────────────┘
                       ▼
              TICK MICROSTRUCTURE
                       │
             ┌─────────┴─────────┐
             ▼                   ▼
      Effort / Result        Regime Features
             │                   │
             └─────────┬─────────┘
                       ▼
                    GBDT
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
    P_GOOD          MAE_Q80        MFE_Q50
        │              │              │
        └──────────────┼──────────────┘
                       ▼
                  ASYMMETRY
                       │
                       ▼
                  TRADE / SKIP

И только если ablation покажет:

одна модель плохо справляется
именно на разных режимах

делаем:

Regime Gate
+
Mixture of Experts

Так будет гораздо сложнее переобучить систему.

—

А самое ценное сейчас — реальные тики позволяют построить Effort vs Result даже без стакана

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

[
Effort =
\frac{|\sum signedVolume|}
{EWMA(|signedVolume|)}
]

а:
[ Result = \frac{|Mid_t-Mid_{t-N}|} {ATR} ]
и:
[ Efficiency = \frac{Result}{Effort+\epsilon} ]
Получается:

Continuation

signed flow     HIGH
price move      HIGH
efficiency      HIGH

Possible absorption / resistance proxy

signed flow     HIGH
price move      LOW
efficiency      LOW

Мы, конечно, без DOM не можем доказать наличие лимитного абсорбера.

Но можем объективно зафиксировать:

было большое направленное усилие, а результат по цене оказался аномально маленьким.

А именно эту аномалию Brain и должен знать.

—

Поэтому мой набор Brain v0.1 без стакана

Я бы оставил около 30–40 признаков:

Structure

KDE distance
HVN/LVN
POC
S1/R1 distance
room_to_level
level_strength

Energy

ATR ratio
ATR percentile
compression
realized volatility
HFD short
HFD long

Momentum

Haos amplitude
Haos slope
Haos acceleration
spectral slope
price velocity
price acceleration

Tick microstructure

tick imbalance
signed volume
CVD slope
CVD acceleration
VPIN
tick intensity
inter-arrival time
Kyle lambda
Amihud
spread
spread percentile
microstructure noise

Interaction

Effort
Result
Effort/Result
Haos × room
flow × room
momentum × HFD

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

И особенно удачно, что большую часть низкоуровневого MQL5-кода уже можно взять из mqt-microstructure, а ML-пайплайн — из FinMLKit/RiskLabAI плюс свежего готового примера MetaQuotes. (GitHub)

Следующим сообщением могу уже сделать тебе конкретное ТЗ программисту BRAIN v0.1 REAL TICKS: какие файлы скачать из этих GitHub, какие классы взять целиком, какие выкинуть из-за DOM, какие 35 признаков считать, формулы каждого и структуру .mqh файлов.

Dmitry

✅ Все три сборки зелёные: Brain_Stage5_CompileTest, MQT_CompileTest, Brain_Stage2_Test → 0 errors, 0 warnings.

Что сделано в этой итерации

1. Точная JJMA-математика ✔

Из вашего Include\SmoothAlgorithms.mqh (Косицын) извлечён и портирован 1:1 алгоритм CJJMA::JJMASeries + JJMAInit → новый самодостаточный Include\Indicators\JJMA.mqh (CJJCMAStream::Process) — все коэффициенты сохранены (PhaseRatio = Phase/100+1.5, Krj, Kfd, degree, Krx, Kct), медианное ядро на 128-элементном отсортированном массиве, фазовая коррекция, warmup-replay 30 баров.
Убрана только бар-механика prev_calculated/save-restore — класс стриминговый (одно значение за вызов), идеально для тиков.
Haos.mqh переключён с EMA на JJMA(7, phase 7) — теперь сигнатура совпадает с вашим Haos_Vol.mq5.

2. Brain_01 изучен полностью ✔

README + все docs + код (NativeFlowEngine, EventTracker, DatasetCollector, ContextAdapter). Понял главное: Stage 5 по вашему роадмапу — это ровно подключение Structure/Energy/Momentum модулей в хуки ContextAdapter, а сторона агрессора берётся из native BUY/SELL флагов (Tick Rule из production исключён).

3. Интеграция Stage 5 выполнена ✔

Файл	Что делает
`Include\Brain\HaosAdapter.mqh`	Реальный триггер вместо заглушки: WPR60/WPR14+JJMA, edge-detect выхода из зон ±30 (машина состояний — `fired=true` ровно один раз на пересечение, как требует INTEGRATION_HAOS.md)
`Include\BrainCore\BrainStage5Context.mqh`	Заполняет все 15 хуков Feature contract v3: POC/HVN/LVN/KDE-distance через `CMqtVolumeProfile`, пивоты S1/R1 от D1, room_to_level, level_strength, atr_percentile (окно 1000), realized_vol, HFD 32/128, spectral OLS-наклон, velocity/accel
`Experts\Brain_Stage5_CompileTest.mq5`	Полный конвейер Stage 5 в каузальном порядке: `tracker.Update → flow.Add → context.OnTick → GetSignal → Freeze features`
`VolumeProfile.mqh`	+ геттеры `MinPrice()/MaxPrice()`
`BrainConfig.mqh`	Мой плотный вектор переименован в `BrainFeatureVector35` (не конфликтует с контрактом v3)

VP наполняется только на native trade ticks (правило Stage 3), с fallback volume_real → tick_volume → 1.

Замечание по интеграции

HaosAdapter теперь реальный в воркспейсовой копии Include\Brain\ — ваш Brain_01\MQL5\Include\Brain я не трогал (там вы работаете параллельно). При следующем синке просто не перезаписывайте воркспейсовую версию старой.

Дальше по плану

Прогнать Brain_Stage5_CompileTest в Strategy Tester (Every tick based on real ticks) — проверить живые значения фичей в журнале.
Собрать полноценный BrainStage5DatasetCollector = ваш Stage 4 коллектор + Stage5Context + реальный Haos → датасет v5 со всеми 15+ полями.
Python-pipeline: purged K-Fold + CatBoost/LightGBM meta-labeling (по SOURCES.md — finmlkit / RiskLabAI как референсы).

Запускайте тест в тестере — если значения в логе адекватные, собираю полный коллектор датасета.

Dmitry

Да. Я бы остановил развитие Stage 6.1 как основной ветки. Он полезен как диагностический эксперимент, но проблема глубже: модель сейчас видит много чисел и почти не видит ситуацию на рынке.

Ваше направление сильнее: сначала описываем рынок языком торговых сетапов, потом ML ищет лучшие сочетания.

У Axia это хорошо видно. Они рассматривают VPOC вместе с открытием относительно value, трендом нескольких дней, экстремумами, momentum, gap, acceptance/rejection. Их логика строится как торговый narrative из нескольких подтверждений. (Axia Futures) Ложный пробой у них тоже рассматривается через ключевой уровень, повторную реакцию, давление участников и дальнейшее поведение цены. (Axia Futures) Order flow у Axia часто выступает уже последним уровнем подтверждения и точности исполнения. (Axia Futures)

Главная цель новой модели

Я бы вообще сменил основной target Stage 6.

ADR5 = средний High-Low предыдущих 5 завершённых торговых дней

TARGET = 0.25 × ADR5

То есть вопрос модели:

Есть ли из этой точки потенциал направленного движения минимум ¼ ADR(5) в сторону сигнала в пределах естественного Haos Cycle, максимум 60 минут?

Строго causal:

ADR5 = только D-1 ... D-5
текущий день в ADR не входит

Основные labels:

y_adr25
    достигли ли +0.25 ADR5

time_to_adr25
    сколько секунд потребовалось

mae_before_adr25
    сколько цена сначала прошла против нас

mfe_60m_adr
    MFE / ADR5

mae_60m_adr
    MAE / ADR5

final_return_adr
    результат в конце Natural Haos Cycle

cycle_duration
    фактическая длина цикла, cap 60m

Именно y_adr25 я бы сделал главным classification target.

—

Что должно попасть в новый Feature Engine

Я бы собрал его примерно так.

Блок	Что модель должна знать
Market Context	тренд/баланс, положение открытия, value, ADR, дневной диапазон
Key Levels	PDH/PDL, PWH/PWL, session H/L, IB, VPOC, VAH/VAL, HVN/LVN, swings
Market Structure	HH/HL/LH/LL, BOS, CHOCH/MSS, displacement
False Breakout	пробой уровня, глубина пробоя, reclaim, скорость возврата
Liquidity	sweep high/low, equal highs/lows, liquidity cluster
Acceptance/Rejection	удержание выше/ниже уровня, время за уровнем, возврат внутрь
BBMA	Extreme, MHV, Re-entry, Momentum, Direction, EMA50, BB state
Smart Money	FVG, OB, mitigation, sweep → displacement → structure shift
Profile/Auction	VPOC rejection, value migration, LVN rejection/fill, excess
Trend Day Context	Initial Balance, open drive, rotations, pullback quality
Effort/Result	большой объём + маленькое движение, absorption, failed effort
Order Flow	delta/CVD, aggression, reversal, intensity, exhaustion
MTF Context	M5/M15/H1 структура, BBMA, Haos, trend
Room to Target	сколько пространства до следующего сильного уровня
Setup State	какой именно торговый сценарий сейчас активен

И это уже будет гораздо ближе к тому, что вы описали.

—

1. Контекст дня

Это сейчас один из самых больших пробелов Brain.

Axia отдельно смотрит на Initial Balance, открытие, value, предыдущий диапазон и тип дня. Например, маленький Initial Balance плюс постепенные push → absorption → новый push может указывать на trend day; быстрый пробой уровня с последующим заполнением LVN больше похож на liquidation move. (Axia Futures)

Я бы добавил:

open_vs_prev_close
open_vs_prev_vah
open_vs_prev_val
open_vs_prev_range

gap_ticks
gap_adr

initial_balance_range
initial_balance_adr

distance_to_pdh
distance_to_pdl
distance_to_pwh
distance_to_pwl

day_range_used
day_range_used / ADR5

position_in_day_range
position_in_prev_day_range

prev_day_trend_score
multi_day_trend_score

day_balance_score
day_trend_score

value_migration_direction
vpoc_migration

Очень важный признак:

remaining_adr_room_directional

Если рынок уже прошёл 90% ADR и Brain хочет движение ещё 25% ADR, вероятность такого сетапа должна сильно отличаться от ситуации, когда использовано 20% ADR.

—

2. Ложные пробои и liquidity sweep

Вот этого нам действительно сильно не хватает.

Нужен механический detector, чтобы ML не пытался самостоятельно восстановить ложный пробой из 15 отдельных чисел.

Например SHORT:

1. Есть заранее известный resistance_level.
2. Цена вышла выше него.
3. excursion_above_level = X ticks.
4. Через N секунд/баров вернулась ниже уровня.
5. Закрепилась ниже.
6. После пробоя было усилие покупателей.
7. Результат покупателей оказался слабым.

Получаем признаки:

sweep_up_active
sweep_depth_ticks
sweep_depth_atr
sweep_depth_adr

seconds_above_level
max_close_above_level
reclaim_speed

distance_after_reclaim
rejection_strength

volume_during_break
delta_during_break
cvd_during_break

effort_result_during_break
absorption_during_break

level_test_count
level_age
level_strength

false_breakout_score

Зеркально для LONG.

Это уже почти готовый торговый паттерн.

—

3. Acceptance / Rejection

Очень важная вещь из auction logic.

Сам факт пробоя уровня мало что значит.

Нужно понимать:

сломали уровень
↓
приняли новую цену?

или

сломали уровень
↓
рынок отказался торговать там?

Признаки:

time_beyond_level
volume_beyond_level
trades_beyond_level

distance_held_beyond_level
retest_count
retest_success

close_back_inside
rejection_velocity

acceptance_score
rejection_score

Это позволит Brain отличать настоящий breakout от liquidity sweep.

—

4. BBMA как отдельная система признаков

Здесь тоже есть хороший материал.

В распространённой реализации BBMA используются Bollinger Bands 20/2, LWMA 5/10 по High и Low, EMA50. Среди состояний есть Extreme, MHV, Re-entry, Direction и Momentum. (MQL5)

Причём сама BBMA сильно опирается на multi-timeframe комбинации. (Scribd)

Я бы встроил полноценный:

BBMAEngine

Он выдаёт на M5/M15/H1:

bb_position
bb_width
bb_width_percentile

ma5_high_position
ma10_high_position
ma5_low_position
ma10_low_position

ema50_distance
midbb_distance

bbma_trend
bbma_momentum
bbma_extreme
bbma_mhv
bbma_reentry
bbma_direction

bars_since_extreme
bars_since_momentum
bars_since_mhv
bars_since_reentry

bbma_sequence_state

А затем MTF:

H1 reentry + M15 extreme
H1 trend + M15 reentry
M15 direction + M5 reentry
H1/M15/M5 alignment

Это уже очень хороший материал для CatBoost/LightGBM.

—

5. Smart Money Concepts

Здесь я бы не копировал названия вслепую. Термины SMC довольно свободно трактуются разными авторами.

Мы зададим строгие математические определения.

Например:

Liquidity Sweep
BOS
CHOCH / MSS
Displacement
FVG
Order Block
Mitigation
Premium / Discount
Equal Highs/Lows

Типичная SMC последовательность выглядит как liquidity sweep → displacement → structure shift → retracement/FVG/OB. Такая комбинация действительно широко используется в SMC-подходах. (Quantum Algo)

Пример FVG:

bullish:
low[0] > high[2]

bearish:
high[0] < low[2]

Дальше:

fvg_size
fvg_size_atr
fvg_age
fvg_fill_pct
fvg_distance
fvg_direction
fvg_with_displacement

Order Block:

последняя противоположная свеча
перед displacement
который вызвал подтверждённый break swing

И признаки:

ob_distance
ob_size
ob_age
ob_test_count
ob_mitigation_pct
ob_displacement_strength
ob_caused_bos

—

6. Effort versus Result

Вот это я бы сохранил и сильно расширил.

Принцип очень правильный:

EFFORT высокий
RESULT маленький

Важен только контекст, где это произошло.

Например:

на PDH
на PDL
на VPOC
на LVN
на swing high
на liquidity sweep
на BB extreme

То есть вместо одного:

effort_result_conflict

появятся:

ER_at_resistance
ER_at_support
ER_after_sweep
ER_on_breakout
ER_on_retest
ER_at_vpoc
ER_at_extreme

Вот здесь текущая native MT5 tape станет очень полезна.

—

7. Volume Profile / Market Profile

Наш StructureEngine уже даёт хорошую базу, но сейчас уровни используются слишком плоско.

Axia прямо показывает, что VPOC становится полезным именно в сочетании с контекстом: open, trend, prior balance, excess, momentum и acceptance. (Axia Futures)

Добавить:

distance_to_vpoc
vpoc_rejection
vpoc_acceptance
vpoc_cross_count

value_area_position
value_area_reentry

hvn_acceptance
hvn_rejection

lvn_break
lvn_rejection
lvn_fill

profile_shape
profile_balance

prominent_vpoc
value_shift_up/down

poor_high
poor_low
excess_high
excess_low

Последние четыре можно сделать приближённо из доступных данных.

—

8. Haos тоже меняет роль

Я бы перестал заставлять весь Brain смотреть рынок только в момент Haos zero-cross.

Haos остаётся важным:

Haos zero-cross
Haos slope
Haos acceleration
Haos extreme
Haos cycle age
Haos MTF alignment

Но генераторов candidate events должно быть несколько:

HAOS_CROSS

LEVEL_TOUCH
LEVEL_BREAK
LEVEL_RECLAIM

LIQUIDITY_SWEEP

BBMA_REENTRY
BBMA_EXTREME
BBMA_MOMENTUM

BOS
CHOCH

VPOC_REJECTION

BREAKOUT_RETEST

ABSORPTION_AT_LEVEL

Это фундаментальное изменение.

Иначе мы можем написать идеальный detector ложного пробоя, но dataset увидит его только тогда, когда рядом случайно произошёл Haos cross.

—

Как должен работать новый Brain

Мне видится такая цепочка:

MARKET CONTEXT
      ↓
IMPORTANT LOCATION
      ↓
SETUP DETECTOR
      ↓
PRICE ACTION CONFIRMATION
      ↓
EFFORT / RESULT
      ↓
ORDER FLOW CONFIRMATION
      ↓
ROOM FOR 0.25 ADR5
      ↓
ML
      ↓
P(move >= 0.25 ADR5)

Вот это уже выглядит как модель торговых сценариев.

Микроструктура остаётся внутри системы, но занимает примерно 15–25% признаков.

Основной объём информации должен идти из:

context
location
structure
setup
multi-timeframe
acceptance/rejection

—

Я бы сделал следующий этап так

STAGE 6.2: STRATEGY CONTEXT ENGINE

Примерная структура:

Include\Brain\
├── MarketContextEngine.mqh
├── KeyLevelEngine.mqh
├── MarketStructureEngine.mqh
├── FalseBreakoutEngine.mqh
├── LiquidityEngine.mqh
├── AcceptanceEngine.mqh
├── BBMAEngine.mqh
├── SmartMoneyEngine.mqh
├── AuctionProfileEngine.mqh
├── EffortResultEngine.mqh
├── SetupEngine.mqh
└── StrategyFeatureVector.mqh

И я бы не ограничивал новый набор 64 признаками.

На исследовательской стадии разумнее:

150–250 осмысленных признаков

потом ablation + SHAP + correlation pruning сократят их до рабочего набора.

Самое важное: каждый признак должен отвечать на понятный торговый вопрос.

Например:

Где рынок?

Какой сейчас режим?

Возле какого уровня?

Что произошло на уровне?

Пробой приняли или отвергли?

Кто приложил усилие?

Был ли результат?

Как ведёт себя старший TF?

Есть ли свободное пространство для 0.25 ADR5?

С таким датасетом уже имеет смысл серьёзно возвращаться к ML.

Dmitry

1. Тестер запускаем на M5, остальные TF считаем внутри

M5 делаем базовым временным каркасом, но EA продолжает работать на каждом тике.

BASE_TF = M5

Контекст:
M5
M15
H1
H4

Дополнительно:
D1
W1

Сам график тестера M5 никак не запрещает получать H1/H4/D1. iCustom() принимает конкретный timeframe, а iBarShift() позволяет определить бар любого TF по времени события. (MQL5)

Более того, ваш BBMA-dashboard уже настроен на M1/M5/M15/H1/H4/D1/W1.

То есть семь отдельных прогонов тестера нам не нужны.

—

2. Но есть очень важная проблема H1/H4

Предположим событие произошло:

10:37

H1-свеча 10:00–10:59 ещё формируется.

Если исторически взять её уже готовые:

High
Low
Close
BB
EMA
Haos

мы потенциально увидим данные из 10:38–10:59.

Это утечка будущего.

В вашем dashboard это уже частично правильно решено: функция находит TF-бар по времени события и при режиме closed-bar переходит на предыдущий полностью завершённый бар.

Для Brain я предлагаю сделать лучше.

Для каждого TF хранить две версии

Например H1:

H1_CLOSED
последняя полностью закрытая H1

H1_ASOF
формирующаяся H1 ровно до момента события

Если событие в 10:37:

H1_CLOSED = 09:00–09:59

H1_ASOF =
Open 10:00
High 10:00–10:37
Low  10:00–10:37
Close = цена в 10:37
Volume 10:00–10:37

H1_ASOF мы сами агрегируем из M5/ticks.

То же самое:

M15_ASOF
H1_ASOF
H4_ASOF
D1_ASOF

Так мы получим настоящий MTF-контекст.

—

3. То есть M5 становится нашей «истиной времени»

Архитектура:

                     EVENT TIME
                         |
        +----------------+----------------+
        |                |                |
       M5               M15              H1
        |                |                |
       H4               D1               W1
        |
   exact AS-OF state

Например событие:

2026.05.14 10:37:24.550

Brain спрашивает каждый TF:

Что было известно рынку
именно в 10:37:24.550?

Не:

Как потом закрылась эта свеча?

Это принципиально.

Ваш dashboard уже анализирует старшие TF сверху вниз, чтобы младшие получили готовый higher-TF context. Эту идею стоит перенести в Brain.

—

4. Дневной Volume Profile тоже можем восстановить

И здесь я бы вообще не использовал M5 OHLC для профиля.

У нас фьючерсы и реальные exchange ticks.

MT5 предоставляет исторические ticks через CopyTicksRange(), включая Last, volume и флаги BUY/SELL. В режиме тестирования на реальных тиках тестер также позволяет получать тики за исторический диапазон. (MQL5)

Поэтому строим собственный:

DailyProfileEngine

Из реальных сделок:

price
volume_real
BUY/SELL
time

—

5. Нужны два дневных профиля одновременно

Previous Day Profile

Он полностью известен в начале нового дня:

PD_POC
PD_VAH
PD_VAL

PD_HVN1
PD_HVN2
PD_HVN3

PD_LVN1
PD_LVN2
PD_LVN3

PD_ProfileHigh
PD_ProfileLow

PD_profile_shape

И расстояния:

dist_PD_POC
dist_PD_VAH
dist_PD_VAL
dist_PD_HVN
dist_PD_LVN

Developing Day Profile

Например событие в 13:15:

только сделки
session_open → 13:15

Получаем:

D_POC_asof
D_VAH_asof
D_VAL_asof

D_HVN_asof
D_LVN_asof

POC_migration
VAH_migration
VAL_migration

Это уже настоящий auction context.

—

6. Профиль не надо пересчитывать с нуля каждый сигнал

Иначе tester станет очень медленным.

Делаем histogram:

price level       volume
--------------------------------
2345.0            821
2345.1            940
2345.2           1602
2345.3           3144  <-- POC
2345.4           2210
...

На каждом новом trade tick:

profile[price_index] += volume_real

То есть developing profile обновляется почти бесплатно.

При смене торгового дня:

current_profile
      ↓
previous_profile

current_profile = empty

Границы торговой сессии можем брать через SymbolInfoSessionTrade(), которое возвращает торговые интервалы конкретного инструмента. (MQL5)

—

7. Самое интересное: мы можем построить собственный Footprint

И вот тут AXIA становится значительно реалистичнее.

У нас уже есть:

TICK_FLAG_BUY
TICK_FLAG_SELL
Last
volume_real

Значит можно для каждого price level считать:

sell_aggressive_volume | buy_aggressive_volume

Например:

2345.4       37 | 142
2345.3       28 | 311
2345.2       19 | 487
2345.1      163 |  44

Это уже footprint-like структура из реальных сделок.

—

8. Из этого появляются нормальные AXIA-признаки

Например diagonal imbalance:

ask_volume[p]
---------------- > threshold
bid_volume[p-1]

Можно считать:

imbalance_ratio
stacked_imbalance_levels
max_imbalance
imbalance_volume
imbalance_price

Zero prints

Можно определить:

buy_volume_at_extreme == 0
sell_volume_at_extreme == 0

или практически:

volume <= минимального порога

Dark cluster

Не надо пытаться определить «цвет».

Формализуем:

volume_at_price percentile >= 95%

Получаем:

high_volume_cluster = true
cluster_volume_zscore
cluster_volume_percentile

—

9. Reloading мы напрямую не видим

Это единственное серьёзное ограничение AXIA.

Исторического DOM у нас нет.

Поэтому:

large resting limit order → отмена → новая заявка

восстановить нельзя.

Но можно обнаружить его следствие.

Reloading proxy

Например:

одна price zone
+
5+ повторных атак
+
очень большой aggressive volume
+
цена проходит <= 1–2 ticks
+
после каждой атаки возвращается

Признаки:

barrier_test_count
aggressive_volume_into_barrier
price_progress_per_100_volume
max_penetration_ticks
reclaim_count
reclaim_speed
time_at_barrier

Это очень близко к вашему:

усилие большое, результата нет.

—

10. Я бы сделал Effort/Result центральным движком

Не одну feature.

Отдельный:

EffortResultEngine

Например:

Effort

aggressive_volume
delta
trade_count
trade_rate
stacked_imbalance
large_cluster_volume

Result

price_displacement
ticks_progress
close_location
acceptance_distance
time_beyond_level

И:

effort_result_ratio

Пример:

BUY aggression = 1500 contracts
price advance  = 1 tick

→ extreme effort / almost zero result
→ possible SELL absorption

Это уже AXIA.

—

11. Ваши 10 AXIA-модулей можно формализовать единым контрактом

Это очень хорошая часть вашего описания.

Для каждого модуля делаем строго:

struct StrategyState
{
   bool context;
   bool mechanics;
   bool footprint;
   bool entry;
   bool stop;
   bool cancellation;

   bool valid;

   int direction;

   double score_context;
   double score_mechanics;
   double score_footprint;
   double score_entry;
};

И:

valid =
context
AND mechanics
AND footprint
AND entry
AND stop
AND !cancellation

То есть правило AXIA сохраняем.

—

12. Но для ML обязательно записываем и Invalid

Это очень важно.

Если писать в CSV только:

AXIA1_VALID

модель никогда не увидит, почему сетап не сработал.

Нам нужны:

axia1_context
axia1_mechanics
axia1_trigger_1
axia1_trigger_2
axia1_trigger_3
axia1_entry_ready
axia1_stop_valid
axia1_cancel
axia1_valid

И численные значения:

axia1_aggression
axia1_price_result
axia1_absorption
axia1_reversal_imbalance
axia1_retest_distance
...

Тогда ML сможет обнаружить, например:

AXIA1 формально Invalid

НО

PDL
+ H1 discount
+ huge absorption
+ M15 BBMA extreme
+ liquidity sweep

→ 67% случаев дали 0.25 ADR

Вот ради этого ML нам и нужен.

—

13. Поэтому жёсткое правило AXIA и ML друг другу не мешают

Будут два слоя.

Strategy Engine

Отвечает:

AXIA1 VALID
AXIA2 INVALID
AXIA3 VALID
...

ML

Получает всю внутреннюю механику:

context
levels
profile
BBMA
SMC
footprint
effort/result
AXIA states

И уже ищет сочетания.

—

14. Haos больше не главный генератор событий

Полностью согласен.

Нужен:

CandidateEventEngine

Источники события:

HAOS_ZERO_CROSS
HAOS_EXTREME

BBMA_EXTREME
BBMA_REENTRY
BBMA_MOMENTUM
BB_EXPANSION
BB_SQUEEZE_BREAK

LIQUIDITY_SWEEP_HIGH
LIQUIDITY_SWEEP_LOW

PDH_TOUCH
PDL_TOUCH
VAH_TOUCH
VAL_TOUCH
POC_TOUCH
LVN_TOUCH

SWING_BREAK
BOS
CHOCH

FAILED_BREAK
RECLAIM

ABSORPTION
STACKED_IMBALANCE
EXHAUSTION

RANGE_BREAKOUT

Событие может иметь несколько триггеров одновременно:

trigger_mask =
LIQ_SWEEP
+ PDL
+ BBMA_EXTREME
+ ABSORPTION

Вот это уже очень интересная строка для ML.

—

15. Мы не обязаны даже заранее знать «стратегию»

Например происходит:

PDL sweep
M15 Extreme
H1 bullish
current D_VAL
seller delta = huge
price stops falling
stacked BUY imbalance appears

В CSV это просто объективные свойства.

А потом ML может выяснить:

эта комбинация →
P(0.25 ADR5) = 0.71

И только потом мы дадим ей имя.

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

—

16. Цель я бы теперь окончательно отвязал от Haos

Primary target:

y_adr25_60m

Условие:

цена достигла
+0.25 × ADR(5)

в направлении candidate event

за <= 60 минут

Дополнительно:

time_to_adr25
mae_before_adr25
mfe_60m_adr
mae_60m_adr

Haos cycle можно оставить отдельным признаком:

haos_cycle_age
haos_cycle_direction
haos_cycle_end_time

Но target теперь универсальный.

Это позволяет сравнивать:

BBMA
AXIA
SMC
Haos
Sweep
Breakout

одной мерой.

—

17. Что из ваших AXIA 1–10 реально получить

AXIA	Исторически реализуемо
1 Absorption	Да, хорошо
2 Elephant	Частично, reloading через proxy
3 Failed Break	Да
4 Auction Imbalances	Да
5 Exhaustion	Да
6 Initiative Drive	Да
7 Key Auction Reversal	Да
8 Breakout	Да
9 Delta Position Unwind	Да
10 Risk Event	частично, как shock/volatility regime

То есть 8–9 из 10 мы можем сделать весьма близко к исходной логике.

—

18. Я бы теперь построил Stage 6.2 именно так

STAGE 6.2A — Historical Context Engine

AsOfTimeEngine
MTFEngine
SessionEngine
DailyProfileEngine
FootprintEngine
KeyLevelEngine

STAGE 6.2B — Pattern Engines

LiquidityEngine
BBMAContextEngine
SMCEngine
EffortResultEngine
AcceptanceEngine
BreakoutEngine

STAGE 6.2C — AXIA Modules

Axia01Absorption
Axia02Elephant
Axia03FailedBreak
...
Axia10RiskEvent

STAGE 6.2D — Event Collector

CandidateEventEngine
        ↓
freeze market snapshot
        ↓
M5/M15/H1/H4
        ↓
daily profile
        ↓
footprint
        ↓
BBMA / SMC
        ↓
AXIA1..10
        ↓
target 0.25 ADR5 / 60m

—

И я бы начал именно с инфраструктуры, а не сразу с AXIA1

Первый контрольный результат должен выглядеть примерно так:

event_time
direction
trigger_mask

M5_state
M15_state
H1_state
H4_state

PDH PDL
PD_POC PD_VAH PD_VAL
D_POC D_VAH D_VAL

nearest_HVN
nearest_LVN

sweep_high
sweep_low

aggressive_buy_volume
aggressive_sell_volume
delta
stacked_buy_imbalance
stacked_sell_imbalance
absorption_buy
absorption_sell

ADR5
day_range_used
room_to_adr25

y_adr25_60m
time_to_adr25
mae_before_adr25

Когда эта историческая база будет causal и проверена, поверх неё AXIA1–10 становятся уже сравнительно простой формализацией.

И главное: для этого достаточно одного запуска Strategy Tester на M5 в режиме real ticks. M15/H1/H4/D1 становятся внутренними временными представлениями одного и того же рынка, а footprint и дневной профиль восстанавливаются из потока сделок. (MQL5)

Я считаю, это сейчас правильная точка для разворота проекта: сначала Stage 6.2A, MTF + Daily Profile + Footprint + Event Bus; ML пока не трогаем.