A detector reporting mAP@50 = 0.90 looks finished. Then someone measures the part inside the box, and the number that matters drifts. The single mAP@50 score never captured the problem, because a box only had to overlap the ground truth by half to count as correct — and half is a generous bar when the box geometry is doing real work downstream. That is the practical gap between the two metrics every object-detection report shows. mAP@50 asks whether the detector found the object. mAP@50-95 asks whether it found the object and drew a tight, well-placed box around it. Reading them together — specifically, reading the size of the gap between them — is how you tell a model that detects from a model that localises. What does mAP@50 actually measure? Mean Average Precision at an IoU threshold of 0.50 counts a predicted box as a true positive if its Intersection over Union with the matching ground-truth box is at least 0.50. IoU is the overlap area divided by the union area; at 0.50, the two boxes need to share half their combined footprint. That is easier to hit than it sounds. A box that is too large, captures a slice of background, or clips a neighbouring object can still clear 0.50 and register as a clean detection. For many workloads that is fine. If the task is “is there a person in this frame” or “flag every pallet in the aisle,” a loose box that reliably lands on the object is a correct answer. mAP@50 is the right metric when detection presence — not box geometry — is what the pipeline consumes. If you want the mechanics of that single-threshold number in isolation, we walk through it in [email protected] explained: what mAP50 measures and how to read it in practice. The trap is treating a high mAP@50 as proof the detector is production-ready for tasks it was never scored against. The 0.50 bar hides localisation error by design. You need a stricter instrument to see it. How is mAP@50-95 computed, and why is it stricter? mAP@50-95 (the primary COCO metric, sometimes written mAP@[.50:.95]) is the average of the mAP computed at ten IoU thresholds: 0.50, 0.55, 0.60, and so on up to 0.95, in steps of 0.05. A prediction that clears 0.50 but sits at 0.62 IoU counts as a hit at the first three thresholds and a miss at the remaining seven. Its contribution to the averaged score collapses. Because the average pulls in thresholds up to 0.95 — where the predicted and ground-truth boxes must nearly coincide — the metric only stays high when boxes are consistently tight. A detector cannot fake mAP@50-95 with loose-but-present boxes. It has to place edges accurately, repeatedly, across the whole dataset. That is why COCO adopted it as the headline number rather than the single 0.50 threshold PASCAL VOC used, and why medical-device CV validation leans on it — a point we develop in mAP50-95 explained: the detection metric behind medical-device CV validation. The mechanical relationship is fixed: mAP@50 is always greater than or equal to mAP@50-95, because 0.50 is the loosest of the ten thresholds being averaged. The interesting information is not either number alone. It is the distance between them. What does a large gap tell you about localisation? The gap between mAP@50 and mAP@50-95 is a localisation-quality diagnostic. A small gap means boxes that clear the presence bar are also tight — the detector places edges well. A large gap means the detector finds objects but draws boxes that would not survive a stricter overlap requirement. Consider a worked example. Two detectors are evaluated on the same validation set: Metric Detector A Detector B mAP@50 0.90 0.88 mAP@50-95 0.78 0.55 Gap (50 minus 50-95) 0.12 0.33 Reading Tight boxes; localises well Detects but localises poorly (Illustrative figures, not a benchmark result — chosen to show how the gap, not the headline score, carries the localisation signal.) Detector B looks nearly as good as A on mAP@50. Judged on that number alone, you might ship it. But its mAP@50-95 of 0.55 against a 0.88 presence score exposes a 0.33 gap: its boxes are loose. In deployment that surfaces as false positives and non-maximum-suppression merge errors in dense scenes, where loose boxes overlap and NMS either suppresses a real detection or fuses two objects into one. It also surfaces as measurement drift wherever box geometry drives a downstream figure — the diagonal length of a part, the centroid used for tracking hand-off, the pixel-to-millimetre conversion feeding a dimensional check. The 0.33 gap is not a rounding artifact. It is quantified localisation headroom: the accuracy that a tighter-geometry model could recover. How do loose axis-aligned boxes on rotated or packed objects show up? The gap widens predictably on two object classes. The first is rotated targets. An axis-aligned bounding box (AABB) drawn around a diagonally oriented part must enclose the whole object, which means it swallows a triangular wedge of background at each corner. That box can clear IoU 0.50 comfortably while sitting far below 0.90 — so it scores fine on mAP@50 and poorly on mAP@50-95. The failure is geometric, not a training deficiency: an axis-aligned box simply cannot fit a rotated object tightly. We treat that constraint directly in rotated bounding box detection explained: when orientation matters in inspection, and the architectural decision of where box geometry is chosen sits in the detection head explained: where AABB vs oriented box geometry is decided. The second is packed scenes. When objects sit shoulder to shoulder — bottles on a shelf, parts in a tray — a slightly loose box overlaps its neighbours. At IoU 0.50 the detector still gets credit; at 0.75 and above the overlap with the true object drops as the box borrows area from adjacent objects. Dense-scene benchmarks amplify this exactly because clean separation is the whole task. If you see a healthy mAP@50 collapse at higher thresholds specifically on your densest validation images, the gap is telling you NMS is about to fail in production. A common pattern in engagements we have supported is that teams first notice the problem not in the metric but in the symptom — a counting error, a tracker that swaps IDs — and only then go back and read the mAP@50-95 gap that predicted it. Reading the gap up front is cheaper. Which metric should you optimise, and which should you report? The decision hinges on what the pipeline downstream of the detector consumes. If the downstream stage needs… Optimise for Report Object presence only (does it exist, roughly where) mAP@50 mAP@50 Box geometry (measurement, dimensioning) mAP@50-95 Both, lead with 50-95 Clean separation in dense scenes mAP@50-95 Both, plus per-image high-IoU breakdown A tracker consuming detections mAP@50-95 Both — loose boxes break association When comparing detectors for a production deployment, report both numbers. The single mAP@50 figure invites the reader to overrate a loose model; the single mAP@50-95 figure hides whether a poor score comes from missed objects (a recall problem) or loose boxes (a localisation problem). Together they separate those two failure modes, which need different fixes — more data or a better backbone for recall, tighter geometry for localisation. The broader menu of detection metrics and how they interact lives in our object detection metrics explained: precision, recall, mAP and IoU, and if you are reading these numbers inside a YOLO training run specifically, mAP in YOLO: how mean average precision scores object detectors covers the reporting conventions. Building a detector where box geometry actually feeds a decision is a computer vision engineering problem, not a leaderboard problem — the metric only earns its keep when it maps to the number your deployment cares about. FAQ How does map50 vs map50-95 work in practice? mAP@50 counts a detection as correct if its box overlaps the ground truth by at least 50% IoU; mAP@50-95 averages that measurement across ten IoU thresholds from 0.50 to 0.95. In practice mAP@50 tells you whether the detector found objects, while mAP@50-95 tells you whether it drew tight boxes around them. Read the two together — the gap between them is the localisation-quality signal. What does mAP@50 actually measure, and why is a 0.50 IoU threshold a loose bar? It measures detection at a single overlap threshold: a predicted box is a true positive if it shares at least half its combined area with the ground-truth box. That bar is loose because a box that is oversized, captures background, or clips a neighbour can still clear 0.50 and count as a clean hit. mAP@50 therefore hides localisation error by design. How is mAP@50-95 computed across the 0.50-0.95 IoU range, and why is it stricter? It is the average of the mAP computed at ten IoU thresholds — 0.50, 0.55, up to 0.95 in 0.05 steps. Because the average includes thresholds near 0.95, where boxes must almost coincide with the ground truth, the score only stays high when boxes are consistently tight. A detector cannot inflate it with loose-but-present boxes. What does a large gap between mAP@50 and mAP@50-95 tell you about localisation quality? A large gap means the detector finds objects but places loose boxes that would fail a stricter overlap requirement. A model at mAP@50 = 0.90 and mAP@50-95 = 0.55 has a 0.35 gap, which is quantified localisation headroom — accuracy a tighter-geometry model could recover. A small gap means boxes that clear the presence bar are already tight. Which metric should you optimise for when box geometry feeds a downstream measurement or dense scene? Optimise for mAP@50-95. When box geometry drives a measurement — a dimension, a centroid, a pixel-to-millimetre conversion — or when dense scenes need clean separation for NMS and tracking, loose boxes cause measurement drift and merge errors. mAP@50-95 is the metric that rewards the tight localisation those tasks depend on. How do loose axis-aligned boxes on rotated or packed objects show up in these metrics? They show up as a widening gap: a healthy mAP@50 that collapses at higher IoU thresholds. An axis-aligned box around a rotated part must enclose background at the corners, so it clears 0.50 but scores poorly above 0.75; packed objects cause boxes to borrow area from neighbours, dropping high-IoU overlap. The metric predicts the NMS and counting failures those geometries cause in production. Which metric should you report when comparing detectors for a production deployment? Report both. mAP@50 alone lets a loose model look production-ready; mAP@50-95 alone hides whether a low score comes from missed objects or loose boxes. Together they separate a recall problem from a localisation problem, and those need different fixes — more data or a better backbone for recall, tighter geometry for localisation. Where the gap points next The mAP@50-95 gap does not tell you what to do — it tells you where the accuracy is hiding. When the gap is large and concentrated on rotated or packed targets, the fix is usually geometric rather than statistical: an oriented-box detection head recovers the localisation that an axis-aligned model structurally cannot. Whether that trade is worth its cost is a deployment question, and it is the exact question a line-side inspection feasibility assessment weighs when it asks whether off-the-shelf detection geometry survives contact with production parts. Before you retrain anything, read the gap on your densest, most-rotated validation images — that is where the number that matters will move first.
