Как проверить прогнозную модель на истории и не обмануть себя

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

Зачем проверять на истории

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

Если оценка проведена честно, она говорит о том, чего ждать от модели в работе. Если нечестно, вы закупите товар, ставите план продаж или строите кампанию удержания под цифры, которых модель не даст. Про сами подходы к прогнозу спроса я писал отдельно: ИИ-прогноз спроса и продаж, TimesFM 3 для прогноза продаж и прогноз спроса для закупки. Здесь только про то, как их проверять.

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

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

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

Практически это выглядит так. Допустим, у меня год ежедневных продаж. Я обучаюсь на первых 6 месяцах, проверяю на 7-м. Затем обучаюсь на первых 7, проверяю на 8-м. И так далее. В итоге получаю несколько оценок и вижу, как модель ведёт себя в разные сезоны, включая неудачные месяцы.

У TimeSeriesSplit есть параметр gap: число отсчётов, которые выбрасываются из конца обучающей выборки перед проверочной. Он полезен, когда признак заглядывает на несколько дней вперёд. Например, если отток определяется как «не покупал 30 дней», то метка для вчерашнего клиента становится известной только через месяц, и без зазора такой клиент попадёт в обучение с ответом, которого в тот день никто не знал.

Утечка будущего: где она прячется

Разбиение по времени защищает от одного вида утечки. Есть и другие, они встречаются на подготовке данных. Документация scikit-learn в разделе про типичные ошибки определяет утечку так: при построении модели используется информация, которой не будет в момент прогноза, из-за чего оценка получается слишком оптимистичной. Там же правило: не вызывать fit на тестовых данных и сначала делить данные, а потом уже заниматься предобработкой. Среднее для нормировки считают по обучающей части, по всем данным его считать нельзя. Для защиты рекомендуют Pipeline, который обучает все шаги только на нужной части.

Что я проверяю в проектах по спросу, продажам и оттоку:

• Агрегаты по всей таблице. «Средние продажи по товару», посчитанные за весь год, подмешивают в январь знания о декабре.
• Признаки из будущего. Остаток на складе на конец дня, итог за неделю, статус «закрыт» у обращения: в момент прогноза этого ещё нет.
• Метка оттока. Если отток определён по отсутствию покупок за 30 дней, то клиентов последнего месяца нельзя использовать как обучающих, их ответ ещё не известен.
• Подбор настроек на проверочной выборке. Если я десять раз подкручиваю модель, глядя на проверочный период, то он перестаёт быть проверочным. Нужен ещё один период, который я не трогаю до самого конца.
• Исправленные задним числом данные. Склад дозагрузил продажи через неделю, а модель учится на уже исправленной версии. В реальности в момент прогноза версия была сырой.

Сравнение с простой базовой моделью

Цифра точности сама по себе ничего не говорит. «Ошибка 12%» много или мало, зависит от того, сколько ошибается самое простое правило. Поэтому я всегда считаю базу и сравниваю с ней.

• Спрос и продажи. «Завтра как сегодня» и «как в тот же день прошлой недели». Второе часто сильно сложнее побить, потому что учитывает недельную сезонность.
• Закупка. «Столько же, сколько в прошлом месяце».
• Отток. «Никто не уйдёт» или «уйдёт тот, кто давно не покупал». Если уходит небольшая доля клиентов, правило «никто не уйдёт» формально даёт высокую долю верных ответов, но бесполезно. В scikit-learn для этого есть DummyClassifier, простая база, которая игнорирует признаки: по документации стратегия most_frequent всегда выдаёт самый частый класс.

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

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

Что я добавляю к одной цифре, чтобы оценка была честной.

• Несколько периодов. Если модель выигрывает у базы в семи месяцах из восьми, это одно. Если выигрывает только в декабре на распродаже, это другое.
• Разрез по товарам или сегментам. Часто модель хороша для ходовых позиций и бесполезна для редких. Тогда и использовать её надо только для первых.
• Цена ошибки. Недозакупка и перезакупка стоят по-разному, и недостаток обходится дороже излишка или наоборот, в зависимости от товара. Среднюю ошибку я перевожу в рубли хотя бы приблизительно.
• Размер выборки. Разница в два пункта на нескольких десятках наблюдений ничего не доказывает. Нужно достаточно примеров, чтобы разрыв не растворялся в шуме.

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

Пример из практики: модель против внешнего ориентира

В кейсе бота аналитики я собрал модель на Python без сторонних библиотек и проверил её по времени: обучение только на прошлом, проверка только на будущем. На 4150 матчах модель угадала 51,3% исходов против 47,3% у правила «всегда побеждают хозяева». Это лучше простой базы. Но на 9911 матчах внешний рыночный ориентир угадывал 53,8%, а модель 51,5%. Он оказался точнее.

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

Как я это делаю

1. Фиксирую вопрос. Что именно предсказываем, на какой срок вперёд и какое решение зависит от ответа.
2. Собираю историю. Из учётной системы, 1С или таблиц. Проверяю дыры, дубли и задним числом исправленные данные.
3. Считаю базу. Простые правила до любой модели. Если они уже закрывают задачу, на этом можно остановиться.
4. Делаю разбиение по времени. Несколько периодов, зазор там, где метка известна с задержкой, и отдельный период, который не трогаю при подборе.
5. Сравниваю и считаю в деньгах. Модель против базы по периодам и сегментам, ошибка в рублях и штуках.
6. Говорю итог как есть. Если модель не лучше правила, пишу об этом в отчёте и предлагаю правило.

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

Сколько это стоит

Отдельной услуги «бэктест» в прайсе нет. Ближайшие позиции по моему прайсу:

• Автоматизация процессов и документов, куда входит сбор данных и отчёт с прогнозом: от 60 000 ₽, от 2 недель.
• Бот для бизнеса, который выдаёт прогноз или сводку в мессенджер: от 80 000 ₽, от 2 недель.
• Сквозная аналитика, если данных для проверки ещё нет: от 30 000 ₽, от 1 недели.
• Разработка по часам, если нужно только проверить готовую модель: от 3 000 ₽/час.

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

Частые вопросы

Сколько истории нужно для бэктеста?

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

Чем бэктест отличается от обычной проверки модели?

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

Что делать, если модель не лучше простого правила?

Использовать правило. Оно дешевле, понятнее и не ломается при смене данных. К модели можно вернуться, когда накопятся новые признаки или история.

Можно ли доверять оценке, если подбирал настройки на тех же данных?

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

Коротко о главном

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

Если хотите проверить прогноз спроса, продаж или оттока на своей истории и понять, лучше ли он простого правила, напишите мне в Telegram с кодовым словом «ИСТОРИЯ»: @chimitdorzhi.