Evaluate, Interpret, and Decide on Deployment

40 min

Classification and Thresholds

Learning goal: understand probability scores, thresholds, confusion matrix, precision, recall, specificity.

A classification model does not output "yes" or "no": it outputs a probability score between 0 and 1. Turning that into an actionable decision requires choosing a threshold: a score above the cutoff is treated as "will exceed capacity." Changing the threshold does not change the model itself, but it dramatically changes the trade-off between precision and recall.

from sklearn.metrics import precision_score, recall_score

proba = model_clf.predict_proba(valid[feature_cols])[:, 1]
for threshold in [0.3, 0.5, 0.7]:
    pred = (proba >= threshold).astype(int)
    precision = precision_score(valid["target_binary"], pred)
    recall = recall_score(valid["target_binary"], pred)
    print(threshold, round(precision, 3), round(recall, 3))

Before choosing a threshold, write down the real cost of each type of error: missing a site that really will exceed capacity (a False Negative) may mean degraded service or emergency reallocation cost; flagging a site that would have been fine (a False Positive) wastes the resources spent pre-allocating. Once both costs are quantified, choosing a threshold becomes a decision that can be reviewed, not a feeling.

• Choosing a threshold because a number 'feels right,' without comparing it to the actual business cost
• Applying the same threshold to every site without checking whether each site's cost structure is actually the same
• Reporting only accuracy without also reporting precision and recall at the chosen threshold
• Not re-checking fairness across group_attribute subgroups after the threshold is chosen

Key takeaway: Completing the steps is not enough; the result must be verifiable, reproducible, and explainable.

40 min

Overfitting, Cross-Validation, and Tuning

Learning goal: use CV on training data; keep test untouched; limit tuning complexity.

A colleague keeps raising model complexity: training-set performance keeps improving, but validation performance starts getting worse. This is a classic overfitting signal: the model has memorized noise in the training data instead of learning patterns that generalize to new data. Cross-validation (CV) lets you evaluate different settings more robustly while using only the training data.

from sklearn.model_selection import TimeSeriesSplit, cross_val_score

tscv = TimeSeriesSplit(n_splits=5)
for depth in [2, 4, 8]:
    scores = cross_val_score(make_model(max_depth=depth), train[feature_cols], train["target_numeric"], cv=tscv, scoring="neg_mean_absolute_error")
    print(depth, round(-scores.mean(), 2))
# The test set is never touched anywhere in this tuning process

Beyond adjusting model complexity, common responses to overfitting include adding regularization, reducing the number of features, or adding more training data. The value of cross-validation is that it estimates a more robust performance range from several splits, rather than depending on whatever luck a single split happened to produce.

• Looking only at the average CV score without checking whether variance across folds is too large
• Using a non-time-aware KFold split on time-ordered data, leaving leakage inside each fold
• Running unlimited tuning attempts, continuing until the validation score 'happens' to improve
• Accidentally using the test set somewhere during tuning (for example, a typo that referenced the test variable)

Key takeaway: Completing the steps is not enough; the result must be verifiable, reproducible, and explainable.

35 min

Feature Importance, Interpretation, and Fairness

Learning goal: treat importance as predictive contribution, not causality; inspect subgroup error.

The model's feature importance shows features_staffing_level as the top predictor, and a colleague immediately concludes: "So increasing staffing will reduce case volume." Feature importance only describes how much a variable contributes to the model's predictions: it does not prove that changing that variable would change the real-world outcome. This is the same trap as correlation versus causation.

importances = pd.Series(model.feature_importances_, index=feature_cols).sort_values(ascending=False)
print(importances.head())

# Check whether error is consistent across group_attribute subgroups
valid_pred = model.predict(valid[feature_cols])
valid.assign(abs_error=(valid["target_numeric"] - valid_pred).abs()).groupby("group_attribute")["abs_error"].mean()

The way feature importance is computed also affects the conclusion: rankings from a tree model's built-in importance, permutation importance, and SHAP values sometimes disagree. When reporting importance, state which method was used, and treat it as 'how much the model currently relies on this variable,' not 'how important this variable is in the real world.'

• Treating a high-importance feature as causal evidence and publicly claiming 'changing it will change the outcome'
• Looking only at the overall importance ranking without checking whether it is consistent across subgroups
• Using only one importance method without cross-checking whether the result is stable
• Drawing conclusions from subgroup error checks on too small a sample without noting the uncertainty

Key takeaway: Completing the steps is not enough; the result must be verifiable, reproducible, and explainable.

40 min

Error Analysis, Drift, and Deployment Decisions

Learning goal: inspect where errors occur, costs, drift risk, monitoring and human fallback.

Three months after launch, a model's performance has quietly degraded, but nobody noticed because the team checked the offline score once and deployed it, with no monitoring afterward. This is the most common consequence of "good test performance means auto-deploy": real-world data distributions shift over time (drift), and a model that performed well once is not guaranteed to keep performing well.

A monitoring plan needs to answer at least three questions: which metric detects degraded performance (for example, a tracked MAE or false-alarm rate), how often it is checked (daily, weekly), and who is responsible for intervening when the metric looks abnormal. 'Monitoring' that does not answer these three questions often exists only on paper, with nobody actually watching it.

valid_pred = model.predict(valid[feature_cols])
errors = (valid["target_numeric"] - valid_pred).abs()
high_demand = valid["target_numeric"] > valid["target_numeric"].quantile(0.9)
print("Average error, high-demand cases:", round(errors[high_demand].mean(), 2))
print("Average error, other cases:", round(errors[~high_demand].mean(), 2))
# If high-demand cases have much larger error, the model is least reliable exactly when accuracy matters most

• Checking overall error only once before deployment without checking whether it concentrates in specific situations
• Not writing down the business cost of a miss versus a false alarm, leaving the threshold or decision basis opaque
• Monitoring metrics with no clear anomaly threshold, so something 'looking off' never triggers any action
• No human fallback mechanism, so an anomaly can only wait for the next scheduled retraining

Key takeaway: Completing the steps is not enough; the result must be verifiable, reproducible, and explainable.

55 min

Independent Lab: Predictive Analytics Use Case

Learning goal: independently deliver baseline, model, evaluation, error analysis, limitations, and a go/no-go decision rubric.

• Go to the DS 201 practice page
• PreviewDownload the practice dataset (with challenges)
• Download the Independent Lab starter notebook
• PreviewDownload the data dictionary (Traditional Chinese)
• PreviewDownload the data dictionary (English)

1. 1Define the prediction problem
   Write down the prediction unit, target (regression or classification), decision, and features available at prediction time.
2. 2Build a baseline
   Build at least one naive/majority/mean baseline for your chosen target.
3. 3Split correctly and train
   Split train/validation/test by time, train a model, and tune on validation.
4. 4Evaluate and compare
   Compare the model against the baseline using MAE/RMSE or precision/recall, and examine the threshold or complexity trade-off.
5. 5Error analysis
   Check whether error concentrates by group_attribute or demand range, and identify at least one pattern worth investigating further.
6. 6Make a deployment decision
   Based on performance, cost, drift risk, and monitoring feasibility, write a reasoned go/no-go decision without claiming universal validity.

• A clearly stated prediction problem and decision
• At least one baseline and its performance
• The correct time-based split and a record of the leakage check
• Model performance compared to baseline, including at least two metrics
• At least one subgroup- or situation-level error analysis
• At least one limitation and a deployment decision (covering cost, drift, monitoring, and human fallback)
• A record of any AI assistance used, and what you personally verified

• A deployment decision must state the assumed costs and monitoring approach, not just a bare 'go' or 'no-go' conclusion
• When a subgroup error analysis is based on a very small sample, say so instead of drawing a firm conclusion
• The limitations field in the Model Card must be specific, such as 'error is less stable in subgroups with fewer than N rows,' rather than a vague 'there may be limitations'

Key takeaway: Completing the steps is not enough; the result must be verifiable, reproducible, and explainable.