Représentation : qualités d'une bonne caractéristique

Nous avons vu diverses manières de mettre en correspondance des données brutes avec des vecteurs de caractéristiques appropriés, mais ce n'est qu'une partie du travail à faire. Voyons à présent les types de valeurs qui permettent d'obtenir des caractéristiques de qualité pour ces vecteurs de caractéristiques.

Éviter les valeurs de caractéristiques discrètes rarement utilisées

Les valeurs d'une bonne caractéristique doivent apparaître à peu près au moins cinq fois dans un ensemble de données. De cette manière, un modèle peut apprendre comment cette valeur de caractéristique est liée à l'étiquette. Autrement dit, si vous disposez de nombreux exemples avec la même valeur discrète, le modèle a l'occasion de voir la caractéristique dans différents contextes et de déterminer ainsi lorsque celle-ci constitue un bon indicateur pour l'étiquette. Par exemple, la caractéristique house_type contiendrait sans doute de nombreux exemples pour lesquels la valeur serait victorian :

house_type: victorian

À l'inverse, si la valeur d'une fonction n'apparaît qu'une seule fois, ou très rarement, le modèle ne peut pas réaliser de prédictions à partir de cette caractéristique. Par exemple, unique_house_id est une mauvaise caractéristique, car chaque valeur n'est utilisée qu'une seule fois. Le modèle ne peut donc en tirer aucun enseignement :

unique_house_id: 8SK982ZZ1242Z

Privilégier les significations claires

La signification de chaque caractéristique doit être claire pour tout membre de l'équipe de projet. Prenons par exemple la bonne caractéristique suivante pour l'âge d'une habitation. Elle est aussitôt reconnaissable comme étant l'âge en années :

house_age: 27

À l'inverse, la signification de la valeur de caractéristique suivante est quasiment incompréhensible, sauf pour l'ingénieur qui l'a créée :

house_age: 851472000

Dans certains cas, des valeurs peu claires peuvent êtres dues à un bruit dans les données (plutôt qu'à de mauvais choix de création). Par exemple, la caractéristique user_age suivante provient d'une source pour laquelle aucune vérification de la qualité des valeurs n'a été effectuée :

user_age: 277

Ne pas mélanger des valeurs "magiques" avec des données réelles

Une bonne caractéristique en virgule flottante ne contient pas de valeurs hors plage, ni de valeurs "magiques". Supposons par exemple qu'une caractéristique contienne une valeur en virgule flottante comprise entre 0 et 1. Les valeurs suivantes sont acceptables :

quality_rating: 0.82
quality_rating: 0.37

Toutefois, si un utilisateur n'a pas saisi de valeur pour quality_rating, il est possible que l'ensemble de données ait représenté son absence par une valeur magique semblable à la valeur suivante :

quality_rating: -1

Pour éviter ce problème de valeurs magiques, convertissez la caractéristique en deux caractéristiques :

  • Une caractéristique qui ne contient que les "quality-rating" et aucune valeur magique.
  • Une caractéristique qui contient une valeur booléenne indiquant si une valeur a été fournie pour quality_rating. Donnez à cette caractéristique booléenne un nom du type is_quality_rating_defined.

Tenir compte de l'instabilité en amont

La définition d'une caractéristique ne doit pas changer au fil du temps. Par exemple, la valeur suivante est utile, car le nom de la ville ne changera probablement pas. Notez qu'il faut tout de même convertir une chaîne telle que "br/sao_paulo" en un vecteur one-hot.

city_id: "br/sao_paulo"

Toutefois, récupérer une valeur déduite par un autre modèle présente des inconvénients supplémentaires. La valeur "219" représente peut-être actuellement São Paulo, mais cette représentation pourrait facilement changer lors d'une exécution future de l'autre modèle :

inferred_city_cluster: "219"

Envoyer des commentaires concernant…

Cours d'initiation au machine learning