Prévisions plates
La prévision statistique est une science contre-intuitive. Cela a déjà été dit dans le passé, mais nous allons souligner à nouveau ce point.
Fréquemment, nous recevons des demandes d’assistance parce que les utilisateurs viennent de télécharger des données sur Lokad et les prévisions qu’ils obtiennent sont plates. En d’autres termes, les valeurs prévues sont constantes pour toutes les étapes à venir. Par exemple, des ventes constantes pour les 6 prochains mois, si nous considérons des prévisions de ventes mensuelles à 6 mois à l’avance.
Il est parfaitement clair cependant qu’il n’y a aucune chance que les ventes commerciales soient parfaitement plates pour les 6 prochains mois, alors pourquoi Lokad continue de produire de tels résultats sans signification ?
Eh bien, nous savons avec certitude que l’activité commerciale va changer (au moins un peu) au cours des six prochains mois. Pas de question à ce sujet. Cependant, le problème est le suivant : comment pouvons-nous produire une prévision aussi proche que possible de ces futurs changements ? Si nous empruntons la voie statistique, nous avons besoin d’un modèle statistique pour les prévisions.
Le problème est que nous avons besoin d’un bon modèle de prévision ; et la règle cardinale de la prévision statistique est que plus le modèle est complexe, plus il faut de données pour que le modèle soit fiable. Les modèles produisant des prévisions distinctes pour chaque étape à venir sont définitivement plus complexes que ceux produisant la même valeur pour toutes les étapes à venir.
À l’inverse, nous pouvons également dire que ces modèles plus complexes sont également moins fiables sur des ensembles de données limités, ce qui signifie que les utiliser est très susceptible de diminuer la précision des prévisions globale dans certaines situations.
Revenons à la situation où les gens se plaignent des prévisions plates, ce qui se passe généralement, c’est simplement que les données qui viennent d’être téléchargées sont soit très courtes (comme seulement 3 mois d’historique mensuel) soit très dispersées (comme un site de commerce électronique avec seulement quelques ventes pour chaque produit). Dans ces situations, Lokad opte fréquemment pour des prévisions plates.
Ce n’est pas un bug, c’est une fonctionnalité d’amélioration de la précision.
Commentaires des lecteurs (6)
Bonjour Johan, la représentation efficace des séries temporelles dans les bases de données relationnelles est une affaire plutôt délicate. En bref, cela dépend beaucoup de la longueur des séries temporelles que vous considérez. Ensuite, je doute qu’il existe une norme industrielle dans ce domaine. En ce qui concerne le code source lui-même, tout dépend beaucoup de la longueur et du nombre de séries temporelles considérées. J’espère que cela vous aide. Il y a 7 ans | Joannes Vermorel
Nous travaillons sur un projet de séries temporelles avec une définition et des observations typiques des séries temporelles. Pouvez-vous nous aider avec ce qui suit :
- Avez-vous une structure standard de l’industrie pour la définition des séries temporelles et les observations associées du point de vue de la conception de la base de données ?
- Quelle serait la meilleure pratique en ce qui concerne le code qui représente une série temporelle, par exemple [Niveau 1].[Niveau 2].[Numéro de séquence].[Version]. Toute orientation et assistance sera appréciée. Il y a 7 ans | Johan Strydom
Salut Izi, c’est une réflexion intéressante :-) J’y ai pensé dès le début, bien que cela ne soit pas largement annoncé sur notre site web. Fondamentalement, pour faire cela, vous auriez besoin de connaître très précisément les données que votre cible envoie à Lokad. Ensuite, vous devez également connaître très précisément le type de corrélations que nous examinons. Les décalages simples des séries temporelles ne sont pas “naturels” dans les données commerciales réelles. Enfin, cela vous coûterait de l’argent car nous ne faisons pas confiance aux données des utilisateurs non payants. En ce qui concerne nos techniques, nous utilisons un mélange complexe de nombreux modèles, qui inclut des classiques bien connus. Ce sujet est évidemment un peu sensible pour nous, mais j’essaierai de publier un aperçu pas trop détaillé plus tard. De plus, il convient de noter que cela est encore en évolution rapide. Il y a 9 ans | Joannes Vermorel
Donc, si je télécharge des données incorrectes, soigneusement conçues pour être corrélées à un fournisseur / partenaire qui utilise votre produit, je peux perturber ses résultats ? C’est intéressant, et cela semble assez facile à faire aussi ! Sinon, ce serait bien d’en savoir plus sur les techniques que vous utilisez (par exemple, ARIMA, ANN, etc.). Il y a 9 ans | Izi
Salut Stephen, Bon point. Le problème principal ici est que l’utilisateur pourrait vouloir non seulement les prévisions elles-mêmes, mais aussi la justification derrière elles ou, du moins, un commentaire. À l’avenir, nous essaierons probablement d’améliorer les applications client de Lokad avec des directives automatisées, qui “commenteront” les prévisions fournies par Lokad. Il y a 9 ans | Joannes Vermorel
Salut Joannes, Penses-tu que cela soit un retour utilisateur utile en termes de description de ce que l’utilisateur attend ? Potentiellement, vous pourriez contraindre l’utilisateur à effectuer uniquement une tâche de prévision pendant quelques mois, disons 3, et s’il en fait plus, il serait averti de l’impact sur l’exactitude des prévisions. Je suppose que cela pourrait également dépendre de la disponibilité des données historiques, donc il y aurait peut-être un moyen de corréler les deux, je ne suis pas sûr. De plus, je pense que du point de vue des utilisateurs, même s’il serait plus correct de leur renvoyer une prévision plate, ils pourraient éventuellement être informés de cette situation et/ou se voir offrir la possibilité de l’accepter ou d’accepter un résultat plus naïf ? Il y a 9 ans | Stephen