Comprehensive coverage of how to measure, validate, debug, and monitor machine learning model performance across problem types and throughout the development lifecycle. Candidates should be able to select and justify appropriate evaluation metrics for classification, regression, object detection, and natural language tasks, including accuracy, precision, recall, F one score, receiver operating characteristic area under the curve, mean squared error, mean absolute error, root mean squared error, R squared, intersection over union, and mean average precision, and to describe language task metrics such as token overlap and perplexity. They should be able to interpret confusion matrices and calibration, perform threshold selection and cost sensitive decision analysis, and explain the business implications of false positives and false negatives. Validation and testing strategies include train test split, holdout test sets, k fold cross validation, stratified sampling, and temporal splits for time series, as well as baseline comparisons, champion challenger evaluation, offline versus online evaluation, and online randomized experiments. Candidates should demonstrate techniques to detect and mitigate overfitting and underfitting including learning curves, validation curves, regularization, early stopping, data augmentation, and class imbalance handling, and should be able to debug failing models by investigating data quality, label noise, feature engineering, model training dynamics, and evaluation leakage. The topic also covers model interpretability and limitations, robustness and adversarial considerations, fairness and bias assessment, continuous validation and monitoring in production for concept drift and data drift, practical testing approaches including unit tests for preprocessing and integration tests for pipelines, monitoring and alerting, and producing clear metric reporting tied to business objectives.
EasyTechnical
85 practiced
Provide three quick unit tests you would write for a preprocessing pipeline used in model training to prevent evaluation leakage and ensure reproducibility. Describe what each test checks.
Sample Answer
**Overview (why these tests matter)** As an applied scientist I write tests that guard against data leakage and ensure deterministic preprocessing so experiments are reproducible and comparable.1) Deterministic transform seed test - What it checks: running the preprocessing pipeline twice with the same random seed and same input yields identical outputs (features, ordering, metadata). - Example test (pytest-style):
- Why: prevents hidden nondeterminism (shuffling, random imputations) that would invalidate experiment comparisons.2) Train-only fit test (no label leakage) - What it checks: transformer fit must only use training features, not labels or test data. Specifically, applying a scaler/encoder fit on full dataset should fail the guard. Test ensures fit receives training subset only. - Example:
python
def test_fit_only_on_train():
with pytest.raises(LeakageError):
preprocess.fit_on_full_data(X_full, y_full) # should be disallowed
- Why: ensures statistics (means, encodings) are computed only from training to avoid optimistic evaluation.3) Schema & missing-value stability test - What it checks: pipeline preserves expected schema and handles missing values consistently (e.g., imputer fills NaNs with stored training value). Test validates column names, dtypes, and that imputations match saved training-imputer state. - Example:
python
def test_schema_and_imputation():
p = preprocess.fit(train)
out = p.transform(val_with_nans)
assert list(out.columns) == expected_columns
assert (out.loc[missing_idx, "age"] == p.imputer.statistics_['age']).all()
- Why: prevents silent feature shifts and ensures downstream models see stable inputs.
EasyTechnical
70 practiced
Define perplexity for a language model. Provide intuition about what a lower vs higher perplexity indicates and its limitations when comparing models on different tokenization schemes or vocabularies.
Sample Answer
**Definition & formula**Perplexity measures how well a language model predicts a sequence. For a test set of tokens t1..tN, perplexity is exp of average negative log-likelihood:
Intuition: perplexity is the “effective branching factor” — the average number of choices the model is uncertain between at each step. It is equivalent to 2^{cross-entropy} (with log base 2).**Lower vs higher**- Lower perplexity → model assigns higher probability to true next tokens → better predictive fit.- Higher perplexity → model is more uncertain / makes poorer predictions.- In practice, a drop in perplexity usually correlates with better downstream text quality but not perfectly.**Limitations across tokenizations/vocabularies**- Perplexity depends on token granularity (characters, subwords, words). Finer tokens (chars) change N and typical token probabilities, so raw perplexities are not comparable.- Vocabulary size, splitter behavior (BPE vs unigram) and preprocessing (casing, normalization) alter likelihoods.- To compare models fairly: evaluate with the same tokenizer/vocabulary and test set, or convert to bits-per-character or normalize by characters/words. Also compare on downstream tasks and human evaluation for practical impact.
MediumTechnical
73 practiced
Medium: Provide a practical plan (steps and checks) to detect label noise in a large labeled dataset for a multi-class image classification problem. Include both automated and manual inspection techniques and how you would quantify noise rate.
Sample Answer
**Plan overview**I’d run automated detectors to triage suspect samples, then prioritize manual inspection with an active-learning loop. Quantify noise via sampled relabeling and model-based estimates.**Automated steps & checks**- Train a baseline classifier (augmentation, calibration). Compute per-sample: - low predicted probability for assigned label - high loss or large gradient norm - disagreement across ensemble/checkpoint models - Confident Learning (cleanlab) suspected-label scores- Compute per-class confusion matrix and OOD/near-boundary detection (embedding distance, k-NN).- Cluster embeddings (t-SNE/UMAP + DBSCAN) and flag outliers in each class.**Manual inspection & human-in-the-loop**- Sample top-N flagged and random control samples per class; relabel by 2+ annotators.- Use annotation UI showing model predictions, nearest neighbors, and original metadata.- Resolve disagreements via majority vote or expert adjudication.**Quantifying noise rate**- Let s = number of sampled items, m = items relabeled as incorrect.
text
noise_rate_estimate = m / s
- Provide class-wise rates and confidence intervals (binomial CI).- Cross-check with model-based upper-bound from cleanlab scores and active re-sampling.**Operationalize**- Iteratively retrain after fixing high-impact labels; track validation uplift.- Maintain audit logs, per-class label quality dashboards, and incorporate continuous monitoring and periodic re-annotation.
HardSystem Design
79 practiced
Hard: Describe how you would set up continuous validation (model and data) in CI/CD for ML models to catch performance regressions before deployment. Include automated tests, offline evaluation thresholds, canary testing, data schema checks, and governance/audit requirements.
Sample Answer
**Clarify goals & constraints**I’d ensure CI/CD prevents performance regressions, enforces data quality, and provides auditable decisions. Targets: latency, accuracy/AUC, calibration, fairness metrics, and data schema/feature drift.**High-level pipeline**- Pre-commit: unit tests for feature transformation code, synthetic-data tests.- CI: model training with fixed seed on a preserved validation set; run reproducible evaluation job that stores artifacts (MLflow/Weights & Biases).- CD: gated deploy only if offline thresholds pass; follow with staged canary rollout and monitoring.**Automated tests & offline thresholds**- Tests: training convergence, metric regressions vs. baseline, feature importance sanity, adversarial/robustness unit tests.- Implement thresholds: e.g., delta AUC >= -0.01, calibration error < 0.02, latency < 200ms. Fail build when violated; exceptions require documented review.**Data schema & drift checks**- Use schema validator (TensorFlow Data Validation / Great Expectations) to assert types, ranges, null rates, cardinality.- Drift detection: population/stability tests (KS for numeric, PSI), embedding-based drift for complex features. Trigger alerts and block deploy if severe.**Canary testing & online validation**- Canary: route small % (1–5%) of production traffic to new model; run shadow logging of inputs/labels.- Online metrics: live A/B metrics, alerting on uplift/regression with automatic rollback if metric exceeds thresholds (e.g., 95% CI shows degradation).- Holdback experiments for fairness/regulatory checks.**Governance & audit**- Record model lineage, datasets, hyperparameters, metric snapshots, and approvals in model registry (MLflow).- Require automated and manual approvals for exceptions; store signed approvals and evaluation reports.- Maintain reproducible artifacts, dataset versioning, and tamper-evident logs for compliance.**Trade-offs**- Stricter gates increase safety but slow iteration. Use risk-based gating per model criticality.This design balances automated protection (tests, thresholds, schema/drift) with staged real-world validation (canary + monitoring) and full auditability required for regulated production deployments.
HardTechnical
91 practiced
Hard: You are asked to evaluate adversarial robustness for an image classifier used in a security-sensitive application. Propose an evaluation protocol including threat models, attack methods (white-box/black-box), robustness metrics, defenses to benchmark, and how to report actionable results to engineers and product managers.
Sample Answer
**Brief objective**Define a repeatable, security-oriented evaluation protocol that measures worst-case and realistic adversarial risk for the image classifier and produces actionable recommendations for engineers and PMs.**1) Threat models (explicit)**- Adversary goals: targeted misclassification, untargeted evasion, confidence manipulation.- Adversary knowledge: white-box (full model, gradients), black-box (no gradients, query access), transfer-based (surrogate models), training-data access (poisoning out of scope here).- Constraints: L_inf / L_2 bounded perturbations (specify epsilons tied to perceptual limits, e.g., L_inf = 8/255), physical-world transformations, query budget and real-time constraints.**2) Attack methods to run**- White-box: PGD (multi-step with random start), CW (optimizer-based), AutoAttack (ensemble, high-confidence benchmark).- Black-box: Boundary Attack, NES/score-based, SPSA and transfer attacks from surrogate ensembles.- Physical / distributional: Expectation Over Transformation (EOT) for robustness to imaging variations.- Adaptive attacks: attacks specifically tuned against each defense to detect gradient masking.Run attacks at multiple epsilons and with fixed compute/query budgets; seed runs for reproducibility.**3) Robustness metrics**- Robust accuracy vs clean accuracy curve across epsilons.- Attack success rate (targeted / untargeted).- Minimal perturbation (median/90th percentile) to cause misclassification.- Confidence degradation and calibrated risk (Brier/expected calibration error under attack).- Transferability rate and query-efficiency (queries to succeed).- Time-to-fail and failure modes (which classes, demographics).Report mean ± std over multiple runs.**4) Defenses to benchmark**- Baselines: undefended model, adversarially trained (PGD), TRADES.- Certified: randomized smoothing (L_2 certificates), interval bound propagation where feasible.- Heuristics: input preprocessing (JPEG, bit-depth), feature denoising; test adaptive attacks to ensure they are not relying on gradient masking.- Practical mitigations: confidence thresholding, ensemble detectors, monitoring + rollback.**5) Experimental protocol**- Use held-out test set + separate validation for tuning attacks; maintain train/dev/test splits.- Automate attack pipelines, log seeds, hyperparameters, GPU time.- For defenses, run strong adaptive white-box attacks; if defense is stochastic, evaluate with expectation over randomness.- Perform ablation studies: attack strength, epsilon sweep, dataset subsets.**6) Reporting actionable results**To engineers:- Detailed report with robustness curves, per-class confusion under attack, attack recipes (commands/hyperparams) to reproduce, identified failure cases, prioritized remediation (e.g., retrain with adversarial examples for classes X,Y).- Code + CI tests: unit tests that run a lightweight attack (FGSM/short PGD) in PR pipelines.To product managers:- High-level risk summary: clean vs robust accuracy at operational epsilons, likelihood of successful attack under realistic constraints, impact matrix (user harm, fraud, business metrics).- Recommended mitigations and cost/benefit: e.g., deploy randomized smoothing for certificated bounds (adds latency X, reduces clean acc by Y), or enforce confidence thresholds plus human review for high-risk classes.- KPIs to track: robust accuracy target, number of detected adversarial incidents, latency SLA, and monitoring alerts.**7) Validation & pitfalls**- Always run adaptive attacks to avoid false security from gradient masking.- Provide reproducible artifacts (scripts, seeds, Docker images) and automation for periodic re-evaluation as model/data drift occurs.This protocol ensures rigorous, reproducible measurements and ties technical findings to concrete engineering actions and product risk decisions.
Unlock Full Question Bank
Get access to hundreds of Model Evaluation and Validation interview questions and detailed answers.