Synthèse de 15 années d'expérience en tant qu'architecte logiciel : Dans le domaine du ML, cinq pièges que rencontrent les débutants

La science des données et l'apprentissage automatique deviennent de plus en plus populaires, et le nombre de personnes dans ce domaine augmente chaque jour. Cela signifie que de nombreux data scientists n’ont pas beaucoup d’expérience dans la création de leurs premiers modèles d’apprentissage automatique, et c’est là que des erreurs peuvent survenir.

Récemment, l'architecte logiciel, data scientist et maître de Kaggle Agnis Liukis a écrit un article dans lequel il parle des solutions à certaines des erreurs les plus courantes des débutants en apprentissage automatique afin de s'assurer que les débutants les comprennent et les évitent.

​

Agnis Liukis a plus de 15 ans d'expérience dans l'architecture et le développement de logiciels et maîtrise des langages tels que Java, JavaScript, Spring Boot, React.JS et Python. De plus, Liukis s'intéresse également à la science des données et à l'apprentissage automatique. Il a participé à plusieurs reprises aux concours Kaggle et a obtenu de bons résultats, et a atteint le niveau master du concours Kaggle.

Voici le contenu de l'article :

Dans le domaine du machine learning, avez-vous marché sur ces 5 écueils ?

1. La normalisation des données n'est pas utilisée si nécessaire

Normalisez les données, puis obtenez les caractéristiques et saisissez-les dans le modèle pour laisser le modèle faire des prédictions. Mais dans certains cas, les résultats de cette approche simple peuvent être décevants car il manque un élément très important.

Certains types de modèles nécessitent une normalisation des données, comme la régression linéaire, les réseaux de neurones classiques, etc. Ce type de modèle utilise les valeurs des caractéristiques pour multiplier les poids des valeurs d'entraînement. Dans le cas de caractéristiques non normalisées, la plage possible d'une valeur de caractéristique peut différer de la plage possible d'une autre valeur de caractéristique.

Supposons que la valeur d'une caractéristique soit comprise dans la plage [0, 0,001] et que la valeur de l'autre caractéristique soit comprise dans la plage [100 000, 200 000]. Pour un modèle qui accorde la même importance à deux fonctionnalités, le poids de la première fonctionnalité sera 100 millions de fois supérieur au poids de la deuxième fonctionnalité. Des pondérations élevées peuvent entraîner de sérieux problèmes pour le modèle, par exemple en cas de valeurs aberrantes. De plus, estimer l’importance de diverses caractéristiques devient difficile car un poids élevé peut signifier que la caractéristique est importante, mais cela peut aussi simplement signifier que sa valeur est faible.

Après la normalisation, les valeurs de toutes les caractéristiques sont dans la même plage, généralement [0, 1] ou [-1, 1]. Dans ce cas, les pondérations seront dans une fourchette similaire et correspondront étroitement à l’importance réelle de chaque caractéristique.

Dans l'ensemble, l'utilisation de la normalisation des données lorsque cela est nécessaire produira des prédictions meilleures et plus précises.

2. Pensez que plus il y a de fonctionnalités, mieux c'est

Certaines personnes peuvent penser que l'ajout de toutes les fonctionnalités est une bonne idée, pensant que le modèle sélectionnera et utilisera automatiquement les meilleures fonctionnalités. En fait, cette idée est difficile à réaliser.

Plus le modèle possède de fonctionnalités, plus le risque de surapprentissage est grand. Même dans des données complètement aléatoires, le modèle est capable de trouver certaines caractéristiques (signaux), même si elles sont parfois plus faibles et parfois plus fortes. Bien entendu, il n’y a pas de véritable signal dans le bruit aléatoire. Mais si nous disposons de suffisamment de colonnes bruyantes, il est possible que le modèle en utilise certaines en fonction du signal de défaut détecté. Lorsque cela se produit, la qualité des prédictions du modèle se dégrade car elles reposent en partie sur du bruit aléatoire.

Il existe désormais de nombreuses techniques pour nous aider à effectuer la sélection des fonctionnalités. Mais vous devez vous rappeler que vous devez expliquer chaque fonctionnalité dont vous disposez et pourquoi cette fonctionnalité aidera votre modèle.

3. Utilisez des modèles basés sur des arbres lorsqu'une extrapolation est nécessaire

Les modèles basés sur des arbres sont faciles à utiliser et puissants, c'est pourquoi ils sont populaires. Cependant, dans certains cas, il peut être erroné d’utiliser un modèle arborescent.

Les modèles basés sur des arbres ne peuvent pas être extrapolés, la valeur prédite de ces modèles ne sera jamais supérieure à la valeur maximale dans les données d'entraînement, et ils ne produiront jamais une valeur prédite inférieure à la valeur minimale pendant l'entraînement.

Dans certaines tâches, la capacité d'extrapoler peut être très importante. Par exemple, si le modèle prédit les cours des actions, ceux-ci pourraient être plus élevés que jamais à l’avenir. Dans ce cas, les modèles basés sur les arbres ne seraient pas directement utiles car leurs prévisions dépasseraient presque les prix historiques les plus élevés.

Il existe plusieurs solutions à ce problème, une solution consiste à prédire le changement ou la différence au lieu de prédire directement la valeur. Une autre solution consiste à utiliser différents types de modèles pour de telles tâches. La régression linéaire ou les réseaux de neurones peuvent effectuer une extrapolation.

4. Utilisez la normalisation des données là où elle n'est pas nécessaire

L'article précédent parlait de la nécessité de la normalisation des données, mais ce n'est pas toujours le cas. Les modèles arborescents ne nécessitent pas de normalisation des données. Les réseaux de neurones peuvent également ne pas nécessiter de normalisation explicite, car certains réseaux incluent déjà une couche de normalisation en interne, comme l'opération BatchNormalization de la bibliothèque Keras.

Dans certains cas, même la régression linéaire peut ne pas nécessiter de normalisation des données, ce qui signifie que toutes les caractéristiques sont déjà dans une plage de valeurs similaire et ont la même signification. Par exemple, si le modèle est appliqué à des données de séries chronologiques et que toutes les caractéristiques sont des valeurs historiques du même paramètre.

5. Fuite d'informations entre l'ensemble d'entraînement et l'ensemble de validation/test

Provoquer une fuite de données est plus facile que les gens ne le pensent, considérez l'extrait de code suivant :

​Fuite de données Exemples de fonctionnalités

En fait, les deux fonctionnalités (sum_feature et diff_feature) sont incorrectes. Ils fuient des informations car après avoir été divisées en ensembles d'entraînement/test, la partie contenant les données d'entraînement contiendra des informations provenant des tests. Cela entraînera des scores de validation plus élevés mais des performances moins bonnes lorsqu'ils seront appliqués à des modèles de données réels.

L'approche correcte consiste d'abord à séparer l'ensemble d'entraînement/l'ensemble de test, puis à appliquer ensuite la fonction de génération de fonctionnalités. Habituellement, c'est un bon modèle d'ingénierie de fonctionnalités de traiter l'ensemble de formation et l'ensemble de test séparément.

Dans certains cas, certaines informations peuvent devoir être transmises entre les deux - par exemple, nous pouvons souhaiter utiliser le même StandardScaler sur l'ensemble de test et l'ensemble d'entraînement.

Dans l’ensemble, c’est bien d’apprendre de ses erreurs, et j’espère que les exemples d’erreurs fournis ci-dessus vous aideront.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!