Идеально воспроизводимый бэктест может заслуживать меньше доверия, чем тот, результаты которого немного меняются. Повторяемость доказывает, что вы можете дважды получить один и тот же ответ; она ничего не говорит о том, не зависит ли ответ от произвольного снимка данных, особенностей библиотеки или скрытой настройки по умолчанию.
Звучит как аргумент против воспроизводимости, но это не так. Зафиксируйте запуск, чтобы иметь возможность его объяснить. Затем намеренно меняйте предположения, которые не должны определять результат. Первый шаг делает результат проверяемым, второй показывает, имеет ли он смысл.
Что на самом деле подтверждает воспроизводимый бэктест?
Если один и тот же код, данные, конфигурация и начальное значение генератора случайных чисел дают одинаковые сделки и метрики, значит, вы взяли под контроль важный источник неопределенности. «Улучшение» агента можно сравнить с родительским запуском. Исправление ошибки можно отделить от изменения расписания комиссий. Коллега может изучить тот же реестр и увидеть те же исполнения.
Но результат зависит от всего, что вы зафиксировали. Представьте криптостратегию, для которой в историческом файле хранятся минутные бары. Вы сохраняете хеш файла, фиксируете код и при каждом повторном запуске получаете коэффициент Sharpe 1.4. Если поставщик данных позже скорректирует несколько свечей, эта безупречная воспроизводимость по-прежнему будет описывать старый файл. Она не покажет, сохранится ли сигнал после корректировки истории и были ли эти свечи доступны в таком виде в тот момент.
Хеш полезен: он делает зависимость видимой. Но он не доказывает, что эта зависимость безвредна.
Зафиксируйте запуск; проверьте вывод
Я предпочитаю разделять два вопроса. Можем ли мы восстановить именно этот запуск? И сохраняется ли вывод исследования при разумных изменениях? Для первого нужна неизменяемая запись, для второго — контролируемые изменения по одному за раз.
| Что записать | Что варьировать после этого | Что это может показать |
|---|---|---|
| Версию исходных данных и контрольные суммы | Редакцию поставщика или второй источник | Зависимость от скорректированных или специфичных для поставщика значений |
| Коммит кода и версии пакетов | Численно эквивалентную реализацию | Чувствительность к порядку операций, округлению или библиотеке |
| Комиссии, финансирование и предположения об исполнении | Обоснованный диапазон издержек | Требует ли небольшое преимущество исключительно благоприятного исполнения |
| Состав рынка и принадлежность к нему на конкретный момент времени | Альтернативные правила отбора допустимых рынков | Зависимость от решений о включении или исключении инструментов |
Например, предположим, что при базовом воспроизведении фьючерсная стратегия показывает избыточную годовую доходность 8%. Запустите ее заново с издержками taker на 25% выше, перенесите учет финансирования на следующий наблюдаемый расчет и поочередно исключите два инструмента с наибольшим вкладом. Это не три способа улучшить модель, а проверки: каждая показывает, не держится ли главный результат на правдоподобной детали.
Проводите каждую проверку отдельно. Если одновременно изменить данные, расписание комиссий и время исполнения, ухудшение результата мало что объяснит. А если проверяемый сценарий неправдоподобен, обозначьте его как стрессовый, а не представляйте как вероятный исход.
Не путайте побайтовое совпадение с численной точностью
Некоторые вычисления чувствительны к порядку операций. Сложение чисел с плавающей точкой неассоциативно, поэтому суммирование множества небольших значений P&L в другом порядке может изменить последние цифры. На точный результат также могут влиять параллельные вычисления, оборудование и версии библиотек. Обычно это безвредно; иногда крошечное численное изменение пересекает порог, меняет позицию и направляет оставшуюся часть симуляции по другому пути.
Поэтому я бы сохранял и точные артефакты, и допуски для сравнения. Записывайте реестр сделок, а не только итоговый Sharpe. Сначала сравнивайте решения и денежные потоки, затем метрики в пределах заданного допуска. Если разница в один цент меняет решение о подаче заявки, отдельно изучите эту границу.
Полезная запись о запуске содержит идентификаторы данных и кода, конфигурацию, начальное значение генератора случайных чисел, среду исполнения и достаточно промежуточных результатов, чтобы проследить путь от метрики до исполнений и денежных потоков. Одной итоговой оценки недостаточно, чтобы артефакт исследования был воспроизводимым.
Когда изменения — это шум, а когда — вывод
Не каждое изменившееся число — повод для тревоги. Небольшое колебание метрики из-за другого порядка суммирования может не затронуть сделки. Изменившуюся сделку вблизи порога стоит проверить. Если после того, как поставщик пересматривает небольшой фрагмент истории, стратегия теряет большую часть результата, это говорит о ее хрупкости, даже если исходный запуск остается совершенно воспроизводимым.
Критики проверок на устойчивость правы в одном: легко менять предположения, пока желаемая стратегия не начнет выглядеть устойчивой, или отвергнуть надежный результат из-за специально экстремального сценария, в котором он ломается. Заранее определите правдоподобные варианты, опубликуйте результаты для всего набора и отделяйте обычные альтернативы от стрессовых сценариев. Затем сохраните базовый вариант, чтобы другой исследователь мог в точности воспроизвести увиденное вами.
Воспроизводимость дает надежную отправную точку. Дальше нужно задать полезный вопрос: какие части ответа остаются неизменными, когда окружающий этот запуск мир меняется так, как можно было разумно ожидать?
← Все статьи
