Prévisions constantes

Joannes Vermorel

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 de support parce qu’ils ont venu de pousser des données vers Lokad, et les prévisions qu’ils obtiennent sont constantes. En d’autres termes, les valeurs prévues sont constantes pour toutes les étapes à venir. Ex : des valeurs de ventes constantes pour les 6 prochains mois, si nous considérons des prévisions de ventes mensuelles sur 6 mois d’avance.

Il est pourtant parfaitement évident qu’il n’y a aucune chance que les ventes commerciales soient parfaitement constantes 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 évoluer (au moins un peu) durant les six prochains mois. Il n’y a aucun doute là-dessus. Cependant, le problème est le suivant : comment pouvons-nous 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 modèle de prévision de qualité ; 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 étape à venir sont définitivement plus complexes que ceux produisant la même valeur pour toutes les étapes à venir.

À l’inverse, on peut également dire que ces modèles plus complexes sont aussi moins fiables sur des jeux 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.

Pour revenir à la situation où les gens se plaignent des prévisions constantes, 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 parcimonieuses (comme le e-commerce avec seulement quelques ventes par produit). Dans ces situations, Lokad recourt fréquemment aux prévisions constantes.

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 une affaire plutôt délicate. En bref, elle dépend fortement de la durée des séries temporelles que vous considérez. Ensuite, je doute qu’il existe un “Industry Standard” dans ce domaine. Par ailleurs, 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. Avez-vous une structure “Industry Standard” pour la définition des séries temporelles et l’observation associée, d’un point de vue de conception de base de données ?
2. Quelle sera 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]. Toute orientation et assistance seront appréciées. Johan Strydom (7 years ago)

Salut Izi, c’est une idée intéressante :-) J’ai pensé à ce type d’“attaque” dès le début, bien que cela ne soit pas largement communiqué sur notre site web. En gros, pour ce faire, vous devriez 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. De simples décalages de séries temporelles ne sont pas “naturels” dans les données commerciales réelles. Enfin, cela vous coûterait un peu d’argent puisque 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 notamment des classiques bien connus. Ce sujet est évidemment un peu sensible pour nous, mais j’essaierai de publier ultérieurement un aperçu pas trop détaillé. Par ailleurs, il faut noter que cela est encore en évolution rapide. Joannes Vermorel (9 years ago)

Donc, si je télécharge des données incorrectes, soigneusement élaborées pour être en corrélation avec 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 à faire en plus ! Sinon, il serait bien d’en savoir plus sur les techniques que vous utilisez (ex : ARIMA, ANN, etc.). 9 years ago

Salut Stephen, Bonne remarque. Le problème fondamental ici 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, pensez-vous que cela constitue un retour utilisateur utile en termes de description de ce que l’utilisateur attend ? Potentiellement, vous pourriez contraindre l’utilisateur à n’effectuer une tâche de prévision que sur quelques mois, disons 3, et s’il dépasse ce délai, un avertissement lui serait donné 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 peut-être y aurait-il 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 constante, potentiellement ils pourraient être notifiés d’une certaine manière à propos de ce cas et/ou se voir offrir la possibilité de l’accepter ou d’accepter un résultat plus naïf ? Stephen (9 years ago)