Here’s the failure mode I’ve seen wreck more fine-tuning projects than any other. A team ships a fine-tune. It handles a few example inputs well. Everyone’s thrilled. And then, in production, they slowly realise the model has gotten worse at things it used to do well, or that its handling of the trickier real-world inputs was never actually good, or that they can’t tell whether their latest tuning run was an improvement or a regression on the previous one. They shipped on vibes.
This article is about not doing that. Evaluating a fine-tuned model well isn’t glamorous, but it’s what separates real improvement from wishful thinking. And once you understand the specific shape it takes (which is a little different from evaluating prompts or RAG systems), it’s a straightforward, high-leverage practice you’ll never stop doing.
The two questions that matter
When you evaluate a fine-tune, you’re really answering two questions at the same time, and they’re both essential. Figure 1 shows the two-part framing.
Figure 1: Every fine-tune evaluation asks two questions. Did it get better at the target task? And did general ability hold up (or did we accidentally break something)? Both must be answered honestly before you can trust a fine-tune.
Question 1: Did the model get better at the target task? This is the obvious one. You fine-tuned to make the model do something specific better; you need to confirm that it actually does that thing better than it did before. If the answer is no, everything else is academic.
Question 2: Did general ability hold up? This is the one people forget, and it can bite badly. Fine-tuning nudges the whole model toward your data, and if you push too hard (too many epochs, too aggressive a learning rate, too narrow a dataset), the model can lose skills it used to have. It might now write your support replies well but do noticeably worse at explaining something completely different, or reasoning through a general problem. This regression is sometimes called catastrophic forgetting, and even mild versions of it are a real risk.
You need to answer both questions before shipping. A fine-tune that wins on question 1 and loses on question 2 might be worse overall than what you started with, depending on how much the model is used outside your target task.
The test set: two parts, one purpose
Everything in fine-tune evaluation rests on having the right test set, and given the two questions above, it should have two parts.
Part 1: Target-task test cases. Twenty to a hundred inputs from the domain you fine-tuned for. These should be representative of what real users will send: some easy, some tricky, some near-edge-cases. Crucially, these examples should be held out from training. If you evaluate on data the model was trained on, you’re grading yourself with an open-book exam, and the numbers will lie to you.
Part 2: General ability test cases. A separate small set of inputs from outside your fine-tuning domain, things the base model handled competently that the fine-tune should still handle competently. Simple reasoning questions, general knowledge, tasks that aren’t in your dataset. This is your safety net against catastrophic forgetting. Fifteen to thirty examples is plenty.
Both parts should be written down and kept stable across runs. The point isn’t a one-time judgement; it’s to compare fine-tuning runs against each other and against the base model on the exact same inputs. That comparability is where the value lives.
What to actually measure
For each test input, you’re comparing the fine-tuned model’s output against either a reference answer (if you have one) or clear criteria (if you don’t). A few practical measures:
- Correctness or accuracy, where there’s a clear right answer. Did it produce the correct classification, extract the right field, follow the exact format, arrive at the right number?
- Faithfulness to style or format, for style-and-format fine-tunes. Does the output actually sound like your brand? Does it follow the structure you trained for?
- Coverage of the answer, meaning did the response actually address the question fully, not just partially?
- Quality on a rubric, for fuzzier tasks. You define a small rubric (say, 1 to 5 on helpfulness, tone, and completeness), and score each output. Yes, it’s subjective; that’s fine, as long as the same person scores both the fine-tuned and base outputs the same way.
Two habits that make grading manageable. First, grade blind where you can, meaning you don’t know which output came from which model as you score them. It removes the bias to give your shiny new fine-tune the benefit of the doubt. Second, use a model-as-judge for larger test sets: ask a strong general model to score each response against your rubric. This scales well, but always spot-check a sample by eye so you can trust the judgements.
The essential comparison: fine-tune vs base
Now the core habit of fine-tune evaluation: always compare your fine-tuned model to the base model on the same inputs. Not just “how does the fine-tune score?”, but “how does the fine-tune score compared to what we already had?” Figure 2 shows what a real evaluation looks like.
Figure 2: Run both models over the same test set. Score both on target-task quality and on general-ability retention. Only ship if the fine-tune clearly wins on the target task and doesn’t lose meaningfully on general ability. A fine-tune that scores well by itself but doesn’t clearly beat the base isn’t worth the cost.
The reason this comparison matters: fine-tuning has real costs (training, hosting, maintenance) that a base model on its own doesn’t. If your fine-tune is only marginally better than the base, or better on the target but noticeably worse on general tasks, you may be paying real money to make your system worse overall. The head-to-head keeps you honest.
In practice, the comparison looks like this. For each test input, generate a response from both the base model and the fine-tuned model. Score both by your criteria. Then tally: how many wins for the fine-tune on the target task? Any losses on general ability? A clean, defensible improvement looks like the fine-tune winning clearly on target and holding steady on general. Anything murkier deserves another look before you ship.
The iteration loop
Evaluation isn’t a one-time gate at the end; it’s the feedback loop that guides how you fine-tune. Every training run gets scored on the same test set, and the numbers tell you whether the changes you’re making (more data, more epochs, different learning rate, different LoRA rank) are helping or hurting. Without this, you’re steering blind. With it, every change becomes a small experiment you learn from.
A pattern that works well in practice:
- Run a small first fine-tune (a subset of the data, few epochs) just to shake out the pipeline. Evaluate it.
- Iterate on the dataset based on where the model fails on the test set. Add more examples of the failure cases; clean up any inconsistencies you spot.
- Try a wider training run, evaluate again. Compare to the previous run’s scores, not just the base.
- Keep going only as long as the numbers are climbing. When they plateau, you’re done, or you need a fundamentally different change (bigger dataset, different technique) rather than more of the same.
Notice how much of this is data-driven, and how little of it is hyperparameter guessing. Most fine-tune improvement comes from dataset improvement, and evaluation is what tells you which data improvements are actually working.
Warning signs to watch for
A short field guide to what “something is wrong” looks like in fine-tune evaluation.
- Evaluation loss stops improving but training loss keeps falling. Classic overfitting; the model is memorising your training set. Stop training earlier or use fewer epochs.
- The fine-tune is worse than the base on general-ability tests. Catastrophic forgetting. Reduce epochs, drop the learning rate, or make sure your dataset is broad enough not to over-specialise.
- Great numbers on the target task, terrible in production. Your test set doesn’t match reality. Rewrite it using actual production inputs.
- The base model already scored well. Fine-tuning may not have been the right tool for this problem. Revisit article 1’s decision framework.
None of these are fatal on their own. All of them are common. And all of them are findable only if you actually evaluate. Skipping evaluation is skipping the ability to catch any of these problems.
The mindset that makes fine-tunes reliable
The teams whose fine-tunes work in production aren’t the ones with the most exotic training setups. They’re the ones with the tightest evaluation loop. They know, at any moment, how their current fine-tune compares to the last one on the same test set, and to the base model. When something regresses, they see it immediately. When something improves, they can prove it. That’s what separates a project that ships confidently from one that ships nervously.
Closing the fine-tuning half
Look back at where we’ve come in this track. Seven articles, and you now have an end-to-end understanding of fine-tuning: when to use it, what it is, how to prepare its data, the techniques that make it practical, how to actually run it, the alignment layers underneath the models you build on, and now, how to prove that what you built is real. That’s the full fine-tuning story, and if you’ve followed along, you’re ready to do this work.
But there’s a second half of this track we haven’t touched yet. Fine-tuning is one way to produce a good language model. Once you have one (fine-tuned or not), you have to run it in the real world. Deploy it. Monitor it. Handle costs. Handle regressions. Handle the operations of these unusual, probabilistic, sometimes-expensive systems. That world has a name of its own, LLMOps, and it’s what the second half of this track is entirely about, starting next.
Next in the series: LLMOps vs MLOps, what changes when the model is a language model, and why it needs its own operational discipline.