Evalml: Datenüberprüfungen: JSON-freundliche Nachrichtenfmt, enthalten eine Typ-Enumeration und betroffene Spaltennamen

Leichte Erweiterung: Um andere programmatische Formatierungen und Internationalisierungen zu ermöglichen, wäre es schön, wenn EvalML zusätzlich zu der Nachricht, die es gerade zurückgibt, die unformatierten Informationen zurückgibt. Etwas wie:

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

Dies würde es möglich machen, eine sprachunabhängige Formatierung der Ergebnisse durchzuführen, indem code wieder an Internationalisierungsstrings gebunden wird. Und wenn Metadaten im Detail verfügbar sind, können diese Informationen optional wieder in die Nachrichten formatiert werden, die auf strukturierte Weise präsentiert werden.

Darüber hinaus würde die Trennung der Prüfung vom tatsächlich zurückgegebenen Code es uns ermöglichen, Prüfungen zu entwerfen, die Sätze unterschiedlicher Empfehlungen/Fehler/Warnungen enthalten können, die von einer einzelnen Prüfinstanz erzeugt werden.

@BoopBoopBeepBoop danke. Ich mag diesen Vorschlag.

Würden Sie erwarten, dass "Code" eine Aufzählung oder nur eine Zeichenfolge ist, die irgendwo in der Datenprüfung definiert ist?

Eine Optimierung, die ich vorschlagen kann, besteht darin, die Struktur flach zu halten:

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

Hier sprechen wir von JSON, aber abgesehen davon denke ich, dass jedes dieser Felder an das DataCheckWarning / DataCheckError Objekt angehängt werden sollte.

Das ist fair - ich hatte diese Elemente dort hinzugefügt, da in meinem Kopf detail "im Wesentlichen eine Karte" war. Dies sind jedoch keine großartigen Beispiele, da sie wahrscheinlich bei allen Überprüfungen vorhanden sind ...

Könnte es Situationen geben, in denen unsere Nachrichten zusätzliche Metadaten enthalten sollten, die im Wesentlichen auf "pro-Nachricht"-Basis vorhanden sind? Beispiele, die ich zuvor gesehen habe, wären das Aufrufen bestimmter Werte als Beispiele, das Formatieren dynamischer Unter-/Obergrenzen in Nachrichten oder ähnliches. Das ist normalerweise der Punkt, an dem Sie von einer detail -Karte (oder einem anderen Namen) profitieren

Würden Sie erwarten, dass "Code" eine Aufzählung oder nur eine Zeichenfolge ist, die irgendwo in der Datenprüfung definiert ist?

Ich würde nur erwarten, dass es stabil ist - wo es lebt ist

Würden Sie erwarten, dass "Code" eine Aufzählung oder nur eine Zeichenfolge ist, die irgendwo in der Datenprüfung definiert ist?

Ich würde nur erwarten, dass es stabil ist - wo es lebt ist

Wenn alles gleich ist, würde ich eine Aufzählung vorziehen. Wir definieren derzeit unsere eigenen Strings, um zu bestimmen, welche Prüfungen als Teil des Jobs ausgeführt werden sollen, und es wäre schön, eine EvalML-konsistente Enumeration zu haben, um sie dort zu nutzen, anstatt unsere eigenen zu erstellen.

Daneben und vielleicht in Bezug auf das, was

Gerade mit @dsherry @freddyaboulton besprochen : Ich hatte https://github.com/alteryx/evalml/pull/1444 eingerichtet , um unsere Datenüberprüfungs-API zu aktualisieren, um ein Wörterbuch anstelle einer Liste von Warnungen und Fehlern zurückzugeben. In Anbetracht dieses Problems aktualisiere ich meine PR, um ein DataCheckResults wobei errors und warnings Attribute sind, und füge eine to_json Methode hinzu für die Klasse, die die JSON-formatierten Nachrichten zurückgibt, wie vorerst nur die Nachricht und die Ebene.

Dieses Problem bleibt bestehen, um das Hinzufügen weiterer Felder (z. B. "Code") zur JSON-Ausgabe zu verfolgen.

Danke @angela97lin !

Hier also der neueste Vorschlag:

• Aktualisieren Sie DataCheck.validate und DataChecks.validate um beide das folgende Format zurückzugeben:

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

wobei jeder Eintrag im obigen Format das Format hat

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

• Definieren Sie eine DataCheckMessageCode Enumeration, um das Feld code oben auszufüllen.
• Löschen Sie die Klassen DataCheckMessage , DataCheckError und DataCheckWarning zugunsten des obigen Diktatformats

Irgendwelche Einwände / Kommentare, bevor wir dies bauen? @tyler3991 @Cmancuso @BoopBoopBeepBoop @angela97lin @freddyaboulton

( @angela97lin @freddyaboulton Ich habe angefangen, eine Version dieses Vorschlags mit einer DataCheckResults Klasse zu schreiben, und dann beschlossen, dass wir einfach das JSON-ifizierte Diktat von oben zurückgeben sollten, anstatt eine andere Klasse zu definieren. Funktionell äquivalent, aber nicht Die Verwendung der Klasse ist einfacher. Die Ergebnisklasse würde nur die gleichen Informationen speichern und ihr keine anderen Funktionen hinzufügen. LMK, wenn Sie das für eine schlechte Idee halten.)

Habe mit @angela97lin über diese RE PR #1444 gesprochen. Der obige Plan bleibt unverändert, außer dass sie sich entscheiden kann, die DataCheckMessage Klassen aus Gründen der Bequemlichkeit intern beizubehalten / um es den Leuten zu erschweren, ungültige Nachrichteneinträge zu definieren. Aber validate gibt ein JSON-fähiges Diktat von Diktaten wie oben definiert zurück.

( @angela97lin Wenn das nicht mit dem übereinstimmt, was wir gerade besprochen haben, korrigiert mich bitte!)

Optimieren Sie dies mit @angela97lin . Neueste:

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

wobei die Taste "Details" alle Informationen enthalten kann, die die Datenprüfung zurückgeben möchte. Und es wird weggelassen, wenn nichts eingefügt werden soll.

Wir müssen die folgenden Datenprüfungen aktualisieren, um die Spalte(n) einzuschließen, die die Prüfung nicht bestanden haben: hoch null, ID und Zielleckage. Bonus, wenn wir auch die anderen Datenprüfungen aktualisieren :)

Dies ist im Grunde das, was @BoopBoopBeepBoop vorgeschlagen hat! @Cmancuso Zur Info