Andrej Karpathy tentang pembelajaran mendalam menunjukkan cara mengubah neural net menjadi produk dengan asumsi yang jelas, metrik, dan alur kerja yang berorientasi rekayasa.
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:
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.
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:
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.
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.
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:
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.
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.
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:
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.
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:
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:
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.
Pengiriman AI paling baik saat Anda memperlakukannya seperti rekayasa: tujuan jelas, baseline, dan loop umpan balik cepat.
Pola praktis untuk alat penyusunan: ukur “detik hingga terkirim” dan “persentase draf yang digunakan dengan pengeditan kecil”.
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:
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.
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:
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”.
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:
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.
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:
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.
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.
Karena demo biasanya dibangun pada input bersih dan dipilih secara khusus dan dinilai berdasarkan impresi, sementara produk menghadapi input berantakan, tekanan pengguna, dan penggunaan berulang.
Untuk menutup kesenjangan itu, definisikan kontrak input/output, ukur kualitas pada data representatif, dan rancang fallback untuk timeout dan kasus berkepercayaan rendah.
Pilih satu metrik yang terkait dengan nilai pengguna yang dapat Anda pantau secara mingguan. Pilihan yang baik:
Tentukan target “cukup baik” sebelum Anda menyetel prompt atau model.
Gunakan alternatif paling sederhana yang bisa realistis diluncurkan:
Jika AI tidak mengalahkan baseline pada metrik utama (tanpa merusak latensi/biaya), jangan rilis dulu.
Pertahankan set kecil yang terlihat seperti lalu lintas nyata, bukan sekadar contoh terbaik.
Aturan praktis:
Ini membuat kemajuan terlihat dan mengurangi regresi yang tidak disengaja.
Mulai dengan guardrail yang dapat diuji dan dapat diprediksi:
Perlakukan guardrail seperti persyaratan produk, bukan hiasan opsional.
Pantau kesehatan sistem dan kualitas keluaran:
Juga log input/keluaran (dengan kontrol privasi) supaya Anda bisa mereproduksi kegagalan dan memperbaiki pola teratas terlebih dahulu.
Tetapkan anggaran maksimum di awal: target latensi dan maks biaya per permintaan.
Lalu kurangi pengeluaran tanpa menebak-nebak:
Sedikit peningkatan kualitas jarang sepadan dengan lonjakan biaya atau penurunan kecepatan di produksi.
Rilis di balik flag dan lakukan rollout bertahap.
Rencana rollout praktis:
Rollback bukan kegagalan; itu bagian dari membuat AI bisa dipertahankan.
Peran minimum yang perlu terlibat (meski satu orang memakai beberapa topi):
Rilis bekerja terbaik ketika semua pihak setuju pada metrik, baseline, dan rencana rollback.
Gunakan ketika Anda ingin bergerak dari ide ke aplikasi yang bekerja dengan cepat, tapi tetap menjaga disiplin rekayasa.
Alur kerja praktis:
Alat ini membantu Anda iterasi lebih cepat; Anda tetap butuh asumsi yang jelas dan keluaran yang terukur.
