Training loss proves almost nothing
Training loss falling means the model has fitted the examples in front of it. A sufficiently large adapter on a few hundred examples can drive it near zero by memorising them, and that model will be worse than the base on anything it has not seen.
The only curve that carries information is evaluation loss on data the model has not trained on. Watch the two together, because the relationship between them is what tells you what happened.
The four shapes
Both falling. The run is working. Continue until evaluation loss stops improving.
Training falling, evaluation rising. Overfitting, and the point where evaluation turned is where the useful learning stopped. Take the checkpoint from that step rather than the final one. Then fix the cause: fewer epochs, more data, a lower rank, or more dropout, in that order of effectiveness.
Both flat. Either the learning rate is too low, the adapter is not actually attached, or the model already does this task and there is nothing to learn. All three are common, and the third is worth taking seriously before spending another week.
Spikes. A learning rate that is too high, or a small number of pathological examples: a single enormous document, a corrupted record. Find them by logging per-example loss and looking at the worst ten. It is usually the data.
One caution about the numbers themselves: loss values are not comparable across runs that differ in masking, sequence packing or tokenisation. A run with prompt masking has a higher loss than one without, and neither is better. Compare a run to itself over time, and compare models to each other on a task evaluation.
The check that everyone skips
A model can get better at your task and worse at everything else. This is catastrophic forgetting, and with LoRA it is milder than with full fine-tuning (the base is frozen), but it is entirely real, particularly at high rank, over many epochs, or on a narrow dataset.
It does not appear in your evaluation loss, because your evaluation set is drawn from the same narrow distribution as your training set. Both numbers improve while the model loses the ability to answer a general question, follow an unrelated instruction, or respond in another language.
Build a general-capability set of perhaps twenty items before you train, and run it before and after:
- Three general knowledge questions the base answers correctly.
- Three instruction-following items unrelated to your task, such as “reply in exactly two sentences”.
- Two items in each other language your users actually use.
- Two items that should be refused.
- Two short reasoning or arithmetic items.
- A handful of your own task’s items, for contrast.
Run them at temperature 0 against the base and against the adapter, and read the outputs side by side. It takes twenty minutes and it is the only thing standing between you and shipping a model that is excellent at one job and broken at the rest.
Evaluation loss is still a proxy
Lower evaluation loss means the model assigns higher probability to the reference answers. It does not mean the outputs are better for your purpose, and the two can diverge: most visibly when the reference answers have a stylistic quirk the model is learning to reproduce.
So finish with the task evaluation from the previous module: the actual inputs, the actual scoring, the actual pass criterion. Run it on the base, on each checkpoint, and on the final adapter. A checkpoint from the middle of the run is often the best model, and you would never know from the final numbers alone.
The failure that fluency hides
Here is what makes a tuned model dangerous in a way a base model is not. Tuning makes the output look like your house style: your formatting, your vocabulary, your level of confidence. Errors arrive in exactly the register your reviewers have learned to trust, and the surface cues they were unconsciously using to catch mistakes are gone.
The correct response is counter-intuitive: increase human review immediately after a fine-tune rather than reducing it. Sample fifty real outputs and read them properly in the first week. What you are checking for is not fluency, which is guaranteed, but whether the content is right.
A tuned model does not sound less sure when it is wrong. That is what you trained out of it.
Every lesson here is open. Your progress is recorded once you pass the Open Model Ecosystem exam.
Check your understanding
After fine-tuning, both training and evaluation loss fall steadily and the task evaluation improves. A week later, users report the model has stopped handling unrelated requests it used to manage. Why did the curves not show this?
Pick the one you would defend. Your answer stays private.
Stuck on something?Ask Tri, your AI tutor