🤖 machine learning

SemiScope: Disentangling Classifier Tuning and Joint Optimization in Semi-Supervised Security Classification

Cet article introduit SemiScope pour démontrer que, pour la classification de sécurité tabulaire binaire, les gains de performance souvent attribués à l'optimisation conjointe complexe de pipelines d'apprentissage semi-supervisé sont principalement pilotés par le réglage du classificateur en aval et du seuil de décision, suggérant qu'une recette plus simple combinant l'auto-apprentissage (Self-Training) avec l'optimisation des hyperparamètres du classificateur est suffisante pour atteindre une performance quasi supervisée.

Auteurs originaux : Rui Shu, Tianpei Xia, Jingzhu He

Publié 2026-07-02

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Rui Shu, Tianpei Xia, Jingzhu He

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous êtes un agent de sécurité essayant de repérer des intrus dans un bâtiment immense. Vous avez quelques collègues de confiance qui peuvent identifier clairement les méchants (données étiquetées), mais vous avez des milliers de caméras non surveillées montrant des gens que vous ne connaissez pas encore (données non étiquetées).

L'Apprentissage Semi-Supervisé (SSL) est comme un système qui demande à vos collègues de confiance d'apprendre au système comment repérer les méchants, puis le système essaie de deviner qui sont les méchants dans les caméras non surveillées. Il utilise ensuite ses propres suppositions pour apprendre encore plus par lui-même.

Pendant longtemps, les experts en sécurité ont traité ce système comme une « boîte noire ». Ils se contentaient de l'allumer avec les paramètres par défaut, en espérant qu'il fonctionnerait. Mais récemment, des chercheurs ont commencé à dire : « Si nous ajustons tous les boutons et les cadrans de ce système en même temps, nous obtenons de bien meilleurs résultats ! »

La Grande Question :
Les auteurs de cet article ont posé une question très spécifique : L'amélioration provient-elle du fait que nous ajustons tout le système ensemble (la partie SSL + la partie classificateur), ou est-ce principalement parce que nous avons très bien réglé le « juge » final (le classificateur) ?

Pensez à la cuisson d'un gâteau.

La partie SSL est la recette (mélanger les ingrédients).
La partie Classificateur est le four et le minuteur (cuisson et finition).
L'affirmation de l'« Optimisation Conjointe » est que vous devez trouver la recette parfaite et les réglages de four parfaits simultanément pour obtenir le meilleur gâteau.

Les auteurs voulaient savoir : Le gâteau est-il meilleur parce que nous avons trouvé une nouvelle recette magique, ou simplement parce que nous avons enfin trouvé la température de cuisson parfaite ?

L'Expérience : « SemiScope » contre « Tuned-Clf »

Pour répondre à cela, les chercheurs ont construit un outil appelé SemiScope. Imaginez que SemiScope est un robot chef super intelligent qui essaie 100 combinaisons différentes de recettes et de réglages de four pour trouver le meilleur gâteau absolu.

Mais pour voir si la « recette » (le SSL) faisait réellement le plus gros du travail, ils ont créé un groupe de contrôle appelé Tuned-Clf.

Tuned-Clf utilise exactement les mêmes 100 essais et le même robot intelligent.
Cependant, il garde la recette fixe sur les réglages « par défaut » (la recette standard, banale).
Il consacre seulement son énergie à régler le four (le classificateur).

Ils ont ensuite comparé les gâteaux faits par le robot complet (SemiScope) aux gâteaux faits par le seul régleur de four (Tuned-Clf).

Les Résultats : Le Four était la Star

Voici ce qu'ils ont trouvé, traduit en termes courants :

Le Robot Complet Gagne (mais de peu) : Lorsqu'ils ont comparé le robot complet (SemiScope) aux réglages « par défaut » (aucun réglage du tout), le robot complet a fait des gâteaux bien meilleurs. C'est une amélioration énorme. Cela confirme que le réglage aide.
Le Régleur de Four fait le Gros du Travail : Lorsqu'ils ont comparé le robot complet (SemiScope) au seul régleur de four (Tuned-Clf), les résultats étaient presque identiques. Sur 4 cas de test sur 5, la différence était si petite qu'elle n'avait pas d'importance.
- L'Analogie : Il s'avère que 86 % de la « magie » de l'amélioration provenait simplement du réglage du four (le classificateur), et non de la recherche d'une nouvelle recette (la partie SSL).
L'Astuce du « Seuil » : L'une des plus grandes découvertes qu'ils ont faites concerne le « seuil de décision ». C'est comme la règle que l'agent utilise pour décider : « Cette personne est-elle assez suspecte pour que je l'arrête ? »
- La plupart des gens utilisent une règle par défaut : « Si vous semblez suspect à 50 %, arrêtez-les. »
- Les chercheurs ont découvert que pour les données de sécurité, la meilleure règle est souvent beaucoup plus basse (comme 20 %). Si vous ne réglez pas cette règle, vous ratez presque tous les méchants. Le « régleur de four » était excellent pour trouver cette règle plus basse et plus efficace.

La Recette Simple pour les Praticiens

Les auteurs concluent que vous n'avez pas besoin d'un robot complexe et coûteux pour trouver une nouvelle recette magique. Au lieu de cela, ils suggèrent une approche plus simple et moins chère qui fonctionne tout aussi bien :

Utilisez la recette standard : Tenez-vous-en à une méthode de base appelée « Auto-apprentissage » (Self-Training) (c'est la méthode par défaut).
Réglez le four : Utilisez un outil intelligent pour trouver les meilleurs réglages pour votre classificateur final (le « juge »).
Ajustez l'alarme : N'utilisez pas la règle par défaut de « 50 % de suspicion ». Réglez le seuil de décision en fonction de vos données spécifiques pour attraper plus de méchants sans déclencher trop de fausses alertes.

Le Mot de la Fin

L'article soutient que lorsque les gens prétendent que l'« Optimisation Conjointe » (régler tout ensemble) est un remède miracle pour les problèmes de sécurité, ils attribuent peut-être le mérite à la mauvaise partie du système.

Le véritable héros est simplement le réglage du classificateur final et de son seuil de décision. Vous pouvez obtenir 99 % des bénéfices en faisant simplement cela, sans avoir besoin du processus complexe et coûteux consistant à régler l'ensemble du pipeline semi-supervisé à partir de zéro.

En bref : Ne compliquez pas la recette. Assurez-vous simplement de savoir exactement comment cuire le gâteau et quand le sortir du four. C'est là que se trouvent les véritables gains.

En résumé : Ne compliquez pas la recette. Assurez-vous simplement de savoir exactement comment cuire le gâteau et quand le sortir du four. C'est là que se trouvent les vrais gains.

Résumé technique : SemiScope : Décomposition du réglage du classifieur et de l'optimisation conjointe dans la classification de sécurité semi-supervisée

1. Énoncé du problème

Les tâches de classification de sécurité (par exemple, détection de logiciels malveillants, détection d'intrusion, phishing) sont confrontées à un goulot d'étranglement critique : les données étiquetées fiables sont rares et coûteuses à produire en raison du besoin d'expertise métier, tandis que les données non étiquetées sont abondantes. L'apprentissage semi-supervisé (SSL) est couramment employé pour propager les étiquettes d'un petit ensemble étiqueté vers un ensemble plus large non étiqueté.

Cependant, les applications de sécurité actuelles traitent souvent le SSL comme une étape de prétraitement "boîte noire", utilisant des hyperparamètres par défaut, des classifieurs en aval fixes, et manquant de mécanismes explicites pour gérer le déséquilibre des classes souvent exacerbé par le pseudo-étiquetage. Bien que des études récentes fassent état de gains de performance issus de l'optimisation des pipelines SSL (via la recherche d'hyperparamètres conjointe, l'AutoML ou le réglage de composants), ces gains sont difficiles à attribuer. Il reste difficile de déterminer si les améliorations proviennent des interactions complexes entre le SSL et le classifieur (optimisation conjointe) ou simplement de l'étape plus simple et plus standard de réglage des hyperparamètres du classifieur en aval. De plus, de nombreuses évaluations antérieures utilisent des protocoles asymétriques (par exemple, le réglage des seuils pour certaines méthodes mais pas pour d'autres) ou des budgets de calcul inégaux, ce qui peut gonfler artificiellement la valeur apparente de l'optimisation conjointe.

2. Méthodologie

Les auteurs introduisent SemiScope, un instrument d'analyse conçu non pas comme une recommandation de déploiement, mais comme un cadre contrôlé pour dissocier les effets de l'optimisation conjointe du réglage du classifieur.

2.1 Le pipeline SemiScope

SemiScope formule le processus SSL comme un pipeline configurable où l'optimisation bayésienne (utilisant l'Estimateur de Parzen structuré par arbre via Optuna) recherche conjointement :

Méthode SSL : Propagation d'étiquettes (LP), Propagation d'étiquettes (LS) ou Auto-apprentissage (ST).
Hyperparamètres SSL : Types de noyaux, largeurs de bande, facteurs de clampage et limites d'itération spécifiques à la méthode choisie.
Filtrage de confiance : Un seuil ( $t$ ) pour filtrer les pseudo-étiquettes basées sur des scores de confiance, afin de traiter le risque de propagation d'étiquettes bruitées.
Suréchantillonnage : Une stratégie SMOTE ciblant un ratio (inspirée de SMOTUNED) qui s'active uniquement lorsque la fraction de la classe minoritaire tombe en dessous d'un seuil (30 %), avec des nombres de voisins et des ratios de classe minoritaire cibles réglables.
Sélection et réglage du classifieur : Choix de classifieurs basés sur des arbres (Forêt aléatoire, XGBoost, LightGBM) et leurs hyperparamètres spécifiques.
Seuil de décision : Réglage du seuil de classification sur l'ensemble de validation pour optimiser le $g$ -measure.

2.2 Le protocole de décomposition

Pour isoler la source des gains de performance, l'étude emploie un protocole de contrôle strict :

SemiScope (Recherche conjointe) : Utilise un budget de 100 essais pour optimiser l'ensemble du pipeline (SSL + Classifieur + Seuil).
Tuned-Clf (Contrôle) : Utilise le même budget de 100 essais et le même réglage du seuil de validation, mais fixe le composant SSL à ses paramètres par défaut (par exemple, LP par défaut ou ST par défaut). Il recherche uniquement sur la famille de classifieurs et leurs hyperparamètres.
Réglage de seuil symétrique : Crucialement, chaque traitement (y compris les lignes de base) règle son seuil de décision sur les données de validation avant l'évaluation finale. Cela empêche de confondre la performance du modèle avec des artefacts de seuil fixe, ce qui est vital pour les ensembles de données de sécurité déséquilibrés (12–20 % de classe minoritaire).

L'étude évalue ce cadre sur cinq ensembles de données de sécurité tabulaires binaires (CIC-IDS-2017, Drebin, NSL-KDD, Phishing, UNSW-NB15) en utilisant le $g$ -measure (moyenne harmonique de la recall et de la spécificité) comme métrique principale.

3. Contributions principales

Le document présente trois contributions principales :

Décomposition contrôlée : Un protocole qui sépare les gains dus à l'optimisation conjointe SSL-classifieur des gains dus à l'optimisation des hyperparamètres du classifieur (HPO) seule, en utilisant des budgets de calcul égaux et un réglage de seuil symétrique.
Protocole de seuil symétrique : Un standard d'évaluation rigoureux où toutes les méthodes règlent leurs seuils de décision sur les données de validation, évitant la distorsion causée par les seuils fixes sur des données de sécurité déséquilibrées.
Recette exploitable : Un flux de travail empiriquement dérivé, plus simple, qui atteint une performance proche de l'optimale sans la complexité de la recherche conjointe complète.

4. Résultats

4.1 Efficacité (RQ1)

SemiScope surpasse chaque ligne de base SSL par défaut (incluant Default LP, LS, ST, et leurs variantes SMOTE) sur les cinq ensembles de données à un taux d'étiquetage de 10 %. L'amélioration par rapport à la ligne de base par défaut la plus forte (Default ST + Random Forest) varie de +0,7 à +12,7 points de $g$ -measure.

4.2 Décomposition (RQ2)

Lorsqu'il est comparé au contrôle Tuned-Clf (qui optimise uniquement le classifieur sur la sortie SSL par défaut) :

Équivalence statistique : Sur 4 ensembles de données sur 5 (CIC-IDS-2017, Drebin, NSL-KDD, UNSW-NB15), le pipeline complet (SemiScope) est statistiquement équivalent au contrôle réglé du classifieur à un Plus Petit Effet de Taille d'Intérêt (SESOI) de $\pm 1,0$ point de $g$ -measure. L'ensemble de données Phishing reste non concluant.
Gain récupéré : Le HPO du classifieur seul récupère un gain médian de 86 % du gain total de SemiScope par rapport à la ligne de base par défaut.
Implication : La majeure partie de l'amélioration observée dans les pipelines conjoints est attribuable au réglage du classifieur en aval et du seuil de décision, et non à la recherche conjointe des paramètres SSL.

4.3 Ablation (RQ3)

Le retrait de composants du pipeline complet révèle :

Sélection du classifieur : Le composant ayant le plus fort levier. Son retrait provoque les chutes de performance les plus importantes.
Sélection de la méthode SSL : A un effet négligeable sur le score moyen mais réduit significativement la variance (améliore la robustesse entre les graines/seeds).
Filtrage de confiance : A un effet moyen quasi neutre ; l'optimiseur le désactive souvent (définit le seuil $\approx 0,5$ ) lorsqu'il n'est pas utile, suggérant que les seuils fixes sont sous-optimaux.

4.4 Efficacité des étiquettes (RQ4)

SemiScope atteint la proximité de 1 point de $g$ -measure d'une référence Random Forest entièrement supervisée à 20–30 % d'étiquettes sur quatre ensembles de données et 40 % sur Drebin. Cela se situe au même taux ou à un taux inférieur que la ligne de base Default ST + RF, les plus grands gains d'efficacité (réduisant le nombre d'étiquettes requis de 20 à 30 points de pourcentage) étant observés sur CIC-IDS-2017 et UNSW-NB15.

4.5 Coût-Bénéfice (RQ5)

Le coût d'optimisation est de 13 à 28 minutes par configuration. Les auteurs soutiennent que ce coût est surtout justifié sur les ensembles de données où les lignes de base par défaut performent mal (ex: CIC-IDS-2017), là où l'optimisation conjointe génère des gains significatifs et un croisement précoce avec la performance supervisée. Sur les ensembles de données où les valeurs par défaut sont déjà fortes (ex: NSL-KDD), le bénéfice marginal d'une recherche conjointe complète est plus faible.

5. Signification et affirmations

Le papier affirme modestement que sa contribution principale n'est pas un nouvel optimiseur, mais une décomposition empirique de l'origine des gains des pipelines SSL.

Réévaluation des gains : L'étude démontre que les gains rapportés des "pipelines SSL conjoints" dans la littérature de sécurité peuvent être mal attribués. Sans contrôles appariés (budgets égaux, réglage de seuil symétrique), les améliorations dues au réglage du classifieur sont souvent confondues avec les bénéfices d'une optimisation complexe des paramètres SSL.
Recommandation pratique : Pour les praticiens, les auteurs proposent une recette plus simple et suffisante :
1. Utiliser l'Auto-apprentissage (Self-Training) comme méthode SSL par défaut.
2. Appliquer l'Optimisation Bayésienne pour régler le classifieur en aval.
3. Régler le seuil de décision sur les données de validation.
  Cette recette atteint une performance à moins de 1 point de $g$ -measure de la référence supervisée à de faibles taux d'étiquetage, égalant ou dépassant la performance des pipelines SSL par défaut avec une complexité nettement moindre.

Les auteurs concluent que l'optimisation conjointe complète doit être réservée aux scénarios où les étiquettes sont extrêmement coûteuses ou là où le SSL par défaut laisse un écart de performance substantiel, plutôt que d'être une stratégie de déploiement par défaut.