How does replaying a small buffer of source examples reduce catastrophic forgetting?

## The idea If forgetting is caused by an objective that mentions only the new task, the most direct repair is to put the old task back into the objective. **Rehearsal** — also called replay — does exactly that: a stored buffer of original examples is mixed into the training stream during adaptation, so every update is computed on a mixture of old and new data. It is the strongest and simplest mitigation available, and everything else in this area exists because keeping the old data is sometimes impossible. ## Why it works With a mixed batch, the gradient at each step is a weighted sum of a new-task gradient and an old-task gradient. A direction that lowers the new loss while destroying old performance now increases the old-task term, and the sum resists it. The optimizer is pushed toward the intersection of the two low-loss regions rather than into whatever nearby point minimises the new task alone. The crucial detail is *interleaving*, not alternating phases. Training on new data for an epoch and then on old data for an epoch reproduces the original problem twice — each phase forgets the other. Every batch should carry both. ## How much data Surprisingly little. Because the pretrained weights still encode most of the old structure, the buffer's job is to *anchor*, not to reteach: a buffer holding on the order of a couple of percent of the source examples, interleaved into every batch, is often enough to hold a retained source score near its original level. That asymmetry — a small fraction of data preventing a large loss of capability — is the practical reason rehearsal is the default recommendation. The mixing ratio is a separate knob from buffer size. You can hold 2 percent of the source set and still make old examples 10 percent of every batch by sampling them more often; you can also weight the old-task loss term up or down. More old signal buys retention and costs plasticity on the new task, and the retained evaluation is how you find the point you actually want. ## What goes in the buffer The buffer defines what is protected. Anything not represented is unprotected, so selection matters more than raw count. - **Cover every retained capability.** In class-incremental training, keep examples per class rather than sampling uniformly from a stream, or rare classes vanish from the buffer and then from the model. - **Keep it balanced.** An imbalanced buffer reproduces its imbalance as a prediction bias, on top of the recency bias that class-incremental training already induces. - **Prefer diverse, representative examples over exclusively hard ones.** Selecting only the hardest cases produces a buffer that is unrepresentative of the old distribution and can anchor the model to its edge cases. - **Fix it before the run and version it**, so a retention number means the same thing across releases. ## The failure modes - **Buffer memorisation.** A small buffer is revisited hundreds of times more often than any new example. The model can fit those specific items while the underlying capability still decays. This is why the retained evaluation set must be strictly disjoint from the buffer — otherwise the tripwire reports the buffer's training accuracy and never fires. - **Ratio set and forgotten.** Too little old data and forgetting proceeds barely slowed; too much and the new task never really lands. It is a tunable with a measurable cost on both sides, so tune it against both evaluations. - **Phase separation.** Replaying old data as a warm-up or a final repair pass instead of interleaving it wastes most of the benefit. - **Stale buffer under distribution shift.** If the world moved, examples kept from two years ago anchor the model to a distribution that no longer exists. For a news-topic tagger refreshed monthly, the buffer must be curated to represent label semantics you still want, not merely old rows. ## What it costs Rehearsal buys retention with storage and with permission. You must keep the source examples, which raises retention-policy, licensing and privacy questions that are often the real blocker — a vendor dataset you are no longer licensed to hold, or user data you promised to delete, cannot sit in a replay buffer. It also lengthens each run, since part of every batch is spent on data whose task is already learned. When the data genuinely cannot be kept, rehearsal is off the table and you fall back to methods that operate on the parameters instead — a penalty that makes the weights the old task depended on expensive to move — accepting weaker retention in exchange for storing no examples at all. ## The judgment call Rehearsal is not free plasticity. Every batch slot given to old data is one not spent on the new task, and every retained capability enlarges the buffer. At some point the honest answer is that a capability is retired and should be dropped from both the buffer and the retained evaluation — a decision worth making explicitly, since the alternative is a buffer that grows forever and an adaptation that gets slower every cycle.