Andrej Karpathy pembelajaran mendalam: pelajaran untuk meluncurkan AI

Mengapa pembelajaran mendalam sering terasa sulit digunakan dalam produk nyata

Demo pembelajaran mendalam bisa terasa seperti sulap. Model menulis paragraf yang rapi, mengenali objek, atau menjawab pertanyaan rumit. Lalu Anda mencoba mengubah demo itu menjadi tombol yang ditekan orang setiap hari, dan semuanya menjadi berantakan. Prompt yang sama berperilaku berbeda, kasus tepi menumpuk, dan momen "wow" berubah menjadi tiket dukungan.

Kesenjangan itulah yang membuat karya Andrej Karpathy beresonansi dengan para pembuat. Ia mendorong pola pikir bahwa jaringan saraf bukan artefak misterius. Mereka adalah sistem yang Anda rancang, uji, dan rawat. Modelnya bukan tidak berguna. Produk hanya menuntut konsistensi.

Ketika tim mengatakan mereka menginginkan AI yang “praktis”, biasanya mereka berarti empat hal:

• Dapat diulang: berperilaku dapat diprediksi pada input umum, bukan hanya demo yang dikurasi.
• Terukur: Anda bisa mendefinisikan “baik” dengan angka, bukan nuansa.
• Terpelihara: Anda bisa memperbarui data, prompt, atau model tanpa merusak semuanya.
• Operable: Anda bisa memantau kegagalan, biaya, latensi, dan kualitas setelah rilis.

Tim kesulitan karena pembelajaran mendalam bersifat probabilistik dan sensitif terhadap konteks, sementara produk dinilai berdasarkan keandalan. Chatbot yang menjawab 80% pertanyaan dengan baik masih bisa terasa rusak jika 20% lainnya percaya diri, salah, dan sulit dideteksi.

Ambil contoh asisten "auto-reply" untuk dukungan pelanggan. Di beberapa tiket terpilih terlihat hebat. Di produksi, pelanggan menulis dengan slang, menyertakan tangkapan layar, mencampur bahasa, atau bertanya tentang kasus kebijakan. Sekarang Anda memerlukan guardrail, perilaku penolakan yang jelas, dan cara mengukur apakah draf itu benar-benar membantu agen.

Pekerjaan awal: memperlakukan jaringan saraf seperti rekayasa, bukan sihir

Banyak orang pertama kali mengenal karya Karpathy lewat contoh praktis, bukan matematika abstrak. Bahkan proyek awal menegaskan satu poin sederhana: jaringan saraf menjadi berguna ketika Anda memperlakukannya seperti perangkat lunak yang bisa diuji, dipatahkan, dan diperbaiki.

Alih-alih berhenti pada “modelnya bekerja”, fokus bergeser ke membuatnya bekerja pada data kotor nyata. Itu meliputi pipeline data, run pelatihan yang gagal karena alasan sepele, dan hasil yang berubah saat Anda mengubah satu hal kecil. Dalam dunia itu, pembelajaran mendalam berhenti terdengar mistis dan mulai terasa seperti rekayasa.

Pendekatan ala Karpathy kurang tentang trik rahasia dan lebih tentang kebiasaan:

• Mulai dengan baseline yang bisa Anda kalahkan, meski sederhana.
• Pilih satu metrik yang menentukan “lebih baik” vs “lebih buruk.”
• Ubah satu hal pada satu waktu sehingga Anda tahu apa yang menyebabkan hasilnya.
• Periksa kesalahan dan contoh, bukan hanya skor akhir.

Dasar itu penting karena AI produk pada dasarnya permainan yang sama, hanya dengan taruhannya lebih tinggi. Jika Anda tidak membangun kerajinan sejak dini (input jelas, output jelas, run yang dapat diulang), mengirim fitur AI berubah menjadi tebak-tebakan.

Membuat jaringan saraf dapat dipahami oleh insinyur yang bekerja

Bagian besar dari dampak Karpathy adalah memperlakukan jaringan saraf sebagai sesuatu yang bisa Anda pikirkan secara rasional. Penjelasan yang jelas mengubah pekerjaan dari “sistem kepercayaan” menjadi rekayasa.

Itu penting untuk tim karena orang yang mengirim prototipe pertama sering bukan orang yang memeliharanya. Jika Anda tidak bisa menjelaskan apa yang dilakukan model, Anda mungkin tidak bisa men-debug-nya, dan pasti tidak bisa mendukungnya di produksi.

Jelaskan seolah-olah Anda berencana memeliharanya

Paksa kejelasan sejak awal. Sebelum membangun fitur, tuliskan apa yang dilihat model, apa yang dihasilkannya, dan bagaimana Anda akan tahu jika itu membaik. Sebagian besar proyek AI gagal karena hal dasar, bukan karena matematika.

Checklist singkat yang memberi keuntungan nanti:

• Apa input dan output tepatnya (format, batas, redaksi)?
• Baseline apa yang harus Anda kalahkan (aturan, pencarian, template, atau model lebih kecil)?
• Seperti apa “baik” (angka, rubrik, atau keduanya)?
• Kegagalan mana yang tidak dapat diterima (keselamatan, privasi, nada merek)?
• Siapa yang meninjau hasil, dan seberapa sering?

Reproduksibilitas adalah bagian dari penjelasan

Pemikiran yang jelas muncul sebagai eksperimen yang disiplin: satu skrip yang bisa Anda jalankan ulang, dataset evaluasi tetap, prompt yang versi-signed, dan metrik yang dicatat. Baseline menjaga Anda jujur dan membuat kemajuan terlihat.

Dari prototipe ke produksi: apa yang berubah saat dirilis

Prototipe membuktikan gagasan bisa bekerja. Fitur yang dirilis membuktikan ia bekerja untuk orang nyata, dalam kondisi berantakan, setiap hari. Kesenjangan itulah tempat banyak proyek AI terhenti.

Demo riset bisa lambat, mahal, dan rapuh selama ia menunjukkan kapabilitas. Produksi membalik prioritas. Sistem harus dapat diprediksi, dapat diamati, dan aman bahkan saat input aneh, pengguna tidak sabar, dan lonjakan trafik.

Batasan yang tiba-tiba Anda pedulikan

Di produksi, latensi adalah fitur. Jika model butuh 8 detik, pengguna batal atau menekan tombol berulang, dan Anda membayar setiap retry. Biaya juga menjadi keputusan produk, karena perubahan prompt kecil bisa menggandakan tagihan Anda.

Monitoring tidak bisa ditawar. Anda perlu tahu bukan hanya layanan aktif, tetapi keluaran tetap dalam kualitas yang dapat diterima seiring waktu. Perubahan data, perilaku pengguna baru, dan perubahan upstream bisa diam-diam merusak performa tanpa memicu error.

Pemeriksaan keselamatan dan kebijakan pindah dari “bagus untuk dimiliki” menjadi wajib. Anda harus menangani permintaan berbahaya, data pribadi, dan kasus tepi dengan cara yang konsisten dan dapat diuji.

Tim biasanya berakhir menjawab set pertanyaan yang sama:

• Berapa waktu respons maksimum yang dapat diterima dan biaya per permintaan?
• Apa fallback ketika model gagal atau timeout?
• Metrik mana yang mendefinisikan kualitas, dan ambang mana yang memicu alert?
• Bagaimana mencegah keluaran yang tidak aman atau tidak patuh?
• Bagaimana menggulung kembali dengan cepat jika kualitas turun?

Perlu lebih dari sekadar keterampilan model

Prototipe bisa dibangun oleh satu orang. Pengiriman biasanya membutuhkan product untuk mendefinisikan keberhasilan, data untuk memvalidasi input dan set evaluasi, infrastruktur untuk menjalankannya secara andal, dan QA untuk menguji mode kegagalan.

"Works on my machine" bukanlah kriteria rilis. Rilis berarti bekerja untuk pengguna saat beban, dengan logging, guardrail, dan cara mengukur apakah itu membantu atau merugikan.

Budaya rekayasa: asumsi, baseline, dan iterasi

Pengaruh Karpathy bersifat kultural, bukan hanya teknis. Ia memperlakukan jaringan saraf seperti sesuatu yang bisa Anda bangun, uji, dan tingkatkan dengan disiplin yang sama seperti sistem rekayasa lainnya.

Mulanya dengan menulis asumsi sebelum menulis kode. Jika Anda tidak bisa menyatakan apa yang harus benar agar fitur bekerja, Anda tidak akan bisa men-debug-nya nanti. Contoh:

• “Pengguna akan menerima jawaban yang disarankan jika itu benar dan sesuai nada mereka.”
• “Latensi di bawah 800 ms diperlukan atau orang berhenti menggunakannya.”

Itu pernyataan yang bisa diuji.

Baseline datang berikutnya. Baseline adalah hal paling sederhana yang mungkin berhasil, dan itu jadi pemeriksa realitas Anda. Bisa berupa aturan, template pencarian, atau bahkan “tidak melakukan apa-apa” dengan UI yang baik. Baseline kuat melindungi Anda dari menghabiskan minggu untuk model mewah yang tidak mengalahkan sesuatu yang sederhana.

Instrumentasi membuat iterasi mungkin. Jika Anda hanya melihat demo, Anda mengarahkan berdasarkan nuansa. Untuk banyak fitur AI, sejumlah kecil angka sudah memberitahu apakah Anda membaik:

• Adopsi (siapa yang mencoba dan terus menggunakan)
• Kualitas (tingkat penerimaan, pengeditan sebelum mengirim, jempol naik/turun)
• Kecepatan (latensi dan waktu ke keluaran berguna pertama)
• Biaya (token, compute, waktu review manusia)
• Keselamatan (pelanggaran kebijakan, kebocoran data sensitif, upaya jailbreak)

Lalu iterasi dalam loop rapat. Ubah satu hal, bandingkan dengan baseline, dan simpan log sederhana tentang apa yang Anda coba dan apa yang bergerak. Jika kemajuan nyata, itu muncul sebagai grafik.

Langkah demi langkah: alur kerja sederhana untuk merilis fitur AI

Pengiriman AI paling baik saat Anda memperlakukannya seperti rekayasa: tujuan jelas, baseline, dan loop umpan balik cepat.

1. Nyatakan masalah pengguna dalam satu kalimat. Tulis seperti keluhan nyata: “Agen dukungan menghabiskan terlalu lama membuat balasan untuk pertanyaan umum.” Jika Anda tidak bisa merumuskannya satu kalimat, fiturnya mungkin terlalu besar.
2. Pilih hasil yang terukur. Pilih satu angka yang bisa Anda pantau mingguan. Pilihan baik termasuk waktu yang dihemat per tugas, tingkat penerimaan draf pertama, pengurangan pengeditan, atau tingkat defleksi tiket. Tentukan apa yang “cukup baik” sebelum membangun.
3. Tentukan baseline yang harus Anda kalahkan. Bandingkan dengan template sederhana, pendekatan berbasis aturan, atau “hanya manusia”. Jika AI tidak mengalahkan baseline pada metrik yang dipilih, jangan rilis.
4. Rancang tes kecil dengan data representatif. Kumpulkan contoh yang sesuai realitas, termasuk kasus berantakan. Simpan set evaluasi kecil yang tidak Anda “latih secara mental” dengan membacanya setiap hari. Tuliskan apa yang dihitung sebagai lulus dan apa yang gagal.
5. Rilis di balik flag, kumpulkan umpan balik, dan iterasi. Mulai dengan grup internal kecil atau persentase kecil pengguna. Log input, output, dan apakah itu membantu. Perbaiki mode kegagalan teratas dulu, lalu jalankan kembali tes yang sama sehingga Anda bisa melihat kemajuan nyata.

Pola praktis untuk alat penyusunan: ukur “detik hingga terkirim” dan “persentase draf yang digunakan dengan pengeditan kecil”.

Asumsi jelas dan keluaran terukur (apa yang harus ditulis)

Banyak kegagalan fitur AI bukan kegagalan model. Mereka adalah kegagalan “kita tidak pernah sepakat seperti apa suksesnya”. Jika Anda ingin pembelajaran mendalam terasa praktis, tulis asumsi dan ukuran sebelum menulis prompt atau melatih model lebih banyak.

Mulai dengan asumsi yang bisa merusak fitur Anda di penggunaan nyata. Umumnya tentang data dan orang: teks input dalam satu bahasa, pengguna meminta satu intent sekaligus, UI memberi konteks cukup, kasus tepi jarang, dan pola kemarin masih berlaku bulan depan (drift). Juga tuliskan apa yang belum Anda tangani, seperti sarkasme, nasihat hukum, atau dokumen panjang.

Ubah setiap asumsi menjadi sesuatu yang bisa Anda uji. Format yang berguna: “Diberikan X, sistem harus melakukan Y, dan kita bisa memverifikasinya dengan Z.” Jaga agar konkret.

Lima hal yang layak ditulis pada satu halaman:

• Input: apa yang dilihat model (field, batas, redaksi) dan apa arti “cukup bersih”
• Kontrak output: apa yang harus dikembalikan (format, nada, tindakan yang diizinkan)
• Evaluasi offline: set kecil berlabel dengan aturan skor (lulus/gagal plus metrik)
• Metrik online: apa yang pengguna lakukan (tingkat penerimaan, pengeditan, waktu yang dihemat, tiket dibuka kembali)
• Guardrail: kapan menolak, bertanya, atau fallback ke alur lebih sederhana

Jaga offline dan online terpisah dengan sengaja. Metrik offline memberitahu apakah sistem mempelajari tugas. Metrik online memberitahu apakah fitur membantu manusia. Model bisa bernilai tinggi secara offline tetapi masih mengganggu pengguna karena lambat, terlalu percaya diri, atau salah pada kasus yang penting.

Tentukan “cukup baik” sebagai ambang dan konsekuensi. Contoh: “Offline: setidaknya 85% benar pada set eval; Online: 30% draf diterima dengan pengeditan minimal.” Jika Anda melewatkan ambang, putuskan sebelumnya apa yang terjadi: tetap di balik toggle, kurangi rollout, rute kasus berkepercayaan rendah ke template, atau berhenti dan kumpulkan lebih banyak data.

Kesalahan umum saat tim menambahkan AI ke produk

Tim sering memperlakukan fitur AI seperti tweak UI biasa: rilis, lihat apa yang terjadi, sesuaikan kemudian. Itu rusak cepat karena perilaku model bisa berubah dengan prompt, drift, dan perubahan konfigurasi kecil. Hasilnya banyak kerja tanpa bukti jelas bahwa itu membantu.

Aturan praktis sederhana: jika Anda tidak bisa menyebut baseline dan pengukuran, Anda belum siap rilis.

Mode kegagalan paling umum:

• Meluncurkan tanpa baseline non-AI, sehingga peningkatan tidak dapat dibuktikan.
• Mengejar kualitas sambil mengabaikan latensi dan biaya (kenaikan 3% tidak sebanding dengan 5x lebih lambat).
• Bergantung pada umpan balik kabur (“pengguna menyukainya”) daripada instrumentasi.
• Menyetel pada set tes kecil atau dipilih yang tidak cocok dengan lalu lintas nyata.
• Tidak punya rencana rollback saat prompt atau pembaruan model menghasilkan keluaran aneh.

Contoh konkret: Anda menambahkan AI untuk menyusun balasan dukungan. Jika Anda hanya melacak jempol, Anda mungkin melewatkan bahwa agen membutuhkan waktu lebih lama meninjau draf, atau balasan akurat tapi terlalu panjang. Ukuran yang lebih baik adalah “persentase terkirim dengan pengeditan minimal” dan “median waktu hingga terkirim”.

Checklist cepat sebelum rilis

Perlakukan hari rilis seperti serah terima rekayasa, bukan demo. Anda harus bisa menjelaskan, dengan kata-kata biasa, apa yang dilakukan fitur, bagaimana Anda tahu itu bekerja, dan apa yang akan Anda lakukan saat itu rusak.

Sebelum rilis, pastikan Anda memiliki:

• Satu paragraf pernyataan masalah dan pengguna target yang jelas.
• Baseline yang diukur (meski sederhana).
• Satu metrik online utama terkait nilai pengguna, plus log yang menangkap input, output, dan hasil.
• Tinjauan keselamatan: mode kegagalan yang mungkin, siapa yang dirugikan, dan apa yang dilakukan UI (peringatkan, blok, minta konfirmasi).
• Rencana rollback dengan pemilik: apa yang memicu rollback dan apa yang Anda cek di jam pertama.

Juga simpan set evaluasi offline yang mirip lalu lintas nyata, mencakup kasus tepi, dan cukup stabil untuk dibandingkan antar minggu. Saat Anda mengubah prompt, model, atau pembersihan data, jalankan ulang set yang sama dan lihat apa yang berubah.

Skenario contoh: merilis fitur penyusunan balasan untuk dukungan

Tim dukungan ingin asisten yang menyusun balasan di dalam tampilan tiket. Agen tidak mengirim pesan sendiri. Asisten menyarankan draf, menyorot fakta kunci yang digunakan, dan meminta agen meninjau dan mengedit sebelum mengirim. Pilihan itu menjaga risiko rendah sambil Anda belajar.

Mulailah dengan memutuskan apa arti “lebih baik” dalam angka. Pilih hasil yang bisa Anda ukur sejak hari pertama menggunakan log yang ada:

• Rata-rata waktu penanganan (open sampai solved)
• Tingkat pengeditan (berapa banyak agen mengubah draf sebelum mengirim)
• Tingkat eskalasi (tiket meningkat ke tingkat lebih tinggi)
• Tingkat dibuka kembali (tiket dibuka kembali dalam 7 hari)
• Skor kepuasan pelanggan (jika sudah Anda lacak)

Sebelum memanggil model, tetapkan baseline yang membosankan tapi nyata: template yang disimpan plus lapisan aturan sederhana (deteksi refund vs pengiriman vs reset kata sandi, lalu isi template terbaik). Jika AI tidak mengalahkan baseline itu, belum siap.

Jalankan pilot kecil. Buat opt-in untuk beberapa agen, dibatasi ke satu kategori tiket terlebih dahulu (misal, status pesanan). Tambahkan umpan balik cepat pada setiap draf: “berguna” atau “tidak berguna,” plus alasan singkat. Tangkap apa yang agen ubah, bukan hanya apakah mereka menekan tombol.

Tentukan kriteria rilis di awal agar Anda tidak menebak nanti. Contoh: waktu penanganan membaik 10% tanpa menaikkan eskalasi atau tingkat dibuka kembali, dan agen menerima draf dengan pengeditan minimal setidaknya 30% waktu.

Juga putuskan apa yang memicu rollback: lonjakan eskalasi, penurunan kepuasan, atau kesalahan kebijakan berulang.

Langkah selanjutnya: terapkan pelajaran ini ke rilis AI Anda berikutnya

Pilih satu ide AI yang bisa Anda rilis dalam 2–4 minggu. Jaga agar cukup kecil sehingga Anda bisa mengukurnya, men-debug, dan menggulung kembali tanpa drama. Tujuannya bukan membuktikan model pintar. Tujuannya membuat hasil pengguna lebih baik secara andal daripada yang sudah Anda miliki.

Ubah ide menjadi rencana satu halaman: apa yang dilakukan fitur, apa yang tidak dilakukan, dan bagaimana Anda akan tahu itu bekerja. Sertakan baseline dan metrik tepat yang akan Anda pantau.

Jika Anda ingin bergerak cepat ke implementasi, Koder.ai (koder.ai) dibangun untuk membuat aplikasi web, server, dan mobile lewat antarmuka chat, dengan fitur seperti snapshot/rollback dan ekspor kode sumber saat Anda membutuhkan kontrol lebih dalam.

Kebiasaan yang perlu dipertahankan sederhana: setiap perubahan AI harus disertai asumsi tertulis dan keluaran yang terukur. Itulah cara pembelajaran mendalam berhenti terasa seperti sulap dan mulai terasa seperti pekerjaan yang bisa Anda kirimkan.