Evalml: Verificações de dados: mensagem amigável JSON fmt, inclui um tipo enum e nomes de coluna afetados

Ligeira expansão: para permitir outra formatação e internacionalização programática, seria bom se o EvalML retornasse as informações não formatadas, além da mensagem que retorna agora. Algo como:

{
  "message": "Warning: too many null values present in column 'foobar'",
  "check": "NullCheck",
  "code": "TOO_MANY_NULLS",
  "detail": {
    "level": "warning",
    "columns": ["foobar"]
  }
}

Isso tornaria possível realizar uma formatação independente do idioma nos resultados, vinculando code volta às strings de internacionalização. E ter metadados disponíveis nos detalhes permite que as informações sejam opcionalmente formatadas de volta nas mensagens que são apresentadas de forma estruturada.

Além disso, separar a verificação do código real que é retornado nos permite projetar verificações que podem ter conjuntos de recomendações / erros / avisos diferentes sendo produzidos a partir de uma única instância de verificação.

@BoopBoopBeepBoop obrigado. Eu gosto dessa proposta.

Você esperaria que "código" fosse um enum ou apenas uma string definida em algum lugar dentro da verificação de dados?

Um ajuste que posso sugerir é manter a estrutura plana:

{
  "message": "Warning: too many null values present in column 'foobar'",
  "code": "TOO_MANY_NULLS",
  "level": "warning",
  "columns": ["foobar"]
}

Aqui estamos falando em termos de JSON, mas deixando isso de lado, acho que cada um desses campos deve ser anexado ao objeto DataCheckWarning / DataCheckError .

Isso é justo - eu adicionei esses elementos lá porque na minha cabeça detail era "essencialmente um mapa". No entanto, esses não são bons exemplos, porque provavelmente estão presentes para todas as verificações ...

Haveria alguma situação em que nossas mensagens devessem incluir metadados adicionais que estão essencialmente presentes em uma base "por mensagem"? Os exemplos que vi sobre isso antes seriam chamar valores específicos como exemplos, formatar limites inferior / superior dinâmicos em mensagens ou algo semelhante. Normalmente é aí que você se beneficia de ter um mapa detail (ou escolher um nome diferente)

Você esperaria que "código" fosse um enum ou apenas uma string definida em algum lugar dentro da verificação de dados?

Eu esperava que fosse estável - onde ele mora é 🤷

Você esperaria que "código" fosse um enum ou apenas uma string definida em algum lugar dentro da verificação de dados?

Eu esperava que fosse estável - onde ele mora é 🤷

Se for tudo igual, acho que prefiro um enum. No momento, estamos definindo nossas próprias cadeias de caracteres para determinar quais verificações executar como parte do trabalho, e seria bom ter um enum consistente com o EvalML para aproveitá-lo em vez de criar o nosso próprio.

Além disso, e talvez em relação ao que @BoopBoopBeepBoop estava mencionando com os detalhes, pode ser útil saber qual tipo de erro foi lançado. Por exemplo, na verificação da coluna de ID, o EvalML verifica se o nome da coluna contém "id" ou se os valores são N% exclusivos. Podemos querer filtrar os primeiros ou representá-los de forma diferente, portanto, esse nível de granularidade pode ser útil, por meio de enums mais granulares ou em algo semelhante a uma estrutura detalhada descrita acima.

Acabei de discutir com @dsherry @freddyaboulton : Eu coloquei https://github.com/alteryx/evalml/pull/1444 para atualizar nossa API de verificação de dados para retornar um dicionário em vez de uma lista de avisos e erros. Com esse problema em mente, atualizarei meu PR para retornar um DataCheckResults que errors e warnings são atributos, bem como adicionarei um método to_json para a classe que retornará as mensagens formatadas em JSON como @BoopBoopBeepBoop sugeriu aqui, com informações mínimas - por enquanto, apenas a mensagem e o nível.

Esse problema permanecerá aberto para rastrear a adição de mais campos (como o "código") à saída JSON.

Obrigado @ angela97lin !

Então aqui está a última proposta:

• Atualize DataCheck.validate e DataChecks.validate para retornar o seguinte formato:

{'errors': [...], 'warnings': [...]}

onde cada entrada acima é do formato

{
  "message": "Warning: too many null values present in column 'foobar'",
  "code": "TOO_MANY_NULLS",
  "level": "warning",
  "columns": ["foobar"]
}

• Defina um DataCheckMessageCode enum para preencher o campo code acima.
• Exclua as classes DataCheckMessage , DataCheckError e DataCheckWarning em favor do formato dict acima

Alguma objeção / comentário antes de construirmos isso? @ tyler3991 @Cmancuso @BoopBoopBeepBoop @ angela97lin @freddyaboulton

( @ angela97lin @freddyaboulton Comecei a digitar uma versão desta proposta com uma classe DataCheckResults e então decidi que deveríamos simplesmente retornar o ditado JSON criado de cima, em vez de definir outra classe. Funcionalmente equivalente, mas não usar a classe é mais simples. Tudo o que a classe de resultados faria é manter a mesma informação, sem adicionar outra funcionalidade a ela. LMK se você acha que é uma má ideia.)

Falei com DataCheckMessage internamente por conveniência / para tornar mais difícil para as pessoas definir entradas de mensagens inválidas. Mas validate retornará um dicionário de dictos compatível com JSON conforme definido acima.

( @ angela97lin se isso não corresponder ao que acabamos de discutir, corrija-me!)

Ajustando isso com @ angela97lin . Mais recentes:

{
  "message": "Warning: too many null values present in column 'foobar'",
  "code": "TOO_MANY_NULLS",
  "data_check_name": "HighlyNullDataCheck",
  "level": "warning",
  "details": {
    "columns": ["foobar"]
  }
}

onde a tecla "detalhes" pode conter qualquer informação que a verificação de dados deseja retornar. E será omitido se não houver nada a ser incluído.

Precisamos atualizar as seguintes verificações de dados para incluir as colunas que falharam na verificação: altamente nulo, ID e vazamento de destino. Bônus se também atualizarmos as outras verificações de dados :)

Isso é basicamente o que @BoopBoopBeepBoop propôs! ✨ @Cmancuso FYI