Nous avons exploré les moyens de mapper des données brutes dans des vecteurs de caractéristiques appropriés, mais ce n'est qu'une partie du travail. Nous devons maintenant explorer les types de valeurs qui constituent de bonnes caractéristiques dans ces vecteurs de caractéristiques.
Éviter les valeurs de caractéristiques discrètes rarement utilisées
Les bonnes valeurs de caractéristiques doivent apparaître plus d'au moins 5 fois dans un ensemble de données.
Cela permet au modèle de découvrir comment cette valeur de caractéristique est liée à l'étiquette.
Autrement dit, le fait d'avoir de nombreux exemples avec la même valeur discrète permet au modèle de voir la caractéristique dans différents contextes, puis de déterminer à son tour si elle constitue un bon prédicteur pour l'étiquette. Par exemple, une caractéristique house_type contient probablement de nombreux exemples dont la valeur est victorian:
✔This is a good example:house_type: victorian
À l'inverse, si la valeur d'une caractéristique n'apparaît qu'une seule fois ou très rarement, le modèle ne peut pas effectuer de prédictions sur la base 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 rien en tirer:
The following is an example of a unique value. This should be avoided.✘unique_house_id: 8SK982ZZ1242Z
Privilégier les significations claires
Chaque caractéristique doit avoir une signification claire pour toute personne impliquée dans le projet. Par exemple, la bonne caractéristique suivante est clairement nommée et la valeur a du sens en ce qui concerne le nom:
✔The meaning of the following value is clear from the label and value.house_age_years: 27
À l'inverse, la signification de la valeur de caractéristique suivante est pratiquement indéchiffrable pour quiconque, à l'exception de l'ingénieur qui l'a créée:
✘The following is an example of a value that is unclear. This should be avoidedhouse_age: 851472000
Dans certains cas, le bruit (plutôt que les mauvais choix techniques) entraîne des valeurs peu claires. Par exemple, les valeurs user_age_years suivantes proviennent d'une source qui n'a pas vérifié les valeurs appropriées:
✘The following is an example of noisy/bad data. This should be avoided.user_age_years: 277
Ne pas mélanger des valeurs "magiques" avec des données réelles
Les bonnes caractéristiques à virgule flottante ne contiennent pas de discontinuités particulières ni de valeurs "magiques". Par exemple, supposons qu'une caractéristique contienne une valeur à virgule flottante comprise entre 0 et 1. Des valeurs comme celles-ci sont acceptables:
✔The following is a good example:quality_rating: 0.82 quality_rating: 0.37
Toutefois, si un utilisateur n'a pas saisi de quality_rating, il est possible que l'ensemble de données ait représenté son absence par une valeur magique semblable à celle-ci:
✘The following is an example of a magic value. This should be avoided.quality_rating: -1
Pour marquer explicitement les valeurs magiques, créez une caractéristique booléenne indiquant si un élément quality_rating a été fourni ou non. Donnez à cette caractéristique booléenne un nom tel que is_quality_rating_defined.
Dans la caractéristique d'origine, remplacez les valeurs magiques comme suit:
- Pour les variables qui acceptent un ensemble fini de valeurs (variables discrètes), ajoutez une nouvelle valeur à l'ensemble et utilisez-la pour indiquer que la valeur de la caractéristique est manquante.
- Pour les variables continues, assurez-vous que les valeurs manquantes n'affectent pas le modèle en utilisant la valeur moyenne des données de la caractéristique.
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 que nous devrons toujours convertir une chaîne telle que "br/sao_paulo" en vecteur one-hot.)
✔This is a good example:city_id: "br/sao_paulo"
Toutefois, la collecte d'une valeur déduite par un autre modèle entraîne des coûts 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 ultérieure de l'autre modèle:
✘The following is an example of a value that could change. This should be avoided.inferred_city_cluster: "219"