Day 2 - Bias and Explainability Drift: Monitoring During Operations with Clarify

📌 Key Takeaways

• Clarify computes pre-training data bias, post-training model bias, and prediction explanations (SHAP), and extends them into continuous monitoring in operation.
• The bias drift monitor periodically recomputes post-training bias metrics such as DPPL and DI to track changes in fairness between groups.
• The feature attribution drift monitor watches how much SHAP importance has changed relative to the baseline, without labels.
• In domains where labels arrive late, feature attribution drift is an early warning that sounds before performance degradation does.
• All four monitors share the same skeleton: "baseline → cron schedule → Processing Job comparison → CloudWatch metrics".

The Three Points Where Clarify Attaches

Clarify attaches at three points: before training, after training, and in operation. Think of it as the same bias-metric engine being reused with only the stage changed.

 ① Pre-training (data)     ② Post-training (model)     ③ In operation (endpoint)
 ─────────────────────   ─────────────────────────   ──────────────────────────
  Raw data bias            Prediction bias · SHAP        Bias Drift Monitor
  CI · DPL · KL/JS   ──▶   DPPL · DI · AD          ──▶   Feature Attribution
  (looks at label dist.)   (looks at predictions)        Drift Monitor
        │                       │                         │
        ▼                       ▼                         ▼
   Resample · recollect   Adjust model · thresholds   Detect departure from baseline
                                                          │
                                                  CloudWatch metrics → alarms

Why look at bias and explanation in operation too? A model that was fair at training time can become unfavorable to a particular group if the distribution of incoming data changes. Also, if the importance of the features the model relies on changes over time, that itself is a warning sign that the model's behavior has changed. MLA-C01 ties "responsible AI" and monitoring together to ask about this.

The Two Faces of Clarify: Bias and Explainability

Clarify does two broad things.

Explainability is computed with SHAP (SHapley Additive exPlanations) values. SHAP is a concept from game theory that fairly distributes and quantifies how much each feature pushed the prediction up or pulled it down from the baseline.

💡 Related theory: Among the bias metrics, the ones the exam covers are the pre-training metrics CI (Class Imbalance) and DPL (Difference in Positive Proportions in Labels), and the post-training metrics DPPL (Difference in Positive Proportions in Predicted Labels) and DI (Disparate Impact). The key point is that "pre-training data bias" and "post-training model prediction bias" are looked at separately. The Bias Drift Monitor tracks how far the post-training bias metrics diverge from the baseline during operation.

Bias Metrics - What to Look at When

You do not need to memorize every metric name, but if you keep two axes straight, "does the metric look at labels or at predictions" and "is it a difference or a ratio", the questions get easy.

Even among "post-training bias" metrics, label requirements split. DPPL and DI are computed from predictions alone, so real-time monitoring in operation is possible. Metrics such as AD and RD, which compare accuracy and recall by group, need ground truth. This is why the Bias Drift Monitor is classified as "labels not needed for some".

Feature Attribution Drift - Detecting Changes in Model Behavior Without Labels

Feature attribution drift looks at how much the importance ranking and magnitude of each feature differ from the baseline. The decisive advantage is that no ground truth labels are needed. How much the model relies on each feature can be computed with SHAP from inputs and predictions alone.

For example, if a credit scoring model weighted "income" most heavily at training time but in operation the contribution of "postal code" suddenly spikes, that is a strong warning that "the model's behavior has changed", even without knowing the answers.

 Baseline SHAP importance      In-operation SHAP importance
 ────────────────────────      ────────────────────────────
  Income        ████████ 0.41    Income        ███ 0.15
  Credit score  █████ 0.27       Postal code   ███████ 0.34   ← rank reversal
  Txn count     ███ 0.18         Credit score  ████ 0.22
  Postal code   ██ 0.09          Txn count     ███ 0.17
                                     │
                                     ▼
             Score how much the importance "ranking" is disturbed → violation if it exceeds the threshold

from sagemaker.model_monitor import ModelExplainabilityMonitor
from sagemaker.clarify import SHAPConfig, ModelConfig, ExplainabilityAnalysisConfig
 
explainability_monitor = ModelExplainabilityMonitor(
    role=role, instance_count=1, instance_type="ml.m5.xlarge",
)
shap_config = SHAPConfig(
    baseline="s3://my-bucket/shap-baseline.csv",
    num_samples=100,
    agg_method="mean_abs",     # aggregate importance as the mean absolute SHAP per feature
)
explainability_monitor.suggest_baseline(
    data_config=...,           # input data configuration
    model_config=ModelConfig(model_name="my-model", instance_type="ml.m5.xlarge",
                             instance_count=1),
    explainability_config=shap_config,
)

• baseline is the reference point (reference data) for the SHAP computation. Against this reference, it measures how much each feature moved the prediction.
• Raising num_samples stabilizes the SHAP estimate, but the Processing Job's time and cost rise with it.
• agg_method="mean_abs" is the mean of absolute values with the sign removed - it means ranking importance by "magnitude of influence, not direction".

The strength of feature attribution drift lies in the "early warning". The model quality monitor has to wait until ground truth accumulates (days to weeks) before it can confirm performance degradation. Feature attribution, by contrast, is computed immediately without answers, so before performance actually drops it gives a leading signal that "the model has started relying on different features". It is especially valuable in domains where label collection is slow.

Bias Drift Monitor - Continuously Watching Fairness

The bias drift monitor periodically recomputes post-training bias metrics (e.g., DPPL, DI) on operational data to track whether bias has grown relative to the training-time baseline. You must specify the sensitive attribute (facet) and the positive outcome.

from sagemaker.model_monitor import ModelBiasMonitor
from sagemaker.clarify import BiasConfig
 
bias_monitor = ModelBiasMonitor(role=role, instance_count=1, instance_type="ml.m5.xlarge")
bias_config = BiasConfig(
    label_values_or_threshold=[1],        # value of the positive (favorable) outcome
    facet_name="gender",                   # sensitive attribute (facet)
    facet_values_or_threshold=[0],         # group to compare
)

• facet: The sensitive attribute column on which fairness is judged (gender, age bracket, region, etc.). Which column to treat as the facet is decided by the business and regulation. It is not selected automatically on technical grounds.
• label_values_or_threshold: What to treat as the "favorable outcome". Definitions such as loan approved = 1, rejected = 0.
• Continuous attributes (e.g., age) split the groups with a threshold.

Some bias drift metrics (e.g., DPPL) are computed from predictions alone without ground truth, so some monitoring is possible in operation even without labels.

⚠️ Trap: "Monitor changes in the model's fairness toward a particular demographic group in operation" is the Bias Drift Monitor (Clarify), and "Monitor changes in the importance of each feature in operation" is the Feature Attribution Drift Monitor (Clarify). It is easy to confuse both with the data quality monitor (simple distribution statistics). Data quality catches "the mean of feature X changed", while feature attribution catches "the influence of feature X on predictions changed" - the latter is more directly about model behavior.

The Four Monitors in One Table

This one table covers it right before the exam.

Split them with one sentence each.

# Common flow: Clarify-based monitors are also operated on a schedule in the same way
explainability_monitor.create_monitoring_schedule(
    endpoint_input=predictor.endpoint_name,
    ground_truth_input=None,                  # feature attribution needs no labels
    analysis_config="s3://my-bucket/analysis-config.json",
    output_s3_uri="s3://my-bucket/explain-results/",
    schedule_cron_expression="cron(0 * ? * * *)",   # every hour
)

analysis_config holds the analysis conditions such as the facet, label definition, and SHAP settings. The bias monitor can additionally connect ground_truth_input here to compute label-based metrics as well.

When Clarify Monitors Get Tangled: Symptom → Cause → Action

In the next post, we look at monitoring from the system operations perspective, not model quality - CloudWatch metrics and alarms, endpoint latency and errors, and logging.

📖 Glossary

• SageMaker Clarify: A service that computes bias in data and models and prediction explanations (SHAP). It extends to continuous monitoring in operation.
• SHAP: A value that uses game theory to fairly distribute and quantify how much each feature pushed a prediction up or pulled it down from the reference point.
• facet (sensitive attribute): The reference column on which fairness is judged (gender, age bracket, etc.). Decided by the business and regulation, not by technology.
• Pre-training bias metrics: Bias in the data itself before training. CI (group sample imbalance), DPL (difference in positive proportion of labels by group), and so on.
• Post-training bias metrics: Prediction bias of the trained model. DPPL (difference in predicted positive proportion), DI (its ratio), AD and RD (differences in accuracy and recall), and so on.
• DI (Disparate Impact): The predicted positive proportion of one group divided by that of the other. The closer to 1, the more on par.
• Bias drift monitor: A monitor that periodically recomputes post-training bias metrics to catch worsening fairness relative to the baseline.
• Feature attribution drift monitor: A monitor that watches, without labels, how far the ranking and magnitude of SHAP importance deviate from the baseline.
• Early warning (leading indicator): A signal that sounds before performance degradation is confirmed. Especially valuable in domains where labels arrive late.
• analysis_config: A configuration file holding the Clarify analysis conditions such as the facet, label definition, and SHAP settings.