Question:
Quand dois-je appliquer la mise à l'échelle des fonctionnalités pour mes données
jjepsuomi
2014-10-29 14:00:48 UTC
view on stackexchange narkive permalink

J'ai eu une discussion avec un collègue et nous avons commencé à nous demander, quand appliquer la normalisation / mise à l'échelle des fonctionnalités aux données? Disons que nous avons un ensemble de fonctionnalités avec certaines fonctionnalités ayant une très large gamme de valeurs et certaines fonctionnalités n'ayant pas une plage de valeurs aussi large.

Si je faisais une analyse en composantes principales, j'aurais besoin de normaliser les données, c'est clair, mais disons que nous essayons de classer les données en utilisant une régression linéaire / voisine k plus proche simple et simple méthode.

Dans quelles conditions dois-je ou ne dois-je pas normaliser les données et pourquoi? Un exemple court et simple mettant en évidence le point ajouté à la réponse serait parfait.

Voir: https://stats.stackexchange.com/questions/29781/when-conducting-multiple-regression-when-should-you-center-your-predictor-varia
Cinq réponses:
Karolis Koncevičius
2014-10-29 15:05:40 UTC
view on stackexchange narkive permalink

À mon avis, la question sur la mise à l'échelle / la non-mise à l'échelle des fonctionnalités dans l'apprentissage automatique est une déclaration sur les unités de mesure de vos fonctionnalités. Et cela est lié aux connaissances préalables que vous avez sur le problème.

Certains algorithmes, tels que Linear Discriminant Analysis et Naive Bayes font la mise à l'échelle des fonctionnalités par conception et vous n’auriez aucun effet à en exécuter un manuellement. D'autres, comme knn peuvent en être gravement affectés.

Donc, avec le type de classificateur knn, vous devez mesurer les distances entre les paires d'échantillons. Les distances seront bien entendu influencées par les unités de mesure utilisées. Imaginez que vous classiez la population en hommes et en femmes et que vous ayez un tas de mesures, y compris la taille. Maintenant, le résultat de votre classification sera influencé par les mesures dans lesquelles la hauteur a été rapportée. Si la hauteur est mesurée en nanomètres, il est probable que les k voisins les plus proches auront simplement des mesures de hauteur similaires. Vous devez mettre à l'échelle.

Cependant, à titre d'exemple de contraste, imaginez classer quelque chose qui a des unités de mesure égales enregistrées avec du bruit. Comme une photographie, un microréseau ou un spectre. dans ce cas vous savez déjà a-priori que vos entités ont des unités égales. Si vous les étiez tous, vous amplifieriez l'effet des caractéristiques qui sont constantes sur tous les échantillons, mais qui ont été mesurées avec du bruit. (Comme un arrière-plan de la photo). Cela aura à nouveau une influence sur knn et pourrait réduire considérablement les performances si vos données avaient des valeurs constantes plus bruyantes que celles qui varient. Désormais, toute similitude entre les k voisins les plus proches sera influencée par le bruit.

C'est comme pour tout le reste de l'apprentissage automatique - utilisez les connaissances préalables autant que possible et dans le cas des fonctionnalités de boîte noire, faites les deux et croisez- valider.

De bons exemples ...
Juste un suivi rapide, pourquoi kNN serait-il affecté par la mise à l'échelle des fonctionnalités?La distance Mahalanobis devrait déjà en rendre compte pour autant que je sache.
@SebastianRaschka Lorsque kNN a été mentionné pour une raison quelconque, je n'avais en tête que la distance euclidienne.Cela devrait expliquer la confusion.kNN peut bien sûr être utilisé avec d'autres mesures de distance et merci de l'avoir remarqué.
Dans le cours d'apprentissage automatique d'Andrew Ng, il explique que la mise à l'échelle des fonctionnalités est également importante lors de la descente de gradient pour s'adapter à un modèle de régression linéaire (https://www.coursera.org/learn/machine-learning/lecture/xx3Da/gradient-descent-mise à l'échelle des fonctionnalités dans la pratique).
Neil G
2014-10-29 14:58:58 UTC
view on stackexchange narkive permalink

Vous devez normaliser lorsque l'échelle d'une entité n'est pas pertinente ou trompeuse, et ne pas normaliser lorsque l'échelle est significative.

K-means considère que la distance euclidienne est significative. Si une entité a une grande échelle par rapport à une autre, mais que la première caractéristique représente vraiment une plus grande diversité, alors le regroupement dans cette dimension devrait être pénalisé.

En régression, tant que vous avez un biais, cela n'a pas d'importance si vous normalisez ou non depuis que vous découvrez une carte affine, et que la composition d'une transformation d'échelle et d'une carte affine est toujours affine.

Quand il y a des taux d'apprentissage impliqués, par exemple lorsque vous effectuez une descente de gradient, l'échelle d'entrée met efficacement à l'échelle les gradients, ce qui peut nécessiter une sorte de méthode du second ordre pour stabiliser les taux d'apprentissage par paramètre. Il est probablement plus facile de normaliser les entrées si cela n'a pas d'importance.

show_stopper
2014-10-29 14:49:07 UTC
view on stackexchange narkive permalink

Il existe plusieurs méthodes de normalisation.

En ce qui concerne la régression, si vous prévoyez de normaliser la fonctionnalité par un seul facteur, cela n'est pas nécessaire. La raison en est que la normalisation à un seul facteur comme la division ou la multiplication par une constante est déjà ajustée dans les poids (c'est-à-dire que le poids d'une entité est 3, mais si nous normalisons toutes les valeurs de l'entité en divisant par 2, alors le nouveau le poids sera de 6, donc globalement l'effet est le même). En revanche, si vous envisagez de vouloir dire normaliser, alors il y a une autre histoire. La normalisation moyenne est bonne lorsqu'il y a une grande variance dans les valeurs des caractéristiques (1 70 300 4). De plus, si une seule caractéristique peut avoir un effet à la fois positif et négatif, il est bon de vouloir dire normaliser. En effet, lorsque vous entendez normaliser un ensemble donné de valeurs positives, les valeurs inférieures à la moyenne deviennent négatives tandis que celles ci-dessus deviennent positives.

En ce qui concerne les k voisins les plus proches, la normalisation doit être effectuée tout le temps. En effet, dans KNN, la distance entre les points provoque le regroupement. Donc, si vous appliquez KNN sur un problème avec 2 fonctionnalités avec la première fonctionnalité allant de 1 à 10 et l'autre allant de 1 à 1000, alors tous les clusters seront générés en fonction de la deuxième fonctionnalité car la différence entre 1 et 10 est petit par rapport à 1-1000 et peuvent donc tous être regroupés dans un seul groupe

"… Si une seule caractéristique peut avoir un effet à la fois positif et négatif, alors il est bon de vouloir dire normaliser. C'est parce que lorsque vous entendez normaliser un ensemble donné de valeurs positives, les valeurs inférieures à la moyenne deviennent négatives tandis que celles supérieures à la moyenne deviennent positives."- L'existence d'un terme de biais ne permettra-t-elle pas à une caractéristique d'avoir un effet positif ou négatif malgré une plage de valeurs positive?
cbeleites unhappy with SX
2015-10-04 17:00:37 UTC
view on stackexchange narkive permalink

Voici un autre exemple d'application chimiométrique où la mise à l'échelle des caractéristiques serait désastreuse:

Il existe de nombreuses tâches de classification (analyse qualitative) de la forme "tester si un contenu d'analyte (= substance d'intérêt) est en dessous de ( ou au-dessus) d'un seuil donné (par exemple, limite légale) ". Dans ce cas, les capteurs pour produire les données d'entrée pour le classificateur seraient choisis pour avoir $$ signal = f (analyte ~ concentration) $$, de préférence avec $ f $ étant une fonction raide et même linéaire.

Dans cette situation, la mise à l'échelle des fonctionnalités effacerait essentiellement toutes les informations pertinentes des données brutes.


En général, quelques questions qui aident à décider si la mise à l'échelle est une bonne idée:

  • Que fait la normalisation sur vos données? résoudre la tâche à accomplir? Cela devrait-il devenir plus facile ou risquez-vous de supprimer des informations importantes?
  • Votre algorithme / classificateur réagit-il de manière sensible à l'échelle (numérique) des données? (convergence)
  • L'algorithme / classificateur est-il fortement influencé par différentes échelles de caractéristiques différentes?
  • Si oui, vos caractéristiques partagent-elles les mêmes échelles (ou comparables) ou même des unités physiques?
  • Votre classificateur / algorithme / implémentation réelle effectue-t-il sa propre normalisation?
RUser4512
2018-04-19 13:55:32 UTC
view on stackexchange narkive permalink

Ce problème semble en fait négligé dans de nombreux cours / ressources d'apprentissage automatique. J'ai fini par écrire un article sur la mise à l'échelle sur mon blog.

En bref, il existe des méthodes d'apprentissage invariantes de "transformation monotone" (arbres de décision et tout ce qui en dérive), des méthodes d'apprentissage invariantes de traduction (kNN, SVM avec noyau RBF), et les autres.

De toute évidence, les méthodes d'apprentissage invariant par transformation monotone sont invariantes par traduction.

Avec le premier cours, vous n'avez pas besoin de faire de centrage / mise à l'échelle. Avec les algorithmes invariants de traduction, le centrage est inutile. Maintenant, pour les autres méthodes, cela dépend vraiment des données. Habituellement, cela peut valoir la peine d'essayer la mise à l'échelle (surtout si les variables ont des ordres de grandeur différents).

Dans un cas général, je recommanderais d'essayer divers prétraitements des données: sans mise à l'échelle, mise à l'échelle divisant par l'écart type, mise à l'échelle divisant par la somme des valeurs absolues de vos données (ce qui la ferait reposer sur un simplexe). L'un d'eux fonctionnera mieux que les autres, mais je ne peux pas dire lequel avant d'avoir essayé.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...