A defect-detection model reports 0.94 mAP50 and the team calls it line-ready. Two weeks after deployment the SPC chart starts drifting — not because the model missed defects, but because it localised them loosely, and that looseness never showed up in the headline number. This is the trap in reporting a single accuracy figure: mAP50 and mAP50-95 are not two views of the same quality. They ask different questions, and only one of them matches what an inspection line demands.

The short version: mAP50 accepts a detection as correct if its box overlaps the true box by at least 0.5 IoU. mAP50-95 averages precision across ten stricter overlap thresholds, from 0.5 up to 0.95 in steps of 0.05. A model can post a strong mAP50 and a mediocre mAP50-95, and that spread is exactly the localisation weakness that later surfaces as instability on the production floor.

What does the IoU threshold actually control?

Intersection over Union (IoU) measures how well a predicted bounding box overlaps the ground-truth box — the area of overlap divided by the area of union. An IoU of 0.5 means the two boxes share half their combined area; an IoU of 0.9 means they are nearly coincident. The threshold is the pass/fail line for calling a detection “correct” before precision is computed.

mAP50 fixes that line at 0.5. That is a forgiving bar. A box that is shifted, oversized, or clipped at the edge of a defect can still clear 0.5 IoU and be scored as a hit. mAP50-95 runs the same evaluation at 0.5, 0.55, 0.60, and so on through 0.95, then averages the ten precision values. Every step upward punishes loose boxes harder, so the averaged figure is dominated by how tightly the model actually localises — not just whether it found something in roughly the right place.

This is the core distinction, and it maps cleanly onto the object-detection mechanics we cover in How an Image Detection Model Works in Industrial Inspection. Detection is two coupled tasks: classify the region, and place the box. mAP50 mostly grades the first. mAP50-95 forces both to be good at once.

When does a model score high on mAP50 but poorly on mAP50-95?

The gap opens whenever the model is confident about what it sees but sloppy about where. Some concrete patterns we see repeatedly in inspection work (observed pattern across TechnoLynx computer-vision engagements, not a benchmarked rate):

• Small or thin defects — hairline scratches, edge chips, print smears. The defect occupies few pixels, so a box that is a little too big still passes 0.5 IoU but fails at 0.75+. The classifier is right; the localiser is coarse.
• Elongated or irregular geometry — a solder bridge or a crack that a tight axis-aligned box struggles to frame. mAP50 tolerates the mismatch; mAP50-95 does not.
• Cluttered scenes — overlapping parts where the model finds the right defect but its box bleeds into a neighbouring feature.

In each case mAP50 reports a comfortable number and mAP50-95 quietly records the deficit. If your validation report only carries the first figure, you have thrown away the signal that predicts on-line behaviour. This is the same localisation-quality story told from the single-metric angle in What mAP@50 Means for Defect Detection in Industrial Vision Inspection and, from the stricter side, in mAP@50-95 Explained.

Which metric should you track for a production inspection task?

There is no universal answer — the right headline metric depends on whether defect position and extent carry downstream consequence. Use the following as a decision rubric.

Decision rubric: choosing your headline metric

Inspection characteristic	Track as headline	Why
Defect presence is the decision (pass/fail, defect somewhere on part)	mAP50 acceptable as primary	Loose localisation does not change the accept/reject outcome
Defect position feeds a downstream action (robotic rework, laser trim, coordinate log)	mAP50-95 primary	Box coordinates must be tight enough to act on
Defect extent is measured (length, area, severity grading)	mAP50-95 primary	Sizing error propagates directly into the grade
Defects are small, thin, or irregular	mAP50-95 primary	This is where the two diverge most
SPC control limits will track the model’s output	mAP50-95 primary, report both	Control limits inherit the localisation variance

The general rule: if anything downstream of the model consumes the box coordinates or the box size, mAP50-95 is the metric that predicts whether that consumption is stable. mAP50 alone is only safe when the sole output is a binary presence flag. Even then, reporting both costs nothing and keeps the localisation trend visible before it becomes a problem — a point we return to in the context of fine-tuning YOLO for line defect detection, where tightening localisation is a distinct tuning objective from raising recall.

How does the chosen metric become the SPC baseline?

This is where the metric choice stops being an academic distinction and becomes an operational one. When a computer-vision inspection model qualifies for a line, its validation accuracy becomes the baseline that Statistical Process Control limits are set against. The monitoring harness records that number, then watches the live defect-escape rate and detection statistics for drift away from it.

If the recorded baseline is mAP50 on a task where localisation matters, you have anchored your control chart to a number that overstates real quality. The model’s live behaviour — box jitter, oversizing, coordinate error on the actual parts — was never captured by the baseline. So the first time a batch of thin or awkwardly-placed defects comes through, the escape rate moves outside your control limits and looks like drift. It is not drift. It is a localisation weakness that the wrong headline metric hid at validation time.

We treat the metric choice as the first decision in the validation pack that our production monitoring harness signs against: the accuracy baseline recorded before SPC instrumentation starts tracking. Get it right and the correlation between validation mAP50-95 and observed escape rate is tight, re-tuning cycles shrink, and late-stage rejections from masked localisation error drop. Get it wrong and you spend the first month after deployment chasing a “drift” that was baked in on day zero. The reliability side of this handshake — which inspection metrics a hardened deployment commits to — is where computer-vision engineering meets our services; the inspection stack itself is described on the computer vision page.

Worked example (illustrative)

Assume a print-inspection model validated at 0.93 mAP50 and 0.61 mAP50-95 on a dataset of ink-smear defects. The 0.93 looks line-ready. The 0.61 says that at IoU thresholds above 0.7, precision collapses — the model finds smears but boxes them loosely.

• Report only mAP50 → SPC baseline set at an implied ~93% quality. Live smear-sizing downstream uses the box extent; loose boxes mis-grade severity; escape rate breaches control limits within weeks; the team logs a “drift” investigation.
• Report both, and track mAP50-95 → baseline set at the honest 0.61, localisation flagged as the qualification blocker, model re-tuned or the sizing logic loosened before deployment; control limits set against behaviour the model can actually hold.

The numbers here are illustrative framing, not a measured benchmark — but the shape is one we see whenever a single headline figure is asked to stand in for two different qualities.

How should you report both metrics so teams share one language?

The practical fix is small and worth the discipline: report mAP50, mAP50-95, and the gap between them as a standing part of every validation summary, and give the gap a name your operations and ML teams both use. A large mAP50-to-mAP50-95 spread is a localisation warning; a small spread means the model places boxes about as well as it classifies them. When operations sees “mAP50 0.94 / mAP50-95 0.62 / spread 0.32,” that single line communicates more about line-readiness than either metric alone. The mechanics behind the averaged figure are unpacked in mAP in YOLO: What Mean Average Precision Means for Inspection Accuracy and the feasibility-reading angle in mAP50 Explained.

FAQ

What does working with mAP50 vs mAP50-95 involve in practice?

Both are mean-average-precision metrics for object detection, but they differ in how strictly they demand box overlap. mAP50 counts a detection as correct at 0.5 IoU — a loose bar. mAP50-95 averages precision across ten IoU thresholds from 0.5 to 0.95, so it rewards tight localisation. In practice, mAP50 tells you whether the model finds defects; mAP50-95 tells you whether it places them accurately.

What does the IoU threshold actually control, and why does mAP50 use 0.5 while mAP50-95 averages across 0.5 to 0.95?

IoU is the overlap between predicted and true boxes, and the threshold is the pass/fail line for scoring a detection as correct. mAP50 fixes that line at 0.5, tolerating shifted or oversized boxes. mAP50-95 sweeps the line from 0.5 to 0.95 and averages the results, so higher thresholds penalise loose boxes progressively harder, making the averaged figure dominated by localisation quality.

When would a model score high on mAP50 but poorly on mAP50-95, and what does that gap tell you about localisation quality?

The gap opens when the model classifies correctly but localises loosely — common with small, thin, or irregular defects, or in cluttered scenes. A box slightly too large still clears 0.5 IoU but fails above 0.7. A wide mAP50-to-mAP50-95 spread is a direct signal that the model knows what it sees but is imprecise about where.

Which metric should you track for a production CV inspection task, and how does that depend on whether defect position and extent matter?

Track mAP50-95 as the headline whenever anything downstream consumes the box coordinates or size — robotic rework, coordinate logging, severity grading, or SPC control limits. mAP50 alone is only safe when the output is a binary presence flag and no downstream step reads position or extent. When in doubt, report both.

How does the chosen accuracy metric become the baseline that SPC control limits are set against on the line?

When a model qualifies for a line, its validation accuracy is recorded as the baseline the monitoring harness watches for drift. Choosing mAP50 on a localisation-sensitive task anchors that baseline to an overstated quality number, so the live box jitter and sizing error it hid were never captured — and surface later as an apparent control-limit breach.

How can a misleading mAP50 headline show up later as drift or defect escapes inside the monitoring harness?

If the baseline overstates localisation quality, the first batch of awkwardly-placed or thin defects produces sizing and coordinate errors the baseline never accounted for, pushing the escape rate outside control limits. It looks like drift but is a localisation weakness baked in at validation — visible from day zero if mAP50-95 had been the tracked metric.

What is a practical way to report both metrics so operations and ML teams share one accuracy language?

Report mAP50, mAP50-95, and the spread between them as a standing line in every validation summary, and name the spread as a localisation-warning indicator. A single line like “mAP50 0.94 / mAP50-95 0.62 / spread 0.32” communicates line-readiness to both operations and ML teams more honestly than either figure alone.

The metric you print at the top of the validation report is not a scoreboard entry — it is the promise your SPC chart will be held to. Before you declare a CV inspection model line-ready, ask which of your downstream steps reads the box coordinates, and whether the number you are about to trust was ever asked to grade them.