Model Evaluation and Validation Questions

Precision, recall, specificity, F1, and accuracy (binary classification): definitions:

• Precision = TP / (TP + FP). Of predicted frauds, fraction that are actual fraud. Measures false-alarm rate.
• Recall (a.k.a. sensitivity) = TP / (TP + FN). Of actual frauds, fraction we detect. Measures missed-fraud rate.
• Specificity = TN / (TN + FP). Of actual non-fraud transactions, the fraction correctly left alone. Prioritize it when a false positive on a legitimate customer is expensive: e.g. a system that auto-freezes flagged accounts, where wrongly freezing a real customer's account triggers a costly support escalation and risks losing that customer, so specificity (not just recall on the fraud side) becomes the number the fraud-ops team watches.
• F1 = 2 * (precision * recall) / (precision + recall). Harmonic mean balancing precision and recall; useful when classes are imbalanced.
• Accuracy = (TP + TN) / (TP + FP + TN + FN). Overall fraction correct across both classes. Prioritize it when classes are roughly balanced and the two error types cost about the same, e.g. an internal audit-sampling task where a false positive and a false negative both just cost one analyst-hour to re-check, unlike this heavily imbalanced fraud case where accuracy is the misleading headline number.

Business priority for fraud detection:

• If false negatives (missed fraud) are much more costly than false positives, prioritize recall. Catching fraud reduces direct monetary loss; higher recall may raise false positives (lower precision), which increases investigation cost but is acceptable if business tolerates it.

Example confusion matrix (actual vs predicted):

• True Fraud (positive): 100 cases
• Non-Fraud (negative): 9,900 cases
  Scenario A (conservative threshold → high recall):
• TP=95, FN=5, FP=800, TN=9,100
  Precision = 95/(95+800)=10.6%; Recall=95/100=95%; Specificity = TN/(TN+FP) = 9,100/9,900 ≈ 91.9%; Accuracy = (TP+TN)/Total = (95+9,100)/10,000 = 9,195/10,000 ≈ 92.0%
  Scenario B (strict threshold → high precision):
• TP=60, FN=40, FP=100, TN=9,800
  Precision = 60/(60+100)=37.5%; Recall=60%; Specificity = TN/(TN+FP) = 9,800/9,900 ≈ 99.0%; Accuracy = (TP+TN)/Total = (60+9,800)/10,000 = 9,860/10,000 = 98.6%
  Notice specificity and accuracy stay high (>90%) in BOTH scenarios here: with only 100 actual frauds against 9,900 actual non-frauds, the negative class dominates the denominator for both metrics, so neither one moves much even as precision swings from 10.6% to 37.5% and recall swings from 95% to 60%. That is exactly why specificity and accuracy are the wrong metrics to lead with on this imbalanced a problem, and why the scenario above prioritizes recall/precision instead.

Trade-offs and thresholding:

• Lowering decision threshold increases predicted positives → raises recall, lowers precision.
• Raising threshold decreases predicted positives → raises precision, lowers recall.
• Use precision-recall curve and choose threshold to meet a target recall (business SLA), possibly optimizing a cost function: Cost = C_FN * FN + C_FP * FP.
• Monitor production metrics (precision at required recall, alert volume) and consider using ranked outputs + manual review for top-K risky transactions to balance operational load.

Additional points:

• F1 useful if you want a single balanced metric, but when costs are asymmetric use recall or a weighted metric (Fβ with β>1 emphasizes recall).

Brief framing

For summarization we need both token-level and sequence-level metrics because they capture different failure modes: lexical overlap, fluency, and semantic adequacy. We also need a language-model-based sanity check (perplexity) and a plan for what to do when the numbers and the humans disagree.

Token-level / overlap metrics

• Token overlap (precision/recall/F1 on n-grams): simple, fast; useful for exact matching and extractive summaries but penalizes paraphrase.
• ROUGE (R1/R2/L): recall-oriented n-gram and longest-common-subsequence measures; standard for summarization, correlates with content coverage.
• BLEU: precision-oriented n-gram metric from MT; less ideal for single-reference summaries and brevity-sensitive, but useful as a complementary precision signal.

Perplexity

• What it measures: how well a language model predicts the generated text token by token; it is a fluency/well-formedness signal about the OUTPUT text alone, not a comparison to the reference or the source.
• Why (and why not) to use it: low perplexity tells you the summary reads like natural, grammatical text; it says nothing about whether the summary is faithful to the source or covers the right content, so a fluent hallucination scores well. Use it as a cheap automatic gate to catch degenerate or repetitive output (e.g., a model collapsing into repeated phrases will show a perplexity spike relative to its own baseline), not as a quality or faithfulness metric.

Sequence-level / holistic metrics

• METEOR / BERTScore / MoverScore: embedding-aware metrics that capture paraphrase and synonymy; BERTScore often correlates better with human judgments on semantic similarity.
• Fact-based metrics: QAGS, QuestEval: automated factuality via question generation + QA to detect hallucinations.

Recommended evaluation suite (production)

• ROUGE-L and ROUGE-1/2 (coverage baseline)
• BERTScore (semantic similarity)
• QAGS or QuestEval for factuality
• Perplexity (relative to the model's own historical baseline) as a fluency/degeneration tripwire, never as a primary quality score
• Length, novelty (n-gram overlap with source), and readability (FKGL)
• Human evaluation: adequacy, fluency, coherence, factuality, and preference tests

Human-eval protocol

• Stratified sampling across lengths, topics, and model confidence
• 3+ annotators per item, majority vote + Cohen's kappa for reliability
• Use Likert scales for adequacy/fluency + binary factuality checks with evidence highlighting
• Paired A/B preference tests for UX decisions; collect free-text failure descriptions

Reconciling automatic metrics with human judgment when they disagree

• Treat human judgment as ground truth for the release decision; automatic metrics are a cheap, noisy proxy for it, never a substitute.
• When ROUGE/BERTScore says a new model is better but human preference disagrees (or vice versa), bucket the disagreeing examples and read them: this is usually where the automatic metric's known blind spot fires, e.g., a paraphrased-but-faithful summary scoring low on n-gram overlap (ROUGE penalty), or a fluent hallucination scoring high on BERTScore/perplexity but failing factuality.
• Quantify the disagreement, don't just note it: compute the correlation (Spearman/Kendall) between each automatic metric and the human preference on the current sample, and track it release over release. A metric whose correlation with human judgment is dropping is a signal that model changes have started to specifically exploit that metric's blind spot (a Goodhart's-law failure mode), and it should be down-weighted or replaced, e.g., swap in QAGS/QuestEval if factuality is the recurring gap.
• Operationally: never ship on an automatic-metric win alone if the paired human comparison disagrees; require the human preference test to be at least non-inferior (via the paired significance test from the human-eval protocol) before promoting a model, and use the automatic metrics for cheap continuous regression testing between the periodic human evaluations.

Justification
Combining ROUGE (coverage), BERTScore (paraphrase), QAGS (factuality), and perplexity (fluency/degeneration tripwire) balances classical reproducibility with semantic and factual assessment, while treating perplexity as a narrow sanity check rather than a quality signal. Human protocols validate the automated signals and capture nuanced errors (hallucination, incoherence) critical for product safety and user trust, and the reconciliation step keeps the automatic metrics honest as models evolve.

Requirements: monitor a binary credit-risk classifier in production to detect performance regressions, data drift, and business impact; provide actionable alerts for ops, data science, and business stakeholders.

Prioritized metrics

1. Model-level (priority: high)

• AUC/ROC and Precision-Recall AUC: signal overall discriminative power (Daily)
• Binned calibration / Predicted vs. observed default rate (Calibration): ensures score probabilities map to real risk (Daily)
• Confusion-matrix KPIs: Precision, Recall, F1 at the operational decision threshold: shows trade-offs relevant to approvals/declines (Real-time for counts, daily for rates)
  Alert rule: If calibration in any risk bin differs from historical baseline by >3 percentage points AND AUC drops >0.02 vs 7‑day rolling average → alert data science & risk team.

2. Data-level (priority: high)

• Population Stability Index (PSI) per feature and overall PSI: detects distribution shift (Daily)
• Feature missingness and outlier rates (per feature): catches ETL/regression problems (Real-time stream for key fields, daily otherwise)
• Covariate shift using Kolmogorov–Smirnov (KS: the largest vertical gap between two features' cumulative distribution curves; a bigger gap means the live feature distribution has drifted further from its training-time baseline) or KL divergence (a number that grows the more one distribution differs from another, 0 when they're identical) on top 10 features (Daily)
  Alert rule: PSI > 0.25 for any feature OR missingness increase >5pp vs baseline → alert data engineering + BI.

3. Business-level (priority: highest operational)

• Approval rate, default rate, weighted loss given default (LGD: the fraction of a defaulted loan's balance that is actually lost once any recovery, such as collateral or a settlement, is subtracted), expected loss (EL) per cohort (EL = probability of default x LGD x exposure amount, the single dollar-loss figure risk teams track per cohort) (Daily/Weekly)
• Revenue / loss per application and per segment (Daily)
• Customer experience metrics: time-to-decision, appeals/override rate (Real-time/daily)
  Alert rule: Observed default rate for newly approved cohort exceeds modeled expected default by >20% or weekly EL increase >15% → immediate business & risk alert.

Implementation notes:

• Expose metrics in BI dashboards with drill-down by segment, channel, and cohort; maintain 7‑day and 30‑day rolling baselines and seasonality adjustments.
• Use tiered alerting: page for critical business breaches, slack/email for data/model degradations.
• Store snapshots for root-cause (predictions, features, outcomes) and enable replay to calculate backtests.

Cluster-randomized experiments randomize treatment at the group level (users, households, schools, regions) rather than individuals. You use them whenever interference or correlated behavior makes individual randomization invalid: e.g., within-household spillover, network effects, or shared environments where one person’s treatment affects others’ outcomes. Randomizing clusters preserves the causal contrast and avoids contamination.

Intra-cluster correlation coefficient (ICC, ρ) measures the similarity of outcomes within clusters: ρ = σ_b² / (σ_b² + σ_w²), where σ_b² is between-cluster variance and σ_w² is within-cluster variance. ICC ranges 0–1; higher ρ means outcomes within the same cluster are more alike.

Impact on sample size and variance:

• Design effect (DE) = 1 + (m − 1)·ρ, with m = average cluster size. DE inflates variance relative to independent individuals.
• Effective sample size Neff ≈ N / DE (N = total individuals). So required total N must be multiplied by DE to retain power.
• Variance of treatment effect estimates must account for clustering: Var_clust = DE · Var_ind. Ignoring ICC underestimates standard errors, inflating Type I error.

Analysis recommendations:

• Power calculations should use estimated ICC and cluster sizes; increasing number of clusters is more effective than increasing cluster size when ρ>0.
• Use cluster-robust standard errors, mixed-effects models (random intercepts), or GEE with exchangeable correlation to correctly estimate SEs.
• Ensure sufficient degrees of freedom (enough clusters) because inference depends on number of clusters, not individuals.

Example: m=20, ρ=0.05 → DE = 1 + 19·0.05 = 1.95, so nearly double the sample needed compared with individual randomization.

Direct answer. Sort once by score and sweep the cumulative TP/FP/FN counts across all candidate thresholds simultaneously, rather than looping over each candidate threshold and rescanning the labels; this turns an O(n · number_of_thresholds) naive sweep into a single O(n log n) pass.

Code (executed and verified below, including a brute-force cross-check).

import numpy as np

def find_best_threshold(probs, y_true, beta=1.0):
    probs = np.asarray(probs)
    y_true = np.asarray(y_true)
    order = np.argsort(-probs)
    probs_sorted = probs[order]
    y_sorted = y_true[order]
    P = y_true.sum()
    tps = np.cumsum(y_sorted)            # TP if we predict positive down to this rank
    fps = np.cumsum(1 - y_sorted)
    fns = P - tps
    precision = np.where(tps + fps > 0, tps / (tps + fps), 0.0)
    recall = np.where(tps + fns > 0, tps / (tps + fns), 0.0)
    b2 = beta ** 2
    denom = b2 * precision + recall
    fbeta = np.where(denom > 0, (1 + b2) * precision * recall / denom, 0.0)
    best_i = np.argmax(fbeta)
    return probs_sorted[best_i], precision[best_i], recall[best_i], fbeta[best_i]

Worked example (recomputed, cross-checked against a brute-force sweep). On 2,000 synthetic points, the sweep above found threshold = 0.4784, precision = 0.7800, recall = 0.8146, F1 = 0.7969. A brute-force loop over every distinct candidate threshold independently found the identical F1 = 0.7969 at the identical threshold, confirming the fast version isn't silently skipping the true optimum.

Structured elaboration. Sorting once costs O(n log n); everything after that (the cumulative sums, the precision/recall/F-beta arrays, and the argmax) is O(n), so the whole routine is O(n log n) rather than the naive O(n · k) you'd get from looping over k candidate thresholds and recomputing precision/recall from scratch at each one. At tens of millions of rows this is the difference between one sort-and-sweep and a job that doesn't finish overnight.

Trade-offs and pitfalls. F-beta with beta > 1 weights recall more heavily than precision (beta=2 is a common choice when missing a positive is costlier than a false alarm); with beta < 1 it's the reverse. The threshold returned is the exact score value of the best-scoring example at the optimal cut, so in production you'd typically predict positive for score >= threshold; make sure the serving code uses the same inequality direction the threshold was chosen with, or you'll silently flip which side of the boundary counts as positive.