mAP@50 is not a promise: reading detection metrics before you ship
On the document-intelligence system I built for my graduation project, the YOLO11 field detector reached 95.16% mAP@50, 68.45% mAP@75, and 62.69% mAP@50–95. Those three numbers describe the same model, and only one of them is the number people quote. Understanding why they diverge — and which of them the downstream pipeline actually cares about — changed how I evaluate detection models.
What the spread actually measures
mAP@50 counts a prediction as correct when it overlaps the ground-truth box by at least 50%. mAP@75 raises that bar to 75%. mAP@50–95 averages the thresholds from 50% to 95% in steps, so it rewards boxes that are not just correct but tight.
A large gap between mAP@50 and mAP@50–95 does not mean the model is missing objects. It means the model finds the right things and draws loose boxes around them. Those are different failures, and they cost different amounts depending on what happens next in the pipeline.
The downstream task decides which failure is expensive
In a form-processing pipeline, a detected field is not the output. It is a crop that gets handed to a recognition model. So the question is not 'how tight is this box' but 'does this crop contain everything the recognition model needs, and nothing that confuses it'.
That reframing inverts the usual intuition. A box that is slightly too large is usually harmless — the recognition model sees the full field plus a little whitespace. A box that is tight enough to score well on mAP@75 but clips a descender, a decimal point, or the first character of a handwritten value is a silent data-corruption bug. It scores better and performs worse.
- Loose box, full content: high recognition accuracy, low mAP@50–95.
- Tight box, clipped content: better mAP@50–95, corrupted downstream value.
- Missed field entirely: hurts every metric, and is the failure worth optimizing against.
What I measure instead
Detection metrics are a diagnostic, not an acceptance criterion. The acceptance criterion has to live at the end of the pipeline: for each field, did the system produce the value a human would have written down?
That end-to-end field accuracy is harder to compute and much harder to argue with. It absorbs detection, classification, recognition, and business-rule resolution into a single number that maps to the operational problem — the reason the system was commissioned in the first place.
Detection metrics still earn their place. They tell you where in the pipeline a regression came from. They just should not be the number on the slide.
A practical checklist
Before quoting a detection score, I now ask four questions.
- Does the downstream consumer need tight boxes, or complete ones? Pad the crop if the answer is 'complete'.
- Which IoU threshold corresponds to a crop the recognition model can still read? That is your real threshold, not 0.5 by convention.
- What is the end-to-end accuracy per field type? Averages hide the one field that is failing 40% of the time.
- What happens to a field the model is unsure about? If the answer is 'nothing', the metric is describing a system nobody should deploy.