How to Know Your Fine-Tune Worked

Every fine-tune ends with the same moment: the training loss curve has flattened, the run is done, and someone has to answer the only question that matters — did it work? Not "did the loss go down" (it always goes down; that is what training is) but "does the model now do the thing we trained it to do, on inputs it has never seen, without breaking what it already did".

The answer does not come from the training run. It comes from the evaluation you built before the run started — the held-out set, the metrics, the comparison against the base model. The how-much-data post covered building the dataset; this post covers judging the result.

And the judgment is the expensive part to get wrong, because a bad fine-tune does not announce itself. It ships quietly, as a model that is confidently wrong in a new way.

The rule is simple and absolute: the examples you evaluate on must never appear in the training set. A model tested on its own training data is a student grading its own homework, and the score is meaningless — memorization looks exactly like learning, and the eval cannot tell them apart.

So the dataset splits before the run: most of it trains, a slice is held out for evaluation, and the held-out slice is sacred. It is not tuned against, not peeked at, not "just checked once". The eval-before-purchase post made the same point for model selection; the discipline is identical for model training.

The held-out set should also look like production. If your training data is clean and your traffic is messy, the eval measures the wrong thing — the dataset-preparation post's curation advice applies to the eval slice with equal force.

The classic signature: training loss keeps falling while held-out performance stops improving, then starts getting worse. The model is memorizing the training set instead of learning the behavior, and the gap between the two curves is the overfitting, made visible.

In behavior, overfitting shows up as rigidity: the model reproduces the training examples' exact phrasing, fails on inputs that are slightly different from anything it saw, and loses the general competence it had before training — the base model's flexibility traded for a narrow imitation.

The fix is not mysterious: more and better data (the how-much-data post's answer), less aggressive training — fewer epochs, a lower learning rate, earlier stopping — and adapter methods that change fewer parameters, which is one of the reasons the adapter comparison favors LoRA for small datasets. Overfitting is a dial, not a verdict.

Every metric has a blind spot, and the blind spots are where bad fine-tunes hide. Exact-match scores reward the model that memorized the phrasing and punish the model that answered correctly in different words. Perplexity measures fluency, not correctness — a confidently wrong answer can be perfectly fluent. And aggregate scores average the failure modes away: a model that is excellent on the common cases and broken on the rare ones can post a fine average while failing exactly the cases that matter.

So the metric set is chosen per task, and the choice is a product decision. A classification task wants precision and recall per class, not an average. A drafting task wants a rubric, not an exact match. The eval post's rubric discipline transfers directly: the bar is written before the run, in the language of the product, not the language of the loss function.

And the base model is the control group. Every fine-tune metric is only meaningful against the same metric run on the un-fine-tuned model — improvement is a comparison, not a number.

The things users notice first. Tone: does the model still sound like the product, or like the training data's author? Refusals: does it still decline what it should decline, or did training teach it to always answer? Regression: did the fine-tune break the general competence it started with — the model that now formats perfectly but reasons worse?

These need eyes, not just metrics. A small human review of held-out outputs — the spot-check discipline from the eval post's judge section — catches what the numbers cannot, and it is cheap enough to run on every training run, not just the important ones.

And the review should include the failures. A fine-tune's error patterns are the roadmap for the next dataset: every reviewed mistake is a free annotation for the next run.

For a throwaway experiment, a quick manual look is proportionate — the full apparatus above is for models that will serve users. The trigger is the same as everywhere else on this blog: the moment someone else depends on the model, the eval stops being ceremony.

What is never overkill is the held-out set. It costs one slice of the dataset at preparation time and it is the difference between knowing and believing. Everything else can scale with the stakes; the held-out set is the floor.

And the honest framing: evaluation is not the tax on fine-tuning, it is the fine-tuning. A training run without an eval is a coin flip with a GPU bill attached.