Advanced usage¶

This notebook shows some more advanced features of skorch. More examples will be added with time.

Run in Google Colab

View source on GitHub

Table of contents¶

• Setup
• Callbacks
  • Writing your own callback
  • Accessing callback parameters
• Working with different data types
  • Working with datasets
  • Working with dicts
• Multiple return values
  • Implementing a simple autoencoder
  • Training the autoencoder
  • Extracting the decoder and the encoder output

Setup¶

A toy binary classification task¶

We load a toy classification task from sklearn.

Definition of the pytorch classification module¶

We define a vanilla neural network with two hidden layers. The output layer should have 2 output units since there are two classes. In addition, it should have a softmax nonlinearity, because later, when calling predict_proba, the output from the forward call will be used.

Callbacks¶

Callbacks are a powerful and flexible way to customize the behavior of your neural network. They are all called at specific points during the model training, e.g. when training starts, or after each batch. Have a look at the skorch.callbacks module to see the callbacks that are already implemented.

Writing a custom callback¶

Although skorch comes with a handful of useful callbacks, you may find that you would like to write your own callbacks. Doing so is straightforward, just remember these rules:

• They should inherit from skorch.callbacks.Callback.
• They should implement at least one of the on_-methods provided by the parent class (e.g. on_batch_begin or on_epoch_end).
• As argument, the on_-methods first get the NeuralNet instance, and, where appropriate, the local data (e.g. the data from the current batch). The method should also have **kwargs in the signature for potentially unused arguments.
• Optional: If you have attributes that should be reset when the model is re-initialized, those attributes should be set in the initialize method.

Here is an example of a callback that remembers at which epoch the validation accuracy reached a certain value. Then, when training is finished, it calls a mock Twitter API and tweets that epoch. We proceed as follows:

• We set the desired minimum accuracy during __init__.
• We set the critical epoch during initialize.
• After each epoch, if the critical accuracy has not yet been reached, we check if it was reached.
• When training finishes, we send a tweet informing us whether our training was successful or not.

Now we initialize a NeuralNetClassifier and pass your new callback in a list to the callbacks argument. After that, we train the model and see what happens.

Oh no, our model never reached a validation accuracy of 0.7. Let's train some more (this is possible because we set warm_start=True):

Finally, the validation score exceeded 0.7. Hooray!

Accessing callback parameters¶

Say you would like to use a learning rate schedule with your neural net, but you don't know what parameters are best for that schedule. Wouldn't it be nice if you could find those parameters with a grid search? With skorch, this is possible. Below, we show how to access the parameters of your callbacks.

To simplify the access to your callback parameters, it is best if you give your callback a name. This is achieved by passing the callbacks parameter a list of name, callback tuples, such as:

callbacks=[
    ('scheduler', LearningRateScheduler)),
    ...
],

This way, you can access your callbacks using the double underscore semantics (as, for instance, in an sklearn Pipeline):

callbacks__scheduler__epoch=50,

So if you would like to perform a grid search on, say, the number of units in the hidden layer and the learning rate schedule, it could look something like this:

param_grid = {
    'module__num_units': [50, 100, 150],
    'callbacks__scheduler__epoch': [10, 50, 100],
}

Note: If you would like to refresh your knowledge on grid search, look here, here, or in the Basic_Usage notebok.

Below, we show how accessing the callback parameters works our AccuracyTweet callback:

As you can see, by passing callbacks__tweet__min_accuracy=0.6, we changed that parameter. The same can be achieved by calling the set_params method with the corresponding arguments:

Working with different data types¶

Working with Datasets¶

We encourage you to not pass Datasets to net.fit but to let skorch handle Datasets internally. Nonetheless, there are situations where passing Datasets to net.fit is hard to avoid (e.g. if you want to load the data lazily during the training). This is supported by skorch but may have some unwanted side-effects relating to sklearn. For instance, Datasets cannot split into train and validation in a stratified fashion without explicit knowledge of the classification targets.

Below we show what happens when you try to fit with Dataset and the stratified split fails:

As you can see, the stratified split fails since y is not known. There are two solutions to this:

• turn off stratified splitting ( net.train_split.stratified=False)
• pass y explicitly (if possible), even if it is implicitely contained in the Dataset

The second solution is shown below:

Working with dicts¶

The standard case¶

skorch has built-in support for dictionaries as data containers. Here we show a somewhat contrived example of how to use dicts, but it should get the point across. First we create data and put it into a dictionary X_dict with two keys X0 and X1:

When skorch passes the dict to the pytorch module, it will pass the data as keyword arguments to the forward call. That means that we should accept the two keys XO and X1 in the forward method, as shown below:

As long as we keep this in mind, we are good to go.

Working with sklearn FunctionTransformer and GridSearch¶

sklearn makes the assumption that incoming data should be numpy/sparse arrays or something similar. This clashes with the use of dictionaries. Unfortunately, it is sometimes impossible to work around that for now (for instance using skorch with BaggingClassifier). Other times, there are possibilities.

When we have a preprocessing pipeline that involves FunctionTransformer, we have to pass the parameter validate=False so that sklearn allows the dictionary to pass through:

When trying a grid or randomized search, it is not that easy to pass a dict. If we try, we will get an error:

The error above occurs because sklearn gets the length of the input data, which is 2 for the dict, and believes that is inconsistent with the length of the target (1000).

To get around that, skorch provides a helper class called SliceDict. It allows us to wrap our dictionaries so that they also behave like a numpy array:

The SliceDict shows the correct length, shape, and is sliceable across values:

With this, we can call GridSearch just as expected:

Multiple return values from forward¶

Often, we want our Module.forward method to return more than just one value. There can be several reasons for this. Maybe, the criterion requires not one but several outputs. Or perhaps we want to inspect intermediate values to learn more about our model (say inspecting attention in a sequence-to-sequence model). Fortunately, skorch makes it easy to achieve this. In the following, we demonstrate how to handle multiple outputs from the Module.

To demonstrate this, we implement a very simple autoencoder. It consists of an encoder that reduces our input of 20 units to 5 units using two linear layers, and a decoder that tries to reconstruct the original input, again using two linear layers.

Implementing a simple autoencoder¶

The autoencoder module below actually returns a tuple of two values, the decoded input and the encoded input. This way, we cannot only use the decoded input to calculate the normal loss but also have access to the encoded state.

Since the module's forward method returns two values, we have to adjust our objective to do the right thing with those values. If we don't do this, the criterion wouldn't know what to do with the two values and would raise an error.

One strategy would be to only use the decoded state for the loss and discard the encoded state. For this demonstration, we have a different plan: We would like the encoded state to be sparse. Therefore, we add an L1 loss of the encoded state to the reconstruction loss. This way, the net will try to reconstruct the input as accurately as possible while keeping the encoded state as sparse as possible.

To implement this, the right method to override is called get_loss, which is where skorch computes and returns the loss. It gets the prediction (our tuple) and the target as input, as well as other arguments and keywords that we pass through. We create a subclass of NeuralNetRegressor that overrides said method and implements our idea for the loss.

Note: Alternatively, we could have used an unaltered NeuralNetRegressor but implement a custom criterion that is responsible for unpacking the tuple and computing the loss.

Training the autoencoder¶

Now that everything is ready, we train the model as usual. We initialize our net subclass with the AutoEncoder module and call the fit method with X both as input and as target (since we want to reconstruct the original data):

Voilà, the model was trained using our custom loss function that makes use of both predicted values.

Extracting the decoder and the encoder output¶

Sometimes, we may wish to inspect all the values returned by the foward method of the module. There are several ways to achieve this. In theory, we can always access the module directly by using the net.module_ attribute. However, this is unwieldy, since this completely shortcuts the prediction loop, which takes care of important steps like casting numpy arrays to pytorch tensors and batching.

Also, we cannot use the predict method on the net. This method will only return the first output from the forward method, in this case the decoded state. The reason for this is that predict is part of the sklearn API, which requires there to be only one output. This is shown below:

However, the net itself provides two methods to retrieve all outputs. The first one is the net.forward method, which retrieves all the predicted batches from the Module.forward and concatenates them. Use this to retrieve the complete decoded and encoded state:

The other method is called net.forward_iter. It is similar to net.forward but instead of collecting all the batches, this method is lazy and only yields one batch at a time. This can be especially useful if the output doesn't fit into memory:

Finally, let's make sure that our initial goal of having a sparse encoded state was met. We check how many activities are close to zero:

As we had hoped, the encoded state is quite sparse, with the majority of outpus being 0.