Как проверить прогноз спроса от ИИ до того, как доверить ему закупки
Прогноз спроса выглядит убедительно, когда график гладкий и число дано до десятых. Но точность нельзя оценить по тому, насколько красиво модель продолжила линию. Её проверяют на периоде, данные которого не участвовали в настройке: модель получает только прошлую историю, строит прогноз, а команда сравнивает его с тем, что действительно произошло. Это и есть простой backtest — проверка на отложенном отрезке времени. До внедрения его можно провести в таблице, не подключая закупочную систему и не выдавая алгоритму право менять заказ.
Сначала зафиксируйте решение
Определите, что именно вы прогнозируете: количество проданных единиц, число заказов, потребность в сырье или поступления по неделям. Единица измерения и горизонт должны совпадать с решением. Магазину, который заказывает товар раз в семь дней, нужен недельный горизонт; точный прогноз на следующий час здесь ничего не решает. Укажите разрез: товар, точка, канал или группа. Чем мельче детализация, тем больше рядов с малым объёмом данных и нулевыми продажами.
Отдельно решите, как ошибка влияет на работу. Недопрогноз скоропортящегося товара может привести к пустой полке, а завышенный прогноз — к списаниям. Для расходника с долгим сроком хранения последствия иные. Поэтому одной средней точности недостаточно: зафиксируйте стоимость дефицита и излишка, доступный срок поставки и минимальную партию. Если данных о стоимости нет, сравнивайте хотя бы количество случаев дефицита и лишнего остатка.
Подготовьте историю без утечки будущего
Соберите дату, фактический спрос, остаток, цену, скидку, наличие товара и внешние события, если они записаны надёжно. Не подменяйте продажи спросом без отметки: если товар отсутствовал, ноль продаж не говорит, что его никто не хотел. Пометьте пропуски, возвраты, изменение упаковки и периоды закрытия. Удалять необычный день только потому, что он портит метрику нельзя: сначала выясните причину и решите, повторится ли она в реальности.
Разделите историю по времени. Например, прошлые месяцы используйте для настройки, следующие четыре недели — для первой проверки, а затем сдвигайте окно и повторяйте тест. Случайное перемешивание строк создаёт утечку: будущая информация попадает в обучение, а результат кажется лучше реального. Когда есть сезонность, проверяйте несколько циклов — обычный будний день и праздничная неделя могут вести себя по-разному.
Поставьте рядом простой ориентир
Сравните сложную модель с наивным правилом: прошлой неделей, тем же днём предыдущей недели или медианой последних похожих периодов. Если система не лучше такого ориентира, её сложность пока не окупается. Для сезонного товара полезно также сравнить прогноз с аналогичным периодом прошлого года. Сопоставление с baseline предотвращает распространённую ошибку: смотреть только на собственную метрику модели и не спрашивать, дала ли она улучшение.
Для оценки посчитайте абсолютную ошибку по каждой дате и товарам, затем покажите медиану и распределение. MAPE плохо ведёт себя при нулевом или очень малом факте, поэтому не используйте его в одиночку. MAE отвечает на вопрос «на сколько единиц ошиблись в среднем», а WAPE позволяет взвесить ошибку относительно общего объёма. При этом большой товар может скрыть провал на малой, но важной позиции; поэтому отдельно показывайте группы, например новые товары, стабильный ассортимент и позиции с редким спросом.
Проведите тест в условиях, похожих на работу
Зафиксируйте, что модель знала в момент прогноза. Если скидка, календарь поставок или запланированное закрытие магазина стали известны позже, нельзя добавлять их в прошлый тест так, будто они были известны заранее. Разделите факторы на исторические и будущие, доступные на дату расчёта. Протестируйте не один идеальный ряд, а разные режимы: сезон, запуск новой позиции, перебой поставок и период без промо.
Сравнивайте модель и baseline при одинаковых горизонтах и одинаковом наборе SKU. Запишите время расчёта, долю рядов, для которых вообще получен прогноз, и частоту ручной правки. Если специалист регулярно заменяет вывод, это не «плохая дисциплина сотрудника», а сигнал пересмотреть входы, пороги или интерфейс. Важно учитывать стоимость запуска: подготовку данных, настройку, вычисления, мониторинг и разбор исключений. Простая формула с небольшим отклонением может быть практичнее, чем более точная система, которая требует постоянной ручной поддержки.
Ограничьте применение пилотом
На первом этапе показывайте прогноз рядом с рекомендацией, но не отправляйте его в заказ автоматически. Сотрудник отмечает «принял», «исправил» или «отклонил» и указывает короткую причину. Через несколько циклов становится видно, где модель помогает и где она систематически ошибается. Только после независимой проверки определите допустимый диапазон, минимальный запас и условие передачи решения человеку. Для длинных рядов можно изучить Timestral — семейство моделей временных рядов, а для сложных исходных таблиц сперва применить наш порядок проверки данных перед отправкой.
Чек-лист результата
В отчёте должны быть: предмет прогноза и горизонт; даты обучения и теста; baseline; набор метрик с оговорками; ошибки по отдельным группам; несколько конкретных промахов; план наблюдения и ответственный сотрудник. Не указывайте единственное число точности без контекста. После запуска продолжайте сравнивать прогноз с фактом: спрос, ассортимент, цена и цепочка поставки меняются, поэтому одна успешная проверка не гарантирует неизменного результата.
FAQ
Можно ли проверить модель на тех же данных, на которых её настраивали? Такая проверка покажет подгонку, а не ожидаемое поведение на будущем периоде.
Нужно ли начинать с дорогой платформы? Нет; сначала достаточно чистого выгружаемого набора и простого baseline.
Когда прогноз можно передавать закупкам? Только после пилота, сравнения с фактом, согласования порогов и назначения человека, который отвечает за исключения.