What is catastrophic forgetting and how does parameter-efficient fine-tuning help avoid it?

How to think about it

Catastrophic forgetting is the loss of previously learned capabilities when fine-tuning, meaning continuing to train a model on a new dataset, changes shared weights, the learned numerical parameters inside the model. Parameter-efficient fine-tuning, or PEFT, reduces this risk by freezing most of the original model and training a small adapter, but it does not guarantee that old behavior stays unchanged.

Why catastrophic forgetting happens

A neural network does not keep each skill in a separate compartment. Language, arithmetic, formatting, domain knowledge, and instruction-following behavior are distributed across many shared parameters. The same weights that help a model explain photosynthesis may also help it interpret a support ticket.

During ordinary fine-tuning, the training algorithm updates all or nearly all of those weights. A gradient is the direction that says how each parameter should change to reduce the training error. For a model with parameters θ, a typical update looks like this:

θ_new = θ_old - η ∇θ L_new

Here, L_new is the loss, a numerical measure of error on the new task, and η is the learning rate, the size of each update.

The problem is that L_new only measures the new data. If the new dataset contains 20,000 examples of telecom billing tickets, the gradient is rewarded for becoming excellent at telecom billing tickets. It is not rewarded for preserving poetry, general question answering, or a previously learned safety behavior unless those examples also appear in training.

A narrow dataset creates a narrow pressure on shared weights. Many updates in the same direction can move the model away from regions of parameter space that supported its earlier capabilities. A high learning rate, many epochs, or a small and repetitive dataset makes the pressure stronger.

With language models, “forgotten” usually means “no longer reliably expressed,” not necessarily that every old fact has been physically erased. A model may still contain useful representations but fail to retrieve them because the fine-tuning changed its preferred behavior, wording, or decision boundary. That is why old-task regression tests matter more than inspecting a few weights.

A concrete example

Imagine a general-purpose language model used by a customer-support company. Before customization, the team records two fixed evaluations:

• An old regression suite of 1,000 prompts covering general questions, refund explanations, arithmetic, and concise email writing.
• A new support suite of 500 telecom billing tickets.

Suppose the base model scores 92 percent on the old suite. It is not yet good at the company’s ticket format, scoring 71 percent on the new suite.

The team performs ordinary full fine-tuning on 20,000 billing tickets. In an illustrative run, the new score rises to 95 percent, but the old score falls to 64 percent. When an engineer asks a general question about cooking, the model starts answering in the company’s ticket template. It has not become useless. It has become too specialized, and the specialization has displaced behavior the team cared about.

PEFT changes which parameters can move. LoRA, or Low-Rank Adaptation, adds two small trainable matrices around selected model layers while keeping the original matrix frozen. The effective weight matrix is:

W_used = W_base + (α / r) B A

W_base is the original frozen matrix. r is the adapter rank, usually much smaller than the matrix dimensions, and α is a scaling value. The matrices A and B are the trainable adapter parameters.

For a 4096-by-4096 layer, the original matrix contains 16,777,216 parameters. A rank-8 LoRA update contains:

A: 8 x 4096       = 32,768 parameters
B: 4096 x 8       = 32,768 parameters
total trainable   = 65,536 parameters

That adapter is about 0.39 percent of the original matrix. If the company trains only A and B, the original matrix cannot be directly overwritten. Disable the adapter and the exact base matrix is still available.

This is the central protection: the new task has a smaller and more constrained place to make its changes. It cannot freely rewrite every feature in the base model.

Why PEFT helps, and what it does not promise

PEFT is a family of techniques, not one algorithm.

• LoRA learns low-rank weight updates.
• Bottleneck adapters add small trainable modules inside the network.
• Prefix tuning and prompt tuning learn virtual input representations rather than changing most model weights.

They all reduce the number of trainable parameters, but they do so in different locations and with different capacity. The common idea is to restrict how much the new task can alter the base model.

That restriction helps in three ways.

First, it protects the original checkpoint. With full fine-tuning, the new model itself contains the changed weights. With PEFT, the original model and the task-specific change can be stored separately.

Second, it reduces the number of degrees of freedom available for destructive updates. A rank-8 adapter cannot express every possible change to a 4096-by-4096 matrix.

Third, it enables isolation. The billing adapter can be used for billing requests, while the unmodified base model handles unrelated requests. A second adapter can be trained for technical documentation without forcing both tasks into one set of weights.

Warning — common misconception: frozen base weights do not mean frozen outputs. When the adapter is active, it changes the computation. A general question sent through the billing adapter can still receive a billing-shaped answer. PEFT protects the base parameters; it does not automatically protect every behavior produced by the combined model.

The senior-level nuance

PEFT reduces catastrophic forgetting. It does not eliminate it.

An adapter can itself forget earlier examples if it is trained sequentially. Suppose the team first trains one adapter for billing and later continues training that same adapter on handset troubleshooting. The base remains frozen, but the adapter’s parameters are now being optimized for the second task. Earlier billing behavior can degrade inside the adapter.

The safer production pattern is to keep the base checkpoint immutable, train separate adapters where possible, and route requests to the appropriate adapter. If one adapter must serve several tasks, mix representative old-task examples into training. This is replay data: a sample of earlier examples included to remind optimization what must not regress. Another option is distillation, where the tuned model is trained to remain close to the original model’s outputs on selected old-task inputs.

The trade-off is capacity. A very small adapter may preserve the base well but underfit the new domain. Increasing its rank gives it more expressive power, which may improve the billing score but also gives it more opportunity to interfere with old behavior. There is no universally correct rank. It depends on the size of the behavior change, the amount and diversity of new data, and the regression tolerance.

PEFT is also not always the right choice. If the base model is fundamentally poor at the new domain, or the task requires a broad change across many capabilities, a small adapter may impose an artificial ceiling. Full fine-tuning can be appropriate when there is substantial high-quality data and a carefully designed replay or regularization strategy. The important point is to compare approaches on both new-task quality and old-task retention, not to treat trainable-parameter count as the objective.

Finally, merging a LoRA adapter into the base model adds its update into the base weights. That can simplify serving, but it removes the convenient separation between base and adapter. Keep the original checkpoint if reversibility matters.

A failure mode to recognize

The first symptom is often a great new-task metric paired with a quiet regression elsewhere. The billing benchmark climbs from 71 percent to 95 percent, while general prompts begin receiving ticket templates, old formatting deteriorates, or refusals change unexpectedly.

Test the model three ways:

1. Base model without the adapter.
2. Base model with the new adapter.
3. The merged model, if merging is part of deployment.

If only the second case fails, the adapter is causing behavioral interference or is being routed too broadly. If the base model itself has changed, the training process was not actually freezing the base, or the deployed artifact is not the checkpoint the team thought it was.

What they’ll ask next

Does PEFT completely prevent catastrophic forgetting?
No. It prevents direct updates to the frozen base when configured that way, but the active adapter can still change old-task outputs. Replay data, separate adapters, routing, and old-task regression tests are still necessary.

Why not solve the problem with a lower learning rate?
A lower learning rate reduces the size of each destructive update, but full fine-tuning still updates shared parameters. Thousands of small updates can still accumulate in the wrong direction, and the model may underfit the new task. Lower learning rates are useful, but they are not a substitute for preserving old-task signal.

When would you choose full fine-tuning instead of PEFT?
I would consider full fine-tuning when the required change is broad, the base model lacks needed capacity, or the new behavior must be deeply integrated throughout the model. I would make that choice only with a held-out old-task evaluation, replay or other retention method, and a deployment plan that can roll back the changed checkpoint.

Say this in the interview: PEFT reduces catastrophic forgetting by freezing the base model and isolating a small task-specific update, but it only reduces the risk; old-task evaluation, replay, and adapter isolation are still needed because the active adapter can change behavior.