3.1 Hyperparameter Tuning

Hyperparameter tuning is supported via the extension package mlr3tuning. The heart of mlr3tuning are the R6 classes:

  • TuningInstance: This class describes the tuning problem and stores results.
  • Tuner: This class is the base class for implementations of tuning algorithms.

3.1.1 The TuningInstance Class

The following sub-section examines the optimization of a simple classification tree on the Pima Indian Diabetes data set.

We use the classification tree from rpart and choose a subset of the hyperparameters we want to tune. This is often referred to as the “tuning space”.

Here, we opt to tune two parameters namely on the one hand the complexity cp and second of all the termination criterion minsplit. As the tuning space has to be bound,one needs to set lower and upper bounds:

Next, we are able to define how to evaluate the performance. In order to determine the evaluation method, one has to choose a resampling strategy and a performance measure.

Finally, one has to select the budget available, to solve this tuning instance. This is done by selecting one of the available Terminators:

For this short introduction, we grant a budget of 20 evaluations and then put everything together into a TuningInstance:

To start the tuning, we still need to select how the optimization should take place. In other words, we need to choose the optimization algorithm via the Tuner class.

3.1.2 The Tuner Class

The following algorithms are currently implemented in mlr3tuning:

In this example, we will use a simple grid search with a grid resolution of 10:

Since we have only numeric parameters, TunerGridSearch will create a grid of equally-sized steps between the respective upper and lower bounds. As we have two hyperparameters with a resolution of 5, the two-dimensional grid consists of \(5^2 = 25\) configurations. Each configuration serves as hyperparameter setting for the classification tree and triggers a 3-fold cross validation on the task. All configurations will be examined by the tuner (in a random order), until either all configurations are evaluated or the Terminator signals that the budget is exhausted.

3.1.3 Triggering the Tuning

To start the tuning, we simply pass the TuningInstance to the $tune() method of the initialized Tuner. The tuner proceeds as follow:

  1. The Tuner proposes at least one hyperparameter configuration (the Tuner and may propose multiple points to improve parallelization, which can be controlled via the setting batch_size).
  2. For each configuration, a Learner is fitted on Task using the provided Resampling. The results are combined with other results from previous iterations to a single BenchmarkResult.
  3. The Terminator is queried if the budget is exhausted. If the budget is not exhausted, restart with 1) until it is.
  4. Determine the configuration with the best observed performance.
  5. Return a named list with the hyperparameter settings ("values") and the corresponding measured performance ("performance").

One can investigate all resamplings which where undertaken, using the $archive() method of the TuningInstance. Here, we just extract the performance values and the hyperparameters:

In sum, the grid search evaluated 20/25 different configurations of the grid in a random order before the Terminator stopped the tuning.

Now the optimized hyperparameters can take the previously created Learner, set the returned hyperparameters and train it on the full dataset.

The trained model could now be used to make a prediction on external data. Note that predicting on observations present in the task, is statistically bias and should be avoided. The model has already seen these observations during the tuning process. Hence, the resulting performance measure would be over-optimistic. Instead, to get unbiased performance estimates for the current task, nested resampling is required.

3.1.4 Automating the Tuning

The AutoTuner wraps a learner and augments it with an automatic tuning for a given set of hyperparameters. Because the AutoTuner itself inherits from the Learner base class, it can be used like any other learner. Analogously to the previous subsection, a new classification tree learner is created. This classification tree learner automatically tunes the parameters cp and minsplit using an inner resampling (holdout). We create a terminator which allows 10 evaluations, and use a simple random search as tuning algorithm:

We can now use the learner like any other learner, calling the $train() and $predict() method. This time however, we pass it to benchmark() to compare the tuner to a classification tree without tuning. This way, the AutoTuner will do its resampling for tuning on the training set of the respective split of the outer resampling. The learner then predicts using the test set of the outer resampling. This yields unbiased performance measures, as the observations in the test set have not been used during tuning or fitting of the respective learner. This is called nested resampling.

To compare the tuned learner with the learner using its default, we can use benchmark():

Note that we do not expect any differences compared to the non-tuned approach for multiple reasons:

  • the task is too easy
  • the task is rather small, and thus prone to overfitting
  • the tuning budget (10 evaluations) is small
  • rpart does not benefit that much from tuning


Bergstra, James, and Yoshua Bengio. 2012. “Random Search for Hyper-Parameter Optimization.” J. Mach. Learn. Res. 13. JMLR.org: 281–305.