A single accuracy figure is an average, and averages are governed by whatever is frequent in the dataset. For an automotive perception model, the frequent cases are clear daylight, well-framed vehicles, and common classes. The rare cases — the ones that generate field incidents — contribute so few samples that a total collapse on them barely moves the headline number. That is the failure mode: benchmark accuracy is not wrong, it is structurally insensitive to exactly the scenarios a release reviewer needs to worry about.
The class and condition mix inside a benchmark was chosen by whoever built the benchmark. It was not sampled from your fleet, your routes, your weather envelope, or your sensor rigs. So when a model reports 0.72 mAP, that number is a weighted average whose weights belong to someone else’s driving distribution.
What “benchmark accuracy hides perception edge cases” means in practice
Take two detectors that both land on the same aggregate score. Model A distributes its errors fairly evenly. Model B is slightly better on the dominant daylight-vehicle bulk — enough to offset a near-total failure on pedestrians at night against wet-road glare, a class that makes up under one percent of the evaluation set. The aggregate arithmetic cannot distinguish these two models. A stratified evaluation separates them immediately.
This is the mechanism, and it is worth stating plainly as a claim: two perception models with identical aggregate accuracy can differ by an order of magnitude in failure rate on an individual rare scenario class, because a class contributing under one percent of evaluation samples cannot materially move a dataset-level average. Nothing about that is a modelling subtlety. It is a property of how weighted means work, and it means the headline number gives the reviewer no way to see a long-tail collapse coming.
We see this pattern regularly in perception review meetings. The score improved release-over-release, the team is confident, and nobody in the room can answer the question “which scenario class got worse?” — because the evaluation was never sliced in a way that could answer it. The stratified view is where models with identical scores stop looking alike, and it is the discipline the broader automotive perception robustness audit is built around.
Which scenario classes go missing
Public perception benchmarks are collected for research comparability, which biases them toward conditions where annotation is cheap and reliable. The systematic under-representation is predictable enough to enumerate:
| Axis | Typically over-represented | Typically thin or absent |
|---|---|---|
| Weather | Dry, overcast, light rain | Fog, heavy rain, snow, spray from adjacent vehicles |
| Lighting | Daylight, lit urban night | Low sun into lens, tunnel entry/exit transitions, wet-road glare |
| Occlusion | Unoccluded, lightly clipped | Heavy mutual occlusion in dense traffic, partially emerging objects |
| Distance | Mid-range (roughly 10–50 m) | Far-field small objects, very near cut-ins |
| Object class | Cars, common pedestrians | Rare vehicle types, road debris, animals, unusual pedestrian poses |
| Sensor rig | One reference configuration | Mounting-height and calibration variance across fleet variants |
The distance and lighting rows are the ones that bite hardest in practice, because both interact with detector confidence rather than producing clean misses. A far-field object under low sun tends to degrade into a low-confidence detection that a downstream tracker discards, and the aggregate metric records that as a modest recall dip inside a bucket that was small to begin with.
How to slice so the failures stop averaging away
Stratification is not exotic instrumentation. It is a labelling and reporting decision made before the evaluation runs, and it changes what the evaluation is capable of showing.
- Tag every evaluation frame along the axes above — weather, lighting regime, occlusion band, distance band, object class, sensor rig — at collection or ingest time, not retrospectively. Retrospective tagging is where scenario coverage quietly gets fabricated.
- Report failure rate per scenario class, not accuracy per dataset. The unit of the release argument becomes “pedestrian, night, wet-road glare, 40–70 m: 11% miss rate” rather than a global figure.
- Publish the per-class sample count next to every per-class rate. A rate without an n is not evidence.
- Name the classes with no measurable coverage. These are not passes; they are unknowns, and they belong in the release record as unknowns.
- Compare per-class against the previous release, so a regression in one bucket cannot be laundered by an improvement in the bulk.
On sample size: precise thresholds depend on the failure rate you are trying to bound and the confidence you need, so treat any single number as a planning heuristic rather than a rule. The practical point is that a bucket holding a handful of frames cannot support a failure-rate claim at all, and reporting one from it is worse than reporting nothing — it converts an unknown into a false pass. When a class cannot be populated adequately, the honest move is to expand collection for that class or declare it uncovered, and much of the work of building a test set against the production driving distribution is exactly this bookkeeping.
Tooling-wise none of this requires a new stack. Scenario tags carried alongside COCO-style or nuScenes-style annotations, evaluation runs grouped by tag in the same PyTorch or ONNX Runtime harness that produces the aggregate figure, and per-class results versioned in something like MLflow, is enough. The cost is discipline, not infrastructure. Our Production AI Monitoring Harness carries this shape as its default output: stratified per-scenario-class failure rates plus declared coverage gaps, replacing a single headline accuracy number as the release artefact. The same stratification then extends into post-deployment monitoring, which is where the axes earn their keep a second time.
Where the aggregate number still earns its place
Overcorrection is its own failure. Aggregate accuracy remains a legitimate instrument for a few specific jobs, and dropping it entirely costs you a useful signal:
| Use | Verdict | Why |
|---|---|---|
| Training-pipeline sanity check | Keep | A collapsed aggregate score catches broken data loading, label mismatch, or a failed export fast |
| Architecture shortlisting | Keep, with caution | Fine for narrowing candidates before real evaluation; not a selection decision |
| Regression tripwire on a fixed reference set | Keep | A sudden aggregate drop is a real alarm, even though a stable one proves nothing |
| Comparability against published research | Keep | This is what the benchmark was designed for |
| Release evidence for a safety-relevant perception function | Reject | Structurally cannot express long-tail behaviour |
| Robustness claim to a customer or reviewer | Reject | Not admissible without per-scenario-class breakdown |
The pattern in that table is consistent: aggregate accuracy is a good detector of gross breakage and a bad detector of narrow collapse. Use it where a global number can plausibly carry the signal, and refuse it where the thing you care about is rare by construction.
For a release reviewer, the practical substitution is straightforward. Instead of one number to argue about, hand over the per-class failure-rate table, the sample count behind each row, the delta against the previous release, and an explicit list of scenario classes with insufficient coverage. In our experience that shortens the review rather than lengthening it, because the argument shifts from “do we trust this figure” to “do we accept this documented failure rate in this class” — a question a reviewer can actually sign. The broader engineering context for how these detectors are built and instrumented sits in our computer vision practice.
Frequently Asked Questions
What does “benchmark accuracy hides perception edge cases” mean in practice for an automotive perception release?
A useful Benchmark Accuracy Hides Perception clarification is this. It means the release signal you are reading is a weighted average whose weights come from the benchmark’s condition mix, not your fleet’s. Rare scenario classes contribute too few samples to move the figure, so a model can fail almost completely on night-time pedestrians in glare while its aggregate score improves. The number is not lying; it simply has no channel through which that failure could be expressed.
Why can two models with the same aggregate accuracy have very different long-tail behaviour?
Because the aggregate is a mean over an uneven class and condition distribution. A small edge in the dominant easy bulk can arithmetically offset a large deficit in a class holding under one percent of samples. Once the same evaluation is sliced by weather, lighting, occlusion, distance band, and object class, the two models separate sharply.
Which scenario classes are systematically under-represented in public perception benchmarks?
Fog, heavy rain and spray, low sun directly into the lens, tunnel entry and exit transitions, wet-road glare at night, heavy mutual occlusion in dense traffic, far-field small objects and very near cut-ins, rare vehicle types, road debris, and animals. Sensor-rig variance is under-represented too — most benchmarks encode one reference configuration rather than the mounting spread of a deployed fleet.
How do we slice evaluation results so edge-case failures become visible instead of averaged away?
Tag every evaluation frame at ingest along the axes that matter — weather, lighting regime, occlusion, distance band, object class, sensor rig — then report failure rate per scenario class with its sample count, plus the per-class delta against the previous release. Retrospective tagging is the common shortcut and the common source of fabricated coverage.
How many samples per scenario class do we need before a per-class failure rate means anything?
There is no universal figure; it depends on the failure rate you are trying to bound and the confidence interval you need, so treat any threshold as a planning heuristic. What is firm is the negative case: a bucket with a handful of frames cannot support a failure-rate claim, and quoting one from it converts an unknown into a false pass. Expand collection for that class, or declare it uncovered.
What should we report to a release reviewer instead of, or alongside, a headline accuracy number?
Per-scenario-class failure rates, the sample count behind each rate, the change against the previous release per class, and an explicit list of classes with coverage too thin to support a claim. That gives the reviewer something signable — acceptance of a documented rate in a named class — rather than a single figure to negotiate over.
Where does benchmark accuracy still have legitimate use in a perception programme?
As a training-pipeline sanity check, an architecture shortlisting filter, a regression tripwire on a fixed reference set, and for comparability against published research. It is a reliable detector of gross breakage and an unreliable detector of narrow collapse, which is precisely why it should not stand as release evidence for a safety-relevant function.
If your last three releases each improved the aggregate score, which scenario class got worse — and would your current evaluation be able to tell you?
Acting on Benchmark Accuracy Hides Perception
Benchmark Accuracy Hides Perception is rarely the hard part — knowing which of its failure modes you can live with is. That answer is workload-specific, and it is worth writing down before you build.
