Evaluating a Classifier During Training

train_classifier_simple is a function used to fine-tune a model to classify spam. Its job is to train a model on a training dataset and, as training proceeds, to evaluate it on a validation dataset. Before reading its internals, it helps to look at it the way a programmer would: which inputs drive the loops, and which outputs does the function hand back to its caller?

The function takes the model, the two data loaders, an optimizer, the device to run on, and four control values: num_epochs, eval_freq, and eval_iter. The two data loaders are the training loader and the validation loader. The optimizer is the object that performs the weight updates.

The returned lists are what make the function useful after it finishes. Because the losses and accuracies are recorded at each evaluation point, you can follow how training progressed over time. examples_seen records how many training examples the model has processed in total, which gives a second way to place each measurement on a timeline.

The function has two loops, one inside the other. The outer loop, written as for epoch in range(num_epochs), runs once per epoch. At the start of each epoch the function calls model.train(), which puts the model in training mode. The inner loop, written as for input_batch, target_batch in train_loader, runs once per batch of training data. Only after the inner loop finishes does the outer loop move on to the next epoch.

The diagram below shows the progression for a small run with two epochs and three batches per epoch. Each batch passes through the same body of steps. The inner loop returns control to the outer loop only when every batch in the current epoch has been processed.

Each batch runs four steps in a fixed order. First, the optimizer resets the loss gradients left over from the previous batch iteration. Second, the function computes the loss for the current input and target batch. Third, the loss is backpropagated, which calculates the loss gradients. Fourth, the optimizer uses those gradients to update the model weights. The reset sits at the top of the batch body because the gradients must be cleared before this batch's gradients are calculated.

The sequence below shows which part of the program acts at each point in one batch iteration. Read each arrow as a message from one part to another, in the order it happens.

After the weight update, the function does two bookkeeping actions. It adds the number of rows in the current input batch to examples_seen, using input_batch.shape[0]. It also increments global_step by one. The source notes that examples_seen counts examples rather than tokens, which is the change from the earlier pretraining code.

The counter global_step is what later decides whether an evaluation happens. It starts at -1 and increases with every batch across all epochs. It is not reset at the start of each epoch, so it keeps counting through the whole run.

The check if global_step % eval_freq == 0 controls how often the model is evaluated. The % operator gives the remainder after division, so the condition is true whenever global_step is an exact multiple of eval_freq. This means eval_freq is a count of training steps between evaluations, not a count of epochs.

When the check passes, the function calls evaluate_model to get a training loss and a validation loss, appends both to their lists, and prints them with the current epoch and step. It then calculates accuracy on both loaders, using num_batches=eval_iter, so only a limited number of batches from each loader are used for this measurement.

The evaluate_model function is the other half of the picture. The source states it is identical to the one used for pretraining. It switches the model into evaluation mode with model.eval(), and it runs its calculations inside a torch.no_grad() block so that no gradients are computed. It estimates loss on both the training and validation datasets, and it does not update any weights. The training data is used only for measurement here; the weight updates that come from backpropagation happen only in the batch loop.

The function ends by setting the model back to training mode with model.train(). This matters because train_classifier_simple calls evaluate_model partway through an epoch, not only at epoch boundaries. Without that final call, the next batches would run with the model still in evaluation mode. This is also why the training function calls model.train() at the start of each epoch.