Exploramos maneiras de mapear dados brutos em vetores de atributo adequados, mas isso é apenas parte do trabalho. Agora precisamos explorar que tipos de valores são realmente bons atributos nesses vetores de atributo.
Evitar valores de atributos discretos usados raramente
Bons valores de atributos devem aparecer mais de cinco vezes ou mais em um conjunto de dados.
Isso permite que o modelo aprenda como esse valor do atributo se relaciona com o rótulo.
Ou seja, ter muitos exemplos com o mesmo valor discreto dá ao modelo a chance de ver o atributo em diferentes configurações e, por sua vez, determinar quando é um bom preditor para o rótulo. Por exemplo, um recurso house_type
provavelmente conteria muitos exemplos em que o valor dele é
victorian:
✔This is a good example:house_type: victorian
Por outro lado, se o valor de um atributo aparece apenas uma vez ou muito raramente, o modelo
não pode fazer previsões com base nesse recurso. Por exemplo, unique_house_id
é um atributo inválido porque cada valor seria usado apenas uma vez, e o modelo
não conseguiu aprender nada com ele:
The following is an example of a unique value. This should be avoided.✘unique_house_id: 8SK982ZZ1242Z
Preferir significados claros e óbvios
Cada recurso deve ter um significado claro e óbvio para qualquer pessoa no projeto. Por exemplo, o bom atributo abaixo é claramente nomeado e o valor faz sentido em relação ao nome:
✔The meaning of the following value is clear from the label and value.house_age_years: 27
Por outro lado, o significado do valor do atributo a seguir é praticamente indecifrável para ninguém além do engenheiro que o criou:
✘The following is an example of a value that is unclear. This should be avoidedhouse_age: 851472000
Em alguns casos, dados com ruído (em vez de escolhas ruins de engenharia) causam valores pouco claros. Por exemplo, os seguintes user_age_years vieram de uma origem que não verificou os valores apropriados:
✘The following is an example of noisy/bad data. This should be avoided.user_age_years: 277
Não misture valores "mágicos" com dados reais
Bons atributos de ponto flutuante não contêm descontinuidades peculiares ou valores "mágicos" fora do intervalo. Por exemplo, suponha que um recurso tenha um valor de ponto flutuante entre 0 e 1. Portanto, valores como os seguintes são bons:
✔The following is a good example:quality_rating: 0.82 quality_rating: 0.37
No entanto, se um usuário não inseriu um quality_rating, talvez o conjunto de dados tenha representado a ausência com um valor mágico, como este:
✘The following is an example of a magic value. This should be avoided.quality_rating: -1
Para marcar explicitamente valores mágicos, crie um recurso booleano que indique se
um quality_rating foi fornecido ou não. Dê um nome a esse recurso booleano, como is_quality_rating_defined.
No recurso original, substitua os valores mágicos da seguinte forma:
- Para variáveis que recebem um conjunto finito de valores (variáveis discretas), adicione um novo valor ao conjunto e use-o para indicar que o valor do atributo está ausente.
- Para variáveis contínuas, use o valor médio dos dados do atributo para garantir que os valores ausentes não afetem o modelo.
Considerar a instabilidade do upstream
A definição de um elemento não deve mudar com o tempo. Por exemplo, o valor a seguir é útil porque o nome da cidade provavelmente não mudará. Observe que ainda precisamos converter uma string como "br/sao_paulo" em um vetor one-hot.
✔This is a good example:city_id: "br/sao_paulo"
No entanto, coletar um valor inferido por outro modelo gera custos adicionais. Talvez o valor "219" represente São Paulo atualmente, mas essa representação poderia facilmente mudar em uma execução futura do outro modelo:
✘The following is an example of a value that could change. This should be avoided.inferred_city_cluster: "219"