Aturan Machine Learning:

Praktik Terbaik untuk Engineering ML

Martin Zinkevich

Dokumen ini dimaksudkan untuk membantu mereka yang memiliki pengetahuan dasar tentang komputer pembelajaran mendapatkan manfaat dari praktik terbaik Google dalam machine learning. Ini menyajikan gaya untuk machine learning, yang mirip dengan Panduan Gaya Google C++ dan panduan populer lainnya untuk pemrograman praktis. Jika Anda telah mengikuti kelas machine learning, atau dibuat atau dikerjakan dengan model machine learning, memiliki latar belakang yang diperlukan untuk membaca dokumen ini.

Martin Zinkevich memperkenalkan 10 aturan favoritnya machine learning. Baca terus untuk mempelajari ke-43 aturan tersebut.

Terminologi

Istilah-istilah berikut ini akan muncul berulang kali dalam diskusi kita mengenai {i>machine learning<i}:

  • Instance: Hal yang ingin Anda buat prediksi. Misalnya, instance mungkin halaman web yang Anda ingin klasifikasikan sebagai "tentang kucing" atau "bukan tentang kucing".
  • Label: Jawaban untuk tugas prediksi, baik jawaban yang dihasilkan oleh machine learning, atau jawaban yang tepat diberikan dalam data pelatihan. Sebagai contoh, label untuk laman web mungkin "tentang kucing".
  • Fitur: Properti instance yang digunakan dalam tugas prediksi. Sebagai misalnya, laman web mungkin memiliki fitur "berisi kata 'kucing'".
  • Kolom Fitur: Rangkaian fitur terkait, misalnya kumpulan semua kemungkinan negara tempat pengguna tinggal. Sebuah contoh mungkin memiliki satu atau beberapa fitur yang ada di kolom fitur. "Kolom fitur" adalah terminologi khusus Google. Kolom fitur disebut sebagai "ruang nama" di sistem VW (di Yahoo/Microsoft), atau kolom.
  • Contoh: Instance (dengan fiturnya) dan label.
  • Model: Representasi statistik dari tugas prediksi. Anda melatih model di contoh, kemudian menggunakan model tersebut untuk membuat prediksi.
  • Metrik: Angka yang penting bagi Anda. Mungkin atau mungkin tidak secara langsung dioptimalkan.
  • Tujuan: Metrik yang coba dioptimalkan oleh algoritme Anda.
  • Pipeline: Infrastruktur yang mengelilingi algoritma machine learning. Termasuk mengumpulkan data dari frontend, memasukkannya ke dalam data pelatihan melatih satu atau beberapa model, dan mengekspor model ke produksi.
  • Rasio klik-tayang: Persentase pengunjung halaman web yang mengklik link dalam iklan.

Ringkasan

Untuk membuat produk yang hebat:

melakukan machine learning seperti teknisi hebatmu, bukan seperti insinyur Anda bukan pakar machine learning.

Sebagian besar masalah yang akan Anda hadapi sebenarnya adalah masalah teknik. Merata dengan semua sumber daya dari pakar {i> machine learning<i} yang hebat, sebagian besar keuntungan berasal dari fitur yang bagus, bukan algoritma {i>machine learning<i} yang hebat. Jadi, hal-hal dasar pendekatannya adalah:

  1. Pastikan pipeline Anda solid secara menyeluruh.
  2. Mulailah dengan tujuan yang wajar.
  3. Tambahkan fitur umum dengan cara yang sederhana.
  4. Pastikan pipeline Anda tetap solid.

Pendekatan ini akan bekerja dengan baik untuk jangka waktu yang lama. Berbeda dengan pendekatan ini hanya ketika tidak ada lagi trik sederhana untuk membawa Anda lebih jauh. Penambahan kompleksitas akan memperlambat rilis mendatang.

Setelah berupaya melakukan trik sederhana, machine learning yang canggih mungkin memang berada di masa depan. Lihat bagian tentang Tahap III project machine learning.

Dokumen ini disusun sebagai berikut:

  1. Bagian pertama akan membantu Anda memahami apakah waktu yang tepat untuk membangun sistem {i>machine learning<i}.
  2. Bagian kedua adalah tentang men-deploy pipeline pertama.
  3. Bagian ketiga membahas peluncuran dan melakukan iterasi sambil menambahkan fitur baru ke pipeline Anda, cara mengevaluasi model dan diferensiasi performa pelatihan dan penayangan.
  4. Tujuan bagian terakhir adalah tentang apa yang harus dilakukan ketika Anda mencapai dataran tinggi.
  5. Setelah itu, ada daftar pekerjaan terkait dan lampiran dengan beberapa latar belakang tentang sistem yang biasa digunakan sebagai contoh dalam dokumen ini.

Sebelum Machine Learning

Aturan #1: Jangan takut meluncurkan produk tanpa machine learning.

Machine learning memang keren, tetapi memerlukan data. Secara teoritis, Anda dapat mengambil data dari masalah yang berbeda dan kemudian menyesuaikan model untuk produk baru, tetapi cenderung akan memiliki performa dasar yang lebih rendah heuristik. Jika Anda berpikir bahwa machine learning akan memberi peningkatan 100%, lalu heuristik akan memberi Anda 50% dari perjalanan ke sana.

Misalnya, jika Anda memberi peringkat aplikasi di pasar aplikasi, Anda dapat menggunakan rasio instal, atau jumlah instal secara heuristik. Jika Anda mendeteksi spam, untuk mengecualikan penayang yang telah mengirim spam sebelumnya. Jangan takut menggunakan manusia mengedit. Jika Anda perlu memberi peringkat kontak, beri peringkat kontak yang terakhir digunakan tertinggi (atau bahkan diberi peringkat menurut abjad). Jika machine learning belum sepenuhnya wajib untuk produk Anda, jangan gunakan sampai Anda memiliki data.

Aturan #2: Pertama, desain dan terapkan metrik.

Sebelum memformalkan apa yang akan dilakukan sistem machine learning Anda, lacak sebanyak mungkin mungkin dalam sistem Anda saat ini. Lakukan hal ini karena alasan berikut:

  1. Akan lebih mudah untuk mendapatkan izin dari pengguna sistem lebih awal.
  2. Jika Anda berpikir bahwa sesuatu mungkin menjadi kekhawatiran di masa depan, lebih baik mendapatkan data historis.
  3. Jika Anda merancang sistem Anda dengan mempertimbangkan instrumentasi metrik, akan lebih baik untuk Anda di masa depan. Secara khusus, Anda sebaiknya tidak menggunakan {i>string<i} di log untuk menginstrumentasikan metrik Anda!
  4. Anda akan melihat apa saja yang berubah dan apa yang tetap sama. Contohnya, misalkan Anda ingin langsung mengoptimalkan pengguna aktif satu hari. Namun, selama manipulasi awal sistem, Anda mungkin memperhatikan bahwa perubahan dramatis pada pengalaman pengguna tidak terlalu mengubah hal ini metrik.

Tim Google Plus mengukur perluasan per pembacaan, pembagian ulang per yang dibaca, plus satu per membaca, komentar/bacaan, komentar per pengguna, pembagian ulang per pengguna, dll. yang mereka gunakan dalam menghitung kebaikan postingan pada waktu penayangan. Selain itu, perlu diketahui bahwa framework eksperimen, tempat Anda dapat mengelompokkan pengguna ke dalam bucket dan statistik berdasarkan eksperimen itu penting. Lihat Aturan #12.

Dengan lebih liberal dalam mengumpulkan metrik, Anda dapat memperoleh gambaran yang lebih luas sistem Anda. Ada masalah? Tambahkan metrik untuk memantaunya. Antusias dengan beberapa ada perubahan kuantitatif pada rilis terakhir? Tambahkan metrik untuk memantaunya.

Aturan #3: Pilih machine learning daripada heuristik yang kompleks.

Heuristik sederhana dapat mempromosikan produk Anda. Heuristik kompleks adalah dan tidak dapat dipelihara. Setelah Anda memiliki data dan ide dasar tentang apa yang Anda coba capai, lanjutkan ke {i>machine learning<i}. Seperti dalam kebanyakan software engineering tugas ini, Anda perlu memperbarui pendekatan secara terus menerus, baik itu heuristik atau model {i>machine learning<i}, dan Anda akan menemukan bahwa model machine learning lebih mudah diupdate dan dipelihara (lihat Aturan #16).

ML Tahap I: Pipeline Pertama Anda

Fokus pada infrastruktur sistem untuk pipeline pertama Anda. Meskipun menyenangkan untuk memikirkan semua pembelajaran mesin imajinatif yang akan Anda lakukan, akan sulit untuk mencari tahu apa yang terjadi jika Anda tidak mempercayai {i>pipelines<i} yang sama.

Aturan #4: Jaga agar model pertama tetap sederhana dan dapatkan infrastruktur yang benar.

Model pertama memberikan dorongan terbesar untuk produk Anda, sehingga tidak perlu keren. Tetapi Anda akan menemui lebih banyak masalah infrastruktur daripada Anda kita harapkan. Sebelum siapa pun dapat menggunakan sistem {i>machine learning<i} baru yang canggih, Anda harus untuk menentukan:

  • Cara menambahkan contoh untuk algoritma pembelajaran Anda.
  • Potongan pertama tentang apa yang "bagus" dan "buruk" bagi sistem Anda.
  • Cara mengintegrasikan model Anda ke dalam aplikasi. Anda dapat menerapkan model berfungsi, atau melakukan prakomputasi model pada contoh secara {i>offline<i} dan menyimpan hasilnya dalam sebuah tabel. Misalnya, Anda mungkin ingin melakukan praklasifikasi halaman web dan menyimpan hasilnya dalam tabel, tetapi Anda mungkin ingin mengklasifikasikan pesan chat secara langsung.

Memilih fitur sederhana memudahkan Anda memastikan bahwa:

  • Fitur tersebut mencapai algoritma pembelajaran Anda dengan benar.
  • Model akan mempelajari bobot yang wajar.
  • Fitur tersebut menjangkau model Anda di server dengan benar.

Setelah Anda memiliki sistem yang melakukan tiga hal ini dengan andal, Anda telah sebagian besar pekerjaan. Model sederhana memberi Anda metrik dasar dan perilaku dasar yang dapat Anda gunakan untuk menguji model yang lebih kompleks. Beberapa tim menargetkan untuk "netral" peluncuran pertama: peluncuran pertama yang secara eksplisit tidak memprioritaskan {i>machine learning<i}, agar tidak teralihkan perhatiannya.

Aturan #5: Uji infrastruktur secara terpisah dari machine learning.

Pastikan bahwa infrastruktur dapat diuji, dan bahwa bagian pembelajaran dari sistem dienkapsulasi sehingga Anda dapat menguji segala sesuatu di sekitarnya. Khususnya:

  1. Menguji memasukkan data ke dalam algoritma. Periksa kolom fitur yang harus diisi. Jika privasi memungkinkan, secara manual memeriksa input ke algoritma pelatihan Anda. Jika memungkinkan, periksa statistik dalam pipeline Anda dibandingkan dengan statistik untuk data yang sama diproses di tempat lain.
  2. Menguji untuk mengeluarkan model dari algoritma pelatihan. Pastikan bahwa model di lingkungan pelatihan Anda memberikan skor yang sama dengan model di lingkungan penayangan Anda (lihat Aturan #37).

Machine learning memiliki unsur ketidakpastian, jadi pastikan Anda menjalankan pengujian kode untuk membuat contoh dalam pelatihan dan inferensi, serta Anda dapat memuat dan menggunakan model tetap selama penayangan. Selain itu, penting memahami data Anda: lihat Saran Praktis untuk Analisis Set Data Besar dan Kompleks.

Aturan #6: Berhati-hatilah dengan data yang dilepas saat menyalin pipeline.

Sering kali kita membuat pipeline dengan menyalin pipeline yang ada (misalnya, program penelusuran kargo ), dan pipeline lama menghapus data yang kita perlukan untuk pipeline baru. Misalnya, pipeline untuk Lagi Ngetren Google Plus menurunkan postingan yang lebih lama (karena mencoba memberi peringkat pada postingan baru). Pipeline ini disalin untuk digunakan untuk Aliran Google Plus, tempat postingan lama masih berarti, tapi {i>pipelines<i} itu masih mengurangi posting lama. Lainnya pola yang umum adalah hanya mencatat data yang dilihat oleh pengguna. Jadi, data ini tidak berguna jika kita ingin membuat model mengapa postingan tertentu tidak dilihat oleh pengguna, karena semua contoh negatif telah dihapus. Masalah serupa terjadi di Google Play. Saat mengerjakan Beranda Aplikasi Play, pipeline baru dibuat yang juga berisi contoh dari halaman landing untuk Play Game tanpa fitur apa pun memperjelas dari mana masing-masing contoh berasal.

Aturan #7: Ubah heuristik menjadi fitur, atau tangani secara eksternal.

Biasanya, masalah yang coba dipecahkan oleh machine learning bukanlah benar-benar baru. Sudah ada sistem yang mengatur peringkat, klasifikasi, atau masalah apa pun yang ingin Anda selesaikan. Ini berarti bahwa ada banyak aturan dan heuristik. Heuristik yang sama ini dapat memberi Anda peningkatan saat disesuaikan dengan machine learning. Heuristik Anda harus ditambang untuk apa pun informasi yang mereka miliki, karena dua alasan. Pertama, transisi ke server mempelajari sistem akan menjadi lebih lancar. Kedua, biasanya aturan-aturan itu mengandung banyak intuisi tentang sistem yang tidak ingin Anda buang. Ada empat cara menggunakan heuristik yang ada:

  • Lakukan prapemrosesan menggunakan heuristik. Jika fitur ini sangat hebat, maka ini adalah sebuah pilihan. Misalnya, jika dalam filter spam, pengirim sudah dimasukkan ke daftar hitam, jangan mencoba mempelajari kembali apa yang "masuk ke daftar hitam" maksudnya. Memblokir pesan. Pendekatan ini paling masuk akal dalam sistem biner tugas klasifikasi.
  • Buat fitur. Membuat fitur secara langsung dari heuristik sangat bagus. Misalnya, jika Anda menggunakan heuristik untuk menghitung skor relevansi untuk sebuah kueri hasil, Anda dapat menyertakan skor sebagai nilai fitur. Nanti Anda mungkin ingin menggunakan teknik machine learning untuk mengoptimalkan nilai (misalnya, mengubah nilai menjadi salah satu dari himpunan data diskret nilai tambah, atau menggabungkannya dengan fitur lain) tapi mulailah dengan menggunakan nilai yang dihasilkan oleh heuristik.
  • Menambang input mentah heuristik. Jika terdapat heuristik untuk aplikasi yang menggabungkan jumlah instal, jumlah karakter dalam teks, dan hari, lalu pertimbangkan untuk memisahkan potongan-potongan ini, dan memasukkan input ini ke dalam pembelajaran secara terpisah. Beberapa teknik yang berlaku untuk ansambel berlaku di sini (lihat Aturan #40).
  • Ubah label. Ini adalah pilihan ketika Anda merasa bahwa proses heuristik menangkap informasi yang saat ini tidak ada dalam label. Misalnya, jika Anda ingin memaksimalkan jumlah download, tetapi Anda juga ingin konten berkualitas, mungkin solusinya adalah dengan mengalikan label dengan jumlah rata-rata bintang yang diterima aplikasi. Ada banyak hal bebas di sini. Lihat "Tujuan Pertama Anda".

Perhatikan kerumitan tambahan saat menggunakan heuristik dalam ML sistem file. Menggunakan heuristik lama dalam algoritma machine learning baru dapat membantu menciptakan transisi yang mulus, tetapi pertimbangkan apakah ada cara yang lebih sederhana untuk mencapai efek yang sama.

Pemantauan

Secara umum, praktikkan kebersihan pemberitahuan yang baik, seperti membuat pemberitahuan yang dapat ditindaklanjuti dan memiliki halaman dasbor.

Aturan #8: Ketahui persyaratan keaktualan sistem Anda.

Seberapa besar penurunan performa jika Anda memiliki model yang berumur satu hari? Seminggu lama? Seperempat usianya? Informasi ini dapat membantu Anda memahami prioritas pemantauan Anda. Jika Anda kehilangan produk yang signifikan jika model tidak diperbarui selama sehari, masuk akal jika ada seorang insinyur yang menontonnya terus menerus. Iklan terbanyak sistem penayangan memiliki iklan baru untuk ditangani setiap hari, dan harus memperbarui per hari. Misalnya, jika model ML untuk Penelusuran Google Play tidak diupdate, mungkin saja memiliki dampak negatif dalam waktu kurang dari sebulan. Beberapa model untuk Lagi Ngetren Google Plus tidak memiliki ID postingan pada modelnya, jadi mereka bisa mengekspor model-model ini secara jarang. Model lain yang memiliki ID postingan diperbarui jauh lebih sering. Perhatikan juga bahwa keaktualan dapat berubah seiring waktu, terutama ketika kolom fitur ditambahkan atau dihapus dari model Anda.

Aturan #9: Deteksi masalah sebelum mengekspor model.

Banyak sistem machine learning memiliki tahap di mana Anda mengekspor model ke menyeluruh. Jika ada masalah dengan model yang diekspor, masalah tersebut terjadi masalah performa.

Lakukan pemeriksaan kesehatan tepat sebelum mengekspor model. Secara khusus, pastikan bahwa performa model wajar untuk data yang ditahan. Atau, jika Anda memiliki Jika masih ada masalah dengan data, jangan ekspor model. Banyak tim model yang terus di-deploy, periksa area di bawah Kurva KOP (atau AUC) sebelum mengekspor. Masalah tentang model yang belum diekspor memerlukan pemberitahuan email, tetapi masalah pada model yang ditampilkan kepada pengguna mungkin memerlukan halaman. Jadi lebih baik untuk menunggu dan yakin sebelum mempengaruhi pengguna.

Aturan #10: Perhatikan kegagalan senyap.

Ini adalah masalah yang lebih sering terjadi pada sistem machine learning daripada jenis-jenis sistem. Misalkan tabel tertentu yang digabungkan tidak diperbarui lagi. Sistem machine learning akan menyesuaikan dan berperilaku akan terus berjalan cukup baik, menurun secara bertahap. Terkadang Anda mendapati tabel yang sudah tidak berlaku selama beberapa bulan, dan pembaruan sederhana meningkatkan performa lebih banyak daripada peluncuran lainnya pada kuartal itu! Cakupan fitur dapat berubah karena perubahan implementasi: misalnya kolom fitur dapat diisi pada 90% contoh, dan tiba-tiba turun menjadi 60% contoh. Play pernah memiliki meja yang basi selama 6 bulan, dan menyegarkan tabel itu saja memberikan peningkatan 2% dalam rasio instal. Jika Anda melacak statistik dari serta memeriksa data secara manual sesekali, Anda dapat mengurangi kegagalan semacam ini.

Aturan #11: Berikan pemilik dan dokumentasi kolom fitur.

Jika sistemnya besar, dan ada banyak kolom fitur, ketahui siapa yang membuatnya atau mempertahankan setiap kolom fitur. Jika Anda menemukan bahwa orang yang memahami kolom fitur yang keluar, pastikan seseorang memiliki tidak akurat atau tidak sesuai. Meskipun banyak kolom fitur memiliki nama deskriptif, hal itu baik untuk memiliki deskripsi yang lebih rinci tentang apa fiturnya, dari mana asalnya dan bagaimana hal itu diharapkan dapat membantu.

Tujuan Pertama Anda

Anda memiliki banyak metrik, atau pengukuran tentang sistem yang penting bagi Anda, tetapi algoritma machine learning Anda sering kali memerlukan satu tujuan, angka yang menunjukkan bahwa algoritma Anda sedang “mencoba” untuk dioptimalkan. Saya mengerti di sini antara tujuan dan metrik: metrik adalah angka yang yang mungkin penting atau tidak penting. Lihat juga Aturan #2.

Aturan #12: Jangan terlalu memikirkan tujuan mana yang Anda pilih untuk dioptimalkan secara langsung.

Anda ingin menghasilkan uang, membuat pengguna Anda senang, dan membuat dunia menjadi lebih baik saat ini. Ada banyak metrik yang penting bagi Anda, dan Anda harus mengukur semuanya (lihat Aturan #2). Namun, di awal proses {i>machine learning<i}, Anda akan melihat semuanya meningkat, bahkan yang tidak Anda optimalkan secara langsung. Misalnya, anggaplah Anda peduli tentang jumlah klik dan waktu yang dihabiskan di situs. Jika Anda mengoptimalkan jumlah klik, waktu yang dihabiskan cenderung meningkat.

Jadi, tetap sederhana dan jangan berpikir terlalu keras untuk menyeimbangkan berbagai metrik ketika Anda masih dapat meningkatkan semua metrik dengan mudah. Jangan gunakan aturan ini juga sejauh ini: jangan mengacaukan tujuan Anda dengan kondisi kesehatan akhir sistem (lihat Aturan #39). Dan, jika Anda langsung meningkatkan metrik yang dioptimalkan, tetapi memutuskan untuk tidak meluncurkannya, beberapa revisi tidak diperlukan.

Aturan #13: Pilih metrik yang sederhana, dapat diamati, dan dapat diatribusikan untuk tujuan pertama Anda.

Sering kali Anda tidak tahu apa tujuan sebenarnya. Anda pikir Anda pernah melakukannya tetapi kemudian ketika Anda melihat data dan analisis sistem lama dan ML baru Anda secara berdampingan sistem, Anda menyadari bahwa Anda ingin menyesuaikan tujuannya. Selain itu, tim yang berbeda sering kali para anggotanya tidak sepakat tentang tujuan yang sebenarnya. Tujuan ML harus sesuatu yang mudah diukur dan merupakan {i>proxy<i} untuk "{i>true<i}" bisnis. Faktanya, sering kali tidak ada yang “benar” objektif (lihat Aturan#39). Namun melatih tujuan ML sederhana, dan mempertimbangkan untuk menggunakan "lapisan kebijakan" di atas yang memungkinkan Anda menambahkan logika tambahan (semoga logika yang sangat sederhana) untuk dilakukan peringkat akhir.

Hal termudah untuk dimodelkan adalah perilaku pengguna yang secara langsung diamati dan disebabkan oleh tindakan sistem:

  • Apakah link yang diberi peringkat ini diklik?
  • Apakah objek yang diberi peringkat ini didownload?
  • Apakah objek yang diberi peringkat ini diteruskan/dibalas ke/dikirim melalui email?
  • Apakah objek yang diberi peringkat ini diberi rating?
  • Apakah objek yang ditampilkan ini ditandai sebagai spam/pornografi/menyinggung?

Hindari pemodelan efek tidak langsung terlebih dahulu:

  • Apakah pengguna berkunjung pada hari berikutnya?
  • Berapa lama pengguna mengunjungi situs?
  • Berapa pengguna aktif harian?

Efek tidak langsung menghasilkan metrik yang bagus, dan dapat digunakan selama pengujian A/B dan selama peluncuran keputusan penting.

Terakhir, jangan membuat machine learning untuk mencari tahu:

  • Apakah pengguna senang menggunakan produk itu?
  • Apakah pengguna puas dengan pengalaman tersebut?
  • Apakah produk tersebut meningkatkan kesehatan pengguna secara keseluruhan?
  • Bagaimana hal ini akan mempengaruhi kesehatan perusahaan secara keseluruhan?

Ini semua penting, tetapi juga sangat sulit untuk diukur. Sebagai gantinya, gunakan {i>proxy<i}: jika pengguna senang, mereka akan tetap berada di situs lebih lama. Jika pengguna puas, mereka akan berkunjung lagi besok. Sejauh kesejahteraan dan kesehatan perusahaan, diperlukan penilaian manual untuk menghubungkan tujuan machine learning ke sifat produk yang Anda jual dan rencana bisnis Anda.

Aturan #14: Memulai dengan model yang dapat ditafsirkan akan mempermudah proses debug.

Regresi linear, regresi logistik, dan regresi Poisson bersifat langsung dimotivasi oleh model probabilistik. Setiap prediksi dapat ditafsirkan sebagai probabilitas atau nilai yang diharapkan. Hal ini membuatnya lebih mudah di-debug daripada model yang menggunakan objektif (nol-satu kerugian, berbagai kerugian engsel, dan sebagainya) yang mencoba untuk langsung mengoptimalkan akurasi klasifikasi atau performa peringkat. Sebagai misalnya, jika probabilitas dalam pelatihan menyimpang dari probabilitas yang diprediksi dalam secara berdampingan atau dengan memeriksa sistem produksi, penyimpangan ini bisa mengungkapkan suatu masalah.

Misalnya, dalam regresi linear, logistik, atau Poisson, ada subset dari data di mana rata-rata harapan yang diprediksi sama dengan label rata-rata (1- dikalibrasi, atau hanya dikalibrasi). Hal ini benar dengan asumsi bahwa Anda tidak memiliki dan bahwa algoritma Anda telah terkonvergensi, dan kira-kira benar secara umum. Jika Anda memiliki fitur yang bernilai 1 atau 0 untuk setiap contoh, lalu kumpulan 3 contoh di mana fitur tersebut adalah 1 dikalibrasi. Selain itu, jika Anda memiliki fitur yaitu 1 untuk setiap contoh, maka himpunan dari semua contoh adalah dikalibrasi.

Dengan model yang sederhana, lebih mudah untuk menangani feedback loop (lihat Aturan #36). Sering kali, kami menggunakan prediksi probabilistik ini untuk membuat keputusan: mis. peringkat postingan dalam menurunkan nilai yang diharapkan (yaitu probabilitas klik/download/dll.). Namun, saat tiba waktunya untuk memilih model yang akan digunakan, keputusan lebih penting daripada kemungkinan data diberikan model (lihat Aturan #27).

Aturan #15: Pisahkan Pemfilteran Spam dan Peringkat Kualitas di Lapisan Kebijakan.

Peringkat kualitas itu bagus, tetapi pemfilteran spam adalah perang. Tanda-tanda yang menunjukkan yang Anda gunakan untuk menentukan postingan berkualitas tinggi akan terlihat jelas bagi mereka yang sistem Anda, dan mereka akan menyesuaikan postingan mereka agar memiliki properti ini. Dengan demikian, peringkat kualitas Anda harus berfokus pada peringkat konten yang diposting dengan iman. Anda tidak boleh mengabaikan siswa peringkat kualitas untuk spam peringkat sangat tinggi. Demikian pula, "tidak pantas" konten harus ditangani secara terpisah dari bagian Kualitas Peringkat. Pemfilteran spam adalah hal yang berbeda. Anda harus memperkirakan bahwa fitur yang perlu Anda buat akan terus berubah. Sering kali, ada akan menjadi aturan yang jelas yang Anda masukkan ke dalam sistem (jika sebuah postingan memiliki lebih dari tiga suara spam, jangan mengambilnya, dan lain-lain). Setiap model yang dipelajari akan memiliki diperbarui setiap hari, atau bahkan lebih cepat. Reputasi pembuat konten akan memainkan peran penting.

Pada level tertentu, output dari kedua sistem ini harus diintegrasikan. Pertahankan Perlu diingat, memfilter spam di hasil penelusuran seharusnya lebih agresif, daripada memfilter spam di pesan email. Selain itu, adalah praktik standar untuk menghilangkan spam dari data pelatihan untuk pengklasifikasi kualitas.

ML Tahap II: Rekayasa Fitur

Pada fase pertama siklus proses sistem machine learning, penting adalah memasukkan data pelatihan ke dalam sistem pembelajaran, mendapatkan metrik kepentingan yang diinstrumentasikan, dan membuat infrastruktur penayangan. Setelah Anda memiliki sistem yang berfungsi menyeluruh dengan pengujian unit dan sistem berinstrumen, Tahap II dimulai.

Pada fase kedua, ada banyak hal yang bergantung pada hasil. Ada berbagai fitur umum yang dapat dimasukkan ke dalam sistem. Jadi, yang kedua di fase machine learning, kita harus menarik sebanyak mungkin fitur dan menggabungkannya secara intuitif. Selama fase ini, semua metrik harus masih meningkat. Akan ada banyak peluncuran, dan ini adalah saat yang tepat untuk melibatkan banyak insinyur yang dapat menggabungkan semua data yang Anda butuhkan untuk membuat sistem pembelajaran yang benar-benar mengagumkan.

Aturan #16: Rencanakan peluncuran dan iterasi.

Jangan berharap model yang Anda kerjakan sekarang akan menjadi model terakhir yang yang akan diluncurkan, atau bahkan Anda akan berhenti meluncurkan model. Jadi pertimbangkan apakah kompleksitas yang Anda tambahkan dengan peluncuran ini akan melambat peluncuran produk di masa mendatang. Banyak tim telah meluncurkan model per kuartal atau lebih untuk bertahun-tahun. Ada tiga alasan dasar untuk meluncurkan model baru:

  • Anda akan membuat fitur baru.
  • Anda menyesuaikan regularisasi dan menggabungkan fitur lama dengan cara baru.
  • Anda sedang menyesuaikan tujuan.

Terlepas dari itu, memberikan sedikit kasih sayang pada model bisa menjadi hal yang baik: melihat data memasukkan data ke dalam contoh dapat membantu menemukan sinyal baru serta sinyal lama yang rusak satu. Jadi, saat Anda membangun model, pikirkan betapa mudahnya menambah atau menghapus atau menggabungkan ulang fitur. Pikirkan tentang betapa mudahnya membuat salinan baru dari pipeline dan memverifikasi ketepatannya. Pikirkan tentang apakah mungkin untuk memiliki dua atau tiga salinan yang berjalan secara paralel. Terakhir, jangan khawatir tentang apakah fitur 16 dari 35 masuk ke dalam versi saluran ini. Anda akan capai di kuartal berikutnya.

Aturan #17: Mulai dengan fitur yang diamati dan dilaporkan secara langsung, bukan fitur yang dipelajari.

Hal ini mungkin menjadi poin yang kontroversial, tetapi dapat menghindari banyak kesalahan. Pertama dari mari kita jelaskan apa yang dimaksud dengan fitur yang dipelajari. Fitur yang dipelajari adalah fitur dihasilkan oleh sistem eksternal (seperti unsupervised clustering sistem) atau oleh pelajar itu sendiri (mis. melalui model faktor atau deep learning). Keduanya berguna, tetapi mereka bisa memiliki banyak masalah, jadi seharusnya bukan model pertama.

Jika Anda menggunakan sistem eksternal untuk membuat fitur, ingatlah bahwa file memiliki tujuannya sendiri. Tujuan sistem eksternal mungkin hanya lemah berkorelasi dengan tujuan Anda saat ini. Jika Anda mengambil snapshot maka sistem bisa menjadi usang. Jika Anda mengupdate fitur dari sistem eksternal, maka maknanya dapat berubah. Jika Anda menggunakan sistem eksternal untuk menyediakan fitur, perlu diketahui bahwa pendekatan ini memerlukan kehati-hatian yang tinggi.

Masalah utama pada model terfaktorkan dan model mendalam adalah keduanya non-konveks. Oleh karena itu, tidak ada jaminan bahwa solusi yang optimal dapat diperkirakan atau ditemukan, dan nilai minimum lokal yang ditemukan pada setiap iterasi dapat berbeda. Variasi ini menyulitkan untuk menilai apakah dampak dari perubahan ke sistem Anda bermakna atau acak. Dengan membuat model tanpa lebih mendalam, Anda bisa mendapatkan performa dasar pengukuran yang sangat baik. Setelahnya dasar tercapai, Anda dapat mencoba pendekatan yang lebih esoterik.

Aturan #18: Lakukan eksplorasi dengan fitur konten yang menggeneralisasi di seluruh konteks.

Sering kali sistem machine learning adalah bagian kecil dari gambaran yang jauh lebih besar. Sebagai misalnya, jika Anda membayangkan postingan yang mungkin digunakan di Lagi Ngetren, banyak orang akan memberi plus satu, membagikan ulang, atau mengomentari postingan sebelum postingan tersebut ditampilkan di Yang Panas. Jika Anda memberikan statistik tersebut kepada peserta, statistik tersebut dapat mempromosikan postingan baru yang tidak memiliki data dalam konteks yang dioptimalkan. YouTube Tonton Berikutnya dapat menggunakan jumlah tontonan, atau tontonan (jumlah berapa kali satu video ditonton setelah video lainnya ditonton) dari penelusuran YouTube. Anda juga bisa menggunakan penilaian pengguna. Terakhir, jika Anda memiliki tindakan pengguna yang Anda gunakan sebagai label, melihat tindakan pada dokumen dalam konteks yang berbeda bisa menjadi aplikasi baru. Semua fitur ini memungkinkan Anda menghadirkan konten baru ke dalam konteks. Perhatikan bahwa ini bukan tentang personalisasi: cari tahu apakah seseorang menyukai konten dalam konteks ini terlebih dahulu, lalu cari tahu siapa yang lebih menyukainya atau kurang.

Aturan #19: Gunakan fitur yang sangat spesifik jika memungkinkan.

Dengan data yang sangat banyak, akan lebih mudah untuk mempelajari jutaan fitur sederhana daripada beberapa fitur kompleks. ID dokumen yang sedang diambil dan Kueri yang dikanonikalisasi tidak memberikan banyak generalisasi, namun menyelaraskan peringkat dengan label Anda pada kueri head. Jadi, jangan takut dengan kelompok fitur di mana setiap fitur berlaku untuk sebagian kecil data Anda, tetapi cakupan keseluruhan di atas 90%. Anda dapat menggunakan regularisasi untuk menghilangkan fitur yang hanya berlaku untuk contoh yang terlalu sedikit.

Aturan #20: Gabungkan dan modifikasi fitur yang ada untuk membuat fitur baru dengan cara yang dapat dipahami manusia.

Ada berbagai cara untuk mengombinasikan dan memodifikasi fitur. {i>Machine learning<i} seperti TensorFlow memungkinkan Anda untuk melakukan pra-pemrosesan data transformasi. Dua pendekatan yang paling standar adalah "diskretisasi" dan "silang".

Diskretisasi terdiri dari mengambil fitur yang berkelanjutan dan membuat banyak fitur diskret darinya. Pertimbangkan fitur berkelanjutan seperti usia. Anda dapat membuat fitur yaitu 1 jika usianya kurang dari 18 tahun, fitur lain yang 1 ketika usia antara 18 dan 35, dan lain-lain. Jangan terlalu memikirkan batasan histogram ini: kuantil dasar akan memberi Anda sebagian besar dampaknya.

Persilangan menggabungkan dua kolom fitur atau lebih. Kolom fitur, di ID adalah sekumpulan fitur yang homogen, (mis. {male, girl}, {US, Kanada, Meksiko}, dan sebagainya). Tanda silang adalah kolom fitur baru dengan fitur di, misalnya, {male, girl} × {US,Canada, Mexico}. Kolom fitur baru ini akan berisi fitur tersebut (laki-laki, Kanada). Jika Anda menggunakan TensorFlow dan memberi tahu TensorFlow untuk membuatkan salib ini untuk Anda, fitur (laki-laki, Kanada) ini akan ada dalam contoh yang mewakili laki-laki Kanada. Perlu diketahui bahwa diperlukan jumlah data untuk mempelajari model dengan persilangan tiga, empat, atau lebih kolom fitur.

Persilangan yang menghasilkan kolom fitur yang sangat besar dapat kelebihan beban. Contohnya, bayangkan Anda melakukan semacam pencarian, dan Anda memiliki kolom fitur dengan kata dalam kueri, dan Anda memiliki kolom fitur dengan kata-kata di dokumen. Anda dapat menggabungkannya dengan tanda silang, tetapi Anda akan mendapatkan banyak fitur (lihat Aturan #21).

Saat bekerja dengan teks, ada dua alternatif. Yang paling kejam adalah dot product. Produk titik dalam bentuknya yang paling sederhana menghitung jumlah kata-kata yang sama antara kueri dan dokumen. Fitur ini kemudian dapat terdiskresi. Pendekatan lainnya adalah persimpangan: jadi, kita akan memiliki fitur yang ada jika dan hanya jika kata "{i>pony<i}" ada di dokumen dan {i>query<i}, dan fitur lain yang ada jika dan hanya jika kata "{i>the<i}" ada di dalam baik dokumen maupun kueri.

Aturan #21: Jumlah bobot fitur yang dapat Anda pelajari dalam model linear kira-kira sebanding dengan jumlah data yang Anda miliki.

Ada hasil teori pembelajaran statistik yang menarik mengenai sesuai dengan tingkat kompleksitas model, tetapi pada dasarnya aturan ini yang perlu Anda ketahui. Saya pernah melakukan percakapan yang membuat orang meragukan apa pun bisa dipelajari dari seribu contoh, atau bahkan Anda memerlukan lebih dari satu juta contoh, karena mereka terjebak dalam metode tertentu dari pembelajaran. Kuncinya adalah menskalakan pembelajaran Anda ke ukuran data Anda:

  1. Jika Anda menggunakan sistem peringkat penelusuran, dan ada jutaan kata yang berbeda dalam dokumen dan kueri dan Anda memiliki 1.000 contoh berlabel, maka Anda harus menggunakan produk titik di antara dokumen dan fitur kueri, TF-IDF, dan setengah lusin teknologi teknologi canggih lainnya baru. 1.000 contoh, belasan fitur.
  2. Jika Anda memiliki satu juta contoh, maka persilakan antara dokumen dan kueri kolom fitur, menggunakan regularisasi dan kemungkinan pemilihan fitur. Ini akan memberi Anda jutaan fitur, tetapi dengan regularisasi, Anda akan memiliki lebih sedikit. Sepuluh juta contoh, mungkin seratus ribu fitur.
  3. Jika Anda memiliki miliaran atau ratusan miliar contoh, Anda bisa kolom fitur dengan token dokumen dan kueri, menggunakan pemilihan fitur dan regularisasi. Anda akan memiliki satu miliar contoh, dan 10 juta baru. Teori pembelajaran statistik jarang memberikan batasan ketat, tetapi memberikan panduan yang bagus untuk memulai.

Pada akhirnya, gunakan Aturan #28 untuk memutuskan fitur apa yang akan digunakan.

Aturan #22: Bersihkan fitur yang tidak lagi Anda gunakan.

Fitur yang tidak digunakan menimbulkan utang teknis. Jika Anda ternyata tidak menggunakan tambahan, dan bahwa menggabungkannya dengan fitur lain tidak akan berfungsi, maka lepaskan dari infrastruktur Anda. Anda ingin menjaga infrastruktur Anda tetap bersih sehingga bahwa fitur yang paling menjanjikan dapat dicoba secepat mungkin. Jika diperlukan, seseorang dapat selalu menambahkan kembali fitur Anda.

Ingatlah cakupan saat mempertimbangkan fitur apa yang perlu ditambahkan atau dipertahankan. Berapa banyak yang tercakup dalam fitur tersebut? Misalnya, jika Anda memiliki fitur personalisasi, tetapi hanya 8% pengguna Anda yang memiliki fiturnya, itu tidak akan terlalu efektif.

Pada saat yang sama, beberapa fitur mungkin melebihi bobotnya. Misalnya, jika Anda memiliki fitur yang hanya mencakup 1% data, tetapi 90% contoh yang memiliki fitur positif, maka itu akan menjadi fitur hebat untuk ditambahkan.

Analisis Sistem oleh Manusia

Sebelum berlanjut ke fase ketiga machine learning, Anda harus berfokus pada sesuatu yang tidak diajarkan di kelas machine learning mana pun: bagaimana melihat model yang ada, dan meningkatkannya. Ini lebih mirip seni daripada sains, namun ada beberapa antipola yang dapat dihindarinya.

Aturan #23: Anda bukan pengguna akhir biasa.

Mungkin ini adalah cara termudah bagi sebuah tim untuk terjebak. Meskipun ada banyak manfaat dari {i>fishfooding<i} (menggunakan prototipe dalam tim Anda) dan {i>dogfooding<i} (menggunakan prototipe di dalam perusahaan Anda), karyawan harus melihat apakah performanya benar. Meskipun sebuah perubahan yang jelas buruk tidak boleh digunakan, apa pun yang terlihat cukup dekat dengan produksi harus diuji lebih jauh, baik dengan membayar orang awam untuk menjawab pertanyaan tentang crowdsource, atau melalui eksperimen langsung pada pengguna nyata.

Ada dua alasan untuk ini. Yang pertama adalah bahwa Anda terlalu dekat dengan pada kode sumber. Anda mungkin mencari aspek tertentu dari postingan, atau Anda terlalu terlibat secara emosional (misalnya bias konfirmasi). Yang kedua adalah waktu Anda terlalu berharga. Pertimbangkan biaya sembilan insinyur yang bekerja dalam satu pertemuan jam, dan pikirkan berapa banyak label manusia yang dikontrak yang membeli pada platform crowdsource.

Jika Anda benar-benar ingin mendapatkan masukan pengguna, gunakan pengalaman pengguna metodologi. Buat persona pengguna (satu deskripsi ada dalam Membuat Sketsa Pengalaman Pengguna) di awal proses dan melakukan uji coba {i>usability<i} (salah satu deskripsinya ada dalam karya Steve Krug Jangan Buat Saya berpikir) nanti. Persona pengguna yang melibatkan pembuatan hipotesis. Misalnya, jika tim Anda semuanya laki-laki, mungkin membantu untuk merancang persona pengguna wanita berusia 35 tahun (lengkap dengan fitur), dan melihat hasil yang dihasilkannya, bukan 10 hasil untuk Laki-laki berusia 25-40 tahun. Mengundang orang-orang yang sebenarnya untuk menonton reaksi mereka terhadap situs Anda (secara lokal atau jarak jauh) dalam pengujian kegunaan juga dapat memberi Anda perspektif Anda.

Aturan #24: Mengukur delta antarmodel.

Salah satu pengukuran yang paling mudah dan terkadang paling berguna yang dapat Anda lakukan sebelum pengguna melihat model baru Anda adalah untuk menghitung seberapa berbeda hasil baru berasal dari produksi. Misalnya, jika Anda memiliki masalah peringkat, menjalankan kedua model pada sampel kueri di seluruh sistem, dan melihat ukuran perbedaan simetris dari hasil (dibobot berdasarkan peringkat ). Jika perbedaannya sangat kecil, maka Anda dapat mengetahui tanpa menjalankan eksperimen bahwa akan ada sedikit perubahan. Jika perbedaannya sangat besar, maka Anda ingin memastikan bahwa perubahannya bagus. Melihat kueri di mana perbedaan simetrisnya tinggi dapat membantu Anda memahami seperti apa perubahannya. Namun, pastikan bahwa sistem stabil. Pastikan bahwa bila dibandingkan dengan model itu sendiri, memiliki rasio yang rendah (idealnya nol) perbedaan simetris.

Aturan #25: Ketika memilih model, performa fungsional mengalahkan kekuatan prediktif.

Model Anda mungkin mencoba memprediksi rasio klik-tayang. Namun, pada akhirnya, kunci adalah apa yang Anda lakukan dengan prediksi itu. Jika Anda menggunakannya untuk menentukan peringkat dokumen, maka kualitas peringkat akhir lebih penting daripada prediksi itu sendiri. Jika Anda memprediksi kemungkinan bahwa suatu dokumen adalah spam dan memiliki batas waktu pada apa yang diblokir, maka ketepatan apa yang diizinkan melalui masalah yang lebih penting. Sering kali, kedua hal ini harus ada dalam perjanjian: ketika mereka tidak setuju, mereka cenderung hanya mendapatkan keuntungan kecil. Jadi, jika ada beberapa perubahan yang meningkatkan hilangnya log tetapi menurunkan kinerja sistem, cari fitur lain. Ketika hal ini mulai terjadi lebih sering, sekarang saatnya meninjau kembali tujuan model Anda.

Aturan #26: Cari pola pada error terukur, dan buat fitur baru.

Misalkan Anda melihat contoh pelatihan yang modelnya "salah". Di klasifikasi, {i>error <i}ini bisa berupa positif palsu atau negatif palsu (NP). Dalam tugas pemberian peringkat, errornya bisa berupa pasangan yang peringkat positifnya lebih rendah daripada negatif. Poin yang paling penting adalah ini adalah contoh machine learning tahu bahwa kesalahannya ada dan ingin memperbaikinya jika diberi peluang. Jika Anda memberi model itu fitur yang memungkinkannya memperbaiki kesalahan, model akan mencoba menggunakannya.

Di sisi lain, jika Anda mencoba membuat fitur berdasarkan contoh tidak dianggap oleh sistem sebagai kesalahan, fitur tersebut akan diabaikan oleh sistem. Contohnya, anggap saja di Penelusuran Aplikasi Play, seseorang menelusuri "game gratis". Misalkan salah satu hasil teratas adalah aplikasi gag yang kurang relevan. Jadi Anda membuat fitur untuk "aplikasi gag". Namun, jika Anda memaksimalkan jumlah instal, dan pengguna menginstal aplikasi gag saat mereka menelusuri game gratis, "aplikasi gag" fitur tidak akan mendapatkan efek yang Anda inginkan.

Setelah Anda memiliki contoh bahwa model keliru, carilah tren yang di luar set fitur Anda saat ini. Misalnya, jika sistem tampaknya mendemosikan postingan yang lebih panjang, lalu menambahkan panjang postingan. Jangan terlalu spesifik tentang fitur yang Anda tambahkan. Jika Anda akan menambahkan panjang postingan, jangan coba menebak artinya, cukup tambahkan selusin fitur dan model akan mencari tahu apa yang harus dilakukan dengan mereka (lihat Aturan #21 ). Itu adalah cara termudah untuk mendapatkan apa yang Anda inginkan.

Aturan #27: Coba ukur perilaku yang tidak diinginkan yang diamati.

Beberapa anggota tim Anda akan mulai frustrasi dengan properti mereka sukai yang tidak ditangkap oleh fungsi kerugian yang ada. Di hingga titik ini, mereka harus melakukan apa pun untuk mengubah cengkeraman mereka menjadi angka. Misalnya, jika mereka merasa terlalu banyak "aplikasi lelucon" ditampilkan di Penelusuran Play, mereka dapat meminta penilai manusia untuk mengidentifikasi aplikasi lelucon. (Anda dapat layak menggunakan data berlabel manusia dalam kasus ini karena ukuran yang relatif kecil sebagian kecil kueri diperhitungkan untuk sebagian besar traffic.) Jika masalah dapat diukur, maka Anda dapat mulai menggunakannya sebagai fitur, tujuan, atau metrik. Aturan umumnya adalah "ukur pertama, optimalkan kedua".

Aturan #28: Ketahuilah bahwa perilaku jangka pendek yang identik tidak menyiratkan perilaku jangka panjang yang identik.

Bayangkan Anda memiliki sistem baru yang melihat setiap {i>doc_id<i} dan {i>exact_query<i}, dan kemudian menghitung probabilitas klik untuk setiap dokumen untuk setiap kueri. Anda menemukan bahwa perilakunya hampir identik dengan sistem Anda saat ini di berdampingan dan pengujian A/B, jadi mengingat kemudahannya, Anda meluncurkannya. Namun, Anda melihat bahwa tidak ada aplikasi baru yang ditampilkan. Mengapa? Karena sistem hanya menunjukkan dokumen berdasarkan riwayatnya sendiri dengan kueri tersebut, cara untuk mengetahui bahwa dokumen baru harus ditampilkan.

Satu-satunya cara untuk memahami bagaimana sistem itu akan bekerja dalam jangka panjang adalah dengan model hanya dilatih pada data yang diperoleh saat model aktif. Hal ini sangat sulit.

Kemiringan Penyajian Pelatihan

Diferensiasi performa pelatihan dan penayangan adalah perbedaan antara performa selama pelatihan dan performa selama penayangan. Kemiringan ini dapat disebabkan oleh:

  • Perbedaan antara cara Anda menangani data dalam pipeline pelatihan dan inferensi.
  • Perubahan data antara saat Anda melatih dan saat Anda melayani.
  • Feedback loop antara model dan algoritma Anda.

Kami telah mengamati sistem machine learning produksi di Google dengan pelatihan- kecondongan penayangan yang berdampak negatif terhadap performa. Solusi terbaik adalah memantaunya secara eksplisit sehingga perubahan sistem dan data tidak menimbulkan bias tidak diperhatikan.

Aturan #29: Cara terbaik untuk memastikan bahwa Anda berlatih seperti Anda melayani adalah dengan menyimpan seperangkat fitur yang digunakan pada waktu inferensi, lalu menyalurkan fitur tersebut ke log untuk digunakan pada waktu pelatihan.

Bahkan jika Anda tidak dapat melakukan ini untuk setiap contoh, lakukan untuk sebagian kecil, misalnya Anda dapat memverifikasi konsistensi antara penayangan dan pelatihan (lihat Aturan #37). Tim yang telah melakukan hal ini pengukuran di Google terkadang terkejut dengan hasilnya. Halaman beranda YouTube beralih ke fitur logging pada waktu inferensi dengan kualitas peningkatan dan pengurangan kompleksitas kode, dan banyak tim beralih infrastruktur mereka.

Aturan #30: Data sampel dengan bobot penting, jangan sembarangan menjatuhkannya.

Ketika Anda memiliki terlalu banyak data, ada godaan untuk mengambil file 1-12, dan mengabaikan file 13-99. Ini adalah kesalahan. Meskipun data yang tidak pernah ditampilkan kepada pengguna bisa diabaikan, pembobotan urgensi adalah yang terbaik untuk beristirahat. Pembobotan kepentingan berarti bahwa jika Anda memutuskan bahwa Anda akan contoh sampel X dengan probabilitas 30%, kemudian berikan bobot 10/3. Dengan semua properti kalibrasi yang dibahas dalam Aturan #14 masih tersedia.

Aturan #31: Berhati-hatilah jika Anda menggabungkan data dari tabel pada waktu pelatihan dan inferensi, data dalam tabel tersebut dapat berubah.

Misalnya, Anda menggabungkan ID dokumen dengan tabel yang berisi beberapa fitur untuk dokumen tersebut (seperti jumlah komentar atau klik). Di antara waktu pelatihan dan penayangan, fitur di tabel mungkin diubah. Prediksi model untuk dokumen yang sama mungkin kemudian bisa berbeda antara pelatihan dan penyaluran. Cara termudah untuk menghindari pengurutan ini masalah adalah mencatat fitur pada waktu inferensi (lihat Aturan #32 ). Jika tabel adalah berubah secara perlahan, Anda juga dapat mengambil {i>snapshot<i} tabel setiap jam atau setiap hari untuk mendapatkan data yang cukup mendekati. Perhatikan bahwa cara ini tidak sepenuhnya menyelesaikan masalah performa.

Aturan #32: Gunakan kembali kode di antara pipeline pelatihan dan pipeline inferensi Anda jika memungkinkan.

Batch processing berbeda dengan pemrosesan online. Dalam pemrosesan {i>online<i}, Anda harus menangani setiap permintaan saat diterima (misalnya, Anda harus melakukan pencarian terpisah untuk setiap kueri), sedangkan dalam batch processing, Anda bisa menggabungkan tugas (misalnya membuat {i>join<i}). Pada waktu inferensi, Anda melakukan pemrosesan online, sedangkan adalah tugas batch processing. Namun, ada beberapa hal yang lakukan untuk menggunakan kembali kode. Misalnya, Anda dapat membuat objek yang khusus untuk sistem Anda di mana hasil dari semua kueri atau gabungan dapat disimpan dengan cara yang sangat mudah dibaca manusia, dan kesalahan dapat diuji dengan mudah. Lalu: setelah mengumpulkan semua informasi, selama inferensi atau pelatihan, Anda menjalankan metode umum untuk menjembatani antara objek yang dapat dibaca khusus untuk sistem Anda, dan format apa pun yang ada di sistem {i>machine learning<i} yang diharapkan. Tindakan ini akan menghilangkan sumber diferensiasi performa pelatihan dan penayangan. Sebagai seorang mungkin, cobalah untuk tidak menggunakan dua bahasa pemrograman yang berbeda di antara pelatihan dan penyaluran produk. Keputusan itu akan membuat hampir tidak mungkin bagi Anda untuk pada kode sumber.

Aturan #33: Jika Anda menghasilkan model berdasarkan data hingga 5 Januari, uji model tersebut dengan data dari tanggal 6 Januari dan setelahnya.

Secara umum, ukur performa model pada data yang dikumpulkan setelah data sebagai tempat pelatihan model, karena ini mencerminkan apa yang akan dilakukan sistem Anda dalam produksi. Jika Anda menghasilkan model berdasarkan data hingga 5 Januari, uji model pada data sejak 6 Januari. Anda akan mengharapkan bahwa performa tidak akan terlalu bagus untuk data yang baru, tetapi seharusnya tidak terlalu buruk. Karena mungkin terdapat efek harian, Anda mungkin tidak memprediksi klik rata-rata atau tingkat konversi, tetapi area di bawah kurva, yang mewakili kemungkinan memberikan skor yang lebih tinggi pada contoh positif daripada negatif misalnya, harus cukup mendekati.

Aturan #34: Dalam klasifikasi biner untuk pemfilteran (seperti deteksi spam atau penentuan email yang menarik), buat pengorbanan jangka pendek kecil dalam kinerja untuk data yang sangat bersih.

Dalam tugas pemfilteran, contoh yang ditandai sebagai negatif tidak ditampilkan kepada pengguna. Misalkan Anda memiliki filter yang memblokir 75% contoh negatif pada saat inferensi. Anda mungkin tergoda untuk menggambar data pelatihan tambahan dari instance yang ditampilkan kepada pengguna. Misalnya, jika pengguna menandai email sebagai spam yang filter Anda lolos, Anda mungkin ingin belajar dari hal itu.

Namun, pendekatan ini memunculkan bias {i>sampling<i}. Anda dapat mengumpulkan data yang lebih bersih jika selama penayangan, beri label 1% dari semua traffic sebagai "dihentikan", dan kirim semua memberikan contoh kepada pengguna. Kini filter Anda memblokir setidaknya 74% contoh negatif. Contoh yang ditahan ini dapat menjadi data pelatihan Anda.

Perhatikan bahwa jika filter Anda memblokir 95% contoh negatif atau lebih, menjadi kurang layak. Meski begitu, jika Anda ingin mengukur penayangan, kinerja yang lebih baik, Anda dapat membuat sampel yang lebih kecil (misalnya 0,1% atau 0,001%). Sepuluh seribu contoh sudah cukup untuk memperkirakan kinerja dengan cukup akurat.

Aturan #35: Waspadai kecondongan yang melekat dalam masalah peringkat.

Saat mengubah algoritma peringkat secara drastis sehingga hasil yang berbeda muncul, Anda telah secara efektif mengubah data yang akan dihasilkan algoritma Anda lihat di masa mendatang. Kemiringan semacam ini akan muncul, dan Anda harus mendesain model di sekitarnya. Ada beberapa pendekatan yang berbeda. Pendekatan ini adalah segala cara untuk mendukung data yang telah dilihat model Anda.

  1. Memiliki regularisasi yang lebih tinggi pada fitur yang mencakup lebih banyak kueri daripada fitur-fitur yang hanya aktif untuk satu kueri. Dengan cara ini, model akan mengutamakan fitur yang khusus untuk satu atau beberapa kueri atas fitur yang melakukan generalisasi terhadap semua kueri. Pendekatan ini dapat membantu mencegah munculnya hasil dari kebocoran ke kueri yang tidak relevan. Perhatikan bahwa hal ini berlawanan dengan saran yang lebih konvensional untuk memiliki lebih banyak regularisasi pada kolom fitur dengan lebih banyak nilai yang unik.
  2. Hanya izinkan fitur untuk memiliki bobot positif. Dengan demikian, setiap fitur yang baik akan lebih baik daripada fitur yang "tidak diketahui".
  3. Tidak memiliki fitur khusus dokumen. Ini adalah versi ekstrem dari #1. Sebagai meskipun aplikasi tertentu merupakan download populer, terlepas dari apa pun sebelumnya, Anda tidak ingin menampilkannya di mana-mana. Tidak memiliki akses khusus dokumen fitur tersebut tetap sederhana. Alasan Anda tidak ingin menampilkan yang populer di mana pun berkaitan dengan pentingnya membuat semua aplikasi yang diinginkan dapat dijangkau. Misalnya, jika seseorang menelusuri "aplikasi pengamatan burung", mereka mungkin mengunduh "burung marah", tetapi tentu saja bukanlah maksud mereka. Menampilkan aplikasi semacam itu dapat meningkatkan rasio download, tetapi meninggalkan kebutuhan pengguna yang pada akhirnya tidak terpuaskan.

Aturan #36: Menghindari feedback loop dengan fitur posisi.

Posisi konten sangat memengaruhi seberapa besar kemungkinan pengguna untuk berinteraksi dengannya. Jika Anda menempatkan aplikasi di posisi pertama, aplikasi akan lebih sering diklik, dan Anda akan yakin bahwa iklan tersebut lebih mungkin diklik. Salah satu cara untuk menangani adalah untuk menambahkan fitur posisi, yaitu fitur tentang posisi konten di halaman. Anda melatih model dengan fitur posisi, dan hal itu mempelajari bobot, misalnya, fitur "posisi pertama" berat. Model Anda sehingga memberikan bobot yang lebih sedikit pada faktor lain untuk contoh dengan "1stposition=true". Lalu saat inferensi, Anda tidak perlu memberikan fitur posisi, atau berikan semuanya memiliki fitur {i>default<i} yang sama, karena Anda menilai kandidat sebelum telah memutuskan urutan untuk menampilkannya.

Perhatikan bahwa penting untuk menjaga agar fitur posisi tetap terpisah dari bagian model lainnya karena adanya asimetri antara pelatihan dan pengujian. Memiliki model yang merupakan penjumlahan dari fungsi fitur posisi dan {i>function<i} dari fitur lainnya sudah ideal. Misalnya, jangan melewati fitur posisi dengan fitur dokumen apa pun.

Aturan #37: Mengukur Kemiringan Pelatihan/Penyajian.

Ada beberapa hal yang dapat menyebabkan kecondongan dalam arti yang paling umum. Selain itu, Anda dapat membaginya menjadi beberapa bagian:

  • Perbedaan antara performa pada data pelatihan dan pisahan layanan otomatis dan data skalabel. Secara umum, hal ini selalu ada, dan tidak selalu buruk.
  • Perbedaan antara performa pada data pisahan dan "hari berikutnya" layanan otomatis dan data skalabel. Sekali lagi, hal ini akan selalu ada. Anda harus menyesuaikan regularisasi menjadi memaksimalkan performa hari berikutnya. Namun, penurunan besar dalam performa antara pisahan dan data hari berikutnya dapat menunjukkan bahwa beberapa fitur sensitif terhadap waktu, dan mungkin menurunkan performa model.
  • Perbedaan antara performa pada "hari berikutnya" data dan real time layanan otomatis dan data skalabel. Jika Anda menerapkan model ke contoh dalam data pelatihan dan penayangan iklan, Anda akan mendapatkan hasil yang sama persis (lihat Aturan #5 ). Jadi, perbedaan di sini mungkin menunjukkan kesalahan teknis.

ML Fase III: Pertumbuhan yang Perlambat, Peningkatan Pengoptimalan, dan Model Kompleks

Akan ada indikasi tertentu bahwa fase kedua hampir selesai. Pertama-tama, keuntungan bulanan Anda akan mulai berkurang. Anda akan mulai memiliki untung-rugi antara berbagai metrik: Anda akan melihat kenaikan dan penurunan eksperimen. Di sinilah konsepnya menjadi menarik. Karena keuntungan lebih sulit untuk dicapai, {i>machine learning<i} harus menjadi lebih canggih. Peringatan: ini memiliki lebih banyak aturan langit biru daripada bagian sebelumnya. Kita telah melihat banyak tim melalui masa-masa yang menyenangkan dari {i>machine learning <i}Tahap I dan Tahap II. Setelah Fase III sudah tercapai, tim harus menemukan jalan mereka sendiri.

Aturan #38: Jangan buang waktu untuk fitur baru jika tujuan yang tidak selaras menjadi masalahnya.

Saat pengukuran Anda di dataran tinggi, tim Anda akan mulai melihat masalah yang di luar cakupan tujuan sistem machine learning Anda saat ini. Sebagai dinyatakan sebelumnya, jika tujuan produk tidak dicakup oleh algoritma yang ada. Anda perlu mengubah tujuan atau sasaran produk Anda. Sebagai Misalnya, Anda dapat mengoptimalkan klik, plus-satu, atau download, tetapi membuat peluncuran keputusan yang sebagian berdasarkan penilai manusia.

Aturan #39: Keputusan peluncuran adalah proxy untuk sasaran produk jangka panjang.

Alice memiliki ide tentang cara mengurangi kerugian logistik dengan memprediksi penginstalan. sampai sekarang. Dia menyarankan saya untuk menambahkan fitur. Kerugian logistik turun. Saat melakukan eksperimen langsung, dia mengalami peningkatan rasio instal. Namun, ketika dia melihat video peluncuran seseorang menunjukkan bahwa jumlah pengguna aktif harian turun sebesar 5%. Tim memutuskan untuk tidak meluncurkan model tersebut. Alice kecewa, tetapi sekarang menyadari bahwa keputusan peluncuran bergantung pada banyak kriteria, yang hanya beberapa di antaranya dapat langsung dioptimalkan menggunakan ML.

Faktanya adalah bahwa dunia nyata bukan ruang bawah tanah dan naga: tidak ada poin" mengidentifikasi kesehatan produk Anda. Tim harus menggunakan statistik yang dikumpulkannya untuk mencoba memprediksi seberapa baik sistem yang sedang berjalan di masa mendatang. Mereka perlu memperhatikan engagement, pengguna aktif 1 hari (DAU), 30 DAU, pendapatan, dan laba atas investasi pengiklan. Metrik yang dalam pengujian A/B itu sendiri hanya merupakan proxy untuk jangka panjang tujuan: memuaskan pengguna, meningkatkan pengguna, memuaskan mitra, dan keuntungan, yang bahkan saat itu Anda dapat mempertimbangkan {i>proxy<i} untuk memiliki dan perusahaan yang berkembang lima tahun dari sekarang.

Satu-satunya keputusan peluncuran yang mudah adalah saat semua metrik menjadi lebih baik (atau setidaknya tidak menjadi lebih buruk). Jika tim mempunyai pilihan antara mesin yang canggih learning otomatis, dan heuristik sederhana, jika heuristik sederhana berhasil pekerjaan yang lebih baik pada semua metrik ini, ia harus memilih metode heuristik. Selain itu, terdapat tidak ada peringkat eksplisit dari semua kemungkinan nilai metrik. Secara khusus, pertimbangkan dua skenario berikut:

Eksperimen Pengguna Aktif Harian Pendapatan/Hari
A 1 juta $4 juta
B 2 juta $2 juta

Jika sistem saat ini adalah A, maka tim tidak akan beralih ke B. Jika sistem saat ini adalah B, maka tim tidak akan beralih ke A. Ini tampaknya bertentangan dengan perilaku rasional; Namun, prediksi perubahan metrik mungkin berjalan atau tidak, dan oleh karena itu, ada risiko besar yang atau mengubah apa pun. Setiap metrik mencakup beberapa risiko yang menjadi perhatian tim.

Selain itu, tidak ada metrik yang mencakup permasalahan utama tim, "di mana produk saya lima tahun dari sekarang"?

Di sisi lain, individu cenderung mendukung satu tujuan yang dapat mereka pengoptimalan secara langsung. Sebagian besar alat machine learning mendukung lingkungan seperti itu. Channel insinyur/perekayasa yang meluncurkan fitur baru bisa menghasilkan aliran peluncuran yang stabil dalam lingkungan fleksibel App Engine. Ada jenis {i>machine learning<i}, {i>multi-objective learning<i}, untuk mengatasi masalah ini. Misalnya, seseorang dapat merumuskan membatasi masalah kepuasan yang memiliki batas lebih rendah pada setiap metrik, dan mengoptimalkan beberapa kombinasi linear metrik. Namun, meski begitu, tidak semua metrik mudah dibingkai sebagai tujuan machine learning: jika dokumen diklik atau aplikasi dipasang, ini karena konten ditampilkan. Tapi akan jauh lebih sulit untuk mengetahui alasan pengguna mengunjungi situs Anda. Cara memprediksi kesuksesan situs secara keseluruhan di masa depan AI-complete: sesulit komputer visi atau natural language processing.

Aturan #40: Jaga agar ansambel tetap sederhana.

Model terpadu yang mengambil fitur mentah dan secara langsung mengurutkan konten adalah model yang paling mudah untuk di-debug dan dipahami. Namun, sekumpulan model (suatu "model" yang menggabungkan skor model lain) dapat berfungsi lebih baik. Untuk menjaga hal-hal sederhana, setiap model haruslah berupa ansambel yang hanya mengambil input model lain, atau model dasar yang memiliki banyak fitur, tetapi tidak keduanya. Jika Anda memiliki model di atas model lain yang dilatih secara terpisah, lalu menggabungkannya dapat mengakibatkan perilaku buruk.

Gunakan model sederhana untuk ansambel yang hanya menggunakan output "base" Anda model sebagai input. Anda juga ingin menerapkan properti pada model ensemble ini. Misalnya, peningkatan skor yang dihasilkan oleh model dasar tidak boleh mengurangi skor ansambel. Juga, lebih baik lagi jika model yang masuk dapat ditafsirkan secara semantik (misalnya, dikalibrasi) sehingga perubahan dasar model tidak tertukar dalam model ansambel. Selain itu, terapkan peningkatan prediksi probabilitas dari pengklasifikasi yang mendasari tidak mengurangi prediksi probabilitas ansambel.

Aturan #41: Saat performa stabil, sebaiknya cari sumber informasi yang baru secara kualitatif untuk ditambahkan, bukan menyaring sinyal yang sudah ada.

Anda telah menambahkan beberapa informasi demografis tentang pengguna. Anda telah menambahkan beberapa informasi tentang kata-kata dalam dokumen. Anda telah melihat template eksplorasi, dan menyesuaikan regularisasi. Anda belum melihat peluncuran dengan konten lainnya 1% peningkatan pada metrik utama Anda dalam beberapa kuartal. Selanjutnya bagaimana?

Saatnya untuk mulai membangun infrastruktur untuk organisasi yang fitur baru, seperti histori dokumen yang telah diakses pengguna ini di hari, minggu, atau tahun terakhir, atau data dari properti yang berbeda. Gunakan wikidata entitas atau sesuatu yang bersifat internal bagi perusahaan Anda (seperti grafik pengetahuan). Gunakan deep link pembelajaran. Mulailah menyesuaikan ekspektasi Anda berapa banyak laba yang Anda harapkan pada investasi, dan perluas upaya Anda sesuai dengan itu. Seperti dalam proyek teknik, Anda harus mempertimbangkan manfaat penambahan fitur baru dibandingkan dengan biaya yang semakin kompleks.

Aturan #42: Jangan berharap keberagaman, personalisasi, atau relevansi memiliki korelasi yang sama dengan popularitas seperti yang Anda kira.

Keberagaman dalam serangkaian konten dapat diartikan sebagai banyak hal, dengan keragaman sumber konten adalah salah satu yang paling umum. Personalisasi menyiratkan setiap pengguna mendapatkan hasilnya sendiri. Relevansi menyiratkan bahwa hasil untuk suatu yang lebih tepat untuk kueri itu daripada yang lain. Jadi, ketiga properti-properti ini didefinisikan sebagai berbeda dari yang biasa.

Masalahnya adalah bahwa yang biasa cenderung sulit dikalahkan.

Perhatikan bahwa jika sistem Anda mengukur klik, waktu yang dihabiskan, tontonan, +1, pembagian ulang, dan lain-lain, Anda mengukur populer konten tersebut. Tim kadang-kadang mencoba untuk mempelajari model pribadi dengan keragaman. Untuk melakukan personalisasi, mereka menambahkan fitur yang memungkinkan sistem untuk dipersonalisasi (beberapa fitur yang mewakili minat pengguna) atau mendiversifikasi (fitur yang menunjukkan apakah dokumen ini memiliki yang sama dengan dokumen lain yang ditampilkan, seperti penulis atau konten), dan menemukan bahwa fitur-fitur tersebut memiliki bobot yang lebih rendah (atau terkadang tanda yang berbeda) dari yang mereka harapkan.

Hal ini bukan berarti keberagaman, personalisasi, atau relevansi tidak berharga. Seperti yang ditunjukkan dalam aturan sebelumnya, Anda dapat melakukan pascapemrosesan untuk keberagaman atau relevansi. Jika ada peningkatan tujuan jangka panjang, Anda dapat menyatakan bahwa keberagaman/relevansi sangat berharga, selain popularitas. Anda dapat melanjutkan menggunakan proses pascapemrosesan, atau memodifikasi langsung objektif berdasarkan keragaman atau relevansi.

Aturan #43: Teman Anda cenderung sama di berbagai produk. Anda cenderung tidak tertarik.

Tim di Google telah mendapatkan banyak dukungan dengan mengambil model yang memprediksi kedekatan koneksi di satu produk, dan membuatnya bekerja dengan baik di produk lain. Teman Anda adalah mereka. Di sisi lain, saya telah melihat beberapa tim kesulitan dengan fitur personalisasi di seluruh segmen produk. Ya, sepertinya sepertinya seharusnya berfungsi. Untuk saat ini, sepertinya tidak seperti itu. Hal yang terkadang menggunakan data mentah dari satu properti untuk memprediksi perilaku di properti lain. Selain itu, perlu diingat bahwa bahkan mengetahui bahwa pengguna memiliki riwayat di properti lain dapat membantu. Misalnya, keberadaan aktivitas pengguna pada dua produk mungkin indikatif.

Ada banyak dokumen tentang machine learning di Google dan juga di luar Google.

Ucapan terima kasih

Terima kasih kepada David Westbrook, Peter Brandt, Samuel Ieong, Chenyu Zhao, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine, Tal Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Konstantinos Katsiapis, Glen Anderson, Dan Duckworth, Shishir Birmiwal, Gal Elidan, Su Lin Wu, Jaihui Liu, Fernando Pereira, dan Hrishikesh Aradhye untuk banyak koreksi, saran, dan contoh yang bermanfaat untuk dokumen ini. Terima kasih kepada Kristin Lefevre, Suddha Basu, dan Chris Berg yang membantu dalam versi sebelumnya. Apa saja kesalahan, kelalaian, atau (terengah-engah!) pendapat yang tidak populer adalah milik saya sendiri.

Lampiran

Ada berbagai referensi untuk produk Google dalam dokumen ini. Kepada memberikan lebih banyak konteks, saya memberikan deskripsi singkat tentang contoh yang paling umum di bawah ini.

Ringkasan YouTube

YouTube adalah layanan video streaming. Tonton Berikutnya di YouTube dan Beranda YouTube Tim halaman menggunakan model ML untuk menentukan peringkat rekomendasi video. Rekomendasi Tonton Berikutnya video untuk ditonton setelah video yang sedang diputar, sedangkan Halaman Beranda merekomendasikan video kepada pengguna yang menjelajahi beranda.

Ringkasan Google Play

Google Play memiliki banyak model yang dapat memecahkan berbagai masalah. Penelusuran Play, Play Rekomendasi yang Dipersonalisasi di Halaman Beranda dan aplikasi 'Pengguna yang Juga Diinstal' semuanya menggunakan machine learning tertentu.

Ringkasan Google Plus

Google Plus menggunakan machine learning dalam berbagai situasi: memberi peringkat postingan di "aliran" postingan yang dilihat oleh pengguna, memberi peringkat "Lagi Ngetren" postingan (postingan yang sangat populer sekarang), memberi peringkat orang yang Anda kenal, dan lain-lain. Google Plus menutup semua akun pribadi pada tahun 2019, dan digantikan dengan Google Currents untuk akun bisnis pada 6 Juli 2020.