Evalml: Penanganan kesalahan untuk kode dengan dependensi pihak ketiga

Dibuat pada 22 Jan 2020  ·  10Komentar  ·  Sumber: alteryx/evalml

Saat ini kami memiliki setidaknya satu ketergantungan perpustakaan pihak ketiga (xgboost) dan satu lagi dalam perjalanan (catboost #247). Masalah ini melacak mencari tahu bagaimana kami menyajikannya kepada pengguna.

Pertanyaan:

  • Apa yang terjadi ketika pengguna mencoba menjalankan saluran dengan ketergantungan pihak ketiga yang tidak diinstal?
  • Bagaimana kami mengizinkan pengguna untuk memilih ikut serta atau keluar dari penggunaan pipeline dengan dependensi pihak ketiga selama automl?

Pikiran saya saat ini adalah bahwa kode @angela97lin menambahkan di catboost PR adalah awal yang baik, yaitu kita memiliki setiap estimator atau komponen melempar kesalahan ketika perpustakaan yang mendasarinya hilang. Tapi saya pikir kita bisa melakukan lebih dari itu juga. Kami dapat menangkap kesalahan itu di automl, melewati saluran yang dimaksud, mungkin mencetak peringatan, dan melanjutkan pencarian. Kami juga dapat meminta pengguna untuk menginstal deps pihak ketiga secara default, dengan memasukkan mereka ke dalam requirements.txt , yang seharusnya mencakup sebagian besar kasus.

Menambahkan komentar terkait yang dibuat di #247 untuk menyimpan semuanya di satu tempat:

  • Apakah kami menyertakan pipeline dengan dependensi pihak ketiga dalam pencarian automl? (Saya pikir fakta bahwa kami menambahkannya ke basis kode menyiratkan "ya" kecuali kami menemukan mereka tidak berguna karena alasan tertentu)
  • Bagaimana seharusnya perilaku pipeline dan komponen pihak ketiga bagi pengguna yang tidak menginstal ketergantungan pihak ketiga? Ada beberapa opsi: kesalahan, peringatan, kegagalan diam/lewati, atau lakukan pemeriksaan perpustakaan sebelum pencarian automl dimulai dan jangan sertakan pipa itu untuk memulai (yang terakhir ini adalah favorit saya)
  • Bagaimana kita menambahkan cakupan tes jawaban kita di atas?
enhancement needs design refactor

Semua 10 komentar

Catatan @jeremyliweishih kita harus memutuskan apakah hal semacam ini ada dalam lingkup proyek pipa atau jika kita ingin menyepaknya

Saya pikir itu harus menjadi masalah satu kali saja dan bukan bagian dari persyaratan untuk proyek pipa karena tidak ada banyak ikatan dengan bagian lain dari proyek. Kami selalu dapat menambahkan proyek pipa sebagai pemblokir untuk perbaikan jangka panjang dan menyertakan tambalan sederhana (termasuk semua deps pihak ketiga sejauh ini) terlebih dahulu.

Terdengar bagus untukku. Dalam hal ini saya pikir kita harus mempertimbangkan ini sebagai pemblokiran pada proyek pipa, karena solusinya dapat berubah tergantung pada apa yang kita ubah tentang pipa

@kmax12 :

Naluri saya di sini adalah bahwa kita harus menyelesaikan proyek pipa fase 1 yang sedang dikerjakan @jeremyliweishih , kemudian kembali ke masalah ini dan membangun cara berkelanjutan untuk membuat dependensi pihak ketiga opsional.

Dan sampai saat itu, kami dapat terus menggabungkan hal-hal seperti #247 (yang menambahkan deps pihak ketiga baru ke requirements.txt tetapi juga menambahkan penanganan kesalahan yang belum sempurna sebagai fallback), dengan pemahaman kami akan melingkari kembali dan menjadikannya opsional saat kami mengatasi masalah ini.

Apakah Anda punya pendapat tentang rencana itu?

@kmax12 mengatakan dalam rapat hari ini:

  • Dia setuju dengan rencana ini. Memisahkan deps pihak ketiga dari proyek pipeline
  • Dua kategori deps pihak ketiga: 1) lib untuk pemodelan pipa, 2) pustaka khusus fitur seperti S3
  • Lihat featuretools: pip install eval[complete] . Dan evaluasi
  • Adalah baik untuk memiliki instalasi sederhana, yang tidak memerlukan segalanya
  • Ada beberapa deps di sana yang harus dihapus sama sekali, seperti merencanakan libs
  • Langkah selanjutnya untuk fitur ini adalah dokumen desain tentang cara kami menyelesaikannya
  • Untuk saat ini, import_or_raise berguna untuk digunakan, seperti yang dilakukan Angela di catboost PR

Menambahkan catatan tambahan dari komentar yang dibuat di #247 :

@dsherry menyebutkan cb_error_msg (pesan kesalahan muncul saat catboost tidak diinstal) dan pesan serupa lainnya dapat menjadi atribut dari Estimator. Misalnya, kita dapat melakukan hal berikut:

  • Tentukan variabel libs di Estimator yang merupakan daftar kosong secara default
  • Tentukan metode kelas Estimator.libs_err_msg(lib), yang secara default mengambil format string "{lib} tidak diinstal. Harap instal menggunakan pip install {lib}." dan menerapkan argumen lib untuk itu
  • Minta Estimator.__init__ melakukan sesuatu seperti untuk lib di self.libs: import_or_raise(lib, self.libs_err_msg(lib))
  • Mintalah setiap kelas mendefinisikan lib sebagai daftar dengan satu atau lebih nama perpustakaan pihak ketiga
  • Dan secara opsional, setiap kelas dapat menentukan penggantian libs_err_msg(lib) jika diperlukan

Saya pikir itu bahkan bisa berharga di level ComponentBase sehingga komponen apa pun yang membutuhkan perpustakaan pihak ketiga dapat menggunakan kerangka kerja ini.

Saya akan mencoba untuk menjatuhkan ini minggu ini. Langkah selanjutnya adalah membuat daftar permintaan dan perilaku yang diinginkan, dan memutuskan API.

@rwedge dan saya membahas ini kemarin.

Latar belakang konfigurasi instalasi melalui setuptools
Setuptools mendukung "ekstra" yang dapat kita gunakan untuk melakukan sesuatu seperti pip install evalml[complete] yang dapat dikonfigurasi untuk menginstal paket tambahan selain pip install evalml .

Perhatikan tampaknya mekanisme ini mendukung penginstalan paket tambahan, dan berpotensi memperbarui versi paket yang diinstal sebelumnya, tetapi tidak menghapus paket. Tidak apa-apa.

Opsi instalasi
Berikut beberapa cara kami dapat menggunakan ekstra pip untuk mengatur ulang dependensi yang diperlukan untuk mengecualikan lib pihak ketiga secara opsional:

  1. evalml : hanya menginstal sklearn. evalml[complete] : juga termasuk pihak ketiga (xgboost/catboost)
  2. evalml : tidak melakukan apa-apa / kesalahan. evalml[minimal] : hanya menginstal sklearn. evalml[complete] : juga termasuk pihak ketiga.
  3. Mungkin ada cara untuk mengatur sesuatu sedemikian rupa sehingga menggunakan evalml menyertakan pihak ketiga tetapi evalml[minimal] tidak, tetapi tidak yakin.

Opsi 1 terasa paling menarik. Saya tidak mengetahui adanya opsi bagus untuk menangani hal ini selain tetap menggunakan penyiapan alat penyiapan kami saat ini.

Opsi dukungan kode
Tidak harus saling eksklusif:

  1. Jalankan import_or_raise pada waktu yang tepat; memiliki kegagalan automl lewati
  2. Minta setiap saluran pipa mencantumkan deps pihak ketiga sebagai metadata; jalankan import_or_raise pada waktu init; memiliki automl mengecualikan pipa yang impornya gagal
  3. Introspeksi: tulis beberapa kode yang memindai paket yang digunakan oleh setiap kelas pipa pada waktu init
  4. Registri: tentukan kelas tunggal yang dapat menyediakan daftar pusat saluran pipa dan dapat merangkum beberapa fungsi ini. Kami telah membahas ini di dokumen/catatan desain untuk #345

Opsi 1 terasa terbaik bagi saya.

Pertanyaan untuk dipertimbangkan

  • Jika kita menggunakan tambahan setuptools, apakah kita nyaman mendukung lebih dari satu target pip install ? Kita harus memiliki cakupan tes untuk keduanya.
  • Bagaimana dengan komponen preprocessing yang menggunakan library pihak ketiga? Bagaimana strategi kita perlu diubah, jika memang ada?
  • Kapan kita ingin pemeriksaan dilakukan, pada saat init-time atau fit-time?

Usul

  • Pindahkan dependensi pihak ketiga ke ekstra, artinya pip install evaml tidak akan menginstalnya tetapi pip install evalml[complete] akan menginstalnya.
  • Minta semua saluran pipa pihak ketiga (xgboost/catboost) menjalankan import_or_raise (sudah selesai)
  • Pastikan automl melewati pipeline pihak ketiga jika import_or_raise gagal.
  • Pengujian: perbarui pengujian saat ini untuk menginstal versi lengkap. Tambahkan tes integrasi yang menginstal versi minimal dan memeriksa fungsionalitas utama. Jalankan itu di checkin untuk menguasai.
  • Perbarui dokumentasi.

Keuntungan: Memungkinkan pengguna untuk menginstal evalml tanpa perpustakaan pihak ketiga.
Kekurangan: Instalasi default tidak sekuat itu. Kami harus mendukung dua versi penginstalan. Bisa jadi jelek menyiapkan automl untuk melewati jalur pipa yang gagal.

Untuk jangka panjang, alangkah baiknya jika kita bisa menemukan solusi yang memunculkan error atau warning lebih awal dari fit-time.

@kmax12 apakah Anda punya pendapat tentang masalah ini?

Saya melakukan tinjauan semua dependensi di requirements.txt . Saya menyertakan ukuran direktori lib setiap perpustakaan di virtualenv di mac saya, untuk mengukur kepentingannya.

Paket yang dibutuhkan oleh evalml dan akan cukup sulit untuk dibuat opsional:

  • numpy (86MB): diperlukan
  • panda (47MB): diperlukan
  • scipy (126MB): diperlukan
  • scikit-belajar (29MB): diperlukan
  • scikit-optimize[plots] (572KB): diperlukan untuk tuner automl
  • category_encoder (776KB): diperlukan untuk encoder satu-panas
  • cloudpickle (132KB): diperlukan untuk menyimpan dan memuat pipa

Paket yang berpotensi dihapus:

  • joblib (1.9MB): tidak yakin, tidak ada referensi langsung. Saya akan mencoba menghapus dan memperbarui.
  • plotly (51MB) : digunakan untuk menghasilkan plot pipa, dalam dokumentasi. Mungkin saja kami dapat memperbarui untuk dinonaktifkan secara default.
  • ipywidgets (824KB): digunakan untuk menghasilkan plot pipa, dalam dokumentasi. Mungkin saja kami dapat memperbarui untuk dinonaktifkan secara default, bersama dengan plotly
  • dask[complete] (50MB) : saat ini hanya direferensikan dalam utilitas yang digunakan dalam kode demo. Ketika kami menambahkan dukungan terdistribusi, itu akan diperlukan untuk itu. Kita bisa menggunakan import_or_raise di sana untuk saat ini
  • colorama (72KB): digunakan dalam logging untuk definisi warna. Kami mungkin dapat menghapusnya, tetapi mungkin tidak sepadan karena ukurannya di bawah 100KB.
  • tqdm (316KB): memberi daya pada output konsol dalam pencarian automl. Kami mungkin dapat memperbaruinya untuk dinonaktifkan secara default. Tapi ini paket kecil.

Kesimpulan: kami dapat mengurangi ukuran penginstal banyak jika kami membuat lebih banyak hal opsional.

Apakah ini memengaruhi rencana kami untuk menangani saluran pipa pihak ketiga? Kami dapat bergerak untuk mendukung beberapa tambahan:

  • pip install evalml : minimal saja, tidak ada cetak biru pihak ketiga, tidak ada plot, tidak ada dukungan terdistribusi
  • pip install evalml[thirdparty] : sertakan cetak biru pihak ketiga
  • pip install evalml[plotting] : minimal, ditambah ploting
  • pip install evalml[distributed] : minimal, ditambah dukungan terdistribusi
  • pip install evalml[plotting,distributed,thirdparty] atau pip install evalml[complete] : sertakan semuanya

Ini akan bekerja dengan baik. Meski rasanya terlalu rumit. Dan itu menimbulkan kekhawatiran tentang pengujian: kami setidaknya memerlukan pengujian integrasi untuk masing-masing untuk memastikan perpustakaan bekerja dengan subset deps.

Alternatifnya adalah hanya mendukung dua target, default minimal dan complete yang mencakup yang lainnya. Pengguna kemudian dapat menginstal dependensi tertentu dengan tangan jika mereka menginginkan subset dari complete .

Solusi didiskusikan dengan @kmax12 :

  • Untuk menghindari deps: pip install --no-dependencies evalml lalu instal deps tertentu secara manual
  • Kami bahkan dapat membuat perintah Makefile untuk itu
  • Perbarui dokumentasi untuk menjelaskan cara melakukan ini
  • Kode kami tidak meledak jika ada paket yang hilang
  • Secara default: sertakan xgboost/catboost. Termasuk merencanakan. Kecualikan dask/distributed (perbarui kode untuk tidak menggunakannya)

Opsi untuk dipertimbangkan untuk jangka panjang: buat dua paket setup.py : evalml-base minimal dan evalml semuanya.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat