A defect model reads 94% accuracy on a test set rebalanced to 50/50, but live defects run at 0.3%. What does that number tell you?

## What went wrong Someone built an evaluation split with equal numbers of defective and good units - typically by keeping every defect and discarding most of the good units - and reported accuracy on it. The reported 94% is a real measurement of *something*, but it is not the accuracy anyone will observe on the line, because **accuracy is a function of the class mix of the set it is computed on**. Write it out. Let *p* be the share of positives (defects), *r+* the recall on defects and *r-* the recall on good units (specificity): ``` accuracy = p * r+ + (1 - p) * r- ``` The class-conditional rates *r+* and *r-* are properties of the model. The weights are properties of the evaluation set. Change the set's composition and the same model reports a different accuracy without a single prediction changing. ## The 50/50 identity worth knowing On a set rebalanced to exactly 50/50, p = 0.5, so ``` accuracy = 0.5 * r+ + 0.5 * r- = (r+ + r-) / 2 ``` which is precisely **balanced accuracy**. So the reported 94% is not a corrupted number - it is the model's balanced accuracy wearing the wrong label. That reframing is the crisp answer to give: 'that is balanced accuracy, and it is fine as a class-balanced summary, but calling it accuracy invites everyone to compare it against a production baseline it was never measured against.' ## Recomputing for the live prior Suppose the underlying rates are r+ = 0.92 and r- = 0.96 (a 4% false-alarm rate on good units); their mean is the reported 0.94. At the live prevalence of 0.003: ``` accuracy_live = 0.003 * 0.92 + 0.997 * 0.96 = 0.00276 + 0.95712 = 0.9599 ``` So the honest production accuracy is about **96%** - a *lower* number than the 94% figure would lead a reader to expect, and, far more importantly, **below the 99.7% majority-class baseline**. The model that looked like a 94% success is, on the metric as reported, worse than never flagging anything. The volume picture is what actually decides deployment. Per 100000 units: 300 defects, of which 276 are caught and 24 missed; 99700 good units, of which 4% - 3988 units - are falsely flagged. The inspection queue holds 4264 units, of which 276 are real. Nothing in a 94% figure hints at that ratio, and no amount of arguing about accuracy will surface it; the flagged-set view has to be reported separately. ## Why rates transfer and accuracy does not Each class-conditional rate is computed **within** one true class - defects caught over defects present - so it is unaffected by how many rows of the *other* class are in the set. Discarding good units cannot change the defect recall. Accuracy, by contrast, is an average across classes weighted by their frequencies, so it inherits the set's composition directly. The assumption that makes the recomputation valid is worth stating in the interview, because it is the part candidates skip: the *conditional distributions must be unchanged*. Discarding good units at random preserves what a good unit looks like, so r- transfers. Discarding them non-randomly - keeping only the hard ones, or only a recent week, or only one production shift - changes what the class *is*, and then neither rate transfers and the whole recomputation is invalid. ## What to do about it 1. **Evaluate on a set that carries the production prior.** Rebalancing the *training* data is a legitimate modelling choice with its own tradeoffs; rebalancing the *evaluation* data destroys the only property that made the number interpretable. Hold out a random, prevalence-preserving slice for scoring. 2. **If the rare class is too small for stable estimates**, keep the natural prior and accept wide intervals on the rare-class rate, or oversample the majority for *speed* while carrying explicit row weights that restore the true prior in the metric. Never let the unweighted number out of the room. 3. **Report class-conditional rates as the primary artifact**, plus the raw confusion matrix and the evaluation-set class mix. Then any reader can recompute for whatever prior their site, season or segment has. 4. **Always print the majority-class baseline next to the headline.** In this case it is the single line that would have caught the error immediately: a 94% figure quoted for a domain whose trivial baseline is 99.7% should never have survived review. 5. **Watch for prior drift after launch.** Even a correctly built evaluation set goes stale if the defect rate moves - a process change that halves defects silently raises accuracy while the model gets no better, which is why prevalence-independent rates belong on the monitoring dashboard. ## The shape of the mistake The general lesson generalises past this scenario: metrics that mix across classes - accuracy, error rate, and anything else summed over rows - are only comparable between two sets that share a class mix. Metrics conditioned on the true class are portable. When a number crosses a boundary between populations, ask which kind it is before you compare it to anything.