Sudden increase in log-loss on training set with H2O GBM

Question

I am performing a hyperparameter grid search for a GBM classifier in H2O, running version 3.10.4.8 (on top of python 3.5.3). This is a multiclass problem (~40 classes).

As a first test, I tried a small grid of parameters, to study the effect of the learning rate, [0.01, 0.05, 0.1], and max depth, [5, 7, 10]. In this example, I didn't use a stopping criterion or validation set, but rather set a large number of trees and just let it run.

The graph below shows the behavior of the log-loss as a function of tree number, for a few sets of parameters.

What strikes me about this behavior is the sudden jump in log-loss at larger tree number for the higher learning rates (and perhaps this behavior would happen eventually for the learning rate of 0.01). My general understanding is that training log-loss should continually decrease with a long tail, while validation log-loss will start to increase at some point, necessitating early stopping to prevent overfitting. Even in that scenario, however, I wouldn't expect such a large and instantaneous jump.

Does anyone have insight into why this behavior might occur? Is there some other parameter that I'm not setting properly that could cause this? Something with the sampling? Or am I fundamentally misunderstanding something about how GBMs function?

Thanks!

Answer 1

I've hit problems like this, and it was due to hitting numeric instability (floating point numbers getting too big or too small). That lowering the learning rate makes it happen later is supporting evidence for that idea.

In every case it was always doing something unreasonable; as soon as you do bring in the validation training set, and early stopping, you never reach enough trees for the algorithm to have this kind of nervous breakdown. (The other place it happens is with deep learning auto encoders, when not using Tanh activation.)

If it does still happen, then either you have a very interesting data set and/or you have found a bug in H2O. I'm sure the developers would love it if you could narrow it down to a small reproducible example, as it could be quite a serious bug.