Evalml: Vérifications des données : message fmt compatible JSON, incluez une énumération de type et les noms des colonnes affectées

Légère expansion : pour permettre d'autres formatages et internationalisations programmatiques, ce serait bien si EvalML renvoyait les informations non formatées en plus du message qu'il renvoie actuellement. Quelque chose comme:

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

Cela permettrait d'effectuer un formatage indépendant de la langue sur les résultats, en liant les code aux chaînes d'internationalisation. Et avoir des métadonnées disponibles dans le détail permet à ces informations d'être éventuellement formatées dans les messages qui sont présentés de manière structurée.

De plus, séparer la vérification du code réel qui est renvoyé nous permettrait de concevoir des vérifications qui peuvent avoir des ensembles de recommandations/erreurs/avertissements différents produits à partir d'une seule instance de vérification.

@BoopBoopBeepBoop merci. J'aime cette proposition.

Vous attendriez-vous à ce que "code" soit une énumération ou simplement une chaîne définie quelque part dans la vérification des données ?

Un ajustement que je peux suggérer est de garder la structure plate :

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

Ici, nous parlons en termes de JSON, mais en mettant cela de côté, je pense que chacun de ces champs devrait être attaché à l'objet DataCheckWarning / DataCheckError .

C'est juste - j'y avais ajouté ces éléments car dans ma tête detail était "essentiellement une carte". Cependant, ce ne sont pas de bons exemples, car ils sont probablement présents pour tous les contrôles...

Y aurait-il des situations où nos messages devraient inclure des métadonnées supplémentaires qui sont essentiellement présentes sur une base « par message » ? Les exemples que j'ai vus à ce sujet auparavant seraient l'appel de valeurs spécifiques à titre d'exemples, le formatage des limites inférieures/supérieures dynamiques dans les messages, ou similaire. C'est généralement là que vous bénéficiez d'une carte detail (ou choisissez un autre nom)

Vous attendriez-vous à ce que "code" soit une énumération ou simplement une chaîne définie quelque part dans la vérification des données ?

Je m'attendrais juste à ce qu'il soit stable - où il vit est 🤷

Vous attendriez-vous à ce que "code" soit une énumération ou simplement une chaîne définie quelque part dans la vérification des données ?

Je m'attendrais juste à ce qu'il soit stable - où il vit est 🤷

Si c'est tout de même, je pense que je préférerais une énumération. Nous définissons actuellement nos propres chaînes pour déterminer les vérifications à exécuter dans le cadre du travail, et ce serait bien d'avoir une énumération cohérente avec EvalML pour en tirer parti au lieu de créer la nôtre.

Parallèlement à cela et peut-être vers ce que @BoopBoopBeepBoop mentionnait avec les détails, il pourrait être utile de savoir quel type d'erreur a été généré. Par exemple, dans la vérification de la colonne ID, EvalML vérifie si le nom de la colonne contient "id" ou si les valeurs sont N% uniques. Nous pouvons vouloir filtrer les premiers ou les représenter différemment, donc ce niveau de granularité peut être utile, soit via des énumérations plus granulaires, soit dans quelque chose de similaire à une structure détaillée décrite ci-dessus.

Je viens de discuter avec @dsherry @freddyaboulton : j'avais mis en place https://github.com/alteryx/evalml/pull/1444 pour mettre à jour notre API de vérification des données afin de renvoyer un dictionnaire au lieu d'une liste d'avertissements et d'erreurs. Avec ce problème à l'esprit, je vais mettre à jour mon PR pour renvoyer un DataCheckResults où errors et warnings sont des attributs, ainsi que pour ajouter une méthode to_json pour la classe qui renverra les messages au format JSON comme @BoopBoopBeepBoop l' a suggéré ici, avec un minimum d'informations - pour l'instant, uniquement le message et le niveau.

Ce problème restera ouvert pour suivre l'ajout de champs supplémentaires (tels que le "code") à la sortie JSON.

Merci @angela97lin !

Voici donc la dernière proposition :

• Mettez DataCheck.validate jour DataChecks.validate pour qu'ils renvoient tous deux le format suivant :

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

où chaque entrée dans ce qui précède est du format

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

• Définissez une énumération DataCheckMessageCode pour remplir le champ code ci-dessus.
• Supprimez les classes DataCheckMessage , DataCheckError et DataCheckWarning au profit du format dict ci-dessus

Des objections / commentaires avant de construire cela? @tyler3991 @Cmancuso @BoopBoopBeepBoop @angela97lin @freddyaboulton

( @angela97lin @freddyaboulton J'ai commencé à taper une version de cette proposition avec une classe DataCheckResults , puis j'ai décidé que nous devions simplement renvoyer le dict JSON d'en haut, plutôt que de définir une autre classe. Fonctionnellement équivalent, mais pas l'utilisation de la classe est plus simple. Tout ce que la classe de résultats ferait est de conserver les mêmes informations, sans y ajouter d'autres fonctionnalités. LMK si vous pensez que c'est une mauvaise idée.)

J'ai parlé à DataCheckMessage interne pour plus de commodité / pour qu'il soit plus difficile pour les gens de définir des entrées de message invalides. Mais validate renverra un dict de dicts compatible JSON comme défini ci-dessus.

( @angela97lin si cela ne correspond pas à ce dont nous venons de discuter, corrigez-moi s'il vous plaît !)

Ajuster cela avec @angela97lin . Dernier:

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

où la touche "détails" peut contenir toutes les informations que la vérification des données veut renvoyer. Et il sera omis s'il n'y a rien à inclure.

Nous devons mettre à jour les vérifications de données suivantes pour inclure la ou les colonnes qui ont échoué à la vérification : hautement nulle, ID et fuite cible. Bonus si nous mettons également à jour les autres contrôles de données :)

C'est en gros ce que @BoopBoopBeepBoop a proposé ! ✨ @Cmancuso Pour votre information