Facebook Prophet est-il adapté pour faire de bonnes prédictions dans un projet réel ?

Nous avons testé Prophet dans le cadre d'un projet réel, sur trois aspects principaux : l'ingénierie des fonctionnalités, l'interprétabilité et l'utilisation dans la production et la maintenance, et voici nos conclusions :

Récemment, un article a souligné que Facebook Prophet n'était pas très performant dans certains cas particuliers. En effet, ce package est si populaire qu'il tend à être considéré comme L'outil de référence pour tous les cas d'utilisation de la prévision. Cela a lancé un débat au sein de la communauté et même son créateur a réagi.
Il existe une abondante littérature sur la manière d'établir une prévision unique avec Prophet. Mais il y a un manque de retour d'information empirique sur la façon dont il se comporte en production, lorsque vous devez fournir des prévisions sur une base quotidienne. Nous avons testé et éprouvé cet outil pendant 6 mois dans le cadre d'un projet commercial réel. Voici ce que nous en avons retenu.

Nous avons utilisé Prophet pour prévoir les arrivées d'appels dans les centres d'appels de l'une des plus grandes sociétés de télécommunications d'Europe, afin d'optimiser la qualité du service à la clientèle.

Nous avons appliqué le cadre GLADS pour rédiger notre approche data :

Une contrainte importante était la nécessité d'interpréter les résultats. En effet, nos prédictions sont consommées par des planificateurs humains dont l'objectif est de maintenir un SLA (X% des appels doivent être traités dans une période donnée) tout en minimisant les coûts. Leur travail consiste en 3 missions :

Les conducteurs d'appel principaux diffèrent selon les UGS. Par exemple, les pilotes de l'assistance commerciale sont les suivants

Nos séries temporelles présentent de fortes saisonnalités et suivent les cycles économiques. Elles ne sont pas stationnaires. Dans ce cas, Prophet est un choix approprié. Nous avons choisi de le tester, ainsi que d'autres algorithmes de ML fréquemment utilisés pour cette tâche.

Prophet présente de nombreux avantages indéniables qui sont particulièrement utiles pour un projet de prévision orienté vers l'entreprise et qui justifient pleinement sa popularité.

L'une d'entre elles est sa facilité d'utilisation. Seules quelques lignes de code et presque aucune ingénierie de fonctionnalité sont nécessaires pour avoir une bonne base de référence. Pour en savoir plus sur son fonctionnement et son utilisation, lisez ce fil Twitter de son créateur, ainsi que cet excellent article de blog (avec le code).

Les caractéristiques temporelles, telles que les tendances et la saisonnalité , sont créées de manière native - Exit les moyennes glissantes, les décalages et autres caractéristiques délicates requises par les modèles arborescents d'apprentissage automatique (ML).

Toutefois, il peut s'avérer difficile de procéder à un réglage précis si plusieurs événements perturbent le signal.

Un grand avantage par rapport aux modèles autorégressifs (par exemple ARIMA) est que Prophet ne nécessite pas de séries temporelles stationnaires: une composante de tendance est générée de manière native.

Pour ces raisons, Prophet fonctionne assez bien pour les prévisions à moyen terme (nous l'avons essayé à l'horizon M+5), même si l'intervalle de confiance est assez large.

La tendance peut être correctement estimée sans aucune data externe (comme le nombre de clients). Il s'agit d'un outil très puissant, car lorsque vous prévoyez les arrivées d'appels, vous ne savez pas combien de clients vous aurez dans 5 mois, et vous ne pouvez donc pas utiliser cette fonction.
Par exemple, ce graphique montre le nombre de clients de l'Internet par fibre optique (FIO) au fil du temps (un marché en croissance pour notre société de télécommunications), comparé à la composante de tendance apprise par Prophet sur les volumes d'appels. Il existe une forte corrélation (coefficient de Pearson : 0,988) entre le volume d'appels et le nombre de clients. Le modèle apprend donc bien la tendance, et uniquement à partir de la série temporelle elle-même.

Nous avons identifié quelques conseils et astuces pour faire de cette tendance un réel avantage pour vos prévisions basées sur Prophet.

L'une des forces de Prophet est aussi une faiblesse pour la stabilité des résultats et des performances : La composante "tendance" tend à expliquer la grande majorité de la prédiction - environ 90% pour notre étude de cas. Par conséquent, si la tendance n'est pas bien estimée, les performances chutent considérablement et vous pouvez perdre plus de 20 points de MAPE en surestimant ou en sous-estimant les prévisions au fil du temps. Vous disposez de plusieurs paramètres pour aider Prophet à ajuster la tendance, notamment `changepoint_prior_scale` et `changepoint_range`

Il est essentiel de trouver la bonne valeur de changepoint_prior_scale, car ce paramètre détermine la flexibilité de la tendance. Plus il est élevé, plus la tendance est flexible. Notre stratégie consiste à rechercher ce paramètre avec les valeurs suivantes (dans une échelle logarithmique) : [0.001, 0.01, 0.1, 0.5]. Des valeurs relativement petites conduisent généralement à une meilleure généralisation.

Autre point d'attention : par défaut, Prophet ne prend en compte queles premiers 80 % de l'historique pour estimer la tendance en spécifiant 25 points de changement potentiels. Nous avons constaté que l'augmentation de cette valeur de 80 % en modifiant le paramètre changepoint_range améliorait les performances. En effet, cette méthode prend également en compte les dernières data, qui sont plus importantes pour expliquer le niveau des appels dans notre cas. Par exemple, dans ce graphique, vous pouvez voir que 2021 data est important parce qu'il a une tendance à la baisse. Nous avons choisi de prendre en compte la totalité de l'ensemble d'entraînement, à l'exception des 7 derniers jours, au lieu de 80 %.

Un autre élément à prendre en compte est la sensibilité aux valeurs aberrantes. La documentation officielle recommande de les supprimer: "Prophet est capable de gérer les valeurs aberrantes dans l'historique, mais seulement en les adaptant aux changements de tendance.

Les composantes saisonnières, telles que les composantes quotidiennes et annuelles, sont estimées à l'aide de séries de Fourier. Comme nos séries temporelles présentent des cycles économiques saisonniers marqués, nous avons constaté que Prophet fonctionnait assez bien.

Mais en approfondissant un peu, nous avons constaté que la modélisation de la saisonnalité hebdomadaire est limitée. Notre série temporelle présentait des valeurs très faibles le samedi par rapport au reste de la semaine (et aucune valeur le dimanche). Nous avons passé beaucoup de temps à essayer d'améliorer nos prédictions pour ce jour particulier de la semaine et nous avons eu beaucoup de mal à le faire.

Nous avons finalement dû recourir à une solution de contournement : empiler deux modèles, dont notre modèle Prophet et un modèle statistique calculant les prédictions sur la base du poids moyen des jours de la semaine au cours des 6 dernières semaines. Et ce, bien que nous ayons essayé de modifier tous les paramètres de la saisonnalité hebdomadaire de Prophet.

Ce que nous comprenons : Sur une saisonnalité de 7 jours (6 dans notre cas sans les dimanches), l'augmentation de l'ordre de Fourier n'est pas très utile, car l'intervalle entre 0 et 2pi n'est divisé qu'en quelques segments (6 ou 7). De plus, un ordre de Fourier faible signifie qu'il ne peut pas s'adapter aux valeurs extrêmes et aux changements rapides de la saisonnalité, comme les samedis dans l'exemple ci-dessus.

D'autres astuces permettent d'affiner les saisonnalités :

Pour les événements et les extra-régresseurs également, le prophète peut être utile.

Vous pouvez ajouter des régresseurs supplémentaires, qu'ils soient continus ou catégoriels, en fournissant une autre série temporelle (valeurs et dates) au modèle à l'aide de la méthode add_regressor. Les événements sont gérés comme des régresseurs catégoriels (la valeur est soit 0 - l'événement n'a pas lieu ce jour ou cette heure - soit 1 - l'événement a lieu).

L'ajout de nouveaux événements est facile : il suffit de fournir à Prophet un cadre de données contenant les dates et les noms des événements.
Ce modèle a très bien fonctionné avec les jours fériés, les vacances et d'autres événements. Et il tend à donner de meilleurs résultats que les modèles basés sur les arbres.

En outre, Prophet utilise la méthode Python holidays pour vous permettre d'utiliser uniquement l'identifiant du pays (USA ou FRA) afin d'ajouter des jours fériés en tant que fonctionnalité.

Comme pour de nombreux autres algorithmes de prédiction de séries temporelles, il est souvent difficile de savoir si un événement récurrent est déjà inclus dans la saisonnalité de Prophet ou s'il doit être signalé manuellement pour aider l'algorithme. Un exemple simple est la période de Noël et du Nouvel An : même période, à peu près le même effet, chaque année. Un exemple plus délicat est celui des vacances de printemps en France. En France, vers le mois d'avril, il y a deux semaines de vacances scolaires dont les dates changent d'une année à l'autre et qui sont divisées par zone géographique (toute la France n'est pas en vacances en même temps).

Bien que la saisonnalité annuelle soit faible au cours de cette période, l'effet d'un événement "vacances de printemps" est positif sur les prévisions de volumes d'appels. Et le modèle est plus performant avec cet événement. L'effet de cet événement n'est donc pas cohérent avec les autres jours fériés et avec la saisonnalité que nous observons, mais il a un effet sur l'apprentissage et les prévisions du modèle qui améliore les performances... Faut-il l'ajouter ou non ?
Nous avons observé des problèmes similaires avec divers jours fériés qui se déplacent chaque année, et nous avons parfois dû utiliser Prophet avec un modèle statistique pour mieux adapter les effets des jours fériés. Cependant, nous n'avons pas de solution cohérente à proposer.

Comme Prophet est un modèle à peu près linéaire dans la façon dont il traite les caractéristiques supplémentaires et les événements, le croisement des caractéristiques n'est pas automatique. Cela signifie que Prophet ne peut pas déduire qu'une combinaison de valeurs de différentes caractéristiques aura un impact exponentiellement plus élevé ou plus faible sur la prédiction, alors que c'est quelque chose que les algorithmes basés sur les arbres et l'apprentissage profond peuvent très bien déduire.

Exemple : disons que vous avez un impact sur votre série temporelle le jour ouvrable + 1 après un jour férié(JH+1). Le fait de fournir à Prophet un événement "DBC+1" lui permettra de mieux s'adapter à cet effet. Mais ici, l'impact dépend largement du fait que le jour DBC+1 est un lundi, un samedi, etc. Et il n'est ni linéaire ni multiplicatif. Il faudra donc ajouter toutes les caractéristiques "HBD+1_monday", "HBD+1_tuesday",...

Lorsquel'on croise des caractéristiques, leur nombre croît de manière exponentielle et leur calculvous coûtera du temps, une perte d'interprétabilité et probablement une baisse de performance si vousajoutez trop de ces caractéristiques.

L'un des principaux avantages de Prophet par rapport à d'autres modèles est sa capacité d'interprétation.

La décomposition native des prévisions en tendances, saisonnalités, événements et composantes extra-régressives est significative pour les profils à faible technicité.

Prophet est un modèle additif: la somme de chaque composante est égale à la prédiction. L'importance de chaque composante est exprimée directement dans l'unité cible(contrairement aux valeurs SHAP). Et il fournit une explication à la fois locale et globale.

Par conséquent, il est très facile de tracer la prédiction / l'impact de chaque composante sur la prévision. Si vous choisissez de passer à un mode multiplicatif, où chaque composante est exprimée en pourcentage de la tendance, vous aurez un peu plus de travail à faire, mais cela reste très facile à tracer.

Malheureusement, tous ces composants ne fournissent qu'environ 10 % de la prédiction, les 90 %restants étant prédits dans la tendance... qui est presque inexplicable. Il vous appartiendra d'essayer d'expliquer la tendance à l'aide de facteurs de régression externes que vous ne pouvez pas utiliser comme caractéristiques pour Prophet, tels que la croissance de la clientèle, les taux de contact et les changements de comportement des clients pour notre étude de cas. Pour ce faire, vous devez disposer des valeurs réelles associées à chacune de ces caractéristiques : il n'est donc possible d'analyser votre tendance qu'en examinant les prédictions faites dans le passé.

Prophet offre très rapidement de bonnes performances par rapport au temps de développement. En d'autres termes, il offre rapidement une bonne base de référence, puisqu'il n'est pas nécessaire d'élaborer des fonctionnalités à long terme.

Prophet permet de prévoir des séries temporelles en un temps record, presque sans ingénierie des caractéristiques et avec un bon niveau de performance.

Il s'entraîne rapidement: il faut moins d'une minute par modèle, avec validation croisée, sur un ensemble de données avec ~3 ans de data sur un macbook Air avec puce M1 et 8 Go de mémoire.

En production, à mesure que de nouvelles données arrivent sur le site data , vous devez réajuster votre modèle. Un moyen d'accélérer la formation est de lancer l'ajustement à chaud, en utilisant les paramètres du modèle précédent. Vous pouvez également utiliser cette fonction pour accélérer le processus de validation croisée. Consultez la section "Mise à jour des modèles ajustés" de la documentation pour aller plus loin.

Prophet a besoin d'au moins deux années de data pour calculer la saisonnalité annuelle, mais nous recommandons d'avoir au moins trois années d'historique data pour obtenir de bonnes performances.

Nous avons atteint une performance de ~15% MAPE après quelques itérations. L'affinage des résultats s'est toutefois avéré assez difficile et il a été difficile d'atteindre ce plafond. Nous avons dû développer des corrections personnalisées sur la sortie pour atteindre un MAPE d'environ 10 %.

Dans notre projet, Prophet et XGboost ont des performances similaires pour les horizons M+1 et M+2. Cependant, les performances aux horizons M+3 et M+4 ont tendance à se dégrader davantage avec Prophet qu'avec XGboost. Cela s'explique par le fait que la tendance n'a pas été correctement estimée. Bien que cela n'ait pas d'impact sur les prévisions à court terme, les prévisions à long terme sont fortement affectées par la direction de la tendance, car elle continue à croître ou à décroître au fil du temps, ce qui conduit à une surestimation ou à une sous-estimation des prévisions. Il est probablement plus sûr d'utiliser une autre approche pour les prévisions à long terme.

Il est intéressant de noter que l'ajout de données historiques ( data ) peut parfois s'avérer contre-productif et entraîner une baisse de la précision des prévisions. Prophet ne permet pas d'accorder plus d'importance aux observations les plus récentes, de sorte que l'ajout de data peut entraîner une baisse de la précision des prévisions.
Dans ce cas, le conseil serait de mener des expériences avec plusieurs longueurs d'historique data et de sélectionner celle qui donne les meilleurs résultats.

Malgré certains avantages indéniables, Prophet n'est pas un modèle prêt à l'emploi. Il faut un certain temps pour l'ajuster afin d'en améliorer les performances. Certaines faiblesses font qu'il est difficile de se fier à sa stabilité en production.
Pour évaluer la fréquence à laquelle nous devrions réentraîner le modèle, nous avons comparé deux stratégies. Nous avons généré des prévisions sur différents mois et mesuré les résultats :

Le réentraînement du modèle tous les mois a donné de meilleurs résultats. En conclusion, malgré la validation croisée temporelle, les hyperparamètres n'étaient pas stables dans le temps. Pour XGboost, il n'est pas nécessaire d'effectuer un tel réentraînement fréquemment. Cependant, ces résultats doivent être traités avec prudence, car les volumes ont été affectés par la crise COVID au moment où nous avons réalisé ce benchmark. Là encore, notre intuition pour expliquer ce résultat est que la tendance est difficile à estimer correctement.

L'un des inconvénients de ce modèle univarié est qu'il faut un modèle par UGS, alors que les approches arborescentes permettent d'utiliser le même modèle pour de nombreux produits.

Cela permet généralement d'obtenir de meilleures performances, comme l'a souligné Pierre-Yves Mousset dans le cadre de son projet. Cependant, le fait d'avoir de nombreux modèles peut constituer un défi technique et un cauchemar en termes de maintenance.

La facilité d'utilisation du prophète en a fait un très bon modèle de base lorsque vos séries temporelles se décomposent facilement en composantes temporelles simples. Cependant, si votre signal est bruyant, le réglage fin des performances du modèle peut s'avérer fastidieux.

Grâce à sa décomposition native de la prévision en composantes temporelles, les décisions du modèle sont faciles à interpréter. Néanmoins, il n'est pas assez précis pour être utilisé afin de mesurer l'impact d'un événement externe, car on ne sait jamais si l'effet de l'événement est déjà pris en compte dans les composantes temporelles natives.

Si votre série temporelle suit certains cycles économiques, vous pouvez obtenir rapidement des performances très correctes, sans avoir recours à une ingénierie intensive. Cependant, la composante "tendance" n'est pas toujours bien estimée, ce qui peut entraîner des dérives importantes en termes de performances. C'est pourquoi ce modèle peut nécessiter un suivi attentif et des interventions humaines fréquentes.

Si vous souhaitez fournir des explications et construire un modèle décent facilement et rapidement, Prophet est une option à envisager. Cependant, si vous êtes soucieux de la stabilité et de la précision des prévisions, envisagez d'utiliser un autre type d'algorithme, comme les modèles à base d'arbres, Orbit ou DeepAR.