LuxAlgo. Часть II: бэктестеры, AI-стратегии и вебхуки

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

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

Часть I этой серии, «установка, алерты TradingView и агент Quant», закончилась на инфраструктуре: аккаунты связаны, тулкиты стоят на графике, алерт TradingView настроен, агент Quant умеет писать код по описанию. Отсюда понадобятся ровно две вещи: связанные аккаунты и закон закрытой свечи, по которому сигнал считается подтверждённым только на закрытии бара. Вперёд эта часть смотрит чаще, чем назад. Условия, из которых ниже собираются стратегии, разбираются дальше по серии: Часть III отдана структурному тулкиту, Часть IV сигнальному, Часть V осцилляторному, и именно оттуда берутся строки, которыми здесь заполняются выпадающие списки. Язык Alert Scripting, ближайший родственник разбираемого здесь Strategy Scripting, живёт в Части VI, а три скринера ждут в Части VII. Часть II стоит между ними: она про измерение, а не про сигналы.

К последней странице должно стать понятно, откуда берутся числа в ответе ассистента и в каких местах они расходятся с числами TradingView не по ошибке, а по определению метрики. Дальше: как собрать бэктест из условий прямо на графике, как выстроить условия во времени, какие настройки делают Winrate (винрейт) красивым и недостоверным одновременно и как событие на графике превращается в POST-запрос на сервер брокера. Чего в тексте нет: ни одной рекомендации, какую стратегию брать, и ни одного суждения о том, какой результат считать хорошим.

«Бэктест не отвечает на вопрос, будет ли стратегия работать. Он отвечает на вопрос, работала ли она в прошлом при этих правилах учёта.»

Содержание

• Пролог. Две дороги к одной цифре
• Глава 1. Две машины с одним именем
• Глава 2. База, из которой ассистент достаёт ответы
• Глава 3. Из чего собрана стратегия в базе
• Глава 4. Как задавать вопрос ассистенту
• Глава 5. Backtest Viewer: как читать чужой результат
• Глава 6. Пределы доверия к цифрам ассистента
• Глава 7. Три бэктестера на графике и их общий фундамент
• Глава 8. Словари входа: чем три бэктестера отличаются друг от друга
• Глава 9. Step & Match: сюжет вместо совпадения
• Глава 10. Как условие превращается в ордер
• Глава 11. Два независимых контура выхода
• Глава 12. Прогноз, который умеет перерисоваться
• Глава 13. Оптимизатор чувствительности
• Глава 14. Strategy Scripting: язык внутри бэктестера
• Глава 15. Алерты бэктестеров в TradingView
• Глава 16. Алерты по AI-стратегиям: события, карточки и письма
• Глава 17. Вебхуки: от сигнала к ордеру у брокера
• Эпилог. Куда ведёт Часть III
• Источники

Раздел документации называется AI Backtesting, и под этим именем уживаются два продукта разной природы. Первый это AI Backtesting Assistant (ИИ-ассистент бэктестинга), чат на сайте LuxAlgo по адресам www.luxalgo.com/chat/ и www.luxalgo.com/backtesting/chat/. Важнее всего понять, чего он не делает: он не считает бэктест по вашему запросу. Он ищет готовый результат в базе, рассчитанной заранее, и пересказывает найденное человеческим языком. Второй продукт это бэктестер, отдельный скрипт на графике. Бэктестеров три, по одному на каждый тулкит: бэктестер Signals & Overlays®, бэктестер Price Action Concepts®, бэктестер Oscillator Matrix®. Они считают в момент запроса, на том символе и на том таймфрейме, которые открыты у вас, и никакой предварительно посчитанной базы за ними нет. Путаница между двумя машинами это главный источник недоразумений во всём разделе: почти каждый вопрос вида «почему у меня получились другие цифры» вырастает именно отсюда.

Из одного этого различия выводится почти всё остальное. Ассистент отвечает мгновенно, потому что вычисление уже произошло, но спрашивать его можно только про заранее оговорённую вселенную: 92 тикера (сумму мы посчитали сами по таблицам источника, глава 2 объясняет почему) и три таймфрейма, ни шагом в сторону. Бэктестер работает на любом символе, доступном вашему тарифу данных TradingView, и на любом таймфрейме, но каждую конфигурацию условий вы задаёте руками и перебираете варианты сами. Второе следствие тоньше: результаты двух машин не обязаны совпадать даже при одинаково сформулированной стратегии. У них разные поставщики котировок, разная доступная глубина истории и разная логика исполнения ордеров. Расхождение здесь норма, а не признак поломки, и глава 6 разбирает его по пунктам. Как выглядит работа с ассистентом в движении, показывает демонстрационный ролик на странице AI Backtesting Introduction документации.

Обе машины закрыты тарифом Ultimate, хотя сам источник в этом не единодушен: страницы одного раздела описывают условия доступа к ассистенту по-разному, и разбор этого расхождения ждёт в главе 6. Пока достаточно рассчитывать бюджет на строгую версию. Словарь у двух машин общий: стратегия описывается условиями входа и условиями выхода, результат меряется одним набором метрик, от Net Profit (чистой прибыли) до Max Drawdown (максимальной просадки). Разница только в том, кто перебирает условия. Ассистент годится для разведки: быстро увидеть, какие сочетания вообще давали заметный результат на популярных инструментах, и не потратить на это вечер. Бэктестер нужен тогда, когда у вас уже есть своя гипотеза, свой инструмент и свои издержки, и ответ требуется именно про них.

Заявленный объём базы: более 10 000 000 рассчитанных стратегий. Собраны они из компонентов трёх тулкитов, Signals & Overlays, Price Action Concepts и Oscillator Matrix, и ничего кроме них в базе нет. Ни одного внешнего индикатора, ни одной пользовательской формулы, ни одной чужой библиотеки. Это не ограничение, о котором забыли упомянуть, а определение продукта: ассистент описывает поведение инструментов LuxAlgo на истории, а не рынок как таковой. Любой его ответ стоит читать с молчаливой приставкой «в рамках трёх тулкитов и при тех правилах учёта, которые заданы движком». Работа с такой базой поэтому устроена иначе, чем работа со скриптом: расчёт произведён заранее и без вашего участия, а от вас требуется не перебор настроек, а точная формулировка вопроса к уже готовым числам.

База не живая. Пересчёт идёт по расписанию, трижды в неделю: в понедельник, в среду и в пятницу, каждый раз в 23:30 UTC. Между пересчётами цифры зафиксированы, и сколько бы раз вы ни задали один и тот же вопрос, ответ придёт один и тот же, даже если рынок за это время успел сходить вниз и вернуться. Практическое следствие простое: винрейт, увиденный в четверг днём, описывает историю по состоянию на вечер среды, и последние полтора суток в него не вошли. На пятиминутном таймфрейме это несколько сотен баров, то есть заметная доля свежей истории для внутридневной стратегии.

Таймфреймов ровно три: 5 минут, 15 минут и 1 час; в интерфейсе они подписаны 5m, 15m и 60m. Ничего другого в базе нет, и просить у ассистента дневную стратегию бессмысленно. Здесь же стоит снять частую путаницу: встроенный график агента Quant, разобранный в Части I, поддерживает семь таймфреймов, от 1 минуты до 1 дня, и опирается на другой набор инструментов. Это другая платформа с другим охватом, и складывать два набора нельзя, хотя оба живут на одном сайте и оплачиваются из одного баланса.

Вселенная инструментов разложена в источнике на шесть таблиц по классам активов: 30 акций, 5 ETF, 27 криптовалютных пар, 13 валютных пар, 3 товарных инструмента и 14 фьючерсных контрактов. Итоговой суммы документация не приводит. Если сложить опубликованные таблицы, получается 92 тикера, и дальше в тексте мы пользуемся именно этим посчитанным числом, помня, что в источнике оно не названо. Полные перечни имён остаются в документации: для понимания охвата важны классы и количества, а не сами тикеры.

Движок, считающий базу, настроек не имеет вовсе, и это существенная часть картины. На стратегию отводится не более 20 000 последних баров. Initial Capital (начальный капитал) равен 10 000 в базовой валюте. Комиссия и Slippage (проскальзывание) не применяются, все настройки тулкитов оставлены по умолчанию, размер позиции единичный и одинаковый для всех тикеров, независимо от цены инструмента. Одновременно открыта не более чем одна позиция, встроенных тейк-профитов и стоп-лоссов нет. Ни одно из этих значений пользователь изменить не может: они выбраны разработчиком один раз для всей базы, иначе десять миллионов бэктестов не были бы сопоставимы между собой.

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

Схема сборки в базе жёсткая, и знание её формы полезнее знания отдельных условий. Одно условие входа состоит ровно из одного триггера и не более чем из двух фильтров; больше трёх слагаемых во входе не бывает. Длинная и короткая стороны зеркальны друг другу и опираются на разнонаправленные индикаторы: там, где в лонге стоит бычье пересечение, в шорте стоит медвежье. Из этого следует, что стратегия из базы всегда описывается одной короткой фразой, и любое ожидание сложной многоступенчатой логики придётся отложить до второй половины части, где условия собираются на графике.

Разница между триггером и фильтром здесь техническая, а не стилистическая. Триггер это одномоментное событие: оно случается на баре и живёт один бар. Фильтр это состояние, которое держится подряд несколько баров. Отсюда странность, бросающаяся в глаза при первом чтении списков: одно и то же понятие встречается в них дважды. Money Flow Crossing Over 50 это триггер, момент пересечения центральной линии. Money Flow Above 50 это фильтр, продолжающееся положение выше неё. Первое открывает сделку, второе только разрешает её открыть. Бычьи и медвежьи условия при этом смешивать в одном входе разрешено: это не сбой генерации, а допустимая конфигурация.

Сигнальный тулкит отдаёт в базу самый широкий словарь: 11 бычьих триггеров и 11 зеркальных медвежьих, полный набор фильтров по обеим сторонам, два нейтральных фильтра Trend Strength (сила тренда) и единственные во всей базе условия выхода. Триггеры делятся на две неравные группы. Шесть из них это градации сигналов двух алгоритмов, подтверждающего и контртрендового, в трёх степенях каждый. Остальные пять это события смены состояния: у трёх оверлеев, у облака и у Reversal Zones (зон разворота), где триггером служит пересечение ценой внутренней границы.

Условия выхода в базе есть только у этого тулкита, и их три: встроенные выходы подтверждающих сигналов, встроенные выходы контртрендовых сигналов и пересечение ценой средней линии зон разворота, подписанное в интерфейсе как Price Cross R1/S1 Average. У двух других тулкитов выходов в базе нет вовсе, и сделка там живёт до встречного входа, поскольку одновременно открытая позиция всё равно одна. Разница между стратегией с выходом и стратегией без выхода при чтении результатов существеннее, чем кажется: в первом случае движок умеет вставать в стороне, во втором нет.

Структурный тулкит ведёт себя иначе: он отдаёт только триггеры, 12 зеркальных пар, и ни одного фильтра. Это не пробел документации, а свойство материала. Слом структуры, вход цены в ордер-блок, съём ликвидности, пробой трендовой линии происходят на конкретном баре и не тянутся во времени; состояний, которые можно держать неделю, структурный тулкит просто не производит. В нескольких парах направление намеренно перевёрнуто относительно подписи, и это стоит заметить заранее, чтобы не читать таблицу как опечатку: отработанный медвежий FVG стоит в бычьей колонке, потому что отработка медвежьего имбаланса это бычье событие. Так же устроен пробой трендовой линии: Bearish Trendline Break означает пробой нисходящей линии и потому относится к бычьей стороне.

Осцилляторный тулкит единственный из трёх делит словарь между событиями и состояниями почти поровну: 7 пар триггеров и 6 пар фильтров. Триггеры у него это пересечения уровней 20, 50 и 80, сигнал HyperWave из зоны перекупленности или перепроданности, появление избытка ликвидности, сигнал разворота и новая дивергенция. Фильтры это те же уровни, взятые как положение, а не как момент, плюс избыток ликвидности как состояние и сильный со слабым конфлюэнсом по обеим сторонам. Такая симметрия делает осциллятор удобным материалом для входа целиком: триггер и оба фильтра можно взять из одного тулкита.

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

Смешанные стратегии в базе есть, и у них появляется техническое требование, о котором легко забыть при воспроизведении. Если условия входа взяты из двух и более тулкитов, на графике понадобится включить в настройках соответствующие коннекторы LUCID: без них один скрипт не видит состояний другого, и стратегия не соберётся. Пример из источника прост: условию на Trend Catcher нужен коннектор со стороны Signals & Overlays. Подробный разбор коннекторов, вместе с расшифровкой аббревиатуры и порядком включения, идёт в главе 14, здесь достаточно предупреждения. Заодно очевидное: смешанная стратегия требует, чтобы на графике стояли все тулкиты, из которых она собрана, иначе воспроизводить будет нечего.

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

Форма ответа тоже задаётся не вами. Если под условия подошла одна стратегия, она рисуется карточкой; если несколько, приходит таблица, которую можно выгрузить в CSV. Предел жёсткий: за один запрос возвращается не более трёх стратегий, и обойти его получится только последовательностью запросов. У каждой стратегии в ответе два действия. Звезда сохраняет её в боковую панель, чтобы вернуться позже. Значок TradingView открывает диалог воспроизведения: пошаговую инструкцию, как повторить эту же конфигурацию на графике, вместе с готовым кодом скриптовой стратегии.

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

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

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

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

Третий режим работает с той стратегией, которую вы уже получили в текущем разговоре. У ассистента есть доступ не только к её итоговым метрикам, но и к списку сделок, и этот список он умеет фильтровать: по индексу сделки, по стороне, по результату, по времени удержания в минутах, по значению P&L, по времени открытия и по времени закрытия. Над отобранным подмножеством считаются среднее, медиана, количество, сумма, процент и длины серий. По каждой сделке возвращаются сторона, время и цена входа, время и цена закрытия, результат.

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

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

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

Отдельно стоит поведение с документацией. Ассистент умеет подтянуть справку LuxAlgo в ответ и объяснить функцию тулкита словами источника. Иногда он решает это сам, но гарантированно делает только тогда, когда в запросе стоит фраза use the documentation. Без неё ответ может прийти из обучающих данных модели, то есть из состояния документации на неизвестный момент в прошлом. Сильнее всего механизм работает в связке из двух шагов внутри одного запроса: сначала попросить найти по документации функции, подходящие под ваш стиль торговли, затем попросить стратегию на этих функциях для нужного класса активов и таймфрейма. Второй шаг опирается на результат первого, и оба выполняются за одно обращение.

Backtest Viewer (просмотр результатов бэктеста) это вторая половина интерфейса ассистента: панель, в которой разворачивается результат одной стратегии. По умолчанию в ней лежит та стратегия, которую нашли последней, а клик по карточке любой более ранней переключает просмотрщик на неё. Настраивать здесь почти нечего, и это принципиально: вы читаете чужой расчёт, а не свой. Из управляющих элементов только сортировка колонок журнала, переключение между табличным и календарным видом и навигация по месяцам.

Обзорный блок собирает пять чисел, которые обычно и запоминаются вместо всей стратегии: Historical Net Profit (кривая эквити), чистая прибыль, число сделок, винрейт и максимальная просадка. Дальше идёт раздел Performance с дневным P&L и результатами по дням недели, а под графиками таблица показателей в трёх разрезах: все сделки, только лонги, только шорты. Этот разрез на три колонки повторяется во всех таблицах просмотрщика, и он же самое полезное, что в них есть. Стратегия, у которой почти вся прибыль собрана в одной колонке, на деле односторонняя, и вторая сторона в ней только добавляет сделок.

Раздел Trades Analysis смотрит не на итог, а на разброс: распределение P&L, визуализация доли прибыльных сделок, диаграмма рассеяния «длительность против P&L», таблица анализа сделок и отдельная таблица длительностей. Trades Log (журнал сделок) устроен проще всего: хронологическая таблица закрытых сделок с колонками входа, выхода, чистого P&L и накопленного P&L, где любая колонка сортируется по возрастанию и по убыванию. Сортировка по накопленному P&L показывает, росла кривая эквити ровно или её вытянули две сделки.

Список метрик просмотрщика длиннее, чем кажется по обзорному блоку, и здесь важнее не названия, а определения. Названия кочуют из платформы в платформу, а формулы за ними расходятся, поэтому единственный способ не обмануться это читать определение. Profit Factor (профит-фактор) в этом просмотрщике равен валовой прибыли, делённой на валовый убыток; CAGR (среднегодовая доходность) приводит результат за весь период к годовому с учётом сложного процента; Gross Profit (валовая прибыль) и Gross Loss (валовый убыток) считаются до взаимного зачёта; Closed Trades (закрытые сделки) это только сделки, которые успели закрыться, и Average Trade (средняя сделка) считается по ним же. Полный справочник ниже.

Calendar View (календарный вид) это не отдельный раздел, а второй режим журнала сделок: тот же список, разложенный на помесячную сетку, где сделки сгруппированы по дням. В ячейке дня стоят P&L, число сделок и доля прибыльных. По краям сетки сводка месяца: P&L месяца, лучший день, худший день и среднее число сделок в день. Между месяцами можно переключаться вперёд и назад. Смысл этого вида в том, что он показывает распределение результата по времени, а не по сделкам: видно, набрана прибыль ровно или заработана в одну неделю, после которой ничего не происходило.

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

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

Всё, что описано выше, отвечает на вопрос, как получить цифру. Осталось понять, чего эта цифра стоит, и разговор придётся начать с расхождения, о котором источник говорит прямо. Просадка в базе LuxAlgo считается по реализованному P&L: в расчёт идут закрытые сделки и их зафиксированный результат. TradingView считает просадку иначе. Отсюда следует, что числа не совпадут, и не совпадут они не потому, что кто-то ошибся в арифметике, а потому что метрика определена по-разному.

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

«Расхождение с TradingView это не ошибка расчёта, а разница в определении метрики»

Второй ограничитель уже назывался среди параметров движка, но здесь он важен по-другому: не более 20 000 последних баров на стратегию. Формулировка звучит щедро, пока не пересчитать её в календарное время. Двадцать тысяч пятиминутных баров это порядка семидесяти суток непрерывной торговли для круглосуточного рынка и порядка двухсот пятидесяти торговых сессий для акций (пересчёт наш, в документации его нет). На часовом таймфрейме окно растягивается, на пятиминутном сжимается, и в обоих случаях оно заметно короче, чем «вся история» на графике TradingView. Стратегия, показавшая ровную кривую на таком отрезке, не проверена ни на одном кризисе, если кризис в отрезок не попал.

Третий слой ограничений спрятан в источниках котировок. Акции и ETF считаются по бирже Cboe BZX и только в основную торговую сессию: премаркет и постмаркет в расчёт не входят вовсе. Для внутридневной стратегии это существенно, потому что часть движения по отчётам и новостям приходится именно на время вне основной сессии, а в базе такого движения просто нет.

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

Отдельный класс проблем относится не к доверию к цифрам, а к доступу к ним: ассистент может просто не ответить. Страница устранения неполадок перечисляет пять типовых ситуаций, и почти все они описывают не поломку, а исчерпанный ресурс.

Выбор модели вынесен в отдельный селектор, и стоимость каждой модели помечена значками $: чем их больше, тем дороже обходится сообщение. Считается при этом не число сообщений, а объём возвращённого содержимого, поэтому несколько очень больших ответов сжигают ресурс быстрее, чем десятки коротких. Отсюда следует неочевидный вывод: экономия достигается не молчанием, а более узкими запросами. Кредиты, которыми всё это оплачивается, общие с агентом Quant из Части I и обнуляются 1 числа каждого месяца.

Остаётся вопрос доступа, обещанный в первой главе. Источник противоречит себе, и воспроизвести противоречие честнее, чем выбрать удобную версию: на одной странице сказано, что ассистент доступен только тарифу Ultimate, на другой, что доступ есть у всех, а Premium и Ultimate получают повышенные лимиты. Страница устранения неполадок держится строгой версии и прямо говорит, что подписчику Premium нужно повышение тарифа. Планировать разумно по строгой версии: если функция нужна для работы, рассчитывайте на Ultimate и считайте расширенный доступ на других тарифах приятной неожиданностью, а не основанием для решения.

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

Настройки любого из трёх скриптов разбиты на области, и число областей у них разное. У бэктестера Signals & Overlays их четыре, и каждой отведена своя страница документации: правила входа, условия выхода, фиксированные уровни защиты и оптимизация. У бэктестеров Price Action Concepts и Oscillator Matrix областей три, потому что страницы оптимизации у них нет вовсе. Это единственное структурное различие на уровне разделов, и знать о нём стоит заранее, чтобы потом не искать в двух скриптах то, чего в них не заложено.

Первое, что задаётся в любом бэктестере, это отрезок истории, о котором будет говорить статистика. За него отвечает Backtesting Window (окно бэктеста) с тремя значениями: Bars, Date и Entire History, по умолчанию Bars. В режиме Bars работает поле Window (Bars) (окно в барах) со значением 2000 по умолчанию, то есть расчёт идёт по двум тысячам последних баров и на пятиминутном графике покрывает совсем не тот промежуток времени, что на часовом. В режиме Date включаются поля Window Start и Window End, оба по умолчанию 2024-01-01 00:00. У конца окна есть тонкость: он закрыт собственным переключателем, и пока переключатель снят, конец не применяется, а расчёт идёт до последнего бара.

Дальше идёт блок, описывающий смоделированный счёт. Начальный капитал по умолчанию 10 000, и это условная сумма, а не ваш депозит. Base Currency (базовая валюта) по умолчанию имеет значение Default, то есть валюту символа, и именно в ней выражается вся статистика прогона: сменив валюту, вы меняете единицу измерения всех чисел разом, от чистой прибыли до просадки.

Order Size (размер ордера) по умолчанию равен 1 Contract, то есть одному контракту на сделку, а единица объёма выбирается из трёх: контракты, сумма в валюте и % of equity (процент от эквити). Commission (комиссия) по умолчанию 0%, и единица здесь тоже тройная: валюта за контракт, валюта за ордер, процент от суммы сделки. Margin for long position и Margin for short position (маржа для длинных и коротких позиций) по умолчанию 0% и задаются в процентах от эквити. Все эти значения нейтральны и к рынку, и к брокеру, и источник говорит об этом прямо: пока в поля не подставлены ваши реальные условия, числа бэктеста описывают счёт, которого не существует.

Общий фундамент на этом заканчивается. Различия между тремя скриптами лежат в двух местах: в словаре условий, которым вы описываете вход, и в том, разрешено ли этим условиям выстраиваться во времени. Условия каждый бэктестер берёт из своего тулкита, и переносить их между скриптами нельзя. Порядок во времени задаёт движок Step & Match (шаги и совпадения), и он есть только у двух бэктестеров из трёх. Оптимизатор, наоборот, есть только у одного. Таблица ниже работает как навигатор по следующим главам: словари входа разбираются в главе 8, шаги и совпадения в главе 9, оптимизатор в главе 13.

Последнее ограничение фундамента не настраивается вовсе, потому что живёт за пределами бэктестера. Расчёт сделок опирается на реальные цены закрытия, а нестандартные типы графиков их не дают: Heikin-Ashi, Renko, Kagi, Line Break, Point and Figure и Range candles показывают производные, синтетические значения, выведенные из настоящих котировок по собственному правилу. Бэктест на таком графике посчитается и выдаст цифры, только описывать они будут торговлю по ценам, которых на рынке не было. Источник отсылает по этому поводу к отдельному руководству TradingView о бэктестинге на нестандартных типах графиков.

Словарь условий это то, чем три скрипта различаются по существу, поэтому разбирать их приходится по отдельности. Одно устройство у них общее: длинная и короткая стороны настраиваются независимо друг от друга. Это не одна настройка с автоматическим зеркалом, а два отдельных блока, и никто не мешает собрать вход в лонг по одному набору событий, а вход в шорт по совсем другому. Предел числа условий на сторону у каждого свой: у бэктестера Signals & Overlays он не объявлен и определяется составом блока, у бэктестера Price Action Concepts их ровно шесть, у бэктестера Oscillator Matrix ровно восемь.

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

Сам словарь собран из компонентов тулкита. Условие Signal Type устроено как два выпадающих списка: в первом выбирается алгоритм, Confirmation или Contrarian, во втором градация сигнала, и градаций восемь. Шесть из них описывают сигнал словами (любой, обычный или усиленный, бычий или медвежий), а два последних, Bullish Classifier и Bearish Classifier, срабатывают только тогда, когда класс сигнала совпадает с числом, набранным в правом поле. Деталь, которая часто ускользает: частота сигналов задаётся не здесь, а в самом тулките, его чувствительностью и режимом Autopilot (автопилот). Бэктестер лишь читает то, что тулкит уже посчитал.

Остальные условия читают состояние оверлеев и уровней. Зоны разворота дают тринадцать значений: шесть пересечений границ от R3 до S3, пять попаданий в полосу между соседними границами и два крайних положения, выше R3 и ниже S3. Smart Trail, Trend Tracer и Trend Catcher дают по четыре значения каждый: текущее бычье или медвежье состояние либо тот единственный бар, на котором состояние сменилось. У Neo Cloud значений восемь, потому что к состоянию и смене добавлены четыре события шага линий lead и lag. Сила тренда стоит особняком: это сравнение числа с порогом, который вы задаёте сами.

У бэктестера Price Action Concepts слот условия собран из двух списков: сначала направление, Bullish или Bearish, затем событие. События покрывают всю разметку тулкита, и их тринадцать: три структурных варианта (CHoCH or BOS, CHoCH, BOS), четыре взаимодействия цены с ордер-блоком, четыре таких же взаимодействия с имбалансом, съём ликвидности и пробой трендовой линии. У последнего события направление читается иначе, чем у остальных: Bullish означает восходящую линию, Bearish нисходящую. Параметры самих концепций задаются не здесь: у ордер-блоков, имбалансов и структуры свои группы настроек ниже по списку, и разбор этих групп это Часть III. Пока названия событий работают для нас как строки в выпадающем списке.

В бэктестере Oscillator Matrix словарь короче и однороднее. Источников шесть: Money Flow (денежный поток), OverFlow (избыток ликвидности), HyperWave, Reversal, Divergences и Confluence. К выбранному источнику применяется оператор сравнения и значение, а у тех источников, которые дают не непрерывный ряд чисел, а отдельные сигналы, в списке появляются дополнительные значения вида Any Bullish. Восемь условий на сторону это общий предел: в него входят и условия тулкита, и внешние условия, так что место в блоке приходится делить между ними.

Внешние условия устроены во всех трёх скриптах одинаково и состоят из трёх частей: выход стороннего индикатора, оператор сравнения, второй выход или число. Оператор выбирается из шести значений: Greater Than (больше), Lower Than (меньше), Equal (равно), Crossing Over (пересечение вверх), Crossing Under (пересечение вниз) и Crossing (пересечение в любую сторону). Требование, о котором забывают чаще всего: индикатор должен быть уже добавлен на график, иначе в выпадающем списке его просто не окажется. У бэктестера Signals & Overlays третье внешнее условие вдобавок принимает ценовые плейсхолдеры open, high, low, close, hl2, ohlc4, hlc3 и hlcc4. Сессия оформлена как отдельное условие: в бэктестере Price Action Concepts это шестой, последний слот. Она разрешает вход только внутри заданного интервала времени, причём часовой пояс берётся у биржи символа, а криптовалюты считаются по UTC.

Механика, к которой ведёт вся предыдущая глава, называется Step & Match и живёт в бэктестерах Price Action Concepts и Oscillator Matrix. Устройство её обманчиво простое: у каждого условия появляется поле Step, и в нём стоит номер. В бэктестере Oscillator Matrix номера идут от 1 до 5, и к ним добавлено значение Invalidate. В бэктестере Price Action Concepts номера доходят до 6; шаг получают пять условий, три ценового действия и два внешних, а сессионное условие номера не имеет. Из одного этого поля вырастают два совершенно разных способа описать вход.

Если два или больше условий несут один и тот же номер, они проверяются вместе и должны выполниться одновременно. Это и есть режим совпадения, ровно та же логика И, что работает в бэктестере Signals & Overlays, только записанная явно. Пока все номера в блоке одинаковы, движок неотличим от простого набора фильтров: он ждёт бар, на котором сходится всё сразу, и в этот момент открывает рыночный ордер.

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

У незавершённой последовательности должен быть способ прерваться, и первый из них лежит в том же выпадающем списке Step. Помимо номеров в нём есть значение Invalidate (шаг инвалидации): условие, помеченное этим значением, не участвует в сюжете, а обрывает его. Когда оно срабатывает, незавершённая последовательность возвращается к первому шагу, и накопленный прогресс исчезает. Таких условий в блоке может быть несколько, и достаточно, чтобы сработало любое одно. Это удобный способ сказать движку, что рынок ушёл из того состояния, ради которого сюжет начинался.

Второй способ прерваться задан не значением списка, а отдельными переключателями блока условий. Их два: Invalidate On Step 1 (сброс при повторе первого шага) и Invalidate On Any Repeated Step (сброс при любом повторе шага). Оба реагируют на одно и то же событие, на повторное срабатывание уже пройденного шага, но реагируют по-разному. Включаются они независимо друг от друга: можно оставить оба выключенными, включить один или включить оба сразу.

Invalidate On Step 1 следит только за первым шагом. Если условие первого шага срабатывает снова, пока последовательность не дошла до конца, весь прогресс, набранный после первого шага, аннулируется. Дальше начинается тонкость, которую легко пропустить: само это повторное срабатывание засчитывается как новый первый шаг, поэтому движок не возвращается к ожиданию первого шага, а сразу ждёт второй. Пример из документации: первый шаг сработал, движок ждёт второй; второй шаг сработал, движок ждёт третий; здесь снова срабатывает условие первого шага, и движок опять ждёт второй. Документация бэктестера Oscillator Matrix описывает то же правило с другой стороны: этот режим не позволяет условию первого шага срабатывать между остальными шагами последовательности.

Invalidate On Any Repeated Step устроен строже. Здесь под наблюдением все уже пройденные шаги, и срабатывание любого из них вне заданного порядка сбрасывает последовательность полностью: движок возвращается к ожиданию первого шага, а не к ожиданию следующего. Пример из документации: первый шаг сработал, движок ждёт второй; второй шаг сработал, движок ждёт третий; здесь срабатывает условие первого или второго шага, и движок снова ждёт первый. Разница между двумя режимами укладывается в одну фразу: первый откатывает прогресс, второй его обнуляет.

Не путайте ни один из двух режимов со значением Invalidate в списке Step: это отдельное условие, которое всегда возвращает незавершённую последовательность к первому шагу и работает независимо от того, включены ли эти переключатели. Оба режима встретятся дальше по серии, уже в настройках тулкитов, где они собраны в один выпадающий список Invalidation Behavior (режим инвалидации) с третьим значением None для отсутствия сброса, но разобраны они только здесь: Части III, IV и V ограничиваются ссылкой на эту главу. Стоит добавить, что шаги живут не только на входе: в бэктестере Price Action Concepts своё поле Step есть у каждого условия выхода, так что и выход разрешено описать сюжетом. Практический итог главы укладывается в одно предложение: без шагов вы описываете состояние рынка, с шагами вы описываете его историю.

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

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

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

Цена заявки задаётся одним из шести способов, и набор одинаков во всех трёх бэктестерах: Price, Currency, Ticks, %, ATR (средний истинный диапазон) и Forecast (прогноз). Первый способ буквальный, ордер стоит на введённой цене. Все остальные считаются как смещение от точки, в которой сработало условие входа, поэтому одно и то же значение на разных инструментах даёт разное расстояние. Важная деталь: любой метод, кроме Price, сам разворачивается в нужную сторону в зависимости от типа ордера, и вручную знак ставить не надо. Отрицательное значение эту автоматическую ориентацию переворачивает, и лимит для лонга окажется выше рынка. Метод Forecast остаётся мёртвым, пока прогноз не включён, и ему посвящена глава 12.

Цена заявки назначается не один раз. Она пересчитывается на каждом баре, где условие входа снова истинно, и продолжает обновляться, пока ордер не исполнен. У условия, которое держится долго, лимитный уровень будет ползти вслед за ценой, и сделка откроется совсем не там, где вы её задумывали при первом срабатывании.

Отрисовка помогает восстановить эту историю. Лимитный ордер рисуется точечной линией, стоп-ордер пунктирной, а точка на линии отмечает каждый бар, на котором условие было истинно и цена заявки обновилась. Густой ряд точек означает, что условие срабатывало почти непрерывно, одиночная точка что оно сработало один раз и не повторилось. Это единственный способ увидеть глазами, сколько раз стратегия хотела войти до того, как ей это удалось.

Последний переключатель блока входа называется Don't Allow Trades Until Closed (запрет новых сделок до закрытия текущей) и настраивается отдельно для длинной и для короткой стороны. Настроенный с двух сторон, он делает ровно то, что обещает: пока позиция открыта, новых входов не будет. Настроенный с одной стороны, он создаёт ловушку. Если запрет включён только на лонгах, открытый лонг действительно заблокирует новые шорты, но обратное не работает: новый лонг по-прежнему способен закрыть открытый шорт, перевернув позицию. В статистике это выглядит как обычный выход по стратегии, хотя ни одно условие выхода не срабатывало.

Выходов в бэктестере два независимых контура, и понимание этой независимости важнее любой отдельной настройки. Первый контур это группа EXIT CONDITIONS (условия выхода): позиция закрывается, когда происходит событие. Второй это группа FIXED TPS & SLS (фиксированные TP и SL): позиция закрывается, когда цена доходит до заранее назначенного уровня. Контуры работают одновременно и ничего не знают друг о друге, поэтому сделку закрывает тот, кто сработал раньше.

Условные выходы разделены на два смысловых класса, и различие между ними не в механике, а в знаке результата. Exit Take Profit закрывает позицию, когда условие выполнено и закрытие оказывается в прибыли. Exit Stop Losses закрывает её, когда условие выполнено и закрытие оказывается в убытке. Срабатывают они одинаково, у каждого есть вариант для длинной и для короткой стороны, и каждый строится как сравнение выхода внешнего индикатора с заданным значением.

Операторов сравнения здесь тоже шесть, и они того же вида: больше, меньше, равно и три варианта пересечения, хотя в списках выходов пересечения подписаны иначе, чем во входе. Вместо числа в поле сравнения можно подставить ценовой плейсхолдер: open, high, low, close, hl2, ohlc4, hlc3, hlcc4. Пример из документации именно такой: выход из длинной позиции в прибыль, когда цена закрытия пересекает верхнюю границу полосы Боллинджера. Отдельная оговорка источника легко теряется, а стоит дорого: внешним источником здесь предполагается осциллятор. Оверлейному индикатору нужен собственный скрипт, возвращающий приведённое значение, иначе сравнение пойдёт не с тем, с чем вы думаете.

Два выхода существуют только в бэктестере Signals & Overlays, потому что только у него есть собственный алгоритм сигналов. Builtins Exits (встроенные выходы) отдают закрытие позиции на откуп этому алгоритму, а Exit On Signal (выход по сигналу) закрывает позицию на любом новом сигнале. У первого есть свойство, которое надо держать в голове при чтении любой статистики: встроенные выходы по устройству закрывают позицию только в прибыль и убыточную сделку не закроют никогда.

Остальные три настройки есть во всех трёх бэктестерах. Time Exits (выход по времени) закрывает сделки в заданное время суток, причём не внутри бара: исполнение приходится на открытие следующего. Часовой пояс берётся у символа графика, а не у вас, и на инструменте с чужой сессией заданный час окажется не тем, что вы имели в виду. Exit On Entry (выход по встречному входу) закрывает позицию, когда срабатывает условие входа в противоположную сторону. Partial Exits (частичный выход) работает только при значении строго меньше 100%: тогда одно событие закрывает часть позиции, выходы становятся ступенчатыми, и одна сделка распадается на серию частичных закрытий.

Второй контур задаётся четырьмя слотами: длинный тейк-профит, короткий тейк-профит, длинный стоп-лосс, короткий стоп-лосс. У каждого свой метод и своё значение. Точка отсчёта для всех методов со смещением одна и та же: цена закрытия бара, предшествующего входу. Заявка привязана к цене до входа, а не к цене исполнения, поэтому фактический выход может оказаться чуть в стороне от заданного уровня. Методов семь. Пять общих: Price, Currency, Ticks, % и ATR. Метод Forecast доступен только тейк-профиту, метод Trailing Stop (трейлинг-стоп) только стоп-лоссу.

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

Настройка Only Exit On A Profit (выход только в прибыль) есть у бэктестеров Price Action Concepts и Oscillator Matrix. Сама по себе она выглядит безобидно: она запрещает выходы, которые зафиксировали бы убыток. В связке с запретом новых сделок до закрытия текущей и при отсутствующем стоп-лоссе она даёт результат, который надо назвать прямо. Убыточная позиция не закрывается, потому что выход запрещён, а новых сделок нет, потому что позиция открыта. Стратегия держит эту позицию бесконечно, все закрытые сделки оказываются прибыльными, и винрейт стремится к 100%. Источник называет такой сценарий нереалистичным, точнее назвать его ошибкой измерения.

Группа настроек называется FORECAST, и её содержимое стоит на границе между аналитикой и самообманом. Переключатель Show Forecast (показывать прогноз) рисует на графике проекцию цены, начинающуюся сразу после последней сделки стратегии. Выглядит это как предсказание рынка, а является описанием собственного прошлого стратегии, и вся глава про то, почему разница здесь существенна.

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

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

Горизонт ограничен сверху настройкой Forecasting Length (длина прогноза), но фактическая длина может оказаться меньше заданной, потому что она зависит от средней длительности сделки. У высокочастотной стратегии прогноз получится коротким, сколько бы баров вы ни попросили. Maximum Forecast Memory (глубина памяти прогноза) определяет, как далеко назад заглядывает расчёт: малое значение делает прогноз реактивным и чувствительным к последним сделкам, большое стабильным и медленным.

У прогноза два потребителя, и оба уже встречались в этой части. Первый: значение Forecast в списке методов длинного и короткого тейк-профита из главы 11, где уровень берётся как перцентиль прогноза. Второй: значение Forecast в методах цены лимитных и стоп-ордеров на входе из главы 10. Перцентиль задаётся числом от 0 до 100, и значения вне этого диапазона просто не работают. Чем меньше перцентиль, тем ближе тейк-профит к цене входа для длинной позиции и тем дальше для короткой.

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

Оптимизатор существует только в бэктестере Signals & Overlays. У двух других бэктестеров его нет вовсе, у них нет даже соответствующей страницы в документации, так что искать его в настройках бесполезно. Причина простая: перебирать он умеет ровно одну настройку, и эта настройка принадлежит алгоритму сигналов, которого у двух других скриптов нет.

Перебирается чувствительность, и только она. Никакие другие параметры оптимизатор не трогает, а работает он в том случае, когда сигналы используются как условия входа. Диапазон перебора задаёте вы: значение «от» и значение «до». Для каждого значения внутри диапазона движок прогоняет отдельный бэктест и запоминает его статистику. Отсюда прямое следствие для стоимости расчёта: широкий диапазон, помноженный на длинное окно бэктеста, повышает вычислительную нагрузку и приводит к ошибкам по таймауту.

Оптимизировать можно по одной из пяти метрик. Четыре из них уже знакомы: чистая прибыль, винрейт, профит-фактор и максимальная просадка, у которой направление обратное, потому что меньше значит лучше. Пятая встречается только здесь. Potential Ratio (φ) (коэффициент потенциала) это сумма максимальных потенциальных прибылей, делённая на сумму максимальных потенциальных убытков. Она измеряет не то, что стратегия взяла, а то, что она могла бы взять, и потому ведёт себя иначе, чем профит-фактор: высокий коэффициент потенциала при скромной чистой прибыли означает, что движение было, а стратегия его не удержала.

Warmup Period (период прогрева) это число баров до начала окна бэктеста, на которых алгоритмы сигналов считаются заранее. Настройка выглядит второстепенной, но без неё сигналы в начале окна будут отличаться от тех, что показал бы сам тулкит на том же графике, потому что алгоритму нужна история. Optimization Dashboard (панель оптимизации) выводит по строке на каждое значение чувствительности из диапазона, со статистикой соответствующего прогона, отсортированной по убыванию оптимизируемой метрики. Простой режим панели сворачивает всё это до одной строки: лучшее значение чувствительности и достигнутая на нём метрика.

Выключается оптимизатор тремя способами, и два из них неочевидны. Первый: расположение панели переведено в значение None, то есть скрытая панель означает и отключённый расчёт. Второй: включён автопилот, который подбирает чувствительность сам и потому несовместим с перебором. Третий: окно бэктеста отключено или переведено в режим Entire History. Если панель не появилась, проверять надо именно эти три места, а не диапазон значений.

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

Всё, что описано до этой главы, задаётся мышью: переключатель, выпадающий список, числовое поле. У бэктестера есть и второй вход, текстовый. Strategy Scripting это собственный язык LuxAlgo, на котором стратегия описывается строками, а рыночные данные и состояние счёта подставляются в них по именам. Pine Script® для этого не нужен, текст разбирает сам бэктестер, и работает язык во всех трёх скриптах. Текстовая запись снимает главное ограничение интерфейса, фиксированное число слотов условий.

Родство здесь важнее новизны. Strategy Scripting это тот же язык, что Alert Scripting в тулкитах, только повёрнутый в сторону бэктестинга: там условие поднимало оповещение, здесь оно открывает и закрывает позиции. Отсюда следует и то, где искать справку. Полный разбор синтаксиса, операторов сравнения и построения последовательностей вынесен в Часть VI, а здесь разбирается специфика бэктестеров. Заодно отметим состояние источника: карточка операторов в разделе бэктестеров не открывается по своему адресу, и полный справочник приходится искать в дереве документации Alert Scripting.

Плейсхолдер это запись вида {название}, которая на каждом баре превращается в число или в логическое значение. Категорий шесть: рыночные данные, время, статистика стратегии, внешние источники, пользовательские определения и триггерные события конкретного бэктестера. К любому плейсхолдеру можно обратиться в прошлое индексом в квадратных скобках: {close[1]} это закрытие предыдущего бара, {close[14]} закрытие четырнадцать баров назад.

Рыночных плейсхолдеров одиннадцать: четыре цены бара, четыре производные цены, объём, диапазон и истинный диапазон. Временных пятнадцать, включая сессионный {hhmm-hhmm}, истинный, пока бар попадает в заданный интервал суток, и плейсхолдер даты {YYYY-MM-DDThh:mm:ss±hh:mm}. Со временем связаны четыре тонкости, и каждая способна тихо испортить расчёт. {dayofweek} считается по времени открытия бара, поэтому на ночных сессиях значение оказывается на единицу меньше фактического торгового дня. Плейсхолдер даты игнорирует настройку часового пояса и работает в UTC-0. {unix_ts} устарел, вместо него пишут {time}. {timeframe} выражается в минутах.

Двадцать два плейсхолдера статистики стратегии остаются самой недооценённой категорией. Они возвращают состояние симулированного счёта: размер позиции, среднюю цену входа, накопленную просадку, винрейт, профит-фактор. Условие на них описывает не рынок, а поведение самой стратегии, например запрет входить, пока просадка превышает порог. Внешних плейсхолдеров ровно три, {external1}, {external2} и {external3}, тогда как в Alert Scripting их пять: одно из немногих расхождений двух диалектов.

Триггерные плейсхолдеры это события самих тулкитов, и они привязаны к своему бэктестеру: имена Signals & Overlays понимает только бэктестер Signals & Overlays. Перечни в источнике длинные, но читаются по одному правилу: имя складывается из направления, названия функции и характера события. Ниже приведены объёмы и принцип, а за точными строками стоит идти на страницу плейсхолдеров.

Пользовательский плейсхолдер объявляется знаком равенства: {имя} = условие. Дальше он ведёт себя как встроенный, включая индекс истории, и это позволяет описать паттерн один раз, а потом ссылаться на него в нескольких действиях. Пример из документации собирает бычий FVG из трёх сравнений и требует, чтобы условие оставалось истинным два бара подряд.

Действие это то, что язык делает с позицией. Синтаксис единообразный: знак @, ключевое слово, круглые скобки, знак равенства и условие. Действий восемь, и они закрывают весь жизненный цикл стратегии: входы, выходы, аварийное закрытие, границы периода расчёта и выключатель. Аргументы задают детали. limit превращает вход в лимитный ордер, stop в стоп-ордер, оба вместе в стоп-лимитный. qty закрывает часть позиции, в единицах или в процентах с суффиксом %, а без него закрывается вся позиция. alert_message задаёт текст оповещения.

Два действия стоят отдельного внимания. @exit_all() закрывает вообще всё, включая позиции, открытые условиями из интерфейса. @only_scripted() при истинном значении заставляет стратегию игнорировать неписаные условия входа: это и есть выключатель, изолирующий скрипт от того, что набрано в слотах. Момент исполнения по умолчанию и для входов, и для выходов это открытие следующего бара; переключатель Fill on bar close (исполнение на закрытии бара) переносит исполнение на закрытие текущего.

Аббревиатура LUCID расшифровывается как LuxAlgo Universal Conditions Identifier, а в интерфейсе стоит уже без расшифровки, в подписях выпадающих списков. LUCID Connector (коннектор LUCID) делает то, чего иначе сделать нечем: пробрасывает триггерные плейсхолдеры одного тулкита внутрь бэктестера другого. Структурное событие Price Action Concepts, состояние облака Neo Cloud и порог силы тренда из Signals & Overlays складываются в одно условие входа.

Порядок настройки жёсткий. Оба скрипта, тулкит-источник и бэктестер, должны стоять на графике одновременно. Нужная функция должна быть включена в тулките-источнике, иначе её плейсхолдер ничего не вернёт. В настройках бэктестера открывается раздел CONDITIONS (ADVANCED) (расширенные условия), и в списке с подписью нужного тулкита выбирается выход его коннектора. Минимальные версии оговорены отдельно: тулкиты Signals & Overlays 7.0, Price Action Concepts 3.0 и Oscillator Matrix 7.0, бэктестеры соответственно 3.0, 2.0 и 2.0.

Алерты бэктестера срабатывают не на сигналах тулкита, а на действиях стратегии: открытии и закрытии позиций. Реализованы они одинаково во всех трёх скриптах. Раздел настроек Alert Messages (тексты алертов) содержит по текстовому полю на каждое действие, и поля разложены по двум группам: Buy Alerts (алерты по длинной стороне) и Sell Alerts (алерты по короткой стороне). Оставленное пустым поле означает, что уйдёт сообщение стратегии по умолчанию, а заполненное подменяет его целиком. У бэктестера Price Action Concepts набор беднее: отдельных алертов на выход по тейк-профиту и по стоп-лоссу у него нет, есть только общие Exit Long и Exit Short.

В тексте работают двенадцать плейсхолдеров, и подстановка происходит в момент срабатывания. Два из них стоит различать заранее. {ticker} возвращает символ без префикса биржи, {prefix} только сам префикс, и если платформа на другом конце ожидает полное имя, собирать его придётся вручную. Пара {time} и {timenow} различается лишь при включённом Recalculate on every tick (пересчёт на каждом тике), который живёт в настройках стратегии по пути Properties > RECALCULATE. Без него оба плейсхолдера дают одно и то же значение, и разница обнаруживается только на живом алерте.

Дальше идёт деталь, из-за которой чаще всего звучит жалоба «алерт работает, но приходит не то». Текст, набранный в настройках бэктестера, не попадает в уведомление сам: в поле сообщения диалога алерта TradingView должна стоять строка {{strategy.order.alert_message}}. Без неё уйдёт стандартное описание сделки, а ваши плейсхолдеры останутся неиспользованными. Из предыдущей главы сюда тянется прямая линия: аргумент alert_message в действиях Strategy Scripting делает ровно то же самое, только из кода, и требует той же строки в диалоге.

AI Strategy Alerts (алерты по AI-стратегиям) устроены иначе, чем алерты из предыдущей главы. Они живут на платформе LuxAlgo, а не в TradingView, и привязаны не к вашему скрипту на графике, а к стратегии из базы. Точек входа в создание ровно две: значок будильника рядом со стратегией, которую вернул ассистент, и та же операция из сохранённой стратегии в боковой панели. Меню настройки открывается до создания, готовый алерт подтверждается кнопкой Create и попадает в боковую панель алертов. Меню из трёх точек у каждой строки даёт три действия: Edit, Pause, Delete. Правка применяется только к будущим срабатываниям, приостановка алерт не удаляет.

Словарь событий закрыт и состоит из четырёх значений: long, short, exit long и exit short. Пользовательских условий здесь нет и по устройству быть не может: алерты ограничены поддерживаемыми тикерами, поддерживаемыми таймфреймами и теми стратегиями, которые уже лежат в базе. Четыре события это четыре независимых переключателя Events (события), и настраиваются они отдельно для канала уведомлений и отдельно для каждого вебхука. Выключенное событие для своего канала просто молчит, тогда как другой канал того же алерта на него реагирует.

Alert message (текст алерта) это свободное многострочное поле, служащее и телом карточки в интерфейсе, и телом письма. Плейсхолдеры здесь пишутся не в фигурных скобках, а в двойных квадратных, и всего их четырнадцать. Вставлять их надёжнее через выпадающий список Placeholders (список плейсхолдеров), который подставляет запись в позицию курсора. Шаблон из документации показывает структуру: название стратегии, событие, тикер, таймфрейм и цена исполнения в одной строке. По-русски она читалась бы так: стратегия с таким именем выдала новый сигнал такого типа по такому тикеру на таком таймфрейме по такой-то цене.

Карточки уведомлений появляются в правом нижнем углу на десктопе и внизу экрана на мобильном, складываясь в стопку: при наведении раскрываются более старые сообщения, при закрытии верхней открывается следующая. Значок шестерёнки на карточке ведёт прямо в редактор этого алерта, превращая уведомление в точку управления. Раздел, где всё это настраивается, называется In-App Notifications (уведомления в интерфейсе). Письма уходят на адрес аккаунта, другого получателя указать нельзя, включает их переключатель Send email (отправлять письмо).

Пределы стоит держать в голове до того, как выстраивать на алертах рабочий процесс. Создание доступно только подписке Ultimate, потолок сто алертов на пользователя, срок жизни отдельного алерта не ограничен. Фьючерсы заслуживают отдельной строки: стратегии на них работают на потоке данных в реальном времени, задержки в пятнадцать минут у них нет. Доставка при этом ничем не гарантирована: под нагрузкой сообщение может опоздать или не прийти вовсе.

Раздел WEBHOOKS находится в том же меню алерта, что и уведомления, и наполняется кнопкой + New. Webhook URL (адрес вебхука) обязателен и проверяется на синтаксическую корректность; пока корректного адреса нет, переключатель самого вебхука недоступен. События у вебхука свои, те же четыре независимых переключателя. Payload (тело запроса) необязателен и принимает только JSON: пустое поле отправляет {}. Некорректный JSON подсвечивается прямо в поле, однако отправится ли такой вебхук, источник не уточняет.

Дальше идёт правило, которое ломает больше интеграций, чем все прочие вместе. Плейсхолдер считается валидным только тогда, когда он стоит внутри двойных кавычек, то есть как строка JSON. Это верно и для тех плейсхолдеров, у которых документированный тип числовой или временной: запись "price": [[strategy_order_price]] недопустима, правильная форма "price": "[[strategy_order_price]]". Принимающая платформа приведёт строку к числу сама, если ей это нужно.

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

Templates (шаблоны) готовы для четырёх платформ. TradersPost обслуживается одним вебхуком со всеми четырьмя включёнными событиями, а направление ордера задаёт плейсхолдер действия. Для фьючерсов меняется единственное поле: тикер передаётся кодом контракта с четырёхзначным годом, потому что именно такой формат ожидает платформа. Поле quantity заполняете вы, автоматически размер позиции не считается.

У 3commas сценария два, и различаются они типом бота. Сигнальный бот типа стратегии TradingView обслуживается одним вебхуком со всеми событиями и тем же плейсхолдером действия. Бот типа custom signal с направлением Reversal требует четырёх вебхуков с одинаковым адресом: у каждого включено ровно одно событие, а значение поля action задано жёстко. Тело запроса во всех четырёх одинаково, меняется только эта строка. Значения secret, bot_uuid и order.amount подставляете вы сами.

Боты Cornix привязаны к направлению, поэтому вебхуков нужно столько, сколько направлений вы торгуете, и в каждом включено ровно то событие, которое соответствует настройке бота. Тип бота при создании выбирается как TradingView Bot. Discord стоит в этом списке особняком: его вебхук принимает два поля, username и content, и годится для журналирования сигналов в канал, а не для торговли.

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

К этому месту собраны два способа получить цифру и разница между ними. Видно, где результаты ассистента расходятся с TradingView и почему это не чья-то ошибка, а разные определения метрик. Разобрана сборка стратегии из условий, их порядок во времени, назначение уровней выхода и ловушка выхода только в прибыль. Показан язык Strategy Scripting и путь от события на графике до POST-запроса на сервер брокера. Чего в тексте не было, так это смысла самих условий: слова CHoCH, ордер-блок, Smart Trail и HyperWave до сих пор оставались строками в выпадающих списках.

Часть III называется «Price Action Concepts, разметка графика без единой линии от руки», и с неё начинается разбор тулкитов. Структура рынка, объёмные ордер-блоки, имбалансы, съёмы ликвидности, зоны премиума и дисконта, графические паттерны: именно оттуда взяты те тринадцать событий, которыми в этой части заполнялись слоты условий входа, и таблицы триггеров из третьей главы там наконец станут читаемыми. Там же, а не здесь, живут полная механика конструктора пользовательских алертов и общая архитектура алертов тулкитов.

Основой этой части послужили двадцать восемь страниц официальной документации LuxAlgo. Раздел AI Backtesting дал пять страниц: вводную, страницу подбора стратегий, просмотрщик результатов, страницу запросов к базе и страницу устранения неполадок, все внутри docs.luxalgo.com/docs/ai-backtesting/.

Раздел бэктестеров дал девятнадцать страниц. По бэктестеру Signals & Overlays их пять: введение, правила входа, условия выхода, тейк-профиты со стоп-лоссами и оптимизация. По бэктестерам Price Action Concepts и Oscillator Matrix по четыре, страницы оптимизации у них нет. Ещё четыре страницы занимает Strategy Scripting, и отдельно стоят страницы прогноза и алертов. Раздел AI Strategy Alerts дал четыре страницы: введение, создание алертов, уведомления и вебхуки.

Состояние источника стоит назвать честно. Карточка операторов в разделе Strategy Scripting не открывается по своему адресу. Часть страниц бэктестеров не публикует значений по умолчанию, и там, где источник молчит, молчим и мы, а не додумываем. Тип плейсхолдера цены ордера на двух страницах указан по-разному. Условия доступа к ассистенту на разных страницах одного раздела описаны противоречиво, и в тексте мы держались строгой версии. Число девяносто два получено сложением опубликованных таблиц по классам активов: в самой документации оно не названо.

Из внешних материалов источник ссылается на документацию TradersPost, справку 3commas по сигнальным ботам, введение Discord в вебхуки и руководство TradingView по бэктестингу на нестандартных типах графиков. Полный текст оговорки о рисках опубликован по адресу www.luxalgo.com/legal/disclaimer/. Материал сверен с документацией 7 августа 2026 года.