A Model-Evaluation Interview Exercise With Uneven Error Costs
Evaluate a model with unequal error costs through labels, precision and recall, threshold tradeoffs and realistic human-review capacity.
TL;DR
- In this fictional model-evaluation exercise, missing an urgent support message and flagging a routine one have different costs.
- Define labels and compare thresholds through error consequences and reviewer workload.
- Inspect individual errors, keep evaluation separate from tuning, and specify fallback and monitoring behavior.
Name the consequences of each mistake
In this fictional interview, a model flags support messages that may require urgent specialist attention. Missing an urgent message can delay important help, while flagging too many ordinary messages can overwhelm the specialist queue. The interviewer asks which metric you would optimise.
Do not choose accuracy before understanding these consequences. Ask what counts as urgent, who labels the examples and what action follows a flag. A model score is part of a workflow, not a decision in isolation.
The exercise is not a claim about a deployed support system. Its purpose is to connect evaluation to the different costs of errors and the capacity of the people who must act on the output.
Define the positive class and labels
State that positive means “requires urgent specialist review” in the fictional setup. Then define false positives and false negatives in those terms. This prevents a discussion in which different participants use the same metric names for opposite outcomes.
The Google classification metrics guide explains precision, recall and how metric choice depends on error costs and class balance. Use those definitions carefully: recall concerns the urgent cases found, while precision concerns the flagged cases that are actually urgent.
Check the label quality. If reviewers disagree about urgency or see different context, a single target label may conceal uncertainty. Establish a review process for ambiguous examples rather than treating every disagreement as model failure or every existing label as unquestionable truth.
Compare threshold choices through workload
Use a fictional threshold comparison without inventing results. A lower threshold might send more messages for review, potentially finding more urgent cases while also increasing false alarms. A higher threshold may reduce the queue while missing more cases. Measure the actual tradeoff on suitable evaluation data rather than assuming the size of either effect.
| Decision dimension | Evidence needed |
|---|---|
| Missed urgent cases | Recall and concrete failure review |
| Unnecessary review | False positives and reviewer workload |
| Queue delay | Capacity and arrival pattern |
| Uneven performance | Relevant subgroup or case-type analysis |
| Confidence in estimates | Sample size and uncertainty |
The queue changes the cost calculation. A threshold that finds more urgent cases but delays all reviews beyond usefulness may not improve the final outcome. Include response capacity and prioritisation in the discussion.
Inspect errors, not only a summary score
Read representative false positives and false negatives under appropriate privacy controls. A model may confuse polite language with low urgency, struggle with abbreviated messages or miss context stored elsewhere. Different error mechanisms suggest different interventions.
Some cases may be better handled with a deterministic rule, an additional question or a clear user escalation route. Do not assume the only option is retraining the model. The product can change how information is collected and how uncertain cases are handled.
Compare performance across relevant conditions without overinterpreting tiny groups. A promising or troubling subgroup pattern may need more evidence before supporting a precise claim. Keep the observed cases and uncertainty visible in the review.
Keep evaluation data separate from tuning
Choose thresholds using an appropriate development process, then assess the decision on data not repeatedly used to optimise it. If the same examples are examined after every change, the apparent result can become too tailored to that set.
Preserve the context in which labels and predictions were produced. A future workload with different language or message types may not behave like the historical sample. Monitor the conditions that could make the evaluation less representative.
Our AI system design guide can help connect data, model output and the downstream review workflow. Keep the whole decision path in the diagram rather than stopping at the score.
Inspect the time delay in obtaining labels. If urgency is confirmed only after a specialist resolves a case, recent predictions may not yet have reliable outcomes. Comparing fully labelled older data with partially labelled recent data can create a false performance trend. Report the evaluation window and unresolved labels explicitly.
Define the fallback and monitoring plan
Explain what happens when the model is unavailable, the review queue is full or a user disputes the classification. A low score should not remove every route to human help if the product's task requires one. Name the approved fallback and its limits.
Track outcome evidence where feasible, including reviewed urgent cases that were initially missed. Reviewer corrections can help, but they may be biased toward cases that were already flagged. Do not assume the unreviewed population is error-free.
In rehearsal, have a partner halve the specialist capacity or change the cost of a missed case. Reconsider the threshold and workflow together. Use the mock interview strategy to explain the decision without pretending one metric solves every problem. A strong answer makes error costs, uncertainty and operational capacity explicit before selecting a model operating point.