training
module.training
module in Avalanche is designed with modularity in mind. Its main goals are to:training
module includes three main components:BaseSGDTemplate
contains all the implemented methods to deal with strategies based on SGD).torch.nn.Module
.torch.optim.Optimizer
already initialized on your model
.torch.nn.functional
.train
and eval
. Both of them, accept either a single experience(Experience
) or a list of them, for maximum flexibility.train_stream
provided by the scenario.plugins
that will be executed during the training/evaluation loops.plugins
list to the SupervisedTemplate
:Naive
strategy). Therefore, the easiest way to define a custom strategy such as a regularization or replay strategy, is to define it as a custom plugin. The advantage of plugins is that they can be combined, as long as they are compatible, i.e. they do not modify the same part of the state. The disadvantage is that in order to do so you need to understand the strategy loop, which can be a bit complex at first.BaseTemplate
, from which all the Avalanche's strategies inherit. Most template's methods can be safely overridden (with some caveats that we will see later).benchmarks
, evaluation
, and models
without using Avalanche's strategies!SupervisedTemplate
). These templates provide:before/after
are the methods responsible for calling the plugins. Notice that before the start of each experience during training we have several phases:models
tutorial) are updated by calling their adaptation
method.self.clock
: keeps track of several event counters.self.experience
: the current experience.self.adapted_dataset
: the data modified by the dataset adaptation phase.self.dataloader
: the current dataloader.self.mbatch
: the current mini-batch. For supervised classification problems, mini-batches have the form <x, y, t>
, where x
is the input, y
is the target class, and t
is the task label.self.mb_output
: the current model's output.self.loss
: the current loss.self.is_training
: True
if the strategy is in training mode.Naive
strategy). This approach reduces the overhead and code duplication, improving code readability and prototyping speed.BasePlugin
, BaseSGDPlugin
, SupervisedPlugin
) and implements the callbacks that you need. The exact callback to use depend on the aim of your plugin. You can use the loop shown above to understand what callbacks you need to use. For example, we show below a simple replay plugin that uses after_training_exp
to update the buffer after each training experience, and the before_training_exp
to customize the dataloader. Notice that before_training_exp
is executed after make_train_dataloader
, which means that the Naive
strategy already updated the dataloader. If we used another callback, such as before_train_dataset_adaptation
, our dataloader would have been overwritten by the Naive
strategy. Plugin methods always receive the strategy
as an argument, so they can access and modify the strategy's state.before/after
) at the appropriate points. For example, train
calls before_training
and after_training
before and after the training loops, respectively. The easiest way to avoid mistakes is to start from the template's method that you want to override and modify it to your own needs without removing the callbacks handling.EvaluationPlugin
(see evaluation
tutorial) uses the strategy callbacks.SupervisedTemplate
, for continual supervised strategies, provides the global state of the loop in the strategy's attributes, which you can safely use when you override a method. For instance, the Cumulative
strategy trains a model continually on the union of all the experiences encountered so far. To achieve this, the cumulative strategy overrides adapt_train_dataset
and updates `self.adapted_dataset' by concatenating all the previous experiences with the current one.