trainingmodule in Avalanche is designed with modularity in mind. Its main goals are to:
trainingmodule includes two main components:
torch.optim.Optimizeralready initialized on your
eval. Both of them, accept either a single experience(
Experience) or a list of them, for maximum flexibility.
train_streamprovided by the scenario.
pluginsthat will be executed during the training/evaluation loops.
pluginslist to the
BaseStrategy). 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 together, 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
BaseStrategyloop, which can be a bit complex at first.
BaseStrategy, which provides generic training and evaluation loops. Most
BaseStrategymethods can be safely overridden (with some caveats that we will see later).
modelswithout using Avalanche's strategies!
BaseStrategy. This strategy provides:
before/afterare the methods responsible for calling the plugins. Notice that before the start of each experience during training we have several phases:
modelstutorial) are updated by calling their
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 classification problems, mini-batches have the form
<x, y, t>, where
xis the input,
yis the target class, and
tis the task label.
self.mb_output: the current model's output.
self.loss: the current loss.
Trueif the strategy is in training mode.
StrategyPluginand implements the callbacks that you need. The exact callback to use depend on your strategy. 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_expto update the buffer after each training experience, and the
before_training_expto customize the dataloader. Notice that
before_training_expis executed after
make_train_dataloader, which means that the
BaseStrategyalready updated the dataloader. If we used another callback, such as
before_train_dataset_adaptation, our dataloader would have been overwritten by the
BaseStrategy. Plugin methods always receive the
strategyas an argument, so they can access and modify the strategy's state.
StrategyPlugin's documentation for a complete list of the available callbacks.
BaseStrategymethods. However, There is an important caveat to keep in mind. If you override a method, you must remember to call all the callback's handlers (the methods starting with
before/after) at the appropriate points. For example,
after_trainingbefore and after the training loops, respectively. The easiest way to avoid mistakes is to start from the
BaseStrategymethod that you want to override and modify it to your own needs without removing the callbacks handling.
BaseStrategyimplements some internal components as plugins. Also, the
evaluationtutorial) uses the strategy callbacks.
BaseStrategyprovides the global state of the loop in the strategy's attributes, which you can safely use when you override a method. As an example, the
Cumulativestrategy trains a model continually on the union of all the experiences encountered so far. To achieve this, the cumulative strategy overrides
adapt_train_datasetand updates `self.adapted_dataset' by concatenating all the previous experiences with the current one.
BaseStrategy. It also allows other people to use your plugin and facilitates interoperability among different strategies.
BaseStrategyor as plugins. However, creating a plugin is allows to use the replay strategy in conjunction with other strategies.