Pelajaran produk ML Daphne Koller: dari riset ke produksi

Mengapa hasil riset seringkali tidak bertahan di realitas produk

Makalah ML yang bagus masih bisa menjadi produk yang mengecewakan. Makalah dibuat untuk membuktikan sebuah gagasan dalam kondisi terkontrol. Produk dibuat untuk membantu orang menyelesaikan tugas di hari yang berantakan, dengan data yang berantakan, dan kesabaran yang minim.

Salah satu pelajaran berguna dari pengalaman produk ML ala Daphne Koller (sebagai lensa, bukan biografi) adalah perubahan insentif: riset menghargai hal baru dan peningkatan yang bersih, sementara produk menghargai kegunaan dan kepercayaan. Jika model Anda mengesankan tetapi fiturnya sulit dipahami, lambat, atau tak terduga, pengguna tidak akan peduli pada benchmark.

Yang diperhatikan pengguna itu dasar dan langsung. Mereka merasakan latensi. Mereka melihat saat input yang sama memberi jawaban berbeda. Mereka mengingat satu kesalahan besar lebih dari sepuluh hasil baik. Dan jika fitur menyentuh uang, kesehatan, atau hal publik, mereka cepat memutuskan apakah layak diandalkan.

Kebanyakan “kemenangan makalah” gagal di dunia nyata karena beberapa alasan yang sama: tujuan tidak jelas (membuat tim mengoptimalkan yang mudah diukur), pergeseran data (pengguna baru, topik baru, edge case baru), kepemilikan tidak jelas (sehingga masalah kualitas berlarut), atau fitur dikirim sebagai “sihir AI” tanpa cara memprediksi, memverifikasi, atau memperbaiki keluaran.

Contoh sederhana: model ringkasan mungkin tampak kuat di tes offline, tetapi produk gagal jika ia menghilangkan satu detail penting, menggunakan nada yang salah, atau butuh 12 detik untuk merespons. Pengguna tidak membandingkannya dengan baseline — mereka membandingkannya dengan waktu dan risiko mereka sendiri.

Tim juga membuang waktu saat menganggap model adalah produk. Pada praktiknya, model hanyalah satu komponen dalam sistem: penanganan input, guardrail, UI, mekanisme umpan balik, logging, dan jalur fallback ketika model ragu.

Hal ini terlihat jelas di pembangun AI yang berhadapan dengan pengguna seperti Koder.ai. Menghasilkan sebuah aplikasi dari chat bisa terlihat luar biasa dalam demo, tetapi pengguna nyata peduli apakah hasilnya berjalan, apakah pengeditan berperilaku dapat diprediksi, dan apakah mereka bisa mengembalikan ketika sesuatu rusak. Itu realitas produk: bukan soal “model terbaik,” melainkan pengalaman yang dapat diandalkan.

Metrik makalah vs hasil produk: apa yang berubah dalam praktik

Riset biasanya mencoba membuktikan sebuah poin: model mengalahkan baseline pada dataset bersih dengan tes tetap. Produk berusaha membantu pengguna menyelesaikan tugas dalam kondisi berantakan, dengan taruhannya nyata dan kesabaran terbatas. Ketidaksesuaian inilah yang membuat banyak ide menjanjikan runtuh.

Salah satu pelajaran praktis adalah menganggap “akurasi” sebagai sinyal awal, bukan garis akhir. Di makalah, kenaikan metrik kecil bisa berarti. Di produk, kenaikan yang sama mungkin tidak terlihat, atau malah membawa biaya baru: respons lebih lambat, edge case yang membingungkan, atau naiknya tiket dukungan.

Prototipe, pilot, produksi: aturan dasar berubah

Prototipe menjawab “apakah ini bisa bekerja sama sekali?” Anda bisa memilih data, menjalankan model sekali, dan mendemokan kasus terbaik. Pilot bertanya “apakah ini membantu pengguna nyata?” Sekarang Anda butuh input nyata, batasan waktu nyata, dan ukuran keberhasilan yang jelas. Produksi menanyakan “bisakah kita mempertahankannya?” Itu mencakup keandalan, keselamatan, biaya, dan apa yang terjadi di hari-hari buruk.

Cara cepat mengingat pergeseran:

• Prototipe: sampel data kecil, metrik sederhana, banyak pemeriksaan manual
• Pilot: alur pengguna nyata, analisis kesalahan terstruktur, loop umpan balik
• Produksi: monitoring, fallback, batas biaya, dan rencana retraining

Pekerjaan tersembunyi yang tidak dicakup makalah

Hasil produk bergantung pada segala hal di sekitar model. Pipeline data bisa rusak. Input bergeser saat perilaku pengguna berubah. Label menjadi kedaluwarsa. Anda juga butuh cara mendeteksi masalah cepat, dan cara membantu pengguna pulih saat AI salah.

“Pekerjaan tersembunyi” itu biasanya meliputi memantau kualitas input, mencatat kegagalan, meninjau kasus aneh, dan memutuskan kapan retrain. Juga termasuk skrip dukungan dan pesan UI yang jelas, karena pengguna menilai keseluruhan pengalaman, bukan model secara terpisah.

Sebelum membangun, definisikan apa arti “cukup baik” dan tuliskan dengan bahasa sederhana: pengguna mana, tugas apa, tipe kesalahan yang dapat diterima, dan ambang di mana Anda meluncurkan atau berhenti. “Mengurangi waktu review manual sebesar 20% tanpa meningkatkan kesalahan berisiko tinggi” lebih berguna daripada “Meningkatkan skor F1.”

Cara menentukan ruang lingkup fitur ML tanpa menebak

Mulailah dari pekerjaan pengguna, bukan model. Ruang lingkup yang baik dimulai dengan satu pertanyaan: apa yang sedang dicoba pengguna capai, dan apa yang memperlambat mereka hari ini? Jika Anda tidak bisa menggambarkan momen tepat dalam alur kerja di mana fitur membantu, Anda masih dalam “mode makalah,” bukan mode produk.

Pembingkaian yang berguna adalah mendefinisikan fitur menurut perannya bagi pengguna. Apakah fitur itu mengurangi pekerjaan mereka (otomatisasi), membantu mereka melakukan pekerjaan lebih baik (assist), atau menawarkan rekomendasi yang bisa mereka terima atau abaikan (decision support)? Pilihan itu membentuk UI, metrik, tingkat kesalahan yang dapat diterima, dan cara menangani kesalahan.

Sebelum membangun apa pun, tulis janji UI dalam satu kalimat. Kalimat itu harus tetap benar pada hari terburuk fitur. “Menyusun draf awal yang bisa Anda edit” lebih aman daripada “Menulis jawaban final.” Jika Anda butuh banyak kondisi agar janji itu benar, ruang lingkup terlalu besar.

Kendala adalah ruang lingkup yang sebenarnya. Nyatakan secara eksplisit.

Template scoping sederhana

Jangan melanjutkan sampai lima baris ini jelas:

• Pekerjaan pengguna: tugas spesifik dan kapan terjadi
• Peran fitur: otomatisasi, assist, atau decision support
• Janji satu kalimat: apa yang UI jamin
• Kendala: latensi, biaya per permintaan, privasi, dan di mana data boleh disimpan
• Toleransi kegagalan: apa yang terjadi saat salah atau tidak pasti

Contoh: misalkan Anda menambahkan “AI schema helper” di alat vibe-coding seperti Koder.ai. Pekerjaan pengguna adalah “Saya butuh tabel database cepat supaya saya bisa terus membangun.” Jika Anda scope sebagai assist, janji bisa jadi “Menyarankan skema tabel yang bisa Anda tinjau dan terapkan.” Itu langsung menyiratkan guardrail: tunjukkan diff sebelum menerapkan perubahan, izinkan rollback, dan utamakan respons cepat daripada penalaran kompleks.

Kirim versi pertama di sekitar tindakan terkecil yang menciptakan nilai. Putuskan apa yang belum Anda dukung (bahasa, tipe data, input sangat panjang, lalu lintas tinggi) dan tampilkan itu di UI. Itulah cara menghindari menyerahkan mode kegagalan model kepada pengguna.

Memilih metrik yang sesuai dengan nilai nyata pengguna

Metrik ML yang baik tidak sama dengan metrik produk yang baik. Cara tercepat melihat celah adalah bertanya: jika angka ini naik, apakah pengguna nyata menyadari dan merasakan perbedaannya? Jika tidak, kemungkinan itu metrik lab.

Kebiasaan andal adalah memilih satu metrik utama yang terkait dengan nilai pengguna dan dapat diukur setelah peluncuran. Semua metrik lain harus mendukungnya, bukan bersaing.

Tumpukan metrik sederhana

Mulai dengan satu metrik utama, lalu tambahkan beberapa guardrail:

• Metrik keberhasilan utama: hasil yang diinginkan pengguna (tingkat penyelesaian tugas, waktu hingga jawaban benar, % sesi yang berakhir dengan “ini membantu”)
• Metrik guardrail: hal yang mencegah Anda “menang” dengan cara yang merugikan pengguna (tingkat saran berbahaya, tingkat keluhan, tingkat kesalahan berdampak tinggi)
• Biaya dan latensi: waktu respons dan biaya per permintaan, karena AI yang lambat atau mahal cepat menjadi tidak bisa dipakai

Guardrail harus fokus pada kesalahan yang benar-benar dirasakan pengguna. Penurunan kecil dalam akurasi mungkin bisa diterima pada kasus berisiko rendah, tetapi satu jawaban salah yang penuh keyakinan pada momen berisiko tinggi merusak kepercayaan.

Metrik offline (akurasi, F1, BLEU, ROUGE) tetap berguna sebagai alat penyaring. Metrik online (konversi, retensi, tiket dukungan, refund, waktu pengerjaan ulang) memberi tahu apakah fitur pantas ada di produk.

Untuk menghubungkan keduanya, definisikan ambang keputusan yang memetakan keluaran model ke sebuah tindakan, lalu ukur tindakannya. Jika model menyarankan balasan, lacak seberapa sering pengguna menerima, mengedit berat, atau menolak.

Jangan lupakan baseline. Anda butuh sesuatu untuk dikalahkan: sistem berbasis aturan, perpustakaan template, atau alur kerja manusia saat ini. Jika AI hanya menyamai baseline tetapi menambah kebingungan, itu rugi bersih.

Contoh: Anda merilis ringkasan AI untuk chat pelanggan. Offline, ringkasan mendapat skor baik pada ROUGE. Online, agen butuh lebih lama memperbaiki ringkasan pada kasus kompleks. Metrik utama yang lebih baik adalah “rata-rata waktu penanganan chat dengan ringkasan AI,” dipasangkan dengan guardrail seperti “% ringkasan yang melewatkan hal penting” (diaudit mingguan) dan “tingkat laporan ringkasan salah” yang dilaporkan pengguna.

Langkah demi langkah: mengubah ide ML menjadi sistem yang bisa dideploy

Sebuah hasil riset menjadi produk ketika Anda bisa mengirimkannya, mengukurnya, dan mendukungnya. Versi praktisnya biasanya lebih kecil dan lebih terkendali daripada versi makalah.

1) Definisikan potongan MVP

Mulai dengan input terkecil yang bisa Anda terima dan keluaran paling sederhana yang masih membantu.

Daripada “ringkas dokumen apa pun,” mulai dengan “ringkas tiket dukungan di bawah 1.000 kata menjadi 3 poin peluru.” Lebih sedikit format berarti lebih sedikit kejutan.

2) Tentukan data yang Anda butuhkan

Tuliskan apa yang sudah Anda miliki, apa yang bisa Anda log dengan aman, dan apa yang harus Anda kumpulkan sengaja. Banyak ide macet di sini.

Jika Anda tidak punya cukup contoh nyata, rencanakan fase pengumpulan ringan: biarkan pengguna memberi peringkat keluaran, atau menandai “berguna” vs “tidak berguna” dengan alasan singkat. Pastikan yang Anda kumpulkan cocok dengan apa yang ingin Anda tingkatkan.

3) Pilih metode evaluasi sejak awal

Pilih evaluasi termurah yang akan menangkap kegagalan terbesar. Set terpisah, tinjauan manusia cepat dengan aturan yang jelas, atau A/B test dengan metrik guardrail bisa bekerja. Jangan mengandalkan satu angka; padukan sinyal kualitas dengan sinyal keselamatan atau kesalahan.

4) Rencanakan rilis seperti eksperimen

Rilis bertahap: penggunaan internal, grup pengguna kecil, lalu peluncuran lebih luas. Jaga loop umpan balik ketat: catat kegagalan, tinjau sampel mingguan, dan kirim perbaikan kecil.

Jika tooling Anda mendukung snapshot dan rollback, gunakan. Bisa mengembalikan cepat mengubah seberapa aman Anda bisa beriterasi.

5) Iterasi dengan aturan berhenti yang jelas

Putuskan di muka apa arti “cukup baik untuk memperluas” dan apa yang memicu jeda. Contoh: “Kita perluas rollout saat helpfulness di atas 70% dan kesalahan berat di bawah 1% selama dua minggu.” Itu mencegah debat tanpa akhir dan janji yang tak bisa ditepati.

Mengatur ekspektasi di aplikasi AI yang berhadapan dengan pengguna

Pengguna tidak menilai model Anda dari jawaban terbaiknya. Mereka menilainya dari beberapa momen ketika model salah dengan penuh keyakinan, terutama saat aplikasi terasa resmi. Mengatur ekspektasi adalah bagian dari produk, bukan sekadar disclaimer.

Bicara dalam rentang, bukan absolut. Daripada “ini akurat,” katakan “biasanya benar untuk X” dan “kurang andal untuk Y.” Jika bisa, tunjukkan tingkat keyakinan dengan bahasa sederhana (tinggi, sedang, rendah) dan kaitkan setiap level dengan apa yang harus dilakukan pengguna selanjutnya.

Jelaskan tujuan sistem dan apa yang bukan tujuannya. Peringatan singkat dekat keluaran mencegah penyalahgunaan: “Bagus untuk drafting dan merangkum. Bukan untuk nasihat hukum atau keputusan akhir.”

Petunjuk ketidakpastian bekerja terbaik jika terlihat dan bisa ditindaklanjuti. Pengguna lebih memaafkan saat mereka bisa melihat alasan AI merespons demikian, atau ketika aplikasi mengakui perlu pemeriksaan.

Petunjuk ketidakpastian praktis yang dipahami pengguna

Pilih satu atau dua petunjuk dan gunakan konsisten:

• Alasan singkat (input apa yang digunakan)
• Kutipan atau cuplikan sumber saat jawaban bergantung pada dokumen
• Label sederhana seperti “Perlu ditinjau” saat keyakinan rendah
• Dua opsi saat input ambigu

Rancang untuk fallback sejak hari pertama. Saat AI ragu, produk harus tetap memungkinkan pengguna menyelesaikan tugas: formulir manual, langkah tinjauan manusia, atau alur berbasis aturan yang lebih sederhana.

Contoh: asisten balasan dukungan tidak boleh mengirim otomatis. Ia harus menghasilkan draf dan menyoroti bagian berisiko (refund, janji kebijakan) sebagai “Perlu ditinjau.” Jika keyakinan rendah, ajukan satu pertanyaan tindak lanjut daripada menebak.

Perangkap umum yang menyebabkan janji berlebih dan churn

Pengguna tidak berhenti menggunakan karena model tidak sempurna. Mereka churn ketika aplikasi terdengar yakin lalu gagal dengan cara yang merusak kepercayaan. Banyak pelajaran produk ML mendarat di sini: pekerjaan bukan hanya melatih model, melainkan merancang sistem yang berperilaku aman dalam penggunaan nyata.

Perangkap umum termasuk overfitting pada benchmark (data produk berbeda jauh dari dataset), mengirim tanpa monitoring atau rollback (pembaruan kecil menjadi hari-hari sakit bagi pengguna), mengabaikan edge case sehari-hari (kueri pendek, input berantakan, bahasa campur), menganggap satu model cocok untuk semua segmen (pengguna baru vs pengguna mahir berbeda), dan menjanjikan “kinerja setara manusia” (pengguna mengingat kesalahan yang dilakukan dengan penuh keyakinan).

Kegagalan ini sering berasal dari melewatkan keputusan produk “non-ML”: apa yang model boleh lakukan, kapan harus menolak, apa yang terjadi saat keyakinan rendah, dan bagaimana orang bisa memperbaikinya. Jika Anda tidak mendefinisikan batasan itu, pemasaran dan UI akan mendefinisikannya untuk Anda.

Skenario sederhana: Anda menambahkan fitur auto-reply AI untuk dukungan pelanggan. Tes offline terlihat bagus, tetapi tiket nyata berisi pesan marah, nomor pesanan yang tidak lengkap, dan thread panjang. Tanpa monitoring, Anda melewatkan bahwa balasan menjadi lebih pendek dan generik setelah perubahan model. Tanpa rollback, tim berdebat dua hari sementara agen menonaktifkan fitur secara manual. Pengguna melihat balasan yakin yang melewatkan detail penting, dan mereka berhenti mempercayai semua saran AI, termasuk yang baik.

Perbaikannya jarang “latih lebih keras.” Perbaikannya adalah tepatkan scope, pilih metrik yang mencerminkan bahaya bagi pengguna (jawaban salah penuh keyakinan lebih buruk daripada penolakan yang aman), dan bangun keselamatan operasional (alert, rilis bertahap, snapshot, rollback).

Contoh skenario: mengirim fitur AI yang bisa dipercaya pengguna

Triage dukungan pelanggan adalah tempat realistis untuk menerapkan pelajaran ini. Tujuannya bukan “menyelesaikan seluruh dukungan dengan AI.” Tujuannya mengurangi waktu yang dibutuhkan manusia untuk merutekan tiket ke tempat yang tepat.

Definisikan janji kecil dan jujur

Janjikan satu hal sempit: saat tiket baru masuk, sistem menyarankan kategori (billing, bug, feature request) dan prioritas (low, normal, urgent). Agen manusia mengonfirmasi atau mengedit sebelum itu memengaruhi routing.

Pilihan kata penting. “Menyarankan” dan “agen mengonfirmasi” menetapkan ekspektasi yang tepat dan mencegah kesalahan awal menjadi outage yang terlihat pelanggan.

Pilih metrik yang cocok dengan tugas

Akurasi offline membantu, tetapi itu bukan scoreboard utama. Lacak hasil yang mencerminkan kerja nyata: waktu-ke-respons-pertama, tingkat penugasan ulang, tingkat override agen, dan kepuasan pengguna (CSAT). Perhatikan juga sinyal “gagal diam-diam,” seperti waktu penanganan lebih lama untuk tiket yang diberi label urgent oleh model.

Rancang untuk kegagalan, bukan kesempurnaan

Alih-alih satu jawaban, tunjukkan 3 saran kategori teratas dengan label keyakinan sederhana (tinggi, sedang, rendah). Saat keyakinan rendah, default ke “perlu ditinjau” dan minta pilihan manusia eksplisit.

Berikan agen kode alasan cepat saat mereka override (area produk salah, konteks hilang, pelanggan marah). Alasan ini menjadi data pelatihan dan menyoroti celah sistematis.

Rilis tanpa kejutan

Mulai kecil dan perluas hanya setelah metrik bergerak ke arah yang benar. Luncurkan ke satu tim dengan alur kerja lama sebagai fallback. Tinjau sampel mingguan untuk menemukan kesalahan berulang. Sesuaikan label dan teks UI sebelum retraining. Tambahkan alert saat tingkat override melonjak setelah pembaruan model.

Jika Anda membangun fitur ini di platform seperti Koder.ai, anggap prompt, aturan, dan teks UI sebagai bagian dari produk. Kepercayaan datang dari sistem penuh, bukan hanya model.

Daftar periksa cepat sebelum Anda kirim

Sebelum merilis fitur ML yang berhadapan dengan pengguna, tuliskan versi paling sederhana dari apa yang Anda janjikan. Sebagian besar pelajaran produk ML intinya: spesifik tentang nilai, jujur tentang batas, dan siap menghadapi realitas.

Periksa item berikut sebelum peluncuran:

• Janji pengguna (satu kalimat): Apa yang fitur lakukan, dan kapan? Bikin dapat diuji.
• Baseline dan target peningkatan: Apa yang terjadi hari ini tanpa ML, dan angka apa yang berarti lebih baik?
• Saat model salah atau ragu: Definisikan perilaku gagal (petunjuk keyakinan, pertanyaan klarifikasi, fallback aturan, atau sembunyikan fitur). Definisikan apa yang dihitung sebagai keluaran tidak aman dan bagaimana itu diblokir.
• Sinyal keberhasilan mingguan: Pilih 1-2 ukuran yang bisa Anda tinjau cepat tiap minggu (penggunaan opt-in, penggunaan ulang, tingkat penyelesaian, tingkat simpan, tingkat keluhan, tingkat undo).
• Monitoring, rollback, kepemilikan: Tahu siapa yang memegang kualitas, siapa yang mendapat alert, dan bagaimana Anda membalik perubahan dengan cepat.

Jika Anda hanya melakukan satu hal ekstra, jalankan rilis kecil dengan pengguna nyata, kumpulkan 20 kegagalan teratas, dan beri label. Kegagalan itu biasanya memberi tahu apakah yang harus disesuaikan adalah scope, UI, atau janji — bukan sekadar model.

Langkah berikutnya: rencana praktis untuk bergerak dari ide ke pengiriman

Mulai dengan spesifikasi satu halaman yang bisa dibaca dalam dua menit. Pakai bahasa sederhana dan fokus pada janji yang bisa dipercaya pengguna.

Tuliskan empat hal: janji pengguna, input (dan apa yang tidak boleh digunakan), output (termasuk bagaimana menunjukkan ketidakpastian atau penolakan), dan batasan (mode kegagalan yang diharapkan dan apa yang belum didukung).

Pilih metrik dan guardrail sebelum membangun. Satu metrik harus mencerminkan nilai pengguna (penyelesaian tugas, lebih sedikit edit, waktu tersimpan). Satu harus melindungi pengguna (tingkat halusinasi pada set uji realistis, tingkat pelanggaran kebijakan, percobaan aksi tidak aman yang diblokir). Jika Anda hanya melacak akurasi, Anda akan melewatkan penyebab churn.

Lalu pilih rollout MVP yang sesuai dengan risikonya: evaluasi offline pada set uji berantakan, mode shadow, beta terbatas dengan tombol umpan balik mudah, dan rollout bertahap dengan kill switch.

Setelah live, monitoring adalah bagian dari fitur. Lacak metrik kunci setiap hari dan beri alert pada lonjakan perilaku buruk. Versi prompt dan model, simpan snapshot keadaan yang bekerja, dan jadikan rollback rutinitas.

Jika ingin prototipe lebih cepat, alur build berbasis chat bisa membantu memvalidasi bentuk produk lebih awal. Di Koder.ai, misalnya, Anda bisa menghasilkan aplikasi kecil di sekitar fitur, menambahkan pelacakan dasar untuk metrik pilihan, dan iterasi pada janji pengguna saat menguji. Kecepatan membantu, tapi disiplin tetap sama: kirim hanya apa yang metrik dan guardrail Anda dukung.

Uji akhir: bisakah Anda menjelaskan perilaku fitur kepada pengguna dalam satu paragraf, termasuk kapan ia mungkin salah? Jika tidak bisa, itu belum siap diluncurkan, sebaik apa pun demo terlihat.