Tune your forecasting models
Imports
Data setup
Optimization
Default optimization
We have default search spaces for some models and we can define default features to look for based on the length of the seasonal period of your data. For this example we’ll use hourly data, for which we’ll set 24 (one day) as the season length.| unique_id | ds | lgb | ridge | |
|---|---|---|---|---|
| 0 | H1 | 701 | 680.534943 | 604.140123 |
| 1 | H1 | 702 | 599.038307 | 523.364874 |
| 2 | H1 | 703 | 572.808421 | 479.174481 |
| 3 | H1 | 704 | 564.573783 | 444.540062 |
| 4 | H1 | 705 | 543.046026 | 419.987657 |
| lgb | ridge | |
|---|---|---|
| SMAPE | 18.78 | 20.00 |
| MASE | 5.07 | 1.29 |
| OWA | 1.57 | 0.81 |
Tuning model parameters
You can provide your own model with its search space to perform the optimization. The search space should be a function that takes an optuna trial and returns the model parameters.| my_lgb | |
|---|---|
| SMAPE | 18.64 |
| MASE | 4.76 |
| OWA | 1.50 |
Tuning scikit-learn pipelines
We internally use BaseEstimator.set_params for each configuration, so if you’re using a scikit-learn pipeline you can tune its parameters as you normally would with scikit-learn’s searches.| ridge | |
|---|---|
| SMAPE | 18.50 |
| MASE | 1.24 |
| OWA | 0.76 |
Tuning features
TheMLForecast class defines the features to build in its constructor.
You can tune the features by providing a function through the
init_config argument, which will take an optuna trial and produce a
configuration to pass to the MLForecast constructor.
| AutoRidge | |
|---|---|
| SMAPE | 13.31 |
| MASE | 1.67 |
| OWA | 0.71 |
Tuning fit parameters
TheMLForecast.fit method takes some arguments that could improve the
forecasting performance of your models, such as dropna and
static_features. If you want to tune those you can provide a function
to the fit_config argument.
| AutoLightGBM | |
|---|---|
| SMAPE | 18.78 |
| MASE | 5.07 |
| OWA | 1.57 |
M5 example: reuse CV splits + global/group rolling means
This example shows both features in two small snippets: We can speed up the tuning process by reusing the cv splits. In traditional tuning, the cv splits are created inside each tuning round, which can be slow depending on data size and number of iterations. With reuse_cv_splits=True these splits are created once and consumed inside the tuning rounds without the need to split the data again.- We benchmark
reuse_cv_splits=TrueagainstFalsewhile keeping the search space fixed to a single configuration. We still run multiple Optuna trials, but every trial evaluates the exact same model and feature settings, so the timing difference comes from reusing the cached CV windows instead of rebuilding them on each trial. - For the example below, the speed up when setting reuse_cv_splits=True is around 22% compared to reuse_cv_splits=True (standard setting)
- We inspect the resulting feature values for
RollingMean(..., global_=True)andRollingMean(..., groupby=[...])to see how the local, global, and grouped aggregations differ.
global_ and groupby; here we
only show RollingMean.
| ds | unique_id | state_id | cat_id | rolling_mean_lag1_window_size7 | global_rolling_mean_lag1_window_size7 | groupby_state_id_rolling_mean_lag1_window_size7 | groupby_state_id__store_id_rolling_mean_lag1_window_size7 | |
|---|---|---|---|---|---|---|---|---|
| 1968 | 2016-06-19 | FOODS_1_001_CA_1 | CA | FOODS | 0.857143 | 137.428574 | 64.428574 | 11.428572 |
| 3937 | 2016-06-19 | FOODS_1_001_CA_2 | CA | FOODS | 1.142857 | 137.428574 | 64.428574 | 23.714285 |
| 5906 | 2016-06-19 | FOODS_1_001_CA_3 | CA | FOODS | 1.714286 | 137.428574 | 64.428574 | 19.571428 |
| 7874 | 2016-06-19 | FOODS_1_001_CA_4 | CA | FOODS | 0.428571 | 137.428574 | 64.428574 | 9.714286 |
| 21632 | 2016-06-19 | FOODS_1_002_CA_1 | CA | FOODS | 1.285714 | 137.428574 | 64.428574 | 11.428572 |
| 23601 | 2016-06-19 | FOODS_1_002_CA_2 | CA | FOODS | 0.714286 | 137.428574 | 64.428574 | 23.714285 |
| 25570 | 2016-06-19 | FOODS_1_002_CA_3 | CA | FOODS | 0.285714 | 137.428574 | 64.428574 | 19.571428 |
| 27538 | 2016-06-19 | FOODS_1_002_CA_4 | CA | FOODS | 0.571429 | 137.428574 | 64.428574 | 9.714286 |
| 41300 | 2016-06-19 | FOODS_1_003_CA_1 | CA | FOODS | 0.142857 | 137.428574 | 64.428574 | 11.428572 |
| 43269 | 2016-06-19 | FOODS_1_003_CA_2 | CA | FOODS | 1.428571 | 137.428574 | 64.428574 | 23.714285 |
| 45238 | 2016-06-19 | FOODS_1_003_CA_3 | CA | FOODS | 0.428571 | 137.428574 | 64.428574 | 19.571428 |
| 47206 | 2016-06-19 | FOODS_1_003_CA_4 | CA | FOODS | 0.142857 | 137.428574 | 64.428574 | 9.714286 |
| ds | y | lag1 | rolling_mean_lag1_window_size7 | global_rolling_mean_lag1_window_size7 | groupby_state_id_rolling_mean_lag1_window_size7 | groupby_state_id__store_id_rolling_mean_lag1_window_size7 | |
|---|---|---|---|---|---|---|---|
| count | 181878 | 181878.000000 | 181778.000000 | 181178.000000 | 181552.000000 | 181552.000000 | 181552.000000 |
| mean | 2013-12-12 09:05:38.112361216 | 1.341410 | 1.341383 | 1.338734 | 128.771957 | 44.179596 | 12.859269 |
| min | 2011-01-29 00:00:00 | 0.000000 | 0.000000 | 0.000000 | 32.857143 | 5.285714 | 0.428571 |
| 25% | 2012-09-22 00:00:00 | 0.000000 | 0.000000 | 0.142857 | 92.285713 | 29.142857 | 6.857143 |
| 50% | 2013-12-23 00:00:00 | 0.000000 | 0.000000 | 0.428571 | 129.071426 | 41.571430 | 11.285714 |
| 75% | 2015-03-23 00:00:00 | 1.000000 | 1.000000 | 1.142857 | 162.000000 | 57.000000 | 17.000000 |
| max | 2016-06-19 00:00:00 | 116.000000 | 116.000000 | 49.285713 | 298.714294 | 149.571426 | 61.000000 |
| std | NaN | 3.615288 | 3.615864 | 3.123487 | 51.012020 | 21.452202 | 7.960689 |
Accessing the optimization results
After the process has finished the results are available under theresults_ attribute of the AutoMLForecast object. There will be one
result per model and the best configuration can be found under the
config user attribute.
Individual models
There is one optimization process per model. This is because different models can make use of different features. So after the optimization process is done for each model the best configuration is used to retrain the model using all of the data. These final models areMLForecast
objects and are saved in the models_ attribute.
Saving
You can use theAutoMLForecast.save method to save the best models
found. This produces one directory per model.
MLForecast object you can load it by itself.

