Модель видела будущее. Почему прогноз от этого не стал лучше

У финансовой модели есть странный способ провалить экзамен на честность: дать ей знания из будущего, а потом обнаружить, что она стала предсказывать хуже. Интуиция протестует. Если в обучающий корпус попали поздние режимы рынка, публикации, исправленные ряды и уже реализовавшиеся кризисы, разве модель не должна получить преимущество?
Работа Чена и соавторов Does Training on Future Data Pay? проверяет этот вопрос без риторики. Авторы сравнивают годовые версии финансовых foundation-моделей так, чтобы один и тот же прогноз видел либо только доступное на его дату, либо и данные, появившиеся позже. На 14 рынках, четырех горизонтах и пяти наборах моделей американский режим обучения дал неприятный результат: в 18 из 20 пар "набор моделей × горизонт" у версии с будущим средняя квадратичная ошибка оказалась выше.
Это не оправдание утечки. Временная граница все равно нарушена. Но эксперимент отделяет два утверждения, которые обычно склеивают: "модель знала лишнее" и "лишнее знание сделало метрику лучше". Первое уже достаточно, чтобы результат нельзя было назвать честным. Второе, как видно, вообще не следует из первого.
Утечка предобучения: будущее не обязано быть подсказкой

Предобученная модель не похожа на обычную регрессию с очевидным столбцом tomorrow_return. Ее память распределена по весам. В обучении она могла увидеть будущие наблюдения, изменения связи между признаками и доходностью, пересмотренные исторические базы или структуру последующего режима. Когда такую модель запускают задним числом в ранней дате, она несет с собой информацию, которой живой исследователь тогда не располагал.
Это и есть leakage предобучения: нарушение не обязательно находится в строке бэктеста. Оно может сидеть в checkpoint. Поэтому утверждение "на инференсе мы подали только исторические цены" недостаточно. Нужно спросить: какая версия весов существовала на дату origin, и на чем она была обучена?
Авторы строят именно такой тест. Для каждого origin они держат численную историю и процедуру инференса одинаковыми, меняя лишь годовую версию модели (annual vintage). Контрольная PIT-версия соответствует информации, доступной на origin; exposed-версия обучалась за его временной границей. Так сравнивают не две случайно разные системы, а цену одного лишнего фрагмента времени.
Почему же лишнее знание может мешать? Финансовая временная серия не учебник с единственной правильной закономерностью. Поздний режим способен сдвинуть представление модели о том, какие паттерны важны: после шока, смены монетарного цикла или перестройки корреляций старый рынок выглядит иначе. Модель делает revision к уже информативному PIT-прогнозу. Если этот revision плохо сонаправлен с исходной ошибкой, он увеличивает ее.
Для квадратной ошибки это можно записать без магии. Пусть PIT-ошибка равна , а поздняя версия меняет прогноз на . Новая ошибка: . Улучшение возникает только если поправка достаточно согласована с ошибкой: ее выигрыш от коррекции должен превосходить собственный квадрат. Большая, но неверно направленная поправка ухудшает MSE. Именно такую декомпозицию авторы используют, и в американском режиме выравнивания с PIT-ошибкой обычно не хватало.
Это важное различие для разработчика: "future-aware" не означает "oracle". Leakage делает эксперимент некаузальным, но не превращает данные в бесплатный альфа-сигнал.
Версии разных лет: как поставить модели в одну временную точку

Проверить старый checkpoint против нового недостаточно: у них могут отличаться данные, код, гиперпараметры и способ выдачи прогноза. В исследовании пять семейств моделей обучены как независимые версии разных лет в трех окружениях: U.S.-trained, global и factor-augmented. Затем их сравнивают на 14 рынках и горизонтах прогноза.
Есть два взаимодополняющих ракурса. В rolling-сравнении фиксируют конкретный origin и смотрят, как его прогноз меняется от годовой версии к годовой версии. В fixed-version-сравнении, наоборот, фиксируют версию модели и двигают целевые окна относительно даты ее training cutoff. Первый ракурс отвечает: "что произошло с одним решением, когда мы допустили более позднюю модель?" Второй: "где конкретная версия начинает пересекать собственную временную границу?"
Особенно полезна origin-aligned PIT-пара. В обоих плечах находятся одинаковые численные истории и один инференс-протокол. Нельзя списать результат на новую выгрузку цен, иной normalizer или более удачный API. Разница обязана прийти из того, чему успели научить веса.
Такой дизайн стоит перенести в production-практику. Для каждого опубликованного прогноза нужны как минимум: идентификатор модели, cutoff обучающих данных, timestamp подготовки каждого внешнего источника, версия feature pipeline и timestamp принятия решения. Модельный реестр без training cutoff похож на журнал сделок без времени исполнения: формально запись есть, но проверить причинность нельзя.
Важна и номенклатура. "Дата датасета" не равна "дате доступности". Фундаментальный показатель может относиться к кварталу, быть опубликован позже и еще раз пересмотрен. В новостях есть event time, publish time и момент, когда конкретный провайдер отдал запись. PIT-режим обязан замораживать именно последний доступный снимок, а не красивую сегодняшнюю таблицу, где прошлое уже переписано.
Результат: информативный прогноз можно испортить обновлением

Главное число исследования намеренно скучное, и оттого сильное: 18 из 20 U.S. model-set-horizon комбинаций в pooled rolling-сравнении получили более высокую MSE после допуска будущих данных. Авторы также сопоставили обновление, пересекающее origin, с обновлением такой же длины, но целиком до origin: пересекающее границу обновление в среднем хуже.
Экономическая проверка не спасает позднюю версию. При едином constrained allocation rule с месячным прогнозом медианная разница annualized certainty-equivalent return "exposed минус PIT" составила −1.77 процентного пункта для США и −2.14 п.п. для международной части. Это не доходность стратегии и не обещание инвестору, а изменение полезности в заданном ограниченном правиле распределения. Именно поэтому эти числа нельзя бездумно пересказывать как "модель теряет 2% в год".
В global и factor-augmented окружениях картина смешаннее. Это правильный повод не строить новую догму. Авторы не доказывают, что поздние данные всегда вредят, а показывают, что их польза - эмпирический вопрос. В одном окружении update может случайно исправить прогноз, в другом - просто добавить режимную путаницу.
Есть еще одна ловушка: красивое out-of-sample число не доказывает отсутствие leakage. Если weights уже заражены будущим, разбиение target-периода после training cutoff не вылечит проблему; заражение путешествует вместе с checkpoint. И обратная ошибка тоже опасна: слабый результат future-aware модели не делает эксперимент честным. Некаузальность - свойство информационного множества, а не знак улучшения метрики.
Статистические защиты тут не являются запасным выходом. В независимой работе о поиске стратегий Gençay (2026) намеренно утекший оракул с design Sharpe 34.7, evaluation Sharpe 51.5 и DSR 1.00 прошел и Deflated Sharpe Ratio, и проверку overfitting. DSR оплачивает множественные попытки честно посчитанных бэктестов; он не умеет узнать, что сами входные данные пришли из завтра.
Point-in-time evaluation: не обещать честность, а сделать ее свойством системы

Практический вывод не "перестаньте обновлять модели". Обновлять их нужно постоянно. Но любой исторический forecast следует восстанавливать тем артефактом, который был доступен в день forecast origin. Для foundation-модели это означает реестр версий разных лет или возможность воспроизводимо построить такую версию: training manifest, хеши данных, cutoff, код и параметры.
Надежный контур состоит из четырех ворот. Первое - PIT data snapshot: признаки выбираются по publish/availability timestamp, а пересмотры позднее origin исключаются. Второе - версия модели: inference использует checkpoint, который не видел будущего относительно origin. Третье - execution timestamp: сделка получает цену не раньше того момента, когда модельный вывод и все признаки были доступны. Четвертое - search ledger: каждая проверенная версия и гиперпараметр записываются, чтобы не выдать лучшую из сотни попыток за одну гипотезу.
Эти ворота ловят разные ошибки. В упомянутой работе Gençay universe переотбирается point-in-time по trailing 63-day dollar volume каждые 21 торговый день; это защищает от выбора сегодняшних ликвидных имен в прошлом. Но автор отдельно раскрывает survivorship bias: список акций фиксирован текущим составом, а из делистингов внутри выборки есть лишь восемь. Нельзя называть такую проблему leakage и считать закрытой одной PIT-процедурой. Survivorship меняет состав наблюдаемого мира; temporal leakage меняет информацию в момент решения. Нужны разные аудиты.
Минимальный тест для команды: возьмите несколько исторических origin, зафиксируйте старый checkpoint и снимки признаков, затем повторите прогноз сегодняшней моделью на тех же числах. Если результаты отличаются, это не обязательно баг и не обязательно преимущество. Это измерение model revision. Дальше можно честно ответить на два вопроса: полезен ли revision и имел ли право старый бэктест его использовать?
Модель, которой позволили заглянуть за дату прогноза, уже провалила каузальный экзамен. Но не надо приписывать ей сверхспособность. Иногда будущее лишь громче убеждает ее в неверной закономерности. Самая сильная инженерная позиция здесь проста: фиксировать не только данные и метрику, но и версию знания, из которой был сделан прогноз.
Источники
Авторы
Инженер торговых систем
Разработка торговых ботов с 2017 года: межбиржевой арбитраж (подключал до 30 бирж), парный арбитраж на коинтеграции между спотом и фьючерсами, скальпинг, фронтраннинг, торговля по новостям, сентиментный анализ, трендовые алгоритмы, а также алгоритмы управления и балансировки портфелей. Делает выставление ордеров до 1 мс, warehouse для big data, бэктестинг-движки, AI-агентов и интерфейсы для ботов (в т.ч. open-source profitmaker.cc). Стек: JS/TS, Python, Rust/Zig/Go, DevOps, backend, frontend, архитектура.