Comme vous l'avez déjà observé vous-même, votre choix de fonctionnalités (sélection de fonctionnalités) peut avoir un impact sur les hyperparamètres de votre algorithme qui sont optimaux, et les hyperparamètres que vous sélectionnez pour votre algorithme peuvent avoir un impact sur le choix de fonctionnalités qui serait optimal.
Donc, oui, si vous vous souciez vraiment de réduire chaque pourcentage de performances de votre modèle et que vous pouvez vous permettre la quantité de calcul requise, la meilleure solution est probablement de sélectionner les fonctionnalités et de régler les hyperparamètres "en même temps". Ce n'est probablement pas facile (selon la façon dont vous sélectionnez la fonctionnalité). La façon dont j'imagine que cela fonctionnerait serait d'avoir différents ensembles de fonctionnalités en tant que candidats et de traiter la sélection d'un ensemble de fonctionnalités parmi tous ces ensembles de candidats comme un hyperparamètre supplémentaire.
En pratique, cela n'est peut-être pas vraiment réalisable. En général, si vous ne pouvez pas vous permettre d'évaluer toutes les combinaisons possibles, je recommanderais:
Optimisez de manière très lâche les hyperparamètres, juste pour vous assurer de ne pas attribuer de valeurs extrêmement mauvaises à certains hyperparamètres. Cela peut souvent être fait à la main si vous avez une bonne compréhension intuitive de vos hyperparamètres, ou effectué avec une procédure d'optimisation d'hyperparamètres très brève en utilisant juste un tas de fonctionnalités que vous savez être décemment bonnes sinon.
Sélection de fonctionnalités, avec des hyperparamètres qui ne sont peut-être pas optimisés à 100% mais qui ne sont pas non plus extrêmement terribles. Si vous avez déjà au moins un algorithme d'apprentissage machine quelque peu décemment configuré, avoir de bonnes fonctionnalités sera beaucoup plus important pour vos performances que la micro-optimisation des hyperparamètres. Exemples extrêmes: si vous n'avez pas de fonctionnalités, vous ne pouvez rien prédire. Si vous avez une fonction de triche qui contient l'étiquette de classe, vous pouvez parfaitement tout classer.
Optimisez les hyperparamètres avec les fonctionnalités sélectionnées à l'étape ci-dessus. Cela devrait être un bon ensemble de fonctionnalités maintenant, où cela peut valoir la peine d'optimiser un peu les hyperparams.
Pour répondre à la question supplémentaire que Nikolas a postée dans les commentaires, concernant la façon dont toutes ces choses (sélection de fonctionnalités, optimisation hyperparamétrique) interagissent avec la validation croisée k-fold: je dirais que cela dépend.
Chaque fois que vous utilisez des données dans l'un des plis pour quoi que ce soit, puis que vous évaluez les performances sur ce même pli, vous obtenez une estimation biaisée de vos performances (vous surestimerez les performances). Donc, si vous utilisez des données dans tous les plis pour l'étape de sélection des fonctionnalités, puis évaluez les performances sur chacun de ces plis, vous obtiendrez des estimations biaisées des performances pour chacun d'eux (ce qui n'est pas bon). De même, si vous avez une optimisation d'hyperparamètre basée sur les données et utilisez des données de certains plis (ou de tous les plis), puis que vous évaluez sur ces mêmes plis, vous obtiendrez à nouveau des estimations biaisées des performances. Les solutions possibles sont:
Répétez le pipeline complet à l'intérieur de chaque pli séparément (par exemple, à l'intérieur de chaque pli, faites la sélection des fonctionnalités + optimisation hyperparamétrique et modèle de formation). Cela signifie que la validation croisée k-fold vous donne des estimations impartiales des performances de ce pipeline complet .
Divisez votre ensemble de données initial en un '' ensemble de données de prétraitement '' et un '' ensemble de données de formation / test ''. Vous pouvez faire votre sélection d'entités + optimisation hyperparamétrique sur le '' jeu de données de prétraitement ''. Ensuite, vous corrigez les entités et les hyperparamètres sélectionnés et effectuez une validation croisée k-fold sur le `` train / ensemble de données de test ''. Cela signifie que la validation croisée k-fold vous donne des estimations impartiales des performances de votre algorithme ML compte tenu des valeurs fixes de l'ensemble de fonctionnalités et de l'hyperparamètre .
Notez comment les deux solutions entraînent des estimations de performances légèrement différentes. Laquelle est la plus intéressante dépend de votre cas d'utilisation, dépend de la façon dont vous prévoyez de déployer vos solutions d'apprentissage automatique dans la pratique. Si vous êtes, par exemple, une entreprise qui a l'intention de disposer du pipeline complet de sélection de fonctionnalités + optimisation hyperparamétrique + formation s'exécutant automatiquement tous les jours / semaines / mois / année / peu importe, vous serez également intéressé par les performances de cet ensemble pipeline, et vous voudrez la première solution.
Si, d'autre part, vous ne pouvez vous permettre de faire la sélection des fonctionnalités + l'optimisation des hyperparamètres qu'une seule fois dans votre vie, et ensuite de ne réentraîner que légèrement régulièrement votre algorithme (avec les valeurs des fonctionnalités et des hyperparamètres fixes), alors les performances seule cette étape sera ce qui vous intéresse, et vous devriez opter pour la deuxième solution