For pre-trained detection models, the key metrics are Precision, Recall, and F1 score. These models find objects in images, so we want to know how many detected objects are correct (Precision) and how many real objects were found (Recall). The F1 score balances both. Also, mean Average Precision (mAP) is often used to measure overall detection quality across classes and thresholds.
Pre-trained detection models in Computer Vision - Model Metrics & Evaluation
| Predicted Object | Predicted No Object |
|------------------|---------------------|
| True Positive (TP)| False Negative (FN) |
| False Positive (FP)| True Negative (TN) |
TP: Correctly detected objects
FP: Wrong detections (false alarms)
FN: Missed objects
TN: Correctly ignored background
Precision = TP / (TP + FP)
Recall = TP / (TP + FN)
If the model is very strict, it detects fewer objects but with high confidence. This means high precision but low recall. For example, in security cameras, you want to avoid false alarms (high precision).
If the model detects many objects, including uncertain ones, it has high recall but low precision. For example, in wildlife monitoring, missing an animal is worse, so high recall is preferred.
The F1 score helps balance these two depending on the use case.
Good: Precision and Recall both above 0.8, F1 score near 0.85 or higher, and mAP above 0.75. This means the model finds most objects correctly and misses few.
Bad: Precision below 0.5 means many false detections. Recall below 0.5 means many missed objects. Low F1 and mAP indicate poor detection quality.
- Accuracy paradox: High accuracy can be misleading if most images have no objects (TN dominate).
- Data leakage: Using test images in training inflates metrics falsely.
- Overfitting: Very high training metrics but low test metrics show poor generalization.
- Ignoring IoU threshold: Detection quality depends on Intersection over Union threshold; metrics vary with it.
Your pre-trained detection model has 98% accuracy but only 12% recall on detecting cars. Is it good for production? Why or why not?
Answer: No, it is not good. The high accuracy is misleading because most images may not have cars, so the model correctly predicts no car often (TN). The very low recall means it misses most cars, which is bad for detection tasks where finding objects is critical.
Practice
pre-trained detection model in computer vision?Solution
Step 1: Understand what pre-trained models do
Pre-trained detection models are trained on large datasets and can detect objects without retraining.Step 2: Compare options with this fact
It allows detecting objects without needing to train the model from scratch. correctly states the main advantage: no need to train from scratch. Other options are incorrect or too specific.Final Answer:
It allows detecting objects without needing to train the model from scratch. -> Option AQuick Check:
Pre-trained means ready-to-use without training [OK]
- Thinking pre-trained models always have perfect accuracy
- Believing pre-trained models need no images
- Assuming pre-trained models detect only one object type
Solution
Step 1: Recall PyTorch torchvision syntax for pre-trained detection models
The correct method is to call the model constructor with pretrained=True argument.Step 2: Check each option
model = torchvision.models.detection.fasterrcnn_resnet50_fpn(pretrained=True) matches the correct syntax. Options A and B use invalid functions. model = torchvision.models.fasterrcnn_resnet50_fpn() misses pretrained=True, so model is untrained.Final Answer:
model = torchvision.models.detection.fasterrcnn_resnet50_fpn(pretrained=True) -> Option CQuick Check:
Use model constructor with pretrained=True [OK]
- Using nonexistent functions like load_model or load
- Forgetting pretrained=True argument
- Calling model without detection namespace
outputs?
import torchvision model = torchvision.models.detection.fasterrcnn_resnet50_fpn(pretrained=True) model.eval() inputs = [image_tensor] outputs = model(inputs)
Solution
Step 1: Understand output format of torchvision detection models
These models return a list of dictionaries, one per input image, with keys like 'boxes', 'labels', and 'scores'.Step 2: Match output type with options
A list of dictionaries, each containing detected boxes, labels, and scores. correctly describes this output. Other options describe incorrect or incomplete formats.Final Answer:
A list of dictionaries, each containing detected boxes, labels, and scores. -> Option AQuick Check:
Detection model outputs list of dicts with boxes, labels, scores [OK]
- Expecting a single tensor instead of list
- Missing 'scores' key in output
- Thinking output crops images automatically
RuntimeError: Expected 4-dimensional input. What is the most likely cause?Solution
Step 1: Understand input shape requirements for detection models
Detection models expect input tensors with shape [batch_size, channels, height, width], i.e., 4 dimensions.Step 2: Identify cause of 4D input error
If input lacks batch dimension (only 3D), this error occurs. The input image tensor is missing the batch dimension. matches this cause. Other options do not cause this error.Final Answer:
The input image tensor is missing the batch dimension. -> Option BQuick Check:
Input must have batch dimension (4D tensor) [OK]
- Ignoring batch dimension requirement
- Confusing pretrained loading with input shape
- Assuming grayscale causes dimension error
Solution
Step 1: Understand pre-trained model adaptation options
Pre-trained models detect many classes. To focus on some, filtering outputs is easiest and fastest.Step 2: Evaluate each option
Filter the model's detected labels to keep only 'car' and 'person' classes after prediction. filters predictions after detection, which is practical. Retrain the entire model from scratch with only car and person images. is costly retraining. Modify the model architecture to remove other classes before loading weights. is complex and not standard. Use the model without any filtering; it will detect only cars and people automatically. is incorrect; model detects all classes by default.Final Answer:
Filter the model's detected labels to keep only 'car' and 'person' classes after prediction. -> Option DQuick Check:
Filter outputs to select desired classes [OK]
- Thinking retraining is always needed
- Trying to change model architecture directly
- Assuming model detects only desired classes by default
Ready to prove it?
Pass the test and this pattern moves unknown
