(Je suis sûr que j'ai déjà écrit la plupart de cela dans une réponse - mais je ne le trouve pas pour le moment. Si quelqu'un tombe sur cette réponse, veuillez le lier). Je vois ici 2 approches légèrement différentes, qui je pense sont toutes les deux sensées.
Mais d'abord une terminologie:
- Issu d'un domaine appliqué, un modèle (ajusté / formé) est pour moi un modèle prêt à l'emploi. C'est-à-dire que le modèle contient toutes les informations nécessaires pour générer des prévisions pour de nouvelles données. Ainsi, le modèle contient également les hyperparamètres . Comme vous le verrez, ce point de vue est étroitement lié à l'approche 2 ci-dessous.
- OTOH, l' algorithme de formation selon mon expérience n'est pas bien défini dans le sens suivant: pour obtenir le modèle (ajusté), non seulement le - appelons-le "ajustement primaire" - des paramètres du modèle "normal" doit être fait, mais aussi les hyperparamètres doivent être corrigés. Du point de vue de mon application, il n'y a pas vraiment de différence entre les paramètres et les hyperparamètres: les deux font partie du modèle et doivent être estimés / décidés pendant la formation.
Je suppose que la différence entre eux est liée à la différence entre quelqu'un développant de nouveaux algorithmes de formation qui décrivent généralement une classe d'algorithmes de formation avec certains paramètres de pilotage (les hyperparamètres) qui sont difficiles / impossibles à corriger (ou du moins à déterminer comment elles devraient être décidées / estimées) sans connaissance de l'application / du domaine.
Approche 1: exiger des résultats d'optimisation stables
Avec cette approche, l '«apprentissage du modèle» correspond à l'ajustement des paramètres du modèle «normal» et des hyperparamètres sont donnés. Une validation interne, par exemple croisée, s'occupe de l'optimisation hyperparamétrique.
L'étape / hypothèse cruciale ici pour résoudre le dilemme de l'ensemble hyperparamétrique à choisir est d' exiger que l'optimisation soit stable . La validation croisée à des fins de validation suppose que tous les modèles de substitution sont suffisamment similaires au modèle final (obtenu par le même algorithme d'apprentissage appliqué à l'ensemble des données) pour permettre de les traiter de manière égale (entre eux ainsi qu'au modèle final). Si cette hypothèse tombe en panne et
les modèles de substitution sont toujours égaux (ou équivalents) entre eux mais pas au modèle final, nous parlons du biais pessimiste bien connu de la validation croisée.
Si également le modèle de substitution n'est pas égal / équivalent les uns aux autres, nous avons des problèmes d' instabilité .
Pour les résultats d'optimisation de la boucle interne, cela signifie que si l'optimisation est stable, il n'y a pas de conflit dans le choix des hyperparamètres . Et si une variation considérable est observée entre les résultats de validation croisée interne, l'optimisation n'est pas stable . Les situations d'entraînement instables ont des problèmes bien pires que la simple décision des ensembles d'hyperparamètres à choisir, et je recommanderais vraiment de prendre du recul dans ce cas et de recommencer le processus de modélisation.
Il y a cependant une exception: il peut y avoir plusieurs minima locaux dans l'optimisation donnant des performances égales à des fins pratiques. Exiger également le choix parmi eux d'être stable peut être une exigence forte inutile - mais je ne sais pas comment sortir de ce dilemme.
Notez que si tous les modèles ne produisent pas le même ensemble de paramètres gagnant, vous ne devez pas utiliser les estimations de boucle externe comme erreur de généralisation ici:
- p
- Mais à moins qu'il n'y ait pas de décision impliquée car toutes les divisions ont produit les mêmes paramètres, cela rompra l'indépendance dans la boucle externe: les données de test de chaque division ont déjà entré la décision quel ensemble de paramètres gagne car il s'agissait de données d'apprentissage dans toutes les autres divisions et donc utilisées pour optimiser les paramètres.
Approche 2: traiter le réglage des hyperparamètres dans le cadre de la formation du modèle
Cette approche jette un pont entre les perspectives du «développeur d'algorithme de formation» et de l'utilisateur appliqué de l'algorithme de formation.
Le développeur de l'algorithme de formation fournit un algorithme de formation "nu" model = train_naked (trainingdata, hyperparameters)
. Comme l'utilisateur appliqué a besoin tunedmodel = train_tuned (trainingdata)
qui s'occupe également de fixer les hyperparamètres.
train_tuned
peut être implémenté, par exemple en enroulant un optimiseur basé sur la validation croisée autour de l'algorithme d'apprentissage nu train_naked
.
train_tuned
peut alors être utilisé comme tout autre algorithme d'apprentissage qui ne nécessite pas d'entrée hyperparamétrique, par exemple sa sortie tunedmodel
peut être soumise à une validation croisée. Maintenant, les hyperparamètres sont vérifiés pour leur stabilité tout comme les paramètres "normaux" doivent être vérifiés pour la stabilité dans le cadre de l'évaluation de la validation croisée.
C'est en fait ce que vous faites et évaluez dans la validation croisée imbriquée si vous faites la moyenne des performances de tous les modèles gagnants, indépendamment de leurs ensembles de paramètres individuels.
Quelle est la différence?
Nous nous retrouvons éventuellement avec différents modèles finaux prenant ces 2 approches:
- le modèle final de l'approche 1 sera
train_naked (all data, hyperparameters from optimization)
- tandis que l'approche 2 utilisera
train_tuned (all data)
et - comme cela exécute à nouveau l'optimisation des hyperparamètres sur l'ensemble de données plus volumineux - cela peut aboutir à un ensemble différent d'hyperparamètres.
Mais encore une fois, la même logique s'applique: si nous constatons que le modèle final a des paramètres sensiblement différents des modèles de substitution de validation croisée, c'est un symptôme de l'hypothèse 1 violée. Donc à mon humble avis, encore une fois, nous n'avons pas de conflit, mais plutôt un contrôle pour savoir si nos hypothèses (implicites) sont justifiées. Et s'ils ne le sont pas, nous ne devons pas trop miser sur une bonne estimation des performances de ce modèle final.
J'ai l'impression (également en voyant le nombre de questions / confusions similaires ici sur CV) que beaucoup de gens pensent que la validation croisée imbriquée fait l'approche 1. Mais l'erreur de généralisation est généralement estimée selon l'approche 2, c'est donc la voie à suivre pour le modèle final aussi.
Exemple d'iris
Résumé: L'optimisation est fondamentalement inutile. La taille d'échantillon disponible ne permet pas de distinctions entre les performances d'aucun des ensembles de paramètres ici.
Du point de vue de l'application, cependant, la conclusion est que peu importe lequel des 4 ensembles de paramètres vous choisissez - ce qui n'est pas si mal que ça: vous avez trouvé un plateau de paramètres relativement stable. Voici l'avantage de la validation imbriquée appropriée du modèle réglé: bien que vous ne puissiez pas prétendre que c'est le modèle optimal, vous pouvez toujours prétendre que le modèle construit sur l'ensemble des données en utilisant l'approche 2 aura précision d'environ 97% (intervalle de confiance à 95% pour 145 cas corrects sur 150: 92 - 99%)
Notez que l'approche 1 n'est pas aussi éloignée qu'il y paraît - voir ci-dessous: votre optimisation a accidentellement raté un "gagnant" relativement clair à cause des liens (c'est en fait un autre symptôme très révélateur du problème de taille de l'échantillon).
Bien que je ne sois pas assez profondément dans les SVM pour "voir" que C = 1 devrait être un bon choix ici, j'irais avec le noyau linéaire plus restrictif. De plus, comme vous l'avez fait pour l'optimisation, il n'y a rien de mal à choisir le jeu de paramètres gagnant même si vous savez que tous les jeux de paramètres conduisent à des performances pratiquement égales.
À l'avenir, cependant, demandez-vous si votre expérience donne des estimations approximatives des performances que vous pouvez attendre et à peu près quel modèle serait un bon choix. Créez ensuite ce modèle (avec des hyperparamètres fixés manuellement) et calculez un intervalle de confiance pour ses performances. Utilisez-le pour décider s'il est judicieux d'optimiser. (Je peux ajouter que je travaille principalement avec des données où l'obtention de 10 cas indépendants supplémentaires n'est pas facile - si vous êtes dans un domaine avec de grands échantillons indépendants, les choses vont beaucoup mieux pour vous)
version longue:
Comme pour l'exemple des résultats sur l' iris
ensemble de données. iris
a 150 cas, SVM avec une grille de 2 x 2 paramètres (2 noyaux, 2 ordres de grandeur pour la pénalité C
) sont considérés.
La boucle intérieure a des divisions de 129 (2x) et 132 (6x) cas. Le "meilleur" jeu de paramètres est indécis entre le noyau linéaire ou rbf, tous deux avec C = 1. Cependant, les précisions de test internes sont toutes (y compris le C toujours perdant = 10) dans une précision observée de 94 à 98,5%. La plus grande différence que nous avons dans l'une des divisions est de 3 contre 8 erreurs pour rbf avec C = 1 contre 10.
Il n'y a aucun moyen que ce soit une différence significative. Je ne sais pas comment extraire les prédictions pour les cas individuels dans le CV, mais même en supposant que les 3 erreurs ont été partagées et que le modèle C = 10 a fait 5 erreurs supplémentaires:
> table (rbf1, rbf10)
rbf10
rbf1 correct wrong
correct 124 5
wrong 0 3
> mcnemar.exact(rbf1, rbf10)
Exact McNemar test (with central confidence intervals)
data: rbf1 and rbf10
b = 5, c = 0, p-value = 0.0625
alternative hypothesis: true odds ratio is not equal to 1
N'oubliez pas qu'il y a 6 comparaisons par paires dans la grille 2 x 2, nous devons donc également corriger les comparaisons multiples.
Approche 1
Dans 3 des 4 divisions externes où rbf a "gagné" sur le noyau linéaire, ils avaient en fait la même précision estimée (je suppose que min en cas de liens renvoie le premier indice approprié).
Changer la grille en
params = {'kernel':['linear', 'rbf'],'C':[1,10]}
rendements
({'kernel': 'linear', 'C': 1}, 0.95238095238095233, 0.97674418604651159)
({'kernel': 'rbf', 'C': 1}, 0.95238095238095233, 0.98449612403100772)
({'kernel': 'linear', 'C': 1}, 1.0, 0.97727272727272729)
({'kernel': 'linear', 'C': 1}, 0.94444444444444442, 0.98484848484848486)
({'kernel': 'linear', 'C': 1}, 0.94444444444444442, 0.98484848484848486)
({'kernel': 'linear', 'C': 1}, 1.0, 0.98484848484848486)
({'kernel': 'linear', 'C': 1}, 1.0, 0.96212121212121215)
Approche 2:
Voici clf
votre modèle final. Avec random_state = 2
, rbf avec C = 1 gagne:
In [310]: clf.grid_scores_
[...snip warning...]
Out[310]:
[mean: 0.97333, std: 0.00897, params: {'kernel': 'linear', 'C': 1},
mean: 0.98000, std: 0.02773, params: {'kernel': 'rbf', 'C': 1},
mean: 0.96000, std: 0.03202, params: {'kernel': 'linear', 'C': 10},
mean: 0.95333, std: 0.01791, params: {'kernel': 'rbf', 'C': 10}]
(se produit environ 1 fois sur 5, 1 fois sur 6 linear
et rbf
avec C = 1
sont à égalité au rang 1)