Где расходится стратегия: как найти первую точку расхождения
Финальный P&L показывает, что результат изменился, но редко объясняет причину. Сравниваем данные, решение, заявку, исполнения и позицию по порядку.

Стратегия может показать один результат в бэктесте, сформировать другой сигнал при повторном запуске и прийти к третьему результату на счёте. Обычно проблема проявляется в конце: сделка не совпала, позиция отличается, итоговая статистика изменилась. Но искать причину по финальной доходности поздно. Она только сообщает, что цепочка разошлась.
Полезнее найти первую точку расхождения: самый ранний этап, на котором две версии одного процесса перестали совпадать. До этой точки данные и решения одинаковы. После неё каждое следующее отличие уже может быть следствием первой ошибки.
Для такого разбора нужны не скриншоты итоговой кривой, а связанная последовательность записей: данные, решение стратегии, заявка, исполнение и позиция.
Сначала определите, что именно сравнивается
Фраза «бэктест не совпал с реальной торговлей» слишком широкая. Между историческим тестом и состоянием счёта находится несколько независимых переходов:
- рыночные данные превращаются во вход стратегии;
- код и параметры формируют сигнал;
- сигнал превращается в заявку;
- биржа принимает, отклоняет или частично исполняет заявку;
- исполнения меняют позицию;
- история счёта превращается в статистику.
Сравнивать нужно соседние этапы. Если входные данные различались, нет смысла начинать с биржевого исполнения. Если сигналы одинаковы, но количество в заявке отличается, проблема находится между расчётом позиции и отправкой ордера. Если заявки совпали, а исполнения нет, проверять нужно состояние ордера и биржевой журнал.
Этот подход не доказывает, что стратегия прибыльна. Он помогает понять, где изменился наблюдаемый процесс.
Контрольная точка 1: данные
Одинаковый символ и таймфрейм ещё не означают одинаковый набор данных. Для воспроизводимого сравнения нужно сохранить:
- площадку и тип рынка;
- торговую пару или идентификатор инструмента;
- период и часовой пояс;
- источник свечей, сделок или стакана;
- правила построения свечи;
- пропуски и способ их обработки;
- комиссии, funding и другие издержки, включённые в модель;
- версию загруженного набора.
Простой пример: стратегия принимает решение на закрытии минутной свечи. Один источник включает сделку с временной меткой ровно 10:01:00 в предыдущую свечу, другой — в следующую. Значения OHLC расходятся, индикатор меняется, а вместе с ним меняется сигнал. В этом случае разница появилась до расчёта ордера.
Для расследования полезно сохранить небольшой фрагмент входных данных вокруг спорного события и контрольную сумму файла или снимка. Это позволяет повторить расчёт на том же входе, а не на «похожей истории», скачанной позже.
Контрольная точка 2: решение стратегии
Если данные совпадают, следующая проверка — код, параметры и состояние стратегии в момент решения.
Минимальная запись содержит:
- версию кода;
- набор параметров;
- идентификатор запуска;
- время расчёта;
- входные значения, необходимые для решения;
- получившийся сигнал;
- целевой размер позиции или правило его расчёта.
Здесь важен не только итог «buy» или «sell». Два запуска могут дать одинаковое направление, но разный целевой объём из-за риска на сделку, текущего баланса, округления или состояния уже открытой позиции.
XTester относится именно к этапу исследования и исторического тестирования. Бэктест помогает проверить, как зафиксированные правила повели себя на выбранных данных. Он не подтверждает, что будущий сигнал будет исполнен по модельной цене.
Для проверки устойчивости одного удачного прогона мало. Отдельные out-of-sample участки и последовательная walk-forward проверка помогают увидеть, сохраняется ли поведение стратегии на данных, которые не использовались при подборе параметров.
Контрольная точка 3: заявка и исполнение
Между сигналом и позицией появляется биржевая асинхронность. Ответ на запрос создания ордера не всегда означает, что ордер полностью исполнен. После отправки возможны разные состояния: заявка принята, остаётся открытой, исполнена частично, исполнена полностью, отменена или отклонена.
Для связи решения с биржевым результатом стоит сохранять:
- внутренний идентификатор решения;
- клиентский идентификатор заявки;
- биржевой идентификатор ордера;
- инструмент, сторону, тип, цену и количество;
- время отправки и подтверждения;
- накопленный исполненный объём;
- среднюю цену исполнений;
- конечный статус и причину отказа, если она есть.
Особенно опасен timeout. Отсутствие ответа не доказывает, что биржа не получила заявку. Без повторной проверки слепой retry способен создать второй ордер. Поэтому после неопределённого результата сначала восстанавливают состояние по клиентскому или биржевому идентификатору, а затем решают, нужна ли повторная отправка.
CopyTrader работает на этапе копирования и исполнения. Публичные материалы уже объясняют синхронизацию настроек перед сделкой и влияние глубины стакана на расчётную цену исполнения. Отдельная задача после отправки — сверить целевое состояние с фактическими ордерами и позицией подписчика.
Контрольная точка 4: позиция и статистика
Даже полный список ордеров ещё не равен итоговой позиции. На счёте могли быть ручные сделки, другие стратегии, частичные исполнения, отмены или изменения режима позиции. Поэтому последняя операционная проверка сравнивает:
- какую позицию система ожидала;
- какие заявки она считает активными;
- какой объём уже исполнен;
- какую позицию сообщает биржа;
- какие внешние изменения произошли на счёте.
После этого начинается другой слой — статистика. Доходность, просадка и распределение сделок имеют смысл только вместе с периодом, источником данных, комиссиями и границами выборки. Они описывают то, что произошло на счёте, но сами по себе не восстанавливают причину отдельного расхождения.
EasyTrading рассматривает XTester, CopyTrader и TradeStat как продукты разных этапов. Сейчас их публичные контуры не следует описывать как одну автоматически связанную систему. Общий принцип уже применим: каждый этап должен сохранять собственное доказательство и устойчивую ссылку на предыдущий.
Как провести разбор инцидента
Рабочая последовательность выглядит так:
- Зафиксировать спорный инструмент и узкий временной интервал.
- Сохранить данные и настройки, не перезаписывая исходные записи.
- Сопоставить идентификатор запуска, сигнала, заявки и биржевого ордера.
- Сравнить этапы по порядку: данные → решение → заявка → исполнения → позиция.
- Отметить первое отличие, а не все последующие симптомы.
- Классифицировать причину: данные, логика стратегии, sizing, транспорт, биржевой статус, ручное вмешательство или расчёт статистики.
- После исправления повторить тот же сценарий на сохранённом входе и проверить соседние случаи.
Для команды полезен короткий отчёт: что ожидалось, что наблюдалось, где появилась первая разница, какими записями это подтверждено и какое правило теперь предотвращает повторение. Такой формат лучше общего вывода «сделки иногда не совпадают».
Что даёт связанная цепочка доказательств
Связанная история не устраняет рыночный риск и не превращает бэктест в прогноз. Она даёт более скромный, но проверяемый результат: можно восстановить, как конкретные данные привели к конкретному решению, что было отправлено на биржу и как это изменило позицию.
Если эта связь потеряна, итоговая цифра остаётся без происхождения. Если сохранена, спор можно разбирать с первой точки расхождения, не смешивая качество стратегии, работу инфраструктуры и поведение рынка.
Материал носит образовательный характер и не является инвестиционной рекомендацией. Исторические тесты и техническая сверка не гарантируют будущую доходность или идентичное исполнение.