Нейросети в трейдинге: Унифицированное смешивание признаков для торговых решений (UniMixer)
136
0
Введение
В большинстве прикладных решений на финансовых рынках нейросети по-прежнему используются как инструмент прогнозирования направления движения цены, величины доходности или уровня волатильности. Звучит логично, но в реальной торговле этого недостаточно. Цена может пойти в нужную сторону и при этом не дать ни нормального входа, ни разумного выхода. В итоге модель угадывает, а счёт — нет.
Проблема здесь глубже, чем кажется. Рынок — не просто временной ряд. Это система, в которой постоянно взаимодействуют десятки факторов: волатильность, ликвидность, объём, спред, фаза сессии, состояние самого счёта. Цена — итог этого взаимодействия. Когда модель смотрит только на последовательность баров, она фактически пытается угадать результат, не разбираясь в причинах.
На этом фоне всё больше внимания привлекают архитектурные решения, которые работают иначе. Они не зацикливаются на времени как на главной оси, а пытаются моделировать взаимодействие признаков. Одной из таких архитектур является фреймворк UniMixer, представленный в работе "UniMixer: A Unified Architecture for Scaling Laws in Recommendation Systems". Его идея достаточно прагматична: не выбирать между механизмами внимания, MLP или моделями факторизации, а рассматривать их как разные способы одного и того же процесса — смешивания признаков. И уже внутри модели комбинировать эти способы в зависимости от решаемой задачи.
Если перевести это на язык трейдинга, получается довольно понятная картина. Важен не сам по себе индикатор или цена. Важно, что происходит, когда рост волатильности совпадает с расширением спреда и снижением ликвидности. Или когда импульс возникает на фоне тонкого рынка. Такие комбинации формируют ситуации, которые трейдеры называют хорошими точками входа. UniMixer как раз и нацелен на выявление таких взаимодействий.
Отсюда вытекает важное следствие: если смотреть на рынок через взаимодействие признаков, то задача модели меняется. Речь уже идет не о прогнозировании ценового движения, а об оценке существования осмысленного торгового действия в конкретный момент времени и его параметрах. Объём позиции, уровни тейк-профита и стоп-лосса, допустимый риск — это становится частью единого решения, а не набором внешних правил.
При этом важно сохранять трезвый взгляд. Финансовый рынок — далеко не идеальная среда для сложных моделей. Данные шумные, закономерности нестабильны, а переобучение поджидает на каждом шагу. Любая попытка перенести архитектуру из другой области, пусть даже успешную, требует серьёзной адаптации. В противном случае модель будет выглядеть убедительно только на истории.
Поэтому объём работы по переносу идей UniMixer в трейдинг объективно выходит за рамки одной статьи. Здесь недостаточно просто взять архитектуру и обучить модель. Нужно переосмыслить входные данные, аккуратно выстроить представление признаков, определить, как учитывать состояние счёта и открытые позиции, и только после этого переходить к полноценному проектированию и построению модели.
В рамках данной статьи мы сознательно ограничим задачу: наша цель — заложить фундамент. Мы познакомимся с ключевыми принципами UniMixer, разберём, как они могут быть интерпретированы в контексте финансовых рынков, сделаем первый практический шаг. Дальнейшее развитие будет логичным продолжением этой работы и темой следующей публикации.
Алгоритм UniMixer
Авторы фреймворка UniMixer строят свою работу вокруг простой, но сильной идеи — вместо выбора одного правильного подхода (механизма внимания, TokenMixer или метода факторизации), они объединяют их в рамках единой теоретической конструкции. По сути, речь идёт о попытке собрать разные школы под одной крышей и заставить их работать согласованно.
Если посмотреть на архитектуру в целом, она состоит из трёх основных модулей. Сначала выполняется токенизация признаков — каждый входной фактор преобразуется в эмбеддинг, формируя набор Feature-токенов. Далее следует стек из M блоков UniMixer. В них важную роль играют два конструктивных элемента: Siamese-нормализация и механизм Sparse-PerToken MoE (разреженная смесь экспертов на уровне отдельных токенов).
Здесь стоит сделать небольшое уточнение. Уже на этом этапе видно, что модель изначально проектируется как масштабируемая система обработки признаков, и каждый токен может обрабатываться по-своему. Для финансовых рынков это звучит особенно интересно: разные факторы (волатильность, объём, спред) по своей природе неоднородны, и единый способ обработки для них часто оказывается слишком грубым.
Возвращаясь к архитектуре, центральным элементом является сам UniMixer-блок. В его основе лежит так называемый параметризованный Rule-Based TokenMixer. Звучит академично, но идея практическая. Этот механизм устанавливает мост между разными типами моделей:
- Attention-подходами, которые хорошо ловят глобальные зависимости;
- TokenMixer-модулями, эффективно перемешивающими информацию между признаками;
- методами факторизации, ориентированными на явные взаимодействия.
В результате UniMixer не выбирает один из подходов, а наследует сильные стороны каждого из них. Модель может одновременно учитывать глобальные зависимости, строить нелинейные комбинации признаков и явно моделировать их взаимодействия. В контексте рынка это выглядит как попытка объединить чтение контекста, локальную логику и жёсткие факторные связи в одном вычислительном блоке.
Отдельного внимания заслуживает механизм Sparse-PerToken MoE. Он позволяет для каждого токена (то есть для каждого признака) динамически выбирать, какие эксперты будут участвовать в его обработке. Иными словами, модель не применяет одну и ту же трансформацию ко всем данным, а адаптируется к их типу и текущему состоянию. Рынок не всегда живёт по одним и тем же правилам, и модель должна уметь переключаться между режимами.
Первый этап обработки данных — формирование входного представления модели. Здесь сырые признаки превращаются в токены, готовые к дальнейшему смешиванию в UniMixer-блоках. Этот шаг важен, потому что здесь закладывается логика понимания моделью структуры данных и взаимосвязи признаков.
Авторы фреймворка предлагают сначала разнести все анализируемые признаки по семантическим доменам. Модель не смешивает всё в один массив, а разделяет логически связанные группы признаков. Для трейдеров аналогия очевидна. Вместо плоского окна цен выделяем:
- рыночные данные: open, close, high, low, объёмы;
- технические индикаторы: RSI, MACD, ATR и др.;
- состояние счёта: баланс, equity, открытые позиции;
- контекст времени и сессии.
Далее каждый домен признаков проходит через собственный embedding-слой:
en = Embedding(Xdomain) ∈ Rd domain
Каждая группа признаков получает своё пространство представления.
После этого все доменные эмбеддинги объединяются в единый вектор.
E = [e1, e2, …, eN]
Но пока это плоский вектор — без структуры, пригодной для смешивания признаков. С целью придания формы вектор делится на равные блоки. Каждый блок проходит собственное линейное преобразование и превращается в токен.
xi = WiprojEdi:di+d + biproj ∈ RD
Важно подчеркнуть, что каждый токен получает свою проекцию. Модель фактически смотрит на одну и ту же информацию под разными углами. В контексте финансов это очень полезно. Один токен может усиливать влияние волатильности, другой — ликвидности, третий — взаимосвязей между ценой и индикаторами.
Все токены собираются в матрицу X ∈ RT×D, где T — количество токенов, а D — их размерность. Эта матрица и становится входом для UniMixer-блоков, в них выполняется смешивание токенов, выявление зависимостей и построение абстрактного представления состояния рынка.
Этот этап превращает разнородный набор признаков в структурированное пространство токенов, с которым модель умеет работать. Для трейдинга это как собрать карту рынка. Каждый токен — это отдельный взгляд на состояние рынка, а UniMixer потом учится соединять эти взгляды в целостную картину.
Следующий шаг — прохождение токенов через UniMixer-блоки. На этом этапе модель учится выявлять сложные зависимости между токенами, а в финансовом контексте — между различными рыночными индикаторами, ценами и состоянием счёта.
Авторы UniMixer отмечают типичную проблему модулей гетерогенного внимания. При вычислении внимания между разными семантическими пространствами используют токен-специфичные веса для Query, Key и Value. На практике это часто приводит к диагонально доминирующему паттерну. На ранних этапах обучения, со случайно инициализированными весами WQh и WKh, величина коэффициента внимания в основном определяется входными значениями токенов X. В результате внимание концентрируется на ограниченном числе токенов. Модель смотрит только на несколько признаков, игнорируя остальной контекст. Такой перекос снижает информативность модели и увеличивает затраты на обучение, вызывая проблемы с распространением градиентов ошибки.
С другой стороны, заданный правилами TokenMixer обладает высокой детерминированностью, но не умеет подстраиваться под данные. Он либо слишком ограничен в выборе паттернов взаимодействия, либо может формировать ошибочные связи между токенами. В задачах трейдинга это критично. Рынок динамичен, и фиксированные правила взаимодействия признаков часто не отражают текущую картину движения цен.
Авторы UniMixer предлагают интересный выход — параметризовать TokenMixer, превратив фиксированное перестановочное преобразование в обучаемое. Формально это выглядит так:
TokenMixer(X) = Reshape(W•Flatten(X)),
где Wperm — большая матрица перестановок, а Flatten(X) — сплющенный вектор входных токенов.
Идея понятна: позволить модели учиться смешивать токены, а не полагаться на жёсткие правила. Но тут возникает практическая проблема: вычислительная сложность O(T²D²) и количество параметров O(T²D²) становятся неприемлемыми. Авторы фреймворка UniMixer тщательно проанализировали структуру матрицы Wperm и выделили свойства, позволяющие сильно сократить количество параметров, заменив её на матрицы G и I меньшего размера.
При таком подходе остаются три технических вызова:
- Прямое использование параметризованных G и I создаёт промежуточную матрицу огромного размера [TD, TD], что сильно нагружает GPU.
- Нужно гарантировать, что обучаемые параметры соблюдают свойства двойной стохастичности, разреженности и симметрии.
- Следует спроектировать унифицированный модуль масштабирования, который объединяет преимущества существующих подходов и обеспечивает высокую эффективность работы модели.
Для решения указанных вызовов вместо работы с абстрактными размерами T и D, вводится более практичная схема. Весь входной вектор длины L разбивается на блоки фиксированного размера B. Тогда количество блоков — L/B. Это выглядит как чисто технический шаг, но на деле — ключевой. Он делит задачу на два уровня:
- локальные взаимодействия внутри блока,
- глобальные взаимодействия между блоками.
Если перевести это на язык трейдинга, то внутри блока — локальная логика, а между блоками — более широкие зависимости. Далее вводятся два типа параметров:
- WBi — для локального смешивания внутри блока,
- WG — для глобального смешивания между блоками.
Важная деталь: каждый блок получает собственный набор весов WBi. Это означает, что разные части входа обрабатываются по-разному. В условиях рынка это особенно ценно. Поведение цены и индикатора — это разные по природе процессы. Пытаться смешивать их одинаково — плохая идея.
Формально UniMixer записывается как:
UniMixer(X) = Reshape((WG ⊗ {WBi}) Flatten(X)),
где ⊗ — обобщённое произведение Кронекера.
Смысл простой:
- сначала обрабатываем данные локально,
- затем собираем их в глобальную структуру.
Чтобы сделать вычисления практичными, авторы фреймворка предлагают оптимизированный процесс вычислений. Сначала входной вектор разбивается блоки xi размером B. Далее каждый блок проходит через своё преобразование:
xi → xiWBi
В результате получаем набор локально обработанных представлений H. И только после этого применяется глобальное смешивание.
UniMixer(X) = Reshape(WG • H)
С инженерной точки зрения это сильное решение. Вместо громоздкой матрицы Wperm размером [L × L] мы получаем:
- локальные операции O(LB),
- глобальные операции O(L²/B).
Итоговая сложность O(L²/B + LB), что уже выглядит вполне разумно. Если перевести это на практику, получается здравый смысл:
- сначала разберись, что происходит локально,
- потом пытайся понять глобальную картину.
Дальше авторы UniMixer добавляют важные ограничения на параметры. Чтобы матрицы не разъехались в процессе обучения, вводятся:
- симметрия: (W + WT)/2,
- положительность и нормировка через итерации Sinkhorn-Knopp,
- температурный коэффициент τ управляет разреженностью.
На практике это означает, что модель учится строить структурированные, устойчивые взаимодействия, а не хаотичные связи между признаками.
Финальный шаг — стандартный, но важный.
O = RMSNorm(X + UniMixer(X))
Остаточные связи сохраняют исходную информацию, а нормализация стабилизирует обучение.
Теперь — короткий, но важный взгляд со стороны трейдинга. Вся эта конструкция фактически реализует идею: рынок — это не один сигнал, а система взаимодействий на разных масштабах. Локально — внутри набора связанных факторов, глобально — между разными группами факторов. И UniMixer даёт инструмент, который:
- не зажимает модель в жёсткую структуру,
- не уходит в хаос,
- остаётся вычислительно управляемым.
Это уже механизм, который учится смешивать факторы рынка.
Авторы фреймворка UniMixer показывают, что архитектура сводит разные классы моделей к единой логике взаимодействия признаков. В качестве отправной точки рассматриваются архитектуры взаимодействия признаков на базе моделей факторизации. Её ядро — это обычное попарное взаимодействие признаков через скалярные произведения. Каждый фактор смотрит на все остальные, и модель оценивает силу их взаимозависимости. Это хорошо знакомая логика, она проста, интерпретируема и часто даёт стабильный результат, где важны конкретные сочетания признаков.
Далее следует важное наблюдение: если в Attention зафиксировать WQ и WK как единичные матрицы, а Value сделать независимым от входа, то механизм вырождается в модель факторизации. В таком случае Attention фактически вырождается в модель факторизации. Иными словами, внимание — это не отдельный класс методов, а частный случай той же идеи взаимодействия признаков. Это тот момент, где теория начинает складываться в единую картину.
На этом фоне становится понятным основной ход мысли авторов фреймворка UniMixer. Они объединяют три подхода — Attention, TokenMixer и модели факторизации — в одну общую конструкцию. В центре оказывается простая, но ёмкая идея: любое взаимодействие признаков можно разложить на два уровня. Первый — локальный, признаки обрабатываются внутри своих групп. Второй — глобальный, здесь происходит взаимодействие между этими группами.
В терминах UniMixer:
- сначала каждый блок признаков проходит своё преобразование, формируя локальные паттерны,
- затем применяется глобальное смешивание, которое определяет, как эти паттерны связаны между собой.
И вот здесь кроется ключевое различие между подходами. В Attention и моделях факторизации глобальное взаимодействие зависит от самих данных — модель оценивает схожесть состояний. В TokenMixer оно фиксировано и не зависит от входа — это заранее заданная схема. UniMixer оставляет за собой право использовать оба варианта и комбинировать их.
Если перевести это на практический язык трейдинга, картина становится довольно наглядной. Иногда рынок действительно ведёт себя по шаблону — и тогда фиксированная логика работает лучше. Иногда важно уловить сходство с предыдущими ситуациями — здесь выигрывает Attention. А иногда решающую роль играют конкретные сочетания факторов — классическая задача для моделей факторизации. В реальной торговле все эти сценарии возникают одновременно, и попытка выбрать один правильный подход обычно заканчивается потерей части информации.
Именно здесь UniMixer выглядит особенно уместно. Он не заставляет модель делать выбор заранее. Вместо этого он даёт ей инструмент, позволяя самой определить, какой тип взаимодействия сейчас более релевантен. Модель учится не только находить зависимости, но и выбирать способ их описания.
Формула, объединяющая разные подходы, — это не столько теоретическое обобщение, сколько практическая рамка. Она позволяет смотреть на модель как на систему, в которой отдельно управляются локальные и глобальные взаимодействия. Это разделение даёт ту гибкость, которой обычно не хватает при работе с рынком.
Однако не всё, что хорошо в теории, так же хорошо на практике. Проблема, с которой сталкиваются авторы фреймворка, вполне инженерная. Уменьшение размера блоков, на которые разбивается анализируемая последовательность, приводит к росту числа локальных матриц WBi. И увеличивается глобальная матрица WG. Модель начинает не столько учиться, сколько перепроизводить однотипные паттерны. Локальные взаимодействия дублируются, а глобальная часть разрастается без заметного выигрыша в качестве.
Решение элегантное — вместо хранения отдельной матрицы для каждого блока вводится набор базисных матриц {Zl}. А для каждого блока обучается не сама матрица, а лишь вектор коэффициентов wi, который задаёт комбинирование базисов. В таком варианте модель перестаёт изобретать велосипед для каждого блока и начинает собирать нужные паттерны из ограниченного набора строительных элементов. Это резко снижает число параметров и одновременно добавляет устойчивости.
С глобальной частью поступают аналогично прагматично. Вместо полной матрицы WG используется её низкоранговое приближение, где ранг r существенно меньше исходной размерности. Это означает, что глобальные взаимодействия теперь описываются не напрямую, а через более компактное представление. С точки зрения вычислений — огромная экономия, без критической потери выразительности.
Вся конструкция в итоге собирается в знакомый вычислительный конвейер. Сначала каждый блок проходит через своё, теперь уже базисно-собранное, локальное преобразование. Затем применяется глобальное смешивание через низкоранговую матрицу, после чего результат возвращается в исходную форму и проходит через остаточную связь с нормализацией.
Отдельно сохраняется важный момент — все матрицы проходят через процедуру нормализации Sinkhorn-Knopp. Это обеспечивает положительность, нормировку и структурированность взаимодействий. Модель по-прежнему учится не хаотичным связям, а упорядоченным схемам взаимодействия.
UniMixer-Lite — зрелый компромисс между гибкостью и эффективностью. Он сохраняет способность Attention учитывать контекст и зависимость от входа, структурированность TokenMixer и факторную природу взаимодействий. При этом убирает главный недостаток сложных моделей — избыточную параметризацию.
В контексте финансовых рынков это выглядит особенно разумно. Слишком тяжёлая модель чаще вредит, чем помогает. Идея с базисами и низким рангом фактически навязывает модели дисциплину. Она не может бесконтрольно усложнять зависимости, а вынуждена искать устойчивые комбинации факторов.
После формирования результатов UniMixer (или UniMixer-Lite), модель не останавливается на линейном смешивании признаков. Следующий шаг — добавить нелинейность и управляемую фильтрацию сигналов. Здесь авторы фреймворка предлагают использовать модифицированный вариант SwiGLU — PerToken SwiGLU.
Каждый токен проходит через два параллельных преобразования:
- первое Wup формирует содержательное представление сигнала,
- второе Wgate через функцию Swish играет роль гейта, то есть регулирует, какую часть информации пропустить дальше.
Затем эти два потока перемножаются поэлементно. Это ключевой момент: модель не просто усиливает сигнал, а модулирует его, подавляя одни компоненты и усиливая другие. После этого результат сжимается обратно через Wdown, возвращаясь к исходной размерности.
PerToken SwiGLU работает как интеллектуальный фильтр. Не вся информация после смешивания одинаково полезна. Модель учится это различать на лету. В финансовом контексте это особенно важно. После этапа UniMixer у нас уже есть набор взаимодействий между факторами. Но часть из них может быть случайным шумом, следствием переобучения или просто нерелевантной в текущем рыночном режиме. Вот здесь pSwiGLU начинает играть роль второго слоя здравого смысла. Он позволяет модели:
- гасить слабые или нестабильные сигналы,
- усиливать устойчивые комбинации факторов,
- адаптироваться к текущему состоянию рынка через гейт-механизм.
Отдельно стоит обратить внимание, что параметры Wiup, Wigate, Widown задаются на уровне отдельных токенов. Это означает, что каждый токен обрабатывается по-своему.
Связка UniMixer и pSwiGLU делает архитектуру избирательной. А в задачах трейдинга это критично. Найти сигнал — половина дела, вторая половина — не поверить шуму.
Далее авторы UniMixer переходят к ещё одной практической проблеме, с которой рано или поздно сталкивается любая архитектура — углубление модели. Теоретически всё просто: добавляем больше слоёв — получаем более сложные зависимости. На практике же всё быстро упирается в нестабильность обучения.
Для улучшения масштабируемости модели авторы фреймворка вводят механизм SiameseNorm, который решает фундаментальное противоречие между Pre-Norm и Post-Norm схемами. Обычно приходится выбирать: либо стабильность градиентов, либо выразительность модели. Здесь авторы пытаются получить и то, и другое.
Идея на удивление элегантная. Вместо одного потока данных в каждом слое используются два связанных потока Xl и Yl. Оба они инициализируются одинаково.
X0 = Y0 = X
Дальше начинается интересное. На каждом слое происходит обновление в два шага:
- Нормализуется поток Y.
- Формируется выход блока UniMixer.
Ol = UniMixer(Xl + RMSNorm(Yl))
Обратите внимание: один поток подаётся как есть, второй — через нормализацию. Уже здесь появляется баланс между сырым сигналом и стабилизированным.
Далее оба потока обновляются, но по-разному:
Xl+1 = RMSNorm(Xl + Ol)
Yl+1 = Yl + Ol
В итоге модель как будто ведёт две бухгалтерии: одна аккуратная и строгая, другая — более свободная и накапливающая опыт.
На последнем слое оба потока объединяются.
Xoutput = XM + RMSNorm(YM)
Это даёт итоговое представление, в котором сочетаются устойчивость, через нормализованный поток, и накопленные взаимодействия, через второй поток.
Аналогия для трейдинга довольно живая. У нас есть:
- консервативный взгляд на рынок — аккуратный, сглаженный, без резких скачков;
- агрессивный, который запоминает все изменения и реагирует быстрее.
Работать только с одним из них — рискованно. Первый может опаздывать, второй — перегибать. А вот их комбинация даёт гораздо более устойчивую картину.
С инженерной точки зрения SiameseNorm решает ключевую задачу: позволяет углублять модель без потери устойчивости обучения. Градиенты не рассыпаются, а полезный сигнал не подавляется чрезмерной нормализацией.
Для финансовых задач это особенно важно. Глубокая модель — это возможность уловить сложные зависимости между факторами. Но без устойчивого обучения она превращается в генератор шума. SiameseNorm выступает тем механизмом, который удерживает баланс.
Реализация средствами MQL5
После детального разбора архитектуры UniMixer становится ясно: перед нами универсальный механизм работы с признаками и их взаимодействиями. Однако теория, какой бы изящной она ни была, в трейдинге сама по себе ценности не имеет. Здесь всё решает практика — как эти идеи ложатся на реальные рыночные данные.
На этом этапе переходим к практической части работы. Сразу обозначим важный момент: речь не идёт о полном переносе оригинальной архитектуры как есть. Такой подход в условиях финансовых рынков, как правило, не работает. Данные имеют другую природу — распределения нестабильны, а требования к устойчивости модели значительно выше, поэтому наша задача — адаптировать, сохраняя ключевые принципы UniMixer.
Фактически мы начинаем с построения фундамента. Нас интересует, как переложить базовую логику архитектуры — токенизацию признаков, их последующее смешивание и формирование взаимодействий — на язык рыночных данных. При этом особое внимание уделяется структуре входного представления и организации признаков, поскольку именно здесь закладывается большая часть будущего качества модели.
В рамках данного проекта рассмотрим один из возможных вариантов такой адаптации. Он не претендует на единственно верное решение, но позволяет выстроить рабочую схему. На её основе можно последовательно развивать модель: усложнять архитектуру, уточнять признаки и переходить к полноценному тестированию.
Двигаясь по пути прохождения информации внутри модели, логично начать с самого первого этапа — токенизации исходных данных. Именно здесь формируется то представление, с которым дальше будет работать архитектура.
Если внимательно посмотреть на предложенный авторами подход, становится заметно его сходство с уже реализованным объектом CNeuronUnifiedTokenizer. Мы имеем ту же идею: привести разнородные исходные признаки к единому, структурированному пространству эмбеддингов, пригодному для дальнейшей обработки.
Однако есть и принципиальное отличие, на котором стоит остановиться. В UniMixer после формирования общего вектора эмбеддингов выполняется разделение сплюснутого вектора на блоки с последующей независимой проекцией каждого блока. Каждый токен формируется как результат отдельного обучаемого преобразования.
Это выглядит как небольшая деталь, но на практике меняет многое. В классическом подходе токены часто являются либо прямыми эмбеддингами признаков, либо их фиксированными комбинациями. Здесь же каждый блок получает собственную матрицу параметров, через которую модель учится “смотреть” на данные под разными углами.
Получается интересный эффект. Один и тот же набор рыночных признаков может быть представлен в нескольких проекциях ещё до того, как начнётся основное смешивание в UniMixer.
С инженерной точки зрения это даёт важное преимущество. Мы сохраняем уже отработанную и понятную логику CNeuronUnifiedTokenizer, но добавляем к ней дополнительный уровень гибкости. Токенизация перестаёт быть просто этапом подготовки данных и начинает играть активную роль в формировании признакового пространства.
От теории — к коду. Создаем новый объект CNeuronUniMixerTokenizer, который наследуется от CNeuronFieldAwareConv. Это выглядит вполне закономерно. Нам нужен механизм, который уже на этапе токенизации учитывает их структуру и потенциальные взаимодействия.
class CNeuronUniMixerTokenizer : public CNeuronFieldAwareConv { protected: CNeuronUnifiedTokenizer cTokenizer; //--- virtual bool feedForward(CNeuronBaseOCL *NeuronOCL) override; virtual bool updateInputWeights(CNeuronBaseOCL *NeuronOCL) override; virtual bool calcInputGradients(CNeuronBaseOCL *NeuronOCL) override; public: CNeuronUniMixerTokenizer(void) {}; ~CNeuronUniMixerTokenizer(void) {}; //--- virtual bool Init(uint numOutputs, uint myIndex, COpenCLMy *open_cl, uint &dimensions[], uint units, uint embed_size, uint blocks, uint candidates, uint topK, ENUM_OPTIMIZATION optimization_type, uint batch); //--- virtual bool Save(const int file_handle) override; virtual bool Load(const int file_handle) override; //--- virtual int Type(void) override const { return defNeuronUnifiedTokenizer; } virtual void SetOpenCL(COpenCLMy *obj) override; virtual void TrainMode(bool flag) override; //--- virtual bool WeightsUpdate(CNeuronBaseOCL *source, float tau) override; };
Ключевой момент — внутри объекта используется уже знакомый нам CNeuronUnifiedTokenizer. Мы не переписываем базовую механику, а используем проверенное решение как фундамент. Это важный инженерный выбор. В трейдинге, как и в хорошем ремесле, новые инструменты не строят с нуля, если старые уже доказали свою надёжность.
Метод инициализации превращает архитектурную идею в конкретную конфигурацию вычислений.
bool CNeuronUniMixerTokenizer::Init(uint numOutputs, uint myIndex, COpenCLMy *open_cl, uint &dimensions[], uint units, uint embed_size, uint blocks, uint candidates, uint topK, ENUM_OPTIMIZATION optimization_type, uint batch) { if(blocks <= 0 || embed_size <= 0 || units <= 0 || (embed_size*units) % blocks != 0) ReturnFalse;
Первое, что делает метод — это жёсткая валидация параметров. Логика предельно прагматична — мы сразу отсекаем ситуации:
- нет блоков → нечего токенизировать,
- нет эмбеддингов или признаков → нечего обрабатывать,
- общий размер embedding-пространства не делится на блоки.
Последнее условие — не формальность. Оно гарантирует, что разбиение будет строго равномерным, без хвостов и перекосов. В контексте UniMixer это критично. Вся дальнейшая логика построена на симметрии блоков.
Далее рассчитывается размер блока.
uint block_size = (embed_size * units) / blocks;
Здесь фактически получаем один токен = один блок фиксированного размера. То есть общее пространство признаков (все эмбеддинги по всем признакам) разворачивается и делится на равные сегменты. Это прямое соответствие теоретической части UniMixer.
Следующий шаг — инициализация родительского класса.
if(!CNeuronFieldAwareConv::Init(numOutputs, myIndex, open_cl, block_size, block_size, units * blocks, (block_size + 3) / 4, candidates, topK, optimization_type, batch)) ReturnFalse;
Вот здесь начинается самое интересное. Мы используем CNeuronFieldAwareConv как вычислительную основу, но конфигурируем его не совсем стандартно:
- вход и выход заданы как block_size → block_size,
- количество каналов: units * blocks.
Фактически мы превращаем слой в механизм, который применяет отдельное преобразование к каждому блоку без введения отдельного класса под каждую проекцию. Всё укладывается в уже существующую инфраструктуру OpenCL — аккуратно и без лишнего усложнения.
Далее инициализируется базовый токенизатор.
if(!cTokenizer.Init(0, 0, OpenCL, dimensions, units, embed_size, candidates, topK, optimization, iBatch)) ReturnFalse; //--- return true; }
Здесь важно правильно понимать архитектуру:
- cTokenizer отвечает за формирование исходных эмбеддингов признаков,
- родительский класс — за их разбиение и проекцию в токены UniMixer.
То есть у нас получается двухступенчатая схема:
- Признаки → эмбеддинги (старый, проверенный механизм).
- Эмбеддинги → токены с независимыми проекциями (новая логика UniMixer).
Это очень аккуратное решение. Мы не ломаем старый поток вычислений, а надстраиваем над ним новый уровень представления.
В терминах трейдинга это можно описать просто:
- Приводим рынок к единому языку (эмбеддинги).
- Разбиваем его на смысловые фрагменты (блоки).
- Даём модели возможность смотреть на каждый фрагмент по-своему.
И именно индивидуальная проекция блоков создаёт ту гибкость, ради которой и затевался весь переход к UniMixer.
Метод прямого прохода получился предельно лаконичным. Вся сложность уже спрятана в конфигурации слоёв. На уровне кода — всего 2 вызова. Но по сути здесь реализуется вся цепочка, о которой мы говорили теоретически.
bool CNeuronUniMixerTokenizer::feedForward(CNeuronBaseOCL *NeuronOCL) { if(!cTokenizer.FeedForward(NeuronOCL)) ReturnFalse;
Сначала cTokenizer формирует базовые эмбеддинги признаков. Сырые рыночные данные проецируются в структурированное embedding-представление. Это уже знакомый и проверенный этап. Здесь модель учится понимать отдельные признаки.
Далее происходит ключевое действие средствами родительского класса.
if(!CNeuronFieldAwareConv::feedForward(cTokenizer.AsObject())) ReturnFalse; //--- return true; }
Здесь реализуется формирование токенов с независимыми матрицами проекции. Важно понимать, что это не отдельный цикл по блокам и не явное разбиение в коде. Всё уже закодировано в параметрах, заданных в методе инициализации. Каждый сегмент embedding-вектора проходит через свою линейную проекцию. Это и есть токенизация в духе UniMixer.
CNeuronUniMixerTokenizer формирует токены через правильно настроенную геометрию слоя. Это как хороший станок: снаружи — одна кнопка, внутри — сложная механика.
В контексте нашей задачи это даёт сразу несколько преимуществ:
- минимальный overhead — нет лишних операций,
- высокая производительность на OpenCL,
- корректное соответствие оригинальной идее UniMixer.
Дальше уже эти токены пойдут в UniMixer-блоки, где начнётся основной анализ взаимодействий.
Заключение
Мы прошли путь от теоретической конструкции UniMixer до её первых практических очертаний в контексте финансовых рынков. Разобрав исходную архитектуру, увидели, что за внешней сложностью скрывается стройная идея — разделение взаимодействий на локальный и глобальный уровни с возможностью гибкого управления ими. Это именно тот подход, которого давно не хватало моделям, работающим с разнородными рыночными признаками.
Ключевой акцент практической части был сделан на построении фундамента. Мы не пытались сразу воспроизвести всю архитектуру целиком. Такой путь в задачах трейдинга чаще приводит к переусложнению без реального выигрыша. Вместо этого реализована базовая, но важная часть — механизм токенизации, адаптированный под логику UniMixer. Объект CNeuronUniMixerTokenizer стал связующим звеном между существующим потоком обработки признаков и новой архитектурой. Он формирует токены с независимыми проекциями и тем самым закладывает основу для последующего анализа взаимодействий.
Полученное решение демонстрирует, что идеи UniMixer могут быть органично перенесены в финансовый контекст без радикального пересмотра всей системы. Более того, такой перенос усиливает модель там, где это важно — на уровне представления данных и их структурирования. Это создаёт предпосылки для точного выявления устойчивых рыночных закономерностей и повышения устойчивости модели к шуму.
В то же время текущий этап — это лишь отправная точка. Впереди остаётся реализация блоков UniMixer и полноценное тестирование на исторических данных. Именно там станет ясно, насколько предложенный подход способен не только красиво выглядеть на бумаге, но и приносить практическую пользу в реальной торговле.
Ссылки
Программы, используемые в статье
| # | Имя | Тип | Описание |
|---|---|---|---|
| 1 | Study.mq5 | Советник | Советник офлайн-обучения моделей |
| 2 | StudyOnline.mq5 | Советник | Советник онлайн-обучения моделей |
| 3 | Test.mq5 | Советник | Советник для тестирования модели |
| 4 | Trajectory.mqh | Библиотека класса | Структура описания состояния системы и архитектуры моделей |
| 5 | NeuroNet.mqh | Библиотека класса | Библиотека классов для создания нейронной сети |
| 6 | NeuroNet.cl | Библиотека | Библиотека кода OpenCL-программы |
Проект представлен на forge.mql5.io/dng.
Предупреждение: все права на данные материалы принадлежат MetaQuotes Ltd. Полная или частичная перепечатка запрещена.
Данная статья написана пользователем сайта и отражает его личную точку зрения. Компания MetaQuotes Ltd не несет ответственности за достоверность представленной информации, а также за возможные последствия использования описанных решений, стратегий или рекомендаций.
Разработка инструментария для анализа движения цен (Часть 22): Панель корреляции
Создание самооптимизирующихся советников на MQL5 (Часть 9): Двойное пересечение скользящих средних
Неопределенность как модель (Часть 4): Случайные процессы — динамика неопределённости
Преодоление проблем доступности в торговых инструментах на MQL5 (Часть I): Как добавить контекстные голосовые оповещения в индикаторы MQL5
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования