What Fine-Tuning Actually Changes Inside a Model

The question people skip

Everyone talks about fine-tuning as though it were a simple continuation of training: take a pretrained model, show it new data, and it learns the new task. That description is not wrong, but it hides the interesting part. A pretrained model already encodes an enormous amount of structure: statistical regularities about language, images, or whatever domain it was trained on. Fine-tuning does not erase that structure and replace it with something new. It perturbs it. Understanding the size and shape of that perturbation is the difference between using fine-tuning competently and using it as a black box you hope will work.

I think this matters because a lot of practical failures in fine-tuning come from treating it like training from scratch with a head start. People pick learning rates, epoch counts, and data volumes as if the model were a blank slate absorbing information for the first time. It is not. It is a highly organised system of weights that already sits in a good region of the loss landscape, and fine-tuning is a local search around that region. The geometry of that search is what actually determines whether you get a useful specialist model or a model that has quietly forgotten half of what made it useful in the first place.

What moves, and by how much

Concretely, fine-tuning updates weights via gradient descent on a new loss computed from your task-specific data, exactly as pretraining did. The mechanism is identical. What differs is the starting point and, usually, the learning rate and number of steps. Pretraining might involve hundreds of thousands of update steps starting from random initialisation. Fine-tuning often involves a few thousand steps, or even a few hundred, starting from weights that already produce coherent, useful representations. Because the starting point is good and the number of steps is small, the resulting weight changes tend to be small in magnitude relative to the original weights, even though they can have an outsized effect on behaviour.

Here is a way to make that concrete. Suppose a particular weight matrix in a transformer layer has values with a typical magnitude around 0.02 after pretraining, which is a realistic order of magnitude for many layers in normalised architectures. During fine-tuning on a modest dataset, say a few thousand labelled examples, over a handful of epochs with a small learning rate, the updates to that same matrix might shift individual values by something on the order of 0.001 to 0.005 per relevant entry. That sounds tiny. But if those shifts are concentrated in the directions that matter for the new task, specifically the directions the model uses to decide between a small set of output classes or to attend to task-relevant tokens, the net effect on output behaviour can be dramatic. A small rotation in a high-dimensional space can change which region of that space an input lands in, and that region is what ultimately gets mapped to a prediction.

This is why fine-tuning can look like it has taught the model an entirely new skill while, in weight space, almost nothing has changed. Most of the pretrained representation, the part that encodes general syntactic or visual structure, stays close to where it started. A comparatively small subset of parameters, often concentrated in the later layers and in components that feed directly into the final prediction, absorbs most of the adaptation. This is also the empirical observation that motivates parameter-efficient methods like low-rank adapters: if the useful update lives in a small subspace, you do not need to touch every parameter to capture it, you can approximate the update with a much smaller number of trainable parameters and get similar results at a fraction of the memory cost.

Why this changes how you should evaluate

If fine-tuning is a small, targeted perturbation rather than a rebuild, then the biggest practical risk is not that the model fails to learn the new task, it is that the perturbation quietly damages capabilities you were relying on and did not test for. This is usually called catastrophic forgetting, though in most realistic fine-tuning regimes it is rarely total and rarely catastrophic in the dramatic sense; it is more often a gradual erosion of performance on inputs that differ from your fine-tuning distribution. If you fine-tune a general-purpose model on a narrow set of customer support tickets, you should expect its behaviour on inputs well outside that domain to drift, even if nothing in your training loop explicitly told it to forget anything.

The practical consequence is that evaluating a fine-tuned model only on your target task's held-out set is not enough. Suppose your fine-tuning set achieves a validation accuracy improvement from 78 percent to 91 percent on the target task, which looks like an unambiguous win. If you do not also check performance on a broader, held-out distribution that resembles what the model will actually see in production, you cannot tell whether that 13-point gain came at the cost of a 5-point regression on inputs that were previously handled correctly. This is a leakage-adjacent problem, not because your test set is contaminated with training data, but because your evaluation coverage is contaminated with your own assumptions about what the model will be asked to do.

A second, more subtle consequence concerns how much data and how many steps you actually need. Because fine-tuning starts from a good region of weight space, it typically requires far less data than training from scratch to reach a given level of task performance, and it is correspondingly easy to overshoot. Training for too many epochs on a small fine-tuning set pushes the weights further from the pretrained region than necessary, and the marginal gains on your task metric often come paired with disproportionate drift elsewhere. Tracking a validation metric that reflects general capability, not just task accuracy, and stopping early when that broader metric starts to slip, is a cheap and effective safeguard against this.

The practical takeaway

Fine-tuning is best understood as a small, structured nudge to a system that already works, not a rewrite. The updates are usually modest in magnitude, concentrated in specific components, and highly effective precisely because they operate within a representation space the pretrained model has already organised sensibly. That efficiency is also the source of the risk: small perturbations can have large behavioural consequences in directions you did not measure. Before you fine-tune anything, decide what your model needs to keep doing well, not just what you want it to newly do, and build that into your evaluation from the start rather than discovering the gap afterwards.