Ingénierie des fonctionnalités : génération de variantes, codage, mise à l'échelle et évitement des fuites

Gains :

• Capacité à produire des fonctionnalités dérivées significatives avec la connaissance du domaine et à encoder des catégories catégorielles avec des méthodes appropriées (one-hot, label, target)
• Capacité à mettre à l'échelle les variables numériques en fonction du type de modèle (normalisation, normalisation) et à éviter une mise à l'échelle inutile ou incomplète
• Possibilité d'éviter les fuites de fonctionnalités en apprenant toutes les transformations après la division formation/test et uniquement à partir de la formation

Il existe un vieil adage en matière d'apprentissage automatique : « L'apprentissage automatique appliqué est essentiellement une ingénierie de fonctionnalités. » Parce que le succès d’un modèle dépend souvent des données que vous fournissez au modèle, plutôt que de l’algorithme que vous choisissez. L'ingénierie des fonctionnalités est l'art de produire des signaux significatifs à partir de données brutes dont le modèle peut tirer des leçons. L’intelligence artificielle est à ce stade une riche source d’idées : lorsqu’on demande « quelles fonctionnalités peuvent être produites à partir de ces données », elle énumère des dizaines de suggestions. Mais certaines de ces suggestions peuvent être utiles, d’autres inutiles et d’autres encore dangereuses (fuite). C'est votre travail de régler le problème.

Pourquoi l'ingénierie des fonctionnalités

Les données brutes arrivent rarement au modèle sous leur meilleure forme. Même si la colonne « date de naissance » à elle seule n'a aucun sens, la valeur « âge » qu'elle génère est un signal fort. Vous pouvez extraire des attributs tels que « jour de la semaine », « jour/nuit », « est-ce un jour férié » à partir de « l'horodatage de la commande ». Vous pouvez combiner deux colonnes pour produire un ratio (« ratio dette/revenu »). Ici, l'ingénierie des fonctionnalités traduit la connaissance du domaine en signal mathématique ; Et c’est justement pour cela que c’est l’étape qui requiert le plus d’intelligence humaine.

Conversion de variables catégorielles en nombres : codage

Les modèles fonctionnent généralement avec des chiffres et non avec du texte. La conversion de variables catégorielles (telles que la ville, la couleur, le type de produit) en nombres s'appelle l'encodage. Trois méthodes courantes :

Encodage à chaud : ouvre une colonne distincte avec une valeur de 0/1 pour chaque catégorie. Pour la « ville », des colonnes Istanbul, Ankara, Izmir sont formées ; Si un client vient d'Istanbul, seule cette colonne sera 1. Idéal lorsque le nombre de catégories est petit ; S'il y a trop de catégories, cela produit des centaines de colonnes (c'est ce qu'on appelle une « explosion de taille »).

Encodage des étiquettes : donne un numéro à chaque catégorie (Istanbul=0, Ankara=1). C'est simple, mais cela peut accidentellement apprendre une séquence au modèle (comme Ankara > Istanbul) ; il est donc utilisé avec prudence dans les catégories non ordonnées.

Encodage cible : remplace chaque catégorie par la moyenne de la variable cible dans cette catégorie. C'est une source de fuite très puissante, mais la plus dangereuse : si l'on prend en compte la cible des données de test, le modèle voit l'avenir. Il doit être calculé uniquement à partir des données d'entraînement et avec soin (dans le cadre d'une validation croisée).

Mise à l'échelle : les grands nombres ne submergent pas le modèle

Certains modèles (basés sur la distance, modèles linéaires, réseaux de neurones) sont sensibles à l'échelle des variables. Si le « revenu » (0-500 000) et « l’âge » (0-100) suivent le même schéma, le revenu peut dominer simplement parce qu’il est plus élevé. La mise à l'échelle corrige ce problème. Deux méthodes courantes : la standardisation (convertit chaque valeur en "combien d'écarts types par rapport à la moyenne") et la normalisation (normalisation min-max - compresse les valeurs dans la plage 0-1). Les modèles arborescents (arbres de décision, forêt aléatoire) sont insensibles à l'échelle et ne nécessitent pas de mise à l'échelle.

Attention : les paramètres de mise à l'échelle et de codage (moyenne, écart type, cartographie catégorie-moyenne) doivent être calculés uniquement à partir des données d'entraînement, puis la même chose doit être appliquée aux données de test. L'inclusion de données de test constitue une fuite et donne à votre modèle une meilleure apparence qu'il ne l'est réellement.

Le cœur des fuites dans l’ingénierie des fonctionnalités

La génération de fonctionnalités est le point de départ le plus fréquent des fuites de données. Deux erreurs typiques : Fuite de temps – production d'une fonctionnalité qui inclut des informations futures (y compris les jours après le jour de prévision lors du calcul de la « moyenne des 30 derniers jours »). Fuite de statistiques : calcul d'une caractéristique (moyenne de mise à l'échelle, valeur de codage cible) à partir de toutes les données avant la répartition formation/test. Règle : apprenez chaque transformation après avoir d'abord effectué la répartition entraînement/test et uniquement à partir des données d'entraînement. Le moyen le plus sûr de le faire régulièrement est d'utiliser un pipeline, une structure qui collecte toutes les transformations dans une seule chaîne et les applique après la division.

Méthode

pour quoi

Risque de fuite

remarque

Encodage à chaud

Variable avec peu de catégories

faible

Explose la taille dans plusieurs catégories

Codage des étiquettes

Catégorie triée

faible

Le désordre enseigne le mauvais ordre

codage cible

Multi-catégories, signal fort

très élevé

Juste issu de l'éducation, en CV

normalisation

Modèles linéaires/distance

moyen

Le paramètre dépend uniquement de l'éducation

Fonctionnalité de fenêtre temporelle

séries chronologiques

haut

Ajouter le futur

trois mini-cases

Cas 1 — Biens de valeur. Une équipe de crédit a généré la fonctionnalité « ratio dette/revenu » à partir des colonnes brutes « revenu mensuel » et « paiement mensuel de la dette ». Cette fonctionnalité dérivée unique a augmenté la précision du modèle de 71 % à 79 % ; parce que c’était le taux, et non le revenu absolu, qui déterminait réellement le risque. Leçon : les ratios générés par la connaissance du domaine sont des signaux forts.

Cas 2 — Fuite d’encodage cible. Une équipe a converti le « code postal » en un nombre avec le codage cible (le taux de désabonnement moyen dans cette zone), mais l'a fait à partir de toutes les données avant de les diviser. Le modèle a donné 94 % sur l'ensemble de test, tombant à 68 % en production. 6 semaines d'efforts inutiles. Leçon : le codage des cibles est effectué avec soin, uniquement dans le cadre de la formation.

Cas 3 — Oubli de mise à l’échelle. Un analyste a intégré les revenus (0 à 400 000) et l'âge des clients (18 à 75 ans) dans un modèle basé sur la distance, sans mise à l'échelle. Le modèle s’est penché presque exclusivement sur le revenu, annulant ainsi l’effet de l’âge. Lorsque la mise à l’échelle a été ajoutée, la segmentation est devenue significative. Leçon : la mise à l'échelle n'est pas négligée dans les modèles distance/linéaire.

Quatre modèles copiables

1) Génération d'idées de fonctionnalités (l'élimination dépend de vous) :

Votre rôle : assistant d'ingénierie des fonctionnalités. Mes colonnes df : Birth_date, order_time (horodatage), Income_tl, Debt_tl, City, product_category. Cible : « le prêt sera-t-il remboursé » (0/1). Suggérez 15 fonctionnalités pouvant être générées à partir de ces colonnes ; préciser le risque de fuite (faible/moyen/élevé) pour chacun. Marquez clairement ceux qui contiennent des informations futures.

2) Codage sécurisé (post-split) :

Écrivez du code qui code à chaud « city » et « product_category ». IMPORTANT : adaptez l'encodage uniquement aux données d'entraînement, puis transformez les données de test (avec sklearn OneHotEncoder). Expliquez comment vous gérez la catégorie invisible (handle_unknown) dans l'éducation.

3) Conversion sans fuite avec Pipeline :

Configurez le pipeline sklearn : appliquez StandardScaler aux colonnes numériques, OneHotEncoder aux colonnes catégorielles, ajoutez un classificateur à la fin. Garantissez que toutes les transformations sont apprises APRÈS la répartition train/test et uniquement à partir de la formation. Expliquez le code et pourquoi il ne fuit pas.

4) Fonction de fenêtre temporelle (contrôle des fuites) :

Générez l'attribut « nombre de commandes au cours des 30 derniers jours » pour chaque client, mais n'incluez JAMAIS de données après le jour de prévision. Expliquez ligne par ligne que le code ne regarde pas vers le futur. Je fournirai la colonne de date de référence.

Invite faible/Invite forte

Invite faible :

Ajoutez de bonnes propriétés à ces données.

« Bon » n'est pas défini, l'objectif n'est pas clair, il n'y a pas de contrôle des fuites. L’IA génère des fonctionnalités aléatoires, voire fuyantes.

Invite puissante :

Votre rôle : ingénieur feature. Cible : "churn en 30 jours" (0/1), date de référence estimée : save_date. Il y a un historique des transactions dans df.Tâche : générer 8 fonctionnalités, répondre à la question « Ai-je cette information au moment de la prédiction » pour CHACUNE. Ajout de la date après la date de référence dans les fonctionnalités de fenêtre horaire. Écrivez le code d'une manière compatible avec le pipeline pour qu'il soit exécuté après la section d'entraînement/test.

Ici, l'objectif, le temps de référence et le contrôle des fuites sont définis dès le début.

Erreurs courantes

• Apprendre la transformation de toutes les données avant la division. Si le paramètre de mise à l'échelle/codage voit les données de test, une fuite se produit.
• Utilisation imprudente du codage cible. Il s’agit de la méthode la plus puissante, mais celle qui présente le plus de fuites ; juste issu de la formation, en validation croisée.
• Ajouter le futur avec une fonctionnalité de fenêtre temporelle. Si le calcul des « 30 derniers jours » est saisi après le jour de prévision, le modèle voit l'avenir.
• Mise à l'échelle inutile dans le modèle arborescent et mise à l'échelle incomplète dans le modèle linéaire. Les décisions de mise à l'échelle sont prises en fonction du type de modèle.
• Ajout de toutes les suggestions de fonctionnalités de l'IA sans aucun doute. Les suggestions peuvent inclure des fonctionnalités inutiles et qui fuient.

Astuce : notez une seule question pour chaque caractéristique que vous générez : « Puis-je calculer cette valeur avec les informations dont je dispose au moment où je fais la prédiction ? » Si la réponse n’est pas clairement « oui », n’utilisez pas cette fonction. Cette seule discipline élimine la plupart des fuites liées aux fonctionnalités.

En résumé

L'ingénierie des fonctionnalités est l'art de générer des signaux significatifs à partir de données brutes et détermine souvent le succès du modèle davantage que celui de l'algorithme. L'encodage des catégories (one-hot, label, target), la mise à l'échelle des numériques (standardisation, normalisation) et la production de fonctionnalités dérivées avec la connaissance du domaine sont les outils de base. Mais cette phase est aussi le cœur de la fuite : toutes les transformations doivent être apprises après le fractionnement entraînement/test et uniquement à partir des données d'entraînement. L'IA génère de nombreuses idées ; C'est le jugement humain qui distingue ce qui a de la valeur et ce qui est dangereux.

Tâche de candidature

Choisissez une variable cible et concevez au moins cinq fonctionnalités dérivées à partir des colonnes dont vous disposez. Pour chacun d'entre eux, répondez par écrit à la question « suis-je disponible au moment de la prédiction » et éliminez-en au moins une comme « risque élevé de fuite ». Codez ensuite les fonctionnalités sécurisées dans un pipeline à implémenter après la partition.

liste de contrôle

• [ ] Ai-je appliqué toutes les transformations après la répartition train/test ?
• [ ] Ai-je appris uniquement les paramètres de mise à l'échelle/d'encodage lors de la formation ?
• [ ] Ai-je répondu à la question « est-ce que je l'ai au moment de la prédiction » pour chaque fonctionnalité ?
• [ ] Ai-je fait particulièrement attention aux méthodes à haut risque telles que le codage cible ?
• [ ] Ai-je décidé d'adapter l'échelle de manière appropriée au type de modèle (arbre/linéaire) ?