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

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

Что именно моделирует демо

Названия demo, paper и testnet не задают одинаковую модель исполнения. Уточните у поставщика среды, какие данные она получает, как определяет цену исполнения, поддерживает ли нужные заявки и учитывает ли комиссии. Тестовая среда может хорошо проверять обмен сообщениями, но иначе обрабатывать ликвидность и очередь заявок.

Например, IBKR описывает paper trading как симулятор без реального исполнения и клиринга; среди его ограничений указаны моделирование по верхнему уровню книги заявок и отличия некоторых типов ордеров. Эти ограничения относятся к IBKR, а не автоматически к любому демосчёту.

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

Зафиксируйте условия до сравнения

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

• Версия программы, набор параметров и идентификатор конфигурации.

• Площадка, среда, тип счёта и способ учёта позиций.

• Точное имя инструмента, размер контракта и единицы объёма.

• Период наблюдения, часовой пояс и состояние синхронизации часов.

• Источник данных, вид цены и доступная глубина информации.

• Правила исполнения, комиссии и другие применимые расходы.

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

Сопоставляйте цепочку событий

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

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

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

Учебный пример частичного исполнения

Представим сравнение покупки 100 условных единиц. Демо записало исполнение всего объёма по 25. В доступном реальном журнале 60 единиц исполнены по 25, а остальные 40 — по 25,05. Средняя цена второй записи равна (60 × 25 + 40 × 25,05) / 100 = 25,02.

На одинаковом объёме затраты на покупку различаются на 2 денежные единицы: 2502 против 2500, до комиссий. Это не прогноз типичного расхождения, а пример расчёта. Если бы оставшиеся 40 единиц не исполнились, сравнивать обе записи как одинаковую полную позицию было бы неверно.

Следующий вопрос — объяснение отличия. Совпадали ли время отправки, доступные котировки и правила моделирования? Была ли вторая часть исполнена позже? По одной средней цене нельзя доказать ни медленную работу программы, ни проблему брокера.

Разложите расхождения по причинам

1. Данные: разные котировки, пропуск обновления, различие времени или спецификации.

2. Решение: другой сигнал, настройка, фильтр или состояние уже открытой позиции.

3. Запрос: различающийся объём, тип заявки, параметры или отказ при приёме.

4. Исполнение: частичное заполнение, ожидание, отмена или другая цена.

5. Учёт: комиссия, начисления и открытый результат включены по-разному.

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

Как оформить вывод

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

В подготовке NH PRO используйте инструкцию по подключению и наблюдению за программой. Сравнение demo/live относится к торговым средам; оно не описывает условия доступа к ПО и не означает наличие демоверсии у каждого продукта.