JetBrains présente une expérience pratique visant à tester trois modèles récents de détection d’objets, à savoir YOLO12, YOLO26 et RF-DETR, non seulement sur des données de référence, mais aussi sur des images représentant des situations plus proches de l’utilisation réelle : dommages aux câbles, fractures osseuses sur des radiographies et bouteilles de boissons empilées. La conclusion principale est claire : un modèle préentraîné n’est pas nécessairement un modèle prêt à être déployé.
Les modèles reposaient initialement sur les données COCO, qui comprennent environ 118 000 images d’entraînement et 80 catégories courantes telles que les personnes, les voitures, les chiens et les chaises. Cependant, certaines cibles pratiques, comme une fracture osseuse, ne font tout simplement pas partie du vocabulaire de ces catégories. De plus, les radiographies, les prises de vue industrielles et les scènes visuellement encombrées diffèrent des images naturelles auxquelles les modèles sont habitués.
Vérifier la base de référence avant l’entraînement
Avant de passer à l’ajustement fin, JetBrains a évalué six points de contrôle, avec deux tailles pour chacune des trois familles, sur l’ensemble de validation COCO val2017, composé de 5 000 images. RF-DETR Base a obtenu le meilleur score mAP50-95, à 0.5325, tandis que les deux modèles YOLO de taille moyenne s’en sont approchés avec 0.5259 et 0.5181, tout en comptant environ 10 millions de paramètres de moins.
La comparaison a également révélé des différences pratiques en matière de vitesse. YOLO26-N a enregistré un temps de 12.3 millisecondes, avec un score mAP50-95 proche de celui de YOLOv12-N, qui a enregistré 23.9 millisecondes bien qu’il soit le plus petit modèle de l’expérience. Quant à RF-DETR Nano, son temps s’est élevé à 12.4 millisecondes, alors que son nombre de paramètres est proche de 30 millions, ce qui dépasse celui de YOLO26-M.
Ces chiffres ne correspondent pas nécessairement à ceux publiés dans les articles consacrés aux modèles, car l’expérience a utilisé un matériel différent de l’unité NVIDIA T4 couramment employée dans les comparaisons et a exécuté les modèles dans leurs frameworks d’origine, sans les convertir en TensorRT. JetBrains explique que TensorRT peut réduire le temps d’inférence en fusionnant les couches et en sélectionnant des noyaux optimisés pour le matériel, mais qu’il nécessite une étape de construction supplémentaire et produit un moteur associé à une unité de traitement graphique donnée. Les chiffres de l’expérience reflètent donc des performances plus proches de l’exécution directe, et non les performances maximales possibles après optimisation.
Tester en dehors du périmètre d’entraînement
L’expérience a utilisé trois ensembles de RF100-VL, une collection comprenant 100 jeux de données multimodaux conçus pour couvrir des cibles rares dans les données d’entraînement habituelles. Les ensembles sélectionnés étaient bone-fracture-7fylg, cable-damage et soda-bottles.
Lorsque les points de contrôle entraînés sur COCO ont été exécutés directement sur ces données, le résultat était presque nul. JetBrains explique cela par le fait que les modèles utilisés sont des détecteurs à vocabulaire fermé : ils disposent d’un nombre déterminé de catégories et ne peuvent pas produire une catégorie telle que fracture si celle-ci ne figure pas dans la tête du modèle, composée de 80 catégories. Ainsi, le fait qu’un modèle obtienne un mAP50 de 0.72 sur COCO ne signifie pas qu’il reconnaîtra automatiquement les fractures osseuses.
Que change l’ajustement fin ?
JetBrains a ajusté finement les trois modèles sur chaque jeu de données pendant 10 époques d’entraînement, au moyen d’une seule unité A100, en s’appuyant sur les pipelines d’entraînement habituels d’Ultralytics et de RF-DETR. Après l’entraînement, les résultats se sont nettement améliorés pour les tâches de détection des dommages aux câbles et des bouteilles de boissons, tandis que la tâche des fractures osseuses est restée la plus difficile.
Les bouteilles de boissons constituaient le cas le plus facile : le score mAP50 de tous les modèles se situait entre 0.91 et 0.97, et YOLOv12-M a obtenu le meilleur mAP50-95, à 0.6422. JetBrains estime que cela s’explique par la proximité des images de produits avec certaines catégories présentes dans COCO, ce qui rend le problème davantage comparable à l’ajout d’un nouveau vocabulaire qu’à un transfert complet entre deux domaines visuels.
Dans la tâche de détection des dommages aux câbles, le mAP50 a atteint 0.93, mais le mAP50-95 le plus élevé n’a pas dépassé 0.446. Cela signifie que les modèles peuvent localiser correctement les dommages, mais qu’ils rencontrent des difficultés à tracer des boîtes englobantes précises autour des défauts fins et allongés. Dans les radiographies de fractures osseuses, le meilleur mAP50, obtenu par RF-DETR Base, n’était que de 0.447, avec de fortes variations entre les modèles. L’examen visuel a également montré que moins de la moitié des images comportaient une fracture détectée dans certains résultats.
Que doit examiner l’équipe de développement ?
- Commencer par une base de référence reproductible : vérifier les performances des points de contrôle dans son propre environnement et sur son propre matériel avant de comparer les résultats aux chiffres publiés.
- Séparer les environnements logiciels : JetBrains a utilisé trois environnements uv isolés au sein d’un même projet PyCharm, car les versions requises de la bibliothèque ultralytics pour les générations de YOLO ne sont pas compatibles. L’utilisation de l’interpréteur distant dans PyCharm nécessite l’édition Professional, tandis que Community Edition prend uniquement en charge les environnements locaux.
- Ne pas se limiter à une seule métrique : l’écart entre mAP50 et mAP50-95 dans la détection des dommages aux câbles révèle un problème de précision du positionnement qui peut ne pas apparaître lorsque l’on examine uniquement le mAP50.
- Adapter le choix du modèle à la tâche : RF-DETR Base a fait preuve d’une plus grande constance et a remporté la comparaison sur deux des trois jeux de données, mais cela ne le rend pas meilleur pour tous les cas.
- Planifier les données lorsque le changement de domaine est important : les résultats des radiographies indiquent que l’ajustement fin seul peut ne pas suffire. Il peut être nécessaire de disposer de davantage de données, de prolonger l’entraînement ou de recourir à un préentraînement spécialisé dans le domaine ; la matière présente ces options sans démontrer la supériorité de l’une d’entre elles dans cette expérience.
L’expérience confirme que les qualificatifs « avancé » ou « préentraîné » ne résument pas l’adéquation d’un modèle de détection d’objets à l’environnement de déploiement. La décision pratique doit équilibrer la précision, le temps d’inférence, la taille du modèle, les exigences de licence et, surtout, le degré de similarité entre les données d’entraînement et le domaine cible. Les résultats de JetBrains restent également liés aux trois ensembles de données et aux paramètres d’entraînement utilisés ; il ne faut donc pas les généraliser comme un classement définitif pour toutes les tâches de détection.