Aggregate metrics mask subgroup differences
Aliases: Simpson's paradox in evaluation · aggregation trap · masking disparity
What it is
A single aggregate metric is a size-weighted average, and it systematically masks performance differences between subgroups: a system with 95% aggregate accuracy might run a 2% error rate for the 80% majority population and 40% for a 5% minority — the majority's good performance dilutes the minority's failure to invisibility in the mean. In extreme cases a Simpson's-paradox reversal appears: the trend within every group points one way, and the merged aggregate points the other, so the aggregate does not merely hide the difference but actively lies.
Why it happens
Three mechanisms stack. Arithmetic structure: weighted averages are sensitive to large groups and numb to small ones — if a 1% population's error rate doubles, the aggregate barely moves. Optimization dynamics: training optimizes aggregate loss, so the model happily accepts trades like "sacrifice 1% of a minority's performance for a 0.5% majority gain" because the trade is net-positive on the metric. Reporting inertia: team updates, benchmarks, and acceptance criteria all communicate in single numbers; once one number becomes the only language, undisaggregated differences have no way to be stated — not because they are hard to compute, but because nobody asks.
Studying it
Research treats the aggregate–disaggregated gap itself as the measurement object: report both for the same system, define the masking magnitude as their difference, and use re-weighting analyses to test for Simpson-type reversals (whether within-group and merged trends agree). Variables include group size ratio and the group performance gap. Methodological caution: stratification shrinks cell sizes, and underpowered subgroup tests convert real differences into "not statistically significant" — which reads as "no difference." Power analysis should precede stratified reporting; oversample the evaluation set if needed to hit minimum cell counts.
Where it stops holding
Not everything needs stratification: purely engineering metrics indifferent to humans (compile time, cache hit rate) aggregate harmlessly; disaggregation matters where errors land on people. Aggregate metrics are not useless — they answer capacity and cost questions; the error is letting them usurp the only voice. And a wrong stratification dimension shreds real differences across irrelevant ones (stratifying by device model while masking a language gap); dimensions must follow the feature's actual impact on populations, not what happens to be in the data.
Applying it
- Make performance dashboards dual-view by default: aggregate row plus stratified table side by side; quoting only the aggregate triggers an automatic prompt to show the stratified view.
- Promote worst-group metric to a first-class acceptance item alongside the aggregate; add a worst-group term to the optimization objective to block majority-for-minority trades.
- Set minimum sample sizes per stratification cell when designing evaluation sets; mark short cells "not evaluable" instead of merging them away.
- Verify: decompose last quarter's aggregate gain into the stratified table and see where it came from; if it mainly came from the majority while small groups flatlined or declined, redirect the improvement plan.
Related
- Same group: P4.03.1 The training distribution decides who bears the failures · P4.03.3 Evaluate with stratified demographic analysis
- Adjacent: P4.10 Data representativeness and bias · P4.09 Algorithmic fairness and disparate impact
- Search terms:
aggregate metrics masking·Simpson's paradox·worst-group accuracy