Encodage et validation croisée

Question

Récemment, j'ai réfléchi à la bonne utilisation de l'encodage dans le schéma de validation croisée. La méthode habituellement recommandée pour encoder les fonctionnalités est:

1. Diviser les données en train et ensemble de test (hold-out)
2. Monter l'encodeur (soit LabelEncoderou OneHotEncoder) sur le train
3. Transformez à la fois le train et l'ensemble de test à l'aide d'un codeur intégré.

Cette méthode est censée empêcher toute fuite de données. Cependant, cela semble souvent omis lors de la validation croisée. Supposons que j'effectue une validation croisée sur le train susmentionné. Si j'encode l'ensemble de train et que j'effectue ensuite une validation croisée, cela n'imite pas vraiment les étapes ci-dessus. L'encodage ne devrait-il pas être effectué "dans" la validation croisée alors? Par exemple, en supposant que nous effectuons une validation croisée 5 fois, ne devrions-nous pas ajuster l'encodeur sur 4 fois et transformer le 5ème fois à chaque étape de validation croisée? Je crois que c'est ce qui se fait habituellement dans l'encodage cible, mais pas vraiment avec l'encodage par étiquette ou à chaud.

Mes questions sont donc:

1. Ai-je raison sur la nécessité de monter l'encodeur sur 4 plis et non sur le 5e pli de validation à chaque étape de validation croisée si nous voulons vraiment éviter le surajustement?
2. Si ce n'est pas le cas, pourquoi est-il vraiment nécessaire d'effectuer les 3 étapes mentionnées précédemment tout en traitant l'ensemble de train et de test (hold-out)?

Answer 1

Vous avez raison, l'étape d'encodage elle-même peut être une source de fuite de données et normalement elle doit être effectuée à l'intérieur de la boucle CV en utilisant uniquement l'ensemble d'entraînement actuel, comme vous le décrivez.

La raison est bien celle que vous mentionnez dans le commentaire: s'il y a une étiquette de classe ou une catégorie de fonctionnalité qui n'apparaît pas par hasard dans un ensemble d'apprentissage particulier pendant CV, le modèle n'est pas censé savoir que cette classe / catégorie existe.

En général, je pense que ce problème ne peut que diminuer les performances sur l'ensemble de test, donc ce n'est probablement pas aussi grave que d'autres types de fuite de données. Pourtant, c'est définitivement une conception expérimentale plus propre à encoder en utilisant uniquement l'ensemble d'apprentissage.

Un problème étroitement lié dans la PNL est lorsque le système n'est pas conçu pour traiter les mots hors vocabulaire (OOV): si tous les mots de l'ensemble de formation et de test sont codés (même erreur), alors il semble à tort que n'importe quel texte peut être entièrement codé, ce qui pourrait causer de mauvaises surprises plus tard.

Cela étant dit, c'est généralement une bonne idée de supprimer les caractéristiques rares ou les valeurs d'étiquettes, et si cela est fait, le résultat devrait être le même en utilisant la méthode appropriée ou la méthode bâclée.