Aturan Machine Learning:

Praktik Terbaik untuk Rekayasa ML

Martin Zinkevich

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

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

Terminologi

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

  • Instance: Hal yang ingin Anda buat prediksinya. Misalnya, instance mungkin berupa 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 adalah "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 negara yang mungkin menjadi tempat tinggal pengguna. Contoh mungkin memiliki satu atau beberapa fitur yang ada di 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 pada contoh, lalu menggunakan model tersebut untuk membuat prediksi.
  • Metrik: Angka yang penting bagi Anda. Mungkin dioptimalkan secara langsung atau tidak.
  • Tujuan: Metrik yang coba dioptimalkan oleh algoritma Anda.
  • Pipeline: Infrastruktur yang mengelilingi algoritma machine learning. Mencakup pengumpulan data dari frontend, 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 di iklan.

Ringkasan

Untuk membuat produk yang bagus:

lakukan machine learning seperti engineer hebat yang Anda miliki, bukan seperti pakar machine learning hebat yang tidak Anda miliki.

Sebagian besar masalah yang akan Anda hadapi sebenarnya adalah masalah teknik. Meskipun memiliki semua referensi dari pakar machine learning yang hebat, sebagian besar keuntungan berasal dari fitur yang hebat, bukan algoritma machine learning yang hebat. Jadi, pendekatan dasar adalah:

  1. Pastikan pipeline Anda solid dari awal hingga akhir.
  2. Mulailah dengan tujuan yang wajar.
  3. Menambahkan fitur yang masuk akal dengan cara yang sederhana.
  4. Pastikan pipeline Anda tetap solid.

Pendekatan ini akan berfungsi dengan baik selama waktu yang lama. Beralih dari pendekatan ini hanya jika tidak ada lagi trik sederhana untuk membuat Anda lebih maju. Menambahkan kompleksitas akan memperlambat rilis mendatang.

Setelah Anda mencoba semua trik sederhana, machine learning canggih mungkin memang akan menjadi masa depan Anda. Lihat bagian tentang project machine learning Fase III.

Dokumen ini disusun sebagai berikut:

  1. Bagian pertama akan membantu Anda memahami apakah waktunya tepat untuk membuat sistem machine learning.
  2. Bagian kedua membahas deployment pipeline pertama Anda.
  3. Bagian ketiga membahas peluncuran dan iterasi saat menambahkan fitur baru ke pipeline, cara mengevaluasi model, dan diferensiasi performa pelatihan dan penayangan.
  4. Bagian akhir membahas hal yang harus dilakukan saat 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 untuk meluncurkan produk tanpa machine learning.

Machine learning memang keren, tetapi memerlukan data. Secara teori, Anda dapat mengambil data dari masalah yang berbeda, lalu menyesuaikan model untuk produk baru, tetapi hal ini kemungkinan akan berperforma lebih buruk daripada heuristik dasar. Jika Anda berpikir bahwa machine learning akan memberikan peningkatan 100%, heuristik akan memberikan peningkatan 50% dari total peningkatan tersebut.

Misalnya, jika Anda membuat peringkat aplikasi di marketplace aplikasi, Anda dapat menggunakan rasio penginstalan atau jumlah penginstalan sebagai heuristik. Jika Anda mendeteksi spam, filter penayang yang pernah mengirim spam. Jangan takut untuk menggunakan pengeditan manusia. Jika Anda perlu memberi peringkat kontak, beri peringkat tertinggi pada kontak yang paling baru digunakan (atau bahkan beri peringkat menurut abjad). Jika machine learning tidak benar-benar diperlukan untuk produk Anda, jangan gunakan hingga Anda memiliki data.

Aturan #2: Pertama, desain dan terapkan metrik.

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

  1. Lebih mudah untuk mendapatkan izin dari pengguna sistem lebih awal.
  2. Jika Anda merasa ada masalah di masa mendatang, sebaiknya dapatkan data historis sekarang.
  3. Jika Anda mendesain sistem dengan mempertimbangkan instrumentasi metrik, semuanya akan berjalan lebih baik untuk Anda di masa mendatang. Secara khusus, Anda tidak ingin mencari string di log untuk membuat instrumen metrik.
  4. Anda akan melihat hal-hal yang berubah dan hal-hal yang tetap sama. Misalnya, Anda ingin langsung mengoptimalkan pengguna aktif harian. Namun, selama manipulasi awal sistem, Anda mungkin melihat bahwa perubahan drastis pada pengalaman pengguna tidak mengubah metrik ini secara signifikan.

Tim Google Plus mengukur perluasan per pembacaan, pembagian ulang per pembacaan, plus-one per pembacaan, komentar/pembacaan, komentar per pengguna, pembagian ulang per pengguna, dll. yang mereka gunakan dalam menghitung kualitas postingan pada waktu penayangan. Selain itu, perhatikan bahwa framework eksperimen, tempat Anda dapat mengelompokkan pengguna ke dalam bucket dan menggabungkan statistik menurut eksperimen, sangat penting. Lihat Aturan #12.

Dengan lebih fleksibel dalam mengumpulkan metrik, Anda bisa mendapatkan gambaran yang lebih luas tentang sistem Anda. Melihat masalah? Tambahkan metrik untuk melacaknya. Bersemangat dengan beberapa perubahan kuantitatif pada rilis terakhir? Tambahkan metrik untuk melacaknya.

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

Heuristik sederhana dapat membuat produk Anda siap diluncurkan. Heuristik yang kompleks tidak dapat dikelola. Setelah memiliki data dan gambaran dasar tentang apa yang ingin Anda capai, lanjutkan ke machine learning. Seperti pada sebagian besar tugas teknik software, Anda harus terus memperbarui pendekatan, baik itu heuristik maupun model machine learning, dan Anda akan mendapati bahwa model machine learning lebih mudah diperbarui dan dikelola (lihat Aturan #16).

ML Fase 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 mengetahui apa yang terjadi jika Anda tidak memercayai pipeline terlebih dahulu.

Aturan #4: Pastikan model pertama tetap sederhana dan infrastrukturnya tepat.

Model pertama memberikan peningkatan terbesar pada produk Anda, sehingga tidak perlu berlebihan. Namun, Anda akan mengalami lebih banyak masalah infrastruktur daripada yang diharapkan. Sebelum siapa pun dapat menggunakan sistem machine learning baru yang canggih, Anda harus menentukan:

  • Cara mendapatkan contoh untuk algoritma pembelajaran Anda.
  • Potongan pertama tentang arti "baik" dan "buruk" bagi sistem Anda.
  • Cara mengintegrasikan model ke dalam aplikasi. Anda dapat menerapkan model secara langsung, atau menghitung model terlebih dahulu pada contoh secara offline dan menyimpan hasilnya dalam tabel. Misalnya, Anda mungkin ingin melakukan pra-klasifikasi halaman web dan menyimpan hasilnya dalam tabel, tetapi Anda mungkin ingin mengklasifikasikan pesan chat secara langsung.

Memilih fitur sederhana akan memudahkan Anda untuk memastikan bahwa:

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

Setelah memiliki sistem yang melakukan ketiga hal ini dengan andal, Anda telah melakukan sebagian besar pekerjaan. Model sederhana Anda memberikan metrik dasar pengukuran dan perilaku dasar pengukuran yang dapat Anda gunakan untuk menguji model yang lebih kompleks. Beberapa tim menargetkan peluncuran pertama yang "netral": peluncuran pertama yang secara eksplisit mende­prioritaskan keuntungan machine learning, untuk menghindari gangguan.

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

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

  1. Uji cara memasukkan data ke dalam algoritma. Pastikan kolom fitur yang harus diisi telah diisi. Jika privasi mengizinkan, 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 cara mendapatkan 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 elemen yang tidak dapat diprediksi, jadi pastikan Anda memiliki pengujian untuk kode guna 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 Besar dan Kompleks.

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

Sering kali kita membuat pipeline dengan menyalin pipeline yang ada (yaitu, cargo cult programming ), dan pipeline lama akan menghapus data yang kita perlukan untuk pipeline baru. Misalnya, pipeline untuk Google Plus What's Hot akan menghapus postingan lama (karena mencoba memberi peringkat pada postingan baru). Pipeline ini dikopi untuk digunakan di Feed Google Plus, tempat postingan lama masih bermakna, tetapi pipeline masih menghapus postingan lama. Pola umum lainnya adalah hanya mencatat data yang dilihat oleh pengguna. Dengan demikian, data ini tidak berguna jika kita ingin membuat model alasan 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 asal setiap contoh.

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

Biasanya, masalah yang coba dipecahkan oleh machine learning tidak sepenuhnya baru. Ada sistem yang sudah ada untuk menentukan peringkat, atau mengklasifikasikan, atau masalah apa pun yang Anda coba pecahkan. Artinya, ada banyak aturan dan heuristik. Heuristik yang sama ini dapat membantu Anda jika disesuaikan dengan machine learning. Heuristik Anda harus digali untuk mengetahui informasi apa pun yang dimilikinya, karena dua alasan. Pertama, transisi ke sistem pembelajaran mesin akan lebih lancar. Kedua, biasanya aturan tersebut berisi banyak intuisi tentang sistem yang tidak ingin Anda buang. Ada empat cara untuk menggunakan heuristik yang ada:

  • Lakukan prapemrosesan menggunakan heuristik. Jika fiturnya sangat luar biasa, ini adalah opsi yang tepat. Misalnya, jika dalam filter spam, pengirim telah diblokir, jangan mencoba mempelajari kembali arti "diblokir". Blokir pesan. Pendekatan ini paling masuk akal dalam tugas klasifikasi biner.
  • Buat fitur. Membuat fitur langsung dari heuristik sangat bagus. Misalnya, jika menggunakan heuristik untuk menghitung skor relevansi untuk hasil kueri, Anda dapat menyertakan skor sebagai nilai fitur. Nantinya, Anda mungkin ingin menggunakan teknik machine learning untuk memproses nilai (misalnya, mengonversi nilai menjadi salah satu kumpulan nilai diskret yang terbatas, atau menggabungkannya dengan fitur lain), tetapi mulailah dengan menggunakan nilai mentah yang dihasilkan oleh heuristik.
  • Menambang input mentah heuristik. Jika ada heuristik untuk aplikasi yang menggabungkan jumlah penginstalan, jumlah karakter dalam teks, dan hari dalam seminggu, pertimbangkan untuk memisahkan bagian-bagian ini, dan memasukkan input ini ke dalam pembelajaran secara terpisah. Beberapa teknik yang berlaku untuk ensemble berlaku di sini (lihat Aturan #40).
  • Ubah label. Ini adalah opsi jika Anda merasa bahwa heuristik mengambil informasi yang saat ini tidak ada dalam label. Misalnya, jika Anda mencoba memaksimalkan jumlah download, tetapi juga menginginkan konten 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 algoritma machine learning baru dapat membantu menciptakan transisi yang lancar, tetapi pikirkan apakah ada cara yang lebih sederhana untuk mencapai efek yang sama.

Pemantauan

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

Aturan #8: Ketahui persyaratan keaktualan sistem Anda.

Berapa banyak penurunan performa jika Anda memiliki model yang berusia satu hari? Seminggu usianya? Seperempat tahun? Informasi ini dapat membantu Anda memahami prioritas pemantauan. Jika Anda kehilangan kualitas produk yang signifikan jika model tidak diperbarui selama sehari, sebaiknya minta engineer untuk terus memantaunya. 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, hal ini dapat memiliki dampak negatif dalam waktu kurang dari sebulan. Beberapa model untuk Hot di Google Plus tidak memiliki ID postingan dalam modelnya sehingga model ini tidak sering diekspor. Model lain yang memiliki ID postingan lebih sering diperbarui. 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 tempat Anda mengekspor model untuk dilayani. Jika ada masalah dengan model yang diekspor, masalah tersebut adalah masalah yang dihadapi pengguna.

Lakukan pemeriksaan keandalan tepat sebelum Anda mengekspor model. Secara khusus, pastikan performa model wajar pada data yang dikecualikan. Atau, jika Anda masih memiliki masalah dengan data, jangan ekspor model. Banyak tim yang terus men-deploy model memeriksa area di bawah kurva ROC (atau AUC) sebelum mengekspor. Masalah terkait model yang belum diekspor memerlukan pemberitahuan email, tetapi masalah pada model yang ditampilkan kepada pengguna mungkin memerlukan halaman. Jadi, sebaiknya tunggu dan pastikan sebelum memengaruhi pengguna.

Aturan #10: Perhatikan kegagalan yang tidak terdeteksi.

Ini adalah masalah yang lebih sering terjadi pada sistem machine learning daripada jenis sistem lainnya. Misalkan tabel tertentu yang digabungkan tidak lagi diperbarui. Sistem machine learning akan menyesuaikan, dan perilaku akan terus cukup baik, menurun secara bertahap. Terkadang Anda menemukan tabel yang sudah tidak berlaku selama berbulan-bulan, dan pembaruan sederhana akan meningkatkan performa lebih dari peluncuran lainnya pada kuartal tersebut. Cakupan fitur dapat berubah karena perubahan penerapan: misalnya, kolom fitur dapat diisi di 90% contoh, dan tiba-tiba turun menjadi 60% contoh. Play pernah memiliki tabel yang tidak berlaku selama 6 bulan, dan memuat ulang tabel saja meningkatkan frekuensi penginstalan sebesar 2%. Jika melacak statistik data, serta 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 akan keluar, pastikan seseorang memiliki informasi tersebut. Meskipun banyak kolom fitur memiliki nama deskriptif, sebaiknya ada deskripsi yang lebih mendetail tentang fitur tersebut, asalnya, dan manfaatnya.

Tujuan Pertama Anda

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

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

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

Jadi, permudahlah dan jangan terlalu memikirkan cara menyeimbangkan berbagai metrik saat Anda masih dapat dengan mudah meningkatkan semua metrik. Namun, jangan terlalu memaknai aturan ini: jangan sampai tujuan Anda tertukar dengan kesehatan sistem akhir (lihat Aturan #39). Selain itu, jika Anda meningkatkan metrik yang dioptimalkan secara langsung, tetapi memutuskan untuk tidak meluncurkannya, beberapa revisi tujuan mungkin 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 mengira Anda tahu, tetapi saat melihat data dan analisis berdampingan dari sistem lama dan sistem ML baru, Anda menyadari bahwa Anda ingin menyesuaikan tujuan. Selain itu, anggota tim yang berbeda sering kali tidak dapat menyetujui tujuan sebenarnya. Tujuan ML harus sesuatu yang mudah diukur dan merupakan proxy untuk tujuan "sebenarnya". Faktanya, sering kali tidak ada tujuan "sebenarnya" (lihat Aturan#39). Jadi, latihlah pada objektif ML sederhana, dan pertimbangkan untuk memiliki "lapisan kebijakan" di atas yang memungkinkan Anda menambahkan logika tambahan (semoga logika yang sangat sederhana) untuk melakukan penentuan peringkat akhir.

Hal yang paling mudah untuk dibuat modelnya adalah perilaku pengguna yang diamati secara langsung dan dapat diatribusikan ke tindakan sistem:

  • Apakah link yang diberi peringkat ini diklik?
  • Apakah objek yang diberi peringkat ini didownload?
  • Apakah objek yang diberi peringkat ini diteruskan/dibalas/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 pada awalnya:

  • Apakah pengguna mengunjungi situs 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 pengambilan keputusan peluncuran.

Terakhir, jangan mencoba membuat machine learning mengetahui:

  • Apakah pengguna senang menggunakan produk tersebut?
  • Apakah pengguna puas dengan pengalaman tersebut?
  • Apakah produk tersebut meningkatkan kesejahteraan pengguna secara keseluruhan?
  • Bagaimana pengaruhnya terhadap kesehatan perusahaan secara keseluruhan?

Semua hal ini penting, tetapi juga sangat sulit diukur. Sebagai gantinya, gunakan proxy: jika pengguna puas, mereka akan tetap berada di situs lebih lama. Jika pengguna merasa puas, mereka akan mengunjungi lagi besok. Sejauh menyangkut kesejahteraan dan kesehatan perusahaan, penilaian manusia diperlukan untuk menghubungkan tujuan machine learning apa pun 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 secara 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 tujuan (kerugian nol-satu, berbagai kerugian engsel, dan sebagainya) yang mencoba langsung mengoptimalkan akurasi klasifikasi atau performa peringkat. Misalnya, jika probabilitas dalam pelatihan menyimpang dari probabilitas yang diprediksi dalam side-by-side atau dengan memeriksa sistem produksi, penyimpangan ini dapat mengungkap masalah.

Misalnya, dalam regresi linear, logistik, atau Poisson, ada subkumpulan data dengan ekspektasi prediksi rata-rata sama dengan label rata-rata (1- momen dikalibrasi, atau hanya dikalibrasi). Hal ini benar dengan asumsi bahwa Anda tidak memiliki regulasi dan algoritma Anda telah berkonvergensi, dan hal ini kurang lebih benar secara umum. Jika Anda memiliki fitur yang bernilai 1 atau 0 untuk setiap contoh, kumpulan 3 contoh dengan fitur tersebut bernilai 1 akan dikalibrasi. Selain itu, jika Anda memiliki fitur yang bernilai 1 untuk setiap contoh, kumpulan semua contoh akan dikalibrasi.

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

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

Peringkat kualitas adalah seni, tetapi pemfilteran spam adalah perang. Sinyal yang Anda gunakan untuk menentukan postingan berkualitas tinggi akan menjadi jelas bagi pengguna sistem Anda, dan mereka akan menyesuaikan postingan mereka agar memiliki properti ini. Oleh karena itu, peringkat kualitas Anda harus berfokus pada peringkat konten yang diposting dengan niat baik. Anda tidak boleh mengabaikan pengoptimal peringkat kualitas karena memberikan peringkat tinggi pada spam. Demikian pula, konten "vulgar" harus ditangani secara terpisah dari Peringkat Kualitas. Pemfilteran spam adalah cerita yang berbeda. Anda harus mengantisipasi bahwa fitur yang perlu Anda buat akan terus berubah. Sering kali, akan ada aturan yang jelas yang Anda masukkan ke dalam sistem (jika postingan memiliki lebih dari tiga suara spam, jangan ambil, dan sebagainya). Setiap model yang dipelajari harus diperbarui setiap hari, jika tidak lebih cepat. Reputasi kreator konten akan berperan besar.

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

ML Fase II: Rekayasa Fitur

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

Pada fase kedua, ada banyak peluang yang mudah diraih. Ada berbagai fitur yang jelas yang dapat ditarik ke dalam sistem. Dengan demikian, fase kedua machine learning melibatkan pengambilan sebanyak mungkin fitur dan menggabungkannya dengan cara yang intuitif. Selama fase ini, semua metrik seharusnya tetap meningkat. Akan ada banyak peluncuran, dan ini adalah waktu yang tepat untuk mendapatkan banyak engineer yang dapat menggabungkan semua data yang Anda perlukan untuk membuat sistem pembelajaran yang benar-benar luar biasa.

Aturan #16: Rencanakan untuk meluncurkan dan melakukan iterasi.

Jangan berharap bahwa model yang Anda kerjakan sekarang akan menjadi model terakhir yang akan Anda luncurkan, atau bahkan Anda akan berhenti meluncurkan model. Oleh karena itu, 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 sedang membuat fitur baru.
  • Anda menyesuaikan regularisasi dan menggabungkan fitur lama dengan cara baru.
  • Anda sedang menyesuaikan tujuan.

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

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

Hal ini mungkin merupakan poin yang kontroversial, tetapi dapat menghindari banyak masalah. 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 tanpa pengawasan) atau oleh pembelajar itu sendiri (misalnya, melalui model faktor atau deep learning). Keduanya dapat berguna, tetapi dapat memiliki banyak masalah, sehingga tidak boleh ada dalam model pertama.

Jika Anda menggunakan sistem eksternal untuk membuat fitur, ingatlah bahwa sistem eksternal memiliki tujuannya sendiri. Tujuan sistem eksternal mungkin hanya memiliki korelasi yang lemah dengan tujuan Anda saat ini. Jika Anda mengambil snapshot sistem eksternal, snapshot tersebut dapat menjadi usang. Jika Anda memperbarui fitur dari sistem eksternal, artinya dapat berubah. Jika Anda menggunakan sistem eksternal untuk menyediakan fitur, perhatikan bahwa pendekatan ini memerlukan banyak perhatian.

Masalah utama terkait model faktor dan model dalam adalah bahwa model tersebut non-konveks. Dengan demikian, tidak ada jaminan bahwa solusi optimal dapat diperkirakan atau ditemukan, dan minimum lokal yang ditemukan pada setiap iterasi dapat berbeda. Variasi ini membuat sulit untuk menilai apakah dampak perubahan pada sistem Anda bermakna atau acak. Dengan membuat model tanpa fitur mendalam, Anda bisa mendapatkan performa dasar yang sangat baik. Setelah dasar ini tercapai, Anda dapat mencoba pendekatan yang lebih esoteris.

Aturan #18: Jelajahi fitur konten yang bersifat umum di berbagai konteks.

Sering kali, sistem machine learning adalah bagian kecil dari gambaran yang jauh lebih besar. Misalnya, jika Anda membayangkan postingan yang mungkin digunakan di Rekomendasi, banyak orang akan memberikan plus-one, membagikan ulang, atau mengomentari postingan sebelum ditampilkan di Rekomendasi. Jika Anda memberikan statistik tersebut kepada pelajar, pelajar dapat mempromosikan postingan baru yang tidak memiliki data dalam konteks yang dioptimalkan. Tonton Berikutnya di YouTube dapat menggunakan jumlah tontonan, atau co-tonton (jumlah frekuensi satu video ditonton setelah video lain ditonton) dari penelusuran YouTube. Anda juga dapat menggunakan rating pengguna yang eksplisit. 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 memasukkan 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 atau kurang menyukainya.

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

Dengan banyak data, akan lebih mudah untuk mempelajari jutaan fitur sederhana daripada beberapa fitur kompleks. ID dokumen yang diambil dan kueri yang dikanonikasikan tidak memberikan banyak generalisasi, tetapi menyelaraskan peringkat dengan label pada kueri head. Jadi, jangan takut dengan grup 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: Gabungkan dan ubah fitur yang ada untuk membuat fitur baru dengan cara yang dapat dipahami manusia.

Ada berbagai cara untuk menggabungkan dan mengubah fitur. Sistem machine learning seperti TensorFlow memungkinkan Anda memproses data sebelumnya melalui transformasi. Dua pendekatan paling standar adalah "discretizations" dan "crosses".

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

Persilangan menggabungkan dua kolom fitur atau lebih. Kolom fitur, dalam terminologi TensorFlow, adalah kumpulan fitur homogen, (misalnya {male, female}, {US, Canada, Mexico}, dan sebagainya). Persilangan adalah kolom fitur baru dengan fitur dalam, misalnya, {male, female} × {US,Canada, Mexico}. Kolom fitur baru ini akan berisi fitur (laki-laki, Kanada). Jika Anda menggunakan TensorFlow dan memberi tahu TensorFlow untuk membuat persilangan ini, fitur (laki-laki, Kanada) ini akan ada dalam contoh yang mewakili laki-laki Kanada. Perhatikan bahwa diperlukan data dalam jumlah besar untuk mempelajari model dengan persilangan tiga, empat, atau lebih kolom fitur dasar.

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

Saat menangani teks, ada dua alternatif. Yang paling keras adalah produk titik. Perkalian titik dalam bentuknya yang paling sederhana hanya menghitung jumlah kata yang sama antara kueri dan dokumen. Fitur ini kemudian dapat didiskretisasi. Pendekatan lainnya adalah persimpangan: dengan demikian, kita akan memiliki fitur yang ada jika dan hanya jika kata "pony" ada dalam dokumen dan kueri, serta fitur lain yang ada jika dan hanya jika kata "the" ada dalam 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 terkait tingkat kompleksitas yang sesuai untuk model, tetapi pada dasarnya aturan ini adalah semua yang perlu Anda ketahui. Saya pernah melakukan percakapan dengan orang-orang yang meragukan bahwa apa pun dapat dipelajari dari seribu contoh, atau bahwa Anda akan memerlukan lebih dari satu juta contoh, karena mereka terjebak dalam metode pembelajaran tertentu. Kuncinya adalah menskalakan pembelajaran Anda sesuai dengan ukuran data:

  1. Jika Anda sedang mengerjakan sistem pemeringkatan penelusuran, dan ada jutaan kata yang berbeda dalam dokumen dan kueri, serta Anda memiliki 1.000 contoh berlabel, Anda harus menggunakan produk titik antara fitur dokumen dan kueri, TF-IDF, dan setengah lusin fitur lain yang sangat dibuat manusia. 1.000 contoh, selusin fitur.
  2. Jika Anda memiliki satu juta contoh, persilangan kolom fitur dokumen dan kueri, menggunakan regularisasi dan mungkin pemilihan fitur. Hal ini akan memberi Anda jutaan fitur, tetapi dengan regularisasi, Anda akan memiliki lebih sedikit fitur. Sepuluh juta contoh, mungkin seratus ribu fitur.
  3. Jika memiliki miliaran atau ratusan miliar contoh, Anda dapat menggabungkan kolom fitur dengan token dokumen dan kueri, menggunakan pemilihan dan regularisasi fitur. Anda akan memiliki satu miliar contoh, dan 10 juta fitur. Teori pembelajaran statistik jarang memberikan batas yang ketat, tetapi memberikan panduan yang bagus untuk titik awal.

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

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

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

Perhatikan cakupan saat mempertimbangkan fitur yang akan ditambahkan atau dipertahankan. Berapa banyak contoh yang tercakup dalam fitur ini? Misalnya, jika Anda memiliki beberapa fitur personalisasi, tetapi hanya 8% pengguna yang memiliki fitur personalisasi, fitur tersebut tidak akan terlalu efektif.

Pada saat yang sama, beberapa fitur mungkin memiliki performa yang lebih baik dari yang diharapkan. Misalnya, jika Anda memiliki fitur yang hanya mencakup 1% data, tetapi 90% contoh yang memiliki fitur tersebut positif, fitur tersebut akan menjadi fitur yang bagus untuk ditambahkan.

Analisis Sistem oleh Manusia

Sebelum melanjutkan ke fase ketiga machine learning, penting untuk berfokus pada sesuatu yang tidak diajarkan di kelas machine learning mana pun: cara melihat model yang ada, dan meningkatkannya. Hal ini lebih merupakan seni daripada sains, tetapi ada beberapa anti-pola yang membantu menghindarinya.

Aturan #23: Anda bukan pengguna akhir biasa.

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

Ada dua alasan untuk ini. Yang pertama adalah Anda terlalu dekat dengan kode. Anda mungkin mencari aspek tertentu dari postingan, atau Anda terlalu terlibat secara emosional (misalnya, bias konfirmasi). Kedua, waktu Anda terlalu berharga. Pertimbangkan biaya sembilan engineer yang duduk dalam rapat selama satu jam, dan pikirkan berapa banyak label manual yang dikontrak yang dibeli di platform crowdsourcing.

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

Aturan #24: Ukur delta antara model.

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

Aturan #25: Saat memilih model, performa utilitarian lebih penting daripada kemampuan prediktif.

Model Anda mungkin mencoba memprediksi rasio klik-tayang. Namun, pada akhirnya, pertanyaan utama 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 dokumen adalah spam, lalu memiliki batas untuk apa yang diblokir, presisi dari apa yang diizinkan akan lebih penting. Biasanya, kedua hal ini harus sesuai: jika tidak sesuai, kemungkinan akan ada sedikit peningkatan. Jadi, jika ada beberapa perubahan yang meningkatkan kerugian log, tetapi menurunkan performa sistem, cari fitur lain. Jika hal ini mulai terjadi lebih sering, saatnya untuk meninjau kembali tujuan model Anda.

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

Misalkan Anda melihat contoh pelatihan yang "salah" menurut model. Dalam tugas klasifikasi, error ini dapat berupa positif palsu atau negatif palsu. Dalam tugas pengurutan, error dapat berupa pasangan dengan nilai positif yang lebih rendah daripada nilai negatif. Poin terpentingnya adalah ini adalah contoh bahwa sistem machine learning tahu bahwa sistem tersebut salah dan ingin memperbaikinya jika diberi 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 sebagai kesalahan oleh sistem, fitur tersebut akan diabaikan. Misalnya, di Penelusuran Aplikasi Play, seseorang menelusuri "game gratis". Misalkan salah satu hasil teratas adalah aplikasi lelucon yang kurang relevan. Jadi, Anda membuat fitur untuk "aplikasi lelucon". Namun, jika Anda memaksimalkan jumlah penginstalan, dan pengguna menginstal aplikasi lelucon saat mereka menelusuri game gratis, fitur "aplikasi lelucon" tidak akan memberikan efek yang Anda inginkan.

Setelah Anda memiliki contoh yang salah diprediksi model, 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 panjang, cukup tambahkan selusin fitur dan biarkan model mencari tahu apa yang harus dilakukan dengannya (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 merasa frustrasi dengan properti sistem yang tidak mereka sukai dan tidak ditangkap oleh fungsi kerugian yang ada. Pada saat ini, mereka harus melakukan apa pun untuk mengubah keluhan mereka menjadi angka yang solid. Misalnya, jika mereka merasa bahwa terlalu banyak "aplikasi lelucon" yang ditampilkan di Penelusuran Play, mereka dapat meminta penilai manusia untuk mengidentifikasi aplikasi lelucon. (Anda dapat menggunakan data berlabel manusia dalam hal ini karena sebagian besar traffic dihasilkan oleh sebagian kecil kueri.) Jika masalah Anda terukur, Anda dapat mulai menggunakannya sebagai fitur, tujuan, atau metrik. Aturan umumnya adalah "ukur dulu, optimalkan kemudian".

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

Bayangkan Anda memiliki sistem baru yang melihat setiap doc_id dan exact_query, lalu menghitung probabilitas klik untuk setiap dokumen untuk setiap kueri. Anda mendapati bahwa perilakunya hampir identik dengan sistem Anda saat ini dalam pengujian A/B dan pengujian berdampingan, sehingga mengingat kesederhanaannya, Anda meluncurkannya. Namun, Anda melihat bahwa tidak ada aplikasi baru yang ditampilkan. Mengapa? Nah, karena sistem Anda hanya menampilkan dokumen berdasarkan historinya sendiri dengan kueri tersebut, tidak ada cara untuk mengetahui bahwa dokumen baru harus ditampilkan.

Satu-satunya cara untuk memahami cara kerja sistem tersebut dalam jangka panjang adalah dengan membuatnya hanya dilatih pada data yang diperoleh saat model aktif. Hal ini sangat sulit.

Diferensiasi Performa Pelatihan dan Penayangan

Perbedaan performa pelatihan dan penayangan adalah perbedaan antara performa selama pelatihan dan performa selama penayangan. Skew ini dapat disebabkan oleh:

  • Perbedaan antara cara Anda menangani data di pipeline pelatihan dan penayangan.
  • Perubahan data antara saat Anda melakukan pelatihan dan saat Anda menayangkan.
  • Loop umpan balik antara model dan algoritme Anda.

Kami telah mengamati sistem machine learning produksi di Google dengan kemiringan penayangan pelatihan yang berdampak negatif pada performa. Solusi terbaiknya adalah memantaunya secara eksplisit sehingga perubahan sistem dan data tidak menyebabkan penyimpangan tanpa disadari.

Aturan #29: Cara terbaik untuk memastikan Anda melatih seperti menayangkan adalah dengan menyimpan kumpulan fitur yang digunakan pada waktu penayangan, 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 yang beralih infrastruktur mereka saat ini.

Aturan #30: Data sampel bobot kepentingan, jangan hapus secara sewenang-wenang.

Jika Anda memiliki terlalu banyak data, ada godaan untuk mengambil file 1-12, dan mengabaikan file 13-99. Ini adalah kekeliruan. Meskipun data yang tidak pernah ditampilkan kepada pengguna dapat dihapus, bobot kepentingan adalah yang terbaik untuk data lainnya. Bobot kepentingan berarti jika Anda memutuskan bahwa Anda akan mengambil contoh contoh X dengan probabilitas 30%, berikan bobot 10/3. Dengan bobot kepentingan, semua properti kalibrasi yang dibahas dalam Aturan #14 tetap berlaku.

Aturan #31: Perhatikan bahwa jika Anda menggabungkan data dari tabel pada waktu pelatihan dan penayangan, 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 penyaluran. Cara termudah untuk menghindari masalah seperti ini adalah dengan mencatat fitur ke dalam log pada waktu penayangan (lihat Aturan #32 ). Jika tabel hanya berubah secara perlahan, Anda juga dapat mengambil snapshot tabel setiap jam atau hari untuk mendapatkan data yang cukup dekat. Perlu diperhatikan bahwa tindakan ini masih belum sepenuhnya menyelesaikan masalah.

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

Batch processing berbeda dengan pemrosesan online. Dalam pemrosesan online, Anda harus menangani setiap permintaan saat tiba (misalnya, Anda harus melakukan pencarian terpisah untuk setiap kueri), sedangkan dalam pemrosesan batch, Anda dapat menggabungkan tugas (misalnya, membuat join). Pada waktu penayangan, Anda melakukan pemrosesan online, sedangkan pelatihan adalah tugas pemrosesan batch. Namun, ada beberapa hal yang dapat Anda lakukan untuk menggunakan kembali kode. Misalnya, Anda dapat membuat objek yang khusus untuk sistem Anda, tempat hasil kueri atau join 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 akan menjalankan metode umum untuk menjembatani antara objek yang dapat dibaca manusia yang khusus untuk sistem Anda, dan format apa pun yang diharapkan sistem machine learning. Tindakan ini akan menghilangkan sumber diferensiasi performa pelatihan dan penayangan. Sebagai konsekuensi, cobalah untuk tidak menggunakan dua bahasa pemrograman yang berbeda antara pelatihan dan penayangan. Keputusan tersebut akan membuat Anda hampir tidak dapat membagikan kode.

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

Secara umum, ukur performa model pada data yang dikumpulkan setelah data yang Anda gunakan untuk melatih model, karena hal ini lebih mencerminkan apa yang akan dilakukan sistem Anda dalam produksi. Jika Anda membuat model berdasarkan data hingga 5 Januari, uji model pada data dari 6 Januari. Anda akan mengharapkan performa tidak akan sebagus pada data baru, tetapi tidak akan jauh lebih buruk. 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 memberikan skor yang lebih tinggi pada contoh positif daripada contoh negatif, harus cukup dekat.

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

Namun, pendekatan ini menimbulkan bias sampling. Anda dapat mengumpulkan data yang lebih bersih jika selama penayangan, Anda melabeli 1% dari semua traffic sebagai "dikecualikan", dan mengirim semua contoh yang dikecualikan kepada pengguna. Sekarang filter Anda memblokir setidaknya 74% contoh negatif. Contoh yang disimpan ini dapat menjadi data pelatihan Anda.

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

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

Jika Anda mengubah algoritma peringkat secara radikal sehingga hasil yang berbeda muncul, Anda telah mengubah data yang akan dilihat algoritma secara efektif di masa mendatang. Jenis kemiringan ini akan muncul, dan Anda harus mendesain model berdasarkan kemiringan tersebut. Ada beberapa pendekatan yang berbeda. Pendekatan ini adalah semua cara untuk mendukung data yang telah dilihat model Anda.

  1. Memiliki regularisasi yang lebih tinggi pada fitur yang mencakup lebih banyak kueri, bukan fitur yang hanya aktif untuk satu kueri. Dengan cara ini, model akan lebih memilih fitur yang spesifik untuk satu atau beberapa kueri daripada fitur yang umum untuk semua kueri. Pendekatan ini dapat membantu mencegah hasil yang sangat populer bocor 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 unik.
  2. Hanya izinkan fitur memiliki bobot positif. Dengan demikian, fitur yang baik akan lebih baik daripada fitur yang "tidak diketahui".
  3. Tidak memiliki fitur khusus dokumen. Ini adalah versi ekstrem dari #1. Misalnya, meskipun aplikasi tertentu merupakan download populer, terlepas dari kueri yang digunakan, Anda tidak ingin menampilkannya di mana saja. Tidak memiliki fitur khusus dokumen akan membuatnya tetap sederhana. Alasan Anda tidak ingin menampilkan aplikasi populer tertentu di mana saja berkaitan dengan pentingnya membuat semua aplikasi yang diinginkan dapat dijangkau. Misalnya, jika seseorang menelusuri "aplikasi pengamatan burung", mereka mungkin mendownload "angry birds", tetapi itu tentu saja bukan niat mereka. Menampilkan aplikasi semacam itu mungkin akan meningkatkan rasio download, tetapi kebutuhan pengguna pada akhirnya tidak terpenuhi.

Aturan #36: Hindari loop masukan dengan fitur posisi.

Posisi konten secara drastis memengaruhi kemungkinan pengguna berinteraksi dengannya. Jika Anda menempatkan aplikasi di posisi pertama, aplikasi tersebut akan lebih sering diklik, dan Anda akan yakin bahwa aplikasi tersebut lebih cenderung diklik. Salah satu cara untuk mengatasinya adalah dengan menambahkan fitur posisi, yaitu fitur tentang posisi konten di halaman. Anda melatih model dengan fitur posisional, dan model tersebut akan belajar untuk memberi bobot, misalnya, fitur "posisi pertama" secara signifikan. Dengan demikian, model Anda memberikan bobot yang lebih rendah pada faktor lain untuk contoh dengan "1st­position=true". Kemudian, saat penayangan, Anda tidak memberikan fitur posisional ke instance apa pun, atau Anda memberikan semua fitur default yang sama, karena Anda menilai kandidat sebelum menentukan urutan untuk menampilkannya.

Perhatikan bahwa penting untuk menjaga fitur posisi tetap terpisah dari sebagian besar model karena asimetri antara pelatihan dan pengujian ini. Model yang merupakan jumlah fungsi fitur posisi dan fungsi fitur lainnya adalah ideal. Misalnya, jangan silangkan fitur posisional dengan fitur dokumen apa pun.

Aturan #37: Ukur Diferensiasi Performa Pelatihan/Penayangan.

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

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

ML Fase III: Perlambatan Pertumbuhan, Pengoptimalan yang Lebih Baik, dan Model yang Kompleks

Akan ada indikasi tertentu bahwa fase kedua akan segera berakhir. Pertama-tama, keuntungan bulanan Anda akan mulai berkurang. Anda akan mulai memiliki kompromi antara metrik: Anda akan melihat beberapa metrik meningkat dan beberapa menurun dalam beberapa eksperimen. Di sinilah hal menariknya. Karena peningkatan lebih sulit dicapai, machine learning harus menjadi lebih canggih. Catatan: bagian ini memiliki lebih banyak aturan blue-sky daripada bagian sebelumnya. Kami telah melihat banyak tim melalui masa-masa indah machine learning Fase I dan Fase II. Setelah Fase III tercapai, tim harus menemukan jalurnya sendiri.

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

Saat pengukuran mencapai puncak, 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 dalam tujuan algoritma yang ada, Anda harus mengubah tujuan atau sasaran produk. Misalnya, Anda dapat mengoptimalkan klik, plus-one, atau download, tetapi membuat keputusan peluncuran sebagian berdasarkan penilai manusia.

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

Alice memiliki ide untuk mengurangi kerugian logistik dalam memprediksi penginstalan. Dia menambahkan fitur. Kerugian logistik menurun. Saat melakukan eksperimen langsung, dia melihat peningkatan rasio penginstalan. Namun, saat dia menghadiri rapat peninjauan peluncuran, seseorang menunjukkan bahwa jumlah pengguna aktif harian turun sebesar 5%. Tim memutuskan untuk tidak meluncurkan model. Alice kecewa, tetapi sekarang menyadari bahwa keputusan peluncuran bergantung pada beberapa kriteria, yang hanya beberapa saja yang dapat dioptimalkan secara langsung menggunakan ML.

Faktanya, dunia nyata bukanlah dungeon and dragons: tidak ada "hit points" yang mengidentifikasi kesehatan produk Anda. Tim harus menggunakan statistik yang dikumpulkan untuk mencoba memprediksi secara efektif seberapa baik sistem tersebut di masa mendatang. Mereka perlu memperhatikan engagement, pengguna aktif 1 hari (DAU), DAU 30 hari, pendapatan, dan laba atas investasi pengiklan. Metrik yang dapat diukur dalam pengujian A/B itu sendiri hanyalah proxy untuk sasaran jangka panjang yang lebih besar: memuaskan pengguna, meningkatkan jumlah pengguna, memuaskan partner, dan laba, yang bahkan dapat Anda pertimbangkan sebagai proxy untuk memiliki produk berkualitas tinggi yang berguna 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 memiliki pilihan antara algoritma machine learning yang canggih, dan heuristik sederhana, jika heuristik sederhana melakukan pekerjaan yang lebih baik pada semua metrik ini, tim harus memilih heuristik. Selain itu, tidak ada peringkat eksplisit untuk 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, tim kemungkinan tidak akan beralih ke B. Jika sistem saat ini adalah B, tim kemungkinan tidak akan beralih ke A. Hal ini tampaknya bertentangan dengan perilaku rasional; namun, prediksi perubahan metrik mungkin berhasil atau tidak, sehingga ada risiko besar yang terkait dengan perubahan tersebut. Setiap metrik mencakup beberapa risiko yang menjadi perhatian tim.

Selain itu, tidak ada metrik yang mencakup masalah utama tim, "ke mana produk saya akan berada dalam lima tahun ke depan"?

Di sisi lain, individu cenderung lebih menyukai satu tujuan yang dapat mereka optimalkan secara langsung. Sebagian besar alat machine learning menyukai lingkungan tersebut. Engineer yang membuat fitur baru dapat mendapatkan peluncuran yang stabil di lingkungan tersebut. Ada jenis machine learning, yaitu pembelajaran multi-tujuan, yang 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, itu karena konten ditampilkan. Namun, jauh lebih sulit untuk mengetahui alasan pengguna mengunjungi situs Anda. Cara memprediksi keberhasilan situs di masa mendatang secara keseluruhan adalah AI-complete: sama sulitnya dengan computer vision atau natural language processing.

Aturan #40: Buat ensemble tetap sederhana.

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

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

Aturan #41: Saat performa mencapai puncak, cari sumber informasi baru secara kualitatif untuk ditambahkan, bukan meningkatkan kualitas sinyal yang ada.

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

Saatnya mulai membangun infrastruktur untuk fitur yang sangat berbeda, seperti histori dokumen yang telah diakses pengguna ini dalam hari, minggu, atau tahun terakhir, atau data dari properti yang berbeda. Gunakan entitas wikidata atau sesuatu yang bersifat internal untuk perusahaan Anda (seperti grafik pengetahuan Google). Gunakan deep learning. Mulai sesuaikan ekspektasi Anda tentang jumlah laba atas investasi yang diharapkan, dan perluas upaya Anda sebagaimana mestinya. Seperti pada project engineering lainnya, Anda harus mempertimbangkan manfaat penambahan fitur baru dengan biaya peningkatan kompleksitas.

Aturan #42: Jangan berharap keragaman, personalisasi, atau relevansi berkorelasi dengan popularitas seperti yang Anda harapkan.

Keragaman dalam sekumpulan konten dapat berarti banyak hal, dengan keragaman sumber konten sebagai salah satu yang paling umum. Personalisasi menyiratkan bahwa setiap pengguna mendapatkan hasil mereka sendiri. Relevansi menyiratkan bahwa hasil untuk kueri tertentu lebih sesuai untuk kueri tersebut daripada kueri lainnya. Dengan demikian, ketiga properti ini ditentukan sebagai berbeda dari yang biasa.

Masalahnya adalah hal biasa cenderung sulit dikalahkan.

Perhatikan bahwa jika sistem Anda mengukur klik, waktu yang dihabiskan, tontonan, +1, berbagi ulang, dan sebagainya, Anda mengukur popularitas konten. Tim terkadang mencoba mempelajari model pribadi dengan keberagaman. Untuk mempersonalisasi, mereka menambahkan fitur yang akan memungkinkan sistem untuk mempersonalisasi (beberapa fitur yang mewakili minat pengguna) atau mendiversifikasi (fitur yang menunjukkan apakah dokumen ini memiliki fitur yang sama dengan dokumen lain yang ditampilkan, seperti penulis atau konten), dan menemukan bahwa fitur tersebut mendapatkan bobot yang lebih rendah (atau terkadang tanda yang berbeda) dari yang diharapkan.

Hal ini bukan berarti bahwa keberagaman, personalisasi, atau relevansi tidak berharga. Seperti yang ditunjukkan dalam aturan sebelumnya, Anda dapat melakukan pasca­pemrosesan untuk meningkatkan keanekaragaman atau relevansi. Jika Anda melihat peningkatan tujuan jangka panjang, Anda dapat mendeklarasikan bahwa keragaman/relevansi itu berharga, selain popularitas. Kemudian, Anda dapat terus menggunakan pasca-pemrosesan, atau langsung mengubah objek berdasarkan keragaman atau relevansi.

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

Tim di Google telah mendapatkan banyak daya tarik dengan menggunakan model yang memprediksi kedekatan koneksi di satu produk, dan membuatnya berfungsi dengan baik di produk lain. Teman Anda adalah dirinya sendiri. Di sisi lain, saya telah melihat beberapa tim berjuang dengan fitur personalisasi di seluruh divisi produk. Ya, sepertinya akan berhasil. Untuk saat ini, sepertinya tidak. 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, keberadaan aktivitas pengguna di dua produk mungkin menunjukkan hal itu sendiri.

Ada banyak dokumen tentang machine learning di Google dan secara eksternal.

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 atas banyak koreksi, saran, dan contoh bermanfaat untuk dokumen ini. Selain itu, terima kasih kepada Kristen Lefevre, Suddha Basu, dan Chris Berg yang membantu versi sebelumnya. Setiap error, kelalaian, atau (gasp!) opini 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.

Ringkasan YouTube

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

Ringkasan Google Play

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

Ringkasan Google Plus

Google Plus menggunakan machine learning dalam berbagai situasi: memberi peringkat pada postingan dalam "feed" postingan yang dilihat oleh pengguna, memberi peringkat pada postingan "Yang Populer" (postingan yang sangat populer saat ini), memberi peringkat pada orang yang Anda kenal, dan sebagainya. Google Plus menutup semua akun pribadi pada tahun 2019, dan digantikan oleh Google Currents untuk akun bisnis pada 6 Juli 2020.