Diagnosing a regression
Why did my model forget things after fine-tuning?
Short answer
Losing a capability the base model had is most often overtraining rather than bad data. Training too long on a narrow dataset overwrites behaviour that was already there, and the influence signature shows it, because the harm is spread evenly across every example instead of concentrating in a subset. Check the epoch count against the dataset size before you go looking for bad examples.
Forgetting and poisoning look different#
Both end with a model that is worse than the one you started with, but they come from opposite places, and the influence distribution tells them apart.
Poisoning is additive. Something in the data taught a wrong answer, and that something is a minority of your examples. Forgetting is erosive. Nothing in the data is wrong, but the model spent so many gradient steps on a narrow distribution that behaviour outside it decayed.
What overtraining looks like in a report#
In the twelve-epoch run, 800 clean Alpaca examples were trained for 12 epochs where 3 would do. Nothing was planted. The capability fell 6.08 nats with a 95% confidence interval of [-7.08, -5.11], and all 16 of 16 eval items flipped from right to wrong. It is the largest regression in the suite.
The attribution result is the instructive part. One cluster carried 100% of the negative influence, which at first reads like a damning data verdict. It is the opposite. That cluster contained all 800 examples at a near-uniform -20.88 each. There was no subset that stood out, because no subset was responsible, and a tool that handed back a short list to delete anyway would have been worse than useless.
Compare that against the poisoned-facts run, where 51 examples out of 851 carried 75% of the harm at 195 times the per-example rate. A real data problem is lumpy. Forgetting is flat.
The check that catches it#
config.overtraining compares the epoch count against the dataset size and fired at high severity
on that run, reporting that 12 epochs over 800 examples risks memorization. It reads the trainer
config out of the run directory, so it needs no GPU and no adapter:
gradian diagnose --dataset train.jsonl --run runs/my-finetuneThe check is a ratio, not a fixed limit. Three epochs over 800 examples still raised a medium finding on other runs in the same suite, so treat it as a prompt to look rather than a verdict. Diagnostics lists the full set of 41.
Check the base model actually had the capability#
There is a failure mode that looks like forgetting and is not. If the base model never held the capability well, there was nothing to forget, and any explanation built on top of that is explaining noise.
Gradian reports this directly and treats it as high severity. Several runs in the suite carried the warning that the base model scored only -5.05 before training, which is why those reports rest on their config findings rather than their influence scores. Before concluding that your model forgot something, measure the base model on the same eval set.
What to do about it#
Reduce epochs before you touch the data. If the capability you lost is general behaviour rather than something your dataset covers, mixing in a small amount of general instruction data is the usual remedy, but the epoch count is the cheaper thing to test first, and it is the one this run actually measured.