Прогнозирование интегрированного спроса

Вероятностное прогнозирование спроса












Главная » Ресурсы » Здесь

Вероятностные прогнозы спроса крайне важны для оптимизации товарных запасов. Прогнозы спроса считаются интегрированным по времени выполнения заказа, когда значения прогнозов соответствуют общему уровню спроса в течение времени выполнения заказов; в классическом прогнозировании прогнозы являются периодическими (ежедневными, еженедельными или ежемесячными) и не учитывают время выполнения заказов. Система Lokad позволяет создавать вероятностные прогнозы спроса, и для этого необходимы данные о вероятности времени выполнения заказов. Система Lokad поддерживает различные статистические схемы, такие как сезонность, тренд или жизненный цикл товара. Факторы изменения спроса, такие как случаи дефицита товара или рекламные акции, также необходимо учитывать. Прогнозы Lokad отражают вероятность спроса на каждую единицу товара в будущем. На данной странице мы расскажем о формулах, используемых для расчета интегрированного спроса в Lokad.

Основной синтаксис

В системе прогнозирования предусмотрена функция создания вероятностных прогнозов. Синтаксис данной функции выглядит так:

Demand = forecast.demand(
  category: C1, C2, C3, C4
  hierarchy: H1, H2, H3, H4
  label: PlainText
  demandStartDate: LaunchDate
  demandEndDate: EndDate
  horizon: Leadtime
  offset: 0
  present: (max(Orders.Date) by 1) + 1
  demandDate: Orders.Date
  demandValue: Orders.Quantity
  // «SO» — случаи дефицита
  censoredDemandDate: SO.StartDate, SO.EndDate
  inflatedDemandDate: TVAds.StartDate, TVAds.EndDate
  // «Promos» — промоакции
  promotionDate: Promos.StartDate, Promos.EndDate
  promotionDiscount: Pros.Discount
  promotionCategory: Promos.Type)

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

Функция возвращает вектор Demand, который представляет собой функцию распределения (см. раздел алгебра распределения). Функции распределения — это сложный тип данных, представляющий собой функции $p: \mathbb{Z} \to \mathbb{R}$. Если точнее, система прогнозирования возвращает случайные переменные, такие значения функций распределения, которые больше нуля и у которых масса равна 1. В текущем примере функция $p(k)$ представляет собой вероятность спроса на $k$ единиц товара. Все элементы (с точки зрения Envision) привязаны к собственной функции распределения спроса.

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

  • present: скалярная дата
  • demandDate: вектор дат с привязкой к элементам
  • demandValue: вектор чисел с привязкой к элементам
  • horizon: вектор распределения

Значение present — это дата, которая считается первым днем составления прогноза, причем предполагается, что данные будут полностью собраны вплоть до предыдущего дня. На практике некоторые компании не работают по воскресеньям, и если последняя дата в наборе данных — это суббота, то существует определенное затруднение относительно того, нужно ли начинать прогнозирование с воскресенья или с понедельника. В примере выше мы используем выражение max(Orders.Date) + 1, исходя из предположения, что заказы размещаются каждый день и что входящие данные за предыдущий день получены.

Значения demandDate и demandValue должны находиться в одной таблице с привязкой к элементам, то есть с колонкой [Id, *] в терминологии Envision. Даты отражают фактические случаи спроса в прошлом. Значения отражают уровень спроса, который обычно выражен в единицах или штуках. Разделение значений спроса на части не поддерживается. В данной таблице содержится история спроса, спрогнозированного системой. Оптимально, чем объемнее история, тем лучше, хотя на практике от данных за более чем 5 лет толку не так уж много. Система прогнозирования может работать как с большой, так и с маленькой историей спроса. Если данных много, то более старые данные просто статистически теряют свою актуальность.

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

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

Формальное определение

В данном разделе мы вкратце даем формальное описание статистической операции, выполняемой нашей системой при расчете интегрированного спроса.

Пусть $y(t)$ будет функцией спроса, а $t$ — временем. Пусть интегрированный спрос’ $D$, привязанный к случайной переменной $\Lambda$, которая представляет собой показатели времени выполнения заказов, определяется следующим образом:

$$\text{D} : (y,\Lambda,t_0) \to \int_0^{\infty} \mathbf{P}[\Lambda=\lambda] \left( \int_{t_0}^{t_0+\lambda} y(t) dt \right) d\lambda$$ Где $\mathbf{P}[\Lambda=\lambda]$ представляет собой вероятность того, что случайная переменная времени выполнения заказа $\Lambda$ будет равна $\lambda$. Спрос считается
интегрированным, потому что он высчитывается путем интегрирования по вероятности времени выполнения заказа.

Если $t_0$ представляет собой текущую дату, то уровень спроса известен (он фиксируется) до времени $t_0$, но неизвестен после него. Цель системы прогнозирования — расчет $\hat{D}(y, \Lambda)$, вероятностной оценки уровня спроса в будущем, выраженной в виде случайной переменной.

Категории, иерархия и ярлыки

Категории, иерархия и простые текстовые ярлыки очень похожи с точки зрения системы прогнозирования: они помогают работать с малым количеством фактических данных.

См. статью о прогнозировании с использованием категорий и иерархии.

Прогнозирование для новых товаров

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

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

Аргумент demandStartDate дает два преимущества. Во-первых, он позволяет составлять прогнозы для новых товаров. В таких случаях полезно указать еще и аргумент отклонения offset. Если установить отклонение на ноль (значение по умолчанию), то период прогнозирования не сможет накладываться на
активный период для наименования.

Пример. Сегодня 1-е июля. Горизонт прогнозирования представляет собой распределение Дирака на 7 дней; то есть время выполнение заказа является постоянным и равным 7 дням. Товар А выходит на рынок 15 июля (дата начала продаж). Если прогноз составить сегодня, то распределение для товара А будет являться функцией Дирака, равной нулю, потому что горизонт прогнозирования заканчивается до начала продаж товара А. Для прогнозирования спроса на первую неделю продаж товара А нужно указать отклонение в 14 дней.

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

Усеченный и завышенный спрос

Наша цель — прогнозирование
спроса. Очень часто фактические данные отражают реальный спрос лишь приблизительно, а значит, в прогнозах (произвольно или непроизвольно) появляются погрешности. Например фактические данные могут быть представлены историей продаж. Однако в случае дефицита товаров объемы продаж падают, тогда как спрос остается неизменным. Система Lokad позволяет обрабатывать такие ситуации, и именно для этого предназначены аргументы censoredDemandDate и inflatedDemandDate. Оба аргумента используют вектор дат, привязанных к элементам, то есть (Id, Date) в терминологии Envision.

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

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

Два аргумента inflatedDemandDate и censoredDemandDate могут использовать один или два вектора как исходные значения. Если предоставлено два вектора дат, то пары
(начало, конец) обрабатываются как сегменты, где первая дата является началом, а вторая — концом, причем эти даты включаются в сам сегмент. При наличии только одного вектора дат длина всех сегментов приравнивается к 1 дню; даты позволяют помечать конкретные дни, когда спрос был завышен или урезан.

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

Прогнозирование промо-акций

Система прогнозирования поддерживает обработку промоакций. Предоставлять данные о промоакциях необязательно. Однако при предоставлении данных о промоакциях их нужно давать как для прошлого, так и для будущего. Как минимум, можно предоставить аргумент promotionDate. Аргумент promotionDate используется так же, как censoredDemandDate: при предоставлении единственного вектора дат периоды промоакций приравниваются к 1 дню. Если предоставлено по две даты, то первый вектор показывает дату начала, а второй — дату окончания промоакции (даты включаются в период).

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

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

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

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