La prévision statistique est une science contre-intuitive. Cela a déjà été dit par le passé, mais nous allons réaffirmer ce point.

Souvent, nous recevons des demandes d’assistance de la part de personnes qui viennent de pousser des données vers Lokad, et dont les prévisions obtenues sont plates. Autrement dit, les valeurs prévisionnelles restent constantes pour toutes les périodes futures. Ex: des ventes constantes pour les 6 prochains mois, si nous considérons des prévisions mensuelles à 6 mois d’avance.

Il est pourtant parfaitement évident qu’il n’y a aucune chance que les ventes commerciales soient parfaitement plates pendant les 6 prochains mois, alors pourquoi Lokad continue-t-il de produire de tels résultats dénués de sens?

Eh bien, nous savons avec certitude que l’activité va changer (au moins un peu) au cours des six prochains mois. Aucun doute là-dessus. Pourtant, le problème est le suivant : comment produire une prévision aussi proche que possible de ces changements futurs? Si nous empruntons la voie statistique, alors 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 fondamentale 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 pas à venir sont définitivement plus complexes que ceux produisant la même valeur pour tous les pas à venir.

Inversement, on peut également dire que ces modèles plus complexes sont aussi moins fiables sur des ensembles de données limités ce qui signifie que leur utilisation est très susceptible de diminuer la précision des prévisions globale dans certaines situations.

Revenons à la situation où les gens se plaignent de prévisions plates: ce qui se passe généralement, c’est 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 rares (comme dans le cas du e-commerce avec seulement quelques ventes par 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)

Salut Johan, la représentation efficace des séries temporelles dans les bases de données relationnelles est un domaine assez délicat. Bref, cela dépend fortement de la longueur des séries temporelles que vous considérez. Ensuite, je doute qu’il existe quelque chose de proche d’une “Industry Standard” dans ce domaine. De plus, pour le code source lui-même, tout dépend de la longueur et du nombre de séries temporelles considérées. J’espère que cela aide. Joannes Vermorel (7 years ago)


Nous travaillons sur un Projet de séries temporelles avec une Définition typique de séries temporelles et des Observations. Pouvez-vous éventuellement nous aider avec ce qui suit:

  1. Disposez-vous d’une structure Industry Standard pour la Définition de séries temporelles et l’Observation associée du point de vue de la conception de bases de données?
  2. Quelle serait la meilleure pratique en ce qui concerne le code qui représente une série temporelle, par exemple [Level 1].[Level 2].[Sequence Number].[Version]. Tout conseil et toute aide seront appréciés. Johan Strydom (7 years ago)

Salut Izi, c’est une pensée intéressante :-) J’ai envisagé ce genre “d’attaque” dès le début, bien que cela ne soit pas largement annoncé sur notre site web. En gros, pour cela, il vous faudrait 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 recherchons. Des décalages de séries temporelles simples ne sont pas “naturels” dans de véritables données commerciales. Enfin, cela vous coûterait de l’argent puisque nous ne faisons pas confiance aux données provenant d’utilisateurs non payants. En ce qui concerne nos techniques, nous utilisons un mélange complexe de nombreux modèles, qui inclut d’ailleurs des classiques bien connus. Ce sujet est évidemment un peu sensible pour nous, mais j’essaierai de publier plus tard un aperçu pas trop détaillé. Ensuite, il faut noter que cela évolue rapidement. Joannes Vermorel (9 years ago)


Donc, si je télécharge des données incorrectes, soigneusement élaborées pour être corrélées à un fournisseur / partenaire dont je sais qu’il utilise votre produit, je peux fausser ses résultats? C’est intéressant, et cela semble assez facile à réaliser également! Par ailleurs, ce serait bien d’en savoir plus sur les techniques que vous utilisez (ex: ARIMA, ANN, etc.). 9 years ago


Salut Stephen, Bon point. Le problème fondamental est que l’utilisateur pourrait vouloir non seulement les prévisions elles-mêmes, mais aussi la logique qui les sous-tend ou, du moins, un commentaire. À l’avenir, nous essaierons probablement d’améliorer les applications clientes de Lokad avec des lignes directrices automatisées, qui “commenteront” les prévisions fournies par Lokad. Joannes Vermorel (9 years ago)


Salut Joannes, penses-tu que ce retour d’information de la part de l’utilisateur soit utile pour décrire ce que l’utilisateur attend? Potentiellement, vous pourriez contraindre l’utilisateur à ne pouvoir effectuer une tâche de prévision que sur quelques mois, disons 3, et s’il y en a davantage, il lui serait donné un avertissement concernant l’impact sur la précision 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 faire le lien entre les deux, je ne suis pas sûr. De plus, je pense que, du point de vue des utilisateurs, même s’il pourrait être plus correct de leur retourner une prévision plate, ils pourraient potentiellement être notifiés d’une manière ou d’une autre à ce sujet et/ou avoir la possibilité de l’accepter ou d’accepter un résultat plus naïf? Stephen (9 years ago)