Backtesting: от гипотезы к проверке

Как я ускорил анализ торговых экспериментов в 18,3 раза, перестроил сложный исследовательский интерфейс и сохранил контроль над настройками, результатами и оптимизацией.

Независимый продукт · Product design и реализация с LLM-инструментами · 2026

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

Я развивал Backtesting как единый инструмент этого цикла. Работа охватила скорость анализа, модель взаимодействия, управление защитными правилами и проверку предлагаемых улучшений. На контрольном журнале анализ ускорился с 79,18 до 4,33 секунды, сохранив результат расчётов.

Замер относится к серверному анализу сохранённого журнала, а не ко всему бэктесту или скорости работы пользователя.

Продуктовая задача и моя роль

Backtesting вырос из инструмента проверки собственных торговых правил в приложение с настройками входов и выходов, управлением капиталом, журналом сделок, аналитикой, историей и многочисленными подборами параметров.

Я отвечал за продуктовую модель, структуру и поведение интерфейса, приоритеты изменений и реализацию с LLM-инструментами. Основным исследовательским контекстом была собственная работа с продуктом и разбор сохранённых запусков.

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

1. Сократить ожидание, сохранив результат

В июльском аудите серверный подбор метрик многократно фильтровал полный журнал для каждой комбинации. Это повторяло одну и ту же работу по тысячам вариантов.

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

В этом замере время ожидания одного анализа сократилось на 74,85 секунды, или 94,5%. Это производные значения из измеренных длительностей. Для проверки корректности также прошли 12 из 12 Rust unit/differential-тестов.

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

2. Организовать интерфейс вокруг исследовательского цикла

Прежние 25 пунктов навигации смешивали редактирование, диагностику и применение изменений. Я собрал их в три направления и 15 групп: 14 тематических и общие инструменты подбора.

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

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

3. Дать непрерывный обзор без лишних обновлений

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

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

Эти числа получены в изолированном Chromium с development React. Они сравнивают промежуточную и оптимизированную версии общего списка; рост FPS или сокращение времени пользовательской задачи по ним не рассчитывались.

4. Сделать защитные правила понятными и проверяемыми

В июльском разборе обнаружилась неоднозначность: параметры переноса стопа были сохранены, но правило оставалось выключенным. Явное включение правила в контрольном повторе изменило результат одной сделки с −40,04 до +1,43 USDT.

В интерфейсе появилось состояние «ВКЛ / ВЫКЛ», исполнение получило метку BE-PATH, параметры стали сохраняться в снимке сделки. Поведение покрыли отдельными long/short-регрессиями.

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

Исследование охватывало DOGEUSDT за 2 мая — 31 июля 2026 года. Для третьего варианта изменение Net PnL относительно исходного составило +101,7%, просадка снизилась на 5,83 процентного пункта, profit factor вырос с 1,62 до 2,85. Это расчёт на периоде подбора с небольшой выборкой; независимой проверки этих параметров на новом периоде в данном отчёте нет.

Продуктовый вывод: сравнение должно показывать прибыль, риск и изменившийся состав сделок вместе. Более высокий win rate сам по себе не определяет лучший вариант.

5. Проверить ценность сложной модели относительно простого варианта

В сентябрьском эксперименте модель Jev оценивала максимальную цель выхода. Набор включал 1 394 сделки по 188 монетам; для оценки использованы 1 387 закрытых сделок, семь открытых исключены.

На 1 385 сопоставимых сделках модель дала 457 точных прогнозов против 450 у исторического baseline: около 33,0% против 32,5%, разница примерно 0,5 процентного пункта. Эксперимент потребовал 1 387 запросов, 2 733 038 входных и 68 680 выходных токенов.

Я также проверил, как предложение модели меняет распределение выходов:

Схема уменьшала историческую просадку, но давала на 42,9% меньше Net PnL. Это ретроспективный пересчёт записанных исполнений: изменение комиссий и проскальзывание заново не моделировались. Результат не дал оснований считать схему улучшением.

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

Результат: изменение всей рабочей системы

Модель настройки, анализа и применения изменений прошла через реализацию, включая совместимость старых настроек и истории. Полноту переноса проверяли по 178 адресам: 175 основным блокам и трём контекстным окнам.

Проверки интерфейса использовали искусственные API/SSE и конфигурации. Они подтверждают поведение заданных сценариев и совместимость; скорость работы людей и снижение числа пользовательских ошибок отдельно не измерялись.

Мой вклад состоял в связке продуктовых приоритетов, модели состояния, интерфейса и реализации. Ускорение анализа проверялось вместе с сохранением результата; новая структура — вместе с сохранением действий; новые торговые варианты — вместе с риском и ценой ошибки.

Следующий цикл развития Backtesting

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

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