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

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

Используйте общую временную границу

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

Ji, Sun, Zhang и Li исследовали эту проблему на нескольких алгоритмах и наборах данных. Они показали, что нарушение общей временной шкалы может приводить к рекомендациям ещё недоступных товаров и менять сравнительный результат моделей. Их работа обосновывает необходимость временного протокола, но не превращает любую историческую проверку в доказательство онлайн-эффекта. [1]

Различайте время события и время доступности

Покупка произошла 10 июня, но сведения поступили в CRM 12 июня. Для рекомендации 11 июня эта покупка ещё неизвестна. Простое условие «дата заказа раньше прогноза» пропустит утечку, если игнорировать задержку передачи.

Храните время события и время, когда оно стало доступно использующему его процессу. Такой подход часто называют point-in-time корректностью: признаки восстанавливаются в состоянии, известном системе в нужный момент.

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

Условный протокол на три периода

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

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

В документации scikit-learn отдельно подчёркивается риск утечки при подготовке признаков: параметры преобразований должны обучаться на тренировочной части. Временной порядок также требует соответствующего способа разделения данных. [2]

Восстановите реальный набор кандидатов

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

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

Что измерять и чего история не покажет

Precision@K показывает долю подходящих по выбранному критерию товаров среди первых K рекомендаций. Recall@K — долю известных подходящих товаров, найденных в этой выдаче. Для обоих показателей надо определить, что именно считается подходящим и за какой период наблюдается результат.

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

Что передать в решение о запуске

Сохраните границы периодов, правила доступности данных, версии каталога, подготовку признаков, варианты сравнения и результаты по одинаковым условиям.

Условная контрольная строка: рекомендация рассчитана 11 июня, чек датирован 10 июня, но получен системой 12 июня. Такой чек исключается из признаков решения 11 июня. Он может стать результатом другого наблюдения только по заранее выбранному правилу. Для заказа с возвратом 25 июня окончательный вклад нельзя считать известным 11 июня. Отдельно укажите ограничения: неполную историю показов, неизвестные внешние покупки или отсутствующие исторические остатки.

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

Источники

1. Ji Y., Sun A., Zhang J., Li C. A Critical Study on Data Leakage in Recommender System Offline Evaluation. ACM Transactions on Information Systems. 2023. 41(3). Article 75. Авторская версия arXiv:2010.11060.

2. scikit-learn developers. Common pitfalls and recommended practices; TimeSeriesSplit. Документация scikit-learn. Раздел о data leakage и временном разбиении. Проверено 22.09.2026.