Analizamos formas de asignar datos sin procesar a vectores de atributos adecuados, pero esa es solo una parte del trabajo. Ahora debemos explorar qué tipos de valores realmente son buenos atributos dentro de esos vectores de atributos.
Evita los valores de atributos discretos que se usan con poca frecuencia
Los valores de atributos correctos deberían aparecer más de 5 veces en un conjunto de datos.
Esto permite que un modelo aprenda cómo se relaciona este valor de atributo con la etiqueta.
Es decir, tener muchos ejemplos con el mismo valor discreto le brinda al modelo la posibilidad de ver el atributo en diferentes configuraciones y, a su vez, determinar cuándo es un buen predictor para la etiqueta. Por ejemplo, es probable que un atributo house_type contenga muchos ejemplos en los que su valor sea victorian:
✔This is a good example:house_type: victorian
Por el contrario, si el valor de un atributo aparece solo una o muy pocas veces, el modelo no puede hacer predicciones basadas en ese atributo. Por ejemplo, unique_house_id es una mala característica porque cada valor se usaría solo una vez, por lo que el modelo no pudo aprender nada:
The following is an example of a unique value. This should be avoided.✘unique_house_id: 8SK982ZZ1242Z
Prefiere significados claros y evidentes
Cada característica debe tener un significado claro y evidente para cualquier persona del proyecto. Por ejemplo, el siguiente buen atributo tiene un nombre claro y el valor tiene sentido con respecto al nombre:
✔The meaning of the following value is clear from the label and value.house_age_years: 27
Por el contrario, el significado del siguiente valor de atributo es casi indescifrable para cualquiera que no sea el ingeniero que lo creó:
✘The following is an example of a value that is unclear. This should be avoidedhouse_age: 851472000
En algunos casos, los datos contaminados (en lugar de decisiones de ingeniería incorrectas) generan valores poco claros. Por ejemplo, el valor user_age_years se obtuvo a partir de una fuente que no verificó los valores adecuados:
✘The following is an example of noisy/bad data. This should be avoided.user_age_years: 277
No mezcle valores "mágicos" con datos reales
Las buenas características de punto flotante no contienen discontinuidades fuera de rango peculiares ni valores mágicos. Por ejemplo, supongamos que un atributo tiene un valor de punto flotante entre 0 y 1. Los valores como los siguientes son correctos:
✔The following is a good example:quality_rating: 0.82 quality_rating: 0.37
Sin embargo, si un usuario no ingresó quality_rating, es posible que el conjunto de datos represente su ausencia con un valor mágico como el siguiente:
✘The following is an example of a magic value. This should be avoided.quality_rating: -1
Para marcar valores mágicos de forma explícita, crea un atributo booleano que indique si se proporcionó un quality_rating o no. Asigna un nombre como is_quality_rating_defined a este atributo booleano.
En la función original, reemplaza los valores mágicos de la siguiente manera:
- En el caso de las variables que toman un conjunto finito de valores (variables discretas), agrega un valor nuevo al conjunto y úsalo para indicar que falta el valor del atributo.
- Para las variables continuas, asegúrate de que los valores faltantes no afecten el modelo mediante el valor medio de los datos de atributos.
Ten en cuenta la inestabilidad ascendente
La definición de un elemento no debe cambiar con el tiempo. Por ejemplo, el siguiente valor es útil porque el nombre de la ciudad probablemente no cambie. (Ten en cuenta que aún necesitamos convertir una string como &solt_br/sao_paulo en un vector de un solo 1).
✔This is a good example:city_id: "br/sao_paulo"
Sin embargo, recopilar un valor inferido por otro modelo tiene costos adicionales. Quizás el valor "219" actualmente represente a São Paulo, pero esa representación podría cambiar fácilmente en una ejecución futura del otro modelo:
✘The following is an example of a value that could change. This should be avoided.inferred_city_cluster: "219"