Continual learning research asks a question that sounds academic until you have shipped an AI system for more than a few months: what happens to everything a model already does well when you teach it something new?
The answer, without deliberate engineering, is that some of it quietly degrades. This is catastrophic forgetting, and it is not a failure mode unique to research settings — it is what happens by default whenever a deployed system is fine-tuned, re-indexed, or has its prompts and retrieval sources updated without checking what was already working.
Forgetting is not always a training-time problem
In production, "forgetting" usually is not a model literally losing weights — it is a system change that shifts behaviour on cases nobody re-tested. A new document source added to a retrieval index can crowd out passages that previously answered a common question well. A prompt change that fixes one failure mode can introduce a regression in an unrelated one. The mechanism differs from academic continual learning, but the symptom — old capability quietly breaking when new capability is added — is the same.
In practice. Every update that could plausibly change model behaviour — a new fine-tune, a re-indexed knowledge base, a prompt revision — should run against the full evaluation set, not just the cases the update was meant to fix.
Stability is a property you design for, not one you hope for
Research on continual learning converges on a few practical mechanisms: keeping a representative sample of prior behaviour to check against, constraining how much a single update is allowed to shift outputs, and separating "this is new information" from "this replaces old information" rather than treating every update the same way. None of these require a research team to apply — they require treating model and knowledge updates with the same discipline as a schema migration.
- Snapshot evaluation results before and after every meaningful change, not just before launch.
- Distinguish additive updates (new information) from corrective ones (replacing something wrong) — they carry different regression risk.
- Version the knowledge base and prompts together with the code that depends on their exact behaviour.
Why this matters more as systems mature
A system's first version is judged on what it can do. Every version after that is also judged, implicitly, on what it stopped doing. The gap between those two judgements is exactly where continual learning research is useful to engineering practice — not as a technique to import wholesale, but as a reminder that capability is not additive by default.
References
Notes on evaluation-set design for update regression testing are available on request.