In our earlier weblog publish on this sequence, we mentioned state-of-the-art fashions for object detection: the architectures, the idea, and what makes YOLO12, YOLO26, and RF-DETR tick. If you need the theoretical background on these fashions, begin there.
This publish is the sensible follow-up: learn how to really use these fashions, learn how to fine-tune them on numerous, specialised datasets that look nothing like their coaching knowledge, and learn how to consider the outcomes – all inside PyCharm.
Why fine-tune in any respect?
Each pretrained detector you obtain was skilled on some distribution of photos, nearly all the time COCO, which is ~118k coaching photos of on a regular basis scenes containing 80 widespread object classes (folks, vehicles, canine, chairs, and so forth.).
Actual-world deployment knowledge not often seems like COCO. Issues that object detection may really be utilized to, equivalent to broken industrial cables, bone fractures on X-rays, or densely stacked soda bottles on a shelf, are:
- Out of vocabulary: “Bone fracture” shouldn’t be certainly one of COCO’s 80 courses, so the mannequin actually has no output class for it.
- Out of visible distribution: X-ray imagery, industrial close-ups, and closely occluded shelf scenes differ drastically from shopper images in texture, viewpoint, and object density.
Deploying a detector on off-distribution knowledge due to this fact requires fine-tuning. However earlier than we break the fashions, let’s set up that we get comparable outcomes on our {hardware} to those reported by builders.
The fashions
For the needs of this experiment, we’ll give attention to three present SOTA object detection households and look at two sizes of every mannequin:
Sanity examine: Reproducing COCO val2017 baselines
We’re going to be working with six pretrained checkpoints: Two completely different sizes of every of the three fashions. To examine that these fashions are behaving as anticipated, we evaluated all of them on the total 5,000-image COCO validation dataset (val2017) to confirm the numbers reported within the earlier publish:
| Mannequin | Params (M) | mAP50 | mAP50-95 | Latency (ms) |
|---|---|---|---|---|
| YOLOv12-N | 2.55 | 0.5548 | 0.4021 | 23.9 |
| YOLO26-N | 2.57 | 0.5498 | 0.3952 | 12.3 |
| YOLOv12-M | 19.67 | 0.6953 | 0.5259 | 72.4 |
| YOLO26-M | 21.90 | 0.6906 | 0.5181 | 13.9 |
| RF-DETR Nano | 30.47 | 0.6750 | 0.4835 | 12.4 |
| RF-DETR Base | 32.17 | 0.7210 | 0.5325 | 12.9 |
Three issues stand out even earlier than we go away COCO behind:
- Bigger fashions (principally) have higher efficiency. RF-DETR Base leads (0.5325 mAP50-95), however the medium YOLOs get remarkably shut (0.5259 / 0.5181) with ~10M fewer parameters.
- YOLO26’s NMS-free design pays off in throughput. YOLO26-N is the quickest mannequin within the lineup (12.3 ms latency) at primarily the identical mAP50-95 as YOLOv12-N, which, regardless of being the smallest mannequin right here, is significantly slower (23.9 ms latency). Consideration is pricey. (If you need extra element on the mannequin architectures and the way they have an effect on efficiency, see the earlier weblog publish on this sequence.)
- RF-DETR Nano shouldn’t be “nano” by parameter depend (~30M – greater than YOLO26-M), however it’s well-optimized: With 12.4 ms latency, it’s the second-fastest total.
Revealed papers report optimized inference latency: That’s, they measure the mannequin’s ahead move in isolation, stripped of the encircling levels of the thing detection pipeline. We intentionally skipped that aggressive optimization so our numbers mirror what you’d really see when deploying these fashions.
In consequence, our latency figures don’t line up with the benchmarks within the fashions’ white papers. There are two essential causes for this:
- {Hardware}: We used completely different {hardware} from the NVIDIA T4 GPU that serves because the de facto commonplace in object detection benchmarking.
- Unoptimized computation graph: We ran the fashions of their native framework moderately than changing them to TensorRT. TensorRT compiles a community right into a hardware-specific engine, fusing layers, choosing the quickest kernels for the goal GPU, and optionally operating in lowered precision. That may reduce latency considerably, however the ensuing engine is tied to 1 GPU and requires an additional construct step, so it doesn’t symbolize how these fashions carry out out of the field.
Accuracy is a unique story: Whereas our latencies diverge from the revealed ones, our mAP50-95 outcomes fall inside cheap noise bounds of the reported figures.
Now that we’ve seen what our pretrained fashions can do on COCO, the dataset they have been skilled on, let’s see what occurs after they’re examined off distribution.
The datasets
For analysis, we used RF100-VL, a large-scale assortment of 100 multimodal datasets protecting ideas intentionally chosen to be uncommon in object detection fashions’ pretraining knowledge. These datasets comprise precisely the off-distribution targets we care about. These targets additionally mirror widespread real-life purposes for object detection, giving us a sensible take a look at of those fashions’ capabilities out within the wild.
We picked three datasets that stress take a look at the fashions in several methods:
| Dataset | Area | Why it’s onerous | Courses |
|---|---|---|---|
cable-damage |
Technical/industrial | High quality-grained injury varieties on visually comparable backgrounds | break, thunderbolt |
bone-fracture |
Medical (X-ray) | Solely completely different imaging modality; delicate options | angle, fracture, line, messed_up_angle |
soda-bottles |
Retail | Heavy occlusion, many near-identical cases per picture | coca-cola, fanta, sprite |
Tutorial: High quality-tuning all three fashions in PyCharm 🙂
Step 1: Establishing the challenge
One of many first challenges we needed to overcome on this challenge was that the three implementations do not share a suitable set of dependencies. Specifically, the 2 completely different generations of YOLO require completely different variations of the ultralytics package deal. PyCharm presents a clear answer for this: one PyCharm challenge with three remoted uv environments – one per mannequin household.
We’ll run our computations on a distant GPU. Configuring a distant interpreter in PyCharm follows the identical workflow as a neighborhood one: the identical dialog and the identical dropdown as within the native case. Be aware that distant interpreters require PyCharm Skilled; Group Version helps native environments solely.
Firstly, we have to instantiate our three uv digital environments through:
cd yolov12 && uv venv .venv --python 3.11 cd yolov26 && uv venv .venv --python 3.11 cd rf-detr && uv venv .venv --python 3.11
As soon as your uv digital environments exist, register every one as an present interpreter. Go to Settings | Python | Interpreter, click on Add Interpreter → Add Native Interpreter, select Atmosphere as Choose present, and level the interpreter subject at that atmosphere’s bin/python. PyCharm doesn’t create something right here, it simply picks up the atmosphere uv already constructed.
Repeat for every atmosphere. From then on, switching is a matter of selecting one from the Settings | Python | Interpreter dropdown, or from the interpreter widget within the bottom-right-hand standing bar.

You’ll find the total listing of dependencies required for every mannequin of their respective challenge repositories. You’ll be able to both set up all of the tasks’ dependencies in PyCharm’s built-in Terminal instrument window or set up particular person packages utilizing the Python Packages instrument window (together with choosing particular variations of packages). You’ll be able to entry each of those instrument home windows by clicking the related icons within the decrease left-hand nook of the PyCharm toolbar.

For a step-by-step information on organising the environments for all three fashions, see our GitHub implementation of this tutorial.
Step 2: Getting the datasets
To acquire the out-of-COCO-distribution datasets, we will set up our datasets through the rf-detr digital atmosphere, because it has roboflow as certainly one of its core dependencies. We then set the Roboflow API key as an atmosphere variable in order that it’s out there to the API when downloading the datasets.
pip set up roboflow export ROBOFLOW_API_KEY="your_key_here" # you will get API key right here: https://docs.roboflow.com/reference/authentication/authentication/find-your-roboflow-api-key
After setting every part up, now you possibly can run the Python script beneath to get the three datasets we’re going to make use of in our tutorial:
import os
from roboflow import Roboflow
api_key = os.environ.get("ROBOFLOW_API_KEY")
if not api_key:
elevate RuntimeError("ROBOFLOW_API_KEY shouldn't be set")
DATASETS = [
"bone-fracture-7fylg",
"cable-damage",
"soda-bottles",
]
VERSION = 2 # RF100 tasks are typically revealed at model 2
FORMAT = "yolov8" # or "coco", "voc", "yolov5"
rf = Roboflow(api_key=api_key)
workspace = rf.workspace("rf100")
for slug in DATASETS:
print(f"Downloading {slug} ...")
attempt:
challenge = workspace.challenge(slug)
dataset = challenge.model(VERSION).obtain(FORMAT)
print(f" -> {dataset.location}")
besides Exception as e:
print(f" !! failed: {e}")
This script connects to the Roboflow cloud service through its Python API consumer and downloads three specified RF100 datasets in YOLOv8 format. It loops by means of every dataset, reviews the place profitable downloads are saved, and prints an error if any obtain fails.
Step 3: Getting a zero-shot baseline by utilizing pretrained fashions on customized knowledge
Earlier than fine-tuning, we’re going to judge the COCO-pretrained checkpoints immediately on our three datasets, to see whether or not the fine-tuning is definitely mandatory. The outcome was unambiguous: The fashions predicted primarily nothing.
Zero-shot mAP50-95 on the take a look at splits of our three datasets:
| Mannequin | cable-damage |
bone-fracture |
soda-bottles |
|---|---|---|---|
| RF-DETR Nano | 0.0004 | 0.0000 | 0.0027 |
| RF-DETR Base | 0.0005 | 0.0000 | 0.0004 |
| YOLOv12-N | 0.0007 | 0.0000 | 0.0266 |
| YOLO26-N | 0.0000 | 0.0000 | 0.0033 |
| YOLOv12-M | 0.0000 | 0.0000 | 0.0160 |
| YOLO26-M | 0.0000 | 0.0000 | 0.0012 |
That is to be anticipated; it’s not a bug! Because the fashions are closed-vocabulary detectors, that’s, they’ve a finite variety of predefined goal courses, they bodily can not output a category like fracture that isn’t of their 80-class COCO head.
That is the punchline of this complete publish: A mannequin scoring 0.72 mAP50 on COCO scores 0.00 on bone fractures. Pretrained ≠ deployable, even when the mannequin is state-of-the-art. Fundamental machine studying ideas nonetheless apply, even within the age of AI!
Step 4: High quality-tuning
All fashions have been fine-tuned on a single A100 GPU for 10 epochs. We used commonplace Ultralytics/RF-DETR fine-tuning pipelines so as to fine-tune the fashions on our three datasets. We fine-tuned a mannequin for every dataset. The total fine-tuning pipeline will be present in finetune_rf100.py scripts within the challenge repo, below the folders for every mannequin.
You’ll be able to see the core of the coaching setup beneath. Each YOLO and RF-DETR are constructed on PyTorch below the hood, however the coaching loops are abstracted behind higher-level library APIs: Ultralytics’ YOLO.practice() for the YOLO fashions, and RF-DETR’s personal practice() performance.
YOLO12 and YOLO26
train_model = YOLO(args.mannequin) train_res = train_model.practice( knowledge=str(yaml_path), epochs=args.epochs, imgsz=args.imgsz, batch=args.batch, machine=args.machine, challenge=args.challenge, title=run_name, exist_ok=True, verbose=False, )
RF-DETR
ModelClass().practice( dataset_dir=str(coco_dir), output_dir=str(output_dir), epochs=args.epochs, batch_size=args.batch_size, grad_accum_steps=args.grad_accum, lr=args.lr, decision=decision, early_stopping=True, checkpoint_interval=1, )
Step 5: Outcomes
High quality-tuning transforms the image. You’ll be able to see the outcomes on the take a look at set after coaching:

On the left, we now have the pretrained fashions’ outcomes for the COCO validation dataset. As we confirmed earlier, accuracy (mAP50-95) fell between 0.39 and 0.53, and all fashions aside from YOLOv12-M confirmed low latency. The fine-tuned fashions on the best confirmed an identical vary of accuracy for the cable-damage and soda-bottle detection duties, solely falling decrease for the bone-fracture process. Furthermore, the fine-tuned fashions have been comparable in latency to the pretrained fashions for his or her supposed duties, and for YOLOv12-M, they have been even sooner. This means that, after fine-tuning to the goal area, the fashions obtain efficiency that’s broadly akin to the pretrained efficiency on their authentic coaching area.
Let’s now have a more in-depth have a look at the fine-tuned fashions’ efficiency, breaking it down by mAP50 and mAP50-95 for the three separate RF-100 datasets:
| Mannequin | cable-damage |
bone-fracture |
soda-bottles |
|---|---|---|---|
| RF-DETR Nano | 0.9195 (0.4391) | 0.2317 (0.1136) | 0.9617 (0.6223) |
| RF-DETR Base | 0.9281 (0.4456) | 0.4474 (0.1915) | 0.9688 (0.6332) |
| YOLOv12-N | 0.9236 (0.4378) | 0.0911 (0.0532) | 0.9677 (0.6343) |
| YOLO26-N | 0.8165 (0.3681) | 0.0193 (0.0064) | 0.9148 (0.5896) |
| YOLOv12-M | 0.8266 (0.3649) | 0.1500 (0.0635) | 0.9706 (0.6422) |
| YOLO26-M | 0.8707 (0.3896) | 0.2194 (0.1038) | 0.9596 (0.6304) |
What the numbers say:
- The
soda-bottlesgoal is the simple win. Each mannequin lands within the 0.91–0.97 mAP50 band. That is seemingly attributable to the truth that the area (shopper merchandise in images) is visually near present courses in COCO, so solely the vocabulary was new. Apparently, the eye mannequin household does nice right here, with YOLOv12-M taking the highest spot (0.6422 mAP50-95). cable-damage: Detection is straightforward, however localization is difficult. mAP50 reaches 0.93, however mAP50-95 tops out at 0.446. It seems that the fashions discover the injury reliably, but they battle to field skinny, elongated defects exactly. In case your software wants tight bins at excessive IoU, this hole could be a big subject.bone-fracturestays genuinely onerous. The most effective mannequin (RF-DETR Base, 0.447 mAP50) is much from production-ready, and the efficiency unfold throughout fashions is large. The modality shift from images to X-rays means the pretrained spine options switch poorly. The completely different picture modality and small, generally nearly indistinguishable bone fractures make the detection process method tougher than the one employed on widespread objects identification. That is the dataset that will most profit from domain-specific pretraining, extra knowledge, or longer fine-tuning.- RF-DETR Base is essentially the most constant performer, profitable on two out of three datasets and difficult severely for the third. The DETR-style structure appears to switch extra robustly to unfamiliar domains.
Qualitative outcomes
To visually assess how these fashions carry out, we will overlay the anticipated bounding bins on the photographs. Let’s have a look at the objects our fashions detected in six random photos per class:



We are able to see this confirms the accuracy values we noticed above: The noisy photos of soda bottles in fridges are labeled precisely, with tight bounding bins for every object. The cable injury is recognized much less constantly, with some fashions failing to seek out the injury altogether, and others creating unnecessarily giant bounding bins. Lastly, the photographs of damaged bones distinction sharply with the opposite two, with lower than half of the photographs having any break recognized, and completely different fashions figuring out completely different potential breakage factors.
Conclusions
Pretrained object detectors are highly effective, primarily based on developments in mannequin structure over the previous 5 years, however as we’ve seen right here, pretrained doesn’t essentially imply deployable. All six fashions carried out properly on COCO, but once we utilized those self same checkpoints on to our specialised datasets, their efficiency fell near zero. Nevertheless, fine-tuning utterly modified that image.
After solely 10 epochs of fine-tuning, all three mannequin households have been in a position to adapt properly to each the cable-damage and soda-bottle datasets. As we famous, the soda-bottle process was significantly transferable, seemingly as a result of it contained objects much like these contained in COCO. cable-damage was additionally detected comparatively reliably, though the bigger hole between mAP50 and mAP50-95 confirmed that exactly finding these tiny defects was nonetheless difficult for the entire fashions. Nevertheless, bone-fracture was a very completely different story, seemingly as a result of transferring from the kind of pure photos contained in COCO to X-rays is a a lot bigger area shift. Whereas RF-DETR dealt with this leap finest, even its efficiency reveals the bounds of fine-tuning, and there are occasions once you may want to think about extra knowledge, longer coaching, and even domain-specific pretraining.
The broader takeaway is that there is no such thing as a single “finest” detector: It’s depending on the duty. Mannequin dimension, latency necessities, licensing restrictions, and most significantly, the similarity between the mannequin’s pretraining knowledge and your goal area all have an effect on the end result. It is very important chorus from unquestioningly trusting the numbers reported by mannequin suppliers and discover the match of a particular mannequin on your personal explicit process.
Get began with PyCharm at present
On this publish, we’ve gone from validating pretrained YOLO12, YOLO26, and RF-DETR checkpoints on COCO to testing them zero-shot on specialised knowledge, to fine-tuning them on three very completely different object detection duties, after which lastly, evaluating the ensuing accuracy and latency. Alongside the way in which, we’ve seen how PyCharm will help handle the sensible aspect of a challenge like this, the place a number of mannequin households require completely different dependency units and coaching environments.
PyCharm helps you retain these workflows collectively in a single challenge whereas utilizing remoted Python environments for every mannequin household. Its interpreter administration, built-in terminal, Python Packages instrument window, and help for distant improvement make it simpler to maneuver between environments and run coaching on distant GPU {hardware} with out having to handle every a part of this workflow individually.
If you happen to’d prefer to attempt these experiments your self, perhaps look into fine-tuning these fashions on your personal particular object detection use case! PyCharm is accessible to obtain and take a look at. You need to use the accompanying challenge code to breed our COCO baselines, obtain the RF100 datasets, fine-tune the fashions, and consider them utilizing the held-out take a look at splits.
You’ll find the full code for this challenge on GitHub. And in the event you’d prefer to study extra about object detection, together with the architectures behind the fashions we used on this publish, try the earlier publish on this sequence.


