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

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

Что проверяют in-sample и out-of-sample

In-sample — данные, которые использовали при построении правил или выборе параметров. Out-of-sample — отложенная часть, которую не использовали для этих решений. Её задача — показать поведение уже зафиксированного варианта на других наблюдениях. В руководстве QuantConnect по исследованиям отдельно рассматриваются переоптимизация и сохранение периода для проверки после разработки.

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

Пример разделения истории по времени

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

1. Январь — июнь: разработка. Проверять гипотезу и варианты параметров.

2. Июль — сентябрь: выбор варианта. Сравнивать заранее заданные кандидаты.

3. Октябрь — декабрь: итоговая проверка. Оценить зафиксированную конфигурацию.

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

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

Не допускайте информации из будущего

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

• Зафиксируйте часовой пояс и время доступности каждого входного значения.

• Проверьте, когда рассчитывается сигнал и когда разрешается выставление заявки.

• Убедитесь, что обработка пропусков и расчёт вспомогательных коэффициентов не используют будущий период.

• Сохраните исходные данные и правила их подготовки, чтобы другой человек мог повторить расчёт.

Запишите модель исполнения и расходы

История цен и история исполнимых сделок — разные вещи. В условиях теста нужны источник котировок, правила bid/ask, комиссии, перенос позиции, задержки, проскальзывание и обработка незавершённых заявок. Неизвестный параметр лучше отметить неизвестным, чем автоматически принять равным нулю.

Условный пример: 60 завершённых сделок дают $540 до отдельного расчётного расхода на исполнение. При допущении $5 на полный цикл остаётся $240: 540 − 60 × 5. При $10 результат равен −$60. Это чувствительность к одному допущению при неизменных сделках; в реальной модели и сами сделки могут измениться. Если выбранное поле отчёта уже включает расход, второй раз его не вычитают.

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

Смотрите не только на итоговую прибыль

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

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

Краткий паспорт проверяемого теста

1. Цель: какую гипотезу проверяли и что должно было её опровергнуть.

2. Воспроизводимость: версия программы, настройки, источник и период данных.

3. Разделение: какие даты использовали для разработки, выбора и итоговой оценки.

4. Исполнение: какие расходы и ограничения учтены, какие остались неизвестными.

5. Полная картина: результаты всех вариантов, открытые позиции и обе кривые капитала.

6. Вывод: что подтверждено наблюдением и какой следующий вопрос остался.

Исторический out-of-sample ещё не является торговлей в реальном времени. Следующий вид проверки описан в материале «Демо и реальная торговля: что сравнивать». Если обсуждаете применение NH PRO, пришлите вопрос о вашей конфигурации: платформу, инструмент и какой именно результат хотите проверить. Успешный исторический тест не устанавливает будущую доходность.