Is Facebook Profeet geschikt om goede voorspellingen te doen in een real-world project?

We hebben Prophet getest in een echt project, op 3 belangrijke aspecten: feature engineering, interpreteerbaarheid en gebruik in productie en onderhoud en dit zijn onze conclusies:

Onlangs werd er in een artikel op gewezen dat Facebook Prophet slecht presteerde op sommige randgevallen. Inderdaad, dit pakket is zo populair dat het wordt beschouwd als DE go-to tool voor elke voorspellende use case. Dit leidde tot een debat binnen de gemeenschap en zelfs de maker reageerde.
Er is veel literatuur over hoe je een enkele voorspelling maakt met Prophet. Maar er is een gebrek aan empirische feedback over hoe het zich gedraagt in productie, wanneer je dagelijks voorspellingen moet doen. We hebben deze tool 6 maanden lang getest en bewezen op een echt bedrijfsproject. Hier zijn enkele vaststellingen.

Voor een van de grootste telecombedrijven in Europa hebben we Prophet gebruikt om het aantal binnenkomende oproepen in callcenters te voorspellen en zo de kwaliteit van de klantenservice te optimaliseren.

We hebben het GLADS-raamwerk toegepast om onze data benadering op te stellen:

Een belangrijke beperking was de behoefte aan interpreteerbaarheid van de resultaten. Onze voorspellingen worden namelijk gebruikt door menselijke planners wiens doel het is om een SLA te handhaven (X% van de oproepen moet worden beantwoord in een bepaalde periode) en tegelijkertijd de kosten te minimaliseren. Hun werk bestaat uit 3 missies:

De belangrijkste drivers voor oproepen verschillen per SKU. Commerciële hulpdrivers zijn bijvoorbeeld:

Onze tijdreeksen zijn sterk seizoensgebonden en volgen economische cycli. Ze zijn niet stationair. In dit geval is Prophet een geschikte keuze. We hebben ervoor gekozen om het te testen, net als andere ML-algoritmen die vaak voor deze taak worden gebruikt.

Prophet heeft veel onbetwistbare voordelen die bijzonder nuttig zijn voor een zakelijk prognoseproject en die zijn populariteit volledig rechtvaardigen.

Een daarvan is het gebruiksgemak. Er zijn maar een paar regels code en bijna geen functies nodig om een goede baseline te hebben. Om meer te leren over hoe het werkt en hoe het te gebruiken, lees deze Twitter thread van de maker, evenals deze uitstekende blog post (met code).

Tijdskenmerken, zoals trend en seizoensgebondenheid worden direct gemaakt - zonder de voortschrijdende gemiddelden, vertragingen en andere lastige kenmerken die nodig zijn voor boomgebaseerde modellen op basis van machine learning (ML).

Het kan echter een heel gedoe zijn om af te stellen als meerdere gebeurtenissen het signaal verstoren.

Een groot voordeel ten opzichte van autoregressieve modellen (bijv. ARIMA) is dat Prophet geen stationaire tijdreeksen nodig heeft: een trendcomponent wordt van nature gegenereerd.

Om deze redenen werkt Prophet vrij goed voor voorspellingen op de middellange termijn (we hebben het geprobeerd op M+5 horizon), ook al is het betrouwbaarheidsinterval vrij groot.

Trend kan correct worden geschat zonder externe data (zoals het aantal klanten). Dit is vrij krachtig, want als je binnenkomende gesprekken voorspelt, weet je niet hoeveel klanten je over 5 maanden zult hebben, dus kun je deze functie niet gebruiken.
Deze grafiek toont bijvoorbeeld het aantal Fiber-Optic Internet (FIO)-klanten in de loop van de tijd (een groeiende markt voor onze telecom organisatie), vergeleken met de trendcomponent die Prophet heeft geleerd over gespreksvolumes. Er is een sterke correlatie (Pearson coeff.: 0,988) tussen het belvolume en het aantal klanten. Het model leert de trend dus goed, en alleen van de tijdreeks zelf.

We hebben een aantal tips en trucs geïdentificeerd om van de trend een echt voordeel te maken voor je prognoses op basis van prognoses.

Een van de sterke punten van Prophet is ook een zwak punt voor de stabiliteit van de resultaten en de prestaties: De trendcomponent heeft de neiging om het overgrote deel van de voorspelling te verklaren - ongeveer 90% voor onze casestudy. Als de trend dus niet goed wordt geschat, zullen de prestaties dramatisch dalen en kun je meer dan 20 punten MAPE verliezen door in de loop van de tijd te veel of te weinig te voorspellen. U hebt meerdere parameters om Prophet te helpen de trend aan te passen, waaronder de `changepoint_prior_scale` en de `changepoint_range`.

Het vinden van de juiste waarde voor changepoint_prior_scale is essentieel, omdat deze parameter de flexibiliteit van de trend bepaalt. Hoe hoger de waarde, hoe flexibeler de trend. Onze strategie is om deze parameter in een raster te zoeken met deze waarden (in een logaritmische schaal): [0.001, 0.01, 0.1, 0.5]. Relatief kleine waarden leiden over het algemeen tot betere generalisatie.

Volgende aandachtspunt: standaard houdt Prophet alleen rekening metde eerste 80% van de geschiedenis om de trend te benaderen door 25 potentiële veranderpunten op te geven. We ontdekten dat het verhogen van deze waarde van 80% door het veranderen van de changepoint_range parameter de prestaties verbeterde. Hierdoor wordt namelijk ook rekening gehouden met de laatste data, die in ons geval belangrijker zijn om het niveau van de oproepen te verklaren. In deze grafiek kun je bijvoorbeeld zien dat 2021 data belangrijk is omdat het een dalende trend heeft. We hebben ervoor gekozen om rekening te houden met de hele trainingsset behalve de laatste 7 dagen in plaats van 80%.

Iets anders om te overwegen is de gevoeligheid voor uitschieters. De officiële documentatie raadt aan om ze te verwijderen: "Prophet kan omgaan met de uitschieters in de geschiedenis, maar alleen door ze aan te passen met trendveranderingen".

Seizoensgebonden componenten, zoals dagelijks en jaarlijks, worden geschat met Fourier-reeksen. Omdat onze tijdreeksen sterke seizoensgebonden bedrijfscycli hebben, vonden we dat Prophet vrij goed werkt.

Maar als we wat dieper duiken, zien we dat de wekelijkse seizoensgebondenheid beperkt is. Onze tijdreeks had zeer lage zaterdagen in vergelijking met de rest van de week (en geen waarden op zondag). We hebben veel tijd en moeite besteed aan het verbeteren van onze voorspellingen voor deze specifieke dag van de week.

Uiteindelijk moesten we een workaround gebruiken: het stapelen van twee modellen, waaronder ons Prophet-model en een statistisch model dat voorspellingen berekent op basis van het gemiddelde gewicht van de weekdagen over de afgelopen 6 weken. En dit ondanks het feit dat we geprobeerd hadden alle parameters in de wekelijkse seizoensgebondenheid van Prophet te wijzigen.

Onze interpretatie: Bij een seizoensgebondenheid van 7 dagen (6 in ons geval zonder zondagen) is het verhogen van de Fourier-volgorde niet zo nuttig, omdat het interval tussen 0 en 2pi slechts in een paar segmenten (6 of 7) is verdeeld. En een lage fouriervolgorde betekent dat extreme waarden en snelle seizoensveranderingen, zoals de zaterdag in het bovenstaande voorbeeld , niet passen.

Enkele andere trucs om de seizoensgebondenheid te verfijnen:

Ook voor evenementen en extra-regressors kan Prophet handig zijn.

Je kunt extra regressoren toevoegen, continue of categorische, door een andere tijdreeks (waarden en data) aan het model toe te voegen met de methode add_regressor. Gebeurtenissen worden beheerd als categorische regressoren (waarde is ofwel 0 - de gebeurtenis vindt niet plaats op die dag of dat uur - of 1 - de gebeurtenis vindt plaats).

Het toevoegen van nieuwe gebeurtenissen is eenvoudig: je hoeft Prophet alleen maar een dataframe te geven met de data en namen van de gebeurtenissen.
Het werkte vrij goed met vakanties, vrije dagen en andere gebeurtenissen. En het geeft meestal betere resultaten dan de boomgebaseerde modellen.

Bovendien gebruikt Prophet de Python vakantie pakket zodat je alleen de id van het land (USA of FRA) kunt gebruiken om gerelateerde feestdagen als functie toe te voegen.

Net als bij veel andere voorspellingsalgoritmen voor tijdreeksen is het vaak moeilijk om te weten of een terugkerende gebeurtenis al is opgenomen in de seizoensgebondenheid van prophet of dat deze handmatig moet worden gemarkeerd om het algoritme te helpen. Een eenvoudig voorbeeld is de kerst- en nieuwjaarsperiode: dezelfde periode, ongeveer hetzelfde effect, elk jaar. Een lastige is de Franse voorjaarsvakantie. In Frankrijk zijn er rond april twee weken schoolvakantie met verschuivende data van jaar tot jaar en verdeeld per geografisch gebied (niet heel Frankrijk gaat op hetzelfde moment op vakantie).

Hoewel de jaarlijkse seizoensgebondenheid in deze periode laag is, is het effect van een "voorjaarsvakantie" positief op de voorspellingen van de gespreksvolumes. En het model presteert beter met deze gebeurtenis. Dus het effect van deze gebeurtenis is niet consistent met andere feestdagen en met de seizoensgebondenheid die we waarnemen, maar er is een effect op de modeltraining en voorspellingen dat de prestaties verbetert... Moeten we het toevoegen of niet?
We hebben soortgelijke problemen waargenomen met verschillende feestdagen die elk jaar veranderen, en we moesten Prophet soms stapelen met een statistisch model om de effecten van feestdagen beter te laten passen. We kunnen echter geen consistente oplossing bieden.

Aangezien Prophet een ruwweg lineair model is in de manier waarop het omgaat met extra kenmerken en gebeurtenissen, is het kruisen van kenmerken niet automatisch. Dit betekent dat Prophet niet kan afleiden dat een combinatie van waarden van verschillende kenmerken zal leiden tot een exponentieel hogere of lagere impact op de voorspelling, terwijl dit iets is dat boomgebaseerde algoritmen en Deep Learning heel goed kunnen afleiden.

Voorbeeld: stel dat je een effect hebt op je tijdreeks op Werkdag + 1 na een vakantie(HBD+1). Als je Prophet dan voorziet van een gebeurtenis "HBD+1", past hij beter bij dit effect. Maar hier hangt de impact grotendeels af van het feit of de dag HBD+1 op een maandag, zaterdag enz. valt. En het is niet lineair noch vermenigvuldigend. Vandaar dat je alle kenmerken "HBD+1_monday", "HBD+1_tuesday",... moet toevoegen.

Als je functies kruist, groeit hun aantal exponentieel en het kost je zowel tijd om ze te berekenen, een verlies aan interpreteerbaarheid en waarschijnlijk een daling van de prestaties alsje te veel van deze functies toevoegt.

Een van de belangrijkste voordelen van Prophet ten opzichte van andere modellen is de interpreteerbaarheid.

De eigen decompositie van de voorspelling in trend-, seizoens-, gebeurtenissen- en extra-regressorcomponenten is zinvol voor low-tech profielen.

Prophet is een additief model: de som van elke component is gelijk aan de voorspelling. Het belang van elke component wordt direct uitgedrukt in de doeleenheid(in tegenstelling tot SHAP-waarden). En het biedt zowel lokale als globale verklaarbaarheid.

Bijgevolg is het heel eenvoudig om de voorspelling / impact van elke component op de voorspelling te plotten. Als je ervoor kiest om over te schakelen op een multiplicatieve modus, waarbij elke component wordt uitgedrukt als percentage van de trend, heb je iets meer werk, maar het blijft heel eenvoudig om te plotten.

Helaas leveren al deze componenten slechts ongeveer 10% van de voorspelling; de overige 90% wordt voorspeld in de trend... die bijna onverklaarbaar is. Het is jouw taak om te proberen de trend te verklaren met behulp van externe regressoren die je niet kunt gebruiken als kenmerken voor Prophet, zoals de groei van het klantenbestand, contactpercentages en veranderingen in klantgedrag voor onze casestudy. Om dit te kunnen doen, moet je beschikken over de werkelijke waarden die zijn gekoppeld aan elk van deze kenmerken: het is dus alleen mogelijk om je trend te analyseren als je terugkijkt naar de voorspellingen die in het verleden zijn gedaan.

Prophet heeft zeer snel goede prestaties, vergeleken met de ontwikkelingstijd. Met andere woorden, het services een goede baseline snel, omdat je niet hoeft te knutselen tijd functies.

Prophet maakt het mogelijk om tijdreeksen te voorspellen met bijna geen feature engineering en een goed prestatieniveau, in recordtijd.

Het traint snel: het duurt minder dan 1 minuut per model, met kruisvalidatie, op een dataset met ~3 jaar data op een macbook Air met M1-chip en 8 Go geheugen.

Als er in de productie nieuwe data binnenkomen, moet je het model opnieuw fitten. Een manier om de training te versnellen is om de fit warm te starten met behulp van de modelparameters van het eerdere model. Je kunt deze functie ook gebruiken om het kruisvalidatieproces te versnellen. Bekijk de paragraaf "Gepaste modellen bijwerken" in de documentatie voor meer informatie.

Prophet heeft ten minste twee jaar data nodig om de jaarlijkse seizoensgebondenheid te berekenen, maar we raden aan om ten minste 3 jaar historische data te hebben voor goede prestaties.

We bereikten een prestatie van ~15% MAPE na een paar iteraties. Het verfijnen van de resultaten was echter een hele uitdaging en het was moeilijk om dit plafond te bereiken. We moesten een aantal aangepaste correcties op de uitvoer ontwikkelen om een MAPE van ~10% te bereiken.

In ons project hebben Prophet en XGboost vergelijkbare prestatiecijfers in de M+1- en M+2-horizon. De prestaties in M+3 en M+4 degraderen echter meer bij Prophet dan bij XGboost. Dit komt omdat de trend niet correct werd geschat. Hoewel dit geen invloed heeft op kortetermijnvoorspellingen, worden langetermijnvoorspellingen sterk beïnvloed door de trendrichting, omdat deze in de loop van de tijd blijft toe- of afnemen, wat leidt tot over-/ondervoorspellingen. Het is waarschijnlijk veiliger om een andere benadering te gebruiken voor langetermijnvoorspellingen.

Interessant genoeg kan het toevoegen van meer historische data soms averechts werken en leiden tot een afname van de nauwkeurigheid van de voorspelling. Prophet staat niet toe om meer gewicht te geven aan de meest recente waarnemingen, dus meer data kan leiden tot een afname van de nauwkeurigheid van de voorspelling.
Hier zou de tip zijn om te experimenteren met verschillende lengtes van historische data en de lengte te kiezen die de beste resultaten oplevert.

Ondanks enkele onmiskenbare voordelen is Prophet geen plug-and-play model. Het vergt wat tijd om het af te stellen om de prestaties te verbeteren. Sommige zwakke punten maken het moeilijk om te vertrouwen op de stabiliteit in de productie.
Om te beoordelen hoe vaak we het model opnieuw zouden moeten trainen, vergeleken we 2 strategieën. We genereerden prognoses voor verschillende maanden en maten de resultaten:

Het model elke maand opnieuw trainen leverde betere resultaten op. Concluderend waren de hyperparameters ondanks de temporele kruisvalidatie niet stabiel in de tijd. Voor XGboost hoef je een dergelijke hertraining niet vaak uit te voeren. Deze resultaten moeten echter met voorzichtigheid worden behandeld, omdat de volumes werden beïnvloed door de COVID-crisis op het moment dat we deze benchmark maakten. Ook hier was onze intuïtie om het resultaat te verklaren dat de trend moeilijk correct in te schatten is.

Een van de nadelen van dit univariate model is dat je één model per SKU nodig hebt, in vergelijking met boomgebaseerde benaderingen waarbij je hetzelfde model voor veel producten kunt gebruiken.

Meestal leidt dit tot betere prestaties, zoals Pierre-Yves Mousset al aangaf in zijn project. Het hebben van veel modellen kan echter een technische uitdaging zijn en een nachtmerrie om te onderhouden.

Het gebruiksgemak van Prophet maakte het tot een zeer goed basismodel wanneer je tijdreeksen gemakkelijk opsplitst in eenvoudige temporele componenten. Als je signaal echter ruis bevat, kan het een heel gedoe zijn om de prestaties van het model te verfijnen.

Dankzij de uitsplitsing van de voorspelling in tijdcomponenten zijn de beslissingen van het model eenvoudig te interpreteren. Toch is het niet nauwkeurig genoeg om te worden gebruikt om de impact van een externe gebeurtenis te meten, omdat je nooit weet of het effect van de gebeurtenis al is meegenomen in de oorspronkelijke tijdcomponenten.

Als uw tijdreeks enkele bedrijfscycli volgt, kunt u snel zeer goede prestaties verkrijgen zonder intensieve functie-engineering. De trendcomponent wordt echter niet altijd goed geschat en dit kan aanzienlijke prestatiedrift veroorzaken. Daarom kan dit model zorgvuldige controle en frequente menselijke interventies vereisen.

Als je enige verklaarbaarheid wilt bieden en eenvoudig en snel een fatsoenlijk model wilt bouwen, is Prophet een optie om te overwegen. Als je echter waarde hecht aan stabiliteit en nauwkeurigheid van voorspellingen, overweeg dan het gebruik van een ander soort algoritme, zoals boomgebaseerde modellen, Orbit of DeepAR.