Loading Batches with Data Loaders

Before a model can be fine-tuned for classification, you need a reliable way to answer a simple question: how often is the model right? The script examined in this article answers that question for three separate datasets, named here as training, validation, and test. The script is small, but it rewards careful reading, because almost every number it prints is the result of a chain of steps you can follow line by line.

The working approach is to run one accuracy function on three different data loaders and print the three results side by side. Read the script first and predict what each printed line will tell you. Then trace how the values are produced. The most useful debugging skill for this kind of script is knowing exactly where to look when a number seems wrong, and that skill is what this article builds.

The source names three data loaders: train_loader, val_loader, and test_loader. Each one supplies batches of examples from a different dataset. Accuracy can be calculated for each of them, and this is the central idea of the section: the same model can be evaluated on training, validation, and test data, producing a separate accuracy for each.

The same function, calc_accuracy_loader, is called three times. Each call receives a different loader, but the same model and the same device. The argument num_batches=10 is passed in every call, so each calculation uses the same batch limit. The loader is therefore the main input that distinguishes the three results. If the model, device, and batch limit are held constant, a difference between the three printed numbers can be traced back to the data each loader supplies.

A data loader does not hand the evaluation code an entire dataset at once. It supplies the dataset's examples in groups called batches. Each call to the accuracy function consumes batches from the loader it receives, which means the loader determines both which examples are looked at and how many of them are looked at in one pass.

The source does not explain what calc_accuracy_loader does internally, so this article does not describe its internals. What the script makes clear is its interface: the function takes a loader, a model, a device, and a batch count, and it returns a value that the script later multiplies by 100 for display. Everything beyond that interface should be treated as something to verify in the source code rather than assumed.

The three calls share a common shape. The first argument changes from call to call, while the model, the device, and the batch limit stay fixed. The pattern below is an illustrative rewrite of that shape. The variable names on the left are placeholders chosen for this article, because the source identifies only the three loaders and the arguments, not the exact result variable names.

The source describes num_batches as a batch limit that each calculation uses. Read literally, a limit of 10 means each call works with at most ten batches from its loader. A smaller number would mean fewer batches are evaluated, and the reported accuracy would be based on a smaller slice of that loader's data. The loop below shows how a limit of five would progress through a loader, as a reasoning exercise rather than a description of the function's internals.

The function returns a fraction, not a percentage. The f-strings in the print lines multiply that fraction by 100 and format it to two decimal places before printing. Every printed percentage can therefore be reconstructed by hand from one variable and one format string.

Because the three numbers come from three different loaders under shared conditions, they are meant to be compared, but with care. A higher training number than validation number, for example, tells you about the two datasets as evaluated by the same model under the same batch limit. The source treats the three results as separate values to be compared thoughtfully, rather than as a single score that can be read at a glance.