Exploramos formas de asignar datos sin procesar a vectores de atributos adecuados, pero eso es solo una parte del trabajo. Ahora, debemos explorar qué tipos de valores generan buenos atributos dentro de esos vectores de atributos.
Evita los valores de atributos discretos con poco uso
Los buenos valores de atributos deben aparecer aproximadamente 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 da al modelo la oportunidad 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 era victorian:
✔This is a good example:house_type: victorian
Por el contrario, si el valor de un atributo aparece solo una vez o muy pocas veces, el modelo no puede hacer predicciones basadas en ese atributo. Por ejemplo, unique_house_id es un atributo malo porque cada valor se usará solo una vez, por lo que el modelo no podría aprender nada de él:
The following is an example of a unique value. This should be avoided.✘unique_house_id: 8SK982ZZ1242Z
Prioriza los significados claros y obvios
Cada atributo debe tener un significado claro y obvio para todos en el 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 del atributo es bastante 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 ruidosos (en lugar de malas decisiones de ingeniería) generan valores poco claros. Por ejemplo, el valor user_age_years siguiente provino de una fuente en la que no se verificaron los valores adecuados:
✘The following is an example of noisy/bad data. This should be avoided.user_age_years: 277
No mezcles valores "mágicos" con datos reales
Los buenos atributos 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. Por lo tanto, 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ó un quality_rating, tal vez 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 de forma explícita los valores mágicos, crea un atributo booleano que indique si
se proporcionó o no un quality_rating. Asigna un nombre como is_quality_rating_defined a este atributo booleano.
En el atributo 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, usa el valor medio de los datos del atributo para asegurarte de que los valores faltantes no afecten el modelo.
Ten en cuenta la inestabilidad de las etapas anteriores
La definición de un atributo 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 debemos convertir una cadena como "br/sao_paulo" en un vector one-hot).
✔This is a good example:city_id: "br/sao_paulo"
Sin embargo, obtener un valor inferido por otro modelo tiene costos adicionales. Quizás el valor “219” represente actualmente 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"