Hii, I am trying to use hierarchical forecasting in my sdk. Till now I was only predicting at the lowest level and was making use of clustering also to group the similar time series together. Now if I perform aggregation on my training data and treat the parent time series separately, how to change my clustering logic accordingly. Based on current setup, We perform clustering on panel data to group related time series. Each cluster undergoes hyperparameter tuning to identify the best model for that group. However, introducing hierarchical reconciliation presents a challenge—series at the same level of the hierarchy might end up in different clusters, potentially disrupting the reconciliation process. For example, consider a sales hierarchy where Total Sales is broken down into Region A (Store 1, Store 2) and Region B (Store 3, Store 4). Ideally, reconciliation ensures that the sum of store-level forecasts aligns with their respective regional forecasts and ultimately with total sales. However, clustering might group (Store 1, Store 3) in one cluster and (Store 2, Store 4) in another, even though Store 1 and Store 2 belong to Region A, and Store 3 and Store 4 belong to Region B. This disrupts the natural hierarchical structure and can lead to inconsistencies when reconciling forecasts across levels. I’m seeking guidance on how to ensure reconciliation in such a setup. Any insights would be greatly appreciated!

I'd just set the Cluster as an additional group to perform reconciliation on (so assign the cluster ID to each time series, and then include it in the spec), e.g.:

spec = [["country"], ["country", "region"], ["country", "cluster"], ["country", "store"], ["country", "region", "cluster", "store"]]

In non-strict hierarchical structures like these, it's likely that you end up with small inconsistencies. I'd try out multiple reconcilers and see what works best for your use case.

The issue I am facing is when I create Y_hier_df, it also introduces parent time series in the df by aggregating different levels, now if I perform clustering on top of that, it can also group parent series along with child series. So, it would lead to distortions in clustering process as well, as parents series would be smoothed out and of different magnitude. And if I perform clustering at each level of hierarchy, then it would make the process too slow for algorithms like dtw.

I'd cluster then on the lowest level only. I'd avoid costly algorithms like dtw, there are many good alternatives available.

Ok, thanks for the suggestions @Olivier

For clustering, no. Re. second question, an example is: tslearn.clustering.TimeSeriesKMeans — tslearn 0.6.3 documentation. You'll find that you can set the metric inside this to

dtw

too, but I'd start with the (much) faster default, which is

euclidean

Untitled

Hi, yes, unfortunately our docs precede our release cycle 🤪 You can fix the error by doing the following:

Y_hat_df = fcst.forecast(df=Y_train_df, h=group.horizon, fitted=True)

Y_fitted_df = fcst.forecast_fitted_values()

Y_rec_df = hrec.reconcile(Y_hat_df=Y_hat_df, Y_df=Y_fitted_df, S=S_df, tags=tags)

We'll soon make a new release that this fix is no longer required and the doc works as expected.

Actually I am using forecasts from algorithms that arre already implemented in my sdk and some of those dont support in-sample predictions. So, in that case if I don't provide in sample predictions for training dataset, it throws an error.

The latter is fixed in the upcoming release