Fine-Tuning Fixed One Thing and Broke Three: Catching the Regression

Fine-tuning is a trade, and you only see one side of it

The mental model most teams carry is that fine-tuning is pure addition: you teach the model your domain, and it keeps everything it already knew plus the new skill. That model is wrong. Fine-tuning moves the weights, and moving them toward your task moves them away from something else. The improvement on your target task is the side of the trade you measure. The degradation on everything else is the side you do not, unless you build the eval to see it.

The research is settled. An empirical study of catastrophic forgetting during LLM fine-tuning found that forgetting is generally observed during continual fine-tuning, and in some settings the severity grows with model scale. You are not unlucky if your fine-tune regressed unrelated capabilities, that is the expected behavior. The only question is whether you noticed.

LoRA forgets less, but does not forget nothing

The most useful practical finding for picking a method comes from “LoRA Learns Less and Forgets Less”: low-rank adaptation is a weaker learner than full fine-tuning but a better regularizer, it acquires less of the target task and, in exchange, preserves more of the base model’s original capabilities. That is a genuine, exploitable trade-off. If preserving general ability matters more than squeezing out the last points on your task, LoRA is often the safer default.

But “forgets less” is not “forgets nothing.” Continual-learning research has shown standard LoRA still suffers meaningful drops on earlier tasks when applied sequentially, because it provides no mechanism to protect pre-trained knowledge from interference. LoRA reduces the blast radius; it does not remove the need to measure it. Whichever method you choose, the obligation is the same: prove what the fine-tune cost you, do not assume.

The scariest finding: benign data can break safety

The result every team shipping a fine-tuned model needs to internalize: fine-tuning can compromise safety alignment even when the fine-tuning data is entirely benign. You do not need adversarial or toxic training data to weaken the model’s guardrails. Fine-tuning on innocuous, on-task examples, your support transcripts, your product docs, can erode the carefully-built refusal behavior the base model came with, making it more willing to comply with harmful requests.

This flips the usual assumption on its head. Teams treat safety as a property of the base model they inherited and forget about it. But the moment you fine-tune, you may have silently lowered the safety floor, and if your eval suite does not include adversarial and harmful-request probes, you will ship that regression straight to production with no signal at all.

Why teams ship the regression anyway

If catastrophic forgetting is so well documented, why does it keep reaching production? Because the incentive structure of a fine-tuning project points away from finding it. The team set out to improve one task; their attention, their metrics, and their definition of success all orbit that task. When the fine-tune lifts the target number, the project is declared a win and shipped, the question “what did this cost everywhere else?” is never asked, because nobody was assigned to ask it. The regression is not hidden by malice or incompetence; it is hidden by focus.

The second reason is that the evaluation is usually built from the fine-tuning data. Teams hold out a slice of the same distribution they trained on and measure against it, which by construction only tests the target task and tells you nothing about the capabilities the fine-tune may have eroded. An eval drawn from the training distribution is structurally incapable of detecting catastrophic forgetting, because forgetting happens precisely on the distributions the training data did not cover. Catching the regression requires eval data that deliberately lives outside the fine-tuning domain.

The fix: a before/after regression suite on untrained capabilities

The discipline is simple and non-negotiable: snapshot a broad capability baseline before fine-tuning, re-run the identical suite after, and gate on regressions in capabilities you did not train. The suite must deliberately reach beyond your task.

# Fine-tune regression gate: measure what you did NOT train for
SUITES = {
    'target_task':     load_golden('support_resolution'),   # should IMPROVE
    'instruction':     load_golden('general_instruction'),  # must not regress
    'reasoning':       load_golden('multi_step_reasoning'),
    'format':          load_golden('json_schema_adherence'),
    'multilingual':    load_golden('non_english'),
    'safety':          load_golden('harmful_request_refusal'),  # the silent one
}

def fine_tune_gate(base_model, tuned_model, tolerance=0.02):
    report = {}
    for name, suite in SUITES.items():
        before = mean(grade(base_model(c.input),  c.gold) for c in suite)
        after  = mean(grade(tuned_model(c.input), c.gold) for c in suite)
        report[name] = {'before': round(before, 4), 'after': round(after, 4),
                        'delta': round(after - before, 4)}

    # Target task must improve; everything else must not meaningfully regress
    assert report['target_task']['delta'] > 0, "Fine-tune did not improve the target task"
    for name, r in report.items():
        if name == 'target_task':
            continue
        assert r['delta'] >= -tolerance, (
            f"REGRESSION on untrained capability '{name}': "
            f"{r['before']:.1%} -> {r['after']:.1%} ({r['delta']:+.1%})")
    return report

The safety suite is the one teams omit and the one that matters most given the benign-data finding. It should include direct harmful requests, jailbreak attempts, and edge cases the base model was trained to refuse. If refusal rate drops after fine-tuning, that is a blocking regression no matter how good the target-task numbers look.

Mitigations when the regression is real

When the gate catches a regression, you have levers before you abandon the fine-tune:

• Switch to LoRA or lower the rank. Per the research, this trades some target-task gain for materially less forgetting, often the right call.
• Mix in replay data. Blend general-capability and safety examples into your fine-tuning set so the model rehearses what it must not forget while learning the new task.
• Reduce learning rate or epochs. Over-training is a primary driver of forgetting; a lighter touch often keeps the gains while shrinking the damage.
• Re-run alignment. If safety regressed, a safety-tuning pass after task fine-tuning can restore the refusal behavior, but only your eval can confirm it worked.

Every one of these is an empirical choice, which is exactly why the before/after suite is the foundation. Without it you are guessing; with it you can see precisely what each mitigation buys back.

Scale changes the calculus, and so does data size

Two findings refine when forgetting bites hardest. First, work on scaling laws for forgetting shows that the amount forgotten grows with the number of parameters updated and the fine-tuning duration, forgetting is not a fixed tax but a function of how aggressively you train. That is actionable: it means lighter-touch fine-tuning (fewer steps, smaller learning rate, fewer trainable parameters) is a direct lever on how much you lose, and your before/after suite is what tells you where the sweet spot sits between target-task gain and general-capability loss.

Second, low-data regimes are deceptively risky. When you have only a few hundred examples for your target task, full fine-tuning can overfit them and forget aggressively, while the model’s general abilities, the very thing that made it useful, degrade fastest. Counterintuitively, the smaller your fine-tuning set, the more important the broad regression suite becomes, because the gap between “looks great on my 200 examples” and “still works on everything else” is widest exactly there.

The bottom line

Fine-tuning is a trade-off, not pure addition: catastrophic forgetting is the expected, documented outcome, full fine-tuning forgets more than LoRA, and even benign training data can erode the base model’s safety alignment. An eval that only measures the task you trained for is structurally blind to the regression. Snapshot a broad capability and safety baseline before fine-tuning, re-run it after, and gate on any meaningful regression in capabilities you did not train, including refusal behavior. A fine-tune that helped your task while quietly breaking three others is a regression you shipped because you only looked where you expected to win.