Metrics, thresholds, and calibration
Measure ordering, repair probability meaning, then choose the policy the operation can actually run.
An ETA model improves RMSE while increasing missed-delivery cost.
This chapter moves from inspect the ranking to check probability meaning. We will make the idea concrete in a small code example before placing it back inside a production system with a declared latency, cost, and operator-capacity budget.
Compare predicted and observed frequency in sufficiently populated bins, then calibrate on data separate from final testing.
Verify the behavior illustrated in threshold_cost.py, then measure decision utility, slice reliability, and system latency.
ROC-AUC alone on 0.1% prevalence hides unusable precision and an impossible review queue. An unsafe release must degrade to a named baseline or the last known-good version.
Build the idea one layer at a time.
Ranking, probability estimation, and action selection are three different questions. A healthy evaluation contract measures each without confusing them.
Threshold-free metrics describe ordering across many possible policies, but production executes one operating point. That point should minimize declared error cost or satisfy capacity and recall constraints on validation data.
Calibration asks whether scores have frequency meaning: among comparable cases scored near 0.7, roughly 70% should be positive. A well-ranked but overconfident model may choose the wrong expected-value action until its probabilities are calibrated.
- temporal splits
- PR curves
- calibration
- experiment guardrails
Follow the reasoning before touching the code.
- 01
Inspect the ranking
Use prevalence-appropriate curves and slice views to learn whether positives move ahead of negatives.
- 02
Choose the operating point
Evaluate false-negative and false-positive cost plus queue capacity for candidate thresholds on validation.
- 03
Check probability meaning
Compare predicted and observed frequency in sufficiently populated bins, then calibrate on data separate from final testing.
scores = [0.92, 0.76, 0.61, 0.40, 0.18, 0.07]
labels = [1, 0, 1, 0, 1, 0]
false_negative_cost = 20
false_positive_cost = 3
for threshold in [0.3, 0.5, 0.7]:
decisions = [score >= threshold for score in scores]
fp = sum(decision and not label for decision, label in zip(decisions, labels))
fn = sum(not decision and label for decision, label in zip(decisions, labels))
cost = fp * false_positive_cost + fn * false_negative_cost
print(threshold, {"reviews": sum(decisions), "fp": fp, "fn": fn, "cost": cost})
high = [label for score, label in zip(scores, labels) if score >= 0.7]
print("high-bin prediction", 0.84, "observed", sum(high) / len(high))Evaluate concrete decision cost at several thresholds.
What to notice
- Raising the threshold shrinks the queue but can exchange inexpensive false positives for costly false negatives.
- The high-score bin is only 50% positive here, far below its average stated confidence of about 0.84.
YOUR TURN Pause and predict before revealing the answer.
If review capacity is exactly three cases, which listed threshold is feasible and has the lowest displayed cost?
Need a hint?
First filter by the printed review count, then compare cost.
Check your reasoning
Threshold 0.5 reviews three cases and costs 23; threshold 0.7 reviews two but costs 43, so 0.5 is the lowest-cost feasible listed policy.
Lessons 1, 2, 3 in this course.
Connect the chapter to the course’s quantitative spine.
Measure ordering, repair probability meaning, then choose the policy the operation can actually run. The cost-aware threshold selection below is the shared course-level lens that helps quantify the surrounding system. Name each symbol, check its units or shape, and use only values that were available at the production cutoff.
Cost-aware threshold selection
| Symbol | Meaning / shape / unit |
|---|---|
t | decision threshold |
FN, FP | error counts at t |
c_FN, c_FP | business cost per error |
Open derivation and numerical substitution
Start from the production quantity being optimized, substitute the observed values with their declared units, then isolate the model-controlled term. Preserve shape annotations at each step so broadcasting or aggregation cannot silently change the result.
- Write the named inputs: t, FN, FP, c_FN, c_FP.
- Substitute one small, hand-checkable batch before vectorizing.
- Calculate an independent reference value and compare within a declared tolerance.
# equation → code contract
inputs = validate_shapes_and_units(batch)
value = compute_c02(inputs)
assert is_finite(value)Change one assumption and make the tradeoff visible.
Use the worked chapter as your prediction, then change one input in the lab and explain why the output moves. The lab runs predefined TypeScript and never executes learner code, so the focus stays on the concept rather than setup.
Cost-aware threshold
Move the cutoff over a fixed set of scored transactions.
Assumption: Fixed 12-event dataset; false positive costs 2 units and false negative costs 12.
Open nonvisual data table
| Item | Computed state | Interpretation |
|---|---|---|
| 0.92 | fraud | review |
| 0.84 | fraud | review |
| 0.76 | legit | review |
| 0.68 | fraud | review |
| 0.59 | legit | review |
| 0.51 | fraud | review |
| 0.43 | legit | pass |
| 0.37 | legit | pass |
| 0.31 | fraud | pass |
| 0.22 | legit | pass |
| 0.14 | legit | pass |
| 0.08 | legit | pass |
Trace the complete operating path.
Carry the chapter’s central idea into the system: Measure ordering, repair probability meaning, then choose the policy the operation can actually run. The path below shows where that reasoning needs an artifact, a test, an owner, or a fallback.
- 01
Turn “Inspect the ranking” into a written invariant and a failing test.
- 02
Promote threshold_cost.py from illustration to a versioned implementation with representative fixtures.
- 03
Use “Check probability meaning” as the release checkpoint: Compare predicted and observed frequency in sufficiently populated bins, then calibrate on data separate from final testing.
- 04
Serve or materialize behind explicit a declared latency, cost, and operator-capacity budget.
- 05
Join telemetry to mature outcomes and retain a rollback path.
Observability
Join service health, input quality, prediction distributions, slice behavior, and mature outcomes by exact version.
Cost
Measure storage, preprocessing, compute, queueing, and human review under a representative arrival pattern.
Failure modes
ROC-AUC alone on 0.1% prevalence hides unusable precision and an impossible review queue. Add a detector, owner, mitigation, and stop condition for this class of failure.
Alternatives
Compare a rule, a simpler statistical baseline, and a different system boundary before adding model complexity.
Explain the contract, not just the vocabulary.
Late-delivery evaluation contract
Specify a cutoff-safe target, validation design, cost/capacity threshold, calibration report, uncertainty, and controlled experiment.
- Decision and metric contract
- Leakage-safe split tests
- Threshold and calibration analysis
- A/B guardrails and rollback
Read primary material with a purpose.
Return to the opening failure.
Store the decision contract, cutoff, split logic, threshold policy, uncertainty, and experiment design beside the model.
For this lesson, the release evidence is the worked code example, a hand-checked formal result, deterministic simulation output, a ≥80% checkpoint, the production rubric, and a named fallback. The course resolves when the system can produce a metric contract, leakage-safe validation, calibration analysis, and experiment plan.