Evaluating a fine-tuned LLM: did the training actually help?
Fine-tuning is easy to run and hard to judge. Here's how to evaluate a fine-tuned model against its base — catching the regressions fine-tuning quietly introduces and proving the gain is real, not vibes.
TL;DR: Fine-tuning a model is a few hours of compute; knowing whether it helped is the hard part. Evaluate the fine-tune the same way you'd evaluate any change — against the base model, on your own data, with metrics mapped to your task — and specifically watch for the regressions fine-tuning loves to introduce: catastrophic forgetting, overfitting to the training set, and safety drift.
Teams fine-tune a model, see a few good outputs, and ship it. Then general quality quietly drops, or it aces the cases it was trained on and fails everything else. Fine-tuning changes the whole model, so it has to be evaluated like the significant change it is. This tutorial is how.
Always evaluate against the base
The only meaningful question is fine-tuned vs. base model, on the same test set. An absolute score on the fine-tune alone tells you nothing — you need the delta. Run both through the identical dataset and compare per metric. If the fine-tune doesn't beat the base on your task metrics, the training didn't help, however good individual samples looked.
The regressions to watch for
Fine-tuning improves the target task by moving the whole model, which is exactly why it breaks things elsewhere:
- Catastrophic forgetting — the model gets better at the fine-tuned task and worse at capabilities it used to have. Test general ability, not just the target task.
- Overfitting — great scores on data resembling the training set, poor generalization to real inputs. This is why your eval set must be held out, never overlapping training data.
- Safety drift — fine-tuning on task data can erode safety alignment. Re-run your safety and jailbreak suite after every fine-tune. (See the LLM safety guide and LLM red teaming.)
The evaluation set
Build it before you fine-tune, and keep it strictly separate from training data:
- Target-task cases — where the fine-tune should improve.
- General-capability cases — to catch forgetting.
- Safety / adversarial cases — to catch alignment drift.
- Real production cases where available — the truest signal. (See synthetic data generation to seed it before you have traffic.)
The comparison
| Dimension | Base | Fine-tuned | Verdict |
|---|---|---|---|
| Target-task accuracy | baseline | should ↑ | the point of fine-tuning |
| General capability | baseline | should hold | ↓ = catastrophic forgetting |
| Safety / guardrails | baseline | should hold | ↓ = alignment drift |
| Cost / latency | baseline | varies | factor into the decision |
Ship the fine-tune only if it wins on the target task without losing general capability or safety. A gain on one metric bought with a loss on another is often a bad trade.
Keep evaluating after you ship
Offline comparison gets you to the ship decision; it doesn't end there. Score the fine-tuned model on production traffic the same way, because held-out test sets still miss what real users do. (See run LLM evals on production traces and why A/B test LLM prompts — the same version-comparison discipline applies to models.)
How Currai fits
Currai scores the base and the fine-tuned model on the same traces and the same metrics — target task, general capability, and safety — so the ship decision is a measured delta, not a hunch. Every score ties to the model version that produced it, and once shipped, the fine-tune keeps getting scored on production traffic so forgetting or drift shows up as a caught regression. See evaluating LLM systems and traces and evals in one place, or start with Currai free.
Frequently asked questions
How do I know if fine-tuning helped?
Compare the fine-tuned model against the base model on the same held-out test set, per metric. Only the delta is meaningful — an absolute score on the fine-tune alone tells you nothing about whether the training added value.
What is catastrophic forgetting?
When fine-tuning improves the target task but degrades capabilities the model used to have. You catch it by testing general ability, not just the task you trained for.
Why must the eval set be held out from training data?
Because a model scores high on data resembling what it was trained on regardless of real generalization. Overlap between training and evaluation data produces inflated scores that collapse on real inputs.
Does fine-tuning affect safety?
It can. Fine-tuning on task data can erode safety alignment, so re-run your safety and jailbreak suite after every fine-tune and refuse to ship if guardrails regressed.