How do you test for catastrophic forgetting after fine-tuning?

Oct 21, 2026 - 7 min read

Short answer: evaluate the starting model and the fine-tuned model on the same tasks under the same conditions. Separate the new capability you want from the existing capabilities you need to preserve. Then inspect which previously successful tasks now fail, not just whether the overall score rose. A regression is evidence to investigate, not proof by itself that training caused catastrophic forgetting.

Nodus supports fine-tuning and collects trained weights as outputs. Training is Beta. Those outputs still need an acceptance test: a completed run does not establish that the model retained the behavior your application depends on. This article describes that customer-side decision, not an automatic forgetting detector or a claim that Nodus prevents forgetting.

What counts as forgetting after fine-tuning?

Catastrophic forgetting describes a loss of previously learned capabilities as a model learns something new. It has been studied in language models during continual fine-tuning. But an unexpected answer after a training run does not identify its cause.

The observed failure might instead come from a different prompt, a changed output limit, a scoring error, or ordinary variation between generations. The practical first question is narrower: did the candidate lose behavior that the starting model demonstrated on tasks we still care about?

You can answer that question without claiming to know the mechanism. Keep the diagnosis separate from the release decision. An unexplained regression may be enough to hold a candidate even when you cannot yet attribute it to forgetting.

Build a retention test around the application, not a broad benchmark alone

Use two distinct groups of tasks:

Acquisition tasks: the new behavior the fine-tuning run is meant to improve.
Retention tasks: existing behavior that must remain useful after training.

For a document assistant, acquisition might mean applying a new domain classification. Retention might mean extracting dates correctly, respecting an output format, and declining to invent a field absent from the document. These are hypothetical task examples, not Nodus customer results.

Choose retention cases from the actual intended workload, with permission to use the data. Include ordinary cases and consequential edge cases. A broad public benchmark can add context, but it cannot substitute for the behaviors your application promises.

Record the acceptance conditions before inspecting candidate answers. For each capability, say what failure means and whether a regression is tolerable. A required format might be nonnegotiable; a small change in stylistic preference might not be. There is no universal acceptable forgetting percentage.

Do not count only tasks that the starting model passed. Keep the complete retention set so you can see both lost and newly acquired successes. The previously passed subset is a useful additional view, not a replacement denominator.

Hold the comparison conditions still

Evaluate the starting model and candidate with the same task inputs, instructions, available context, output limits, generation settings, and scoring rule. Preserve the exact model versions and evaluation record so the comparison can be checked later.

If your application uses sampled generation, allow for output variation. Repeat the matched evaluation enough to distinguish a recurring failure pattern from an isolated unlucky answer. The amount of repetition depends on the variability and stakes; a single fixed number is not appropriate for every workload.

For human-rated tasks, apply the same rubric to both models and hide model identity when practical. If the scoring process changes, rescore both sides. Comparing a candidate judged under a stricter rubric with an earlier baseline score is not a controlled retention test.

Failed evaluation attempts also need a visible record. A missing answer caused by a broken evaluation service is not evidence about the model’s knowledge. Resolve or separately report that failure before making the comparison.

Worked example: almost unchanged accuracy can hide substantial churn

The following numbers are illustrative, not a measured experiment, a Nodus benchmark, or a customer result. Assume every task is scored under matched conditions.

Task group	Starting model successes	Candidate successes
New target capability	180 of 300	240 of 300
Existing application tasks	90 of 100	89 of 100
Required output-format cases	40 of 40	39 of 40
Total	310 of 440	368 of 440

The combined score rises from about 70.5% to 83.6%. That is a useful acquisition result, but not a release decision. The existing-task score falls by only one percentage point, which also conceals something important.

Inspect the paired outcomes for those same 100 existing tasks:

Outcome on the same task	Illustrative task count
Both models pass	78
Starting model passes; candidate fails	12
Starting model fails; candidate passes	11
Both models fail	9

The baseline passes 78 + 12 = 90 tasks. The candidate passes 78 + 11 = 89. The net decline is one task, but 12 previously successful cases were lost and 11 different cases improved. Among the 90 baseline successes, the candidate retains 78, or about 86.7%.

Those lost cases might be low-impact variations or concentrated in a critical workflow. The counts alone cannot tell you. Review the changed answers and assign each meaningful regression to a capability and severity. The format failure also requires inspection; a strong improvement on new tasks does not automatically compensate for an unusable output.

Use the failure pattern to choose the next experiment

If losses cluster in one capability, investigate that capability before changing the entire training plan. Check the evaluation first: were the instructions and scoring really matched, and do repeated evaluations reproduce the loss?

Once the regression is credible, make the next experiment answer a specific question. For example, does a candidate from an earlier stage preserve the required behavior, or does a revised training-data mix improve retention? Treat each as a hypothesis, not a guaranteed cure. Recheck acquisition as well as retention so preserving old behavior does not erase the intended gain.

When you use the same retention cases repeatedly to choose among candidates, they become development evidence. Confirm the final choice on untouched cases representing the same capabilities before making a general claim about retained performance. Do not quietly change the acceptance rule because a preferred candidate missed it.

A useful decision record contains the acquisition result, per-capability retention results, paired losses and gains, unresolved failures, and the reason for accepting or holding the candidate. It should be possible to understand the tradeoff without looking at a training curve.

Where does Nodus fit in this workflow?

Nodus’s Training (Beta) guide describes fine-tuning and reviewing run stages, curves, results, cost, and outputs in the console. Use those records to identify the candidate and retrieve its trained weights. They are evidence about the run, not a certificate that every existing capability survived.

Keep the retention evaluation as an explicit acceptance step. Nodus’s documented validation-loss selection is not a substitute for testing application behavior, and this article does not claim a built-in retention dashboard or automatic approval gate.

If you are planning fine-tuning and want to discuss the training workload and the evidence you need from a run, book a conversation with Nodus.

FAQ

Does lower validation loss rule out catastrophic forgetting?

No. Lower loss on the selected validation distribution does not establish retention on other capabilities. Measure the behaviors you need to preserve directly.

Does one failed answer prove the model forgot a skill?

No. Check matched conditions, scoring, and generation variability first. One consequential failure can still justify holding a release while you investigate, without claiming a general loss of skill.

Can LoRA guarantee that existing behavior stays unchanged?

No. A fine-tuning method is not an acceptance test. Evaluate the actual candidate on acquisition and retention tasks rather than treating the method’s name as a retention guarantee.

Should new successes cancel out lost old successes?

Only if that tradeoff matches the application’s predeclared requirements. Report both. An improved total does not make a newly broken required workflow acceptable.