Бэктест стратегии на криптовалюте: как проверить идею без подгонки под историю

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

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

Эта статья продолжает материал OneMagic про технический анализ криптовалют, но не повторяет индикаторы и графические паттерны. Здесь фокус уже другой: как превратить торговое правило в воспроизводимый эксперимент. Базовую механику ордеров и торгового плана удобнее сначала разобрать в инструкции как торговать криптой, а затем тестировать именно формализованные правила.

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

Что такое бэктест и какой вопрос он действительно должен решать

Увеличить

Бэктест — это эксперимент, а не доказательство будущей прибыли

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

Поэтому результат теста нужно читать как набор свидетельств о поведении правила, а не как сертификат доходности. Сильная стратегия должна объясняться экономически или поведенчески, выдерживать ухудшение параметров и сохранять разумные свойства вне участка, на котором её настраивали. Если смысл стратегии сводится к тому, что «эта комбинация параметров дала лучший Sharpe в прошлом», исследование ещё не закончено.

Сначала формулируют гипотезу, затем открывают пространство параметров

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

Чем больше решений принимается уже после того, как исследователь увидел equity curve, тем выше риск data mining. Если сначала протестировать сотни индикаторов, затем выбрать лучший, потом подобрать таймфрейм и ещё после этого оптимизировать стоп, финальный результат отражает не только рыночный эффект, но и количество попыток. В QA исследования полезно хранить журнал всех протестированных вариантов, а не только победителя.

Торговое правило должно быть однозначным

Фраза «покупать на сильной поддержке» непригодна для строгого бэктеста, если поддержка определяется глазами постфактум. Нужна вычислимая формулировка: например, минимальная цена последних N завершённых баров, подтверждение закрытием, конкретный лимит риска и правило обработки гэпа или проскальзывания. Однозначность нужна не ради красоты кода, а чтобы один и тот же набор данных всегда давал один и тот же набор решений.

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

Сравнивайте стратегию с простым baseline

Абсолютная прибыль сама по себе мало говорит о ценности торгового правила. В сильном бычьем рынке почти любая long-only система может показать рост. Поэтому нужен baseline: buy-and-hold, постоянная денежная позиция, простой трендовый фильтр или другая минимальная модель, соответствующая задаче. Если сложная стратегия не улучшает риск-профиль относительно простого baseline после расходов, дополнительная сложность может не иметь смысла.

Сравнение должно использовать одинаковую начальную сумму, одинаковую валюту учёта и сопоставимый период. Для оценки результата полезно понимать механику PnL в криптотрейдинге: realized и unrealized результат, комиссии и денежные потоки нельзя смешивать в одну красивую процентную цифру.

Бэктест стратегии и бэктест инфраструктуры — разные задачи

Стратегический тест проверяет гипотезу: когда входить, когда выходить и сколько риска брать. Инфраструктурный тест проверяет, способен ли код воспроизводить эти решения без ошибок состояния. Один и тот же сигнал может выглядеть устойчиво на исторических данных, но торговый бот способен потерять деньги из-за duplicate order, пропущенного partial fill или рассинхронизации баланса. Поэтому успешная стратегия ещё не означает готовую автоматизацию.

Эту границу важно сохранять и в обратную сторону. Надёжный execution engine не превращает отрицательное математическое ожидание в положительное. Материал про крипто-ботов и их безопасность отвечает за права и подключение, а исторический тест — за качество самой торговой логики.

Что считать успешным результатом исследования

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

До запуска теста полезно определить критерии продолжения: минимальное число независимых сделок, допустимый drawdown, диапазон устойчивых параметров, положительный net expectancy после стрессовых расходов и приемлемое поведение на out-of-sample. Если критерии придумываются после результата, они уже не являются независимым фильтром.

Данные для бэктеста: как не подмешать будущее в прошлое

Увеличить

Point-in-time данные важнее идеальной полноты

Для честной симуляции каждый информационный элемент должен появляться в модели не раньше, чем он стал доступен участнику рынка. Это называется point-in-time подходом. Для OHLCV-свечей правило кажется очевидным, но ошибки возникают даже здесь: сигнал, рассчитанный по close текущей свечи, нельзя исполнять по цене открытия той же свечи. Close известен только после завершения периода.

Чем больше источников подключено, тем сложнее временная дисциплина. Funding, open interest, on-chain метрики, новости, листинги и индексы могут публиковаться с задержкой. Если историческая база хранит уже исправленное или агрегированное значение без времени фактической публикации, тест способен получить информацию раньше реального трейдера.

Нужно определить, что означает timestamp

Один провайдер может маркировать минутную свечу временем начала интервала, другой — концом. Если код считает, что timestamp 10:00 означает уже завершённую свечу 10:00–10:01, а источник на самом деле обозначает её начало, возникает скрытый look-ahead. Перед тестом документируйте semantics времени: timezone, open time, close time, время фактической доступности бара и правила перехода на летнее время там, где это применимо.

Крипторынок торгуется 24/7, но это не отменяет календарные границы. Дневная свеча зависит от выбранного UTC cutoff. Стратегия, основанная на дневном закрытии, может показывать разные результаты при разных временных границах. Если эффект исчезает при небольшом сдвиге cutoff, он может быть артефактом построения данных.

OHLC-свеча не раскрывает порядок событий внутри бара

Если на одной часовой свече high касается take-profit, а low — stop-loss, из OHLC нельзя узнать, что произошло раньше. Тест, который всегда выбирает выгодный порядок, систематически завышает результат. Нужны более мелкие данные, консервативное правило при неопределённости или отдельная intrabar-модель.

Особенно критична эта проблема для коротких стопов и стратегий с несколькими ордерами. Чем ниже дистанция до уровней относительно диапазона свечи, тем меньше доверия к симуляции на грубом таймфрейме. Для понимания механики стопов полезно отдельно разобрать stop-loss и take-profit.

Текущий список монет создаёт survivorship bias

Один из самых опасных криптоспецифичных перекосов — тестировать прошлое только на токенах, которые существуют и ликвидны сегодня. Победители пережили делистинги, закрытия проектов, миграции и обнуление спроса; проигравшие исчезли из удобного текущего списка. Если стратегия в прошлом «выбирает топ-20 сегодняшних монет», она фактически знает будущее.

Для cross-sectional и multi-asset тестов нужен исторический universe: какие активы реально существовали, были доступны и удовлетворяли фильтрам на каждую дату. Делистинг должен быть событием модели, а не удалением плохой строки из датасета. Тот же принцип подробно проявляется в DCA: тест только на нынешних победителях завышает устойчивость регулярной покупки.

Листинг и начало истории не всегда равны моменту реальной торговли

Первые свечи молодого токена могут содержать тонкую ликвидность, временно неработающие депозиты, аномальный spread или ограниченное число площадок. Исторический агрегатор может построить красивый ряд, но реальное исполнение крупного объёма в первые часы было невозможно. Для нового актива полезно вводить minimum history, liquidity filter и задержку после листинга.

Если стратегия использует рейтинг по объёму или капитализации, фильтр тоже должен быть point-in-time. Нельзя применять сегодняшние категории рынка к истории. Общие принципы того, как устроены капитализация и ликвидность, раскрыты в материале о рынке криптовалют.

Данные разных площадок нельзя смешивать без правил

Цена BTC или ETH на разных площадках обычно близка, но не идентична. Для малоликвидных токенов расхождения могут быть значительными. Если сигнал рассчитывается по индексу, а исполнение моделируется по одной конкретной площадке, нужно синхронизировать источники и явно учесть basis. Если стратегия использует high с одного venue и якобы исполняется по low другого, симуляция создаёт несуществующую ликвидность.

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

Пропуски, дубликаты и ошибочные свечи нужно обрабатывать до исследования

Missing bars нельзя молча заполнять последней ценой, если это влияет на индикаторы и входы. Дубликаты могут удваивать объём или число сигналов. Аномальная свеча из-за bad tick способна создать фантастический вход или стоп. Поэтому data QA — часть стратегии, а не техническая уборка после исследования.

Полезный pipeline сначала проверяет монотонность времени, уникальность ключа symbol+timestamp, отрицательные и нулевые значения, логические связи high≥open/close и low≤open/close, резкие выбросы и ожидаемое число интервалов. Все автоматические исправления должны логироваться.

Для деривативов нужны funding, mark price и правила инструмента

Бэктест perpetual futures, который использует только последнюю цену, неполон. Реальный результат зависит от funding payments, leverage, maintenance margin, mark/index price и возможной ликвидации. Для short-позиций на других инструментах могут добавляться borrowing constraints. Чем сложнее продукт, тем больше параметров исполнения нужно моделировать.

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

Как не допустить look-ahead bias в сигналах и исполнении

Сигнал на закрытии свечи исполняется после закрытия, а не раньше

Классическая ошибка выглядит невинно: индикатор рассчитывается по close свечи, а сделка записывается по этому же close. В реальности точное значение close известно лишь после завершения бара, а заявка отправляется позже. Если стратегия рассчитана на минутных данных, даже небольшая задержка способна изменить fill. В корректной модели нужно определить event time сигнала, время отправки ордера и первую допустимую цену исполнения.

Для медленных стратегий разница между close и следующим open может быть небольшой, но это не повод игнорировать правило. Методология должна быть одинаковой для всех тестов, иначе исследователь будет бессознательно выбирать выгодный вариант там, где это улучшает equity curve.

Indicator warm-up не должен использовать будущий участок

Moving average, ATR, RSI и другие индикаторы требуют истории для инициализации. Если тест начинается 1 января, а система загружает будущие значения или рассчитывает нормализацию на всей выборке, возникает утечка. Warm-up должен использовать только данные до первого торгового решения.

Та же проблема возникает при стандартизации признаков. Среднее, дисперсия, quantile thresholds и другие параметры preprocessing вычисляются на train window, а не на полном периоде. Иначе статистика будущего незаметно влияет на прошлые сигналы.

Centered rolling window почти всегда содержит будущее

Некоторые аналитические библиотеки позволяют центрировать rolling window вокруг текущего наблюдения. Для визуального анализа это удобно, но для торгового бэктеста опасно: половина окна находится в будущем. Любой feature должен использовать trailing window или данные, доступные к текущему моменту.

Проверка кода должна смотреть не только на формулу, но и на индексирование: shift(-1), forward fill после неправильного merge, resample с неподходящим label/closed и joins по ближайшему timestamp часто создают look-ahead без явного обращения к будущей цене.

Target labeling отделяют от feature generation

В машинном обучении будущая доходность законно используется для создания target: модель должна учиться предсказывать именно её. Но target не должен попадать в features напрямую или через preprocessing. Data pipeline удобно разделять физически: сначала формируется feature matrix на доступной информации, отдельно — label из будущего интервала, затем выполняется time-aware split.

Случайное перемешивание временных строк часто разрушает этот принцип. Для финансовых рядов train/test split обычно должен уважать хронологию, а при overlapping labels может понадобиться дополнительный purge или embargo, чтобы границы наборов не делили одну и ту же будущую информацию.

Событийные данные получают лаг фактической публикации

Если стратегия использует funding, open interest, on-chain flows или новости, историческая база может содержать timestamp события и timestamp загрузки. Для теста важен момент, когда информация могла быть прочитана. Например, агрегированный показатель за час, опубликованный через несколько минут после часа, нельзя использовать для сделки ровно на границе часа.

В идеале хранится available_at. Если его нет, применяется консервативный reporting lag. Лучше немного ухудшить симуляцию, чем получить сигнал, который в реальном времени невозможен.

Лимитный ордер не считается исполненным только потому, что цена коснулась уровня

Условие low≤limit price ещё не гарантирует полный fill. Впереди могли стоять другие заявки, доступный объём мог быть мал, а касание — одним микротиком. Для частых стратегий такая оптимистичная модель систематически завышает доходность. Минимальная защита — требовать проход цены через уровень, учитывать объём или вводить fill probability.

Для market order обратная проблема: нельзя считать исполнение ровно по last price. Реальная средняя цена зависит от spread и глубины. Подробнее этот слой разобран в статье о slippage в криптовалюте.

Stop-market и stop-limit моделируются по-разному

Stop-market после триггера превращается в рыночное исполнение и может дать сильное проскальзывание. Stop-limit ограничивает цену, но способен не исполниться вообще. Бэктест, который для обоих типов просто закрывает позицию ровно на stop price, создаёт искусственную защиту.

В стрессовом тесте полезно моделировать gap-through-stop: если рынок перескочил уровень, выход происходит по следующей доступной цене или по conservative slippage model. Для stop-limit отдельно учитывается сценарий зависшей позиции.

Bar-close стратегия и tick-driven стратегия требуют разной точности

Если решение принимается один раз в день и цели широкие, минутная точность исполнения может не быть главным источником ошибки. Но скальпинг и market making зависят от microstructure. Нельзя использовать один и тот же упрощённый fill model для недельного тренда и секундной сетки.

Для высокочастотной логики нужны order book, latency, queue position и realistic event sequence. Если таких данных нет, честный вывод — стратегия не может быть подтверждена этим бэктестом. Материал про скальпинг криптовалют показывает, почему spread и исполнение становятся частью самой стратегии.

Комиссии, spread, slippage и ликвидность: как превратить gross backtest в net backtest

Gross PnL почти всегда красивее реального результата

Первый расчёт стратегии часто показывает PnL без издержек. Это полезно только как диагностика сырого сигнала. Для решения о жизнеспособности нужен net result: trading fee, spread, slippage, funding, borrow, network costs и другие расходы, которые соответствуют выбранному инструменту и способу исполнения.

Чем выше turnover, тем важнее этот слой. Стратегия с десятками сделок в день может иметь положительный gross expectancy и отрицательный net expectancy. Поэтому расходы добавляются до финальной оптимизации, а не после того, как параметры уже выбраны на идеальном рынке.

Maker/taker fee нельзя фиксировать одной универсальной цифрой

Комиссия зависит от площадки, уровня пользователя, типа ордера и того, стал ли лимитный ордер maker или фактически исполнился как taker. Для исторического теста можно использовать консервативную модель: базовый fee tier плюс отдельный stress scenario. Если стратегия выживает только при максимальных скидках, её запас прочности слаб.

Не стоит вшивать в долгосрочную статью конкретный тариф конкретной площадки как постоянный факт. Такие параметры меняются. В исследовательском файле храните versioned fee assumptions и дату проверки.

Spread — это стоимость немедленного входа ещё до slippage

Если best bid 99,9, а best ask 100,1, покупка и немедленная продажа уже создают отрицательный round trip без движения mid price. Backtest по mid или close может полностью игнорировать эту стоимость. Для market orders корректнее моделировать сторону стакана: buy около ask, sell около bid, а затем добавлять market impact.

В малоликвидных токенах spread может расширяться именно в стрессовые периоды, когда стратегия чаще хочет выйти. Поэтому средний spread недостаточен: полезно тестировать percentile или regime-dependent assumptions.

Slippage зависит от размера, а не только от процента

Одинаковый процент slippage для всех сделок удобен, но плохо отражает реальность. Цена исполнения зависит от notional относительно доступной depth. Увеличение капитала способно разрушить стратегию, которая выглядела прибыльной на маленьком размере. Поэтому capacity analysis — отдельная часть проверки.

Минимальный подход: разделить инструменты на liquidity buckets и задать разные slippage assumptions. Лучший — использовать исторический order book или модель price impact. Материал OneMagic о ликвидности криптовалюты помогает отделить торговый объём от реальной способности исполнить нужный размер.

Market impact создаёт обратную связь с собственной стратегией

При крупном объёме стратегия сама сдвигает цену. Историческая свеча была сформирована без вашего будущего ордера, поэтому простой replay данных не моделирует воздействие. Для небольшого retail size эффект может быть несущественным на крупных парах, но на тонких рынках он становится центральным.

Если стратегия предполагает масштабирование капитала, тестируйте несколько размеров. Capacity curve показывает, при каком notional net expectancy начинает ухудшаться из-за impact. Это полезнее обещания, что стратегия «масштабируема».

Funding по perpetual futures может изменить знак результата

Стратегия, которая долго держит directional perpetual position, получает или платит funding. Игнорирование этого потока особенно опасно для carry, market-neutral и leveraged стратегий. Funding должен привязываться к реальным историческим интервалам и знаку позиции.

Даже если средний funding невелик, экстремальные периоды могут создать заметный drag. Поэтому в отчёте удобно показывать trading PnL и funding PnL отдельно, чтобы понять источник результата.

Partial fill меняет и цену, и риск

Лимитный ордер может исполниться на 20%, затем цена уйдёт. Стратегия, которая считает весь объём открытым, искажает позицию, PnL и последующие ордера. Для stop/target логики это особенно критично: защитные уровни должны соответствовать фактическому размеру позиции.

В упрощённом backtest можно использовать fill ratio model. В event-driven симуляции лучше хранить order states и обрабатывать каждое исполнение отдельно. Этот принцип совпадает с инженерной логикой торгового бота, но здесь он оценивается именно как источник исторической ошибки.

Минимальный notional, tick size и lot size влияют на малые стратегии

Историческая формула может рассчитать позицию 3,74 USDT или цену ордера с точностью, которую реальный рынок не принимает. Площадка округлит quantity и price или отклонит заявку. Для небольшого капитала такие ограничения способны заметно изменить частоту входов.

Симуляция должна использовать instrument metadata, действовавшие в тестируемый период, если они менялись. Если истории спецификаций нет, зафиксируйте приближение и оцените чувствительность результата к округлению.

Stress-cost test важнее оптимистичной средней

После базового net backtest увеличьте комиссии, spread и slippage. Например, не ради конкретного универсального множителя, а по сценариям: обычный рынок, ухудшенная ликвидность, экстремальный выход. Если небольшое ухудшение cost model уничтожает весь edge, стратегия слишком хрупкая.

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

Как строить train, validation, out-of-sample и walk-forward без самообмана

In-sample нужен для разработки, а не для финального доказательства

In-sample период — участок, на котором исследователь формирует и настраивает стратегию. Здесь допустимо сравнивать варианты, искать разумные параметры и диагностировать ошибки. Но чем больше решений принято на этом отрезке, тем меньше независимой информации остаётся в его итоговом Sharpe, CAGR или profit factor. Эти метрики уже частично отражают процесс поиска.

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

Validation помогает выбирать между моделями, но тоже постепенно загрязняется

Если после каждого изменения вы смотрите validation и снова корректируете стратегию, validation становится частью процесса обучения. Формально код не обучался на этих данных, но человек обучался. Это особенно заметно, когда десятки итераций отклоняются или принимаются по одному и тому же отрезку.

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

Out-of-sample не должен становиться новым in-sample

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

В реальной работе чистый OOS ресурс ограничен. Поэтому важно не расходовать его на мелкие косметические проверки. Сначала устраните ошибки на train/validation, заморозьте specification и только затем запускайте holdout.

Walk-forward имитирует периодическое переобучение

Walk-forward схема делит историю на последовательные окна. В каждом цикле параметры выбираются только на прошлом train window, затем стратегия применяется к следующему unseen window. После этого окно сдвигается. Итоговая кривая состоит из последовательных out-of-sample фрагментов.

Такой подход особенно полезен, если стратегия по своей природе должна регулярно адаптироваться: например, оценивать волатильность, выбирать lookback или пересчитывать universe. Walk-forward не гарантирует устойчивость, но уменьшает иллюзию, что один набор параметров известен заранее на всём горизонте.

Anchored и rolling walk-forward отвечают на разные предположения

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

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

Проверяйте разные рыночные режимы отдельно

Одна aggregate equity curve способна скрыть, что стратегия зарабатывает только в сильном тренде и системно теряет в боковике. Разделите историю хотя бы на режимы высокой/низкой волатильности, тренд/флэт, бычьи/медвежьи фазы и периоды кризисной ликвидности. Границы режима желательно определять без будущей информации.

Результат по режимам помогает понять причинность. Если momentum-стратегия работает только там, где существует устойчивый тренд, это логично. Если её прибыль возникает исключительно в одном коротком периоде с одной аномальной монетой, устойчивость вызывает вопросы.

Проверка на нескольких активах снижает риск случайного совпадения

Стратегию на BTC полезно протестировать на других крупных ликвидных инструментах, если гипотеза претендует на общий эффект. Не обязательно требовать одинаковой прибыли, но направление свойства должно быть объяснимым. Например, edge может ослабевать на менее ликвидных рынках из-за расходов — это закономерно.

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

Benchmark и null model показывают, сколько результата создаёт сложность

Сравните модель не только с buy-and-hold, но и с упрощённой версией самой стратегии: без одного фильтра, с фиксированным параметром, со случайным входом при том же holding period. Если сложный фильтр почти не меняет результат, он может лишь повышать риск overfitting.

Null model особенно полезна для проверки метрики. Например, если стратегия имеет высокий win rate просто потому, что держит позиции до маленькой прибыли и допускает редкие огромные убытки, случайная модель с тем же exit geometry может показать похожую картину.

Research log превращает эксперимент в воспроизводимый процесс

Для каждого запуска сохраняйте code version, data version, параметры, дату, причину теста и результат. Так можно восстановить, сколько вариантов реально было просмотрено. Это важно не только для статистики multiple testing, но и для дисциплины: исследователь видит, как часто менял правила после неудачи.

Минимальный журнал можно хранить в CSV или базе: run_id, commit, dataset hash, config hash, train/OOS dates, metrics и краткий вывод. Если лучший результат невозможно повторить из сохранённых данных и кода, он не должен использоваться для реального капитала.

Overfitting, data mining и статистические ловушки бэктеста

Чем больше комбинаций протестировано, тем выше шанс случайного победителя

Представьте сто стратегий без настоящего edge. Из-за случайности некоторые покажут хороший исторический результат. Если выбрать только лучшую кривую и забыть остальные девяносто девять, возникает selection bias. Чем шире search space, тем менее впечатляющим должен казаться единичный высокий Sharpe или CAGR.

Именно поэтому важен журнал попыток. Фраза «эта стратегия дала Sharpe 1,8» имеет разный смысл, если она была единственной заранее сформулированной гипотезой или лучшей из пяти тысяч параметрических комбинаций.

Backtest overfitting — это подгонка не только параметров, но и всей исследовательской истории

Overfitting обычно представляют как слишком точный выбор moving average, например 37 вместо 40 периодов. Но подгоняться могут таймфрейм, asset universe, дата начала, режим фильтра, вид комиссии, метод position sizing и даже метрика, по которой выбирается победитель. Итоговая стратегия становится продуктом множества скрытых решений.

Сильная защита — сокращать degrees of freedom. Сначала простая гипотеза, затем небольшой набор параметров с экономическим смыслом, затем независимая проверка. Если для объяснения edge нужна длинная цепочка условий, каждое из которых появилось после просмотра истории, риск подгонки высок.

Parameter plateau важнее единственной вершины

Устойчивый эффект обычно существует в некоторой области параметров. Если стратегия прибыльна при lookback 18–30, но фантастический результат возникает ровно на 23 и быстро исчезает на 22 или 24, это красный флаг. Такой spike часто отражает случайную синхронизацию с конкретными событиями.

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

Cherry-picking периода делает стратегию красивой без изменения кода

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

Полезна rolling-start analysis: запускать одну и ту же стратегию с множеством дат начала и сравнивать распределение исходов. Если весь эффект зависит от единственного удачного старта, это слабое основание для капитала.

Survivorship bias в крипте особенно опасен

Рынок криптовалют быстро меняет состав. Активы делистятся, теряют ликвидность, мигрируют на новые контракты, иногда практически обнуляются. Тест на сегодняшнем списке крупных токенов ретроспективно исключает множество провалов. Это завышает как среднюю доходность universe, так и качество стратегий отбора.

Для честной выборки храните исторические membership rules. Если это невозможно, ограничьте вывод: тест доказывает поведение стратегии на нынешних выживших активах, а не на реальном прошлом universe.

Data snooping возникает даже без кода

Если аналитик годами смотрел на один и тот же график BTC, он уже знает крупные развороты и кризисы. При ручной формулировке идеи это знание способно влиять на выбор правил. Формально стратегия «записана до теста», но человек не является чистым наблюдателем.

Полностью устранить этот эффект невозможно. Его можно уменьшить внешними рынками, свежими временными периодами, pre-registration гипотезы и независимым review другим человеком, который оценивает правила до просмотра результатов.

Look-ahead и survivorship bias могут давать очень убедительные метрики

Опасность этих ошибок в том, что результат выглядит не как явный баг, а как качественная стратегия: высокий Sharpe, небольшая просадка, ровная equity curve. Поэтому метрики не способны сами обнаружить неправильную временную модель. Data lineage и code review важнее финальной красивой таблицы.

CFA Institute относит look-ahead, survivorship bias, overfitting, data mining, unrealistically low turnover costs и transaction costs к типичным ловушкам quantitative investing. В практическом исследовании это означает: сначала проверяется честность эксперимента, только потом число доходности.

Multiple testing требует более строгого порога доверия

Если тестировалось много гипотез, обычная интуиция «результат выглядит статистически значимым» может быть ложной. Формальные методы correction или оценки probability of backtest overfitting существуют, но даже без сложной математики полезно задавать простой вопрос: сколько альтернатив было отброшено прежде, чем появилась эта кривая?

Работы Bailey, Borwein, López de Prado и Zhu показывают, что выбор лучшей модели после множественных backtests способен создавать overfit даже при использовании стандартных hold-out подходов. Для прикладного автора главный вывод — количество экспериментов является частью доказательства.

Сложный ML не освобождает от базовой дисциплины

Machine learning увеличивает число параметров и потенциальных утечек. Feature selection, hyperparameter tuning и model architecture создают большой search space. Поэтому time-aware cross-validation, frozen preprocessing и строгий OOS становятся ещё важнее.

Если простой baseline уже даёт аналогичный net result, сложная модель должна доказать свою ценность устойчивостью, а не сложностью. Более высокая вычислительная стоимость и менее прозрачные решения сами по себе являются operational cost.

Какие метрики смотреть: доходность без риска почти ничего не доказывает

Net return — только первая строка отчёта

Итоговая доходность нужна, но её легко улучшить увеличением риска. Две стратегии могут закончить период с одинаковым результатом, хотя одна пережила просадку 12%, а другая — 70% и почти дошла до ликвидации. Поэтому return всегда читается рядом с drawdown, volatility, exposure и использованным leverage.

В крипте особенно важно отделять доходность стратегии от общей beta рынка. Если система просто почти постоянно находится в long во время бычьего цикла, значительная часть результата может объясняться направлением рынка, а не сигналом.

Maximum drawdown показывает глубину исторической потери капитала

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

Поэтому рядом полезно хранить длительность drawdown, time to recovery и underwater curve. Стратегия, которая годами не обновляет максимум, требует другого капитала и терпения, чем система с частыми короткими просадками.

Sharpe ratio требует осторожности с распределением криптодоходностей

Sharpe сравнивает excess return с volatility и удобен как общий risk-adjusted показатель. Но его интерпретация осложняется автокорреляцией, fat tails, нелинейными payoff и нестабильностью режима. Высокий исторический Sharpe не является самостоятельным доказательством edge.

Вместо поклонения одной цифре сравнивайте Sharpe между train/OOS, режимами и cost scenarios. Если показатель резко падает при небольшом изменении assumptions, это важнее его максимального исторического значения.

Profit factor и expectancy раскрывают механику сделок

Profit factor — отношение суммарной gross profit к суммарному gross loss. Expectancy можно выражать как средний net результат сделки или в единицах риска R. Эти метрики помогают увидеть, создаётся ли прибыль высокой частотой небольших побед или редкими крупными сделками.

Но обе чувствительны к выборке. Несколько экстремальных выигрышей могут создать высокий profit factor при хрупкой основной массе сделок. Поэтому смотрите медиану, quantiles и долю прибыли, созданную лучшими сделками.

Win rate без среднего выигрыша и убытка почти бесполезен

Стратегия с 90% прибыльных сделок может быть убыточной, если редкие проигрыши огромны. Система с 35% побед может иметь положительное ожидание, если средний выигрыш существенно превышает средний убыток. Win rate всегда читается вместе с payoff ratio.

Особенно подозрителен очень высокий win rate у стратегий, которые усредняют убыточную позицию или не фиксируют loss. Нереализованный убыток не исчезает только потому, что сделка ещё не закрыта.

Turnover связывает статистику с реальными расходами

Turnover показывает, насколько активно стратегия меняет позиции. Высокий turnover увеличивает комиссии, spread, slippage, tax/accounting workload и инфраструктурные требования. Даже если историческая net модель учитывает fees, turnover остаётся важным operational metric.

Сравнивайте turnover между parameter sets. Если небольшой прирост gross Sharpe требует кратного увеличения числа сделок, экономический смысл оптимизации сомнителен.

Exposure показывает, сколько времени капитал действительно был под риском

Две стратегии с одинаковой доходностью могут иметь разную market exposure. Если одна находится в позиции 95% времени, а другая 25%, их capital efficiency и режимный риск различаются. Для leveraged систем дополнительно важен gross/net exposure.

Exposure полезно разбивать по long/short, инструментам и режимам. Так видно, не спрятана ли стратегия под видом сложного алгоритма, который фактически постоянно long.

Tail metrics важны из-за нелинейных криптодвижений

Средняя volatility плохо описывает ликвидационные каскады, depeg и flash-crash. Смотрите худшие дневные/сделочные результаты, expected shortfall или хотя бы lower-tail quantiles. Проверьте, какая часть drawdown создана несколькими экстремальными событиями.

Не удаляйте неприятные outliers только потому, что они ухудшают отчёт. Если событие могло произойти в реальном рынке и данные корректны, оно является частью риска. Отдельно можно показать результат без очевидной data error, но не без реального кризиса.

Benchmark-relative metrics отделяют edge от общего рынка

Для long-only криптостратегии полезно сравнивать excess return и drawdown относительно простого benchmark. Цель не обязательно обогнать buy-and-hold по абсолютной прибыли: система может быть полезна, если существенно уменьшает просадку или market exposure при приемлемой доходности.

Benchmark должен соответствовать задаче. Для стратегии на одной монете это может быть buy-and-hold того же актива; для multi-asset — заранее заданный простой portfolio rule. Нельзя выбирать слабый benchmark после того, как увидели результат.

Результат показывают распределением, а не одной точкой

Хороший отчёт включает train, validation, OOS, walk-forward segments, несколько cost scenarios и parameter neighborhood. Для каждой части показываются одинаковые метрики. Тогда читатель видит, устойчив ли эффект, а не только лучший run.

Если стратегия переживает разные окна с умеренными, но похожими результатами, это обычно убедительнее одного феноменального периода. Исследование ищет robustness, а не максимальное число.

Robustness-тесты: как попытаться сломать стратегию до запуска

Perturbation test меняет параметры вокруг выбранной точки

После выбора разумных параметров сдвиньте их в обе стороны. Если moving average 50 работает, проверьте 45, 47, 53, 55; если stop равен 2 ATR, проверьте соседние значения. Цель — не найти новый максимум, а увидеть чувствительность. Стратегия, которая разваливается от малейшего изменения, вероятно, слишком точно подогнана.

Эта проверка особенно полезна после оптимизатора. Вместо таблицы «лучший набор» стройте карту окрестности и ищите область стабильности.

Cost shock показывает запас экономического edge

Увеличьте spread, slippage и комиссии относительно base case. Стратегия не обязана оставаться столь же прибыльной, но должна демонстрировать понятный запас. Если удвоение умеренной оценки slippage делает expectancy резко отрицательным, реальный edge может быть меньше ошибки модели исполнения.

Для высокочастотных систем cost shock иногда важнее изменения сигнала. Это связано с тем, что gross edge на сделку мал и расходы составляют значительную долю.

Latency shock проверяет зависимость от идеального времени

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

Latency test также выявляет псевдосигналы на close, которые существуют лишь при нереальном мгновенном исполнении. Для крипты с быстрыми пробоями это частая проблема.

Missing-data test проверяет поведение при сбоях

Удалите часть баров или имитируйте задержку data feed. Система должна либо безопасно остановиться, либо продолжить по заранее заданным правилам. Если пропуск одного события создаёт двойную позицию или неверный сигнал, проблема уже относится к production risk.

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

Regime stress нужен потому, что средняя история сглаживает кризисы

Отдельно рассмотрите периоды резкого падения рынка, расширения spread, массовых ликвидаций и снижения ликвидности. Вопрос не «заработала ли стратегия в каждом кризисе», а «повела ли себя так, как предполагала риск-модель». Если stop должен ограничивать loss, стрессовый участок проверяет именно это.

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

Asset substitution проверяет, не запомнила ли модель один график

Если гипотеза должна работать на классе ликвидных криптоактивов, замените основной инструмент на другие активы по заранее заданному universe. Не требуйте идентичной доходности: важна сохранность механики. Например, trend-following может давать разные результаты, но не должен полностью менять знак при каждом соседнем рынке без объяснения.

Если стратегия действительно специфична для BTC из-за его структуры ликвидности или derivatives market, это допустимо — но такая ограниченность должна быть частью тезиса, а не обнаруживаться после провала на остальных активах.

Randomized trade-order и bootstrap помогают понять зависимость от последовательности

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

Такой Monte Carlo слой особенно полезен для position sizing: стратегия может иметь положительное expectancy, но неприемлемую вероятность большой просадки при агрессивном риске на сделку.

Remove-best-trades test показывает концентрацию прибыли

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

В отчёте полезно показывать долю total PnL, созданную top-1, top-5 и top-10 сделками. Тогда высокая средняя доходность не скрывает редкую структуру payoff.

Forward paper test проверяет текущий рынок без реального капитала

После исторической разработки заморозьте rules и запускайте paper trading на новых данных. Это уже настоящий out-of-sample во времени: исследователь не знает будущих цен. Paper test проверяет формирование сигналов, time zones, расписание и order logic.

Но demo fill model может быть оптимистичным. Поэтому paper — мост к small live, а не финальное доказательство. Для автоматизированных стратегий следует отдельно сверять фактические сигналы с ожидаемыми.

Small-live validation проверяет то, чего историческая симуляция не знает

Минимальный реальный размер позволяет измерить фактический spread, slippage, latency, rejected orders, частичные исполнения и психологическую реакцию владельца. Цель этапа — не заработать значимую сумму, а проверить divergence между backtest и live.

Если live fills систематически хуже модели, сначала обновляется cost/execution assumption и повторно оценивается edge. Увеличивать капитал только потому, что первые несколько сделок прибыльны, методологически неверно.

Практический протокол OneMagic: от идеи до решения о реальном тесте

Шаг 1. Запишите гипотезу и причину, почему эффект вообще может существовать

Начните не с индикатора, а с объяснения. Что делает другую сторону сделки готовой систематически отдавать вам edge? Это может быть поведенческая реакция, вынужденные ликвидации, медленная адаптация к информации, структурная премия за риск или микроэкономика исполнения. Объяснение не обязано быть доказанным заранее, но оно ограничивает пространство случайного поиска.

Одной строкой запишите falsification condition: какой исторический результат заставит отказаться от идеи. Это защищает от бесконечного добавления фильтров после каждого провала.

Шаг 2. Превратите идею в specification без двусмысленности

Зафиксируйте universe, timeframe, signal time, entry order, exit, stop, position sizing, максимальную одновременную exposure и правила при отсутствии данных. Если используются индикаторы, укажите lookback и warm-up. Если стратегия short или leveraged, добавьте funding/margin assumptions.

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

Шаг 3. Определите данные и их point-in-time свойства

Запишите источник OHLCV/trades/order book, timezone, правила свечей, start/end history, delisting handling и корректировки. Для каждого дополнительного feature укажите available_at. Если часть этих полей неизвестна, это становится явным ограничением исследования.

Не смешивайте красивые агрегированные данные и реальное venue исполнения без basis model. Сначала проще провести честный тест на одном источнике, затем усложнять.

Шаг 4. Выберите baseline и заранее задайте метрики

До запуска выберите benchmark и основной набор критериев: net return, max drawdown, drawdown duration, Sharpe или другая risk-adjusted метрика, turnover, exposure, profit factor, expectancy и tail loss. Так вы не сможете после результата объявить победителем ту метрику, которая случайно оказалась красивой.

Если стратегия основана на стопе и фиксированном риске, дополнительно измеряйте R-multiple distribution. Для position sizing полезно сверить денежный риск с материалом о размере позиции и капитала, не перенося инвестиционные проценты автоматически в трейдинг.

Шаг 5. Постройте base cost model до оптимизации

Добавьте trading fees, spread, slippage и для derivatives funding. Определите conservative fill rule. Если точных исторических order-book данных нет, используйте простую, но явно завышенную оценку расходов и затем sensitivity analysis.

Бэктест без стоимости исполнения можно хранить как gross diagnostic, но нельзя использовать его как итоговую оценку стратегии.

Шаг 6. Разделите train, validation и final OOS до просмотра результата

Границы периодов задаются заранее. Финальный holdout не открывается во время настройки. Если используется walk-forward, определите длину train/test windows и schedule пересчёта до того, как увидите лучшую комбинацию.

Храните config в файле, а не только в коде. Так можно доказать, что границы не менялись после просмотра equity curve.

Шаг 7. Ограничьте search space и сохраните все эксперименты

Если тестируется несколько параметров, задайте диапазон на основании гипотезы и рыночного масштаба. Не запускайте бесконечный optimizer по сотням бессмысленных значений. Каждый run сохраняется с hash данных и конфигурации.

После серии тестов анализируйте не только top-1, но и distribution результатов. Если top-1 сильно оторван от соседей, это повод подозревать случайность.

Шаг 8. Выполните robustness battery

Минимальный набор: parameter perturbation, cost shock, latency shock, regime split, alternative assets, remove-best-trades и rolling start dates. Для стратегии с ML добавьте time-aware validation и контроль leakage.

Результат считается интересным, если разумный edge сохраняется в нескольких независимых проверках. Не требуется идеальная прибыль во всех режимах; требуется объяснимая устойчивость.

Шаг 9. Заморозьте версию перед OOS и forward test

После выбора specification создайте version tag. Любое изменение после OOS получает новый номер и требует новой независимой проверки. Это простое правило предотвращает незаметное превращение holdout в очередной train.

Paper trading должен использовать тот же decision code, что и backtest, если архитектура позволяет. Различаться должен источник данных и execution adapter, а не сама стратегия.

Шаг 10. Сравните live и simulated fills

На small-live этапе собирайте intended price, sent time, accepted time, fill time, average fill, fee, slippage и rejected reason. Затем строится reconciliation между исторической моделью исполнения и реальным рынком.

Если реальный execution gap превышает edge, стратегия не готова к масштабированию. Сначала обновляется симуляция, потом повторяется оценка.

Шаг 11. Определите kill criteria ещё до запуска

Реальный рынок не обязан повторять backtest. Заранее задайте условия остановки: превышение ожидаемого drawdown, систематический рост slippage, изменение liquidity regime, поломка данных, нарушение risk limits или статистически значимое ухудшение expectancy. Остановка — часть системы, а не признание поражения.

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

Шаг 12. Ведите торговый журнал как продолжение исследования

Backtest заканчивается там, где начинается новый поток данных, но исследование продолжается. Сохраняйте сигналы, причины пропущенных сделок, исполнения, комиссии и отклонения от specification. Именно live journal позволяет отличить degradation edge от ошибок дисциплины или инфраструктуры.

Следующая отдельная статья курса будет посвящена торговому дневнику. Здесь достаточно принципа: без сохранённой фактической истории нельзя корректно сравнить live с backtest и понять источник расхождения.

Когда бэктест лучше остановить и не усложнять

Остановитесь, если идея отрицательна после реалистичных расходов, результат держится на одном коротком периоде, параметры образуют острый spike, OOS системно ломается, стратегия требует невозможного исполнения или вся прибыль зависит от нескольких случайных outliers без экономического объяснения. Добавлять новые фильтры в такой ситуации обычно означает усиливать overfitting.

Хороший research process ценит ранний отказ от слабой идеи. Ресурс исследователя ограничен так же, как капитал.

Что делать, если исторических данных мало

Не компенсируйте короткую историю огромным числом параметров. Упростите модель, снизьте уверенность вывода, используйте несколько сопоставимых активов и больше forward observation. Для молодого токена честный вывод «данных недостаточно» сильнее, чем точная оптимизация на шести месяцах.

Короткая history также означает, что observed drawdown почти наверняка не покрывает все будущие режимы. Размер реального капитала должен отражать эту неопределённость.

Как читать красивый чужой backtest

Просите не скриншот equity curve, а specification, период, universe, данные, cost model, число протестированных вариантов и OOS. Проверьте, включены ли делистинги, можно ли было реально исполнить заявленный объём, что произошло в худших режимах и насколько параметры устойчивы.

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

Итог: лучший бэктест — тот, который трудно обмануть

Цель исследования — построить процедуру, в которой стратегии сложно случайно выглядеть лучше, чем она есть. Point-in-time данные, честный signal timing, реалистичное исполнение, costs, независимый OOS, walk-forward, журнал всех экспериментов и robustness tests снижают пространство самообмана.

Даже после этого будущая прибыль не гарантирована. Но процесс меняет качество решения: вместо «эта кривая росла в прошлом» появляется проверяемое утверждение о том, где стратегия работала, где ломалась, какой риск переживала и какие условия должны выполниться перед небольшим реальным тестом.

Отдельно проверяйте смену спецификаций инструмента

Криптовалютный контракт и правила торговой пары не обязаны оставаться одинаковыми на всём историческом горизонте. Площадка может изменить tick size, minimum quantity, leverage tiers, funding interval, маржинальные требования или даже базовый контракт. Если бэктест применяет сегодняшнюю спецификацию к прошлому, часть заявок может оказаться нереалистичной. Для точного исследования instrument metadata желательно versioned по времени.

Когда такой истории нет, не нужно притворяться, что точность полная. Проведите sensitivity test на нескольких разумных спецификациях и укажите ограничение. Для стратегии с широкими дневными сигналами влияние может быть небольшим; для высокочастотного алгоритма изменение tick size способно существенно повлиять на число fills и net expectancy.

Форки, миграции и смена тикера требуют заранее заданной политики

В крипте один экономический актив может пережить migration контракта, redenomination или смену ticker. Исторический провайдер иногда склеивает ряды автоматически, иногда оставляет их раздельно. Без проверки исследователь может получить искусственный ценовой скачок либо, наоборот, идеально непрерывный ряд, которого не было для конкретного держателя.

До теста задайте policy: как обрабатываются migrations, airdrops, forks, redenominations и delist/relist. Если стратегия торгует только крупнейшие ликвидные пары и никогда не держит актив через такие события, это можно явно исключить. Но исключение должно быть правилом, а не удалением неудобного эпизода после просмотра результата.

Бенчмарк тоже должен быть реализуемым

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

Для криптовалюты часто достаточно простого buy-and-hold того же актива или заранее заданной корзины. Чем сложнее benchmark, тем выше риск перенести в сравнение дополнительные скрытые assumptions.

Не объединяйте backtest и прогноз цены

Исторический тест стратегии — не прогноз уровня BTC или другого токена. Он проверяет условное правило: что происходило после определённых состояний рынка. Даже если стратегия устойчиво реагировала на волатильность или тренд, из этого нельзя вывести конкретную будущую цену. Разделение особенно важно для reader-facing материалов, где красивый historical return легко воспринимается как обещание.

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

Reproducibility требует фиксировать версию данных, а не только код

Даже неизменный код способен через месяц дать другой результат, если data vendor исправил историю, добавил missing bars или изменил метод агрегации. Поэтому серьёзный backtest хранит dataset version, checksum или snapshot ключевых данных. Без этого невозможно понять, вызвана ли разница новой логикой или новым датасетом.

То же касается внешних параметров: fee table, funding source, universe membership и symbol mapping. Research artifact должен позволять ответить, на какой именно версии мира была получена цифра. Это особенно важно, если статья или внутренний отчёт обновляются спустя месяцы.

Красивый equity curve нужно проверять на арифметические ошибки

До статистической интерпретации проверьте бухгалтерию симуляции: cash не должен становиться отрицательным без разрешённого leverage, закрытие позиции не должно дважды возвращать капитал, fee списывается один раз, realized PnL согласуется с trade ledger, а equity равна cash плюс mark-to-market открытых позиций. Баг в accounting способен создать более впечатляющий результат, чем любой overfitting.

Полезно сверять несколько случайно выбранных сделок вручную и сравнивать итог с формулой PnL. Автоматические unit tests для accounting и order transitions — дешёвая защита от очень дорогих выводов.

Для отдельной визуальной проверки зон плотной ликвидности можно использовать карту ликвидности Bitcoin, но heatmap не заменяет исторический order book и не должен автоматически превращаться в сигнал бэктеста. Такой источник полезен как контекст, а не как ретроспективное объяснение каждой сделки.

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

Если бэктест стратегии на криптовалюте проходит OOS, walk-forward и стресс исполнения, следующий шаг всё равно не масштабный капитал, а контролируемая forward-проверка. Именно разрыв между исторической моделью и новым потоком данных показывает, насколько исследование было честным.