Entraîner un ResNet sur un jeu de données propriétaire ne pose plus de difficulté algorithmique. Le réseau est stable, les implémentations PyTorch et TensorFlow sont matures, et les hyperparamètres par défaut donnent des résultats corrects sur ImageNet. Le problème se déplace : c’est la qualité du dataset, le choix de la profondeur du réseau et la stratégie de régularisation qui déterminent si le modèle sera robuste ou simplement fonctionnel sur le banc de test.
Geler les couches d’un ResNet pré-entraîné : jusqu’où aller sur un petit dataset
Un transfer learning naïf (geler tout le backbone, ne réentraîner que le classifieur final) fonctionne quand le domaine cible ressemble à ImageNet. Sur des images médicales, industrielles ou satellitaires, les features de bas niveau divergent trop pour que cette approche tienne.
A voir aussi : Meilleurs serveurs eMule : guide pour optimiser vos téléchargements
Nous recommandons de dégeler progressivement les blocs résiduels en partant du dernier stage. Sur un ResNet-50, cela signifie libérer d’abord le stage 4 (les sept derniers bottleneck blocks), puis le stage 3 si la loss de validation continue de baisser. Dégeler les stages 1 et 2 n’apporte un gain mesurable que si le dataset dépasse plusieurs dizaines de milliers d’images annotées.
Le learning rate différencié est la clé technique ici. Appliquer un learning rate dix fois plus faible aux couches gelées qu’au classifieur évite de détruire les représentations pré-apprises. Un scheduler cosine avec warm restart sur cinq à dix époques donne un bon compromis entre vitesse de convergence et stabilité.
Lire également : Améliorer qualité données : astuces efficaces pour optimiser précision
Préparation du jeu de données : le poste que personne ne budgétise correctement
La recherche récente confirme une tendance forte : le coût de curation des données est désormais un poste budgétaire explicite dans les pipelines MLOps. Des indicateurs comme le taux de complétude, la fraîcheur et la cohérence inter-annotateurs sont suivis avec la même rigueur que les métriques métier.
Sur un dataset d’images propriétaire, trois actions ont un impact direct sur la robustesse du ResNet entraîné.
- Nettoyer les doublons et les images corrompues avant toute augmentation. Un outil comme fiftyone permet de détecter les near-duplicates par embedding et de visualiser les outliers du dataset en quelques lignes de code.
- Vérifier l’équilibre des classes. Un déséquilibre supérieur à un rapport de un à cinq entre la classe majoritaire et la classe minoritaire dégrade la précision sur les classes rares. Le suréchantillonnage, le sous-échantillonnage ou une loss pondérée (focal loss, class-balanced loss) corrigent le problème.
- Standardiser la résolution d’entrée. Un ResNet attend des tenseurs de taille fixe. Redimensionner toutes les images à la même résolution (224×224 ou 256×256 selon la variante) avec un padding ou un crop centré évite les artefacts de déformation.
Annotation et accord inter-annotateurs
Sur un jeu de données annoté en interne, mesurer le taux d’accord entre annotateurs (kappa de Cohen ou Fleiss) avant de lancer l’entraînement permet de repérer les classes ambiguës. Si deux annotateurs ne sont pas d’accord sur la même image, le réseau ne fera pas mieux.
Corriger les labels bruités a plus d’impact que changer d’architecture. C’est un point que l’approche data-centric a largement documenté ces dernières années.
Régularisation et augmentation sur ResNet : les choix qui changent la robustesse
Un ResNet-50 compte environ vingt-cinq millions de paramètres. Sur un dataset de quelques milliers d’images, le surapprentissage est garanti sans régularisation agressive.
L’augmentation de données reste le levier le plus rentable. Les transformations classiques (rotation, flip horizontal, crop aléatoire, jitter de couleur) suffisent dans la majorité des cas. Les stratégies automatiques de type RandAugment ou TrivialAugment simplifient le choix des hyperparamètres d’augmentation en supprimant la recherche manuelle de combinaisons.
Dropout, weight decay et label smoothing
Le dropout est rarement utilisé dans les ResNets originaux, qui s’appuient sur la batch normalization pour régulariser. Ajouter un dropout de 0.2 à 0.5 avant la couche fully-connected finale reste utile sur un petit dataset.
Le weight decay (L2 regularization) à une valeur entre 1e-4 et 5e-4 est standard. Nous observons que le label smoothing à 0.1 réduit la surconfiance du modèle sur les classes mal représentées, ce qui améliore directement la calibration des prédictions.
Choix de la profondeur ResNet : 18, 34, 50 ou 101 couches
Empiler des couches ne garantit pas un meilleur résultat sur un dataset restreint. Un ResNet-18 surpasse régulièrement un ResNet-101 quand le nombre d’images par classe est faible, parce qu’il dispose de moins de paramètres à ajuster et converge plus vite.
La règle empirique que nous appliquons : commencer par un ResNet-18 pré-entraîné, mesurer les performances sur le jeu de validation, puis passer au ResNet-50 si la capacité du modèle semble insuffisante (erreur de validation qui plafonne malgré une loss d’entraînement basse). Le ResNet-101 ne se justifie que sur des datasets dépassant la centaine de milliers d’échantillons annotés.
Variantes à considérer
Les ResNet-D et ResNet-RS (revised training procedure) apportent des gains de performance sans modifier fondamentalement l’architecture. Ils ajustent le stem (les premières couches de convolution) et les hyperparamètres d’entraînement. Sur un entraînement from scratch, ces variantes convergent plus proprement que le ResNet original.
Traçabilité et versioning du dataset pour la conformité réglementaire
Depuis 2024, plusieurs textes européens renforcent les exigences de traçabilité des données d’entraînement. Le RGPD, le Data Act et l’AI Act imposent aux entreprises qui entraînent des modèles sur des données propriétaires de documenter l’origine, le traitement et le versioning de chaque jeu de données.
Concrètement, cela signifie que le pipeline d’entraînement d’un ResNet doit inclure un outil de versioning de datasets (DVC, LakeFS ou un registre MLflow) et un journal de traçabilité des transformations appliquées. Le versioning des données n’est plus une bonne pratique, c’est une exigence de conformité.
Archiver le hash de chaque split (train, validation, test) et les hyperparamètres associés permet de reproduire un entraînement à l’identique, ce qui répond à la fois aux audits réglementaires et aux besoins de debugging technique.
Le point souvent négligé : la suppression d’une donnée personnelle dans le dataset source doit pouvoir déclencher un réentraînement ou, à défaut, être documentée comme risque résiduel. Articuler RGPD et cycle de vie du modèle demande une infrastructure pensée dès le départ, pas un patch ajouté après la mise en production.
