Model Debugging Workflows
A model with good aggregate metrics can still be badly broken
95% overall accuracy sounds healthy until you discover it's 99% on the majority group and 60% on a minority subgroup, or that it quietly degraded last month because an upstream feature pipeline started silently returning nulls. Aggregate metrics are a starting point for debugging, not an endpoint — a systematic model debugging workflow needs to actively look for the failure modes that a single summary number hides.
Slice-based evaluation: the first and highest-leverage step
Before trusting an overall metric, break it down by meaningful slices: by data source, by time window, by demographic or business segment, by input length or feature value ranges. A model's error rate is almost never uniform across these slices, and the slices with the worst performance are usually where the real product risk concentrates. Tools like sliceline and manual stratified evaluation both aim to surface these automatically rather than relying on a practitioner to guess which slices to check.
import pandas as pd
from sklearn.metrics import accuracy_score, f1_score
def evaluate_by_slice(df, y_true_col, y_pred_col, slice_cols):
rows = []
for col in slice_cols:
for value, group in df.groupby(col):
if len(group) < 20: # skip tiny slices -- unreliable metrics
continue
rows.append({
"slice_feature": col,
"slice_value": value,
"n": len(group),
"accuracy": accuracy_score(group[y_true_col], group[y_pred_col]),
"f1": f1_score(group[y_true_col], group[y_pred_col], average="macro"),
})
report = pd.DataFrame(rows).sort_values("accuracy")
return report
# report = evaluate_by_slice(df, "label", "prediction", ["region", "device_type", "signup_cohort"])
# print(report.head(10)) # worst-performing slices surface at the top
Error analysis: reading the actual misclassified examples
Beyond quantitative slicing, manually reading a sample of the model's worst mistakes — high-confidence errors in particular — is one of the highest-signal debugging activities available. A high-confidence error (the model was very sure and very wrong) usually points to a systematic issue: a mislabeled training example, a feature that's leaking differently at inference time than training time, or a genuine edge case the training distribution never covered. Grouping these qualitatively by root cause (label noise vs. distribution shift vs. missing feature vs. genuinely hard example) turns a pile of individual errors into an actionable fix list.
Train/serving skew is a common silent failure mode
| Debugging technique | Catches | When to run |
|---|---|---|
| Slice-based evaluation | Subgroup performance gaps | Every evaluation, not just once |
| High-confidence error review | Label noise, feature leakage, edge cases | After each retrain |
| Train/serving skew comparison | Pipeline bugs, feature drift | Before and after deployment |
| Learning curve analysis | Underfitting vs. overfitting | During model development |
What's next?
Error analysis naturally raises a more structured question: once you've found where a model fails, how do you systematically categorize and quantify those failure patterns in a repeatable way, rather than relying on ad hoc reading of individual misclassified examples each time?
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.