Evalml: Suporte para parametrização de verificações de dados; ter InvalidTargetDataCheck validar o destino usando problem_type

@angela97lin você poderia descrever o caso de uso para isso?

@dsherry Claro! Em #929, @freddyaboulton e eu estávamos discutindo como seria bom se o InvalidTargetDataCheck pudesse ser ainda mais útil se estivesse ciente do tipo de problema que estava lidando. Por exemplo, se soubéssemos que nosso problema era classificação binária, mas a entrada para a verificação de dados tivesse mais de duas classes, poderíamos lançar um aviso/erro. Portanto, seria bom poder passar parâmetros de alguma forma ou apenas mais informações para a verificação de dados. Infelizmente, isso não funciona bem com nosso design atual, onde passamos classes e não instâncias.

Como alternativa, poderíamos criar classes de verificação de dados para cada tipo de problema, como BinaryClassificationInvalidTargetDataCheck, mas isso também pode ficar muito complicado, ao determinar o que DefaultDataChecks deve incluir (ou isso também deve ser dividido em DefaultBinaryClassificationDataChecks?)

Acabei de discutir com @angela97lin @freddyaboulton

Gostamos da ideia de espelhar o padrão que usamos para component_graph em pipelines:

• A lista de verificações de dados pode ser especificada inicialmente para pesquisa automática como uma lista de subclasses DataCheck (ou igual, mas dentro DataChecks ), não instâncias
• Uma vez que a pesquisa automl deseja executar as verificações de dados, ela pode criar uma instância da classe DataChecks
• Nesse ponto, passaríamos um dict data_check_parameters , semelhante ao nosso pipeline parameters , que contém configuração opcional para uma ou mais verificações de dados.
• Se os usuários quiserem usar DataChecks diretamente, eles podem seguir um padrão semelhante
• data_check_parameters deve ser o padrão None para que as pessoas não precisem criar isso se não for necessário. Mas se um argumento necessário estiver faltando em uma verificação de dados (como problem_type para alguns), isso deve resultar em um erro de inicialização

Aqui está um esboço de como isso pode parecer na pesquisa automl:

# today this helper standardizes the input to a list of `DataCheck` instances, and wraps that in a `DataChecks` instance
# after this work, this would standardize the input to a `DataChecks` class.
# if `data_checks` was already a `DataChecks` class, do nothing. else if `data_checks` is a list of `DataCheck` classes, define a `AutoMLDataChecks` class to wrap and return that
data_checks_class = self._validate_data_checks(data_checks)
# next we create the `DataChecks` instance by passing in data checks parameters
data_check_parameters = {'Target Datatype Data Check': {'problem_type': self.problem_type}}
data_checks = data_checks_class(data_check_parameters)
data_check_results = data_checks.validate(X, y)

O uso direto seria semelhante.

Próximos passos

• @angela97lin @freddyaboulton outros revisam o esboço acima e verificam a sanidade
• @angela97lin registrará um problema para rastrear a adição de uma verificação de dados TargetDatatype (nome a ser definido), com base em nossa discussão em #960 . Essa verificação de dados exigiria que um parâmetro problem_type fosse passado em
• Quem pegar este problema também deve pegar aquele TargetDatatype ao mesmo tempo e construir isso! 🛠️ 😁

@dsherry O plano parece bom para mim! A única coisa que eu acrescentaria é que prefiro aumentar o InvalidTargetDataCheck já existente ao invés de criar uma nova verificação de dados, mas qualquer uma das abordagens funcionaria para mim. Quem pegar isso, certifique-se de verificar se o alvo tem apenas dois valores únicos quando o problem_type é binário. Isso foi mencionado na revisão para # 929.

if problem_type == "binary" and len(set(y)) != 2:
    # Warn that we do not have two unique values in y

Você sabe, @angela97lin @freddyaboulton vamos usar esse problema para rastrear a) atualizar o automl e a API de verificação de dados para dar suporte à parametrização e b) atualizar InvalidTargetDataCheck para validar o destino e gerar erros inteligentes, para todo o destino tipos que suportamos.

Mencionando porque acabei de registrar um bug #970 e, olhando mais de perto, o problema seria corrigido pelo acima. Então isso fechará #970.

@dsherry Que oportuno! Isso me soa bem 😊