ML-прогнозирование спроса для ритейла и производства

Почему прогнозирование спроса даёт сбой на реальных данных

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

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

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

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

Что даёт модель: эффекты в запасах и планировании

Модель прогнозирует не одно число на всю сеть, а иерархию: товарная позиция — склад — неделя, с отдельными сезонными профилями для каждой группы. Точечный прогноз дополняется квантильными границами, поэтому план закупки строится не от «среднего», а от уровня обслуживания, который вы задаёте сами. На ретро-периоде средняя ошибка держится в диапазоне 12–18% против 30–40% у планирования «от прошлого месяца».

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

С другой стороны закрываются упущенные продажи: дефицит по ходовым позициям виден за 2–4 недели до пика и попадает в заказ раньше, чем полка опустеет. Ансамбль моделей на табличных признаках, например LightGBM, переобучается по расписанию — сдвиги спроса подхватываются без переписывания правил вручную.

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

Точность прогноза проверяем до запуска: ретро-тест показывает, как модель отработала бы прошлые сезоны, и в контур планирования она попадает только после этого.

Подходы к прогнозированию спроса: статистика и машинное обучение

Выбор между статистической моделью и машинным обучением — не вопрос «новее значит лучше». Он определяется горизонтом планирования, длиной истории продаж и тем, сколько внешних факторов реально двигает спрос. Открытые инструменты вроде Prophet дают базовую линию через разложение тренда и сезонности — её считают до того, как усложнять модель.

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

Этапы внедрения: от аудита данных до передачи модели

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

1. Аудит данных. Сверяем продажи из касс и учётных систем с остатками и поставками, находим периоды, где нулевые продажи означают отсутствие товара на полке, а не отсутствие спроса. Отдельно собираем промо-календарь, цены, график отгрузок и праздники — без них модель объясняет всплеск случайностью.
2. Схема данных. Фиксируем гранулярность (товар × точка × день), правила агрегации, обработку возвратов, отмен и лагов поставки. На выходе — витрина, из которой признак пересобирается одной и той же процедурой при обучении и при работе в реальном контуре.
3. Построение и настройка модели. Считаем базовую линию по сопоставимым неделям как точку отсчёта, затем добавляем сезонность, регрессию и отбор признаков. Проверяем качество скользящим окном по времени, а не случайным разбиением выборки.
4. Валидация на отложенном периоде. Последние недели держим вне обучения и считаем ошибку по каждой группе товаров. Там, где прогноз хуже базовой линии, возвращаемся к данным, а не подкручиваем коэффициенты.
5. Проверка в рабочем процессе. Прогноз уходит в закупку и планирование производства, сверяется с решением категорийного менеджера — так видно, где расхождение вызвано данными, а где изменением самого рынка.
6. Передача модели и обучение команды. Отдаём документацию по признакам, регламент переобучения, запуск по расписанию и контроль отклонений прогноза от факта. Инженеры заказчика дальше ведут модель самостоятельно.

Обсудим вашу задачу — вернёмся с оценкой и планом по этапам.

Артефакты проекта: схема данных, модель, регламент обновления

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

• Конфигурации расчёта: горизонт прогноза, гранулярность (товар, склад, день), параметры сезонности, правила обработки промо и периодов дефицита — с пояснением, почему выбран каждый параметр.
• Схемы потоков данных: источники, расписание выгрузок, точки контроля качества на входе и карта преобразований от сырых транзакций до признаков.
• Политики доступа: роли по группам товаров и складам, разделение «видит сырые данные» и «видит только прогноз», журналирование обращений к выгрузкам.
• Документация модели: какие признаки влияют на результат, на каком периоде она проверялась, где границы применимости и что считается выходом за них.
• Регламент переобучения: условия запуска (сдвиг спроса, накопление новых продаж, сезон), периодичность, кто инициирует и как результат проверяется до публикации.
• Мониторинг качества: ежедневные метрики ошибки по группам товаров, контроль смещения прогноза, оповещения при выходе за порог.
• Инструкция по сопровождению: типовые сбои, порядок отката на предыдущую версию модели, зоны ответственности и контакты инженеров.

Такой комплект позволяет вашей команде менять параметры и перезапускать расчёт самостоятельно, а нас подключать только к развитию — а не к ежемесячному «поддержанию жизни».

Кейс: остатки и упущенные продажи до и после внедрения

Сеть из 180 магазинов и около 12 тысяч активных позиций. Прогноз строили по средним продажам прошлых периодов: на акции, погоду и локальные всплески он не реагировал, поэтому планировщики правили цифры руками. Заказы уходили в учётную систему 1С:ERP уже с поправками «на глаз», а расхождение с фактом разбирали постфактум.

Что показал замер

Что изменили: прогноз разделили по уровням — сеть, магазин, товарная группа, отдельный товар — и добавили признаки акций, цен, праздников и наличия на полке. Гипотезы проверяли ретро-тестом на двух сезонах, в работу шла только та, что улучшала точность на обоих горизонтах.

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

Что делать, если данные разбросаны по нескольким системам?

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

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

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

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

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

Технические сомнения: данные, качество, интеграция

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

Как прогноз встраивается в учётную систему?

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

Как обеспечивается защита данных?

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

Кто сопровождает модель после запуска?

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

Обсудим вашу задачу и вернёмся с планом

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

• История отгрузок и продаж — выгрузка за достаточный период в разрезе товара и точки, с отметками возвратов, списаний и обнулений остатка. Это база для оценки проекта: по ней сразу видно, хватает ли данных на сезонность и на редкие позиции.
• Календарь промо и внешних событий — акции, праздники, изменения цен, поставки и перебои. Без них модель припишет всплески спросу, а не решению о скидке.
• Иерархия товаров и локаций — товарные категории, склады, магазины или производственные линии. Она задаёт, на каком уровне строить прогноз и как агрегировать результат.
• Горизонт и шаг прогноза — на сколько дней или недель вперёд и с какой частотой пересчёт. Это определяет и состав данных, и сроки внедрения.
• Текущий процесс планирования — кто и в какой момент принимает решение о закупке или производстве, где прогноз должен появиться: в учётной системе, в отчётности или в отдельном интерфейсе.
• Целевая точность и цена ошибки — как считается расхождение и какая ошибка допустима для разных категорий. Для ходовых позиций и для длинного хвоста требования разные.
• Ограничения по данным и доступам — что нельзя выгружать за периметр, какие системы придётся связать, кто со стороны вашей команды подтверждает доступы.

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