Evalml: Comprobaciones de datos: fmt de mensaje compatible con JSON, incluye una enumeración de tipo y los nombres de las columnas afectadas

Ligera expansión: para habilitar otro formato e internacionalización programáticos, sería bueno si EvalML devolviera la información sin formato además del mensaje que devuelve ahora mismo. Algo como:

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

Esto haría posible realizar un formateo independiente del idioma en los resultados, vinculando code nuevo a las cadenas de internacionalización. Y tener metadatos disponibles en detalle permite que esa información se vuelva a formatear opcionalmente en los mensajes que se presentan de manera estructurada.

Además, separar la verificación del código real que se devuelve nos permitiría diseñar verificaciones que pueden tener conjuntos de recomendaciones / errores / advertencias diferentes que se producen a partir de una única instancia de verificación.

@BoopBoopBeepBoop gracias. Me gusta esa propuesta.

¿Esperaría que "código" fuera una enumeración o simplemente una cadena definida en algún lugar dentro de la verificación de datos?

Un ajuste que puedo sugerir es mantener la estructura plana:

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

Aquí estamos hablando en términos de JSON, pero dejando eso a un lado, creo que cada uno de estos campos debe adjuntarse al objeto DataCheckWarning / DataCheckError .

Eso es justo: había agregado esos elementos allí, ya que en mi cabeza detail era "esencialmente un mapa". Sin embargo, esos no son buenos ejemplos, porque probablemente estén presentes en todos los controles ...

¿Habría situaciones en las que nuestros mensajes deberían incluir metadatos adicionales que estén esencialmente presentes "por mensaje"? Los ejemplos que he visto en esto antes serían llamar valores específicos como ejemplos, formatear límites dinámicos inferiores / superiores en mensajes, o similar. Por lo general, es allí donde se beneficia de tener un mapa de detail (o elija un nombre diferente)

¿Esperaría que "código" fuera una enumeración o simplemente una cadena definida en algún lugar dentro de la verificación de datos?

Solo esperaría que fuera estable, donde vive es 🤷

¿Esperaría que "código" fuera una enumeración o simplemente una cadena definida en algún lugar dentro de la verificación de datos?

Solo esperaría que fuera estable, donde vive es 🤷

Si todo es lo mismo, creo que preferiría una enumeración. Actualmente estamos definiendo nuestras propias cadenas para determinar qué comprobaciones ejecutar como parte del trabajo, y sería bueno tener una enumeración consistente con EvalML para aprovecharla en lugar de crear la nuestra.

Junto a esto y tal vez hacia lo que @BoopBoopBeepBoop estaba mencionando con el detalle, podría ser útil saber qué tipo de error se produjo. Por ejemplo, en la verificación de la columna de ID, EvalML comprueba si el nombre de la columna tiene "id" o si los valores son N% únicos. Es posible que queramos filtrar los primeros o representarlos de manera diferente, por lo que este nivel de granularidad puede ser útil, ya sea a través de enumeraciones más granulares o en algo similar a una estructura detallada descrita anteriormente.

Acabo de hablar con @dsherry @freddyaboulton : había puesto https://github.com/alteryx/evalml/pull/1444 para actualizar nuestra API de verificación de datos para devolver un diccionario en lugar de una lista de advertencias y errores. Con este problema en mente, actualizaré mi PR para devolver un DataCheckResults donde errors y warnings son atributos, además de agregar un método to_json para la clase que devolverá los mensajes con formato JSON como @BoopBoopBeepBoop ha sugerido aquí, con información mínima, por ahora, solo el mensaje y el nivel.

Este problema permanecerá abierto para realizar un seguimiento de la adición de más campos (como el "código") a la salida JSON.

¡Gracias @ angela97lin !

Así que aquí está la última propuesta:

• Actualice DataCheck.validate y DataChecks.validate para que ambos devuelvan el siguiente formato:

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

donde cada entrada en lo anterior tiene el formato

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

• Defina una enumeración DataCheckMessageCode para completar el campo code anterior.
• Elimine las clases DataCheckMessage , DataCheckError y DataCheckWarning a favor del formato dict anterior

¿Alguna objeción / comentario antes de construir esto? @ tyler3991 @Cmancuso @BoopBoopBeepBoop @ angela97lin @freddyaboulton

( @ angela97lin @freddyaboulton Empecé a escribir una versión de esta propuesta con una clase DataCheckResults , y luego decidí que simplemente deberíamos devolver el diccionario JSON-ified de arriba, en lugar de definir otra clase. Funcionalmente equivalente, pero no usar la clase es más simple. Todo lo que haría la clase de resultados es mantener la misma información, no agregarle otra funcionalidad. LMK si cree que es una mala idea).

Hablé con DataCheckMessage internamente por conveniencia / para que sea más difícil para las personas definir entradas de mensajes no válidas. Pero validate devolverá un dictado compatible con JSON como se definió anteriormente.

( @ angela97lin, si eso no coincide con lo que acabamos de discutir, ¡

Modificando esto con @ angela97lin . Más reciente:

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

donde la tecla "detalles" puede contener cualquier información que la verificación de datos desee devolver. Y se omitirá si no hay nada que incluir.

Necesitamos actualizar las siguientes verificaciones de datos para incluir las columnas que fallaron en la verificación: muy nulo, ID y fuga de destino. Bonificación si también actualizamos las otras comprobaciones de datos :)

¡Esto es básicamente lo que propuso @BoopBoopBeepBoop ! ✨ @Cmancuso FYI