What Is Continual Learning? Complete 2026 Guide
- 1 day ago
- 37 min read
Every deployed AI model eventually meets a world that has changed since it was trained: new customers, new fraud patterns, new vocabulary, new sensors on a factory floor. Most models handle this the hard way — someone collects fresh data, retrains from scratch, and hopes nothing important breaks. Continual learning asks a different question: can a system update itself as the world moves, keep what it already knows, and still learn something new? The honest answer, after a decade of research, is: sometimes, partially, and only if you design for it carefully.
TL;DR
Continual learning means training a model on a sequence of tasks, domains, or data streams while trying to retain earlier knowledge — it is not the same as online learning, fine-tuning, or giving an LLM a bigger context window.
The central obstacle is catastrophic forgetting: gradient updates for new data can overwrite what a network learned before (Kirkpatrick et al., 2017).
Every method has to balance stability (keep old knowledge) against plasticity (learn new knowledge) — this is the stability-plasticity dilemma.
Method families include replay, regularization, parameter isolation, gradient management, and pretrained-model adaptation — real systems usually combine several.
Evaluation needs more than final accuracy: forgetting, backward transfer, and forward transfer all matter (Lopez-Paz & Ranzato, 2017; Díaz-Rodríguez et al., 2018).
Continual learning is a system-design decision, not just an algorithm choice — it should solve a concrete operational problem, not be adopted because it sounds advanced.
What Is Continual Learning?
Continual learning is a machine learning approach where a model learns from a sequence of tasks, domains, or data over time while trying to retain previously learned knowledge. Unlike standard training, it must resist catastrophic forgetting — the tendency of new learning to overwrite old capabilities — while still adapting to new information.
Table of Contents
What Continual Learning Actually Means
One-sentence definition: Continual learning is the study and practice of training a system on a non-stationary stream of tasks, domains, or classes so that it keeps acquiring new capabilities without losing the ones it already had.
In plain language: instead of training a model once on a fixed dataset and freezing it forever, continual learning keeps the model's education going — but it has to protect what it already learned while doing so. That protection step is what separates continual learning from ordinary training.
The more formal view. In standard machine learning, you assume training data is independently and identically distributed (i.i.d.) and available all at once. Continual learning drops that assumption. Data arrives as a sequence of experiences — tasks, domains, or batches — often with shifting distributions, and the learner typically cannot revisit all earlier data in full. The objective is not just to minimize loss on the current experience, but to keep performance acceptable across all experiences seen so far, a goal researchers describe as balancing stability and plasticity while pursuing good generalization within and across tasks (Wang et al., 2024).
A real-world analogy. Picture a radiologist who trained on decades of X-ray films and is then asked to read a new generation of digital scans from a new machine. She does not throw out everything she learned about anatomy and pathology. She adapts her interpretation skills to the new format while keeping her prior expertise intact. That is the behavior continual learning tries to reproduce in a model — accumulate, don't replace.
What continual learning is not. It is easy to mistake several adjacent ideas for continual learning:
Training a model for a very long time on one static dataset is not continual learning — it is just longer training.
Periodically retraining a model from scratch on all historical data plus new data is a legitimate engineering strategy, but it sidesteps the actual continual-learning problem because the model never has to protect knowledge under a gradient update from new data alone.
A single fine-tuning pass on one new dataset is a one-time adaptation, not a sequential learning process.
Feeding a model live data at inference time without updating its parameters is not continual learning; the parameters are static.
Giving an LLM a longer context window changes what it can read in one pass, not what it has permanently learned.
Connecting an application to a vector database for retrieval, as in retrieval-augmented generation, stores information externally; it does not update model weights.
Continual learning is not automatically synonymous with online learning. Online learning describes processing data one instance (or small batch) at a time, often without revisiting it; continual learning is broader and specifically foregrounds the retention of prior knowledge across distinct tasks or distributions, which online learning does not require by definition.
Why the terminology isn't fully standardized. Researchers use "continual learning," "lifelong learning," and "incremental learning" in overlapping but not identical ways. Some treat them as synonyms; others reserve "lifelong learning" for open-ended, never-ending learning inspired by biological cognition (Parisi et al., 2019), and "incremental learning" for settings with well-defined task or class boundaries. "Continuous learning" sometimes refers to the same idea and sometimes to streaming, single-pass learning specifically. This article uses "continual learning" as the umbrella term and calls out narrower usages where the distinction matters.
Why Continual Learning Matters
The assumption behind most deployed AI systems — train once, deploy forever — breaks down quickly in practice. Data distributions drift. New classes, users, products, and environments appear. Objectives change as business needs evolve. A model trained on last year's transaction patterns will misjudge this year's fraud, and a recommendation engine trained before a product line launched has no way to reason about it.
Full retraining sounds like a safe fallback, but it has real costs. Storing and reprocessing all historical data is expensive and sometimes legally constrained — privacy regulations, contractual data-retention limits, and bandwidth or storage caps on edge devices can make holding the entire history impractical. Retraining large models from scratch is also computationally expensive and slow, which matters when a system needs to adapt within hours, not weeks.
Continual learning targets the gap between "adapt constantly" and "retrain everything." Concrete pressures that push practitioners toward it include:
Personalization: an assistant or recommendation system that should specialize to an individual user's evolving preferences without relearning from zero for every other user.
Edge devices and autonomous agents: robots and on-device models that encounter new environments after deployment and cannot phone home for a full retrain.
Fraud and anomaly detection: attackers change tactics constantly, and models such as those used in AI fraud detection need to incorporate new patterns without forgetting older fraud signatures.
Cybersecurity: malware and intrusion techniques evolve; static classifiers used in AI-driven cybersecurity tools age quickly.
Industrial and predictive maintenance monitoring: sensor characteristics and failure modes shift as equipment ages, complicating predictive maintenance models trained on a fixed snapshot.
Medical imaging and clinical decision support: new scanner hardware, protocols, or patient populations shift input distributions over time.
Language technologies: vocabulary, slang, entities, and facts change continuously, a challenge explored later in this article's LLM section.
It's worth being precise about what continual learning promises and does not promise. It is not a universally safe, already-solved deployment strategy — uncontrolled model drift is a real risk, and the difference between healthy adaptation and harmful drift is a matter of careful monitoring, not something continual learning guarantees by default. The goal is accumulation and reuse of knowledge under real-world constraints, not unconstrained self-modification.
How Continual Learning Works
Conceptually, a continual learning system follows a repeating loop:
The model starts with some existing knowledge (which may be nothing, for a system trained from scratch, or a pretrained foundation model).
New data arrives — a new task, class, domain, or simply the next batch in a stream.
The model updates its parameters using the current experience.
A continual-learning mechanism — replay, regularization, isolation, routing, or consolidation — intervenes to protect useful prior knowledge during that update.
The system is evaluated on both the new experience and earlier ones.
The loop repeats as new experiences arrive.
Several design variables shape how hard this loop is in practice. Whether task boundaries are known (does the system know when a "new task" starts?) and whether task identity is available at inference time change which methods are even applicable. Memory and compute budgets determine whether replay-based approaches are feasible. Whether the system sees each example once (single-pass, streaming) or can revisit data across multiple epochs changes optimization dynamics substantially. Distribution shifts can be abrupt (a hard task boundary) or gradual (a slow drift with no clean boundary, sometimes called "blurry" or task-free). And the data itself may be fully labeled, partially labeled, or entirely unlabeled, which determines whether supervised, semi-supervised, or self-supervised continual methods apply.
A framework-neutral sketch of the loop looks like this:
knowledge = initialize_model()
memory = initialize_memory_or_regularizer()
for experience in data_stream:
batch = sample(experience)
loss = task_loss(knowledge, batch)
loss += retention_penalty(knowledge, memory) # regularization, distillation, or replay term
knowledge = update_parameters(knowledge, loss)
memory = update_memory(memory, experience, knowledge)
evaluate(knowledge, all_experiences_seen_so_far)This is illustrative, not production code — real implementations vary enormously depending on the method family, and none of the function calls above map to a single library API.
Catastrophic Forgetting Explained
Catastrophic forgetting (also called catastrophic interference) is the tendency of a neural network trained sequentially on new data to lose performance on tasks it previously learned well. The term originates in connectionist psychology research from the late 1980s and remains the central obstacle in continual learning today.
The mechanical cause is straightforward: gradient-based optimization updates whichever parameters reduce loss on the current batch, with no built-in incentive to preserve parameters that mattered for a different, now-absent task. Because many parameters in a neural network are shared across tasks, an update that helps task B can directly overwrite the weight configuration that made task A work. This is why naive sequential fine-tuning — training on task A, then simply continuing to train the same network on task B — routinely produces excellent performance on B and collapsed performance on A (Kirkpatrick et al., 2017; Li & Hoiem, 2017).
Forgetting is not always dramatic. It can show up gradually as representations drift over many small updates, or suddenly at a hard task boundary. It can also appear at different levels: in the raw parameters, in learned internal representations, in output predictions, or in overall task-level behavior — a model might still "know" something in its representations but fail to express it correctly at the output layer.
A concrete illustration: imagine a single neural network trained first to classify images of vehicles, then trained on images of animals, then trained on images of household objects. Without any continual-learning mechanism, testing the network after task three on the original vehicle images typically shows accuracy falling toward chance level, even though the network still performs well on the animal and household-object tasks it saw more recently. The earlier "vehicle" knowledge has effectively been overwritten.
It's worth stressing that retention alone is not the whole objective. A network that becomes rigid enough to never forget anything typically achieves that by refusing to change much at all — which sacrifices the ability to learn new things, discussed next as loss of plasticity. Zero forgetting is not automatically desirable if it comes at the cost of adaptability. It is also important to distinguish harmful, unintended forgetting from machine unlearning, where removing specific information (for compliance, privacy, or correction) is the deliberate goal rather than an accidental side effect. Forgetting, interference, transfer, and generalization are related but distinct: some interference between tasks is unavoidable and even useful when tasks share structure, while other interference is purely destructive.
The Stability-Plasticity Dilemma
Two properties pull in opposite directions in any continual learner:
Stability: the ability to retain useful knowledge already acquired.
Plasticity: the ability to learn and adapt to new information.
Optimizing only one side breaks the system. A network tuned purely for plasticity forgets catastrophically, as described above. A network tuned purely for stability — heavily constrained not to change — resists forgetting but may fail to absorb new tasks at all, a failure researchers call intransigence.
A useful analogy: think of memory as wet clay versus dry, fired ceramic. Wet clay reshapes easily (high plasticity) but holds no permanent form (low stability). Fired ceramic holds its shape indefinitely (high stability) but cannot be reshaped without breaking it (low plasticity). Useful continual learning needs something closer to clay that hardens selectively — flexible where new information should be absorbed, firm where prior knowledge must survive.
There is a subtler failure mode beyond simple rigidity: loss of plasticity, where a network's capacity to learn anything new degrades over a very long sequence of tasks, even when nothing is explicitly protecting old knowledge. A widely cited 2024 study published in Nature demonstrated this directly: on a version of ImageNet repurposed into roughly 2,000 sequential binary classification tasks, standard deep-learning training dropped from about 89% accuracy on early tasks down to about 77% — roughly the level of a linear model — by the 2,000th task, even though each new task was, individually, no harder than the ones before it (Dohare et al., 2024). The authors argue this shows standard backpropagation-based deep learning, on its own, is not well-suited to continual learning without additional mechanisms to preserve the network's capacity to keep learning.
It also matters to distinguish preserving old outputs from preserving genuinely reusable representations. A method that keeps a model's predictions unchanged on old tasks by simply refusing to update relevant output units is different from one that preserves internal representations flexible and general enough to support both old and new tasks — the latter is what most continual-learning research is actually trying to achieve, and capacity saturation (running out of usable representational "room") is a real constraint as more tasks accumulate.
Continual Learning Settings and Scenarios
Comparing continual-learning methods fairly requires agreeing on what, exactly, is changing between experiences. The most widely cited framework distinguishes three scenarios based on what changes and what information is available at test time (van de Ven, Tuytelaars & Tolias, 2022):
Task-incremental learning. The model learns a sequence of distinct tasks, and crucially, it knows which task it is being asked about at test time (task identity is given). This lets the network use task-specific output components, which makes the problem comparatively easier.
Domain-incremental learning. The input distribution or context changes across experiences, but the structure of the task and the label space stay conceptually the same, and the model does not need to know which "domain" a test example came from. A defect-detection model that must work across several factory lines with different lighting and camera setups is a domain-incremental scenario.
Class-incremental learning. New classes are introduced over time, and the model must classify among all classes seen so far without being told which subset the current test example belongs to. This is generally the hardest of the three because the model has to discriminate between classes that were never observed together during training, a problem that has proven very difficult for standard deep networks, especially when storing old examples is restricted (van de Ven, Tuytelaars & Tolias, 2022).
Beyond these three foundational scenarios, the literature discusses several related settings: instance-incremental learning (new examples of the same classes/tasks arrive continuously); online and streaming continual learning (data is processed once, often one sample at a time); blurry or task-free continual learning (no clean task boundaries exist at all, and the system must detect shifts implicitly); open-world and open-set continual learning (the model must recognize that a new input belongs to none of its known classes); continual reinforcement learning (an agent's environment or reward structure changes over time); unsupervised and self-supervised continual learning; multimodal continual learning; federated continual learning (learning continues across many decentralized clients, as in federated learning); and continual learning built on top of pretrained models, covered later in this article.
Setting | What Changes | Is Task Identity Available? | Typical Difficulty | Example |
Task-incremental | Distinct tasks arrive sequentially | Yes, at test time | Lower | A robot learns to grasp, then stack, then sort — and is told which skill is being tested |
Domain-incremental | Input distribution/context shifts | No | Medium | A quality-inspection model faces new lighting and camera setups across factory lines |
Class-incremental | New classes appear over time | No | Higher | A wildlife-camera classifier must recognize all species seen so far, unprompted |
Task-free / online | No clean boundaries; data streams continuously | Not applicable | Variable, often high | A recommendation model updates continuously as user behavior drifts |
Continual reinforcement learning | Environment, dynamics, or reward changes | Depends on formulation | Often high | An agent must keep working after in-game rules or reward structure change |
Note: Scenario definitions and terminology are not perfectly standardized across papers; some works use "incremental learning" and "continual learning" interchangeably, while others reserve specific terms for specific boundary conditions. Always check a given paper's precise scenario definition before comparing its reported numbers to another paper's.
Major Continual Learning Method Families
No single method dominates every setting, and most competitive systems today combine ideas from more than one family below. Reported results across papers are often hard to compare directly because protocols differ in memory budget, task ordering, architecture, pretraining, and hyperparameter tuning — a caveat that applies throughout this section.
Replay and Rehearsal Methods
Replay methods store or generate a sample of past experience and interleave it with new training data, directly counteracting forgetting by literally re-exposing the model to old information. Experience replay keeps raw examples in an episodic memory buffer; reservoir sampling is a common technique for maintaining a representative buffer under a fixed memory budget as the stream continues. Generative replay instead trains a generative model to synthesize pseudo-examples of past tasks, avoiding the need to store raw data — useful when privacy or storage limits raw-data retention. Latent or feature replay stores intermediate representations rather than raw inputs, which can be more compact. Several methods pair replay with knowledge distillation, using outputs from an earlier version of the network as a soft training signal (sometimes called "dark" replay when using logits rather than hard labels).
Influential concrete methods include Gradient Episodic Memory (GEM), which uses a small episodic memory to constrain new gradient updates so they do not increase loss on stored past examples (Lopez-Paz & Ranzato, 2017); its more efficient successor A-GEM, which relaxes GEM's per-sample constraints for a single averaged constraint (Chaudhry et al., 2019); iCaRL, which combines a fixed exemplar memory with distillation for class-incremental image classification (Rebuffi et al., 2017); and deep generative replay approaches that use generative models instead of stored exemplars.
Replay's advantages are conceptual simplicity and strong empirical performance, especially in class-incremental settings. Its disadvantages include storage cost, potential privacy concerns around retaining raw past data, the difficulty of keeping a small buffer representative (class imbalance in the buffer can bias the model), and compute overhead from training on both new and replayed data every step.
Regularization-Based Methods
Regularization methods add a penalty term to the training loss that discourages large changes to parameters (or functions) deemed important for earlier tasks, avoiding the need to store old data at all. Parameter regularization penalizes movement of specific weights; functional regularization penalizes changes to the model's outputs on representative inputs instead.
Elastic Weight Consolidation (EWC) is the best-known parameter-regularization method: it estimates, via an approximation to the Fisher information, how important each parameter was to previously learned tasks, then penalizes changes to the most important parameters when learning something new (Kirkpatrick et al., 2017). Synaptic Intelligence computes a related importance measure online, during training itself, rather than after the fact (Zenke, Poole & Ganguli, 2017). Learning without Forgetting (LwF) takes a functional-regularization approach: before training on a new task, it records the network's outputs on the new task's inputs using the old network, then uses those recorded outputs as a distillation target during training, requiring no old data or explicit parameter importance estimate (Li & Hoiem, 2017).
A generic regularized continual-learning objective looks like this:
$$\mathcal{L}{total} = \mathcal{L}{new} + \lambda , \mathcal{R}_{old}$$
In plain language: the total loss the network minimizes is the ordinary loss on the new task ($\mathcal{L}{new}$) plus a penalty term ($\mathcal{R}{old}$) that grows the more the network's parameters (or outputs) drift from what worked on earlier tasks. The weight $\lambda$ controls how strongly the network protects old knowledge versus how freely it adapts to new data — a direct, tunable knob on the stability-plasticity trade-off.
Regularization methods avoid storing raw data, which is attractive for privacy and storage-constrained settings. Their weaknesses: importance estimates are approximations that can be inaccurate, constraints tend to accumulate and stack across many sequential tasks (making the network progressively more rigid), and they generally struggle more than replay under large distribution shifts or long task sequences, and their effectiveness depends heavily on the specific scenario and how much task information is available.
Architectural and Parameter-Isolation Methods
Rather than fighting for shared parameters, isolation methods dedicate distinct parameters, subnetworks, or components to different tasks, physically preventing interference. Progressive Neural Networks add a new column of parameters for each new task while keeping earlier columns frozen, with lateral connections letting new columns reuse old features (Rusu et al., 2016, preprint). PackNet takes the opposite approach within a fixed-capacity network: it iteratively prunes and frees up a subset of weights for each new task while freezing the weights used by earlier tasks (Mallya & Lazebnik, 2018). More recent variants use learned binary masks, adapters, or prompt-based components layered onto a shared backbone, and expert-routing or mixture-of-experts architectures that direct different inputs to different sub-networks.
The advantage of isolation is that catastrophic forgetting on frozen parameters is essentially eliminated by construction. The disadvantages are real too: fixed-capacity approaches like PackNet eventually run out of room as more tasks accumulate, expanding architectures like Progressive Networks grow model size roughly linearly with the number of tasks, and many isolation methods assume task identity is known at inference to select the right sub-network — an assumption that fails outright in class-incremental settings. Deployment complexity also rises with dynamically changing architectures.
Optimization and Gradient-Management Methods
A related family works directly on the optimization process rather than the loss function or architecture. Gradient projection and orthogonalization techniques constrain new-task gradient updates to directions that do not interfere with directions important to earlier tasks — GEM's core mechanism is one instance of this idea, formulated as a constrained optimization problem at each step. Other approaches explicitly measure gradient alignment between tasks and adjust updates to favor directions that are neutral or beneficial to prior tasks. The boundary between "gradient management" and "replay" is not always clean in practice, since several methods (including GEM itself) use a small memory of past examples specifically to compute the gradient constraints.
Representation-Learning and Pretrained-Model Approaches
A growing share of modern continual-learning research assumes access to a strong pretrained backbone — a foundation model or transformer trained on broad data — rather than training from scratch. Common strategies include freezing the backbone entirely and only training lightweight task-specific heads or prototypes; parameter-efficient adaptation using small adapter modules or low-rank updates layered onto frozen weights; prompt-based continual learning, where small learned "prompts" steer a frozen model's behavior per task; and prototype-based classification, which stores a compact class representation rather than raw exemplars.
Strong pretraining measurably reduces some forms of forgetting, because a general-purpose, already-rich representation space needs less aggressive reshaping for each new task. But it introduces its own complications: pretraining data may already overlap with supposedly "new" benchmark tasks (contaminating evaluation), and a frozen-backbone approach can simply move the stability-plasticity trade-off into the smaller adapted components rather than eliminating it.
Hybrid Approaches
Most competitive real systems combine families rather than relying on one in isolation — replay plus regularization, replay plus distillation, adapters plus a small replay buffer, expert routing plus an external memory, or retrieval-style external memory paired with limited internal parameter updates. This is less a distinct fifth family than a recognition that the families above address different failure modes, and combining them tends to cover more ground than any single mechanism alone.
Method Family | Core Idea | Strengths | Weaknesses | Memory Cost | Compute Cost | Best-Suited Conditions |
Replay / rehearsal | Store or generate past examples and interleave with new data | Strong empirical results, especially class-incremental | Storage/privacy concerns, buffer representativeness | Medium–high | Medium–high | Storage allowed, moderate task count |
Regularization | Penalize drift in important parameters or outputs | No raw-data storage needed | Constraints accumulate, weaker under large shifts | Low | Low–medium | Privacy-sensitive, storage-constrained settings |
Parameter isolation | Dedicate distinct parameters per task | Eliminates forgetting on frozen parts by construction | Capacity growth, needs task ID at inference (often) | Low–medium | Low–medium | Known, bounded number of tasks |
Gradient management | Constrain update directions to avoid interference | Principled, works well with small memories | Added optimization complexity | Low–medium | Medium | Research settings, moderate task counts |
Pretrained-model adaptation | Adapt a frozen strong backbone with lightweight modules | Efficient, strong baseline performance | Contamination risk, trade-off shifts, not eliminated | Low | Low | Strong backbone available, limited compute |
No method family is universally "best." Reported comparisons are only meaningful when memory budgets, task orderings, architectures, and hyperparameter search effort are matched — a point emphasized across the survey literature (Wang et al., 2024; De Lange et al., 2021).
Evaluating Continual Learning Systems
Final-task accuracy alone hides most of what matters in continual learning — a model could ace the last task while having quietly forgotten everything before it. Rigorous evaluation constructs a full performance matrix: accuracy on every previously seen task, measured after training on every subsequent experience, not only at the very end.
From that matrix, several summary metrics are standard:
Average accuracy: mean performance across all tasks at the current point in training.
Forgetting: the drop in performance on a task between its best-ever accuracy and its accuracy after training on later tasks.
Backward transfer (BWT): whether learning new tasks improves (positive BWT) or degrades (negative BWT) performance on earlier tasks — introduced alongside GEM (Lopez-Paz & Ranzato, 2017).
Forward transfer (FWT): whether knowledge from earlier tasks improves performance on a task the model has not yet been trained on.
Intransigence: the inability to learn a new task well even when given the chance, a sign of excessive stability.
A widely used backward-transfer formulation:
$$BWT = \frac{1}{T-1}\sum_{i=1}^{T-1} \left(R_{T,i} - R_{i,i}\right)$$
Here $T$ is the total number of tasks, $R_{i,i}$ is the accuracy on task $i$ right after training on task $i$, and $R_{T,i}$ is the accuracy on task $i$ after training on all $T$ tasks. A negative value means forgetting occurred on average; a positive value means later learning actually helped earlier tasks.
Beyond accuracy-based metrics, complete evaluation also considers computational efficiency, memory overhead, training time, inference cost, model growth (for expanding architectures), sample efficiency, and — where relevant — robustness, calibration, fairness over time, privacy of any stored data, and adaptation latency (Díaz-Rodríguez et al., 2018).
Several caveats matter for anyone interpreting continual-learning results. Metric definitions vary slightly across papers, so exact numeric comparisons across different codebases can be misleading. Positive backward transfer is a stronger and rarer result than simply avoiding forgetting. Lower forgetting does not automatically mean better overall learning — a model that barely adapts at all has low forgetting and low usefulness. Results are highly sensitive to memory budget, task ordering, architecture, pretraining, and hyperparameter tuning effort, so a method that "wins" under one protocol may not win under another. Joint training on all data pooled together (ignoring the continual-learning constraint entirely) is commonly reported as an upper-bound-style reference point, and naive sequential fine-tuning with no protective mechanism is the standard lower-bound baseline. Reporting a single final score, without the full performance-over-time picture, can conceal a model that performed terribly mid-stream and only happened to recover by the end.
Metric | What It Measures | Higher Is Better? |
Average accuracy | Overall performance across all seen tasks | Yes |
Forgetting | Performance drop on old tasks after new learning | No (lower is better) |
Backward transfer | Effect of new learning on old-task performance | Yes (can be negative) |
Forward transfer | Effect of old learning on new-task performance | Yes |
Common Benchmarks and Datasets
Continual-learning research relies on a mix of simple, controlled benchmarks and more realistic, harder ones.
Permuted MNIST, Rotated MNIST, and Split MNIST apply pixel permutations, rotations, or class splits to the classic MNIST digit dataset to construct artificial task sequences. Split CIFAR-10 and Split CIFAR-100 do the same with more visually complex natural images. These MNIST- and CIFAR-based benchmarks remain useful for fast, controlled experiments and ablation studies, but they are widely acknowledged as too simple to make strong claims about real-world deployment readiness — the tasks are artificial partitions of an otherwise i.i.d. dataset, not naturally evolving data.
ImageNet-derived incremental benchmarks split the standard ImageNet classes into sequential groups for class-incremental evaluation at larger scale. CORe50 is a benchmark purpose-built for continuous object recognition from video, explicitly designed around a small set of objects captured under naturally varying conditions rather than an artificial split of a static dataset (Lomonaco & Maltoni, 2017). Domain-focused benchmarks such as DomainNet test domain-incremental learning across visually distinct domains (sketches, paintings, real photos) of the same classes. More recent efforts target naturally evolving, temporally ordered data streams to better approximate real deployment conditions, and continual reinforcement-learning environments and LLM-specific continual benchmarks have emerged to address settings this article covers in later sections.
Two persistent problems affect benchmark interpretation across the field: benchmark leakage, where evaluation data has effectively already been seen during pretraining of a backbone, is a growing concern as pretrained models become the default starting point; and protocol inconsistency — differing memory budgets, task orders, and preprocessing choices — makes reproducing or directly comparing published results across papers difficult even on the same nominal benchmark.
Real-World Applications
Several domains illustrate why continual learning matters operationally, and what would go wrong without it.
Fraud and anomaly detection. Fraud tactics change constantly; a model trained on last quarter's patterns misses new schemes. Continual updates must incorporate new fraud signatures without erasing detection ability for older, still-active schemes — a direct instance of the forgetting risk discussed earlier, relevant to systems like AI-based fraud detection and broader anomaly detection.
Cybersecurity and malware detection. Malware families evolve, and attackers actively adapt to evade known detectors, making AI security and AI-driven cybersecurity tools a natural continual-learning use case — full retraining cycles are often too slow relative to how quickly new threats appear.
Recommendation and personalization. User preferences, product catalogs, and seasonal trends shift continuously; a recommendation engine that cannot adapt loses relevance, but one that overreacts to short-term noise can develop unstable, poor-quality suggestions.
Predictive maintenance and industrial monitoring. Sensor characteristics, equipment wear patterns, and failure modes evolve as machinery ages; predictive maintenance systems need to track these shifts, and a false negative — missing a genuinely new failure signature — has direct safety and cost consequences.
Healthcare and medical imaging. New scanner hardware, imaging protocols, or patient population shifts change input distributions in AI in healthcare settings. Because misdiagnosis has severe consequences, any continual update here demands strict human oversight, careful validation, and rollback capability rather than autonomous, unmonitored adaptation.
Robotics and autonomous systems. Robots deployed in the physical world, discussed in the context of general-purpose robotics, encounter new objects, terrains, and tasks that were never part of their training distribution, and full retraining is rarely feasible on-site.
On-device and edge AI. Personal devices running edge AI often cannot transmit raw data back to a central server for retraining because of bandwidth, latency, or privacy constraints, making local, resource-constrained adaptation attractive.
Language technologies and assistants. Vocabulary, named entities, and factual knowledge change over time — a challenge explored in depth in the next section on large language models.
Across every one of these applications, what must be remembered, what failure looks like, and which constraints (latency, storage, regulation, safety) apply differ enough that no single continual-learning recipe transfers cleanly between them — a point developed further in the implementation framework below. This article does not make specific medical, safety, or regulatory claims about any of these systems beyond noting that human oversight and rollback mechanisms are broadly recommended wherever consequences of failure are severe.
Continual Learning for Large Language Models and Foundation Models
Continual learning shows up at several distinct points in the LLM lifecycle: continual pre-training (extending a base model's general knowledge with new, large-scale text over time), domain-adaptive pretraining (specializing a general model to a domain like law, medicine, or finance), sequential fine-tuning or supervised instruction tuning across successive datasets, preference or alignment updates (including techniques related to RLHF), tool-use adaptation, skill acquisition, personalization to a specific user or organization, and multilingual or domain expansion (Shi et al., 2024).
The risks are distinctive at this scale. Catastrophic forgetting of general capabilities can occur when a model is heavily fine-tuned on a narrow domain, degrading broad reasoning or knowledge that was not part of the fine-tuning data. Alignment drift and safety regressions are a particular concern: continual updates intended to add a capability can inadvertently weaken safety behaviors established during earlier training stages. Domain over-specialization can make a model excellent at one narrow task while measurably worse at everything else. Knowledge conflicts arise when newly learned facts contradict facts absorbed earlier, and it is often genuinely difficult to determine whether a model's factual knowledge was actually updated or whether it is simply pattern-matching surface phrasing from fine-tuning data. Evaluation contamination is a serious methodological problem, since continually pretrained models may have already seen benchmark-like data during an earlier stage. And the sheer training cost of iterating on models with tens or hundreds of billions of parameters makes naive "just retrain from scratch every time" approaches operationally unrealistic for most organizations, which is exactly the practical pressure that motivates continual-learning research for LLMs in the first place.
It is important to draw sharp boundaries between continual learning and several adjacent techniques that are sometimes conflated with it:
Retrieval-augmented generation (RAG) stores information externally in a vector database or similar index and retrieves it at inference time; it does not change model parameters and is not continual learning, though it can be a complementary strategy.
Long-context prompting and in-context learning let a model use more information within a single forward pass; nothing about the model's weights is permanently updated.
Model editing techniques target narrow, surgical changes to specific facts within a model, which is a related but distinct research area from broad continual learning.
Periodic full retraining avoids the continual-learning problem entirely by starting over, at high cost.
Parameter-efficient fine-tuning (adapters, low-rank updates) is a tool that continual-learning methods can use, but applying it once to one new dataset is not, by itself, continual learning — repeated, sequential application with a retention mechanism is what makes it continual.
Tool use lets a model call external functions or APIs; it does not modify the model's learned parameters.
These technologies can complement continual learning — for example, retrieval can handle fast-changing facts while continual fine-tuning handles slower-changing skills or style — but none of them is automatically equivalent to it. Given the rapid pace of change in this specific sub-area, and because commercial systems' internal training practices are often undocumented, this section avoids claims about how any particular proprietary product handles continual updates; readers should consult each vendor's official documentation for that.
Continual Learning Compared With Related Concepts
Continual learning sits in a crowded neighborhood of related ideas, and the boundaries between them are treated differently across research communities.
Concept | Main Goal | Data Arrival | Does the Model Update? | Must Old Knowledge Be Retained? | Key Difference |
Batch learning | Learn once from a fixed dataset | All at once | Once | Not applicable | No sequential adaptation at all |
Learn from a continuous stream, often one example at a time | Continuous | Continuously | Not required by definition | Focuses on efficient single-pass updates, not explicit retention | |
Incremental learning | Add new tasks/classes/data over time | Sequential | Yes | Usually, but scope varies by paper | Often used near-synonymously with continual learning |
Lifelong learning | Open-ended, human-like accumulation of skills over a "lifetime" | Sequential, ongoing | Yes | Strongly emphasized | Broader, more open-ended framing than task-bounded continual learning |
Reuse knowledge from a source task to help a target task | Typically two distinct phases | Yes, for the target task | Not required | One-directional transfer; no requirement to retain source-task performance | |
Adapt a pretrained model to one new dataset/task | Single new dataset | Yes, once | Not required | A single adaptation step, not a sequence | |
Domain adaptation | Adjust a model to a new but related input distribution | Usually one shift | Yes | Sometimes | Focuses on one specific distribution shift, not an open sequence |
Concept-drift adaptation | Track a target variable's changing relationship with inputs over time | Continuous stream | Yes | Partially | Statistics/streaming-focused framing, close to online continual learning |
Learn several tasks simultaneously | All tasks available together | Yes | Not sequential by design | Tasks are trained jointly, not one after another | |
Meta-learning | Learn how to learn new tasks quickly | Many tasks, often simulated | Yes, at a meta level | Not the primary goal | Optimizes for fast adaptation, not necessarily long-term retention |
Choose which examples to label for efficient training | Pool or stream, learner selects | Yes | Not the primary goal | Focuses on label efficiency, not sequential task retention | |
Train across decentralized data without centralizing it | Distributed across clients | Yes, aggregated centrally | Depends on setting | Focuses on decentralization and privacy, not sequential task structure | |
Learn a policy via reward signals | Interaction with an environment | Yes | Not required by definition | Reward-driven; becomes "continual RL" only when the environment itself changes over time | |
Ground generation in external retrieved information | Index updated externally | No (parameters frozen) | Handled by the index, not the model | No parameter update at all | |
In-context learning | Use examples within a single prompt to guide behavior | Within one inference call | No | Not applicable | Entirely transient; nothing persists after the call |
Model editing | Make a targeted correction to specific model knowledge | A single edit event | Yes, narrowly | Only for the edited fact | Surgical and localized, not a general learning process |
Machine unlearning | Deliberately remove specific learned information | A removal request | Yes, to forget | Explicitly the opposite — forgetting is the goal | Intentional forgetting rather than accidental forgetting |
These boundaries are genuinely debated. Some researchers treat "incremental learning" and "continual learning" as fully interchangeable; others use "lifelong learning" as the broadest umbrella term and treat continual learning as one operationalization of it. When reading continual-learning literature, always check how a specific paper defines its terms rather than assuming a universal convention.
A Practical Implementation Framework
Before choosing a method, define the problem precisely. Useful questions to answer up front include: What actually changes over time — new classes, a shifting input distribution, a changing reward signal, or something else? What must be remembered, specifically, and for how long? What data can legally and operationally be stored, given privacy and retention constraints? Are task boundaries known, and is task identity available at inference time? What are the memory budget, compute budget, and acceptable model-size growth? What adaptation latency is acceptable — minutes, hours, days? What rollback and monitoring plan exists if an update degrades performance? What evaluation matrix and baseline methods will be used? Is there a scheduled retraining cadence as a fallback, and what human-review requirements apply before an update goes live?
A practical evaluation workflow follows from these answers:
Establish a naive sequential fine-tuning baseline (no protective mechanism) as the worst-case reference.
Establish a joint-training or full-retraining reference when feasible, as a rough upper bound.
Choose task orderings that resemble realistic deployment conditions, not just convenient benchmark splits.
Test across multiple random seeds and task orders, since single-run results can be misleading.
Fix and report memory budgets explicitly so comparisons remain fair.
Measure performance over time across the whole stream, not only at the end.
Track both retention (forgetting) and acquisition (new-task accuracy) separately.
Monitor model growth and operational cost as tasks accumulate.
Test for safety, fairness, calibration, and distribution shift where the application demands it.
Maintain checkpoints and a clear rollback path.
Use shadow deployment or a staged rollout for higher-risk systems before full production adoption.
Document exactly what is stored in any replay memory, and under what retention policy.
Compare the continual-learning solution against simpler alternatives (scheduled retraining, a retrieval layer, or separate per-segment models) before committing to it.
A minimal, framework-neutral evaluation-loop checklist:
for each candidate_method in [naive_baseline, joint_upper_bound, method_A, method_B]:
for each seed in seeds:
for each task_order in orders:
train_sequentially(candidate_method, tasks, seed, task_order)
record(average_accuracy, forgetting, backward_transfer,
forward_transfer, memory_used, compute_used)
summarize_across(seeds, orders)
compare(candidate_methods, against = [naive_baseline, joint_upper_bound])When Continual Learning Is the Right Choice
Continual learning tends to earn its complexity when several of these conditions hold: data genuinely arrives over time rather than in one fixed batch; full historical retraining is too expensive in compute, time, or data-storage terms to repeat regularly; the deployment environment itself changes (new users, products, sensors, or attack patterns); previously learned capabilities must be preserved even as new ones are added; adaptation speed matters more than the marginal accuracy gains of a from-scratch retrain; personalized, per-user or per-device learning is valuable; and storage or data-retention restrictions genuinely prevent centralizing all historical data for a full retrain.
When Continual Learning May Not Be the Right Choice
Simpler alternatives often win when periodic batch retraining is affordable and fast enough for the business need; data distributions are relatively stable and drift slowly, if at all; a retrieval layer can solve the problem without touching model parameters at all; separate, independently maintained models per segment or use case are simpler and safer than one continually evolving model; the "new" data really represents a single, one-time domain shift rather than an ongoing stream; there isn't reliable historical evaluation data to verify that updates aren't quietly degrading the system; regulatory or safety requirements demand tightly version-controlled, auditable model releases rather than a continuously drifting model; the adaptation signal available is too noisy to learn from reliably; a model update could introduce unacceptable regressions in a high-stakes setting; or the operational complexity of maintaining a continual-learning pipeline outweighs its expected benefit. Continual learning should solve a concrete system requirement identified through the questions above — not be adopted simply because it is a technically interesting idea.
Limitations and Open Research Problems
Several challenges remain genuinely unresolved. The stability-plasticity trade-off has no universal solution — every method makes a choice along that trade-off, not an escape from it. Very long task sequences continue to expose loss-of-plasticity effects even in methods that handle forgetting reasonably well (Dohare et al., 2024). Unknown task boundaries, natural and gradual shifts, and recurring (rather than strictly novel) distributions are all harder than the clean task splits used in most benchmarks. Scalability, memory efficiency, and compute or energy cost all worsen as task counts and model sizes grow. Privacy and security of replay buffers is an underexplored risk, since stored exemplars are themselves sensitive data. Negative transfer and spurious knowledge retention (keeping outdated or wrong information because it was never explicitly targeted for forgetting) both remain open problems. Fair, reproducible evaluation is hampered by inconsistent protocols across papers, and realistic, naturally evolving benchmarks are still less common than artificial splits of static datasets. Multimodal learning, open-world recognition, and continual reinforcement learning all introduce additional, less-studied failure modes. Safety, alignment, and long-term monitoring become significantly harder to reason about once a system's parameters are expected to keep changing after deployment, and model rollback, provenance, and auditability — knowing exactly what changed, when, and why — are underdeveloped in most current tooling. Finally, deciding what a system should forget versus retain, and how to combine internal parameter updates with external memory systems like retrieval, remain active areas of inquiry rather than solved problems.
Future Outlook
Several directions look likely to shape the next few years of continual-learning research, based on current trends rather than firm predictions. More realistic, longer-duration benchmarks that better resemble naturally evolving data are likely to keep displacing purely artificial task splits. Methods explicitly designed around strong pretrained and foundation models — rather than training from scratch — will likely continue to dominate practical applications, given how much forgetting a good pretrained representation space appears to mitigate. Parameter-efficient continual adaptation, modular architectures, and mixture-of-experts-style routing are active areas that address both capacity growth and interference simultaneously. Combining external memory (retrieval-style systems) with internal parameter updates, rather than treating them as competitors, looks like a promising direction for handling fast-changing facts alongside slower-changing skills. Better task-free learning, continual self-supervised learning, and continual multimodal learning all remain comparatively underdeveloped relative to supervised, task-bounded settings. Neuromorphic and other edge-oriented approaches aim to bring continual adaptation to resource-constrained hardware. Safety, privacy, and governance tooling for continually updating systems will likely need to mature alongside the algorithms themselves, particularly for LLM-based systems where alignment drift is a live concern. And evaluation that spans a system's complete deployment lifecycle — not just a fixed benchmark sequence — is likely to become more standard as continual learning moves from research papers into production systems. None of this implies a near-term arrival at fully human-like, open-ended lifelong learning; the field is addressing narrower, more tractable versions of the problem.
Conclusion
Continual learning is the attempt to make machine learning systems behave less like a one-time exam and more like an ongoing education — accumulating new capability without discarding old competence. The central tension driving nearly every method in this article is the stability-plasticity trade-off: hold on too tightly to what a model already knows and it cannot adapt; let it adapt too freely and catastrophic forgetting erases prior knowledge. No method eliminates that trade-off; each one makes a deliberate, situational choice about where to sit on it, using replay, regularization, architectural isolation, gradient management, or pretrained-model adaptation, often in combination. That is why continual learning is best understood as a system-design problem — one that requires clarity about what changes, what must be remembered, and what constraints on memory, compute, and risk apply — rather than a single algorithm to drop into an existing pipeline. Evaluation has to track both new and old capabilities over the entire course of learning, not just a final score, because a model that quietly forgot everything along the way can still look fine at the finish line. With that framing in place, the practical questions below tackle the specifics readers most often ask next.
FAQ
What is continual learning in simple terms?
Continual learning is training a model on new information over time while trying to keep it good at the things it already learned, rather than starting over or letting old skills fade every time something new is introduced.
Is continual learning the same as continuous learning?
The terms are often used interchangeably, but "continuous learning" sometimes specifically implies uninterrupted, single-pass streaming updates, while "continual learning" is the broader research term covering sequential tasks, domains, and classes with an explicit focus on retaining prior knowledge. Usage varies by author, so check context.
Is continual learning the same as online learning?
No. Online learning describes processing data one instance or small batch at a time, often without revisiting it, and doesn't require explicitly preserving performance on earlier tasks. Continual learning is broader and specifically centers on retaining knowledge across distinct experiences, which online learning does not guarantee by definition.
What is catastrophic forgetting?
Catastrophic forgetting is when a neural network trained on new data loses much of its earlier performance because gradient updates for the new task overwrite parameters that mattered for previously learned tasks. It's the central problem continual-learning methods try to solve.
What are the main types of continual learning?
The three foundational scenarios are task-incremental (task identity known at test time), domain-incremental (input distribution shifts, task structure stays similar), and class-incremental (new classes appear, no task identity given) — with several related settings like task-free, online, and continual reinforcement learning layered on top.
What is a replay-based method in continual learning?
Replay methods store or generate a sample of past data — as raw exemplars, generated pseudo-examples, or stored representations — and mix it with new training data so the model keeps practicing on old tasks while learning new ones, directly counteracting forgetting.
Does continual learning require storing old data?
Not always. Replay-based methods do store or generate past data, but regularization-based methods (like EWC or Learning without Forgetting) and many parameter-isolation methods avoid storing raw old data at all, instead constraining how much parameters or outputs are allowed to change.
How is continual learning evaluated?
Beyond final accuracy, evaluation tracks a full performance matrix over time, plus metrics like average accuracy, forgetting, backward transfer, and forward transfer, alongside practical factors like memory use, compute cost, and model growth.
Can large language models learn continually?
Yes, in several forms — continual pretraining, domain-adaptive pretraining, and sequential fine-tuning — but doing so risks forgetting general capabilities, alignment drift, and safety regressions, which is why it requires careful evaluation rather than routine, unmonitored updates.
Is retrieval-augmented generation a form of continual learning?
No. RAG retrieves information from an external index at inference time without changing the model's parameters, while continual learning specifically involves updating the model itself over a sequence of experiences. The two can complement each other.
What are the main disadvantages of continual learning?
Storage and privacy concerns for replay-based methods, growing rigidity or capacity constraints for regularization and isolation methods, added engineering complexity, difficulty proving safety and robustness of continuously updating systems, and the general difficulty of fairly comparing methods across inconsistent evaluation protocols.
Is continual learning ready for production use?
It depends heavily on the application. It's used in production for settings like fraud detection and personalization with careful monitoring and rollback plans, but for high-stakes domains such as medical diagnosis, most practitioners still favor tightly controlled, versioned model releases over continuously self-updating models.
Can continual learning intentionally make a model forget something?
Deliberately removing specific learned information is generally studied under a separate label — machine unlearning — rather than continual learning, since continual learning's default goal is retention, while unlearning's explicit goal is targeted removal.
What is the stability-plasticity dilemma?
It's the core trade-off in continual learning between stability (retaining existing knowledge) and plasticity (the ability to learn new information). Overemphasizing one causes either catastrophic forgetting or an inability to adapt, so every continual-learning method makes a deliberate choice about where to sit on this spectrum.
When should a company consider continual learning instead of periodic retraining?
When data truly arrives as an ongoing stream, full retraining is too slow or expensive to repeat as often as needed, the environment keeps changing (new users, fraud patterns, or products), and preserving prior capability while adapting quickly matters more than squeezing out the last bit of accuracy a full retrain might offer.
Key Takeaways
Continual learning trains a model on a sequence of tasks, domains, or classes, explicitly trying to retain earlier knowledge — it is distinct from online learning, fine-tuning, RAG, and simply extending a context window.
Catastrophic forgetting happens because gradient updates for new data can overwrite parameters that mattered for earlier tasks, and it can appear gradually or suddenly, and at the parameter, representation, or output level.
The stability-plasticity dilemma has no universal fix; every method — replay, regularization, isolation, gradient management, or pretrained-model adaptation — makes a deliberate trade-off, and most competitive systems combine several.
Task-incremental, domain-incremental, and class-incremental learning are the three foundational scenarios, and class-incremental is generally the hardest because task identity is unavailable at inference.
Rigorous evaluation requires a full performance matrix over time, not just final accuracy — forgetting, backward transfer, and forward transfer all carry independent information.
Loss of plasticity is a distinct failure mode from forgetting: a network can lose its ability to learn new things even when nothing is explicitly protecting old knowledge.
Continual learning for LLMs and foundation models introduces distinctive risks — alignment drift, safety regressions, and evaluation contamination — that go beyond classic image-classification forgetting.
The right question is not "does continual learning sound advanced?" but "does my system genuinely need to adapt over time while preserving specific prior knowledge, under specific memory, compute, and risk constraints?"
Actionable Next Steps
Write down precisely what changes over time in your system and what specifically must be remembered.
Specify which continual-learning scenario applies — task-incremental, domain-incremental, class-incremental, or task-free/online.
Establish a naive sequential fine-tuning baseline and, if feasible, a joint-training upper-bound reference.
Choose or construct a benchmark or realistic data stream that reflects your actual deployment conditions, not just a convenient artificial split.
Select evaluation metrics up front: average accuracy, forgetting, backward transfer, and forward transfer at minimum.
Set explicit memory, compute, privacy, and adaptation-latency constraints before comparing methods.
Test at least one replay-based method and one non-replay method (regularization or isolation) as points of comparison.
Evaluate across multiple random seeds and task orderings, not a single run.
Build monitoring, checkpointing, and rollback procedures before any continual-learning system goes live.
Compare your continual-learning solution against simpler alternatives — scheduled retraining, a retrieval layer, or separate per-segment models.
Document every assumption, failure mode, and what exactly is stored in any replay memory.
Revisit the "is this the right choice" checklist periodically as your data, scale, and risk tolerance change.
Glossary
Backward transfer: The effect that learning a new task has on performance on previously learned tasks; can be negative (forgetting) or positive (old tasks improve).
Catastrophic forgetting: The sharp loss of performance on previously learned tasks caused by training on new data.
Class-incremental learning: A setting where new classes are introduced over time and the model must distinguish among all classes seen so far without being told which task or class group a test example belongs to.
Concept drift: A change over time in the statistical relationship between inputs and the target variable a model is predicting.
Continual learning: Training a system on a sequence of tasks, domains, or data while trying to retain previously acquired knowledge.
Domain-incremental learning: A setting where the input distribution or context shifts over time while the underlying task structure stays similar, and task identity is not required at test time.
Episodic memory: A stored buffer of past training examples used by replay-based continual-learning methods.
Experience replay: Interleaving stored or generated past examples with new training data to counteract forgetting.
Forward transfer: The effect that knowledge from earlier tasks has on learning a task the model has not yet been trained on.
Generative replay: Using a generative model to synthesize pseudo-examples of past tasks instead of storing raw data.
Incremental learning: A term often used interchangeably with continual learning, generally implying tasks or classes are added sequentially.
Intransigence: The failure to learn a new task well, often a side effect of a continual-learning method being overly conservative about protecting old knowledge.
Lifelong learning: A broader, often more open-ended framing of continual learning inspired by how humans and animals accumulate skills over a lifetime.
Loss of plasticity: A gradual decline in a network's ability to learn new tasks over a long sequence, distinct from forgetting old ones.
Machine unlearning: Deliberately removing specific learned information from a model, as opposed to accidental forgetting.
Non-stationary data: Data whose statistical properties change over time, rather than being drawn from one fixed distribution.
Online learning: Learning from a continuous stream of data, typically one example or small batch at a time, without an inherent requirement to preserve performance on earlier data.
Parameter isolation: A continual-learning strategy that dedicates distinct parameters or subnetworks to different tasks to prevent interference.
Plasticity: A model's capacity to learn and adapt to new information.
Regularization (in continual learning): Adding a penalty term to training loss that discourages large changes to parameters or outputs deemed important for earlier tasks.
Replay buffer: The storage structure holding past examples (or generated substitutes) used by replay-based methods.
Stability: A model's capacity to retain previously learned, useful knowledge.
Stability-plasticity dilemma: The fundamental trade-off in continual learning between retaining old knowledge and remaining able to learn new information.
Task boundary: The point at which one task, domain, or experience ends and another begins in a continual-learning stream.
Task-free continual learning: Learning without explicit, known boundaries between tasks or experiences.
Task-incremental learning: A setting where distinct tasks arrive sequentially and the model is told which task it faces at test time.
Sources & References
Kirkpatrick, J., Pascanu, R., Rabinowitz, N., et al. "Overcoming Catastrophic Forgetting in Neural Networks." Proceedings of the National Academy of Sciences, 114(13), 3521–3526, 2017. https://www.pnas.org/doi/10.1073/pnas.1611835114
Li, Z., & Hoiem, D. "Learning without Forgetting." IEEE Transactions on Pattern Analysis and Machine Intelligence, 40(12), 2935–2947, 2017. https://doi.org/10.1109/TPAMI.2017.2773081
Lopez-Paz, D., & Ranzato, M. "Gradient Episodic Memory for Continual Learning." Advances in Neural Information Processing Systems 30 (NeurIPS 2017). https://proceedings.neurips.cc/paper/2017/hash/f87522788a2be2d171666752f97ddebb-Abstract.html
Chaudhry, A., Ranzato, M., Rohrbach, M., & Elhoseiny, M. "Efficient Lifelong Learning with A-GEM." International Conference on Learning Representations (ICLR), 2019. https://openreview.net/forum?id=Hkf2_sC5FX
Rebuffi, S.-A., Kolesnikov, A., Sperl, G., & Lampert, C. H. "iCaRL: Incremental Classifier and Representation Learning." IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2001–2010, 2017. https://openaccess.thecvf.com/content_cvpr_2017/papers/Rebuffi_iCaRL_Incremental_Classifier_CVPR_2017_paper.pdf
Rusu, A. A., Rabinowitz, N. C., Desjardins, G., et al. "Progressive Neural Networks." arXiv preprint, 2016 (preprint). https://arxiv.org/abs/1606.04671
Mallya, A., & Lazebnik, S. "PackNet: Adding Multiple Tasks to a Single Network by Iterative Pruning." IEEE Conference on Computer Vision and Pattern Recognition (CVPR), 7765–7773, 2018. https://openaccess.thecvf.com/content_cvpr_2018/papers/Mallya_PackNet_Adding_Multiple_CVPR_2018_paper.pdf
Zenke, F., Poole, B., & Ganguli, S. "Continual Learning Through Synaptic Intelligence." Proceedings of the 34th International Conference on Machine Learning (ICML), PMLR 70, 3987–3995, 2017. https://proceedings.mlr.press/v70/zenke17a.html
van de Ven, G. M., Tuytelaars, T., & Tolias, A. S. "Three Types of Incremental Learning." Nature Machine Intelligence, 4(12), 1185–1197, 2022. https://doi.org/10.1038/s42256-022-00568-3
Dohare, S., Hernandez-Garcia, J. F., Lan, Q., Rahman, P., Mahmood, A. R., & Sutton, R. S. "Loss of Plasticity in Deep Continual Learning." Nature, 632, 768–774, 2024. https://doi.org/10.1038/s41586-024-07711-7
Wang, L., Zhang, X., Su, H., & Zhu, J. "A Comprehensive Survey of Continual Learning: Theory, Method and Application." IEEE Transactions on Pattern Analysis and Machine Intelligence, 46(8), 5362–5383, 2024. https://arxiv.org/abs/2302.00487
De Lange, M., Aljundi, R., Masana, M., et al. "A Continual Learning Survey: Defying Forgetting in Classification Tasks." IEEE Transactions on Pattern Analysis and Machine Intelligence, 44(7), 3366–3385, 2021/2022. https://arxiv.org/abs/1909.08383
Parisi, G. I., Kemker, R., Part, J. L., Kanan, C., & Wermter, S. "Continual Lifelong Learning with Neural Networks: A Review." Neural Networks, 113, 54–71, 2019. https://doi.org/10.1016/j.neunet.2019.01.012
Kudithipudi, D., Aguilar-Simon, M., Babb, J., et al. "Biological Underpinnings for Lifelong Learning Machines." Nature Machine Intelligence, 4, 196–210, 2022. https://www.nature.com/articles/s42256-022-00452-0
Lomonaco, V., & Maltoni, D. "CORe50: A New Dataset and Benchmark for Continuous Object Recognition." 1st Annual Conference on Robot Learning (CoRL), PMLR 78, 17–26, 2017. https://proceedings.mlr.press/v78/lomonaco17a.html
Lomonaco, V., Pellegrini, L., Cossu, A., et al. "Avalanche: An End-to-End Library for Continual Learning." IEEE/CVF Conference on Computer Vision and Pattern Recognition Workshops (CVPRW), 2021. https://openaccess.thecvf.com/content/CVPR2021W/CLVision/papers/Lomonaco_Avalanche_An_End-to-End_Library_for_Continual_Learning_CVPRW_2021_paper.pdf
Díaz-Rodríguez, N., Lomonaco, V., Filliat, D., & Maltoni, D. "Don't Forget, There Is More Than Forgetting: New Metrics for Continual Learning." arXiv preprint, 2018 (preprint; NeurIPS 2018 Continual Learning Workshop). https://arxiv.org/abs/1810.13166
Shi, H., Xu, Z., Wang, H., et al. "Continual Learning of Large Language Models: A Comprehensive Survey." arXiv preprint 2404.16789, 2024 (published in ACM Computing Surveys, 2025). https://arxiv.org/abs/2404.16789
