4. Performance Analysis

Imagine that two neural networks are trained to classify images of clothing. Both models reach 99% accuracy on the training data. However, when the models are evaluated on images that were not used during training, the first reaches 88% accuracy while the second reaches only 62%. What explains the difference?

According to the reported numbers, both models can reproduce the correct labels for almost every training image. But this alone does not prove that they have learned a useful, generalizable rule. The first model has learned a relationship that transfers well to previously unseen examples. Instead, the second model may have memorized the training examples or relied on accidental patterns that do not extend beyond the training set.

The goal of machine learning is to produce a model that performs well on unseen examples relevant to a task, not just on the training data. This distinction changes how model development should be approached. Training becomes one part of a broader experiment designed to answer a more demanding question:

Has the model learned a relationship that generalizes beyond the data used to update its parameters?

Answering this question requires more than one accuracy value. We need clearly separated datasets, reliable evaluation procedures, learning curves, diagnostic tests, and controlled comparisons. When performance is poor, we must determine whether the problem lies in the data, the optimization procedure, the capacity of the model, or its ability to generalize. This lesson develops a systematic approach to that investigation.

1. Generalization Is The Goal

A model learns by adapting its parameters to the training data. If it cannot perform well on those examples, it has not learned the task successfully. Strong training performance is therefore necessary. However, a flexible neural network can adapt to patterns that are useful only within the training data. It may memorize unusual examples, exploit correlations that occurred by chance, or construct complicated rules around noisy labels. These adaptations reduce training loss but may not help the model perform well on new examples. Strong training performance is therefore not sufficient to assess the model against its designed task.

The following four concepts are crucial for understanding model performance.

Concept	Description	Remarks
Capacity	The family of relationships a model can represent.	A linear classifier has limited capacity, whereas a neural network has a much larger representational capacity.
Optimization	The process that searches for parameter values.	A model with adequate capacity can have poor training performance if optimization fails.
Training fit	How well the trained model performs on training data.	A model with insufficient capacity cannot fit training data, no matter how long it is trained.
Generalization	How well the trained model performs on data that did not affect its parameters.	A model may fit the training data perfectly but generalize poorly if it has adapted to accidental patterns that do not extend beyond the training samples.

These distinctions help us analyze the causes of poor performance. A model may perform poorly because it lacks capacity, because the optimizer has not found useful parameters, because the training data is unrepresentative, or because the model has adapted too strongly to training-specific details.

2. Data Partitions

A trustworthy evaluation depends on separating data according to purpose. The three standard partitions are the training set, the validation set, and the test set. These partitions are not interchangeable. Each one answers a different question and influences the development process in a different way.

Partition	Main role
Training set	Parameter updates and fitted preprocessing
Validation set	Model comparison and development decisions
Test set	Final evaluation to assess generalization

The exact proportions depend on the amount of available data, the variability of the task, grouping constraints, and the precision required from the final estimate. There is no universally correct percentage for each partition. You may see 80/10/10, 70/15/15, or other splits.

Training data

The training set contains the examples used to calculate gradients and update the model parameters during the optimization process. It also determines any preprocessing operation that must be fitted from data.

Suppose numerical features are standardized using a mean and standard deviation. Those statistics must be calculated from the training set. They become part of the fitted pipeline and are then applied unchanged to validation and test examples. The same principle applies to other fitted transformations, including:

• data normalization;

• missing-value imputation;

• feature selection;

• dimensionality reduction;

• vocabulary construction;

• resampling rules learned from class frequencies.

The training set may be evaluated during development to monitor progress. But this performance does not provide an independent estimate of generalization. The model has already adapted to those examples.

Validation data

The validation set contains examples that do not produce parameter updates. Its purpose is to evaluate the model while its parameters remain fixed. The resulting measurements guide choices such as:

• model architecture;

• learning rate;

• training duration;

• regularization strength;

• checkpoint selection;

• preprocessing alternatives.

Validation data is therefore not completely unused. It influences the final system indirectly through development decisions. This distinction is important. Training data affects parameters through gradients. Validation data affects development through model selection.

Now suppose we train hundreds of models, inspect validation performance after every run, and repeatedly modify the system to improve the validation score. Although the models were not trained on validation data, the development process has gradually adapted to it. This is sometimes described as overfitting the validation set. The development process is therefore not unlimited.

Test data

The test set is reserved for the end of development. It should not influence the model architecture, learning rates, training duration, or any other design decisions. Those choices must be made using only training and validation data. Once the model and training pipeline have been finalized, the test set provides an independent estimate of performance on unseen examples.

Now suppose there is a large difference between validation and test performance. The correct response is not to tune the model repeatedly on the test set until the score improves. Doing so would turn the test set into another validation set, effectively destroying its original purpose. If the test set is used to guide development, it is no longer independent and cannot provide an unbiased estimate of generalization.

As a general rule, the test set should never enter the development process. If development continues after the test results have been examined, a new untouched test set may eventually be required to obtain a genuinely unbiased estimate of final performance.

Data leakage

Data leakage occurs when information that should be unavailable during training or validation enters the development process. Leakage can make validation or test performance appear much stronger than performance on genuinely unseen data. It is particularly dangerous because the code may execute correctly and the evaluation metrics may look convincing.

Leakage can arise from many sources. It may be a coding mistake, a misunderstanding of the data, or an accidental property of the dataset. The following examples illustrate some common pitfalls.

• Leakage through fitted preprocessing.

  • Computing normalization statistics from the entire dataset.

  • Selecting features using all targets.

  • Fitting a dimensionality reduction method before splitting.

  • Imputing missing values using complete-dataset statistics.

  • Balancing or resampling before creating the splits.

• Leakage through partitioning.

  • Duplicated examples in training and test sets.

  • Grouped examples split across partitions.

  • Time-series data split without respecting temporal order.

• Leakage through repeated test-set use.

  • Selecting the best model using test accuracy.

  • Tuning hyper-parameters to improve test performance.

  • Repeating development after examining the test result.

3. Performance Diagnostics

A learning curve records a quantity such as loss or accuracy across epochs, thereby preserving the evolution of the training process. Learning curves are usually plotted for both training and validation data to provide a visual summary of the model’s behaviour. They show whether optimization is succeeding, whether fitting is progressing or regressing, and whether generalization is improving or deteriorating.

Learning curves help distinguish several broad situations, as summarized in the following table.

Training behaviour	Validation behaviour	Initial interpretation
Little or no improvement	Little or no improvement	Pipeline or optimization problem
Stabilizes at a weak level	Also weak	Underfitting or inadequate optimization
Becomes very strong	Stagnates or deteriorates	Overfitting or distribution mismatch
Strong and stable	Strong and stable	Promising generalization
Poor	Unexpectedly strong	Check for data leakage or implementation error

These interpretations are provisional. A model with poor training performance may lack capacity, but it may also be using an unsuitable learning rate. A large train-validation gap may indicate overfitting, but it may also reflect a mismatch between the two datasets.

Optimization

When a model does not fit the training data, it is tempting to make it larger. That may be the correct response, but only after we establish that optimization is functioning. A useful diagnostic principle is:

Do not diagnose insufficient capacity until the model proves it can learn under simpler conditions.

The following sequence of checks is designed to identify optimization problems. It starts with inexpensive inspections and delays architecture changes until there is evidence that the pipeline works.

Check	Purpose
Inspect examples	Verify that the data is loaded correctly and that labels match the inputs.
Verify shapes and dtypes	Confirm that the model input, output, and loss are compatible with the data.
Confirm that loss is finite	Detect numerical failure.
Inspect gradients	Detect disconnected or detached computations.
Confirm parameter updates	Detect optimizer misconfiguration.
Fit a tiny batch	Verify that the model can learn a small number of examples.
Diagnose the learning rate	Determine whether optimization is the dominant problem.

Inspect the data

Begin with the cheapest checks. Inspect one batch and verify that

• the feature shape matches the model input;

• the target format matches the loss function;

• class indices lie in the expected range;

• features and targets contain the same number of examples;

• values are finite;

• labels correspond to the inspected inputs.

For multiclass classification with cross-entropy, the model should normally return logits of shape (batch size, number of classes), while the targets should contain integer indices with shape (batch size,). An output-target mismatch can prevent learning even though the program runs.

Inspect gradients

Inspect the gradients after backpropagation and before the optimizer step. A missing gradient may indicate that the parameter did not contribute to the loss or that part of the computation was detached. Finite-gradient checks can also detect numerical failure. A small gradient is not automatically wrong. Some parameters legitimately receive smaller updates than others. The important question is whether the gradients are consistently absent, zero, or non-finite while the model fails to learn.

Confirm that parameters change

Gradients may exist while the optimizer still fails to update the intended parameters. Store a copy of the parameters before the update, perform the optimizer step, then compare. If the parameters do not change, possible explanations include:

• the optimizer was given the wrong parameter collection;

• the learning rate is zero or extremely small;

• optimizer.step() was not called;

• gradients were cleared before the step;

• the loss is disconnected from the parameters.

Fit a tiny batch

One of the strongest pipeline checks is to train the model on a very small group of examples. A sufficiently flexible model should usually drive the loss very low. Success indicates that:

• the forward computation is connected;

• the loss depends on the model output;

• gradients can be calculated;

• the optimizer can change the parameters;

• the model has enough capacity to fit at least these examples.

Failure suggests a more basic problem. Possible causes include incorrect labels, incompatible output dimensions, detached computations, missing gradients, unsuitable optimizer settings, or insufficient capacity even for the tiny subset.

Diagnose the learning rate

The learning rate controls the magnitude of parameter updates.

• Small learning rate –> The loss decreases only slightly within the available budget.

• Large learning rate –> The loss can oscillate, increase, or become non-finite.

A short comparison of different learning rates can test whether optimization is the dominant problem. The data split, architecture, initialization policy, number of epochs, and evaluation procedure should remain fixed. Otherwise, the experiment cannot isolate the learning rate.

Underfitting

A model underfits when its architecture or input representation is too limited to capture the data relationships required by the task. As a result, it cannot achieve adequate performance even on the training set. The most visible sign of underfitting is that the training loss stabilizes at a high value (or training accuracy stabilizes at a weak level) after optimization has made sufficient progress. Validation performance is usually poor as well, but the decisive evidence is the poor training performance: the model has not captured the examples on which its parameters were fitted.

Before attributing this behaviour to underfitting, we should verify that optimization is functioning correctly. An unsuitable learning rate, too few training epochs, or an incorrect training pipeline can also produce poor training performance. These are optimization failures rather than limitations of what the model can learn.

Once the training pipeline has been verified, possible causes of underfitting include:

• insufficient model capacity;

• an architecture that does not match the structure of the data;

• inadequate input representation;

• excessive regularization.

The capacity of a neural network can be increased through wider hidden layers, additional layers, or an architecture suited to the structure of the data. The final option is especially important. For images, a convolutional network can use spatial structure more effectively than an MLP. Increasing the width of an unsuitable architecture is not always the most useful change.

Important

A successful tiny-batch test does not prove that the model has enough capacity for the complete dataset. It shows that the training pipeline works and that the model can fit a small collection of examples. If the tiny-batch test succeeds, optimization appears stable, and training performance still plateaus at a weak level on the complete dataset, underfitting becomes a credible diagnosis.

Overfitting

A model overfits when it becomes increasingly successful on the training data without achieving corresponding improvement on unseen examples. A typical pattern is that training loss continues to decrease, while validation loss decreases initially but then stagnates or increases. A possible explanation is that the model may have captured broad useful patterns early in training, but later updates increasingly exploit details that are specific to the training data. This is why overfitting often appears after a period of useful learning. A single worse validation epoch is not enough evidence to conclude overfitting. Diagnosis should rely on a sustained divergence between training and validation behaviour.

The following table summarizes some common causes of overfitting.

Factor	How it can harm generalization
Accidental patterns	The model learns correlations that occurred by chance in the training sample
Noisy targets	The model constructs special rules around incorrect or ambiguous labels
High capacity	The model has many ways to fit idiosyncratic details in training data
Excessive training	As training progresses, it increasingly focuses on difficult or unusual examples
Limited coverage	The training set omits important variations present in future data
Repeated model selection	Development decisions adapt too strongly to validation data

Important

A model with many adjustable parameters can represent a large family of functions. This flexibility may be necessary for a difficult problem, but it also provides many ways to fit idiosyncrasies in a limited sample of training data. The relevant issue is not capacity alone, but capacity relative to the complexity of the task and the available amount of training data. A large neural network does not automatically overfit, but it requires more care to avoid overfitting.

Distribution mismatch

Poor validation performance does not always indicate conventional overfitting. Suppose an image classifier is trained on well-lit photographs but validated on dark mobile-phone images. The model may have learned a stable relationship within the training distribution while failing under different conditions. This is distribution mismatch. If the training data is not representative of the target population, the model may adapt to patterns that do not transfer to future examples. The problem is not that the model has memorized the training data, but that the training data does not reflect the conditions in which the model will be used.

If there is a mismatch between the training and validation distributions, the learning curves may resemble overfitting because training performance is strong while validation performance remains weak. However, the appropriate intervention may not be to take steps to reduce overfitting. It may be necessary to collect more representative data or revise the splitting procedure. This is why inspecting errors and examples is as important as plotting aggregate metrics.

4. Improving Generalization

Once overfitting is a credible diagnosis, we can consider interventions to improve generalization. The appropriate intervention depends on the suspected cause. More data improves coverage of the underlying distribution. Regularization changes the optimization objective. Dropout changes the training-time computation. Early stopping changes which parameter state is selected. Each intervention has different implications for training, validation performance, and the final model.

More and better data

Additional training examples can reduce reliance on accidental patterns from a small dataset. The value of new data depends on what variation it contributes. Repeated examples from one narrow source may add less value than examples covering meaningful differences in the target population. Data quality also matters. Correcting labels, improving class balance, and removing duplicated examples may be more valuable than collecting a larger quantity of unreliable data. When distribution mismatch is the problem, the new examples should reflect the conditions in which the model will operate.

Important

Improving data quality and coverage is often more effective than increasing model complexity.

Adjusting model capacity

A model with unnecessary capacity has more ways to fit training-specific details. Reducing hidden width or depth can improve generalization when the architecture is much more flexible than the available data requires. However, reducing capacity too far causes underfitting. The objective is not to build the smallest possible model. It is to use enough capacity to represent the stable relationship without introducing complexity that provides no measured benefit. A controlled width experiment might compare different hidden sizes while keeping the architecture, learning rate, data split, training budget, and initialization policy fixed. If the larger model achieves lower training loss but identical validation performance, the additional capacity improved fitting without improving generalization under the tested conditions.

Regularization

Regularization modifies the optimization objective to discourage solutions that are overly specialized to the training data. Weight decay, dropout, and other techniques can reduce overfitting by penalizing large parameter values or by changing the training-time computation. Regularization does not guarantee better generalization. If the regularization strength is too large, the model may fail to fit the training data adequately. A controlled experiment can compare different regularization strengths while keeping the architecture, learning rate, data split, training budget, and initialization policy fixed.

Weight decay

Weight decay discourages the optimizer from producing unnecessarily large parameter values. It introduces a preference for solutions with smaller weights when several parameter configurations fit the training data similarly. Weight decay does not guarantee better generalization. If the value is too large, the model may fail to fit the training data adequately. In PyTorch, weight decay can be configured through the optimizer.

Dropout

Dropout randomly suppresses part of a hidden representation during training. Because the available activations change from one pass to another, the model cannot rely as strongly on one fixed collection of hidden units. This can reduce co-adaptation and improve generalization in some settings, although it is not universally beneficial.

Dropout behaves differently during training and evaluation. During training, a random subset of activations is suppressed, and the remaining activations are scaled to preserve their expected magnitude. During evaluation, dropout is disabled and all activations pass through unchanged. In PyTorch, the switch occurs by calling model.train() and model.eval().

Early stopping

Early stopping ends training after validation performance has failed to improve for a chosen number of epochs. It should not be confused with checkpointing. Checkpointing saves the model state at the best validation epoch, whereas early stopping determines when training should end.

Data augmentation

For some data types, new training examples can be created through transformations that preserve the target. An image may remain in the same class after a small crop, translation, or brightness adjustment. Training on such variations encourages the model to use features that remain stable under those transformations. Data augmentation introduces assumptions about invariance. A horizontal flip may preserve the label of a shoe, but it may not preserve the meaning of text or directional symbols. Poorly chosen transformations can alter the meaning of an example and harm learning. Because these assumptions depend strongly on the data domain, augmentation will be studied in more depth with convolutional image models.

5. Controlled experiments

Model improvement should not be an uncontrolled sequence of changes. Otherwise, it is impossible to determine which change caused a difference in performance. A useful experiment changes one planned factor while keeping the remaining conditions as stable as reasonably possible. Four elements should be stated explicitly when designing a controlled experiment.

• Hypothesis: a proposed explanation that can be tested through experimentation.

• Independent variable: the factor that is deliberately changed to test the hypothesis.

• Outcome: the measurement that will be compared across different values of the independent variable.

• Controlled conditions: the factors that are kept fixed to isolate the effect of the independent variable.

Example

Suppose the learning curves show strong training performance and a widening validation gap. A controlled experiment might test whether weight decay improves generalization.

• Hypothesis: “Moderate weight decay will reduce training fit but improve validation loss.”

• Independent variable: Weight-decay value.

• Outcome: Best validation loss obtained during training.

• Controlled conditions: Data split, preprocessing, model, optimizer, learning rate, epochs.

Baselines

Every improvement should be compared with a meaningful reference. A baseline may be a majority-class prediction, a linear classifier, a small neural network, the current best validated system, or the same architecture without the proposed modification. The baseline must use the same data split and evaluation procedure. A complex model that reaches 85% validation accuracy is not impressive if a much simpler model reaches 84% under the same conditions.

Negative results

A controlled experiment does not need to improve the model to be informative. Suppose dropout reduces both training and validation performance. Several explanations become plausible: the original model was not overfitting strongly, the dropout probability was too large, optimization became more difficult, or the training budget was insufficient for the regularized model. The result narrows the investigation. A negative result becomes difficult to interpret when several factors changed simultaneously or when the outcome was selected after repeatedly inspecting many alternatives.

Repeated runs

Neural-network training contains randomness. Parameter initialization, data shuffling, and stochastic layers can cause two otherwise identical runs to produce different results. Fixing a seed makes a comparison easier to reproduce. However, one seed does not establish that a small performance difference is robust. When two methods differ only slightly, repeated runs with several seeds provide stronger evidence. The mean and variation across runs can reveal whether an apparent improvement is consistent or merely the result of one favourable initialization. Nonetheless, not every experiment requires repeated runs.

6. Conclusion

A model should do more than perform well on training data: it must generalize to new examples. Comparing training and validation performance helps determine whether the main problem is failed optimization, underfitting, overfitting, or a mismatch between the training and validation distributions. Once we have a clear hypothesis, we should change one factor at a time and compare the results under the same conditions. The validation set guides these decisions, while the test set remains untouched until the final evaluation.

        ---
config:
  flowchart:
    rankSpacing: 15

---
flowchart TD

  A[Model performs poorly]
  B{Can it fit a tiny batch?}
  C[Fix pipeline or optimization]
  D[Train on full training set]
  E{Converged?}
  F[Adjust optimizer, learning rate, or number of epochs]
  G[Proceed to next stage]

  A --> B
  B -- No --> C
  B -- Yes --> D
  D --> E
  E -- No --> F
  E -- Yes --> G


  H[Once training has stabilized]
  I{Training strong?}
  J[Underfitting]
  K{Validation strong?}
  L["<div style='text-align:center'>Overfitting or<br/> distribution mismatch</div>"]
  M[No obvious problem]

  H --> I
  I -- No --> J
  I -- Yes --> K
  K -- No --> L
  K -- Yes --> M
    

---

Final Quiz

Quiz

What is the primary role of the validation set?

Answer

Validation data guides development choices such as architecture, learning rate, regularization, training duration, and checkpoint selection. It does not directly produce gradients, but it still influences the final system.

Quiz

A dataset is divided into training, validation, and test partitions. Which procedure is correct?

• Calculate separate normalization statistics for each partition.

• Calculate normalization statistics using all partitions together.

• Calculate statistics from the training set and apply them to every partition.

• Calculate statistics from the test set because it provides the final estimate.

Answer

Fitted preprocessing must be determined from the training set. The resulting transformation is then applied unchanged to validation and test data.

Quiz

A model reaches 100% accuracy on its training data. Which conclusion is justified?

• The model has solved the task.

• The model will reach 100% accuracy on new data.

• The model can correctly classify the training examples.

• The model cannot be overfitting.

Answer

The result shows that the model classifies the training examples correctly. It does not establish how the model behaves on unseen data.

Quiz

A model finishes training with 72% validation accuracy. Is that enough information to decide whether it underfits or overfits?

Answer

No. We also need training performance and the evolution of both training and validation measurements across epochs.

Quiz

Training and validation losses are both high and nearly constant. Which problem should be investigated first?

• A. Overfitting

• B. Optimization or pipeline failure

• C. Test-set leakage

• D. Excessively strong generalization

Answer

The model has not successfully fitted the training data. Verify the data, outputs, loss, gradients, optimizer, and learning rate before diagnosing generalization.

Quiz

Training loss continues decreasing while validation loss has increased for several epochs. What does this pattern suggest?

Answer

It suggests overfitting: later updates continue improving adaptation to the training data without improving performance on validation examples.

Quiz

A larger model reaches lower training loss but identical validation performance. What can we conclude?

Answer

The additional capacity improved training fit but did not improve generalization under the tested conditions. This does not prove that larger models are always unnecessary.

Quiz

A model perfectly fits 16 examples. Does this prove that it will generalize?

Answer

No. It only demonstrates that the model and optimization pipeline can fit those examples. Generalization must still be measured on held-out data.

Quiz

A model has poor training accuracy. Increasing its width does not help, but changing the learning rate causes training loss to decrease rapidly. Was the original problem primarily insufficient capacity?

Answer

No. The evidence points more strongly toward an optimization problem.

Quiz

A model reaches 58% training accuracy and 57% validation accuracy. The loss has stabilized, the model fits a tiny batch, and several learning rates have been tested. Which explanation is now plausible?

Answer

The model may be underfitting because its capacity or input representation is inadequate.

Quiz

A model contains dropout. Validation is performed inside torch.inference_mode(), but model.eval() is never called. Is the procedure correct?

Answer

No. `torch.inference_mode()` disables gradient tracking, but it does not switch dropout into evaluation behaviour. `model.eval()` is also required.

Quiz

After adding dropout and weight decay, doubling the hidden width, and changing the optimizer, validation accuracy improved. Which change caused the improvement?

Answer

The experiment cannot determine that. Several factors changed simultaneously, so their effects are confounded.

Quiz

A model is evaluated on the test set. The result is disappointing, so the architecture is changed and evaluated on the same test set again. Is the second result still an independent final evaluation?

Answer

No. The first test result influenced development. The test set has become part of the selection process.