Utiliser l’augmentation avec précaution

Rôle de l’augmentation#

L’augmentation des données transforme les images d’entraînement à la volée : le modèle voit donc une version légèrement différente de chaque image à chaque époque. Bien réalisée, elle améliore la robustesse aux variations d’éclairage, d’échelle et d’orientation, et réduit le surapprentissage, car le modèle ne peut pas mémoriser des images qui changent constamment. Mal réalisée, elle lui apprend des scènes physiquement impossibles et masque des lacunes dans le jeu de données qu’il faudrait corriger.

Regarde le panneau de teinte ci-dessus : l’ara rouge devient jaune. C’est sans conséquence si tu distingues les « aras des autres oiseaux », mais cela pose problème si la couleur distingue deux de tes classes.

Les paramètres par défaut importants#

Voici les valeurs par défaut d’Ultralytics 8.4 ; la référence des paramètres d’augmentation répertorie tous les arguments :

Les jeux de données de profondeur font exception : mosaic, mixup, cutmix et copy_paste produiraient des cartes de profondeur appariées non valides ; le chargeur de données de profondeur les règle donc automatiquement sur 0.

Le test de déploiement#

Chaque transformation activée doit répondre à une première question, puis à une seconde :

Un ara à l’envers est une bonne image d’entraînement pour un drone qui regarde directement vers le bas, mais une image gâchée pour une caméra fixée à un mur. Les transformations qui échouent à ce test produisent un signal d’entraînement négatif : le modèle apprend à reconnaître des images qu’il ne verra jamais, au détriment de sa capacité à reconnaître celles qu’il verra.

Un profil pratique#

Une caméra orientée vers le bas au-dessus d’un convoyeur trie des pièces dont les classes ne se distinguent que par leur couleur. Il faut supprimer la variation de teinte, tandis que les retournements verticaux et les petites rotations deviennent réalistes. Voici l’exécution telle qu’elle est présentée sur le jeu de démonstration COCO8 ; remplace le YAML de données par le tien et indique un nombre réel d’époques :

from ultralytics import YOLO

model = YOLO("yolo26n.pt")
model.train(
    data="coco8.yaml",
    epochs=1,
    imgsz=320,
    hsv_h=0.0,  # la couleur est le signal de classe : conserve les teintes fidèles
    flipud=0.5,  # vue de dessus : aucun « haut » dans l’image
    degrees=10.0,  # les pièces sont orientées selon de petits angles quelconques
)

Ouvre train_batch0.jpg dans le dossier d’exécution et vérifie trois points : les boîtes restent précises après la transformation, les indices qui définissent les classes (couleur, forme, texte) sont préservés et rien ne paraît physiquement impossible. Réduis l’intensité de toute transformation qui ne respecte pas l’un de ces critères. Entraîne ton premier modèle présente l’entraînement lui-même.

Mosaic et close_mosaic#

Mosaic assemble quatre images en une seule et est activé par défaut. C’est l’augmentation la plus efficace pour la détection : chaque image d’entraînement regroupe plusieurs scènes, échelles et contextes d’objets. Le problème, c’est que les images Mosaic ne ressemblent pas aux images rencontrées en production ; close_mosaic=10 désactive donc cette augmentation pour les 10 dernières époques afin que le modèle termine son entraînement sur des entrées réalistes. La désactivation de Mosaic désactive aussi mixup, cutmix et copy_paste, tandis que les retournements, HSV et les transformations géométriques continuent de s’appliquer.

Ce que l’augmentation ne peut pas corriger#

L’augmentation amplifie ce qui existe déjà. Si le jeu de données ne contient aucune image nocturne, aucun réglage ne peut créer la nuit : il ne fera que produire des versions plus claires ou plus sombres d’images prises de jour. Si une classe n’est utilisable qu’avec une augmentation agressive, tu n’as pas assez d’exemples de cette classe. Reprends la collecte de données de haute qualité et représentatives.