Aturan Machine Learning:

Praktik Terbaik untuk Rekayasa ML

Martin Zinkevich

Dokumen ini dimaksudkan untuk membantu pengguna yang memiliki pengetahuan dasar tentang machine learning agar mendapatkan manfaat dari praktik terbaik Google dalam machine learning. Panduan ini menyajikan gaya untuk machine learning, mirip dengan Panduan Gaya Google C++ dan panduan populer lainnya untuk pemrograman praktis. Jika Anda pernah mengikuti kelas machine learning, atau membuat atau mengerjakan model machine learning, berarti Anda memiliki latar belakang yang diperlukan untuk membaca dokumen ini.

Martin Zinkevich memperkenalkan 10 aturan machine learning favoritnya. Lanjutkan membaca untuk mempelajari ke-43 aturan tersebut.

Terminologi

Istilah berikut akan muncul berulang kali dalam diskusi kita tentang machine learning yang efektif:

  • Instance: Hal yang Anda inginkan untuk membuat prediksi. Misalnya, instance mungkin halaman web yang ingin Anda klasifikasikan sebagai "tentang kucing" atau "bukan tentang kucing".
  • Label: Jawaban untuk tugas prediksi, baik jawaban yang dihasilkan oleh sistem machine learning, maupun jawaban yang benar yang diberikan dalam data pelatihan. Misalnya, label untuk halaman web mungkin berupa "tentang kucing".
  • Fitur: Properti instance yang digunakan dalam tugas prediksi. Misalnya, halaman web mungkin memiliki fitur "berisi kata 'kucing'".
  • Kolom Fitur: Kumpulan fitur terkait, seperti kumpulan semua kemungkinan negara tempat pengguna tinggal. Sebuah contoh mungkin memiliki satu atau beberapa fitur dalam kolom fitur. "Kolom fitur" adalah terminologi khusus Google. Kolom fitur disebut sebagai "namespace" dalam sistem VW (di Yahoo/Microsoft), atau kolom.
  • Contoh: Instance (dengan fiturnya) dan label.
  • Model: Representasi statistik dari tugas prediksi. Anda melatih model berdasarkan beberapa contoh, lalu menggunakan model tersebut untuk membuat prediksi.
  • Metrik: Angka yang penting bagi Anda. Mungkin atau mungkin tidak dioptimalkan secara langsung.
  • Tujuan: Metrik yang coba dioptimalkan oleh algoritma Anda.
  • Pipeline: Infrastruktur yang berkaitan dengan algoritma machine learning. Hal ini meliputi pengumpulan data dari front end, memasukkannya ke dalam file data pelatihan, melatih satu atau beberapa model, dan mengekspor model ke produksi.
  • Rasio Klik-Tayang Persentase pengunjung halaman web yang mengklik link pada iklan.

Ringkasan

Untuk membuat produk yang hebat:

melakukan machine learning layaknya engineer yang hebat, bukan pakar machine learning yang hebat.

Sebagian besar masalah yang akan Anda hadapi, pada kenyataannya, masalah teknik. Meskipun dengan semua resource dari pakar machine learning yang hebat, sebagian besar keuntungan berasal dari fitur yang hebat, bukan algoritma machine learning yang hebat. Jadi, pendekatan dasarnya adalah:

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

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

Setelah Anda menghabiskan trik sederhana, machine learning yang canggih mungkin akan ada di masa depan Anda. Lihat bagian project machine learning Tahap III.

Dokumen ini disusun sebagai berikut:

  1. Bagian pertama akan membantu Anda memahami apakah waktu yang tepat untuk membangun sistem machine learning.
  2. Bagian kedua adalah tentang men-deploy pipeline pertama Anda.
  3. Bagian ketiga adalah tentang peluncuran dan iterasi sekaligus menambahkan fitur baru ke pipeline, cara mengevaluasi model dan kecondongan penyaluran pelatihan.
  4. Bagian terakhir adalah tentang apa yang harus dilakukan saat Anda mencapai dataran tinggi.
  5. Setelah itu, ada daftar pekerjaan terkait dan lampiran dengan beberapa latar belakang sistem yang biasanya digunakan sebagai contoh dalam dokumen ini.

Sebelum Machine Learning

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

Machine learning itu keren, tetapi memerlukan data. Secara teoretis, Anda dapat mengambil data dari masalah yang berbeda, lalu menyesuaikan model untuk produk baru, tetapi hal ini mungkin akan menurunkan performa heuristics dasar. Jika menurut Anda machine learning akan memberi Anda peningkatan 100%, maka heuristik akan memberikan 50% peningkatan.

Misalnya, jika Anda memberi peringkat aplikasi di marketplace aplikasi, Anda dapat menggunakan rasio instal atau jumlah penginstalan sebagai heuristik. Jika Anda mendeteksi spam, filter penayang yang sebelumnya telah mengirim spam. Jangan takut untuk menggunakan pengeditan manusia. Jika Anda perlu memberi peringkat kontak, beri peringkat tertinggi yang terakhir digunakan (atau bahkan beri peringkat menurut abjad). Jika {i>machine learning<i} tidak mutlak diperlukan untuk produk Anda, jangan menggunakannya sampai Anda memiliki data.

Aturan #2: Pertama, desain dan terapkan metrik.

Sebelum merumuskan apa yang akan dilakukan sistem machine learning, lacak sebanyak 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 menurut Anda ada sesuatu yang mungkin menjadi kekhawatiran di masa mendatang, sebaiknya dapatkan data historis sekarang.
  3. Jika Anda mendesain sistem dengan mempertimbangkan instrumentasi metrik, semuanya akan lebih baik bagi Anda di masa mendatang. Khususnya, Anda tidak ingin mencari string dalam log untuk menginstrumentasikan metrik Anda.
  4. Anda akan memperhatikan, apa saja yang berubah dan tetap sama. Misalnya, Anda ingin langsung mengoptimalkan pengguna aktif satu hari. Namun, selama manipulasi awal sistem, Anda mungkin melihat bahwa perubahan dramatis pada pengalaman pengguna tidak mengubah metrik ini secara signifikan.

Ukuran tim Google Plus diperluas per baca, bagikan ulang per baca, plus satu per bacaan, komentar/baca, komentar per pengguna, pembagian ulang per pengguna, dll. yang mereka gunakan dalam menghitung kebaikan postingan pada waktu penayangan. Selain itu, perhatikan bahwa framework eksperimen, tempat Anda dapat mengelompokkan pengguna ke dalam bucket dan menggabungkan statistik berdasarkan eksperimen, sangatlah penting. Lihat Aturan #12.

Dengan menjadi lebih liberal dalam mengumpulkan metrik, Anda bisa mendapatkan gambaran yang lebih luas tentang sistem Anda. Ada masalah? Tambahkan metrik untuk melacaknya. Merasa senang dengan perubahan kuantitatif pada rilis terakhir? Tambahkan metrik untuk melacaknya.

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

Heuristik yang sederhana dapat membuat produk Anda diluncurkan. Heuristik yang kompleks tidak dapat dipelihara. Setelah Anda memiliki data dan gambaran dasar tentang apa yang ingin Anda capai, lanjutkan ke {i>machine learning<i}. Seperti pada sebagian besar tugas software engineering, Anda perlu terus memperbarui pendekatan, baik model tersebut heuristik maupun yang dipelajari machine learning, dan Anda akan mendapati bahwa model yang dipelajari mesin lebih mudah diperbarui dan dikelola (lihat Aturan #16).

ML Tahap I: Pipeline Pertama Anda

Fokus pada infrastruktur sistem untuk pipeline pertama Anda. Meskipun menyenangkan untuk memikirkan semua machine learning imajinatif yang akan Anda lakukan, akan sulit untuk mencari tahu apa yang terjadi jika Anda tidak memercayai pipeline Anda terlebih dahulu.

Aturan #4: Buat model pertama tetap sederhana dan dapatkan infrastruktur dengan benar.

Model pertama memberikan dorongan terbesar untuk produk Anda, sehingga tidak perlu elegan. Tetapi Anda akan menghadapi lebih banyak masalah infrastruktur daripada yang Anda perkirakan. Sebelum siapa pun dapat menggunakan sistem machine learning baru yang canggih, Anda harus menentukan:

  • Cara mendapatkan contoh ke algoritme pembelajaran.
  • Bagian pertama tentang apa arti "baik" dan "buruk" bagi sistem Anda.
  • Cara mengintegrasikan model ke dalam aplikasi Anda. Anda dapat menerapkan model secara langsung, atau melakukan prakomputasi model pada contoh secara offline dan menyimpan hasilnya dalam tabel. Misalnya, Anda mungkin ingin melakukan klasifikasi halaman web dan menyimpan hasilnya dalam tabel, tetapi Anda mungkin ingin mengklasifikasikan pesan chat secara langsung.

Memilih fitur yang sederhana akan mempermudah untuk memastikan bahwa:

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

Setelah memiliki sistem yang dapat melakukan ketiga hal ini dengan andal, Anda telah melakukan sebagian besar pekerjaan. Model sederhana akan memberi Anda metrik dasar pengukuran dan perilaku dasar pengukuran yang dapat digunakan untuk menguji model yang lebih kompleks. Beberapa tim menargetkan peluncuran pertama yang "netral": peluncuran pertama yang secara eksplisit tidak memprioritaskan keuntungan machine learning, agar perhatian tidak terganggu.

Aturan #5: Menguji infrastruktur secara independen dari machine learning.

Pastikan infrastruktur dapat diuji, dan bagian pembelajaran dari sistem dienkapsulasi sehingga Anda dapat menguji semua hal di sekitarnya. Khususnya:

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

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

Aturan #6: Berhati-hatilah agar data tidak hilang saat menyalin pipeline.

Sering kali kami membuat pipeline dengan menyalin pipeline yang ada (yaitu, pemrograman kultus kargo ), dan pipeline lama menghapus data yang kami perlukan untuk pipeline baru. Misalnya, pipeline untuk Yang Sedang Populer di Google Plus menurunkan postingan lama (karena mencoba memberi peringkat postingan baru). Pipeline ini disalin untuk digunakan untuk Google Plus Stream, dengan postingan lama yang masih bermakna, tetapi pipeline ini masih menghapus postingan lama. Pola umum lainnya adalah hanya mencatat log data yang dilihat oleh pengguna. Oleh karena itu, 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 Play. Saat mengerjakan Beranda Aplikasi Play, pipeline baru dibuat yang juga berisi contoh dari halaman landing untuk Play Game tanpa fitur apa pun untuk membedakan dari mana setiap contoh berasal.

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

Biasanya masalah yang coba dipecahkan oleh machine learning bukanlah hal yang benar-benar baru. Sudah ada sistem untuk memberi peringkat, atau mengklasifikasikan, atau masalah apa pun yang Anda coba pecahkan. Ini berarti bahwa ada banyak aturan dan heuristik. Heuristik yang sama ini dapat memberikan peningkatan saat disesuaikan dengan machine learning. Heuristik Anda harus ditambang untuk informasi apa pun yang mereka miliki, karena dua alasan. Pertama, transisi ke sistem {i>machine learning<i} akan lebih lancar. Kedua, biasanya aturan itu berisi banyak intuisi tentang sistem yang tidak ingin Anda buang. Ada empat cara untuk menggunakan heuristik yang ada:

  • Lakukan prapemrosesan menggunakan heuristik. Jika fitur tersebut sangat luar biasa, maka ini adalah sebuah pilihan. Misalnya, jika, dalam filter spam, pengirim sudah dimasukkan ke daftar hitam, jangan mencoba mempelajari kembali arti "dimasukkan ke daftar hitam". Memblokir pesan. Pendekatan ini paling masuk akal dalam tugas klasifikasi biner.
  • Membuat fitur. Langsung membuat fitur dari heuristik adalah hal yang bagus. Misalnya, jika Anda menggunakan heuristik untuk menghitung skor relevansi untuk hasil kueri, Anda dapat menyertakan skor sebagai nilai fitur. Nantinya Anda dapat menggunakan teknik machine learning untuk mengolah nilai tersebut (misalnya, mengonversi nilai menjadi salah satu kumpulan nilai diskret terbatas, atau menggabungkannya dengan fitur lain), tetapi mulailah dengan menggunakan nilai mentah yang dihasilkan oleh heuristik tersebut.
  • Tambang input mentah heuristik. Jika ada heuristik untuk aplikasi yang menggabungkan jumlah penginstalan, jumlah karakter dalam teks, dan hari, sebaiknya pisahkan bagian-bagian tersebut, dan masukkan input ini ke dalam pembelajaran secara terpisah. Beberapa teknik yang berlaku untuk ensemble dapat diterapkan di sini (lihat Aturan #40).
  • Ubah label. Ini adalah opsi ketika Anda merasa bahwa heuristik mengambil informasi yang saat ini tidak terdapat dalam label. Misalnya, jika Anda mencoba memaksimalkan jumlah download, tetapi juga menginginkan konten yang berkualitas, mungkin solusinya adalah mengalikan label dengan jumlah rata-rata bintang yang diterima aplikasi. Ada banyak kelonggaran di sini. Lihat "Tujuan Pertama Anda".

Perhatikan kompleksitas tambahan saat menggunakan heuristik dalam sistem ML. Menggunakan heuristik lama dalam algoritme machine learning yang baru dapat membantu menciptakan transisi yang lancar, tetapi pikirkan apakah ada cara lebih sederhana untuk mencapai efek yang sama.

Monitoring

Secara umum, terapkan higiene pemberitahuan yang baik, seperti membuat pemberitahuan 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? 1 minggu? Seperempat usia? Informasi ini dapat membantu Anda memahami prioritas pemantauan. Jika Anda kehilangan kualitas produk yang signifikan jika model tidak diperbarui selama satu hari, seorang engineer harus memantaunya terus-menerus. Sebagian besar sistem penayangan iklan memiliki iklan baru untuk ditangani setiap hari, dan harus diperbarui setiap hari. Misalnya, jika model ML untuk Penelusuran Google Play tidak diperbarui, model tersebut dapat berdampak negatif dalam waktu kurang dari satu bulan. Beberapa model untuk Lagi Ngetren di Google Plus tidak memiliki ID postingan dalam modelnya, sehingga model ini jarang diekspor. Model lain yang memiliki ID postingan diperbarui jauh lebih sering. Perhatikan juga bahwa keaktualan dapat berubah dari waktu ke waktu, terutama saat kolom fitur ditambahkan atau dihapus dari model Anda.

Aturan #9: Mendeteksi masalah sebelum mengekspor model.

Banyak sistem machine learning memiliki tahap untuk mengekspor model ke penayangan. Jika ada masalah dengan model yang diekspor, masalah tersebut juga akan dihadapi pengguna.

Lakukan pemeriksaan kesehatan tepat sebelum mengekspor model. Secara khusus, pastikan performa model wajar untuk data yang ditahan. Atau, jika Anda memiliki masalah dengan data yang masih ada, jangan mengekspor model. Banyak tim yang terus men-deploy model memeriksa area di bawah kurva KOP (atau ABK) 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 menunggu dan memastikan sebelum mempengaruhi pengguna.

Aturan #10: Perhatikan kegagalan senyap.

Ini adalah masalah yang lebih sering terjadi pada sistem machine learning daripada jenis sistem lainnya. Misalkan tabel tertentu yang sedang digabungkan tidak lagi diperbarui. Sistem machine learning akan menyesuaikan, dan perilaku akan terus cukup baik, dan secara bertahap akan menurun. Terkadang Anda menemukan tabel yang sudah tidak berlaku dalam beberapa bulan, dan refresh sederhana meningkatkan performa lebih besar daripada peluncuran lainnya pada kuartal tersebut. Cakupan fitur dapat berubah karena perubahan implementasi: misalnya kolom fitur dapat diisi pada 90% contoh, dan tiba-tiba turun menjadi 60% dari contoh. Play pernah memiliki tabel yang usang selama 6 bulan, dan memperbarui tabel saja dapat meningkatkan rasio penginstalan sebesar 2%. Jika Anda melacak statistik data, sekaligus memeriksa data secara manual sesekali, Anda dapat mengurangi jenis kegagalan ini.

Aturan #11: Berikan pemilik dan dokumentasi kolom fitur.

Jika sistemnya besar, dan ada banyak kolom fitur, ketahui siapa yang membuat atau mengelola setiap kolom fitur. Jika Anda mendapati bahwa orang yang memahami kolom fitur pergi, pastikan seseorang memiliki informasi tersebut. Meskipun banyak kolom fitur memiliki nama deskriptif, ada baiknya Anda memiliki deskripsi yang lebih mendetail tentang fitur tersebut, asalnya, dan bagaimana fitur tersebut diharapkan dapat membantu.

Tujuan Pertama Anda

Anda memiliki banyak metrik atau pengukuran tentang sistem yang penting, tetapi algoritme machine learning sering kali memerlukan satu tujuan, yaitu angka yang "dicoba" untuk dioptimalkan oleh algoritme Anda. Saya membedakan antara tujuan dan metrik: metrik adalah angka apa pun yang dilaporkan sistem Anda, yang mungkin penting atau tidak penting. Lihat juga Aturan #2.

Aturan #12: Jangan terlalu memikirkan tujuan yang akan Anda optimalkan secara langsung.

Anda ingin menghasilkan uang, membuat pengguna senang, dan membuat dunia menjadi tempat yang lebih baik. Ada banyak metrik yang penting dan Anda harus mengukur semuanya (lihat Aturan #2). Namun, di awal proses machine learning, Anda akan melihat semuanya meningkat, bahkan ada yang tidak Anda optimalkan secara langsung. Misalnya, Anda peduli dengan jumlah klik dan waktu yang dihabiskan di situs. Jika Anda mengoptimalkan jumlah klik, waktu yang dihabiskan akan meningkat.

Jadi, tetap sederhana dan jangan berpikir terlalu keras untuk menyeimbangkan berbagai metrik karena Anda masih dapat meningkatkan semua metrik dengan mudah. Namun, jangan terlalu memperhatikan aturan ini: jangan salah membedakan tujuan Anda dengan kondisi utama sistem (lihat Aturan #39). Selain itu, jika Anda meningkatkan metrik yang dioptimalkan secara langsung, tetapi memutuskan untuk tidak meluncurkannya, beberapa revisi yang objektif mungkin diperlukan.

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

Sering kali Anda tidak tahu tujuan sebenarnya. Anda berpikir melakukannya, tetapi kemudian saat Anda menatap data dan analisis secara berdampingan dari sistem lama dan sistem ML baru, Anda menyadari bahwa Anda ingin menyesuaikan tujuan tersebut. Lebih lanjut, anggota tim yang berbeda sering tidak mencapai tujuan yang sebenarnya. Tujuan ML harus berupa sesuatu yang mudah diukur dan merupakan proxy untuk tujuan "benar". Bahkan, sering kali tidak ada tujuan "benar" (lihat Aturan#39). Jadi, latih tujuan ML yang sederhana, dan pertimbangkan untuk memiliki "lapisan kebijakan" di atasnya yang memungkinkan Anda menambahkan logika tambahan (yang semoga logikanya sangat sederhana) untuk melakukan peringkat akhir.

Hal termudah untuk dimodelkan adalah perilaku pengguna yang langsung diamati dan dapat diatribusikan ke tindakan sistem:

  • Apakah link berperingkat ini diklik?
  • Apakah objek berperingkat ini didownload?
  • Apakah objek yang diberi peringkat ini diteruskan/dibalas/dikirim melalui email?
  • Apakah objek berperingkat 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 keputusan peluncuran.

Terakhir, jangan mencoba agar machine learning mencari tahu:

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

Semua ini penting, tetapi juga sangat sulit diukur. Sebagai gantinya, gunakan proxy: jika pengguna senang, mereka akan tetap berada di situs lebih lama. Jika puas, pengguna akan berkunjung lagi besok. Sejauh menyangkut kesejahteraan dan kesehatan perusahaan, penilaian manusia diperlukan untuk menghubungkan tujuan yang dipelajari mesin dengan 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 dimotivasi secara langsung oleh model probabilistik. Setiap prediksi dapat ditafsirkan sebagai probabilitas atau nilai yang diharapkan. Hal ini membuatnya lebih mudah di-debug daripada model yang menggunakan tujuan (kehilangan nol-satu, berbagai kerugian engsel, dan sebagainya) yang mencoba mengoptimalkan akurasi klasifikasi atau performa peringkat secara langsung. Misalnya, jika probabilitas dalam pelatihan menyimpang dari probabilitas yang diprediksi secara berdampingan atau dengan memeriksa sistem produksi, penyimpangan ini dapat mengungkapkan masalah.

Misalnya, dalam regresi linear, logistik, atau Poisson, ada subset data yang ekspektasi prediksi rata-ratanya sama dengan label rata-rata (dikalibrasi 1 momen, atau baru dikalibrasi). Hal ini benar dengan asumsi bahwa Anda tidak memiliki regularisasi dan algoritma Anda telah terkonvergensi, dan secara umum dianggap benar. Jika Anda memiliki fitur dengan nilai 1 atau 0 untuk setiap contoh, set 3 contoh dengan fitur tersebut bernilai 1 akan dikalibrasi. Selain itu, jika Anda memiliki fitur 1 untuk setiap contoh, kumpulan semua contoh akan dikalibrasi.

Dengan model sederhana, akan lebih mudah untuk menangani feedback loop (lihat Aturan #36). Sering kali, kami menggunakan prediksi probabilistik ini untuk membuat keputusan: misalnya membuat peringkat postingan yang menurunkan nilai yang diharapkan (misalnya kemungkinan klik/download/dll.). Namun, ingatlah bahwa ketika tiba saatnya untuk memilih model mana yang akan digunakan, keputusan ini lebih penting daripada kemungkinan data yang diberikan oleh model (lihat Aturan #27).

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

Peringkat kualitas adalah seni yang bagus, tetapi pemfilteran spam adalah perang. Sinyal yang Anda gunakan untuk menentukan postingan berkualitas tinggi akan terlihat jelas bagi pengguna yang menggunakan sistem Anda, dan mereka akan menyesuaikan postingan mereka agar memiliki properti ini. Oleh karena itu, peringkat kualitas harus berfokus pada pemberian peringkat pada konten yang diposting dengan niat baik. Anda tidak boleh mengecilkan pembelajar peringkat berkualitas karena tingginya peringkat spam. Demikian pula, konten yang "tidak pantas" harus ditangani secara terpisah dari Peringkat Kualitas. Pemfilteran {i>spam <i}adalah hal yang berbeda. Anda harus mengantisipasi bahwa fitur yang perlu Anda buat akan terus berubah. Sering kali, akan ada aturan jelas yang Anda masukkan ke dalam sistem (jika postingan memiliki lebih dari tiga suara spam, jangan mengambilnya, dan sebagainya). Setiap model yang dipelajari harus diupdate setiap hari, atau lebih cepat. Reputasi pembuat konten akan memainkan peran penting.

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

ML Tahap II: Rekayasa Fitur

Pada fase pertama siklus proses sistem machine learning, masalah yang penting adalah memasukkan data pelatihan ke dalam sistem pembelajaran, mendapatkan metrik minat apa pun yang diinstrumentasikan, dan membuat infrastruktur penyaluran. Setelah Anda memiliki sistem end-to-end yang berfungsi dengan pengujian unit dan sistem yang diinstrumentasikan, Fase II akan dimulai.

Pada fase kedua, ada banyak hal yang sulit dicapai. Ada berbagai fitur jelas yang dapat ditarik ke dalam sistem. Dengan demikian, fase kedua dari machine learning melibatkan pengambilan 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 mengumpulkan banyak engineer yang dapat menggabungkan semua data yang Anda butuhkan untuk membuat sistem pembelajaran yang benar-benar hebat.

Aturan #16: Rencanakan peluncuran dan iterasi.

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

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

Terlepas dari itu, memberi sedikit model cinta itu bagus: memeriksa data yang dimasukkan ke dalam contoh dapat membantu menemukan sinyal baru serta sinyal lama yang rusak. Jadi, saat membuat model, pikirkan tentang betapa mudahnya menambahkan atau menghapus atau menggabungkan kembali fitur. Pikirkan betapa mudahnya membuat salinan baru pipeline dan memverifikasi ketepatannya. Pikirkan apakah mungkin untuk memiliki dua atau tiga salinan yang berjalan secara paralel. Terakhir, jangan khawatir apakah fitur 16 dari 35 akan masuk ke dalam versi pipeline ini. Anda akan mendapatkannya pada kuartal berikutnya.

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

Hal ini mungkin menjadi poin kontroversial, tetapi ini menghindari banyak jebakan. Pertama-tama, mari kita jelaskan apa yang dimaksud dengan fitur yang dipelajari. Fitur yang dipelajari adalah fitur yang dihasilkan oleh sistem eksternal (seperti sistem pengelompokan yang tidak diawasi) atau oleh pelajar itu sendiri (misalnya, melalui model faktor atau deep learning). Keduanya dapat berguna, tetapi dapat memiliki banyak masalah sehingga tidak boleh berada di model pertama.

Jika Anda menggunakan sistem eksternal untuk membuat fitur, ingatlah bahwa sistem eksternal memiliki tujuannya sendiri. Tujuan sistem eksternal mungkin hanya berkorelasi lemah dengan tujuan Anda saat ini. Jika Anda mengambil {i>snapshot<i} dari sistem eksternal, gambar itu bisa usang. Jika Anda memperbarui fitur dari sistem eksternal, artinya mungkin berubah. Jika Anda menggunakan sistem eksternal untuk menyediakan fitur, perlu diketahui bahwa pendekatan ini memerlukan banyak kehati-hatian.

Masalah utama pada model faktor dan model mendalam adalah model tersebut tidak konveks. Oleh karena itu, tidak ada jaminan bahwa solusi optimal dapat diperkirakan atau ditemukan, dan nilai minimum lokal yang ditemukan pada setiap iterasi dapat berbeda. Variasi ini mempersulit penilaian apakah dampak perubahan pada sistem Anda bermakna atau acak. Dengan membuat model tanpa fitur mendalam, Anda bisa mendapatkan performa dasar pengukuran yang sangat baik. Setelah dasar pengukuran ini tercapai, Anda dapat mencoba pendekatan yang lebih khusus.

Aturan #18: Jelajahi dengan fitur konten yang generalisasi di seluruh konteks.

Sering kali sistem machine learning adalah bagian kecil dari gambaran yang jauh lebih besar. Misalnya, jika Anda membayangkan postingan yang mungkin digunakan di Lagi Ngetren, banyak orang akan memberi plus-satu, membagikan ulang, atau mengomentari postingan sebelum ditampilkan di Lagi Ngetren. Jika Anda memberikan statistik tersebut kepada peserta, tindakan tersebut dapat mempromosikan postingan baru yang tidak memiliki datanya dalam konteks yang dioptimalkannya. YouTube Tonton Berikutnya dapat menggunakan jumlah tontonan atau tontonan bersama (jumlah berapa kali satu video ditonton setelah video lain ditonton) dari penelusuran YouTube. Anda juga dapat menggunakan rating eksplisit dari pengguna. Terakhir, jika Anda memiliki tindakan pengguna yang digunakan sebagai label, melihat tindakan tersebut pada dokumen dalam konteks yang berbeda dapat menjadi fitur yang bagus. 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 lebih sedikit.

Aturan #19: Gunakan fitur yang sangat spesifik sebisa mungkin.

Dengan data yang banyak, mempelajari jutaan fitur sederhana akan lebih mudah daripada mempelajari beberapa fitur kompleks. ID dokumen yang diambil dan kueri yang dikanonikalisasi tidak memberikan banyak generalisasi, tetapi akan menyelaraskan peringkat Anda dengan label pada kueri head. Oleh karena itu, jangan khawatir dengan kelompok fitur yang setiap fiturnya berlaku untuk sebagian kecil data Anda, tetapi cakupan keseluruhannya di atas 90%. Anda dapat menggunakan regularisasi untuk menghilangkan fitur yang berlaku untuk terlalu sedikit contoh.

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

Ada berbagai cara untuk menggabungkan dan memodifikasi fitur. Sistem machine learning seperti TensorFlow memungkinkan Anda untuk memproses data terlebih dahulu melalui transformasi. Dua pendekatan yang paling standar adalah "diskretisasi" dan "persilangan".

Diskretisasi terdiri dari pengambilan fitur berkelanjutan dan pembuatan banyak fitur diskret dari fitur tersebut. Pertimbangkan fitur berkelanjutan seperti usia. Anda dapat membuat fitur yaitu 1 jika usia kurang dari 18 tahun, fitur lainnya adalah 1 saat usia antara 18 dan 35, dan sebagainya. Jangan terlalu memikirkan batas-batas histogram ini: kuantil dasar akan memberi Anda sebagian besar dampak.

Persilangan menggabungkan dua kolom fitur atau lebih. Kolom fitur, dalam terminologi TensorFlow, adalah kumpulan fitur homogen, (misalnya {laki-laki, perempuan}, {US, Kanada, Meksiko}, dan sebagainya). Tanda silang adalah kolom fitur baru dengan fitur di, misalnya, {laki-laki, perempuan} × {US,Kanada, Meksiko}. Kolom fitur baru ini akan berisi fitur (laki-laki, Kanada). Jika Anda menggunakan TensorFlow dan memberi tahu TensorFlow untuk membuat persilangan ini untuk Anda, fitur (pria, Kanada) ini akan ada dalam contoh yang mewakili warga Kanada laki-laki. Perhatikan bahwa diperlukan sejumlah besar data untuk mempelajari model dengan persilangan dari tiga, empat, atau lebih kolom fitur dasar.

Persilangan yang menghasilkan kolom fitur yang sangat besar dapat mengalami overfit. Misalnya, bayangkan Anda sedang melakukan semacam penelusuran, dan Anda memiliki kolom fitur dengan kata-kata dalam kueri, dan Anda memiliki kolom fitur dengan kata-kata dalam dokumen. Anda dapat menggabungkannya dengan tanda silang, tetapi akan ada banyak fitur (lihat Aturan #21).

Saat bekerja dengan teks, ada dua alternatif. Yang paling mengerikan adalah produk titik. Produk titik dalam bentuknya yang paling sederhana hanya menghitung jumlah kata yang sama antara kueri dan dokumen. Fitur ini kemudian dapat didiskriminasi. Pendekatan lainnya adalah persimpangan: dengan demikian, kita akan memiliki fitur yang ada jika dan hanya jika kata "pony" ada di dokumen dan kueri, dan fitur lain yang ada jika dan hanya jika kata "the" ada di dokumen dan 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 tingkat kompleksitas yang sesuai untuk suatu model, tetapi hanya aturan ini yang perlu Anda ketahui. Saya sering berkomunikasi dengan orang-orang yang ragu bahwa apa pun bisa dipelajari dari seribu contoh, atau Anda perlu lebih dari satu juta contoh, karena mereka terjebak dalam metode pembelajaran tertentu. Kuncinya adalah menskalakan pembelajaran Anda ke ukuran data Anda:

  1. Jika Anda bekerja menggunakan sistem peringkat penelusuran, dan ada jutaan kata berbeda dalam dokumen dan kueri, serta Anda memiliki 1.000 contoh berlabel, Anda harus menggunakan produk titik di antara fitur dokumen dan kueri, TF-IDF, serta setengah lusin fitur lainnya yang direkayasa oleh manusia. 1.000 contoh, selusin fitur.
  2. Jika Anda memiliki satu juta contoh, hubungkan kolom fitur dokumen dan kueri, menggunakan regularisasi dan mungkin pemilihan fitur. Ini akan memberi Anda jutaan fitur, tetapi dengan regularisasi, Anda akan memiliki lebih sedikit fitur. Sepuluh juta contoh, mungkin seratus ribu fitur.
  3. Jika Anda memiliki miliaran atau ratusan miliar contoh, Anda dapat melintasi kolom fitur dengan token dokumen dan kueri, menggunakan pemilihan fitur dan regularisasi. Anda akan memiliki satu miliar contoh dan 10 juta fitur. Teori pembelajaran statistik jarang memberikan batasan yang ketat, tetapi memberikan panduan yang bagus sebagai titik awal.

Di bagian akhir, gunakan Aturan #28 untuk menentukan fitur yang akan digunakan.

Aturan #22: Bersihkan fitur yang tidak digunakan lagi.

Fitur yang tidak digunakan akan menimbulkan utang teknis. Jika ternyata Anda tidak menggunakan suatu fitur, dan menggabungkannya dengan fitur lain tidak berfungsi, hapus fitur tersebut dari infrastruktur Anda. Anda ingin menjaga infrastruktur Anda tetap bersih sehingga fitur yang paling menjanjikan dapat dicoba secepat mungkin. Jika perlu, seseorang dapat menambahkan kembali fitur Anda kapan saja.

Ingatlah cakupan saat mempertimbangkan fitur apa yang akan ditambahkan atau disimpan. Berapa banyak contoh yang dicakup oleh fitur ini? Misalnya, jika Anda memiliki beberapa fitur personalisasi, tetapi hanya 8% pengguna yang memiliki fitur personalisasi, fitur tersebut tidak akan 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 tersebut positif, maka fitur tersebut akan sangat bagus untuk ditambahkan.

Analisis Manusia terhadap Sistem

Sebelum melanjutkan ke fase ketiga machine learning, Anda perlu berfokus pada sesuatu yang tidak diajarkan di kelas machine learning mana pun: cara melihat model yang sudah ada dan meningkatkannya. Ini lebih merupakan seni daripada ilmu, tetapi ada beberapa antipola yang bisa dihindari.

Aturan #23: Anda bukan pengguna akhir biasa.

Ini mungkin cara termudah bagi tim untuk terjebak. Meskipun ada banyak manfaat dari fishfood (menggunakan prototipe dalam tim Anda) dan dogfood (menggunakan prototipe dalam perusahaan), karyawan harus melihat apakah performanya sudah benar. Meskipun perubahan yang jelas buruk tidak boleh digunakan, apa pun yang terlihat cukup dekat dengan tahap produksi harus diuji lebih lanjut, baik dengan membayar orang awam untuk menjawab pertanyaan di platform crowdsource, atau melalui eksperimen langsung pada pengguna sungguhan.

Ada dua alasan untuk ini. Yang pertama adalah Anda terlalu dekat dengan kodenya. Anda mungkin mencari aspek tertentu dari postingan, atau Anda terlalu terlibat secara emosional (mis. bias konfirmasi). Yang kedua adalah waktu Anda terlalu berharga. Pertimbangkan biaya sembilan engineer yang duduk dalam rapat satu jam, dan pikirkan berapa banyak label manusia terkontrak yang melakukan pembelian di platform crowdsource.

Jika Anda benar-benar ingin mendapatkan masukan pengguna, gunakan metodologi pengalaman pengguna. Buat persona pengguna (salah satu deskripsinya ada dalam Sketching User Experiences milik Bill Buxton) di awal proses dan lakukan pengujian kegunaan (salah satu deskripsinya ada di Don’t Make Me Think milik Steve Krug) nanti. Persona pengguna melibatkan pembuatan pengguna fiktif. Misalnya, jika tim Anda semuanya laki-laki, mungkin akan membantu mendesain persona pengguna perempuan berusia 35 tahun (lengkap dengan fitur pengguna), dan melihat hasil yang dihasilkan, bukan 10 hasil untuk laki-laki berusia 25 hingga 40 tahun. Mengundang pengguna aktual untuk mengamati reaksi mereka terhadap situs Anda (secara lokal atau jarak jauh) dalam pengujian kegunaan juga dapat memberi Anda perspektif baru.

Aturan #24: Ukur delta di antara model.

Salah satu pengukuran yang paling mudah dan terkadang paling berguna yang dapat Anda lakukan sebelum pengguna melihat model baru Anda adalah dengan menghitung perbedaan hasil baru dari produksi. Misalnya, jika Anda mengalami masalah peringkat, jalankan kedua model pada sampel kueri di seluruh sistem, dan lihat ukuran perbedaan simetris hasil (diukur berdasarkan posisi peringkat). Jika perbedaannya sangat kecil, Anda dapat mengetahui tanpa menjalankan eksperimen bahwa akan ada sedikit perubahan. Jika perbedaannya sangat besar, maka Anda harus memastikan perubahannya baik. Melihat kueri yang memiliki perbedaan simetris yang tinggi dapat membantu Anda memahami perubahannya secara kualitatif. Namun, pastikan sistemnya stabil. Pastikan bahwa jika dibandingkan dengan model itu sendiri, memiliki perbedaan simetris yang rendah (idealnya nol).

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

Model Anda dapat mencoba memprediksi rasio klik-tayang. Namun, pada akhirnya, pertanyaan utamanya adalah apa yang Anda lakukan dengan prediksi tersebut. Jika Anda menggunakannya untuk menentukan peringkat dokumen, kualitas peringkat akhir lebih penting daripada prediksi itu sendiri. Jika Anda memprediksi kemungkinan bahwa sebuah dokumen adalah spam, kemudian memiliki batas pada bagian yang diblokir, presisi mengenai hal yang diizinkan akan lebih diutamakan. Kedua hal ini sering kali harus disepakati: jika mereka tidak sepakat, kemungkinan keduanya hanya akan memberikan sedikit keuntungan. Oleh karena itu, jika ada beberapa perubahan yang meningkatkan hilangnya log tetapi menurunkan performa sistem, cari fitur lain. Ketika hal ini mulai lebih sering terjadi, saatnya untuk meninjau kembali tujuan model Anda.

Aturan #26: Cari pola dalam error yang diukur, lalu buat fitur baru.

Misalkan Anda melihat contoh pelatihan bahwa modelnya "salah". Dalam tugas klasifikasi, error ini bisa berupa positif palsu atau negatif palsu. Dalam tugas peringkat, error bisa berupa pasangan dengan peringkat positif lebih rendah dari negatif. Poin yang paling penting adalah contoh ini menunjukkan bahwa sistem machine learning mengetahui bahwa sistem tersebut keliru dan ingin memperbaikinya jika ada kesempatan. Jika Anda memberi model fitur yang memungkinkannya memperbaiki error, model akan mencoba menggunakannya.

Di sisi lain, jika Anda mencoba membuat fitur berdasarkan contoh yang tidak dianggap oleh sistem sebagai kesalahan, fitur tersebut akan diabaikan. Misalnya, anggaplah seseorang menelusuri "game gratis" di Penelusuran Aplikasi Play. Misalkan salah satu hasil teratas adalah aplikasi GAG yang kurang relevan. Jadi, Anda membuat fitur untuk "aplikasi GAg". Namun, jika Anda memaksimalkan jumlah penginstalan, dan orang-orang menginstal aplikasi gag saat mereka menelusuri game gratis, fitur "aplikasi GAG" tidak akan memiliki efek yang Anda inginkan.

Setelah Anda memiliki contoh bahwa modelnya salah, cari tren yang berada di luar kumpulan fitur Anda saat ini. Misalnya, jika sistem tampaknya mendemosikan postingan yang lebih panjang, tambahkan panjang postingan. Jangan terlalu spesifik tentang fitur yang Anda tambahkan. Jika Anda akan menambahkan panjang postingan, jangan mencoba menebak arti panjangnya, cukup tambahkan selusin fitur dan model biarkan mencari tahu cara untuk menambah panjang postingan (lihat Aturan #21 ). Itu adalah cara termudah untuk mendapatkan apa yang Anda inginkan.

Aturan #27: Cobalah untuk mengukur perilaku yang tidak diinginkan dan diamati.

Beberapa anggota tim akan mulai frustrasi dengan properti sistem yang tidak mereka sukai yang tidak ditangkap oleh fungsi kerugian yang ada. Pada titik ini, mereka harus melakukan apa pun yang diperlukan untuk mengubah pegangan mereka menjadi angka yang solid. Misalnya, jika menurut mereka terlalu banyak "aplikasi gag" ditampilkan di Penelusuran Play, mereka dapat meminta pelabel manusia untuk mengidentifikasi aplikasi gag. (Dalam kasus ini, Anda dapat menggunakan data berlabel manusia dengan baik karena sebagian kecil kueri mencakup sebagian besar traffic.) Jika masalah Anda dapat diukur, Anda dapat mulai menggunakannya sebagai fitur, tujuan, atau metrik. Aturan umumnya adalah "ukur dulu, optimalkan kedua".

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

Bayangkan Anda memiliki sistem baru yang melihat setiap doc_id danexact_query, lalu menghitung probabilitas klik untuk setiap dokumen untuk setiap kueri. Anda mendapati bahwa perilakunya hampir identik dengan sistem Anda saat ini di kedua sisi dan pengujian A/B, sehingga mengingat kesederhanaannya, Anda meluncurkannya. Namun, Anda melihat bahwa tidak ada aplikasi baru yang ditampilkan. Mengapa demikian? Karena sistem Anda hanya menampilkan dokumen berdasarkan historinya sendiri dengan kueri tersebut, maka tidak ada cara untuk mengetahui apakah dokumen baru harus ditampilkan.

Satu-satunya cara untuk memahami cara kerja sistem semacam itu dalam jangka panjang adalah dengan melatihnya hanya pada data yang diperoleh saat model aktif. Ini sangat sulit.

Kemiringan Penyajian Pelatihan

Kemiringan pelatihan-penyaluran adalah perbedaan antara performa selama pelatihan dan performa selama penayangan. Kecenderungan ini dapat disebabkan oleh:

  • Perbedaan antara cara Anda menangani data di pipeline pelatihan dan penyaluran.
  • Perubahan data antara saat Anda berlatih dan saat Anda melakukan penayangan.
  • Umpan balik antara model dan algoritma Anda.

Kami telah mengamati sistem machine learning produksi di Google dengan kecenderungan penyusunan pelatihan yang negatif berdampak negatif pada performa. Solusi terbaik adalah memantaunya secara eksplisit sehingga perubahan sistem dan data tidak menimbulkan kecondongan tanpa diketahui.

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

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

Aturan #30: Data sampel dengan bobot nilai penting, jangan secara sewenang-wenang!

Jika memiliki terlalu banyak data, Anda mungkin tergoda untuk mengambil file 1-12, dan mengabaikan file 13-99. Ini adalah kesalahan. Meskipun data yang tidak pernah ditampilkan kepada pengguna dapat dihapus, pembobotan nilai penting paling baik untuk sisanya. Pembobotan kepentingan berarti jika Anda memutuskan bahwa Anda akan mengambil sampel contoh X dengan probabilitas 30%, maka berikan bobot 10/3. Dengan bobot nilai penting, semua properti kalibrasi yang dibahas dalam Aturan #14 masih berlaku.

Aturan #31: Waspadalah jika Anda menggabungkan data dari tabel pada waktu pelatihan dan penyajian, data dalam tabel dapat berubah.

Misalnya Anda menggabungkan ID dokumen dengan tabel yang berisi fitur untuk dokumen tersebut (seperti jumlah komentar atau klik). Antara waktu pelatihan dan penayangan, fitur dalam tabel dapat diubah. Prediksi model Anda untuk dokumen yang sama mungkin berbeda antara pelatihan dan penayangan. Cara termudah untuk menghindari masalah semacam ini adalah dengan mencatat fitur ke dalam log pada waktu inferensi (lihat Aturan #32). Jika tabel hanya berubah perlahan, Anda juga dapat membuat snapshot tabel setiap jam atau setiap hari untuk mendapatkan data penutupan yang wajar. Perlu diperhatikan bahwa langkah ini tetap tidak menyelesaikan masalah sepenuhnya.

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

Batch processing berbeda dengan pemrosesan online. Dalam pemrosesan online, Anda harus menangani setiap permintaan saat permintaan tersebut tiba (misalnya, Anda harus melakukan pencarian terpisah untuk setiap kueri), sedangkan dalam batch processing, Anda dapat menggabungkan tugas (misalnya membuat join). Pada waktu penayangan, Anda melakukan pemrosesan online, sedangkan pelatihan adalah tugas batch processing. Namun, ada beberapa hal yang dapat Anda lakukan untuk menggunakan kembali kode tersebut. Misalnya, Anda dapat membuat objek khusus untuk sistem Anda, tempat hasil kueri atau gabungan dapat disimpan dengan cara yang sangat mudah dibaca manusia, dan error dapat diuji dengan mudah. Kemudian, setelah mengumpulkan semua informasi, selama penayangan atau pelatihan, Anda menjalankan metode umum untuk menjembatani objek yang dapat dibaca manusia yang spesifik untuk sistem Anda, dan format apa pun yang diharapkan oleh sistem machine learning. Hal ini menghilangkan sumber kecondongan penyaluran pelatihan. Sebagai konsekuensi, cobalah untuk tidak menggunakan dua bahasa pemrograman yang berbeda antara pelatihan dan penayangan. Keputusan tersebut akan membuat Anda hampir tidak mungkin untuk membagikan kode.

Aturan #33: Jika Anda membuat model berdasarkan data hingga 5 Januari, uji model pada data mulai dari 6 Januari dan setelahnya.

Secara umum, ukur performa model pada data yang dikumpulkan setelah data yang digunakan untuk melatih model, karena hal ini lebih mencerminkan apa yang akan dilakukan sistem Anda dalam produksi. Jika Anda memproduksi model berdasarkan data hingga 5 Januari, uji model pada data mulai 6 Januari. Anda akan berharap bahwa performanya tidak akan terlalu bagus pada data baru, tetapi seharusnya tidak lebih buruk secara drastis. Karena mungkin ada efek harian, Anda mungkin tidak dapat memprediksi rasio klik atau rasio konversi rata-rata, tetapi area di bawah kurva, yang mewakili kemungkinan untuk memberi contoh positif skor yang lebih tinggi daripada contoh negatif, seharusnya cukup mendekati.

Aturan #34: Dalam klasifikasi biner untuk pemfilteran (seperti deteksi spam atau menentukan email yang menarik), lakukan pengorbanan kecil dalam kinerja jangka pendek untuk mendapatkan 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 saat penayangan. Anda mungkin tergoda untuk mengambil data pelatihan tambahan dari instance yang ditampilkan kepada pengguna. Misalnya, jika pengguna menandai email sebagai spam yang diberikan oleh filter Anda, Anda mungkin ingin mempelajarinya.

Tetapi pendekatan ini memperkenalkan bias {i>sampling<i}. Sebagai gantinya, Anda dapat mengumpulkan data yang lebih bersih jika selama penayangan, Anda memberi label 1% dari semua traffic sebagai "dipisahkan", dan mengirim semua contoh yang ditangguhkan kepada pengguna. Sekarang filter Anda memblokir setidaknya 74% contoh negatif. Contoh yang ditampilkan ini bisa menjadi data pelatihan Anda.

Perhatikan bahwa jika filter Anda memblokir 95% contoh negatif atau lebih, pendekatan ini menjadi kurang layak. Meskipun demikian, jika ingin mengukur performa penayangan, Anda dapat membuat sampel yang lebih kecil (misalnya 0,1% atau 0,001%). Sepuluh ribu contoh sudah cukup untuk memperkirakan performa secara akurat.

Aturan #35: Waspadai kecondongan inheren dalam masalah peringkat.

Saat Anda mengganti algoritme peringkat secara cukup signifikan sehingga hasil yang ditampilkan berbeda, Anda telah secara efektif mengubah data yang akan dilihat algoritme di masa mendatang. Kecondongan semacam ini akan muncul, dan Anda harus mendesain model di seputarnya. Ada beberapa pendekatan yang berbeda. Pendekatan ini adalah semua cara untuk mendukung data yang telah dilihat oleh model Anda.

  1. Memiliki regularisasi yang lebih tinggi pada fitur yang mencakup lebih banyak kueri dibandingkan fitur yang diaktifkan hanya untuk satu kueri. Dengan cara ini, model akan lebih memilih fitur yang spesifik untuk satu atau beberapa kueri dibandingkan fitur yang bersifat umum untuk semua kueri. Pendekatan ini dapat membantu mencegah hasil yang sangat populer bocor ke kueri yang tidak relevan. Perlu diperhatikan bahwa hal ini bertentangan dengan saran yang lebih konvensional untuk memiliki lebih banyak regularisasi pada kolom fitur dengan nilai yang lebih unik.
  2. Hanya izinkan fitur yang memiliki bobot positif. Dengan demikian, fitur yang bagus akan lebih baik daripada fitur yang "tidak diketahui".
  3. Tidak memiliki fitur khusus dokumen. Ini adalah versi ekstrem dari #1. Misalnya, meskipun aplikasi tertentu adalah download yang populer terlepas dari kuerinya, Anda tidak ingin menampilkannya di mana-mana. Tidak memiliki fitur hanya dokumen membuat hal itu tetap sederhana. Alasan Anda tidak ingin menampilkan aplikasi populer tertentu di mana-mana berkaitan dengan pentingnya membuat semua aplikasi yang diinginkan dapat dijangkau. Misalnya, jika seseorang menelusuri "aplikasi mengamati burung", mereka mungkin akan mendownload "burung pemarah", tetapi itu jelas bukan tujuan mereka. Menampilkan aplikasi seperti itu dapat meningkatkan rasio download, tetapi membiarkan kebutuhan pengguna tidak terpenuhi.

Aturan #36: Hindari feedback loop dengan fitur posisi.

Posisi konten sangat memengaruhi seberapa besar kemungkinan pengguna berinteraksi dengannya. Jika Anda menempatkan aplikasi di posisi pertama, aplikasi akan lebih sering diklik, dan Anda akan yakin aplikasi tersebut kemungkinan besar akan diklik. Salah satu cara untuk menangani hal ini adalah dengan menambahkan fitur posisi, yaitu fitur tentang posisi konten di halaman. Anda melatih model dengan fitur posisi, dan model akan belajar memberi bobot, misalnya, fitur "1stposition" berat. Model Anda sehingga memberikan lebih sedikit bobot pada faktor lain misalnya dengan "1stposition=true". Kemudian, saat penayangan, Anda tidak memberikan fitur posisi pada instance apa pun, atau memberikan semua fitur default yang sama kepada instance tersebut, karena Anda menilai kandidat sebelum memutuskan urutan tampilannya.

Perhatikan bahwa penting untuk menjaga setiap fitur posisi agak terpisah dari model lainnya karena asimetri antara pelatihan dan pengujian ini. Idealnya, model merupakan jumlah dari fungsi fitur posisi dan fungsi dari fitur lainnya. Misalnya, jangan silang fitur posisi dengan fitur dokumen apa pun.

Aturan #37: Ukur Kemiringan Pelatihan/Penyajian.

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

  • Perbedaan antara performa pada data pelatihan dan data pisahan. Secara umum, ini akan selalu ada, dan tidak selalu buruk.
  • Perbedaan antara performa pada data pisahan dan data "hari berikutnya". Sekali lagi, hal ini akan selalu ada. Anda harus menyesuaikan regularisasi untuk memaksimalkan performa pada hari berikutnya. Namun, penurunan besar pada performa antara data pisahan dan hari berikutnya dapat mengindikasikan bahwa beberapa fitur sensitif terhadap waktu dan mungkin menurunkan performa model.
  • Perbedaan antara performa pada data "hari berikutnya" dan data langsung. Jika Anda menerapkan model pada contoh dalam data pelatihan dan contoh yang sama pada penayangan, Anda akan mendapatkan hasil yang sama persis (lihat Aturan #5). Oleh karena itu, perbedaan di sini mungkin menunjukkan error engineering.

ML Tahap III: Pertumbuhan yang Lambat, Peningkatan Pengoptimalan, dan Model Kompleks

Akan ada indikasi tertentu bahwa fase kedua semakin dekat. Pertama-tama, keuntungan bulanan Anda akan mulai berkurang. Anda akan mulai mengalami kerugian antarmetrik: Anda akan melihat beberapa peningkatan dan sebagian lainnya turun dalam beberapa eksperimen. Di sinilah pembahasan akan menjadi menarik. Karena keuntungan lebih sulit dicapai, machine learning harus menjadi lebih canggih. Peringatan: bagian ini memiliki lebih banyak aturan langit biru daripada bagian sebelumnya. Kami telah melihat banyak tim melewati masa-masa membahagiakan {i>machine learning<i} Tahap I dan Fase II. Setelah Tahap III tercapai, tim harus menemukan jalur mereka sendiri.

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

Setelah data pengukuran Anda stabil, tim Anda akan mulai melihat masalah yang berada di luar cakupan tujuan sistem machine learning Anda saat ini. Seperti yang dinyatakan sebelumnya, jika sasaran produk tidak tercakup oleh tujuan algoritme yang ada, Anda perlu mengubah tujuan atau sasaran produk Anda. Misalnya, Anda dapat mengoptimalkan klik, plus-satu, atau download, tetapi membuat keputusan peluncuran berdasarkan sebagian dari penilai manusia.

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

Alice memiliki ide untuk mengurangi kerugian logistik dari memprediksi penginstalan. Dia menambahkan sebuah fitur. Kerugian logistik menurun. Saat melakukan eksperimen langsung, dia melihat peningkatan rasio instal. Namun, saat dia menghadiri rapat peninjauan 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 beberapa kriteria, hanya beberapa di antaranya yang dapat dioptimalkan secara langsung menggunakan ML.

Faktanya, dunia nyata bukanlah ruang bawah tanah dan naga: tidak ada "titik sasaran" yang mengidentifikasi kesehatan produk Anda. Tim harus menggunakan statistik yang dikumpulkan untuk mencoba memprediksi secara efektif seberapa baik sistem di masa depan. Mereka perlu memperhatikan engagement, pengguna aktif 1 hari (DAU), 30 DAU, pendapatan, dan laba atas investasi pengiklan. Metrik yang dapat diukur dalam pengujian A/B ini sendiri hanyalah proxy untuk tujuan jangka panjang: memuaskan pengguna, meningkatkan pengguna, memuaskan partner, dan keuntungan, yang meskipun dengan demikian, Anda dapat mempertimbangkan proxy untuk memiliki produk berkualitas tinggi yang berguna, dan perusahaan yang berkembang dalam lima tahun dari sekarang.

Satu-satunya keputusan peluncuran yang mudah adalah ketika semua metrik menjadi lebih baik (atau setidaknya tidak menjadi lebih buruk). Jika tim memiliki pilihan antara algoritme machine learning yang canggih dan heuristik sederhana, jika heuristik sederhana melakukan pekerjaan yang lebih baik pada semua metrik ini, maka harus memilih heuristik tersebut. Selain itu, tidak ada peringkat eksplisit untuk semua nilai metrik yang mungkin. Secara khusus, pertimbangkan dua skenario berikut:

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

Jika sistem saat ini adalah A, maka kemungkinan tim tidak akan beralih ke B. Jika sistem saat ini adalah B, maka kemungkinan tim tidak akan beralih ke A. Hal ini tampaknya bertentangan dengan perilaku rasional; namun, prediksi perubahan metrik mungkin atau mungkin tidak akan berhasil, dan dengan demikian ada risiko besar yang terkait dengan perubahan tersebut. Setiap metrik mencakup beberapa risiko yang berkaitan dengan tim.

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

Di sisi lain, individu cenderung mendukung satu tujuan yang dapat mereka optimalkan secara langsung. Sebagian besar alat machine learning mendukung lingkungan seperti itu. Seorang engineer yang meluncurkan fitur baru bisa mendapatkan aliran peluncuran yang stabil di lingkungan tersebut. Ada jenis machine learning, pembelajaran multi-tujuan, yang akan mulai mengatasi masalah ini. Misalnya, seseorang dapat merumuskan masalah kepuasan batasan yang memiliki batas lebih rendah pada setiap metrik, dan mengoptimalkan beberapa kombinasi linear metrik. Namun, meskipun demikian, tidak semua metrik mudah dibingkai sebagai tujuan machine learning: jika dokumen diklik atau aplikasi diinstal, hal itu karena konten yang ditampilkan. Namun, jauh lebih sulit untuk mencari tahu alasan pengguna mengunjungi situs Anda. Cara memprediksi keberhasilan situs secara keseluruhan di masa mendatang adalah AI-complete: sesulit visi komputer atau natural language processing.

Aturan #40: Jaga agar ansambel tetap sederhana.

Model terpadu yang menggunakan fitur mentah dan langsung memberi peringkat konten adalah model yang paling mudah untuk di-debug dan dipahami. Namun, ansambel model ("model" yang menggabungkan skor model lain) dapat berfungsi lebih baik. Agar mudah, setiap model harus berupa ensemble yang hanya menggunakan input dari model lain, atau model dasar yang menggunakan banyak fitur, tetapi tidak keduanya. Jika Anda memiliki model di atas model lain yang dilatih secara terpisah, penggabungan model tersebut dapat menghasilkan perilaku buruk.

Gunakan model sederhana untuk ansambel yang hanya menggunakan output dari model "dasar" sebagai input. Anda juga ingin menerapkan properti pada model ensemble ini. Misalnya, peningkatan skor yang dihasilkan oleh model dasar tidak boleh mengurangi skor ansambel. Selain itu, sebaiknya model yang masuk dapat ditafsirkan secara semantik (misalnya, dikalibrasi) sehingga perubahan model yang mendasarinya tidak membingungkan model ansambel. Selain itu, menerapkan bahwa peningkatan probabilitas yang diprediksi dari pengklasifikasi dasar tidak akan mengurangi probabilitas yang diprediksi dari ansambel.

Aturan #41: Saat performa stabil, cari sumber informasi 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 mempelajari eksplorasi template dan menyesuaikan regularisasi. Dalam beberapa kuartal, Anda belum melihat peluncuran dengan peningkatan lebih dari 1% pada metrik utama. Apa langkah selanjutnya?

Saatnya mulai membangun infrastruktur untuk berbagai fitur yang benar-benar berbeda, seperti histori dokumen yang diakses pengguna ini dalam sehari, seminggu, atau setahun terakhir, atau data dari properti yang berbeda. Gunakan entity wikidata atau hal lain yang bersifat internal untuk perusahaan Anda (seperti grafik pengetahuan Google). Menggunakan deep learning. Mulailah menyesuaikan ekspektasi Anda terhadap berapa banyak laba atas investasi, dan perluas upaya Anda sesuai dengan itu. Seperti dalam project teknik apa pun, Anda harus mempertimbangkan manfaat penambahan fitur baru dan bandingkan dengan biaya peningkatan kompleksitas.

Aturan #42: Jangan mengharapkan keberagaman, personalisasi, atau relevansi berkolerasi dengan popularitas seperti yang Anda pikirkan.

Keberagaman dalam serangkaian konten dapat berarti banyak hal, dan keragaman sumber konten menjadi salah satu yang paling umum. Personalisasi menyiratkan setiap pengguna mendapatkan hasil mereka sendiri. Relevansi menyiratkan bahwa hasil untuk kueri tertentu lebih sesuai untuk kueri tersebut daripada yang lain. Dengan demikian, ketiga properti ini dapat dianggap berbeda dari yang biasa.

Masalahnya adalah hal yang biasa cenderung sulit dikalahkan.

Perhatikan bahwa jika sistem Anda mengukur klik, waktu yang dihabiskan, sesi tonton, +1, pembagian ulang, dan sebagainya, berarti Anda mengukur populer konten. Tim terkadang mencoba mempelajari model pribadi dengan keberagaman. Untuk mempersonalisasi, ekstensi menambahkan fitur yang memungkinkan sistem melakukan personalisasi (beberapa fitur yang mewakili minat pengguna) atau diversifikasi (fitur yang menunjukkan apakah dokumen ini memiliki fitur yang sama dengan dokumen lain yang ditampilkan, seperti penulis atau konten), dan mendapati bahwa fitur tersebut mendapatkan bobot yang lebih sedikit (atau terkadang tanda yang berbeda) dari yang mereka harapkan.

Hal ini tidak berarti bahwa keberagaman, personalisasi, atau relevansi tidak bermanfaat. Seperti yang ditunjukkan dalam aturan sebelumnya, Anda dapat melakukan pascapemrosesan untuk meningkatkan keragaman atau relevansi. Jika tujuan jangka panjang terlihat meningkat, Anda dapat mendeklarasikan bahwa keberagaman/relevansi itu berharga, selain popularitas. Kemudian, Anda dapat melanjutkan menggunakan pascapemrosesan Anda, atau langsung memodifikasi objektif tersebut berdasarkan keberagaman atau relevansi.

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

Tim di Google mendapatkan banyak daya tarik dengan mengambil model yang memprediksi kedekatan hubungan dalam satu produk, dan membuatnya berfungsi dengan baik di produk lain. Teman Anda adalah siapa mereka. Di sisi lain, saya telah melihat beberapa tim berjuang dengan fitur personalisasi di seluruh pembagian produk. Ya, sepertinya aplikasi ini akan berhasil. Untuk saat ini, sepertinya tidak demikian. Yang terkadang berhasil adalah menggunakan data mentah dari satu properti untuk memprediksi perilaku di properti lain. Selain itu, perlu diingat bahwa mengetahui bahwa pengguna memiliki histori di properti lain juga dapat membantu. Misalnya, kehadiran aktivitas pengguna pada dua produk mungkin bersifat indikatif.

Ada banyak dokumen tentang machine learning, baik di Google maupun di luar organisasi.

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 Gihihers, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Tal Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Konstantinos. Terima kasih juga kepada Kristen Lefevre, Suddha Basu, dan Chris Berg yang telah membantu pembuatan versi sebelumnya. Setiap kesalahan, kelalaian, atau (terkejut) pendapat yang tidak populer adalah milik saya.

Lampiran

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

Ringkasan YouTube

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

Ringkasan Google Play

Google Play memiliki banyak model yang memecahkan berbagai masalah. Aplikasi Penelusuran, Mainkan, dan Rekomendasi yang Dipersonalisasi di Halaman Beranda, serta aplikasi 'Pengguna Juga Menginstal' semuanya menggunakan machine learning.

Ringkasan Google Plus

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