A defect-detection model passes validation at mAP@50-95 = 0.62, ships to the line, and the false-reject rate climbs. The dashboard shows one number that went up during training. It cannot tell you why the line is now rejecting good parts. That gap — between a single aggregate score and the actual quality of your detections — is what mAP@50-95 exists to expose, and what most teams throw away by reading only the headline figure. mAP@50-95 is not a black-box accuracy score. It is an average of average-precision computed across a sweep of intersection-over-union (IoU) thresholds, from 0.50 up to 0.95 in steps of 0.05. Read as a single number, it tells you almost nothing you can act on. Read as the breakdown it actually is, it tells you whether your model localises defects tightly, which classes are carrying the score, and where a regression came from. What mAP@50-95 actually measures Start with IoU. When a model draws a bounding box around a suspected defect, IoU measures how well that box overlaps the ground-truth box — the intersection area divided by the union area. An IoU of 1.0 is a perfect match; 0.50 means the box is roughly half-right. To count a detection as a “hit,” you pick an IoU threshold: at 0.50, a loosely placed box still counts; at 0.90, only a tightly localised box does. Average precision (AP) is the area under the precision-recall curve for one class at one IoU threshold. mAP — mean average precision — averages AP across all your defect classes. So mAP@50 is the mean AP when the hit threshold is fixed at IoU ≥ 0.50. That is a forgiving bar. A box that captures the general region of a scratch, without hugging its edges, still counts as correct. mAP@50-95 does something different. It computes AP at ten IoU thresholds — 0.50, 0.55, 0.60, all the way to 0.95 — and averages the lot. This is the COCO-style primary metric, and it is the default headline number reported by frameworks like Ultralytics YOLO and most PyTorch detection pipelines. Because the average includes the strict thresholds, a model only scores well at mAP@50-95 if its boxes are placed accurately, not just approximately. This is the core distinction we return to throughout: mAP@50-95 rewards localisation precision, mAP@50 rewards detection presence. The two answer different questions, and confusing them is where inspection deployments go wrong. If you want the narrower treatment of the loose-threshold metric on its own, we cover what mAP@50 means for defect detection separately; this article is about why averaging across the full IoU sweep changes what the number tells you. How is mAP@50-95 computed across IoU thresholds? The mechanics are worth walking through once, because the structure is what makes the metric readable rather than opaque. For each of the ten IoU thresholds, the evaluator sorts every predicted box by confidence, matches predictions to ground-truth boxes that clear that threshold, and builds a precision-recall curve. The area under that curve is the AP for that class at that threshold. Repeat for every defect class, average across classes to get mAP at that threshold, then average those ten per-threshold mAP values. That final average is mAP@50-95. The consequence is that mAP@50-95 is not one measurement — it is fifty or more measurements (thresholds × classes) collapsed into a scalar. The scalar is fine for tracking a training run. It is useless for diagnosis. The moment something changes, you have to unfold it again. The quick read Metric IoU threshold(s) What a high value tells you What it hides mAP@50 0.50 only The model finds defects and roughly locates them Whether boxes are tight enough for downstream measurement mAP@75 0.75 only Boxes are reasonably tight Behaviour at the extremes mAP@50-95 0.50 → 0.95 (avg of 10) Detection presence and localisation quality together Which threshold band or class is weak — until you break it out The single-number habit is the failure. The fix is to always carry the per-threshold curve and the per-class table alongside the aggregate. Reading the gap between mAP@50 and mAP@50-95 Here is the most actionable signal the metric gives you. Take mAP@50 and mAP@50-95 for the same model and look at the difference. A small gap — say mAP@50 = 0.88 and mAP@50-95 = 0.80 — means the model’s boxes stay accurate as you tighten the IoU bar. Detections are well localised. A large gap — mAP@50 = 0.88 but mAP@50-95 = 0.55 — means the model finds defects but places its boxes loosely. It passes the forgiving threshold and collapses at the strict ones. That collapse is not an abstract statistic on an inspection line. It is avoidable false rejects and, worse, missed defects on classes where box accuracy governs a downstream measurement step. A model tuned for mAP@50 can validate cleanly and still localise badly enough to hurt line performance — this is exactly the trap the side-by-side comparison of mAP@50 and mAP@50-95 on the line walks through in operational terms. In our experience with industrial CV inspection, the gap is disproportionately driven by small defects (observed pattern across manufacturing engagements; not a benchmarked constant). A two-pixel scratch has so little area that a slightly misplaced box drops its IoU below 0.75 immediately, even though the same box would clear 0.50 without trouble. So a widening mAP@50-to-mAP@50-95 gap after a data or model change is often a signal that small-defect localisation specifically has degraded — something the aggregate never says out loud. How per-class AP finds which defect types are regressing The other unfold is by class. mAP averages AP across every defect type you detect. That average is exactly where a regression hides. Suppose your validation mAP@50-95 drops from 0.62 to 0.58 after retraining on a fresh data batch. The aggregate says the model got worse. It does not say the model got worse at scratches while improving on dents. Only the per-class AP table does that. When you lay the per-class numbers from the two runs side by side, a four-point aggregate drop frequently resolves into one class falling hard while the rest hold or improve. This matters most for the defect types that carry escape cost — the ones where a miss ships a bad part to a customer. A class-level AP regression on a low-frequency, high-consequence defect can be completely masked by strong performance on common, low-consequence ones, because the rare class contributes little to the average. If you monitor only the aggregate, you can watch escape risk rise while the headline number looks stable. The discipline is to weight your attention by escape cost, not by how much each class moves the mean. The mechanism of how the detector produces those boxes in the first place — the confidence scores, the non-max suppression, the class assignment — is covered in how an image detection model works in industrial inspection; understanding it makes the per-class table far easier to interpret when a class regresses. When is a high mAP@50-95 misleading? A strong aggregate is not a clean bill of health. Several conditions produce a high mAP@50-95 that will not survive contact with a production line. The first is validation-set mismatch. mAP is only as representative as the images it was scored on. If your validation set under-samples the lighting conditions, part variants, or defect morphologies the line actually sees, a high score reflects the easy subset, not the deployment. This is not a metric flaw — it is a data-coverage flaw the metric cannot see. The second is class imbalance masking the tail, as above. The third is confidence-threshold drift: mAP integrates over all confidence values, but the line runs at one fixed operating point. A model can have excellent mAP@50-95 and still behave badly at the specific confidence threshold you deploy, because the metric averaged over a curve you only occupy one point of. Before trusting the aggregate, check per-class AP on your escape-cost classes, the mAP@50-to-mAP@50-95 gap for localisation health, and the precision-recall behaviour at your actual operating threshold. There is also the question of what the metric does not do. mAP@50-95 is a validation-time measurement. It defines what “good” meant on a frozen dataset at sign-off. It does not detect drift once the model is live — that is the job of the on-line monitoring layer, and it is a different discipline entirely. How the validation baseline feeds SPC monitoring This is where the metric connects to production reliability. The mAP@50-95 you sign off at validation is the baseline the monitoring layer holds the line to. When a CV inspection deployment runs statistical process control on its detection outputs, the control limits and drift signals are anchored to what the model demonstrated at validation — including which classes it was strong on and how tight its localisation was. Concretely, the validation mAP ties to the false-reject and missed-defect rates that inspection ROI is actually measured on. If validation established a false-reject rate consistent with a given mAP and localisation profile, the SPC charts later flag when the live rate departs from it. The metric does not replace on-line drift detection; it defines the reference that drift detection measures against. A weak or misread validation baseline poisons everything downstream — you cannot hold a line to a number you never understood. This is why we treat the mAP@50-95 breakdown as the entry to a longer reliability chain. The validation metric is one of the detection metrics an industrial-CV deployment signs off before it runs against production AI reliability in production. If you are building or hardening a defect-detection deployment, our computer vision practice treats validation metrics and production monitoring as one continuous accountability surface rather than two disconnected steps, and our broader engineering services carry that through to the SPC layer. FAQ What does working with map50-95 involve in practice? mAP@50-95 averages average-precision across ten IoU thresholds from 0.50 to 0.95. In practice it measures both whether your model finds defects and how tightly it localises them — a high value means detections are accurate, not just present, which is what matters when a downstream measurement or reject decision depends on the box position. How is mAP@50-95 computed as an average of average-precision across IoU thresholds from 0.50 to 0.95? For each IoU threshold in 0.50, 0.55, …, 0.95, the evaluator builds a precision-recall curve per class, takes the area under it as AP, averages AP across classes to get mAP at that threshold, then averages those ten per-threshold mAP values. The scalar you see is fifty-plus measurements collapsed into one number. What does the gap between mAP@50 and mAP@50-95 tell you about a model’s bounding-box localisation quality? A small gap means boxes stay accurate as the IoU bar tightens — good localisation. A large gap means the model finds defects but places boxes loosely, passing the forgiving 0.50 threshold and collapsing at the strict ones. The gap is disproportionately driven by small defects, whose tiny area punishes any box misplacement. How do per-class AP values under mAP@50-95 help you find which defect types are regressing? The aggregate averages AP across all defect classes, which hides where a regression lives. Laying per-class AP side by side across two runs resolves a small aggregate drop into the specific class that fell — critical for low-frequency, high-escape-cost defects that contribute little to the mean and can degrade unnoticed. How does validation mAP@50-95 relate to the false-reject and missed-defect rates you later monitor on the line? Validation mAP and its localisation profile establish the false-reject and missed-defect rates that inspection ROI is measured on. A model tuned only for mAP@50 can validate cleanly yet localise poorly, driving avoidable false rejects. The validation baseline is what production SPC charts later hold the line to. When is a high mAP@50-95 misleading for a CV inspection use case, and what should you check alongside it? A high aggregate misleads when the validation set under-samples real line conditions, when class imbalance masks a weak escape-cost class, or when the metric’s curve-averaging hides bad behaviour at your fixed operating threshold. Check per-class AP on escape-cost classes, the mAP@50-to-mAP@50-95 gap, and precision-recall at your actual deployment confidence. How does the mAP@50-95 baseline set at validation feed the control limits and drift signals in SPC monitoring? The validation mAP@50-95 — including per-class strength and localisation tightness — is the reference the SPC monitoring layer anchors its control limits and drift signals to. It defines what “good” meant at sign-off; it does not replace on-line drift detection, it gives drift detection the baseline to measure departures against. Read the metric as the breakdown it is — a per-threshold curve and a per-class table — before you let it anchor a production baseline. The question that separates a robust deployment from a fragile one is not “did the number go up,” but “did the localisation on my highest-escape-cost defect class hold at the IoU threshold my line actually runs at.”
