Comment arrêter les bots avec l’apprentissage automatique de Sliceline

Voici le dernier article de notre série dédiée à Sliceline. Nous avons précédemment exploré ce qu’est Sliceline et comment l’appliquer à des ensembles de données fictifs. Dans cet article, nous abordons :

• l’application de Sliceline dans un contexte de sécurité ;
• comment configurer Sliceline pour identifier les segments pertinents.

Application de Sliceline à la détection des bots

Sliceline est un débogueur de modèles d’apprentissage automatique (machine learning, ou ML). Le modèle de ML que nous allons déboguer est un modèle de détection des bots, conçu comme un simple modèle d’apprentissage supervisé qui utilise quelques signaux pour déterminer si une requête provient d’un humain ou d’un bot. 

Les erreurs de prédiction du modèle de détection de bots seront analysées à l’aide de Sliceline. Le modèle de ML a été entraîné sur les données de trafic réel d’un de nos clients. Voyons ce que contient l’ensemble de données…

Données d’entraînement

Notre ensemble de données d’entraînement est composé de 20 000 requêtes HTTP, dont la moitié est considérée par notre système de détection comme des requêtes de bots et l’autre moitié comme des requêtes humaines. En plus de l’étiquette, nous avons 6 colonnes (également appelées « features » en ML) pour chaque requête :

Vous pouvez consulter notre blog si vous souhaitez en savoir plus sur les différents champs/caractéristiques. 

Notez que notre modèle considère le cookie_length comme une colonne numérique. De plus, pour éviter de divulguer des informations sur notre client, le host et le user_agent ont été cryptés.

Données pour un seul hit considéré comme humain :

• country : FR
• cookie_length : 249
• headers : 1277637147
• host : f5740297184fb9d7c952c2c0172a8c8a71fdd1e0fffcab2b2c7a918c06a457be
• method : GET
• user_agent : db0ec61fd196ee3b8fc09a5459e6e7a3f7e6733139740504ce032ecf37595d1a

Modélisation

Pour prédire si un hit provient d’un bot ou d’un humain, nous avons d’abord conçu un pipeline de traitement en utilisant scikit-learn :

Pour compléter notre pipeline, nous avons entraîné un CatBoostClassifier avec des paramètres standards sur les données traitées.

Notre pipeline a estimé le score de chaque requête pour déterminer s’il s’agit d’une requête de bot, nous permettant ainsi de calculer la log loss élémentaire comme erreur d’entraînement de notre modèle. Plus la log loss/erreur d’entraînement du modèle est faible, meilleur est le modèle.

Gestion des colonnes numériques

Selon notre article précédent :

En fpurnissant à Sliceline avec l’ensemble des données d’apprentissage et les erreurs d’apprentissage par élément, nous pouvons identifier les domaines dans lesquels le modèle est nettement moins performant.

Sliceline identifiera les sous-populations dans lesquelles le modèle rencontre des difficultés. Les sous-populations, également appelées « slices », sont définies par un filtre de la forme :

Les features numériques sont pratiques pour le modèle de ML. Mais pour Sliceline, elles posent un problème. Prenons le champ cookie_length, qui représente la longueur de la chaîne de cookies. Dans notre ensemble de données, ce champ peut prendre des valeurs de 0 à 7 532. Ainsi, le filtre suivant :

Pour faciliter la gestion des valeurs pour Sliceline, nous avons besoin d’une transformation spéciale. Nous devons binariser les features numériques en segments. Nous avons utilisé la classe ContinuousOptimalBinning de optbinning. Ce n’est pas le seul binner possible. Nous aurions pu utiliser le KBinsDiscretizer de scikit-learn ou même créer notre propre binner personnalisé. Après transformation, les valeurs possibles pour cookie_length deviennent :

Analyse des erreurs

Dans la détection, nous pouvons nous concentrer sur différents types d’erreurs :

• toutes les erreurs (toutes les prédictions de notre modèle qui sont incorrectes) ;
• les faux positifs (humains détectés comme bots) ;
• les faux négatifs (bots que nous n’avons pas détectés).

Gardez à l’esprit que l’étiquette que nous utilisons est la décision de notre système de détection actuel. Cette étiquette peut être erronée sans que nous le sachions.

Résultats

Pour chaque type d’erreur, Sliceline peut identifier les sous-populations pour lesquelles le modèle est nettement moins performant.

Toutes les erreurs confondues

Définition du slice :

• host : 43836151e20255b16f2368d290d305ff6c6d9436d9b352738c2ccf9f27494d43 ET
• user_agent : 42a98ff8e0c0edc2002cdc7d0ce11f8c7378713d9b25f22ce2d9461969f130db ET
• country : FR

Log loss du modèle sur :

• l’ensemble de données complet (20 000 requêtes) : 0.039 ;
• le slice sélectionné (815 requêtes) : 0.68.

Le slice mélange des faux positifs potentiels et des faux négatifs potentiels. Il regroupe 815 requêtes. Cette analyse est intéressante pour améliorer la performance globale du modèle.

Faux positifs

Définition du slice :

• country : FR ET
• headers : 598941606

Log loss du modèle sur :

• l’ensemble de données complet (20 000 requêtes) : 0.039 ;
• le slice sélectionné (76 requêtes) : 0.73.

Cette tranche identifie 76 requêtes potentielles de faux positifs, c’est-à-dire des humains qui ont été bloqués.

Faux négatifs

Définition du slice :

• country : FR ET
• host : 43836151e20255b16f2368d290d305ff6c6d9436d9b352738c2ccf9f27494d43 ET
• headers : -707806984

Log loss du modèle sur :

• l’ensemble de données complet (20 000 requêtes) : 0.039 ;
• le slice sélectionné (826 requêtes) : 0.68.

Ce slice identifie 826 requêtes potentielles de faux négatifs, c’est-à-dire des bots qui n’ont pas été bloqués.

Utilisation des résultats

Sliceline vous propose des filtres identifiant des faux positifs et des faux négatifs potentiels. Vous pouvez exploiter ces résultats de différentes manières :

• vous pouvez analyser la sous-population trouvée pour comprendre le type d’erreur : qui a raison entre le modèle de ML et le système de détection actuel ;
• après analyse, vous pouvez également créer de nouvelles features de ML basées sur les champs de règles de Sliceline afin d’améliorer les performances du modèle ;
• si vous utilisez des règles pour arrêter les bots ou pour permettre aux humains d’être sur la liste blanche, et si vous êtes sûr de la règle trouvée par Sliceline, vous pouvez utiliser cette règle dans votre système de détection actuel.

Configuration de Sliceline

Sliceline est hautement configurable. Si vous avez lu le code des exemples précédents que nous avons partagés, vous avez peut-être remarqué ces paramètres :

• alpha
• k
• max_l
• min_sup
• verbose

Chaque paramètre est utile d’une certaine manière. Voici une définition plus large, complémentaire à la documentation.

alpha
Si vous êtes plus intéressé par des sous-populations plus petites avec une erreur moyenne plus élevée, vous pouvez ajuster le paramètre alpha. Plus alpha est proche de 1, plus les sous-populations peuvent être petites et donc plus l’erreur moyenne sur ces slices est élevée. Vous pouvez réduire la valeur de alpha pour obtenir des slices plus grands.
Note : il existe un compromis entre la taille du slice et l’erreur moyenne du slice, et ce compromis est contrôlé à l’aide de alpha. Sa valeur dépend de ce que vous recherchez.

k
Le paramètre k est assez simple : combien de slices voulez-vous que Sliceline génère ? Votre réponse à cette question est la valeur de k. Il est possible que, lors du calcul, un ou plusieurs slices obtiennent les mêmes scores. Dans ce cas, les slices avec des scores égaux sont tous générés.

max_l
Le paramètre max_l spécifie le nombre maximal de champs utilisés pour définir votre slice. Ainsi, en utilisant la notation de (1), nous avons :

0 < N ⩽ max_l

min_sup
Le paramètre min_sup correspond au seuil de support minimal. Inspiré par la recherche d’ensembles d’éléments fréquents, il garantit la signification statistique en ignorant les modalités des features qui sont sous-représentées dans votre ensemble de données.

verbose
Ce paramètre booléen vous permet d’activer ou de désactiver les logs de calculs de Sliceline.

Dans notre exemple, nous avons utilisé la configuration suivante :

• alpha = 0.95 : nous sommes prêts à obtenir un slice assez petit.
• k = 1 : nous ne sommes intéressés que par le slice le plus important, c’est-à-dire le slice sur lequel notre modèle performe le moins bien.
• max_l = 5 : nos slices seront définis par un maximum de 5 champs.
• min_sup = 10 : les modalités des champs avec moins de 10 enregistrements seront ignorées.
• verbose = True : nous voulons voir les logs de calculs.

Conclusion

Nous arrivons à la fin de cette série d’articles de blog sur Sliceline. Après avoir présenté Sliceline et l’avoir appliqué à des ensembles de données fictifs, nous l’avons appliqué sur des données de trafic réelles dans un contexte de sécurité d’apprentissage automatique pour la détection de fraudes : la détection de bots.

Nous avons construit un modèle d’apprentissage automatique sur des données étiquetées par un système de détection déjà existant. En analysant les deux types d’erreurs, Sliceline a démontré à quel point il était puissant et hautement configurable. Jouer avec ses paramètres vous aidera à découvrir encore plus de slices intéressants pour votre problème afin de réduire soit les faux positifs, soit les faux négatifs.

Pour explorer le potentiel de notre nouveau débogueur de modèles de ML, essayez-le et donnez-nous votre avis :

• Le dépôt GitHub
• La documentation
• L’article de recherche