Normalisation avant validation croisée

16

La normalisation des données (pour avoir une moyenne nulle et un écart-type unitaire) avant d'effectuer une validation croisée multipliée par k a-t-elle des conséquences négatives telles qu'un sur-ajustement?

Remarque: c'est pour une situation où #cases> total #features

Je transforme certaines de mes données à l'aide d'une transformation de journal, puis normalise toutes les données comme ci-dessus. J'effectue ensuite la sélection des fonctionnalités. Ensuite, j'applique les fonctionnalités sélectionnées et les données normalisées à une validation croisée répétée de 10 fois pour essayer d'estimer les performances du classificateur généralisé et je crains que l'utilisation de toutes les données pour normaliser ne soit pas appropriée. Dois-je normaliser les données de test pour chaque pli en utilisant les données de normalisation obtenues à partir des données d'entraînement pour ce pli?

Toutes les opinions reçues avec reconnaissance! Toutes mes excuses si cette question semble évidente.

Edit: En testant cela (conformément aux suggestions ci-dessous), j'ai trouvé que la normalisation avant CV ne faisait pas beaucoup de différence en termes de performances par rapport à la normalisation dans CV.

cross-validation normalization

— BGreene
source

13

Pour répondre à votre question principale, il serait optimal et plus approprié d'évoluer dans le CV. Mais cela n'aura probablement pas beaucoup d'importance et pourrait ne pas être important du tout si votre classificateur redimensionne les données, ce qui est le plus important (au moins dans R).

Cependant, la sélection de la fonctionnalité avant la validation croisée est un GRAND NON et entraînera un sur-ajustement, car vous les sélectionnerez en fonction de leurs performances sur l'ensemble des données. La transformation de journal peut être effectuée à l'extérieur, car la transformation ne dépend pas des données réelles (plus du type de données) et n'est pas quelque chose que vous ne feriez pas si vous n'aviez que 90% des données au lieu de 100% et n'est pas modifié selon les données.

Pour répondre également à votre commentaire, il est évident que cela entraînera un sur-ajustement dépendra de votre manière de sélectionner les fonctionnalités. Si vous les choisissez par hasard (pourquoi feriez-vous cela?) Ou en raison de considérations théoriques a priori (autres publications), cela n'aura pas d'importance. Mais si cela dépend de votre ensemble de données, ce sera le cas. Elements of Statistical Learnings a une bonne explication. Vous pouvez télécharger librement et légalement un .pdf ici http://www-stat.stanford.edu/~tibs/ElemStatLearn/

Le point qui vous concerne se trouve dans la section 7.10.2 à la page 245 de la cinquième impression. Il est intitulé "Les mauvaises et les bonnes façons de faire une validation croisée".

— Erik
source

Merci - si les seuls résultats rapportés concernent les performances estimées obtenues en utilisant le modèle sélectionné (caractéristiques) dans chaque pli, cela ne peut pas entraîner un sur-ajustement? Après tout, vous ne signalez que les performances généralisées d'un sous-ensemble de fonctionnalités donné.

— BGreene

J'ai développé ma réponse pour répondre à votre commentaire. Je pense que l'explication dans le lien est meilleure que ce que je peux cuisiner en ce moment.

— Erik

Je vous remercie. Cela suggère que la sélection de fonctionnalités basée sur un filtre standard ne doit jamais être utilisée et que la sélection de fonctionnalités basée sur un wrapper ou équivalent est utilisée à la place. Cela vaut-il toujours pour la situation où #Cases> #Features? (J'ai 259 cas, un total de 56 fonctionnalités). Je suppose que le potentiel d'erreur est moindre ici?

— BGreene

4

La validation croisée est mieux perçue comme une méthode pour estimer la performance d'une procédure statistique, plutôt que comme un modèle statistique. Ainsi, afin d'obtenir une estimation de performance impartiale, vous devez répéter chaque élément de cette procédure séparément dans chaque pli de la validation croisée, ce qui inclurait la normalisation. Je dirais donc normaliser dans chaque pli.

La seule fois où cela ne serait pas nécessaire, c'est si la procédure statistique était complètement insensible à l'échelle et à la valeur moyenne des données.

— Dikran Marsupial
source

Je pense que c'est une bonne réponse, même si elle n'est pas rigoureuse, elle fait passer le message. Je pense que le sens est que si vous normalisez dans chaque pli, il est garanti que la normalisation ne biaisera pas les performances. La façon dont il a été écrit semblait qu'il n'y avait pas d'autre moyen d'éviter les préjugés, bien que Dikran ait souligné à la dernière ligne qu'il existe d'autres moyens. Si vous faites une normalisation à l'intérieur de CV, cela n'augmente jamais le biais, par opposition à le faire à l'extérieur, ce qui peut. Le biais peut ne pas affecter beaucoup de toute façon, comme indiqué dans l'autre réponse.

— Tom Anderson

1

Je pense que si la normalisation n'implique que deux paramètres et que vous avez un bon échantillon de taille ce ne sera pas un problème. Je serais plus préoccupé par la transformation et le processus de sélection des variables. La validation croisée 10 fois semble être à la mode aujourd'hui. Est-ce que personne n'utilise le bootstrap 632 ou 632+ pour l'estimation du taux d'erreur du classificateur comme suggéré d'abord par Efron (1983) dans JASA et suivi plus tard dans un article d'Efron et Tibshirani avec le 632+?

— Michael R. Chernick
source

0

J'aime personnellement la méthode .632. Qui est essentiellement boostrapping avec remplacement. Si vous faites cela et supprimez les doublons, vous obtiendrez 632 entrées sur un ensemble de 1000 entrées.

— MannyK
source

e_{0}

$e_0$