Разработка отчётов бэктестов: Sharpe, drawdown, P&L метрики

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

Бэктестинг почти всегда выглядит лучше живой торговли, и это не совпадение. Отчёт строится на истории, где нет отказов, задержек и неисполненных заявок. Разрыв между кривой в отчёте и фактической эквити — это не «рынок изменился», а конкретные допущения, заложенные в модель.

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

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

Третий — разные правила подсчёта метрик. Sharpe, drawdown и P&L считают по дневным доходностям или по сделкам, по закрытым позициям или по внутридневной эквити, с реинвестированием или без, с учётом финансирования и дивидендов или в вакууме. Две команды на одном наборе данных получат разные цифры, и оба отчёта будут формально верны.

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

Что меняется, когда метрики считаются по единым правилам

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

• Единый источник сделок: комиссии, проскальзывание и ставка финансирования подтягиваются из одного хранилища, а не вписываются руками в таблицу.
• Один расчётный контур: доходность, коэффициент Шарпа и максимальная просадка считаются общей библиотекой; смена периода или набора инструментов не меняет формулу.
• Воспроизводимость расчётов: вместе с отчётом сохраняются снимок данных, список инструментов и параметры прогона — результат повторяется на другой машине без правок.
• Сверка с фактом: исторический отчёт сравнивается с журналом исполненных сделок, и расхождение объясняется издержками исполнения, а не ошибкой в коде.
• Контроль данных: пропуски, дубликаты и разрывы котировок отсекаются до расчёта, а не всплывают потом в кривой доходности.
• Риск рядом с доходностью: просадка, время восстановления и доля прибыльных сделок идут в том же отчёте, что и рост капитала.

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

Форматы отчётов бэктестинга: сравнение подходов

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

Варианты и их ограничения

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

Порядок работ: от постановки метрик до регулярного бэктестинга

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

1. Аудит истории сделок. Выгружаем сделки и движения средств, сверяем с биржевыми отчётами, помечаем пропуски и дубли. Фиксируем часовой пояс, комиссии и корректировки — без этого доходность искажается на ровном месте.

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

3. Настройка расчётного контура. Хранилище истории, справочник инструментов и сервис, который собирает отчёт по запросу и по расписанию на одних и тех же правилах.

4. Проверка сходимости. Прогоняем эталонный период и сверяем с независимым пересчётом. Каждое расхождение либо объясняем, либо устраняем — иначе метрике нельзя верить.

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

6. Регламент регулярного запуска. Расписание пересчёта, версионирование конфигураций и оповещение о сбое: результат не зависит от того, кто и когда запустил отчёт.

Дальше бэктестинг становится рутиной — новые сделки попадают в отчёт по расписанию, а эффект изменений в стратегии виден на сравнении периодов.

Что передаём на руки: схемы, правила расчёта и регламенты

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

• Описание метрик и допущений — формулы Sharpe, drawdown и P&L, окно доходности, базовая ставка, что считаем безрисковой доходностью и почему именно так.
• Схемы расчёта — цепочка от сырых котировок до итоговой таблицы: где чистим данные, где агрегируем, на каком шаге появляется каждая метрика.
• Правила обработки аномалий — пропуски в ряду, выбросы, разрывы на неторговых днях, корпоративные события: когда данные исключаются, когда интерполируются и что попадает в журнал расчёта.
• Инструкции по запуску — параметры окружения, порядок шагов, точка входа и ожидаемое время пересчёта на историческом периоде.
• Регламент проверки отчёта — эталонный прогон, контрольные суммы по метрикам и перечень расхождений, которые считаются ошибкой, а не нормой.
• Шаблоны отчётности — формат выгрузки, состав полей, периодичность и порядок передачи результатов в риск-контроль и руководству.
• Журнал изменений методики — версия конфигурации к каждому отчёту, чтобы сравнение между периодами оставалось корректным.

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

Кейс: как отчёт бэктестинга перестал расходиться с фактом

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

Собрали единый расчётный модуль: одна модель сделки, один зафиксированный набор допущений, версия модели печатается в шапке отчёта рядом с самими метриками. Методику привели к требованиям GIPS — расчёт стал воспроизводимым: тот же вход и та же версия модели дают тот же Sharpe, ту же просадку и тот же P&L у любого инженера команды.

Что изменили

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

Почему просадка в отчёте меньше, чем в реальной торговле

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

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

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

Технические сомнения по расчёту метрик и отчётности

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

Ниже — инженерные вопросы, которые чаще всего поднимаются до старта работ.

Как часто пересчитывается отчёт и насколько это дорого?

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

Какие метрики считаются спорными и как снимается разночтение?

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