Evalml: Perbarui pipa dan komponen untuk mengembalikan struktur data Woodwork

Dibuat pada 4 Nov 2020  ·  5Komentar  ·  Sumber: alteryx/evalml

1393 memperbarui pipeline untuk menerima struktur data Woodwork, dan #1288 membahas memperbarui pipeline dan komponen untuk menerima struktur data Woodwork sebagai input. Namun, output untuk metode seperti transform dan predict masih merupakan DataFrames panda, yang aneh. Masalah ini melacak pembaruan metode kami untuk mengembalikan struktur data Woodwork.

Komentar yang paling membantu

Sepertinya opsi ketiga adalah opsi terbaik dan terbersih. Mudah-mudahan kinerjanya tidak terpengaruh, tetapi secara konseptual tampaknya terdengar bagus. Terima kasih telah membawanya ke perhatian saya ... mencoba untuk membungkus kepala saya di sekitar semua hal.

Semua 5 komentar

Memikirkan ini untuk saat ini, mengingat Woodwork sedang menyelesaikan rencana pembaruan besar. Jika Woodwork menjadi perpanjangan dari panda, kita mungkin tidak ingin atau perlu melakukan ini.

@ angela97lin dan saya check in, dan mendiskusikan beberapa opsi implementasi:

  1. Minta evaluasi grafik komponen meneruskan panda ke setiap komponen. Untuk menunjukkan jenis ww ke komponen, tambahkan bidang baru ke fit dll., atau tetap dengan pola fitur teks menggunakan parameter init untuk menunjukkan kolom yang relevan. Kekurangan: jelek dari perspektif API, inilah mengapa kami membuat kayu di tempat pertama.
  2. Selama evaluasi grafik komponen, berikan woodwork ke setiap komponen. Minta setiap komponen mengembalikan panda. Kerugian: batasan potensial adalah bahwa komponen tidak dapat mengubah jenis kayu dari fitur input atau fitur yang baru dibuat, kecuali dengan mengubah pandas dtype. Kami tidak memiliki komponen yang bergantung pada ini.
  3. Selama evaluasi grafik komponen, berikan woodwork ke setiap komponen. Minta setiap komponen mengembalikan kayu. Tantangan: sebagian besar komponen harus dikonversi ke panda secara internal untuk melakukan transformasi seperti menambahkan fitur, menghapus fitur, atau memodifikasi fitur. Setelah transformasi tersebut, kita harus memastikan jenis kayu asli masuk ke datatable kayu baru yang dikembalikan, jika tidak, pengaturan yang diganti pengguna akan hilang, seperti sekarang ini.

Status: @angela97lin saat ini sedang mengejar opsi 3 di #1668

Rencana: kami akan melanjutkan strategi itu, mengawasi runtime yang berkurang karena beberapa instantiasi yang dapat didata. Dan kami akan mempertimbangkan jika ada permintaan fitur yang harus kami buat pada kayu untuk membuatnya lebih mudah. Kami juga akan mengawasi setiap opsi menarik yang mungkin kami lewatkan sejauh ini.

@chukarsten @gsheni

Sepertinya opsi ketiga adalah opsi terbaik dan terbersih. Mudah-mudahan kinerjanya tidak terpengaruh, tetapi secara konseptual tampaknya terdengar bagus. Terima kasih telah membawanya ke perhatian saya ... mencoba untuk membungkus kepala saya di sekitar semua hal.

Meretas ini dan memikirkan lagi:

Tujuan akhirnya adalah kita memerlukan beberapa cara untuk melacak tipe logika asli yang diinginkan pengguna. Ini bisa berupa informasi yang disimpan oleh grafik komponen, atau diteruskan ke setiap komponen yang bertanggung jawab untuk kemudian mengatur kembali tipe-tipe tersebut setelah mentransformasikan beberapa data. Saat ini mengejar 3, dan menambahkan informasi ke grafik komponen karena itu yang paling mudah untuk diuji (daripada memperbarui setiap komponen)... tetapi pada tingkat komponen, itu tidak masuk akal.

Katakanlah pengguna menentukan Woodwork DataTable dan secara eksplisit mengonversi col kategoris ke bahasa alami. Pengguna meneruskannya ke komponen. Kita perlu mengonversi ke panda untuk meneruskan ke perpustakaan eksternal, dan kita ingin mengembalikan objek Woodwork. Jika kita hanya memanggil konstruktor Woodwork, itu hanya akan mengambil tipe yang disimpulkan (kategoris), yang ganjil? Jadi kita harus melacak jenis bahasa alami asli yang ditentukan dan mengonversinya sebelum menyerahkan kembali ke pengguna.

Menarik untuk dicatat adalah scaler standar: itu bisa mengambil kolom int dan mengubahnya menjadi float. Jika kita kemudian mencoba untuk mengatur col kembali ke tipe aslinya (int), kita akan dimarahi karena mencoba mengubah float menjadi int ketika itu tidak aman. 😬.

Pembaruan: berdiskusi singkat dengan @dsherry dan @chukarsten. Saat ini saya sedang menerapkan # 3, tetapi memiliki grafik komponen yang menangani melacak jenis pengguna asli dan memperbarui informasi itu saat diteruskan dari komponen ke komponen. Ini berfungsi dengan baik dan membawa kita ke tempat di mana AutoML / pipeline berfungsi, tetapi setelah #1668 digabungkan, kita harus menangani penanganan ini di tingkat komponen dan menghapus kode ini dari grafik komponen.

Tugas saya selanjutnya: perbaiki tes indeks dari memperbarui cabang dari utama, bersihkan komentar dan masalah file yang dapat diatasi yang tidak terkait dengan PR ini (hanya kode pembersihan umum). Setelah kode lebih bersih, cari redundansi dan profil untuk melihat dari mana perbedaan waktu yang sangat besar ini berasal / apa yang dapat kita lakukan untuk mengatasinya.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat