Pour une classification avec des forêts aléatoires en R, comment doit-on s'ajuster aux tailles de classe déséquilibrées?

J'explore différentes méthodes de classification pour un projet sur lequel je travaille et je suis intéressé à essayer Random Forests. J'essaie de m'instruire au fur et à mesure et j'apprécierais toute aide apportée par la communauté CV.

J'ai divisé mes données en ensembles de formation / test. De l'expérimentation avec des forêts aléatoires dans R (en utilisant le package randomForest), j'ai eu des problèmes avec un taux de classification erroné élevé pour ma petite classe. J'ai lu cet article concernant les performances des forêts aléatoires sur des données déséquilibrées, et les auteurs ont présenté deux méthodes pour traiter le déséquilibre de classe lors de l'utilisation de forêts aléatoires.

1. Forêts aléatoires pondérées

2. Forêts aléatoires équilibrées

Le package R ne permet pas la pondération des classes (à partir des forums d'aide R, j'ai lu que le paramètre classwt ne fonctionne pas correctement et est planifié comme une future correction de bogue), donc je me retrouve avec l'option 2. Je suis en mesure de spécifier le nombre d'objets échantillonnés dans chaque classe pour chaque itération de la forêt aléatoire.

Je suis mal à l'aise de définir des tailles d'échantillons égales pour les forêts aléatoires, car je pense que je perdrais trop d'informations sur la classe plus large, ce qui entraînerait de mauvaises performances avec les données futures. Les taux de classification erronée lors du sous-échantillonnage de la grande classe se sont améliorés, mais je me demandais s'il y avait d'autres façons de gérer les tailles de classe déséquilibrées dans les forêts aléatoires?

Si vous n'aimez pas ces options, avez-vous envisagé d'utiliser plutôt une méthode de renforcement? Étant donné une fonction de perte appropriée, le boost recalibre automatiquement les poids au fur et à mesure. Si la nature stochastique des forêts aléatoires vous plaît, le renforcement du gradient stochastique en fait également partie.

Je pense que pondérer des objets équivaut en quelque sorte à les dupliquer. Vous devriez peut-être essayer de modifier l'étape de bootstrap en échantillonnant de manière appropriée vos différentes classes.

Une autre pensée est que le déséquilibre de classe peut déplacer votre seuil de décision vers une autre valeur que $0.5$(si c'est un problème de classification binaire). Essayez de considérer les courbes ROC et l'AUC pour évaluer la gravité du déséquilibre à l'origine des mauvaises performances de vos modèles.

Au lieu d'échantillonner de grandes classes, vous pouvez développer de petites classes! Si les grandes classes ont beaucoup plus d'observations que de petites, alors le biais sera petit. J'espère que vous pourrez gérer cet ensemble de données surdimensionné.

Vous pouvez également identifier des sous-ensembles d'observations qui gèrent le plus d'informations sur les grandes classes, il existe de nombreuses procédures possibles, la plus simple je pense est basée sur la méthode des voisins les plus proches - l'échantillonnage d'observation conditionné à la structure du graphique de voisinage garantit que l'échantillon aura une densité de probabilité plus similaire à d'origine.

randomForest est écrit en Fortran et c, le code source est disponible (http://cran.r-project.org/src/contrib/randomForest_4.6-2.tar.gz) mais je ne peux pas repérer l'endroit où l'enthropie est calculée, ps. ups que randomforest utilisent Gini au lieu de l'enthropie

(1) Vous avez raison, la fonction de pondération ne fonctionne pas et vous ne savez pas si elle a déjà été corrigée.

(2) La plupart utilisent l'option 2 avec des données équilibrées. La clé pour ne pas perdre trop de données est l'échantillonnage stratifié. Vous échantillonnez au hasard un ensemble équilibré unique pour chaque arbre.

Le suréchantillonnage synthétique des minorités (SMOTE) génère de nouvelles observations de la classe minoritaire sous forme de combinaisons convexes aléatoires d'observations voisines. Le document est ici: https://bmcbioinformatics.biomedcentral.com/articles/10.1186/1471-2105-14-106