Normalisation avant validation croisée

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.

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".

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.

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+?

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.