Evalml: Pemeriksaan data: Pesan ramah-JSON fmt, sertakan jenis enum dan nama kolom yang terpengaruh

Sedikit perluasan: untuk mengaktifkan pemformatan & internasionalisasi terprogram lainnya, alangkah baiknya jika EvalML mengembalikan informasi yang tidak diformat selain pesan yang dikembalikan sekarang. Sesuatu seperti:

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

Ini akan memungkinkan untuk melakukan pemformatan independen bahasa pada hasil, dengan mengikat code kembali ke string internasionalisasi. Dan memiliki metadata yang tersedia secara detail memungkinkan informasi tersebut diformat kembali secara opsional ke dalam pesan yang disajikan secara terstruktur.

Selain itu, memisahkan pemeriksaan dari kode aktual yang dikembalikan akan memungkinkan kami merancang pemeriksaan yang dapat memiliki kumpulan rekomendasi/kesalahan/peringatan berbeda yang dihasilkan dari satu contoh pemeriksaan.

@BoopBoopBeepBoop terima kasih. Saya suka usulan itu.

Apakah Anda mengharapkan "kode" menjadi enum, atau hanya string yang ditentukan di suatu tempat di dalam pemeriksaan data?

Satu tweak yang mungkin saya sarankan adalah menjaga struktur tetap datar:

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

Di sini kita berbicara tentang JSON, tetapi mengesampingkannya, saya pikir masing-masing bidang ini harus dilampirkan ke objek DataCheckWarning / DataCheckError .

Itu adil - saya telah menambahkan elemen-elemen itu di sana karena di kepala saya detail adalah "pada dasarnya sebuah peta". Namun, itu bukan contoh yang bagus, karena mungkin ada untuk semua pemeriksaan ...

Akankah ada situasi di mana pesan kita harus menyertakan metadata tambahan yang pada dasarnya ada pada basis "per-pesan"? Contoh yang pernah saya lihat sebelumnya akan memanggil nilai tertentu sebagai contoh, memformat batas bawah/atas dinamis dalam pesan, atau serupa. Itu biasanya di mana Anda mendapat manfaat dari memiliki peta detail (atau pilih nama lain)

Apakah Anda mengharapkan "kode" menjadi enum, atau hanya string yang ditentukan di suatu tempat di dalam pemeriksaan data?

Saya hanya berharap itu stabil - tempat tinggalnya

Apakah Anda mengharapkan "kode" menjadi enum, atau hanya string yang ditentukan di suatu tempat di dalam pemeriksaan data?

Saya hanya berharap itu stabil - tempat tinggalnya

Jika semuanya sama, saya pikir saya lebih suka enum. Kami saat ini mendefinisikan string kami sendiri untuk menentukan pemeriksaan mana yang dijalankan sebagai bagian dari pekerjaan, dan alangkah baiknya jika memiliki enum yang konsisten dengan EvalML untuk dimanfaatkan di sana alih-alih membuat milik kami sendiri.

Bersamaan dengan ini dan mungkin terhadap apa yang @BoopBoopBeepBoop sebutkan dengan detail, mungkin berguna untuk mengetahui jenis kesalahan apa yang terjadi. Misalnya, dalam pemeriksaan kolom ID, EvalML melakukan pemeriksaan apakah nama kolom memiliki "id" di dalamnya atau apakah nilainya N% unik. Kami mungkin ingin memfilter yang pertama atau mewakilinya secara berbeda, jadi tingkat perincian ini mungkin berguna, baik melalui enum yang lebih terperinci atau dalam sesuatu yang mirip dengan struktur detail yang dijelaskan di atas.

Baru saja didiskusikan dengan @dsherry @freddyaboulton : Saya telah memasang https://github.com/alteryx/evalml/pull/1444 untuk memperbarui API pemeriksaan data kami untuk mengembalikan kamus alih-alih daftar peringatan dan kesalahan. Dengan mempertimbangkan masalah ini, saya akan memperbarui PR saya untuk mengembalikan DataCheckResults mana errors dan warnings adalah atribut, serta menambahkan metode to_json untuk kelas yang akan mengembalikan pesan berformat JSON seperti yang disarankan @BoopBoopBeepBoop di sini, dengan informasi minimal--untuk saat ini, hanya pesan dan levelnya.

Masalah ini akan tetap terbuka untuk melacak penambahan lebih banyak bidang (seperti "kode") ke keluaran JSON.

Terima kasih @ angela97lin !

Jadi inilah proposal terbaru:

• Perbarui DataCheck.validate dan DataChecks.validate untuk keduanya mengembalikan format berikut:

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

di mana setiap entri di atas adalah format

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

• Tentukan enum DataCheckMessageCode untuk mengisi bidang code atas.
• Hapus kelas DataCheckMessage , DataCheckError dan DataCheckWarning mendukung format dict di atas

Adakah keberatan/komentar sebelum kami membangun ini? @tyler3991 @Cmancuso @BoopBoopBeepBoop @angela97lin @freddyaboulton

( @angela97lin @freddyaboulton Saya mulai mengetik versi proposal ini dengan kelas DataCheckResults , dan kemudian memutuskan bahwa kita harus mengembalikan dict yang disamakan dengan JSON dari atas, daripada mendefinisikan kelas lain. Secara fungsional setara, tetapi tidak menggunakan kelas lebih sederhana. Semua hasil yang akan dilakukan kelas adalah menyimpan info yang sama, tidak menambahkan fungsionalitas lain ke dalamnya. LMK jika menurut Anda itu ide yang buruk.)

Berbicara dengan @ angela97lin tentang RE PR #1444 ini. Paket di atas tidak berubah, kecuali dia dapat memilih untuk menyimpan kelas DataCheckMessage sekitar internal untuk kenyamanan / untuk mempersulit orang untuk menentukan entri pesan yang tidak valid. Tetapi validate akan mengembalikan dict dari dicts yang dapat JSON seperti yang didefinisikan di atas.

( @ angela97lin jika itu tidak sesuai dengan apa yang baru saja kita diskusikan, mohon koreksi saya!)

Tweak ini dengan @angela97lin . Terbaru:

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

di mana kunci "detail" dapat menyimpan info apa pun yang ingin dikembalikan oleh pemeriksaan data. Dan itu akan dihilangkan jika tidak ada yang dimasukkan.

Kami perlu memperbarui pemeriksaan data berikut untuk menyertakan kolom yang gagal dalam pemeriksaan: sangat nol, ID, dan kebocoran target. Bonus jika kami juga memperbarui cek data lainnya :)

Ini pada dasarnya apa yang diusulkan @BoopBoopBeepBoop ! @Cmancuso FYI