Cheatsheet

Continual / Lifelong Post-training (production-validated methods only)

Models are iteratively updated (new data / new capabilities / new alignment rounds) → catastrophic forgetting and capability regression are real problems at scale. ⚠️ This page only covers methods validated in large-scale production; classical academic CL algorithms are listed separately and explicitly marked "not production-validated" — do not cite them as industry-standard answers in interviews.

1. What "Continual" Looks Like in Production

Not the textbook online-streaming continual learning setup, but: periodic retraining from a base / checkpoint with adjusted data mixing ratios. Goal = add new capabilities / new alignment while not degrading existing capabilities (avoid alignment tax / regression).

1.1 Mechanism & Measurement of Forgetting

Mechanism: gradient descent on new data often produces an update direction θLnew-\nabla_\theta \mathcal{L}_{\text{new}} that conflicts with the old task's descent direction (gradient interference: Lold,Lnew<0\langle \nabla\mathcal{L}_{\text{old}},\, \nabla\mathcal{L}_{\text{new}}\rangle < 0), so weights drift toward "good-for-new, bad-for-old" (weight drift) and old capabilities are lost. Larger drift, higher LR, and longer training all worsen forgetting — which is exactly why "low LR + few epochs + PEFT" works (it limits drift).

Measurement: use BWT (backward transfer). Let Ri,jR_{i,j} be the metric on task jj after learning task ii; after the final task TT:

BWT=1T1j=1T1(RT,jRj,j)\mathrm{BWT} = \frac{1}{T-1}\sum_{j=1}^{T-1}\big(R_{T,j} - R_{j,j}\big)

BWT<0\mathrm{BWT}<0 means forgetting (more negative = worse). In production it is monitored alongside retention and regression probes on old benchmarks.

2. ✅ Production-Validated Toolbox

2.1 Data Replay / Rehearsal — the workhorse

Mix a certain proportion of old / general data (instruction data mixing ratio) during continual fine-tuning. The simplest and most effective anti-forgetting measure; the engineering focus is on ratio, deduplication, and quality filtering.

2.2 Low Learning Rate + Few Epochs + PEFT

Small-step fine-tuning limits weight drift; LoRA / adapters enable cheap incremental adaptation + change isolation (a bad adapter can simply be discarded).

2.3 KL Regularization Against the Base

The RLHF term βKL(πθπref)\beta\,\mathrm{KL}(\pi_\theta\,\|\,\pi_{\mathrm{ref}}) is fundamentally about anchoring the policy near the base to prevent drift and forgetting.

2.4 Model Merging / Weight Averaging

2.5 Distillation Consolidation

Distill multiple experts / updated teachers into a single model to consolidate capabilities and compress multiple iterative rounds.

2.6 Sequential Forgetting Across Stages (SFT → DPO → RL)

Later stages erode earlier ones: the policy drift in the DPO / RL stage wipes out part of the capabilities and formatting learned in SFT, usually worst at the final RL step (no labeled constraint, chasing reward, prone to over-optimization). Mitigations: keep a KL to the SFT reference during RL, mix in SFT replay, add verifier constraints on key capabilities, and run regression probes after each stage.

提示 / Note

XRIGHT (Fernando et al., arXiv:2410.15483) gave the first theoretical proof that sequential SFT to DPO/RLHF forgetting exhibits a non-diminishing optimality gap -- more training rounds cannot automatically eliminate forgetting. It proposed the ALRIGHT / MAXRIGHT joint optimization frameworks, achieving up to ~23% improvement on MMLU/HellaSwag/SORRYBench/XSTest.

2.7 Retraining vs incremental -- when not to cut corners

Condition Favor retraining Favor incremental
New data volume Large (>30% of original) Small (<10%)
Old/new task overlap Low (entirely new domain) High (same-domain fine-tuning)
Forgetting tolerance Zero tolerance (safety/compliance) Small degradation acceptable
Compute budget Abundant Constrained
Model scale Large (merging/caching amortizes cost) Small (retraining is cheap)

Cost model (rough): C_retrain proportional to D_total times T; C_incre proportional to D_new times T_incre (typically T_incre much smaller than T, but add replay cost alpha times D_old).

Heuristic: if D_new / D_total < 0.1 and tasks are similar, use incremental + replay; if cumulative degradation appears after multiple rounds, retrain. The Google PaLM-2 merging study shows larger models are more robust to simple averaging -- so "increment, then periodically retrain + merge checkpoints" is the current mainstream pattern.

3. ❌ Not Production-Validated (Academic — Not Industry Standard)

4. Honestly Leveraging Your CL Background

Fed-TaLoRA (federated continual fine-tuning), Continual Agent → transferable insights (forgetting metrics, retention perspective, aggregation consistency).

5. Code: replay mixing + weight merging

39 行 / lines
import torch, itertools

# (1) replay mixing: interleave old/general data into new data by ratio, to fight forgetting
def make_replay_stream(new_data, old_data, replay_ratio=0.3, seed=0):
    """After each new sample, insert one cyclically-reused old sample with prob replay_ratio."""
    g = torch.Generator().manual_seed(seed)
    old_cycle = itertools.cycle(old_data)
    stream = []
    for x in new_data:
        stream.append(("new", x))
        if torch.rand(1, generator=g).item() < replay_ratio:
            stream.append(("old", next(old_cycle)))
    return stream

# (2) model soup: equal-weight average of homogeneous checkpoints (must share init)
def model_soup(state_dicts):
    avg = {k: torch.zeros_like(v) for k, v in state_dicts[0].items()}
    for sd in state_dicts:
        for k, v in sd.items():
            avg[k] += v / len(state_dicts)
    return avg

# (3) task arithmetic: theta0 + sum_i scale_i*(theta_ft_i - theta0); add to gain, subtract to forget
def task_arithmetic(theta0, finetuned, scales):
    merged = {k: v.clone() for k, v in theta0.items()}
    for sd, s in zip(finetuned, scales):
        for k in merged:
            merged[k] += s * (sd[k] - theta0[k])     # tau_i = theta_ft_i - theta0
    return merged

# --- Toy check ---
t0 = {"w": torch.zeros(3)}
a  = {"w": torch.tensor([1., 0., 0.])}
b  = {"w": torch.tensor([0., 2., 0.])}
print("soup:", model_soup([a, b])["w"])                                  # [0.5, 1.0, 0.0]
print("theta0+tau_a+tau_b:", task_arithmetic(t0, [a, b], [1.0, 1.0])["w"])   # [1., 2., 0.]
print("forget b (-tau_b):", task_arithmetic(t0, [a, b], [1.0, -1.0])["w"])   # [1., -2., 0.]
print("replay stream:", [tag for tag, _ in make_replay_stream(range(4), range(100, 103), 0.5)])

6. Interview Questions

L1 — Fundamentals


Q1: Why does continual fine-tuning cause forgetting? What is the simplest effective anti-forgetting method?

A: The root cause is gradient interference + weight drift: when doing gradient descent on new data, the update direction θLnew-\nabla_\theta \mathcal{L}_{\text{new}} often conflicts with old-task gradients (Lold,Lnew<0\langle\nabla\mathcal{L}_{\text{old}},\nabla\mathcal{L}_{\text{new}}\rangle < 0), and weights drift in a direction that is "good for new, bad for old," causing old capabilities to degrade. The larger the drift, the higher the LR, and the longer the training, the worse the forgetting. The simplest and most effective method is replay (data rehearsal/mixing): mix a proportion of old/general data into the new training stream, directly telling the model "don't forget this" from the data side. The engineering focus is on the mixing ratio, deduplication, and quality filtering.

Follow-up: Why does low LR + few epochs help reduce forgetting? Because it limits the magnitude of per-step weight drift—small-step fine-tuning = small perturbations to old knowledge. Similarly, LoRA limits the capacity of the change via a low-rank adapter, and the adapter can be discarded to roll back if things go wrong.


Q2: Why does LoRA / PEFT help mitigate forgetting?

A: Three reasons: ① Change isolation—full fine-tuning modifies all weights; a low-rank adapter only changes a small subset of parameters, causing less physical perturbation to old capabilities. ② Discardable—a broken adapter can be simply discarded to revert to the base model; full fine-tuning cannot be cleanly rolled back. ③ Cheap incremental adaptation—a separate adapter per new task/data, composed on demand at inference, avoiding the interference that comes from "one model simultaneously satisfying all tasks." The tradeoff: LoRA's expressivity is limited—complex new capabilities may require higher rank or full fine-tuning.

Follow-up: Can LoRA completely avoid forgetting? No. LoRA limits the "magnitude" of the change, not the "direction"—if new data strongly conflicts with old knowledge, LoRA still overwrites old capabilities, just with a smaller amplitude. Preventing forgetting still requires replay / KL regularization / merging alongside LoRA.


Q3: How does BWT (backward transfer) measure forgetting? BWT vs retention ratio?

A: BWT = 1T1j=1T1(RT,jRj,j)\frac{1}{T-1}\sum_{j=1}^{T-1}(R_{T,j} - R_{j,j}), where Ri,jR_{i,j} = the metric on task jj after learning task ii. BWT < 0 means forgetting (the more negative, the worse). vs retention ratio: BWT directly quantifies the absolute degradation (Δ\Delta); retention = RT,j/Rj,jR_{T,j} / R_{j,j} measures the relative fraction preserved—the two are complementary. In production, both are monitored alongside regression probes on old benchmarks, not just the aggregate BWT.

Follow-up: What are BWT's limitations? It only measures "how much was lost," not "how much was gained"—pair it with FWT (forward transfer, positive transfer of new knowledge) for a complete picture: BWT+FWTBWT+FWT is the "net gain" criterion for an incremental update. Additionally, BWT assumes tasks can be independently evaluated; for interleaved conversational/reasoning capabilities, proxy benchmarks must be chosen carefully.


L2 — Intermediate


Q4: How do you set the data mixing ratio for replay? When is replay not worth it?

A: There is no universal formula. Practical heuristics: ① Scale-based: old data volume \approx 10–50% of new data volume (depending on task similarity). ② Dynamic: monitor retention on old benchmarks—if it degrades beyond a threshold (e.g., 2%), increase the replay ratio. ③ Quality over quantity: a small amount of high-quality, representative old samples is more effective than a large volume of low-quality old data. When replay is not worth it: the new and old tasks are radically different (e.g., switching from code to medicine), the old data volume is too large to replay fully, or storage/bandwidth constraints make it impractical—in these cases, prefer LoRA isolation or model merging.

Follow-up: What's the relationship between replay and KL regularization? They are complementary, not substitutes. Replay reminds the model of the old distribution from the data side; KL regularization constrains the policy not to deviate from the reference from the optimization side. In RLHF settings, KL is an essential anti-drift mechanism (usually combined with replay). The combination of both typically outperforms either alone.


Q5: Why does model soup / weight averaging work? Prerequisites and failure conditions?

A: The theoretical foundation is Linear Mode Connectivity (LMC): multiple models fine-tuned from the same pretrained initialization tend to fall within the same basin of the loss landscape, with a low loss barrier under linear interpolation (they are linearly mode-connected), so the average point still has low loss. Prerequisite: shared initialization + limited drift (low-LR fine-tuning). Failure: different initializations / too-large task divergence → high barrier → averaging makes things worse. Task arithmetic (θ0+τi\theta_0 + \sum \tau_i) further assumes task vectors are approximately linearly additive (implicitly: they lie in different subspaces with little mutual interference); when this fails, use TIES (Trim small-magnitude params, Elect signs, Disjoint Merge) or DARE (Drop large fractions of delta + REscale) as pre-processing—these significantly outperform naive averaging.

Follow-up: What do the three TIES-Merging steps actually do? ① Trim: reset parameters that changed only slightly (sparsify the delta, reduce noise). ② Elect Signs: vote across models to determine the dominant sign direction for each parameter (resolve +/- conflicts). ③ Disjoint Merge: only merge parameters aligned with the agreed-upon sign. After these three steps, parameter conflicts are resolved and merge quality improves substantially.


Q6: Why are classical CL algorithms (EWC / GEM / SI) unpopular in LLM production?

A: Four core reasons: ① Cost: EWC requires computing and storing the Fisher Information Matrix (intractable at LLM parameter counts), and GEM requires solving a projection at every step (whose cost scales with episodic memory size). ② Complexity: many hyperparameters, hard to tune; for LLMs' "entangled capabilities," it's difficult to precisely define "which parameters are important to which tasks" for regularization objectives. ③ Effectiveness: simple replay + merging + PEFT + KL often matches or outperforms classical CL algorithms in practice, while being much simpler. ④ Scale mismatch: classical CL methods were designed for small models / small tasks; LLMs' 100B+ parameters and thousands of tasks make them computationally infeasible.

Follow-up: Do EWC and friends still have academic value? Yes—they provide the theoretical framework for forgetting (importance weighting, gradient projection, episodic memory compression) and inspired lighter-weight LLM-era variants. But in an interview: mention "academically there's EWC etc.," then honestly add "production mainstream is replay / merging / PEFT / KL."


L3 — Advanced


Q7: In a multi-round SFT → DPO → RL pipeline, where is forgetting most severe, and how do you mitigate it?

A: It is most severe at the final RL step—with no annotation constraints and only reward chasing, over-optimization is easy (policy drift erases capabilities and formatting learned during SFT). XRIGHT (Fernando et al., arXiv:2410.15483) gave the first theoretical proof that sequential training's forgetting has a non-diminishing optimality gap (more training cannot automatically eliminate it). Mitigations: ① keep KL to the SFT reference during the RL phase; ② mix in SFT replay (data rehearsal); ③ add verifier constraints on key capabilities (not just reward scoring); ④ run regression probes after each phase—monitor degradation on old benchmarks, roll back or adjust the mixing ratio if thresholds are exceeded; ⑤ model averaging: Wang (ACL 2024) found that per-layer interpolation between pre- and post-RLHF weights achieves the optimal point on the alignment-capability Pareto front.

Follow-up: Continual alignment vs retraining—how to choose? If the new alignment requirement is a small increment relative to the old one and in-distribution → incremental RL fine-tuning + KL anchoring to the ref. If cumulative degradation is evident after multiple rounds (regression probe alarms) → retrain from the base checkpoint and merge old adapters/checkpoints. Google PaLM-2 empirical evidence: larger models are more robust to simple averaging—"incrementally update → periodically retrain + merge checkpoints" is the current mainstream pattern.


Q8: What are the assumptions behind task arithmetic? When does it fail?

A: Task arithmetic assumes task vectors τi=θft,iθ0\tau_i = \theta_{\text{ft},i} - \theta_0 are approximately linearly additive—implicit premises: ① the τi\tau_i lie in different subspaces of the parameter space with little mutual interference; ② the change magnitudes are not so large as to cause nonlinear effects. Failure conditions: ① highly correlated/conflicting tasks → interference after addition (Ilharco et al. characterize failure with "interference"); ② excessive drift magnitude → the linear-superposition assumption breaks (the loss surface is no longer flat); ③ models fine-tuned from different inits do not share LMC → the linear interpolation barrier is high. Mitigations: TIES-Merging (Trim + Elect Sign + Merge) and DARE (Drop delta + REscale) as pre-processing significantly reduce parameter conflict during merging. Large-model empirical finding (Google, 64B PaLM-2): the larger the model, the closer the results of different merging methods (TIES/DARE-TIES/Averaging)—even simple averaging suffices.

Follow-up: Why is merging easier for larger models? Larger models have more parameter redundancy, so deltas from different fine-tuning runs are more likely to occupy sparse/orthogonal subspaces of the parameter space, with less mutual interference—hence simple averaging works. This is the "overparameterization dividend" manifesting in the continual learning setting.


Q9: Design a production-grade continual post-training monitoring scheme. What dimensions must it cover?

A:

Dimension Metric / Tool Threshold / Trigger
Forgetting monitoring BWT + retention ratio + regression probes (old benchmarks) Retention drop >2% → increase replay ratio or roll back
New capability validation New benchmark metrics vs retraining baseline Incremental result < 80% of retraining → consider full retrain
Alignment / safety Safety refusal rate / over-refusal / jailbreak ASR Any dimension degrades >1% → pause incremental, audit
Cost tracking Cumulative incremental cost vs retraining cost Cincre,cumulative>CretrainC_{\text{incre,cumulative}} > C_{\text{retrain}} → full retrain
Drift audit Weight L2 distance vs base / activation distribution KL Anomalous drift → inspect data mix, LR, epochs

Key principle: don't just look at aggregate metrics—monitor per-capability-dimension trends (reasoning / code / safety / dialogue each trend separately). An aggregate BWT can hide severe degradation in specific capabilities.

Follow-up: What did the COPR benchmark (Zhan et al., arXiv:2402.14228) contribute? It established the first continual human preference alignment benchmark—with a three-tier evaluation (reward-based + GPT-4 + human), covering multiple backbones, multiple replay configurations, and multiple learning orders. It proposed Lagrangian dual dynamic regularization (per-step regularization of the current policy against the historically optimal policy), which is robust across different backbones and replay sizes.

## §A Key Papers Timeline