Чек-лист разделения данных для прогноза спроса без утечки

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

Чек-лист предназначен аналитику и владельцу процесса пополнения запасов. Результат — схема обучающих, валидационных и тестовых периодов, которую можно применить к своему датасету. Официальная документация сверена 4 ноября 2026 года. Пример дат ниже вымышленный; обучение, подбор модели и измерение точности в этой работе не проводились.

Содержание

• 1. Зафиксируйте момент решения и горизонт
• 2. Разделите дату события и дату доступности
• 3. Уберите из обучения незавершённые цели
• 4. Отложите последний период до настройки
• 5. Постройте последовательные окна проверки
• 6. Проверьте, что означает gap в вашей таблице
• 7. Обучайте преобразования внутри каждого окна
• 8. Сохраните границы и ограничения вместе с результатами

1. Зафиксируйте момент решения и горизонт

• Запишите время, когда компания выпускает прогноз.
• Укажите, какие будущие даты или интервалы требуется предсказать.
• Определите, прогнозируется продажа за день, сумма за горизонт или другая величина.

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

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

2. Разделите дату события и дату доступности

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

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

В руководстве scikit-learn об утечке данных отдельно разбирается недопустимое использование информации, недоступной во время предсказания. Здесь мы переносим этот принцип на сроки поступления бизнес-данных; предложенная таблица не является встроенной функцией библиотеки.

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

3. Уберите из обучения незавершённые цели

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

В учебном примере модель выпускается утром 1 октября. Если цель записи — сумма за семь дней от даты начала, запись с началом 30 сентября требует наблюдений до 6 октября. На 1 октября она ещё не пригодна как завершённая обучающая цель. Последняя потенциально допустимая дата начала без задержки поступления — 24 сентября: её интервал заканчивается 30 сентября. Если данные закрываются позже, граница сдвигается раньше.

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

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

4. Отложите последний период до настройки

• Выделите финальный тестовый период, который имитирует будущую эксплуатацию.
• Более ранние периоды используйте для разработки и валидации.
• Не подбирайте признаки и гиперпараметры по ошибкам финального теста.

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

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

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

5. Постройте последовательные окна проверки

• Выберите несколько моментов выпуска прогноза внутри периода разработки.
• Для каждого восстановите доступную историю и завершённые цели.
• Сравните модель с базовым подходом на одинаковых датах и горизонтах.

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

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

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

6. Проверьте, что означает gap в вашей таблице

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

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

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

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

7. Обучайте преобразования внутри каждого окна

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

Общая средняя по всем датам использует информацию из будущего, даже если модель затем обучается только на старых строках. Pipeline помогает связать обучение преобразований и модели, но не исправляет заранее построенные признаки с будущими значениями. Причины и способы защиты описаны в разделе common pitfalls.

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

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

8. Сохраните границы и ограничения вместе с результатами

• Сохраните даты и идентификаторы записей каждой части.
• Зафиксируйте горизонт, задержку источников и правила зрелости целей.
• Покажите ошибку по отдельным окнам и нужным бизнес-сегментам.

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

Общий контекст данных, метрик и роли прогноза разобран в статье «Прогнозирование спроса с ИИ». Текущий чек-лист решает более узкую задачу: какие записи разрешено использовать при воспроизведении конкретного момента решения.

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

Как AI студия Владимира Ломтева помогает подготовить данные прогноза

AI студия Владимира Ломтева занимается подготовкой данных, ML-прогнозированием и тестированием. Для временного разделения работа может включать описание доступности источников, сборку исторических срезов и сравнение прогнозов на одинаковых временных окнах.

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

Обсудить задачу.

Итог: признаки готового временного разбиения

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