Обсуждение статьи "Нейросети в трейдинге: От единственного прогноза к пространству рыночных сценариев (сценарное кросс-внимание)"

Новый комментарий
 

Опубликована статья Нейросети в трейдинге: От единственного прогноза к пространству рыночных сценариев (сценарное кросс-внимание):

Статья вводит промежуточный слой между Forecast и торговой политикой. CNeuronScenarioCrossAttention по отдельности анализирует сценарии, не смешивая их траектории, включает оценку неопределённости и применяет априорные вероятности только после содержательной интерпретации. Для Актёра используется исторический контекст, Критик работает без памяти. На выходе — компактные контексты для принятия решения.

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

Сценарное кросс-внимание рассматривает каждый вариант будущего отдельно и сохраняет целостность его траектории. Неопределённость включается в содержание прогнозных токенов, а априорная вероятность применяется только после содержательного анализа. Для Актёра дополнительно учитывается история предыдущих решений, что помогает отличать обычный рыночный шум от реальной смены режима. Критик остаётся без внутренней памяти и оценивает предлагаемое действие в текущем состоянии.

Автор: Dmitriy Gizlyk

 

Я внимательно прочитал статью полностью.

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

Мне особенно понравились несколько моментов.

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

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

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

Отдельно хочу отметить решение оставить Критика без внутренней памяти. Это тоже выглядит правильно. Критик должен объективно оценивать текущее состояние, тогда как память действительно необходима именно Актёру, который принимает последовательные торговые решения.

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

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

Например, логически связанные компоненты памяти можно было бы объединить в отдельную структуру или класс.

Например:

struct HistoryBlock { CNeuronAddToStack stack; CNeuronMomADTTM ttm; CNeuronConvOCL projection; CCrossMHFlashAttention market; CNeuronCrossAttention context; CNeuronCrossAttention scenario; };

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

Также некоторые названия можно сделать более говорящими.

Например:

  • cKV → cKeyValue ;

  • cQueryGradient → cProjectedQueryGradient или cQueryResidualGradient .

Такие имена позволяют быстрее понять назначение объекта без просмотра реализации.

Ещё одно небольшое предложение касается режима работы объекта.

Вместо булевой переменной

bool bCritic;

можно использовать перечисление

enum Mode { ACTOR, CRITIC };

Такой вариант будет более расширяемым. Если в будущем появятся новые режимы работы (например, World Model, Encoder или Decoder), архитектуру не придётся изменять.

Я также сделал бы интерфейс более симметричным. Сейчас существуют методы GetWz() и GetWu() , однако отсутствуют аналогичные методы для других важных компонентов ( Attention , OutputProjection , ScenarioHistory и т.д.). Более единообразный интерфейс сделал бы код ещё удобнее.

Если говорить уже о самой статье, то, на мой взгляд, единственный её недостаток заключается в том, что она слишком подробно следует структуре исходного кода. Читатель последовательно проходит через большое количество внутренних объектов ( cWz , cWu , cTokenSum , cTokenPE , cTokensTranspose и многие другие), из-за чего иногда теряется общая картина алгоритма.

Мне кажется, статья станет ещё сильнее, если её строить вокруг нескольких крупных функциональных блоков:

  • Projection;

  • Token Encoding;

  • Cross Attention;

  • Scenario Refinement;

  • Policy Gate.

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

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

  • общая схема прохождения данных от Forecast к Actor и Critic;

  • схема сохранения оси сценариев внутри Scenario Cross Attention;

  • схема памяти Actor;

  • итоговая схема всей архитектуры.

Несколько хороших рисунков позволят сократить объём текста и сделают статью намного понятнее.

Ещё одно небольшое замечание касается использования внутренних имён классов. В статье иногда встречаются такие названия, как cHeadGateTranspose или cHistoryTokenProjection . Для программиста они понятны, но для читателя лучше использовать функциональные названия («проекция исторических токенов», «сценарный гейт», «контекст истории»), а реальные имена классов упоминать только там, где это действительно необходимо.

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

Также было бы полезно добавить небольшое сравнение с классическими архитектурами памяти, такими как Transformer Encoder, GRU или LSTM, и объяснить, почему именно предложенный подход лучше подходит для решения данной задачи.

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

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

Новый комментарий