Classes for callback implementors¶
fastai provides a powerful callback system, which is documented on the callbacks page; look on that page if you're just looking for how to use existing callbacks. If you want to create your own, you'll need to use the classes discussed below.
A key motivation for the callback system is that additional functionality can be entirely implemented in a single callback, so that it's easily read. By using this trick, we will have different methods categorized in different callbacks where we will find clearly stated all the interventions the method makes in training. For instance in the LRFinder callback, on top of running the fit function with exponentially growing LRs, it needs to handle some preparation and clean-up, and all this code can be in the same callback so we know exactly what it is doing and where to look if we need to change something.
In addition, it allows our fit function to be very clean and simple, yet still easily extended. So far in implementing a number of recent papers, we haven't yet come across any situation where we had to modify our training loop source code - we've been able to use callbacks every time.
To create a new type of callback, you'll need to inherit from this class, and implement one or more methods as required for your purposes. Perhaps the easiest way to get started is to look at the source code for some of the pre-defined fastai callbacks. You might be surprised at how simple they are! For instance, here is the entire source code for GradientClipping:
@dataclass
class GradientClipping(LearnerCallback):
clip:float
def on_backward_end(self, **kwargs):
if self.clip:
nn.utils.clip_grad_norm_(self.learn.model.parameters(), self.clip)
You generally want your custom callback constructor to take a Learner parameter, e.g.:
@dataclass
class MyCallback(Callback):
learn:Learner
Note that this allows the callback user to just pass your callback name to callback_fns when constructing their Learner, since that always passes self when constructing callbacks from callback_fns. In addition, by passing the learner, this callback will have access to everything: e.g all the inputs/outputs as they are calculated, the losses, and also the data loaders, the optimizer, etc. At any time:
- Changing self.learn.data.train_dl or self.data.valid_dl will change them inside the fit function (we just need to pass the
DataBunchobject to the fit function and not data.train_dl/data.valid_dl) - Changing self.learn.opt.opt (We have an
OptimWrapperon top of the actual optimizer) will change it inside the fit function. - Changing self.learn.data or self.learn.opt directly WILL NOT change the data or the optimizer inside the fit function.
In any of the callbacks you can unpack in the kwargs:
n_epochs, contains the number of epochs the training will take in totalepoch, contains the number of the currentiteration, contains the number of iterations done since the beginning of trainingnum_batch, contains the number of the batch we're at in the dataloaderlast_input, contains the last input that got through the model (eventually updated by a callback)last_target, contains the last target that got through the model (eventually updated by a callback)last_output, contains the last output spitted by the model (eventually updated by a callback)last_loss, contains the last loss computed (eventually updated by a callback)smooth_loss, contains the smoothed version of the losslast_metrics, contains the last validation loss and metrics computedpbar, the progress bartrain, flag to know if we're in training mode or notstop_training, that will stop the training at the end of the current epoch if Truestop_epoch, that will break the current epoch loopskip_step, that will skip the next optimizer stepskip_zero, that will skip the next zero grad
When returning a dictionary with those key names, the state of the CallbackHandler will be updated with any of those changes, so in any Callback, you can change those values.
Methods your subclass can implement¶
All of these methods are optional; your subclass can handle as many or as few as you require.
Here we can initiliaze anything we need. The optimizer has now been initialized. We can change any hyper-parameters by typing, for instance:
self.opt.lr = new_lr
self.opt.mom = new_mom
self.opt.wd = new_wd
self.opt.beta = new_betaThis is not technically required since we have on_train_begin for epoch 0 and on_epoch_end for all the other epochs,
yet it makes writing code that needs to be done at the beginning of every epoch easy and more readable.
Here is the perfect place to prepare everything before the model is called. Example: change the values of the hyperparameters (if we don't do it on_batch_end instead)
At the end of that event xb,yb will be set to last_input, last_target of the state of the CallbackHandler.
Here is the place to run some code that needs to be executed after the output has been computed but before the loss computation. Example: putting the output back in FP32 when training in mixed precision.
At the end of that event the output will be set to last_output of the state of the CallbackHandler.
Here is the place to run some code that needs to be executed after the loss has been computed but before the gradient computation.
Example: reg_fn in RNNs.
At the end of that event the output will be set to last_loss of the state of the CallbackHandler.
Here is the place to run some code that needs to be executed after the gradients have been computed but before the optimizer is called.
If skip_step is True at the end of this event, the optimizer step is skipped.
Here is the place to run some code that needs to be executed after the optimizer step but before the gradients are zeroed.
If skip_zero is True at the end of this event, the gradients are not zeroed.
Here is the place to run some code that needs to be executed after a batch is fully done. Example: change the values of the hyperparameters (if we don't do it on_batch_begin instead)
If end_epoch is True at the end of this event, the current epoch is interrupted (example: lr_finder stops the training when the loss explodes).
Here is the place to run some code that needs to be executed at the end of an epoch. Example: Save the model if we have a new best validation loss/metric.
If end_training is True at the end of this event, the training stops (example: early stopping).
Here is the place to tidy everything. It's always executed even if there was an error during the training loop, and has an extra kwarg named exception to check if there was an exception or not. Examples: save log_files, load best model found during training
Annealing functions¶
The following functions provide different annealing schedules. You probably won't need to call them directly, but would instead use them as part of a callback. Here's what each one looks like:
You probably won't need to use this class yourself. It's used by fastai to combine all the callbacks together and call any relevant callback functions for each training stage. The methods below simply call the equivalent method in each callback function in self.callbacks.
This is a convenience class that provides a consistent API for getting and setting optimizer hyperparameters. For instance, for optim.Adam the momentum parameter is actually betas[0], whereas for optim.SGD it's simply momentum. As another example, the details of handling weight decay depend on whether you are using true_wd or the traditional L2 regularization approach.
This class also handles setting different WD and LR for each layer group, for discriminative layer training.
Used for smoothing loss in Recorder.
Used for creating annealing schedules, mainly for OneCycleScheduler.
See the documentation on metrics for more information.
Callback methods¶
You don't call these yourself - they're called by fastai's Callback system automatically to enable the class's functionality.