LightGBM résulte différemment selon l'ordre des données

8

J'ai deux jeux de données A et B qui sont exactement les mêmes en termes de nombre de colonnes, de nom de colonnes et de valeurs. La seule différence est l'ordre de ces colonnes. Je forme ensuite le modèle LightGBM sur chacun des deux ensembles de données avec les étapes suivantes

  1. Divisez chaque ensemble de données en formation et test (utilisez la même graine aléatoire et le même rapport pour A et B)
  2. Laissez les hyperparamètres comme par défaut
  3. Définir un état aléatoire comme un nombre fixe (pour la reproduction)
  4. Réglez le learning_rate à l'aide d'une recherche de grille
  5. Entraînez un modèle LightGBM sur l'ensemble d'entraînement et testez-le sur l'ensemble d'essai
  6. Le taux d'apprentissage avec les meilleures performances sur l'ensemble de test sera choisi

Les modèles de sortie sur les deux jeux de données sont très différents, ce qui me fait penser que l'ordre des colonnes affecte les performances de la formation du modèle à l'aide de LightGBM.

Savez-vous pourquoi c'est le cas?

Duy Bui
la source

Réponses:

6

Une explication possible est la suivante:

Lorsque l'ordre des colonnes diffère, il y a une petite différence dans la procédure.

LightGBM, XGBoost, CatBoost, entre autres, permettent de sélectionner différentes colonnes parmi les fonctionnalités de votre ensemble de données à chaque étape de la formation.

La sélection de ces colonnes se fait de manière aléatoire: supposons que votre jeu de données comporte 20 colonnes. Le nœud racine sélectionne les entités 1re, 3e et 18e , sur les deux ensembles de données, les 1re, 3e et 18e entités sont différentes dans les deux ensembles de données possibles. Cela se fait à plusieurs reprises et à chaque étape, il y a un caractère aléatoire affectant votre résultat final.

Juan Esteban de la Calle
la source
Comment pouvons-nous contrôler ce caractère aléatoire lorsque l'algorithme sélectionne un sous-ensemble de fonctionnalités pour construire un arbre de décision? C'était aussi ma seule pensée pour répondre à cette situation. De plus, je suppose que si nous sélectionnons toujours toutes les fonctionnalités par arbre, l'algorithme utilisera Gini (ou quelque chose de similaire) pour calculer l'importance des fonctionnalités à chaque étape, ce qui ne créera pas d'aléatoire.
Duy Bui
lightgbmpermet à l'utilisateur de définir les graines aléatoires utilisées pour l'échantillonnage des lignes et des colonnes.
bradS
1
@bradS: Je n'ai pas défini la graine comme un hyperparamètre dans le LightGBM mais j'ai vérifié à nouveau et les graines devraient être définies comme un nombre fixe par défaut. Cela signifie qu'il devrait avoir le même résultat, ce qui n'est pas le cas ici. lightgbm.readthedocs.io/en/latest/Parameters.html
Duy Bui
3

Bien que l'ordre des données soit sans conséquence en théorie, il est important dans la pratique. Étant donné que vous avez pris des mesures pour garantir la reproductibilité, un ordre différent des données modifiera votre logique de fractionnement des tests de train (sauf si vous savez avec certitude que les rames et les jeux de test dans les deux cas sont exactement les mêmes). Bien que vous ne spécifiiez pas comment vous divisez les données, il est fort possible qu'un certain assortiment de points de données rende la machine plus robuste aux valeurs aberrantes et donc offre de meilleures performances du modèle. Dans le cas où les données de train et d'essai sont les mêmes dans les deux cas, vous devriez probablement voir s'il y a une mesure de semences / reproductibilité (dans n'importe quelle partie de votre code) que vous n'avez pas prise.

gbdata
la source
Désolé, j'ai oublié de le mentionner. Mettra à jour ma requête. L'entraînement et le test sont exactement les mêmes parce que je les ai séparés en utilisant la même graine aléatoire.
Duy Bui
@DuyBui quelques suggestions à essayer: 1) si vous utilisez Gpu, définissez gpu_use_dp sur true De: github.com/Microsoft/LightGBM/pull/560#issuecomment-304561654 2) définissez num_threads sur un nombre fixe De: github.com/ Microsoft / LightGBM / issues / 632 ;
gbdata