Abbiamo esplorato i modi per mappare i dati non elaborati in vettori di caratteristiche adatti, ma questo è solo una parte del lavoro. Dobbiamo ora capire quali tipi di valori creano caratteristiche soddisfacenti all'interno dei vettori di caratteristiche.
Evita valori delle caratteristiche discreti utilizzati raramente
I valori delle caratteristiche efficaci dovrebbero apparire più di cinque volte in un set di dati.
In questo modo, il modello è in grado di capire in che modo il valore di questa caratteristica è correlato all'etichetta.
In altre parole, avere molti esempi con lo stesso valore discreto dà al modello la possibilità di vedere la caratteristica in impostazioni diverse e, a sua volta, di determinare se è un buon fattore predittivo per l'etichetta. Ad esempio, una funzionalità house_type
potrebbe contenere molti esempi in cui il suo valore era
victorian:
✔This is a good example:house_type: victorian
Al contrario, se il valore di una caratteristica appare solo una volta o molto raramente, il modello non può fare previsioni in base a quella caratteristica. Ad esempio, unique_house_id
non è una caratteristica valida perché ogni valore verrebbe utilizzato una sola volta, quindi il modello non
ha potuto imparare nulla da questo:
The following is an example of a unique value. This should be avoided.✘unique_house_id: 8SK982ZZ1242Z
Preferisci significati chiari e evidenti
Ogni funzionalità deve avere un significato chiaro e ovvio per chiunque nel progetto. Ad esempio, la seguente caratteristica valida ha un nome chiaro e il valore ha senso rispetto al nome:
✔The meaning of the following value is clear from the label and value.house_age_years: 27
Al contrario, il significato del seguente valore delle funzionalità è praticamente incomprensibile a chiunque tranne che all'ingegnere che l'ha creato:
✘The following is an example of a value that is unclear. This should be avoidedhouse_age: 851472000
In alcuni casi, dati disomogenei (piuttosto che cattive scelte tecniche) causano valori poco chiari. Ad esempio, user_age_years proviene da un'origine che non ha verificato i valori appropriati:
✘The following is an example of noisy/bad data. This should be avoided.user_age_years: 277
Non mescolare valori "magici" con dati effettivi
Le buone caratteristiche in virgola mobile non contengono peculiari discontinuità o valori "magici" fuori intervallo. Ad esempio, supponiamo che una caratteristica contenga un valore con virgola mobile compreso tra 0 e 1. Quindi, valori come quelli seguenti sono validi:
✔The following is a good example:quality_rating: 0.82 quality_rating: 0.37
Tuttavia, se un utente non ha inserito un quality_rating, forse il set di dati rappresentava la sua assenza con un valore magico come il seguente:
✘The following is an example of a magic value. This should be avoided.quality_rating: -1
Per contrassegnare esplicitamente i valori magici, crea una funzionalità booleana che indichi se è stato fornito o meno un quality_rating. Assegna un nome a questa funzionalità booleana
come is_quality_rating_defined.
Nella funzionalità originale, sostituisci i valori magici come segue:
- Per le variabili che accettano un insieme finito di valori (variabili discrete), aggiungi un nuovo valore all'insieme e utilizzalo per indicare che il valore della caratteristica manca.
- Per le variabili continue, utilizza il valore medio dei dati della caratteristica per assicurarti che i valori mancanti non influiscano sul modello.
Tieni conto dell'instabilità upstream
La definizione di una funzionalità non dovrebbe cambiare nel tempo. Ad esempio, il valore seguente è utile perché il nome della città probabilmente non cambierà. Tieni presente che dobbiamo comunque convertire una stringa come "br/sao_paulo" in un vettore one-hot.
✔This is a good example:city_id: "br/sao_paulo"
Tuttavia, la raccolta di un valore dedotto da un altro modello comporta costi aggiuntivi. Forse il valore "219" rappresenta attualmente San Paolo, ma questa rappresentazione potrebbe cambiare facilmente in una futura esecuzione dell'altro modello:
✘The following is an example of a value that could change. This should be avoided.inferred_city_cluster: "219"