Model Performance Analysis and Root Cause Analysis Questions

Techniques for diagnosing and troubleshooting production ML models, including monitoring metrics such as accuracy, precision, recall, ROC-AUC, latency and throughput; detecting data drift, feature drift, data quality issues, and model drift. Covers root-cause analysis across data, features, model behavior, and infrastructure, instrumentation and profiling, error analysis, ablation studies, and reproducibility. Includes remediation strategies to improve model reliability, performance, and governance in production systems.

EasyTechnical

60 practiced

Given a confusion matrix from 10,000 predictions:

TP = 90, FP = 10, FN = 910, TN = 8,990

Compute accuracy, precision, recall, and F1. Interpret what these metrics indicate about model behavior and practical consequences in production.

MediumTechnical

70 practiced

Design an A/B test (randomized online experiment) to evaluate a retrained model against the production model. Specify the primary metric tied to business impact, secondary metrics, sample size calculation approach, traffic split and bucketing strategy (user-level vs session-level), and how to handle multiple comparisons or peeking.

Sample Answer

Goal: test whether the retrained model improves business outcomes vs the current production model without introducing regressions.

Primary metric (business tie): incremental conversion rate (or revenue per user/session depending on product). Choose the metric that directly maps to revenue or retention (e.g., daily active user conversion to paid plan; or incremental ARPU over a 7‑day window).

Secondary metrics:- Model-specific metrics: prediction calibration, false positive/negative rates, AUC.- User-impact metrics: engagement (session length), retention at 7/30 days.- Safety/QA metrics: error rate, latency, CPU/memory usage.- Business-guardrails: churn, support tickets, refund rate.

Sample-size calculation:- Decide minimum detectable effect (MDE) on the primary metric (e.g., 2% relative lift or absolute delta 0.5%).- Use baseline conversion p0, desired power (typically 80–90%), alpha (0.05 two-sided), and standard formula for two-proportion z-test (or t-test for continuous metric). Add inflation for clustering (design effect) if bucketing at user-level with repeated measures.- Example formula for proportions: n_per_group = [ (Z_{1-α/2}√(2p̄(1−p̄)) + Z_{power}√(p1(1−p1)+p2(1−p2)))² ] / (p1−p2)².- Add 10–20% buffer for loss-to-follow-up and QA exclusion.

Traffic split & bucketing:- Use user-level randomization (not session-level) to avoid cross-contamination and leakage for user-affecting models (recommendation, personalization). Assign stable bucket IDs (hashed user_id → bucket).- 50/50 split is standard for maximum power; if riskier, start with 10/90 ramp: e.g., quick internal 1%/1% for smoke, then 10/10, then full 50/50 once stable.- Persist assignment for duration of experiment and for post-experiment rolling analysis window (e.g., 30 days).

Handling multiple comparisons / peeking:- Pre-register analysis plan: primary metric, statistical test, endpoints, stopping rules.- Control Type I error: use alpha=0.05 for primary metric only; adjust secondary metrics interpretively (no formal claims) or apply FDR/BH correction when testing multiple hypotheses.- Avoid continuous peeking; use group sequential methods (e.g., O’Brien–Fleming) or alpha spending functions if interim looks are needed. Alternatively, use pre-specified fixed checkpoints.- Use sequential testing libraries (e.g., always-valid p-values, MAB-safe tests) if frequent looks are unavoidable.- Report confidence intervals and Bayesian credible intervals as complementary information.

Monitoring & rollout:- Real-time monitoring of guardrail metrics; automatic rollback if metric breach threshold crossed.- Post-experiment: run heterogeneity analysis (by segment, device, geography), check randomization balance, run sanity checks (sample sizes, exposure rate), and validate no instrumentation bias.- If positive with robustness checks, rollout gradually with continued monitoring.

This design balances statistical rigor with operational safety and ties directly to business impact.

HardTechnical

63 practiced

You must define SLAs/SLOs for a prediction API balancing latency (p95 < 200ms), availability (99.9%), and model accuracy (precision >= 0.85 on a critical class). Explain how you would set error budgets, alerting tiers, automated throttling/fallback strategies, and communication/compensation policies in case of breaches.

Sample Answer

High-level strategy: treat latency, availability and accuracy as three independent SLOs with a shared error budget policy and clear remediation tiers. Measure on rolling 30‑day windows and compute burn rate to decide automated vs. human actions.

SLO definitions & error budgets- Latency SLO: p95 < 200ms. Error if a request’s latency >200ms. Error budget = allowed fraction 0.1% of requests per 30 days (i.e., 99.9% of requests must meet p95).- Availability SLO: 99.9% (monthly). Error budget = 0.1% downtime ≈ 43.2 minutes/month.- Accuracy SLO (critical class): precision ≥ 0.85 over a rolling 24‑hour window (or 30 days for business reporting). Error budget = allow precision to drop to 0.84 for up to N hours per window (set conservatively, e.g., 1% time).

Alerting tiers and runbooks- Info/Diagnostic (burn rate < 2x): Slack/monitoring dashboards, daily digest. Actions: analyze logs, check feature drift dashboards, schedule investigation.- Warning (burn rate 2–5x): Pager on-call engineer, automated data collection (samples, model inputs, recent retrain metrics), rerun validation tests.- Critical (burn rate > 5x or crossing availability window): Immediate page + SE/ML lead + SRE. Execute emergency runbook (traffic diversion, rollback, fallback).

Automated throttling & fallback- Circuit breaker by error budget: if latency/availability error budget exhausted or burn rate critical, enable degradations: - Fail open to a deterministic business rule or cached/stale predictions (documented accuracy trade-off). - Serve a smaller, faster model (distilled model) with known precision profile. - Rate-limit non-critical traffic (batch or lower-priority users), keeping critical flows prioritized.- Graceful degradation: return “stale but validated” prediction with metadata (timestamp, model id, confidence) and telemetry.- Canary/Shadowing: always shadow new models; when accuracy SLO degrades, divert shadow traffic back to last stable model or rollback via feature-flag.

Detection & root cause- Continuous checks: feature-distribution drift, label feedback lag, input schema validation, upstream latency.- Automated retrain triggers only if labels are reliable; otherwise quarantine data and require human review.

Communication & compensation- Internal: incident channel, incident timeline, owner, mitigation steps; blameless postmortem within 72 hours with action items and owners.- External: status page with SLA dashboard, incident notifications for customers when availability/accuracy SLO breached beyond warning tier. Provide ETA for mitigation and follow-up report.- Compensation policy: automatic pro-rata service credit if availability <99.9% for the monthly billing cycle exceeding a threshold (e.g., >1 hour total downtime beyond budget). For accuracy breaches impacting business outcomes, offer negotiated remediation (free credits, expedited retraining or manual review) tied to quantified customer impact. All compensation thresholds and processes documented in SLA.

Why this works- Clear quantitative SLOs and error budgets enable automated, predictable responses rather than ad‑hoc firefighting.- Tiered alerts avoid noise while ensuring critical breaches get engineering attention.- Fallbacks preserve availability while minimizing business impact; explicit trade-offs keep customers informed and protected.- Postmortems and compensation close the loop and build trust.

EasyTechnical

51 practiced

Explain shadow testing (dark launch) for validating a new ML model. How does running the candidate model in shadow mode help with performance analysis and root-cause detection before sending live traffic? Which metrics should you compare between shadow and baseline runs?

Sample Answer

Situation: When preparing to deploy a new ML model, I run it in shadow (dark launch) mode—receiving a copy of live requests but not affecting production decisions—to validate behavior before switching traffic.

How shadow testing helps:- Safe realism: the candidate sees real inputs (including rare edge cases) and exposes mismatches that synthetic tests miss.- Performance profiling: measures inference latency, CPU/GPU/memory use, and throughput under production load, identifying resource bottlenecks.- Behavioral comparison and root-cause detection: by logging paired outputs (baseline vs candidate) for each request, you can compute per-request deltas, slice analysis (user segments, feature ranges), and trace back to features or input patterns causing regressions. Storing contextual logs and sample inputs enables replay for debugging and model explainability tools to inspect why predictions diverged.

How to run it (concise steps):- Mirror production requests to candidate model synchronously or asynchronously.- Never let candidate responses affect user-facing systems.- Persist timestamps, inputs, baseline and candidate outputs, prediction confidences, and resource metrics.- Run automated checks and alerts on divergence thresholds; sample and replay failures to dev pipelines.

Key metrics to compare (baseline vs shadow):- Prediction-level: - Prediction distribution shifts (class probabilities, score histograms) - Top-k accuracy / precision / recall / F1 (if labels available eventually) - Confusion matrix / per-class error rates, false positives/negatives - Calibration (reliability diagrams, Brier score) - Confidence / entropy changes and % low-confidence predictions- Latency & reliability: - P50/P95/P99 inference latency, tail latency, error rates, timeouts - Throughput and request drop/failure counts- Resource & cost: - CPU/GPU utilization, memory, I/O, cost per request- Data/robustness: - Feature importance shifts, input covariate drift, distributional distance (KL, JS, population stability index)- Business and downstream: - Proxy business metrics (e.g., click-through, conversion uplift, fraud alerts) from a delayed ground-truth pipeline or shadow-analysis heuristics

What I watch for and actions:- Small global metric differences warrant deeper slice analysis. Large regressions or tail latency increases trigger rollback of candidate rollout.- Use alerts for delta thresholds (e.g., >2% increase in false positives, >50ms P95 latency). Reproduce failures by replaying logged requests, inspect features, model explainability outputs, and iterate on model or preprocessing.

Result: Shadow testing provides realistic, low-risk validation—catching correctness, performance, and operational issues early—so when the model goes live you’ve minimized surprises and regression risk.

MediumTechnical

60 practiced

Explain how you would use SHAP values to perform root-cause analysis when a model's error rate increases sharply for a particular user segment. Describe the steps to compute, aggregate across the segment, compare to baseline, and caveats when interpreting SHAP changes.

Sample Answer

Situation: The model’s error rate has jumped for a specific user segment (e.g., users in Region X). I would use SHAP to find which features’ contributions changed for that segment versus baseline and identify likely root causes.

Steps:1. Compute instance-level SHAP- Use the same explainer used in production (TreeExplainer/DeepExplainer/KernelExplainer) and compute SHAP values for: (a) all instances in the failing segment, (b) a baseline set (e.g., historical population or recent non-failing users).2. Aggregate across the segment- Compute metrics per feature: mean(SHAP), mean(|SHAP|), median, and the sign proportion (fraction positive vs negative). Also capture distribution (violin/histogram) to see heterogeneity.- Optionally compute interaction SHAP for top features to detect feature-pair effects.3. Compare to baseline- For each feature compute delta = metric_segment − metric_baseline. Rank features by change in mean(|SHAP|) and change in signed mean to see which features increased influence or flipped direction.- Run statistical tests (bootstrap CIs, permutation test, or t-test if assumptions hold) to verify significance and compute effect sizes.4. Triangulate with data- Check feature distributions in the segment vs baseline (P(feature|segment) drift) and label distribution changes. Map SHAP shifts to input distribution shifts or to model response shifts.5. Prioritize actions- If a feature’s SHAP importance rose because its values shifted into a regime the model hadn’t seen, consider data augmentation, reweighting, or feature engineering. If SHAP sign flipped while input distribution unchanged, inspect model logic, recent model updates, or label noise.

Caveats when interpreting SHAP changes:- SHAP is descriptive, not causal: a change in SHAP points to association with model output, not that the feature caused errors.- Background/baseline choice matters: SHAP values depend on the background dataset; compare using consistent baseline or test sensitivity to different baselines.- Correlated features & interactions: SHAP can apportion importance across correlated inputs but may produce unstable attribution; use interaction SHAP and conditional analyses.- Sample size and variance: small segments yield high variance; use bootstrap CIs.- Model changes and explainer consistency: if model version changed, recompute SHAP with the same explainer settings.- Computation & approximation: kernel approximations may be noisy; prefer exact explainers for trees or validated approximations.

This process links SHAP-driven signals to data drift and model behavior, enabling prioritized, testable remediation (relabeling, retraining, feature fixes, or targeted monitoring).

Unlock Full Question Bank

Get access to hundreds of Model Performance Analysis and Root Cause Analysis interview questions and detailed answers.

Join thousands of developers preparing for their dream job.