A model card reports mAP@50 = 0.91 and the pilot proposal quietly rounds it to “catches about 90% of defects.” That translation is where most CV inspection scoping goes wrong. mAP@50 is a benchmark averaging device, not the accuracy your line will be judged on — and the gap between the two decides whether a pilot survives contact with the production floor. The number is real and useful. What it is not is a promise. mAP@50 averages precision across recall at a single, loose 0.50 IoU threshold. That threshold rewards a box that roughly overlaps the defect, and it says nothing about whether the model localises tightly enough for your smallest in-spec defect, nor whether false positives stay under the throughput ceiling. Reading it correctly is what turns a headline score into an honest, line-relevant accuracy band. How should you think about mAP@50 in practice? Break the acronym down and the caveats fall out on their own. AP — average precision. For one class, a detector produces boxes each carrying a confidence score. Sweep the confidence threshold from high to low, and at every step you can compute precision (of the boxes you accepted, how many were correct) and recall (of the real defects present, how many you caught). Plot precision against recall and you get a curve. Average precision is the area under that curve — a single number summarising the precision/recall trade-off across all operating points. mAP — mean average precision. Compute AP for each defect class, then average across classes. That is the “mean” part. It gives every class equal weight regardless of how frequent or how visually distinct it is. @50 — the IoU threshold that decides “correct.” Here is the part that gets glossed over. To count a predicted box as a true positive, it must overlap the ground-truth box by at least an Intersection-over-Union (IoU) of 0.50. That is a loose bar. A box can miss half the defect’s extent and still count as a hit. So mAP@50 is the mean, across your defect classes, of the area under each class’s precision/recall curve, where “correct” means only 50% box overlap. It is a legitimate model-comparison metric — the same one you see quoted for YOLO and R-CNN family detectors on COCO and Pascal VOC. It is not the detection rate your line runs at, and treating the two as interchangeable is the failure this article exists to prevent. For the mechanics of how detectors produce those boxes in the first place, our explainer on how an image detection model works in industrial inspection covers the pipeline that feeds the metric. What does the 0.50 IoU threshold hide about localisation quality? IoU at 0.50 is generous by design — it was chosen so that early object detectors would score anything at all. On natural-image benchmarks, a box that covers roughly the right region is good enough for a human to agree “yes, that’s a dog.” Defect inspection is a different problem. Consider a hairline scratch, a solder void, or a print smear a few pixels across. A predicted box centred on the general area but oversized by 40% still clears IoU 0.50. On a benchmark that counts as a perfect detection. On the line, that same loose box may: straddle two adjacent parts, making the downstream reject/pass logic ambiguous; fail to localise the defect tightly enough for a measurement-based tolerance check; inflate the apparent detection rate for defects the imaging chain barely resolves. The stricter the localisation your process actually requires, the less mAP@50 tells you. This is why the same model reported at mAP@[.50:.95] — averaging IoU thresholds from 0.50 to 0.95 in steps — often looks dramatically worse: the higher-IoU terms punish exactly the sloppy boxes that mAP@50 forgives. If your defect class needs tight boxes, mAP@[.50:.95] is the more honest headline. We walk through that trade-off directly in mAP50 vs mAP50-95 for reading CV inspection metrics on the line. How is mAP@50 computed from precision and recall across classes? The computation order matters because averaging hides variance at two levels — across confidence thresholds and across classes. Match predictions to ground truth per image at IoU ≥ 0.50. Each ground-truth box can be claimed by at most one prediction; extra overlapping boxes are false positives. Rank all predictions for a class by confidence, then walk down the list computing running precision and recall. Integrate the precision/recall curve to get AP for that class (interpolation conventions differ slightly between Pascal VOC and COCO, which is why the same model can post two slightly different mAP numbers). Average AP across all classes to get mAP@50. The consequence for inspection: a model with strong AP on a dominant, easy defect class and weak AP on a rare, safety-critical class can still post a respectable mAP@50. The average launders the weak class. In a benchmark that is fine. On a line where the rare class is the one that triggers a recall, the average is misleading. This is an observed-pattern we see repeatedly when auditing pilot metrics — the headline mAP@50 looks healthy while one critical class sits below usable recall. The fix is never a single number; it is a per-class breakdown, which is also the core argument in our companion piece on what mean average precision means for inspection accuracy. Why can a high mAP@50 still mean poor detection of your smallest defect? Two mechanisms, and they compound. The first is the class-averaging effect above: your smallest in-spec defect is usually the hardest class, so its weak AP gets absorbed into the mean. The second is the imaging margin. A detector cannot recover a signal the camera and lighting never captured. If a 30-micron defect projects onto fewer than a couple of pixels at your working distance and sensor resolution, no amount of model tuning produces a stable detection — the signature simply is not in the frame. A benchmark dataset collected under favourable, high-resolution conditions can show mAP@50 = 0.9 for a defect class that, on your imaging chain, is fundamentally under-resolved. This is the divergence point that scoping teams miss. mAP@50 measures the model against the dataset it was tested on. It cannot tell you whether your imaging chain resolves the defect signature at line speed. That is why we treat achievable accuracy as a property of the whole pipeline — optics, sensor, lighting, and model together — not of the model alone. Our computer vision practice exists precisely to reason about that full chain rather than a detached benchmark number. How does mAP@50 relate to the detection and false-positive rates a line is judged on? A production line is judged on two operational numbers, per defect class: Detection rate (recall) at a fixed operating point — of the defects that occur, what fraction does the deployed system flag, at the single confidence threshold you actually run. False-positive rate at that same operating point — how many good parts get flagged, which sets rework load and operator trust. mAP@50 collapses the entire precision/recall curve into one area-under-curve number. But a line does not run on a curve — it runs on one chosen point on that curve. Two models with identical mAP@50 can behave completely differently at the operating point you need, because one curve may be strong in the high-recall region and the other strong in the high-precision region. The averaging metric cannot distinguish them; your line will. There is also a throughput ceiling. Every false positive costs a rework decision, and above some rate the line either slows or operators start ignoring alerts. So the real target is not “maximise mAP@50” but “hold detection rate ≥ X for each class while keeping false positives under the budget the line can absorb at speed.” Decision surface: which detection metric to report when You need to… Report Why Compare two candidate models quickly mAP@50 Single averaged number, standard across YOLO/R-CNN benchmarks; fine for ranking Judge localisation tightness mAP@[.50:.95] Averages strict IoU thresholds; punishes loose boxes mAP@50 forgives Commit to a pilot acceptance criterion Per-class detection rate + false-positive rate at the operating point This is the number the line is actually judged on Assess a safety-critical rare defect Per-class AP + recall for that class alone Class-averaging hides weak rare-class performance Bound what any model can reach on your optics Imaging-margin analysis (pixels-on-defect) before any mAP number A signal the camera never captured cannot be detected The rule of thumb: mAP@50 for model selection, per-class detection and false-positive bands for pilot acceptance. Confusing the two is the single most common scoping error we correct. For a deeper read of mAP50 specifically as a feasibility signal, see mAP50 explained: reading the detection metric for inspection-line feasibility. How do camera and imaging-chain choices cap the mAP@50 you can reach? This is the constraint that outranks the model. Before a single training epoch runs, the optics fix a ceiling on achievable accuracy for each defect class. The governing quantity is pixels-on-defect: the physical size of the defect divided by the ground-sample distance (how many microns each pixel covers). Push that below a few pixels and the defect stops being a stable, learnable signature and becomes indistinguishable from sensor noise, JPEG artefacts, or surface texture. Lighting geometry compounds it — a scratch invisible under diffuse light can be obvious under grazing illumination, and vice versa. Motion blur at line speed erodes it further. None of this appears in a benchmark mAP@50. The benchmark tested one imaging condition; your line is another. The honest way to scope a pilot is to establish the imaging margin first, derive the accuracy band the optics permit, and only then ask what mAP@50 a model can reach against that ceiling. Fine-tuning helps within the margin the imaging chain allows — never beyond it, as we discuss in fine-tuning YOLO for manufacturing-line defect detection. FAQ How does mAP@50 actually work? mAP@50 is the mean, across your defect classes, of the area under each class’s precision/recall curve, where a predicted box counts as correct if it overlaps the true box by at least 50% (IoU 0.50). It is a legitimate metric for comparing and ranking detectors, but it is an averaged benchmark number, not the detection rate a specific line runs at. Treating a headline mAP@50 as “catches that fraction of defects” is the core scoping error to avoid. What does the 0.50 IoU threshold actually measure, and what does it hide about localisation quality? IoU 0.50 requires only 50% box overlap to count a detection as correct, which is deliberately loose. It rewards roughly-placed boxes and hides whether the model localises tightly enough for small or measurement-critical defects. mAP@[.50:.95], which averages stricter IoU thresholds, punishes the sloppy boxes mAP@50 forgives and is the more honest headline when tight localisation matters. How is mAP@50 computed from precision and recall across classes and confidence thresholds? Predictions are matched to ground truth at IoU ≥ 0.50, ranked by confidence, and used to trace a precision/recall curve whose area is that class’s average precision; the mean of those AP values across classes gives mAP@50. Because it averages twice — across confidence thresholds and across classes — a strong dominant class can mask a weak rare one, so a per-class breakdown is always more informative than the single number. Why can a high mAP@50 on a benchmark still mean poor detection of your smallest in-spec defect on the line? Two reasons compound: class-averaging absorbs the weak AP of your hardest (usually smallest) defect class into a healthy-looking mean, and the imaging margin sets a hard ceiling the model cannot beat. If the defect projects onto too few pixels on your camera and lighting setup, the signature isn’t in the frame at all, so a benchmark score from favourable imaging conditions does not transfer to your line. How does mAP@50 relate to the per-defect-class detection rate and false-positive rate a line is actually judged on? mAP@50 collapses the whole precision/recall curve into one area-under-curve number, but a line runs at a single chosen operating point on that curve. Two models with identical mAP@50 can behave very differently at the point you need, so the operational targets are per-class detection rate and false-positive rate at your fixed threshold, kept under the throughput ceiling. Use mAP@50 for model selection, per-class bands for pilot acceptance. When should you report mAP@50, mAP@[.50:.95], or a per-class detection/false-positive band instead? Report mAP@50 to compare and rank candidate models quickly, mAP@[.50:.95] to judge localisation tightness, and per-class detection/false-positive bands at the operating point when committing to a pilot acceptance criterion. For safety-critical rare defects, report that class’s AP and recall alone rather than any average, because averaging hides weak rare-class performance. How do camera and imaging-chain choices cap the mAP@50 a model can realistically reach on your defect classes? Pixels-on-defect — defect size divided by how many microns each pixel covers — sets a ceiling before any training runs; below a few pixels the defect blends into noise and cannot be learned reliably. Lighting geometry and motion blur at line speed tighten that ceiling further. None of it shows in a benchmark mAP@50, so the honest sequence is to establish the imaging margin first and only then ask what score a model can reach against it. Where this leaves a scoping team mAP@50 earns its place as a fast, standard way to rank detectors. The mistake is asking it to do a job it was never built for: predicting the detection and false-positive rates your line will run at, on your optics, at your speed. Those numbers come from a per-defect-class band grounded against the imaging chain, not from a single benchmark headline. If you are staring at a model card and trying to decide whether 0.91 is good enough, the more useful question is: good enough for which defect class, at which operating point, under which imaging margin? Answering that is exactly what a vision-pipeline feasibility audit does — it reports achievable accuracy as a per-class detection and false-positive band, so the metric is anchored to the physics of your line rather than to someone else’s dataset. Our services page is the starting point when a metric question turns into a feasibility question.
