Défis et limites

L’apprentissage semi-supervisé (SSL – Semi-Supervised Learning) s’impose comme une solution intermédiaire entre apprentissage supervisé (basé uniquement sur des données étiquetées) et apprentissage non supervisé (sans aucune étiquette). Il exploite efficacement un petit jeu de données étiquetées et un large volume de données non étiquetées pour améliorer la performance des modèles tout en réduisant les coûts liés à l’annotation.

Malgré ses nombreux avantages, le SSL comporte également de nombreuses limites pratiques et théoriques. Cet article explore en profondeur ces défis, illustrant pourquoi l’intégration du SSL dans un pipeline de machine learning nécessite rigueur, précaution et stratégie.

Problèmes liés à la qualité des données non étiquetées

Hétérogénéité et distribution divergente

Le fondement du SSL repose sur l’idée que les données non étiquetées proviennent de la même distribution que les données étiquetées. Si ce n’est pas le cas, les représentations apprises risquent d’être biaisées, voire contre-productives.

Exemple : En reconnaissance d’images, si les données étiquetées sont issues d’un appareil photo professionnel, mais que les données non étiquetées viennent de caméras de surveillance à basse résolution, la différence de distribution dégrade fortement la performance du modèle.

Bruit et qualité incertaine

Les données non étiquetées sont souvent collectées en masse, sans nettoyage. Cela introduit :

• des erreurs de format,

• des valeurs aberrantes,

• ou des données hors domaine.

Le modèle pourrait intégrer ces informations comme valides, amplifiant ainsi les erreurs.

Hypothèses fortes sur la structure des données

Hypothèse de voisinage (cluster assumption)

Elle suppose que les points proches dans l’espace des caractéristiques partagent la même classe. Cela sous-tend de nombreuses méthodes SSL comme les graphes ou les algorithmes de propagation de labels.

Mais cette hypothèse ne tient pas toujours :

• Certaines classes peuvent être dispersées dans l’espace.

• Deux instances proches peuvent appartenir à des classes différentes dans des cas complexes.

Hypothèse de la faible densité

La frontière de décision devrait passer par des zones à faible densité. Cela paraît logique, mais dans le monde réel, des zones à forte densité peuvent contenir plusieurs classes, surtout dans des jeux de données bruités ou multi-sources.

Propagation d’erreurs : les pseudo-labels imparfaits

Beaucoup de techniques SSL reposent sur le pseudo-étiquetage, où le modèle attribue une étiquette aux données non étiquetées selon ses propres prédictions.

Problème majeur : Si un pseudo-label est incorrect, et qu’il est réutilisé pour entraîner le modèle, l’erreur est consolidée. Ce mécanisme peut mener à :

• une cascade d’erreurs,

• un effondrement du modèle,

• une perte de généralisation.

Il est donc crucial de filtrer ou de pondérer les pseudo-étiquettes selon leur niveau de confiance.

Complexité algorithmique et calculatoire

Modèles complexes

Les techniques modernes (e.g. MixMatch, FixMatch, Mean Teacher, etc.) combinent plusieurs réseaux, fonctions de perte et contraintes de régularisation. Cette sophistication augmente la précision mais alourdit considérablement le coût computationnel.

Temps d’entraînement

La combinaison :

• du traitement des données non étiquetées,

• du recalcul fréquent des pseudo-labels,

• et de la régularisation par consistance

conduit à des temps d’entraînement prolongés, parfois multipliés par 2 ou 3 par rapport au modèle supervisé équivalent.

Hyperparamètres supplémentaires

Exemples :

• Seuils de confiance pour les pseudo-labels

• Coefficients de pondération entre pertes supervisée et non supervisée

• Nombre d’époques spécifiques à la phase semi-supervisée

Le tuning devient alors plus complexe et plus fragile.

Nécessité d’un socle étiqueté de qualité

Contrairement à une idée reçue, le SSL ne fonctionne pas avec zéro étiquette. Il faut un jeu étiqueté initial suffisamment représentatif, faute de quoi :

• Les pseudo-labels seront biaisés

• Le modèle n’apprendra pas les frontières correctes

• La validation du modèle sera impossible

Le SSL complète l’apprentissage supervisé, mais ne le remplace jamais entièrement.

Problèmes d’évaluation

Jeux de test peu représentatifs

Dans des scénarios où les données étiquetées sont rares, le jeu de test l’est aussi. Si ce dernier n’est pas représentatif de la distribution globale, l’évaluation sera faussée.

Surapprentissage sur la validation

Avec un faible volume de données étiquetées, il est fréquent que le modèle surapprenne le petit jeu de validation, surestimant ainsi ses performances générales.

Déficit de métriques robustes

Des métriques comme l’accuracy peuvent être trompeuses en présence d’un déséquilibre entre classes. Or, de nombreux benchmarks en SSL utilisent uniquement l’accuracy, masquant des problèmes plus profonds.

Sécurité et vulnérabilités

Attaques adversariales

Les modèles semi-supervisés peuvent être manipulés par des entrées soigneusement conçues. L’absence d’étiquettes rend plus difficile la détection de comportements anormaux.

Empoisonnement des données

Un attaquant pourrait injecter dans les données non étiquetées :

• des exemples biaisés,

• des valeurs anormales,

• ou des patterns répétitifs.

Le modèle les intègre dans son apprentissage, provoquant des dérives insidieuses.

Limites théoriques

Contrairement à l’apprentissage supervisé, le cadre théorique du SSL est encore jeune.

Peu de garanties formelles

Il existe peu de bornes de généralisation solides ou de garanties de convergence dans les algorithmes SSL, notamment pour les approches basées sur le deep learning.

Dépendance forte aux hypothèses

Les méthodes SSL dépendent de postulats (structure du voisinage, densité, etc.) qui ne sont pas vérifiables à l’avance.

En cas de violation, les performances peuvent s’effondrer sans avertissement.

Défis par domaine d’application

Vision par ordinateur

• Problèmes de qualité d’image : flou, mauvaise luminosité, occlusions.

• Cohérence des transformations (data augmentation) cruciale : une rotation peut changer la classe (ex. : chiffre 6 ↔ 9).

Traitement du langage naturel (NLP)

• Forte dépendance au contexte linguistique.

• Ambiguïtés sémantiques difficiles à résoudre sans supervision.

• Les méthodes doivent prendre en compte la syntaxe, grammaire, pragmatique.

Données tabulaires

• Structure hétérogène : variables numériques, catégorielles, temporelles.

• Peu de régularité dans l’espace vectoriel.

• La notion de « proximité » entre deux lignes n’est pas toujours pertinente.

Situations où le SSL est déconseillé

• Classes non représentées dans les données étiquetées.

• Domaines très ouverts avec grande diversité de types de données.

• Données générées aléatoirement ou sans structure exploitable.

• Problèmes sensibles ou critiques (ex. diagnostic médical) où la robustesse prime.

Bonnes pratiques pour limiter les risques

• Échantillonnage stratégique des données étiquetées pour couvrir toutes les classes.

• Filtrage des pseudo-labels selon un seuil de confiance élevé.

• Nettoyage rigoureux des données non étiquetées avant intégration.

• Utilisation d’ensembles modèles (ensembles learning) pour réduire le biais de surconfiance.

• Mix supervision + SSL + self-supervised : une hybridation des approches peut donner des résultats plus robustes.

Conclusion

L’apprentissage semi-supervisé offre un potentiel considérable, notamment dans les situations où l’annotation manuelle est coûteuse ou impraticable. Cependant, il n’est pas une solution miracle. Il exige :

• une base étiquetée solide,

• des hypothèses bien comprises,

• des algorithmes rigoureux,

• et des mécanismes de validation fiables.

Pour les praticiens, le succès du SSL repose sur une maîtrise fine des limites autant que sur l’exploitation de ses avantages. Intégrer le SSL, c’est avant tout un choix stratégique, qui doit être adapté au contexte, aux données et aux objectifs.