TSlab скорость расчетов, Monte Carlo и Байес после триллионной сетки. Часть 3 ARANEA

 

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


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

> Реально ли сделать `2 000 000` прикладных оценок в секунду в TSLab?

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

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

Я мог бы привести пример и на Zorro. Но Zorro решает немного другую задачу: это скорее программная среда для бэктестинга, оптимизации и автоматизации торговых систем через код и скрипты, а не визуальный конструктор логики в стиле TSLab. Для этой серии мне проще отталкиваться от TSLab, потому что там понятнее визуальная логика для большинства читателей из этого узкого направления.

Если говорить именно про `2 000 000` оценок в секунду в TSLab, то понадобятся не только настройки. Понадобятся инструменты уровня JetBrains, хороший опыт в C++, понимание памяти, потоков, профилирования, CPU/GPU и внутренней логики пересчета. А еще нужны знания в прикладной математике: комбинаторика, теория вероятностей, математическая статистика, численные методы, методы оптимизации, анализ временных рядов, алгоритмы, структуры данных, оценка сложности, работа с кэшем и параллельными вычислениями.

Если все это есть, особенно последнее, то `2 000 000` оценок в секунду иногда проще сделать уже не в TSLab, а в своей программе. Собственно, так я постепенно и пришел к ARANEA.

Теперь про скорость вычислений «в лоб». Чтобы расчет был быстрым, его нужно сначала сделать чистым и последовательным.

1. Не нужно вычислять `0 + 0 = 0`, если заранее понятно, что ветка не дала входов.
2. Нужно закладывать правильную последовательность вычислений: от перестановки слагаемых сумма не меняется, но стоимость итерации может измениться сильно.
3. Нужно делить расчет на семейства. Одни и те же EMA-ряды можно переиспользовать десятки раз, а не пересчитывать их под каждую соседнюю гипотезу.
4. Дешевые entry-фильтры должны идти раньше тяжелого PM-прогона.
5. Производные ряды, bitset-ы, кэши и группы входов должны считаться один раз и переиспользоваться.
6. Не каждую промежуточную сущность нужно записывать на диск, если она нужна только для следующего шага.
7. Большой перебор должен быть не хаотичной таблицей, а последовательным планом.

В архитектуре своего проекта я разложил расчетный процесс на `32` этажа. Можно было сделать больше, но зачем, если уже появляется управляемая последовательность: подготовка данных, entry-карта, фильтры, группы, PM, pruning, метрики, артефакты, пул и дальнейший отбор. Я буду показывать пример, где `34` стратегии, `170` правил и итоговые `31` триллион комбинаций все еще разбираются на старом компьютере но немного позже. Смысл не в красивой большой цифре, а в том, что скорость начинается не с «добавить потоков», а с правильной математики и архитектуры вычислений.


Что вообще можно считать стратегией





Тут важно сразу снять еще одно ограничение. В первых частях я специально использовал простые EMA-состояния, DOP и несколько PM, потому что на них легче показать рост количества комбинаций. Но сам подход не привязан к EMA.

В алгоритмической торговле почти любую формализуемую идею можно превратить в правило:

1. свечной паттерн: тело, хвосты, положение `close`, последовательность баров;
2. объем: рост/падение объема, всплеск, реакция после всплеска;
3. кластерный объем: уровень, дельта, дисбаланс, удержание зоны, возврат к ликвидности;
4. волновая логика: pivot-точки, глубина коррекции, отношение волн, выход одной волны за другую, время формирования;
5. старшие таймфреймы: `4h`, `12h`, `1d` как внешний контекст для `1h`;
6. преобразования цены: Heiken Ashi, Renko, Kagi, крестики-нолики и другие формы графика;
7. индикаторные состояния: EMA, SMA, RSI, MACD, ATR, ADX, Bollinger Bands, Donchian Channel;
8. правила выхода: fixed stop, ATR-stop, trailing, percent take, parabolic stop, частичный выход, выход по времени или противоположному сигналу.

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

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

Именно поэтому спор «EMA против свечей», «индикаторы против объемов» или «Renko против обычного графика» для вычислений вторичен. Важнее другое: сколько таких условий можно формально описать, в какой последовательности их считать и какие результаты потом сохранить. Когда речь идет о миллиардах и триллионах комбинаций, ошибка в последовательности легко превращается в месяцы лишнего времени.

Отсюда и мое отношение к Monte Carlo и Байесу. Они полезны, но они не делают стратегию прибыльной сами по себе.

Любой метод имеет право на существование, если он не живет в фантазии, а применяется на практике и проверяется результатами. Байес, Monte Carlo, полный перебор, жадный отбор, ручной анализ графика — все это инструменты. Проблема начинается там, где инструменту начинают приписывать магию.

Если бы Байес и Monte Carlo сами по себе давали прибыльность, то все, кто подключил эти методы к оптимизации, давно стали бы богаты. Но рынок так не работает. Лучшие показатели на истории часто оказываются не лучшими стратегиями, а переоптимизированными показателями. Можно предположить, что `31` триллион комбинаций получится прогнать через Байес или Monte Carlo за сутки. И что дальше? Мы получим набор лучших точек по выбранной функции качества, но это еще не означает, что в будущем рынок даст этим точкам заработать.

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

Простой бытовой пример — рыбалка. Озеро хорошее, рыба есть, снасти нормальные. Но сегодня давление высокое, щука спряталась или уже наелась, и вы ничего не поймали. На следующий день условия изменились, и все ловится отлично. Рынок похож: одна и та же логика может быть живой в одном режиме и бесполезной в другом. Поэтому среди триллионов комбинаций нельзя просто искать лучший `PnL` или лучший `winrate`. Нельзя забрать с рынка больше, чем он в конкретном режиме способен дать вашей логике. Если из доступного движения удалось стабильно забрать даже небольшую часть, это уже может быть хорошим результатом.


Monte Carlo может быстро раскидать случайные точки по пространству и показать распределение результатов. Байес может быстрее искать хорошую область по выбранной функции качества. Но оба метода отвечают на вопрос, который мы им задали. Если задать слабый вопрос вроде «найди лучший `PnL`», то метод найдет лучший `PnL` на уже известной истории. Это может быть рабочая область, а может быть просто красивый хвост прошлого участка.




Я уже приводил похожий пример во второй части: условие могло выполниться на один час раньше и попасть в одну группу сделок, а могло выполниться на час позже и попасть уже в другую группу. Если эта сделка прибыльная, она улучшит показатели той группы, куда попала. Если убыточная — ухудшит. Теперь представим не один фильтр, а `3-4` правила одновременно. Сколько сделок в разных местах истории случайно распределятся по таким группам и подтянут или испортят итоговые показатели, по которым потом будут судить о прибыльности стратегии? Именно поэтому одна лучшая строка или один найденный максимум не доказывают, что найден устойчивый принцип.

Главная проблема в том, что такие методы не обязаны до конца анализировать все логические ветки. Ветка может быть слабой по максимальному `PnL`, но устойчивой по просадке. Может быть средней отдельно, но полезной как short-хедж к long-пулу. Может проиграть по одной метрике, но выиграть как семейство соседних параметров. Если Monte Carlo почти не попал в эту область, а Байес ушел к другой функции качества, то в итоговой картине этой ветки как будто не существовало.

Поэтому перед Байесом и Monte Carlo нужна карта гипотез: какие правила вообще дали входы, какие PM выжили, какие фильтры не убили статистику, где результат держится не на одной сделке, какие соседние параметры ведут себя похоже. Только после этого имеет смысл использовать Monte Carlo для сборки пулов и Байес для уточнения состава, весов или параметров по уже понятной функции качества.

И еще один обязательный слой — правая сторона графика. Если оптимизация шла на одном участке истории, например `2020-2023`, то найденные профили нужно включить на участке, который они не видели, например `2023-2024`. Там становится понятно, что мы нашли: живую гипотезу, переобученный фильтр, PM, который спасал только один рыночный режим, или случайный лучший результат.




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

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

В Байесе или Monte Carlo можно взять лучшие найденные варианты и тоже провести такую проверку. Формально все будет выглядеть нормально: есть кандидаты, есть метрики, есть повторный прогон. Но мне интереснее другой уровень: взять не только несколько победителей, а сразу миллионы вариантов, которые прошли первичный отбор, и смотреть их выживаемость, отклонение и устойчивость как семейства. Тогда мы сравниваем не одну точку, а форму области, где стратегия продолжает жить.

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




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

Я также не утверждаю, что Monte Carlo или Байес «хуже» ARANEA. Это методы для других вопросов. Байес ищет хорошую точку по выбранной функции качества. Monte Carlo сканирует распределение случайных вариантов. ARANEA на первом этапе строит карту того, где торговая гипотеза вообще имеет право на жизнь.

Главная ошибка — пытаться заменить постановку задачи методом оптимизации. Если вопрос слабый, быстрый метод просто быстрее даст слабый ответ.
Простая арифметика времени

Базовая формула остается такой: `wall_time = total_evaluations / evaluations_per_second`.

Если взять грубую скорость первого TSLab-замера `385.53` оценки/сек и применить ее к верхней сетке второй части, получится примерно `8 865 073 180` секунд. Это около `102 605` дней, или `281.11` года.

Так как благодаря фильтрам предподготовки, которые описывал немного выше получилось срезать из общего числа вычислений 99% грязных расчетов… в конкретном запуске ARANEA осталось `25 159 256 816` проверок. Если считать их с той же грубой скоростью TSLab-замера, получится около `65 258 208` секунд, или `755` дней, или `2.07` года.

Теперь посмотрим на тот же объем через разные скорости:

| Скорость | Верхняя сетка `3.417T` | После entry-подготовки `25.159B` |
|---:|---:|---:|
| `385.53`/сек | `281.11` года | `2.07` года |
| `100 000`/сек | `395.58` дня | `69.89` часа |
| `500 000`/сек | `79.12` дня | `13.98` часа |
| `2 000 000`/сек | `19.78` дня | `3.49` часа |

Эта таблица показывает две разные вещи.

Первая: математическое отсечение до тяжелого расчета иногда важнее голой скорости. Если отправить в PM все `3.417T`, даже высокая скорость быстро превращается в недели и месяцы.

Вторая: после правильной подготовки данных скорость начинает менять практический режим работы. Разница между `385.53` и `100 000-500 000` проверок в секунду — это переход от «ждать невозможно» к «можно планировать исследовательские прогоны».

На этой конкретной стратегии, активе и таймфрейме скорость ARANEA в моих прогонах колеблется примерно от `100 000` до `500 000` проверок в секунду. Это не константа для всех рынков и не финальный потолок. Чем тяжелее PM и чем дольше живет сделка, тем ниже скорость. Чем лучше подготовлены entry-ветки и кэши, тем меньше лишней работы попадает в расчет.




Вывод третьей части(первую и вторую часть в отредактированном варианте я выложу на хабр из которых вывод будет написан тут) просто изменять посты к сожалению уже нельзя.

Во второй части мы получили верхнюю сетку `3 417 786 951 264` и увидели, что после entry-подготовки в конкретном запуске осталось `25 159 256 816` проверок. В третьей части появляется смысл скорости: при `385.53` оценки/сек даже сокращенный план выглядит как годы, а при `100 000-500 000` проверок/сек он превращается в практический исследовательский прогон.

Но скорость — это не финальный ответ. Она только открывает возможность задавать правильные вопросы: какие ветки живые, какие PM устойчивы, где результат держится на группе соседних параметров, а где мы просто поймали случайный хвост истории.

Monte Carlo и Байес нужны не вместо исследовательской карты, а после нее. Сначала ARANEA должна подготовить качественный массив кандидатов: с метриками, фильтрами, PM, ограничениями и отсечением грязных вариантов. Потом Monte Carlo может проверять распределения и пулы, а Байес — уточнять состав, веса или параметры по уже осмысленной функции качества.

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