Training
Continual Learning Algorithms Prototyping Made Easy
Welcome to the "Training" tutorial of the "From Zero to Hero" series. In this part we will present the functionalities offered by the
training module.First, let's install Avalanche. You can skip this step if you have installed it already.
!pip install avalanche-lib=0.2.1
The
training module in Avalanche is designed with modularity in mind. Its main goals are to:- 1.provide a set of popular continual learning baselines that can be easily used to run experimental comparisons;
- 2.provide simple abstractions to create and run your own strategy as efficiently and easily as possible starting from a couple of basic building blocks we already prepared for you.
At the moment, the
training module includes three main components:- Templates: these are high level abstractions used as a starting point to define the actual strategies. The templates contain already implemented basic utilities and functionalities shared by a group of strategies (e.g. the
BaseSGDTemplatecontains all the implemented methods to deal with strategies based on SGD). - Strategies: these are popular baselines already implemented for you which you can use for comparisons or as base classes to define a custom strategy.
- Plugins: these are classes that allow to add some specific behaviour to your own strategy. The plugin system allows to define reusable components which can be easily combined (e.g. a replay strategy, a regularization strategy). They are also used to automatically manage logging and evaluation.
Keep in mind that many Avalanche components are independent of Avalanche strategies. If you already have your own strategy which does not use Avalanche, you can use Avalanche's benchmarks, models, data loaders, and metrics without ever looking at Avalanche's strategies!
If you want to compare your strategy with other classic continual learning algorithm or baselines, in Avalanche you can instantiate a strategy with a couple lines of code.
Most strategies require only 3 mandatory arguments:
- model: this must be a
torch.nn.Module. - optimizer:
torch.optim.Optimizeralready initialized on yourmodel. - loss: a loss function such as those in
torch.nn.functional.
Additional arguments are optional and allow you to customize training (batch size, number of epochs, ...) or strategy-specific parameters (memory size, regularization strength, ...).
from torch.optim import SGD
from torch.nn import CrossEntropyLoss
from avalanche.models import SimpleMLP
from avalanche.training.supervised import Naive, CWRStar, Replay, GDumb, Cumulative, LwF, GEM, AGEM, EWC # and many more!
model = SimpleMLP(num_classes=10)
optimizer = SGD(model.parameters(), lr=0.001, momentum=0.9)
criterion = CrossEntropyLoss()
cl_strategy = Naive(
model, optimizer, criterion,
train_mb_size=100, train_epochs=4, eval_mb_size=100
)
Each strategy object offers two main methods:
train and eval. Both of them, accept either a single experience(Experience) or a list of them, for maximum flexibility.We can train the model continually by iterating over the
train_stream provided by the scenario.from avalanche.benchmarks.classic import SplitMNIST
# scenario
benchmark = SplitMNIST(n_experiences=5, seed=1)
# TRAINING LOOP
print('Starting experiment...')
results = []
for experience in benchmark.train_stream:
print("Start of experience: ", experience.current_experience)
print("Current Classes: ", experience.classes_in_this_experience)
cl_strategy.train(experience)
print('Training completed')
print('Computing accuracy on the whole test set')
results.append(cl_strategy.eval(benchmark.test_stream))
Most continual learning strategies follow roughly the same training/evaluation loops, i.e. a simple naive strategy (a.k.a. finetuning) augmented with additional behavior to counteract catastrophic forgetting. The plugin systems in Avalanche is designed to easily augment continual learning strategies with custom behavior, without having to rewrite the training loop from scratch. Avalanche strategies accept an optional list of
plugins that will be executed during the training/evaluation loops.For example, early stopping is implemented as a plugin:
from avalanche.training.plugins import EarlyStoppingPlugin
strategy = Naive(
model, optimizer, criterion,
plugins=[EarlyStoppingPlugin(patience=10, val_stream_name='train')])
In Avalanche, most continual learning strategies are implemented using plugins, which makes it easy to combine them together. For example, it is extremely easy to create a hybrid strategy that combines replay and EWC together by passing the appropriate
plugins list to the SupervisedTemplate:from avalanche.training.templates import SupervisedTemplate
from avalanche.training.plugins import ReplayPlugin, EWCPlugin
replay = ReplayPlugin(mem_size=100)
ewc = EWCPlugin(ewc_lambda=0.001)
strategy = SupervisedTemplate(
model, optimizer, criterion,
plugins=[replay, ewc])
Beware that most strategy plugins modify the internal state. As a result, not all the strategy plugins can be combined together. For example, it does not make sense to use multiple replay plugins since they will try to modify the same strategy variables (mini-batches, dataloaders), and therefore they will be in conflict.
If you arrived at this point you already know how to use Avalanche strategies and are ready to use it. However, before making your own strategies you need to understand a little bit the internal implementation of the training and evaluation loops.
In Avalanche you can customize a strategy in 2 ways:
- 1.Plugins: Most strategies can be implemented as additional code that runs on top of the basic training and evaluation loops (e.g. the
Naivestrategy). 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. - 2.Subclassing: In Avalanche, continual learning strategies inherit from the appropriate template, which provides generic training and evaluation loops. The most high level template is the
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).
Keep in mind that if you already have a working continual learning strategy that does not use Avalanche, you can use most Avalanche components such as
benchmarks, evaluation, and models without using Avalanche's strategies!As we already mentioned, Avalanche strategies inherit from the appropriate template (e.g. continual supervised learning strategies inherit from the
SupervisedTemplate). These templates provide:- 1.Basic Training and Evaluation loops which define a naive (finetuning) strategy.
- 2.Callback points, which are used to call the plugins at a specific moments during the loop's execution.
- 3.A set of variables representing the state of the loops (current model, data, mini-batch, predictions, ...) which allows plugins and child classes to easily manipulate the state of the training loop.
The training loop has the following structure:
train
before_training
before_train_dataset_adaptation
train_dataset_adaptation
after_train_dataset_adaptation
make_train_dataloader
model_adaptation
make_optimizer
before_training_exp # for each exp
before_training_epoch # for each epoch
before_training_iteration # for each iteration
before_forward
after_forward
before_backward
after_backward
after_training_iteration
before_update
after_update
after_training_epoch
after_training_exp
after_training
The evaluation loop is similar:
eval
before_eval
before_eval_dataset_adaptation
eval_dataset_adaptation
after_eval_dataset_adaptation
make_eval_dataloader
model_adaptation
before_eval_exp # for each exp
eval_epoch # we have a single epoch in evaluation mode
before_eval_iteration # for each iteration
before_eval_forward
after_eval_forward
after_eval_iteration
after_eval_exp
after_eval
Methods starting with
before/after are the methods responsible for calling the plugins. Notice that before the start of each experience during training we have several phases:- dataset adaptation: This is the phase where the training data can be modified by the strategy, for example by adding other samples from a separate buffer.
- dataloader initialization: Initialize the data loader. Many strategies (e.g. replay) use custom dataloaders to balance the data.
- model adaptation: Here, the dynamic models (see the
modelstutorial) are updated by calling theiradaptationmethod. - optimizer initialization: After the model has been updated, the optimizer should also be updated to ensure that the new parameters are optimized.
The strategy state is accessible via several attributes. Most of these can be modified by plugins and subclasses:
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>, wherexis the input,yis the target class, andtis the task label.self.mb_output: the current model's output.self.loss: the current loss.self.is_training:Trueif the strategy is in training mode.
Plugins provide a simple solution to define a new strategy by augmenting the behavior of another strategy (typically the
Naive strategy). This approach reduces the overhead and code duplication, improving code readability and prototyping speed.Creating a plugin is straightforward. As with strategies, you have to create a class which inherits from the corresponding plugin template (
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.from avalanche.benchmarks.utils.data_loader import ReplayDataLoader
from avalanche.core import SupervisedPlugin
from avalanche.training.storage_policy import ReservoirSamplingBuffer
class ReplayP(SupervisedPlugin):
def __init__(self, mem_size):
""" A simple replay plugin with reservoir sampling. """
super().__init__()
self.buffer = ReservoirSamplingBuffer(max_size=mem_size)
def before_training_exp(self, strategy: "SupervisedTemplate",
num_workers: int = 0, shuffle: bool = True,
**kwargs):
""" Use a custom dataloader to combine samples from the current data and memory buffer. """
if len(self.buffer.buffer) == 0:
# first experience. We don't use the buffer, no need to change
# the dataloader.
return
strategy.dataloader = ReplayDataLoader(
strategy.adapted_dataset,
self.buffer.buffer,
oversample_small_tasks=True,
num_workers=num_workers,
batch_size=strategy.train_mb_size,
shuffle=shuffle)
def after_training_exp(self, strategy: "SupervisedTemplate", **kwargs):
""" Update the buffer. """
self.buffer.update(strategy, **kwargs)
benchmark = SplitMNIST(n_experiences=5, seed=1)
model = SimpleMLP(num_classes=10)
optimizer = SGD(model.parameters(), lr=0.01, momentum=0.9)
criterion = CrossEntropyLoss()
strategy = Naive(model=model, optimizer=optimizer, criterion=criterion, train_mb_size=128,
plugins=[ReplayP(mem_size=2000)])
strategy.train(benchmark.train_stream)
strategy.eval(benchmark.test_stream)
Check base plugin's documentation for a complete list of the available callbacks.
You can always define a custom strategy by overriding the corresponding template methods. 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, 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.Notice that the
EvaluationPlugin (see evaluation tutorial) uses the strategy callbacks.As an example, the
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.from avalanche.benchmarks.utils import AvalancheConcatDataset
from avalanche.training.templates import SupervisedTemplate
class Cumulative(SupervisedTemplate):
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
self.dataset = None # cumulative dataset
def train_dataset_adaptation(self, **kwargs):
super().train_dataset_adaptation(**kwargs)
curr_data = self.experience.dataset
if self.dataset is None:
self.dataset = curr_data
else:
self.dataset = AvalancheConcatDataset([self.dataset, curr_data])
self.adapted_dataset = self.dataset.train()
strategy = Cumulative(model=model, optimizer=optimizer, criterion=criterion, train_mb_size=128)
strategy.train(benchmark.train_stream)
Easy, isn't it? :-)
In general, we recommend to implement a Strategy via plugins, if possible. This approach is the easiest to use and requires a minimal knowledge of the strategy templates. It also allows other people to re-use your plugin and facilitates interoperability among different strategies.
For example, replay strategies can be implemented as a custom strategy or as plugins. However, creating a plugin allows to use the replay in conjunction with other strategies or plugins, making possible the combination of different approach to build the ultimate continual learning algorithm!.
This completes the "Training" chapter for the "From Zero to Hero" series. We hope you enjoyed it!