Бэктест и paper trading доказывают разные вещи

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

Для чего каждый

Последняя строка решает, стоит ли всё упражнение хоть чего-нибудь.

Издержки должны быть внутри цикла

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

Стратегия, делающая сто сделок в день со средним преимуществом 0,08% при издержках round-trip 0,11%, — это не «прибыльно минус комиссии». Ей вообще не следовало совершать эти сделки. Применённый внутри цикла фильтр издержек их убирает, и оставшаяся выборка — другая, гораздо меньшая стратегия.

# Неправильно: прибыльная кривая со стрижкой в конце.
equity = simulate(strategy, data)
equity -= total_fees                       # сделки, не имевшие смысла, всё равно случились

# Правильно: издержка — часть решения.
def on_signal(sig, book):
    edge  = expected_move(sig)
    cost  = fee_in + fee_out + slippage_estimate(book, sig.size)
    if edge <= cost:
        return skip("преимущество ниже издержек")   # этой сделки не существует
    return trade(sig)

Наш микроструктурный движок формулирует это как проектное правило: если матожидание вне выборки не положительно после комиссий, слиппеджа и стресса по задержкам — система не торгует. И это правило живёт в коде, а не в документе. Калькулятор безубытка — та же мысль в одну строку.

Сетки, а не точечные оценки

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

Стратегия, чья прибыльность рушится между 50 и 150 миллисекундами предполагаемой задержки, — это не стратегия, это ставка на вашу инфраструктуру. Лучше узнать это из сетки, чем из продакшна.

Что ловит paper trading

Paper trading ставит виртуальные ордера против живого стакана. Он не скажет, реально ли преимущество: столько времени его не погоняешь. Он скажет, работает ли ваша программа, — и список того, что он ловит, а бэктест не может, длинный:

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

Один код, три режима

Требование, которое делает обе стадии осмысленными: бэктест, paper и live должны исполнять один и тот же код стратегии и риска, различаясь только адаптером исполнения. Если у бэктеста своя упрощённая обработка ордеров, вы проверили то, что никогда не будет работать.

Наши движки построены именно так: сбор, research, бэктест, paper, live — фазы одной системы с флагом режима, а не разные программы. Практическая выгода в том, что баг, найденный в paper, — это баг в коде, который будет торговать, а исправление проверяется повторным прогоном бэктеста.

Сравнение двоих и есть настоящий тест

Цифра, за которой стоит следить, — не paper-P&L. Это расхождение между paper и бэктестом за один и тот же период. Те же сигналы? Те же цены исполнения в пределах смоделированного слиппеджа? То же число сделок?

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

Порядок и его причина

1. Бэктест с издержками внутри и сеткой задержек. Если преимущество умирает здесь — остановитесь, это дёшево.
2. Paper trading на том же коде. Сравнение с бэктестом, а не с нулём.
3. Testnet ради жизненного цикла ордера: отказы, частичные исполнения, учения по reconnect.
4. Live минимальным объёмом, с предварительно проверенным kill switch.
5. Масштабирование только после того, как live качественно совпал с paper.

Каждая пропущенная стадия сдвигает обнаружение проблемы на более поздний и более дорогой этап. Весь аргумент в этом.