Evalml: Larang penarikan kembali sebagai tujuan automl

Saya pikir presisi dan akurasi baik-baik saja dalam arti mereka tidak akan memberi Anda model yang sepele.

kami tidak selalu ingin menghapus penarikan sebagai tujuan, hanya saja tidak boleh mengoptimalkannya dalam pencarian automl. misalnya, saya mungkin ingin mengoptimalkan f1, tetapi kemudian melihat skor ingatan saya di sampingnya

@ kmax12 ya, benar, kami tidak ingin menghapus kode yang menghitung penarikan, dan kami ingin tetap mendukung penarikan komputasi sebagai skor pada saluran, tetapi kami ingin melarangnya sebagai tujuan pengoptimalan yang didukung di automl.

Ini mengingatkan saya pada diskusi yang sedang berlangsung seputar metode klasifikasi biner plotting/info untuk ROC dan matriks konfusi (#427, #365). Itu bukan metrik yang dapat kami optimalkan di automl, dan itu juga bukan skor angka tunggal, tetapi di bawah API kami, cara termudah untuk mendefinisikannya adalah dengan menambahkannya sebagai instance dari ObjectiveBase .

Saat ini kami memiliki sejumlah hal yang dapat dihitung menggunakan pipeline:

1. Prediksi
2. Skor fungsi objektif untuk automl
3. Metrik penilaian, setelah automl
4. Plotting data (contoh untuk klasifikasi biner: kurva ROC, matriks konfusi)
5. Fitur penting

Saya pikir sampai saat ini kami telah mencoba menggunakan ObjectiveBase untuk mewakili 2, 3, dan 4. Dengan kata lain, kami kehilangan API yang jelas untuk menentukan metode penilaian dan metode plot, terpisah dari proses automl .

Saya pikir langkah selanjutnya di sini adalah mendesain API tersebut. Sepertinya saya sudah mengajukannya sebagai #392. Saya akan memperbarui tiket ini untuk diblokir pada itu.

Untuk pengerjaan ulang API tujuan sekarang, kami telah memindahkan ROC dan Confusion Matrix ke PlotMetrics sebagai gantinya (lebih sedikit desain yang digunakan, ini adalah cara termudah untuk memisahkan keduanya dari tujuan lainnya tanpa merusak barang). Kami juga telah menambahkan can_optimize_threshold sebagai atribut untuk BinaryClassificationObjective , jadi jika fit() dipanggil dengan tujuan dengan can_optimize_threshold=True maka kami mengoptimalkan untuk tujuan itu, jika tidak, kami mengoptimalkan untuk Ketepatan. Pemikiran tentang hal ini dan bagaimana hal ini dapat sejalan dengan beberapa pertanyaan yang diajukan di sini? Apakah tidak jelas apakah pengguna memanggil fit pada Recall tetapi sebaliknya kami mengoptimalkan untuk Akurasi?

@angela97lin ya, saya pikir memindahkan ROC/kebingungan dari ObjectiveBase adalah langkah positif! Saya pikir #392 harus melacak lebih jauh. Mari kita lanjutkan percakapan tentang cara memperbarui API di #392. Dengan begitu, masalah ini hanya dapat melacak pembaruan mengingat setelah kami membuat keputusan tentang cara menangani hal ini secara lebih umum.

Juga saya pikir pengoptimalan ambang klasifikasi biner adalah subjek yang terpisah, dan untungnya pekerjaan Anda yang sedang berlangsung di #346 menangani 100%!

Meringkas diskusi dengan @eccabay dan @jeremyliweishih sebelumnya: Opsi untuk mendukung ini adalah:

• Hapus tujuan penarikan seluruhnya.
• Hapus entri untuk tujuan penarikan kembali di objectives/utils.py OPTIONS , dan konfirmasikan bahwa melarang tujuan tersebut di automl.