Evalml: データチェック：JSON対応のメッセージfmt、型列挙型と影響を受ける列名を含める

わずかな拡張：他のプログラムによるフォーマットと国際化を可能にするために、EvalMLが現在返すメッセージに加えて、フォーマットされていない情報を返すと便利です。 何かのようなもの：

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

これにより、 codeを国際化文字列に結び付けることにより、結果に対して言語に依存しないフォーマットを実行できるようになります。 また、メタデータを詳細に利用できるようにすることで、その情報をオプションでフォーマットして、構造化された方法で表示されるメッセージに戻すことができます。

さらに、返される実際のコードからチェックを分離することで、単一のチェックインスタンスから生成されるさまざまな推奨事項/エラー/警告のセットを持つことができるチェックを設計できます。

@BoopBoopBeepBoopありがとう。 私はその提案が好きです。

「コード」は列挙型であると思いますか、それともデータチェック内のどこかで定義された文字列であると思いますか？

私が提案するかもしれない1つの微調整は、構造を平らに保つことです：

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

ここではJSONの観点から話していますが、それはさておき、これらの各フィールドはDataCheckWarning / DataCheckErrorオブジェクトにアタッチする必要があると思います。

それは公平です-私の頭の中でdetailが「本質的に地図」だったので、私はそこにそれらの要素を追加しました。 ただし、これらはおそらくすべてのチェックに存在するため、優れた例ではありません...

メッセージに、基本的に「メッセージごと」に存在する追加のメタデータを含める必要がある状況はありますか？ これについて以前に見た例は、例として特定の値を呼び出す、メッセージの動的な下限/上限をフォーマットするなどです。 これは通常、 detail （または別の名前を選択）マップを使用することでメリットが得られる場所です。

「コード」は列挙型であると思いますか、それともデータチェック内のどこかで定義された文字列であると思いますか？

私はそれが安定していることを期待しています-それが住んでいる場所は🤷

「コード」は列挙型であると思いますか、それともデータチェック内のどこかで定義された文字列であると思いますか？

私はそれが安定していることを期待しています-それが住んでいる場所は🤷

それがすべて同じなら、私は列挙型を好むと思います。 現在、ジョブの一部として実行するチェックを決定するために独自の文字列を定義しています。独自の文字列を作成する代わりに、EvalMLと整合性のある列挙型を使用してそこで活用できると便利です。

これに加えて、おそらく@BoopBoopBeepBoopが詳細で言及していたことに向けて、どのタイプのエラーがスローされたかを知ることが役立つ場合があります。 たとえば、ID列のチェックでは、EvalMLは、列名に「id」が含まれているかどうか、または値がN％一意であるかどうかをチェックします。 前者を除外するか、別の方法で表現したい場合があるため、このレベルの粒度は、より詳細な列挙型を使用するか、上記の詳細構造に類似したもので役立つ場合があります。

@dsherry @freddyaboultonと話し合ったばかりです。https ： //github.com/alteryx/evalml/pull/1444を使用して、警告とエラーのリストではなく辞書を返すようにデータチェックAPIを更新しました。 この問題を念頭に置いて、PRを更新してDataCheckResultsを返します。ここでerrorsとwarningsは属性であり、 to_jsonメソッドを追加します。 @BoopBoopBeepBoopがここで提案したように、最小限の情報でJSON形式のメッセージを返すクラスの場合-今のところ、メッセージとレベルのみ。

この問題は、JSON出力へのフィールド（「コード」など）の追加を追跡するために未解決のままになります。

ありがとう@ angela97lin ！

だからここに最新の提案があります：

• DataCheck.validateとDataChecks.validateを更新して、両方とも次の形式を返します。

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

上記の各エントリは次の形式です。

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

• 上記のcodeフィールドに入力するためのDataCheckMessageCode列挙型を定義します。
• DataCheckMessage 、 DataCheckError 、およびDataCheckWarningクラスを削除して、上記のdict形式を優先します

これを作成する前に、異議/コメントはありますか？ @ tyler3991 @Cmancuso @BoopBoopBeepBoop @ angela97lin @freddyaboulton

（ @ angela97lin @freddyaboulton DataCheckResultsクラスを使用してこの提案のバージョンを入力し始め、別のクラスを定義するのではなく、JSON化されたdictを上から返す必要があると判断しました。機能的には同等ですが、そうではありません。クラスの使用は簡単です。クラスが実行するすべての結果は、他の機能を追加するのではなく、同じ情報を保持することです。それが悪い考えだと思う場合は、LMKです。）

このREPR ＃1444についてDataCheckMessageクラスを内部に保持することを選択する場合があります。 ただし、 validateは、上記で定義されているように、JSON対応のdictのdictを返します。

（ @ angela97linそれが今話し合ったものと一致しない場合は、私を訂正してください！）

@ angela97linでこれを微調整します。 最新：

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

ここで、「詳細」キーは、データチェックが返したい情報を保持できます。 また、含めるものがない場合は省略します。

次のデータチェックを更新して、チェックに失敗した列を含める必要があります：高度にnull、ID、およびターゲットリーク。 他のデータチェックも更新するとボーナス:)

これは基本的に@BoopBoopBeepBoopが提案したものです！ ✨ @ Cmancuso