Je ne recommanderais pas l'approche utilisée par Neal et al. . Leurs données sont uniques pour deux raisons:
Ils travaillent avec des données sur les aliments, qui sont généralement plus denses et plus stables que les autres données sur les ventes au détail de produits. Un emplacement donné vendra des dizaines de cartons de lait ou de paquets d'œufs par semaine et vendra ces mêmes produits depuis des décennies, par rapport à la mode ou aux pièces automobiles où il n'est pas inhabituel de vendre un seul article toutes les 3 ou 4 semaines, et les données ne sont disponibles que pour un an ou deux.
Ils prévoient des entrepôts et non des magasins. Un seul entrepôt couvre plusieurs magasins, de sorte que leurs données sont encore plus denses que la moyenne. En fait, un entrepôt est généralement utilisé comme niveau d'agrégation / de regroupement naturel pour les magasins, de sorte qu'ils effectuent déjà essentiellement un regroupement des données du magasin.
En raison de la nature de leurs données, ils peuvent se passer directement de la modélisation de séries chronologiques individuelles. Mais les données de la plupart des détaillants seraient trop clairsemées au niveau de chaque sku / magasin pour qu'ils puissent retirer cela.
Comme l'a dit zbicycliste, ce problème est généralement abordé à l'aide de prévisions hiérarchiques ou multi-échelons . Les packages de prévision de la demande commerciale utilisent tous une forme de prévision hiérarchique
L'idée est de regrouper les produits et les magasins dans des produits et des régions similaires, pour lesquels des prévisions agrégées sont générées et utilisées pour déterminer la saisonnalité et la tendance globales, qui sont ensuite réparties réconciliées en utilisant une approche descendante avec les prévisions de base générées pour chaque référence individuelle. / combinaison de magasin.
Outre le défi que zbicycliste a mentionné, un problème plus important est que trouver les regroupements optimaux de produits et de magasins n'est pas une tâche triviale, qui nécessite une combinaison d'expertise de domaine et d'analyse empirique. Les produits et les magasins sont généralement regroupés dans des hiérarchies élaborées (par département, fournisseur, marque, etc. pour les produits, par région, climat, entrepôt, etc. pour l'emplacement) qui sont ensuite transmises à l'algorithme de prévision avec les ventes historiques les données elles-mêmes.
Répondre aux commentaires meraxes
Que diriez-vous des méthodes utilisées dans le concours de Kaggle de prévision de ventes d'épicerie de Corporación Favorita, où elles permettent aux modèles d'apprendre des histoires de ventes de plusieurs produits (probablement sans rapport), sans faire aucun groupement explicite? Est-ce toujours une approche valable?
Ils effectuent le regroupement implicitement en utilisant magasin, article, famille, classe, cluster comme fonctionnalités catégorielles.
Je viens de lire un peu de la section de Rob Hyndman sur les prévisions hiérarchiques. Il me semble que faire une approche descendante fournit des prévisions fiables pour les niveaux agrégés; cependant, il présente l'énorme inconvénient de la perte d'informations en raison de l'agrégation qui peut affecter les prévisions pour les nœuds de niveau inférieur. Il peut également être "incapable de capturer et de tirer parti des caractéristiques de séries individuelles telles que la dynamique du temps, les événements spéciaux".
Trois points à ce sujet:
- L'inconvénient qu'il pointe dépend du regroupement des données. Si vous regroupez tous les produits et magasins, alors oui, ce serait un problème. Par exemple, l'agrégation de tous les magasins de toutes les régions brouillerait toute saisonnalité spécifique à une région. Mais vous ne devriez agréger que jusqu'au groupe pertinent, et comme je l'ai souligné, cela nécessitera une analyse et une expérimentation pour trouver.
- Dans le cas spécifique de la demande de détail, nous ne sommes pas inquiets de "perdre des informations en raison de l'agrégation" car souvent les séries chronologiques au niveau des nœuds inférieurs (c'est-à-dire SKU / Store) contiennent très peu d'informations, c'est pourquoi nous les regroupons jusqu'au niveau supérieur. niveaux en premier lieu.
- Pour les événements spécifiques SKU / magasin, la façon dont nous l'abordons au sein de mon équipe consiste à supprimer les effets spécifiques à l'événement avant de générer une prévision, puis de les rajouter plus tard, une fois la prévision générée. Voir ici pour plus de détails.