Le prophète Facebook est-il adapté à la réalisation de bonnes prédictions dans le cadre d'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 en production et en maintenance, et voici nos conclusions :

Récemment, un article a souligné que Facebook Prophète n'était pas très performant dans certains cas particuliers. En effet, ce package est tellement 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 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 en centres d'appel pour l'une des plus grandes entreprises de télécommunications d'Europe, afin d'optimiser la qualité du service à la clientèle.

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

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

Principal les conducteurs d'appel diffèrent selon les UGS. Par exemple, les conducteurs d'assistance commerciale comprennent

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'un d'entre eux est son facilité d'utilisation. Quelques lignes de code seulement et presque pas d'ingénierie des fonctionnalités sont nécessaires pour obtenir 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 code).

Caractéristiques temporelles, comme la tendance et la saisonnalité sont créés en mode natif - Exit les moyennes glissantes, les décalages et autres caractéristiques délicates requises par les modèles arborescents basés sur l'apprentissage automatique (ML).

Toutefois, il peut être 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 stationnairesLa composante tendancielle est générée de manière native.

Pour ces raisons, le prophète 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 data externe (comme le nombre de clients). Cette fonction est très puissante, 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 l'utiliser.
Par exemple, ce graphique montre le nombre de clients Fiber-Optic Internet (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 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 en ce qui concerne la stabilité des résultats et des performances : Le La composante tendancielle tend à expliquer la grande majorité de la prédiction. — autour de 90% pour notre étude de cas. Ainsi, si la tendance n'est pas bien estimée, les performances chuteront de façon spectaculaire et vous pouvez perdre plus de 20 points de MAPE en prédisant trop ou pas assez dans le 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éfinit la flexibilité de la tendance. Plus il est élevé, plus la tendance est flexible. Notre stratégie consiste à rechercher ce paramètre sur la grille avec les valeurs suivantes (dans une échelle logarithmique) : [0,001, 0,01, 0,1, 0,5] : [0.001, 0.01, 0.1, 0.5]. Des valeurs relativement petites conduisent généralement à une meilleure généralisation.

Prochain point d'attention : par défaut, Prophet prend en compteseulement le premier 80% de l'histoire à approximation de 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, cela prend également en compte les derniers data, qui sont plus importants 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 l'ensemble des données 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 retirer: “Prophet est capable de traiter les valeurs aberrantes de l'historique, mais seulement en les adaptant aux changements de tendance.

Composantes saisonnières, telles que 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 : l'empilement de deux modèles, dont notre modèle Prophète et un modèle statistique en calculant des prévisions basées sur le 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 dimanche), 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). Et un ordre de Fourier faible signifie que il ne peut pas s'adapter à des valeurs extrêmes et à des changements rapides en fonction de la saisonnalité, comme le samedi dans l'exemple ci-dessus.

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

Pour événements et extra-régresseurs ainsi que le Prophète peut être utile.

Vous pouvez ajouter un supplément...régresseurs, soit continue ou catégorielle, en fournissant une autre série temporelle (valeurs et dates) au modèle à l'aide de l'option add_regressor méthode. 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-là ou à cette heure-là - soit 1 - l'événement a lieu).

Il est facile d'ajouter de nouveaux événements : il vous suffit de fournir à Prophet un cadre dataframe contenant les dates et les noms des événements.
Il a très bien fonctionné pour les jours fériés, les vacances et d'autres événements. Et il a tendance à donnent de meilleurs résultats que les modèles basés sur les arbres.

De plus, Prophet utilise le logiciel Python vacances pour vous permettre de n'utiliser que l'identifiant du pays (USA ou FRA) pour ajouter des jours fériés connexes en tant que fonctionnalité.

Comme pour beaucoup d'autres algorithmes de prédiction de séries temporelles, il est souvent difficile d'obtenir un résultat satisfaisant. Il est difficile de savoir si un événement récurrent est déjà pris en compte dans la saisonnalité de Prophet. ou si elle doit être signalée 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édictions du modèle qui améliore les performances... Devons-nous l'ajouter ou non ?
Nous avons observé problèmes similaires avec les différents jours fériés qui se déplacent chaque année, et nous avons parfois dû superposer Prophet avec un modèle statistique pour mieux adapter les effets des vacances. Cependant, nous n'avons pas de solution cohérente à proposer.

Comme Prophet est un modèle à peu près linéaire en la façon dont il gère les fonctionnalités supplémentaires et les événements, le croisement des fonctionnalités 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 les algorithmes basés sur les arbres et l'apprentissage profond peuvent très bien le faire.

Exemple : supposons que vous ayez un impact sur votre série temporelle au jour ouvrable + 1 après un jour férié (DBC+1). Ensuite, en fournissant au Prophète un événement “DBC+1”L'utilisation de l'expression "jour" permettra de mieux tenir compte de 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. Vous devrez donc ajouter toutes les caractéristiques “DBC+1_monday”, “DBC +1_mardi”,…

Lorsqu'ils se croisent, leur nombre augmente de façon exponentielle et cela va vous coûter cher à tous les deux. le temps nécessaire pour les calculer, une perte d'interprétabilité et probablement une baisse de performancesi vous ajoutez un trop grand nombre de ces fonctions.

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 utile pour les profils à faible technicité.

Le prophète 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 à Valeurs SHAP). Elle permet en outre d'expliquer les choses à la fois au niveau local et au niveau mondial.

Par conséquent, il est vraiment facilité de représentation graphique de la prévision / de 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 éléments ne fournissent qu'environ 10% de la prédiction, le reste 90% prévu dans la tendance... qui est presque inexplicable. Il vous appartiendra d'essayer d'expliquer cette tendance à l'aide de régresseurs externes que vous ne pouvez pas utiliser comme caractéristiques pour Prophet, tels que la croissance de la base de 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é.

Le prophète a 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, car vous n'avez pas besoin de créer des caractéristiques temporelles.

Prophet permet de prévoir des séries temporelles à l'aide de presque pas d'ingénierie des fonctionnalités et un bon niveau de performance, en un temps record.

Il forme rapidementLe temps d'exécution est de moins d'une minute par modèle, avec validation croisée, sur un ensemble de data avec ~3 ans de data sur un macbook Air avec une puce M1 et 8 Go de mémoire.

En production, lorsque de nouveaux data arrivent, vous devez réajuster votre modèle. Un moyen d'accélérer l'apprentissage 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” sur la documentation pour aller plus loin.

Prophet a besoin d'au moins deux années de data pour calculer la saisonnalité annuelle. ayant au moins 3 ans d'ancienneté data d'avoir 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 était difficile d'atteindre ce plafond. Nous avons dû développer quelques corrections personnalisées sur la sortie pour atteindre un MAPE de ~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.

Intéressant, Parfois, l'ajout de data historiques peut 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 qu'une plus grande quantité de data peut entraîner une diminution de la précision des prévisions.
Dans ce cas, le conseil serait de faire des expériences avec plusieurs longueurs d'historique data et de choisir 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 compter sur 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, vous n'avez pas besoin 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 vous faut un modèle par UGS, par rapport aux approches basées sur les arbres, qui permettent d'utiliser le même modèle pour de nombreux produits.

En général, cela permet d'obtenir de meilleures performances, comme l'a souligné Pierre-Yves Mousset sur son projet. Cependant, le fait d'avoir de nombreux modèles peut constituer un défi technique et un cauchemar à entretenir.

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. Toutefois, si vous êtes soucieux de la stabilité et de la précision des prévisions, envisagez d'utiliser un autre type d'algorithme, tel que les modèles basés sur les arbres, Orbite ou DeepAR.