Continual Learning Systems | The Garnet Wiki

Continual learning systems enable machine learning models to adapt and improve over time as new data arrives, without needing full retraining from scratch. They are essential when data distributions shift, new classes emerge, or model drift degrades performance—common in real-world deployments where data is streaming, labels are sparse, and feedback loops are active. These systems are required not just for batched retraining, but for online, incremental, and adaptive learning across the lifecycle of a model.

Core Workflow: Ingest, Adapt, Deploy

Ingest New Data Streams

New data arrives in structured batches or real-time streams. The system must identify and validate incoming data before feeding it into the learning pipeline.


aws s3 cp s3://data-ingest/2024-06-15-batch.json /tmp/batch.json

# Validate schema using JSON Schema
jq -e '.timestamp? and .user_id? and .action? and .label? and .confidence?' /tmp/batch.json
# Exit code 0: valid; 1: invalid

# Register the batch with metadata
curl -X POST https://ml-api/ingest \
  -H "Content-Type: application/json" \
  -d '{
    "batch_id": "2024-06-15",
    "source": "user-activity-logs",
    "schema_version": "v2.1",
    "timestamp": "2024-06-15T08:00:00Z",
    "size_bytes": 1438210,
    "num_records": 12345,
    "expected_labels": ["click", "purchase", "view", "add_to_cart"]
  }'

Data ingestion fails silently if the schema_version does not match the registered schema in the registry. The system logs a schema_mismatch error with expected, actual, and diff fields, and places the batch in staging/schema_mismatch for manual review.

Prepare Data for Learning

Before training, data must be cleaned, transformed, and versioned. The system uses a standard pipeline of transformations applied via configuration.

# config/data-prep.yaml
preprocessing:
  - name: normalize_timestamp
    type: timestamp
    input_column: "timestamp"
    output_column: "ts_epoch"
    format: "ISO8601"
    timezone: "UTC"

  - name: encode_categorical
    type: one_hot
    columns:
      - "category"
      - "device_type"
    output_prefix: "cat_"
    min_frequency: 5

  - name: impute_missing
    type: median
    columns:
      - "session_duration"
      - "page_views"
    strategy: "median"
    fill_value: null

  - name: filter_outliers
    type: iqr
    columns:
      - "revenue"
      - "time_on_site"
    multiplier: 1.5
    drop_outliers: true

The pipeline reads a batch from a data store and writes the processed output to a versioned dataset. Each transformation is idempotent and logged in a transform_log table:

CREATE TABLE transform_log (
  id SERIAL PRIMARY KEY,
  batch_id VARCHAR(32) NOT NULL,
  transform_name VARCHAR(64) NOT NULL,
  start_time TIMESTAMPTZ,
  end_time TIMESTAMPTZ,
  input_rows BIGINT,
  output_rows BIGINT,
  metrics JSONB,
  status TEXT CHECK (status IN ('success', 'failed', 'skipped')),
  error TEXT
);

When a transformation fails, the system logs the error in transform_log and sends a message to a failure queue. A worker process consumes the queue and retries failed steps with exponential backoff.

Train Incrementally

The core loop of continual learning: update the model using new data while retaining knowledge from prior training.

# Train a model incrementally using a pre-configured pipeline
ml-train \
  --model-id "click-prediction-v3" \
  --batch-id "2024-06-15" \
  --strategy "incremental" \
  --learning-rate 0.001 \
  --epochs 5 \
  --warmup-epochs 2 \
  --loss-function "focal" \
  --weight-decay 0.01 \
  --checkpoint-dir "/models/checkpoints/v3" \
  --data-version "2024-06-15-v2" \
  --resume-from "2024-06-15-v1"

# Output: training logs with metrics at each epoch
{
  "epoch": 1,
  "train_loss": 0.42,
  "val_loss": 0.39,
  "accuracy": 0.88,
  "f1": 0.86,
  "memory_usage_mb": 4500
}

The --strategy "incremental" flag enables a specific training regime: the model updates weights using only the new batch, with a small learning rate and a weight decay that penalizes changes to prior weights. The system tracks model versions in a models table:

CREATE TABLE models (
  id VARCHAR(64) PRIMARY KEY,
  version VARCHAR(32) NOT NULL,
  base_model_id VARCHAR(64),
  training_batch_id VARCHAR(32),
  trained_at TIMESTAMPTZ,
  metrics JSONB,
  status TEXT CHECK (status IN ('training', 'ready', 'failed', 'deploying')),
  checkpoint_path TEXT,
  created_at TIMESTAMPTZ
);

The system automatically creates a new versioned model if the new training improves the validation loss by more than 0.01 over the previous version. Otherwise, it marks the model as candidate but does not promote it.

Evaluate and Validate

Before deployment, the system evaluates the new model against a held-out validation set and compares it to the previous version.

# Evaluate a model against a validation dataset
ml-eval \
  --model-id "click-prediction-v3" \
  --version "2024-06-15-v2" \
  --dataset-id "validation-2024-05" \
  --output-format "json" \
  --metrics "accuracy", "precision", "recall", "f1", "auc"

# Response
{
  "model_id": "click-prediction-v3",
  "version": "2024-06-15-v2",
  "dataset_id": "validation-2024-05",
  "metrics": {
    "accuracy": 0.894,
    "precision": 0.871,
    "recall": 0.862,
    "f1": 0.866,
    "auc": 0.915
  },
  "confusion_matrix": [
    [1243, 312],
    [205, 1330]
  ],
  "time_taken_ms": 1842,
  "memory_usage_mb": 3600
}

Evaluation fails if the dataset is not registered or if the model version does not exist. The evaluation service checks for missing_data, schema_mismatch, and outlier_in_data conditions, logging them in a evaluation_logs table with a reason field.

Deploy and Serve

The system promotes a model to production if evaluation meets criteria and activates it via a canary deployment.

# Deploy a model to production with canary rollout
ml-deploy \
  --model-id "click-prediction-v3" \
  --version "2024-06-15-v2" \
  --strategy "canary" \
  --canary-percentage 0.3 \
  --traffic-split "uniform" \
  --rollout-duration "PT2H" \
  --monitoring-params "latency", "error_rate", "throughput"

# Update model registry
UPDATE models
SET status = 'deploying', deployment_started = NOW()
WHERE id = 'click-prediction-v3' AND version = '2024-06-15-v2';

The deployment triggers a series of health checks: the model must respond within 200ms, return valid JSON, and have an error rate below 5%. During rollout, the system logs deployment_event records:

{
  "event_type": "deployment_started",
  "model_id": "click-prediction-v3",
  "version": "2024-06-15-v2",
  "canary_percentage": 30,
  "rollout_duration": "PT2H",
  "started_at": "2024-06-15T09:15:32Z",
  "status": "in_progress"
}

If a canary instance fails, the system halts rollout and logs deployment_failed with details on which endpoint, metric, or response format failed.

Failure Modes and Sharp Edges

Silent Data Drift

The system assumes that incoming data follows the same schema and distribution as prior data. When a new column appears or a label shifts, the model adapts poorly.

Failure: A batch arrives with user_country as US, UK, DE, but the model was trained on user_region with values North, South, East, West. The model does not recognize the new region and assigns a default embedding.
Detection: The system computes a feature_drift score using the Kolmogorov-Smirnov test across all numerical features. If the score exceeds 0.2, it triggers a drift_alert in a monitoring system.

Overfitting on Recent Data

With incremental learning, models quickly adapt to recent data but forget older patterns.

Failure: A model trained on 2024 data becomes highly accurate on recent user behavior but performs poorly on users from Q1 2023.
Solution: The system enables elastic_weighting during training: weights are adjusted based on the age of each sample, with older samples receiving higher influence. The --elastic-weighting flag activates a log_decay schedule.

Checkpointing and Versioning Confusion

The system uses model checkpoints for both training and serving, but the two formats differ.

Failure: A model is trained with checkpoint-format: "pytorch", but the serving engine expects tensorflow format. The deployment fails silently, returning model_load_error with expected_format and actual_format.
Resolution: The system includes a convert_checkpoint step that runs on-demand, with a --from-format and --to-format flag. The conversion is idempotent and logs conversion_stats with input_size, output_size, time_taken.

Model Comparison and Versioning

When evaluating models, the system compares versions based on a baseline and delta metric.

Failure: Two models are evaluated, but the system compares them using accuracy only, missing a subtle difference in recall that matters for a downstream system.
Solution: The system requires a comparison_config.json file that defines which metrics to compare, how to weight them, and thresholds for success.

{
  "baseline": "click-prediction-v2",
  "metrics": [
    {
      "name": "f1",
      "weight": 0.6,
      "threshold": 0.01
    },
    {
      "name": "auc",
      "weight": 0.4,
      "threshold": 0.005
    }
  ],
  "require_stable": true,
  "max_drift": 0.05
}

The require_stable flag ensures that all metrics have converged (variation below threshold) before accepting the model.

The Hidden Cost of Warmup

The --warmup-epochs flag in training is often misunderstood.

Failure: A model is trained with 2 warmup epochs, but the warmup is not applied during inference. The model’s early predictions are inaccurate.
Solution: The system enforces that warmup epochs are applied not just during training but also during inference. During deployment, it automatically adds a warmup phase to the model server, where it processes a batch of input data before serving.

Monitoring and Feedback

Health Checks

The system periodically checks the health of all deployed models.

# Health check for a model
curl -X GET https://model-server/health?model=click-prediction-v3&version=2024-06-15-v2

Response:

{
  "model_id": "click-prediction-v3",
  "version": "2024-06-15-v2",
  "status": "healthy",
  "uptime_minutes": 142,
  "last_evaluated": "2024-06-15T10:30:00Z",
  "metrics": {
    "avg_latency_ms": 187,
    "error_rate": 0.021,
    "throughput_requests_per_sec": 234
  },
  "drift_detected": true,
  "outlier_in_data": [
    "user_country",
    "revenue"
  ],
  "warnings": [
    "low_memory_usage",
    "high_latency_in_q2"
  ]
}

If error_rate exceeds 0.03, the system triggers a model_health_alert and starts a new training job with the latest data.

Feedback Loop and Retraining Triggers

The system collects feedback from production and uses it to trigger retraining.

{
  "feedback_id": "fb-2024-06-15-001",
  "model_id": "click-prediction-v3",
  "version": "2024-06-15-v2",
  "input": {
    "user_id": 12345,
    "timestamp": "2024-06-15T11:20:00Z",
    "action": "click",
    "context": { "page": "product", "category": "electronics" }
  },
  "prediction": {
    "click_probability": 0.87,
    "label": "purchase"
  },
  "user_feedback": {
    "actual_label": "purchase",
    "confidence": 0.9,
    "notes": "User clicked but didn't buy. Expected a purchase."
  },
  "timestamp": "2024-06-15T11:22:15Z"
}

Feedback is ingested via a feedback_queue. When the queue reaches 1000 entries, the system triggers a retrain job with --feedback-based strategy, which uses feedback labels as additional training data and adjusts the loss function to prioritize misclassified examples.

Lifecycle Management

The system tracks the full lifecycle of a model:

Training: training, training_failed, training_completed
Evaluation: evaluated, evaluation_failed, evaluation_passed
Deployment: deploying, deployed, deployment_failed, canary_rolled_out
Monitoring: model_health_alert, drift_detected, outlier_in_data

Each state change is logged with metadata, and the system uses these events to generate a model_lifecycle view, showing the path from initial training to production and the reasons for any failure.

Summary

Continual learning systems are not just about retraining models. They are about orchestrating data, training, evaluation, and deployment into a cohesive loop that adapts to changing conditions. The system succeeds when data drifts, labels arrive late, and new features emerge. It fails when updates are silent, models overfit, and versioning is inconsistent. The key is not just the commands and flags but the patterns: how data is ingested, how models are evaluated, how deployments are rolled out, and how failures are detected and resolved. The system is defined by its data flow, its metadata, and its failure modes—not by a product’s name.

This page was rewritten on 15 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.