Previsão de demanda de produtos para milhares de produtos em várias lojas


9

Atualmente, estou trabalhando em uma tarefa de previsão de demanda, com dados de dezenas de milhares de produtos em algumas milhares de lojas. Mais especificamente, tenho alguns anos de dados diários de vendas por produto em cada loja, e meu objetivo é prever as vendas futuras de cada item em cada loja, um dia antes; dois dias antes, etc.

Até agora, considerei dividir cada par de loja de produtos em uma única série temporal e fazer uma previsão para cada série temporal, como foi feito no artigo de Neal Wagner, Técnicas inteligentes para prever várias séries temporais em sistemas do mundo real . Em outras palavras, usarei apenas as informações históricas das vendas do produto de uma determinada loja para prever as vendas futuras desse produto nessa loja.

No entanto, eu tenho visitado o Kaggle e competições como a Previsão de Vendas de Produtos Corporativos Favorita sugerem uma abordagem diferente, que é usar as informações de todas as lojas e todos os produtos para prever vendas futuras. Pelo que entendi, as informações históricas de vendas de todos os produtos em todas as lojas são despejadas no conjunto de treinamento, a partir do qual o modelo aprenderá a prever vendas futuras. É muito diferente dos métodos tradicionais de séries temporais, mas aparentemente, com base nos resultados da competição, funciona.

O último método parece promissor e mais robusto. No entanto, há o problema de ter que processar centenas de milhões de pontos de dados.

Qual método é mais apropriado para minha tarefa? Para aqueles que trabalharam em problemas semelhantes, qual metodologia você recomendaria?


1
Quando trabalhei nisso, usei a abordagem de séries temporais, MAS com a sazonalidade extraída de produtos similares (por exemplo, uma categoria) em lojas semelhantes (por exemplo, um segmento geográfico em que o tempo seria semelhante). Mas isso ocorre, em parte, devido às restrições de tempo: nem todos os dados chegaram ao mesmo tempo, e o tempo entre a última chegada de dados e quando a previsão foi necessária era pequeno (às vezes negativo!). Essas foram considerações operacionais, não estatísticas.
Zbicyclist

Obrigado por compartilhar isso! Posso saber como você conseguiu incorporar a sazonalidade de produtos similares na previsão? por exemplo, você pegou a sazonalidade média e a adicionou como outro recurso do modelo?
meraxes

Dessazonalize, modele, preveja e depois ressalgue.
Zbicyclist

Respostas:


9

Eu não recomendaria a abordagem usada por Neal et al. . Seus dados são exclusivos por dois motivos:

  • Eles estão trabalhando com dados de alimentos, que geralmente são mais densos e mais estáveis ​​do que outros dados de produtos de varejo. Um determinado local estará vendendo dezenas de caixas de leite ou pacotes de ovos por semana e estará vendendo esses mesmos produtos há décadas, em comparação com peças de moda ou de carro, onde não é incomum ter vendas de um único item a cada 3 ou 4 semanas, e dados disponíveis por apenas um ano ou dois.

  • Eles estão prevendo para armazéns e não lojas. Um único armazém abrange várias lojas, portanto, seus dados são ainda mais densos que a média. De fato, um armazém é normalmente usado como um nível natural de agregação / agrupamento para lojas, portanto, eles já estão essencialmente realizando um agrupamento de dados da loja.

Devido à natureza de seus dados, eles podem modelar séries temporais individuais diretamente. Mas os dados da maioria dos varejistas seriam muito escassos no nível individual de sku / loja para que eles pudessem obter isso.

Como disse o ciclista, esse problema geralmente é abordado usando previsões hierárquicas ou de vários escalões . Todos os pacotes de previsão de demanda comercial usam alguma forma de previsão hierárquica

A idéia é agrupar produtos e lojas em produtos e regiões semelhantes, para os quais as previsões agregadas são geradas e usadas para determinar a sazonalidade e a tendência gerais, que são então distribuídas de maneira reconciliada usando uma abordagem de cima para baixo com as previsões de linha de base geradas para cada sku individual. / combinação de loja.

Além do desafio mencionado pelo ciclista, um problema maior é que encontrar os agrupamentos ideais de produtos e lojas não é uma tarefa trivial, que exige uma combinação de experiência no domínio e análise empírica. Os produtos e as lojas são geralmente agrupados em hierarquias elaboradas (por departamento, fornecedor, marca, etc. para produtos, por região, clima, armazém, etc ... por local), que são alimentados com o algoritmo de previsão juntamente com as vendas históricas dados em si.


Abordando comentários de meraxes

Que tal os métodos usados ​​na Competição Corporativa de Previsão de Vendas de Mercearia Favorita, onde eles permitem que os modelos aprendam com o histórico de vendas de vários produtos (possivelmente não relacionados), sem fazer nenhum agrupamento explícito? Ainda é uma abordagem válida?

Eles estão fazendo o agrupamento implicitamente usando loja, item, família, classe, cluster como recursos categóricos.

Acabei de ler um pouco da seção de Rob Hyndman sobre previsão hierárquica. Parece-me que fazer uma abordagem de cima para baixo fornece previsões confiáveis ​​para níveis agregados; no entanto, possui a enorme desvantagem de perda de informações devido à agregação que pode afetar as previsões para os nós de nível inferior. Também pode ser "incapaz de capturar e tirar proveito das características individuais das séries, como dinâmica do tempo, eventos especiais".

Três pontos em relação a isso:

  • A desvantagem para a qual ele aponta depende do agrupamento dos dados. Se você agregar todos os produtos e lojas, sim, isso seria um problema. Por exemplo, agregar todas as lojas de todas as regiões prejudicaria qualquer sazonalidade específica da região. Mas você deve agregar apenas o agrupamento relevante e, como apontei, isso exigirá algumas análises e experimentações para ser encontrado.
  • No caso específico da demanda de varejo, não estamos preocupados em "perder informações devido à agregação", porque frequentemente as séries temporais nos nós inferiores (ou seja, SKU / Loja) contêm muito pouca informação, e é por isso que as agregamos até as mais altas níveis em primeiro lugar.
  • Para eventos específicos de SKU / loja, a maneira como abordamos isso em minha equipe é remover os efeitos específicos do evento antes de gerar uma previsão e adicioná-los novamente mais tarde, depois que a previsão for gerada. Veja aqui para detalhes.

Obrigado por esta visão! Que tal os métodos usados ​​na Competição Corporativa de Previsão de Vendas de Mercearia Favorita, onde eles permitem que os modelos aprendam com o histórico de vendas de vários produtos (possivelmente não relacionados), sem fazer nenhum agrupamento explícito? Ainda é uma abordagem válida?
Meraxes

Acabei de ler um pouco da seção de Rob Hyndman sobre previsão hierárquica. Parece-me que fazer uma abordagem de cima para baixo fornece previsões confiáveis ​​para níveis agregados; no entanto, possui a enorme desvantagem de perda de informações devido à agregação que pode afetar as previsões para os nós de nível inferior. Também pode ser "incapaz de capturar e tirar proveito das características individuais das séries, como dinâmica do tempo, eventos especiais".
meraxes

@meraxes veja minha edição.
Skander H.

Obrigado pela explicação elaborada, @Alex! Em relação ao seu último ponto, e isso pode ser um pouco estranho, mas você trata as férias da mesma maneira? ou seja, remover seus efeitos antes de gerar previsões e adicioná-los novamente mais tarde?
meraxes

^ Pergunto porque percebo que minhas previsões parecem muito sensíveis aos valores extremos nos dados. Minha abordagem atual é otimizar os dados e, em seguida, usar o analisador de pico de série, conforme descrito no artigo de Neal Wagner et al. para identificar picos explicáveis ​​por feriados e adicioná-los novamente depois. Entendo que outra maneira seria usar variáveis ​​fictícias para remover o efeito dos feriados. Qual abordagem você recomendaria?
meraxes
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.