Dari Prompt ke Produk: Mengubah LLM Menjadi Aplikasi Nyata

Prompt yang berhasil di playground adalah demo, bukan produk. Celah di antara keduanya adalah tempat sebagian besar proyek AI diam-diam mati. Membangun aplikasi LLM yang bertahan menghadapi pengguna nyata lebih sedikit berkaitan dengan prompting cerdik daripada yang disiratkan oleh demo, dan jauh lebih banyak berkaitan dengan disiplin perangkat lunak biasa. Kami telah menghadirkan cukup banyak dari ini — Youp, MadaiOps, dan sekarang Linea — hingga punya pendapat tentang apa yang sebenarnya menutup celah itu. Tidak ada satu pun darinya yang glamor.

Jebakannya adalah versi pertama terasa selesai. Anda menempelkan prompt yang cerdik, model mengembalikan sesuatu yang mengesankan, dan menggoda untuk membungkusnya dengan UI dan menyebutnya peluncuran. Lalu pengguna nyata datang dengan input yang tidak pernah Anda bayangkan, model melakukan sesuatu yang salah dengan penuh percaya diri, dan Anda menyadari Anda tidak punya cara untuk mengetahui apakah perbaikan Anda membuat keadaan lebih baik atau lebih buruk. Tulisan ini membahas perancah yang mengubah demo mengesankan itu menjadi sesuatu yang bisa Anda jalankan di produksi dan tidur nyenyak semalaman.

Mulai dengan eval, bukan prompt

Hal dengan pengungkit tertinggi yang bisa Anda bangun di awal adalah set evaluasi. Bukan benchmark, bukan leaderboard — sebuah folder berisi input nyata yang dipasangkan dengan seperti apa output yang baik. Dua puluh contoh mengalahkan nol, dan lima puluh contoh terkurasi mengalahkan seribu yang di-scrape.

Alasannya sederhana. Begitu Anda punya eval, rekayasa prompt berhenti menjadi soal firasat. Anda mengubah satu baris, Anda menjalankan set-nya, Anda mengamati angkanya bergerak. Tanpa eval, setiap penyesuaian adalah takhayul. Kami telah menyaksikan tim menghabiskan seminggu memperbaiki sebuah prompt hanya untuk mengalami regresi pada kasus yang sudah mereka pecahkan berbulan-bulan sebelumnya, karena tidak ada yang mengukur kasus yang tidak sedang mereka lihat.

Beberapa pendapat yang kami pegang teguh:

• Nilai berdasarkan hasil, bukan susunan kata. Untuk apa pun yang terstruktur — ekstraksi, klasifikasi, perutean — lakukan assert pada hasil yang di-parse, bukan pada kemiripan string. Untuk teks terbuka, LLM-sebagai-juri dengan rubrik yang ketat boleh saja, tetapi validasi juri itu terhadap segelintir label manusia terlebih dahulu, atau Anda hanya mengukur selera satu model.
• Simpan file regresi. Setiap kegagalan produksi menjadi test case permanen. Inilah cara set eval Anda tetap jujur — ia tumbuh persis ke arah-arah yang didorong oleh realitas.
• Beri versi pada eval Anda bersama prompt Anda. Prompt tanpa set eval-nya adalah perubahan kode yang belum diuji.

Jika Anda membangun satu hal dari artikel ini, bangunlah ini. Segala hal di hilir bergantung pada kemampuan menjawab: apakah itu membuatnya lebih baik?

Guardrail lebih murah daripada permintaan maaf

Model gagal dengan cara-cara yang tidak dilakukan perangkat lunak biasa. Mereka akan mengarang API yang tidak ada, menyetujui premis salah seorang pengguna, atau memancarkan JSON yang tampak valid dengan field yang dihalusinasikan. Guardrail adalah lapisan yang menangkap ini sebelum sampai ke pengguna atau, lebih buruk lagi, ke langkah eksekusi.

Pikirkan dalam tiga posisi.

• Guardrail input menolak atau membersihkan sebelum model berjalan: penyaringan prompt-injection, redaksi PII, penyaringan yang di luar topik.
• Guardrail output memvalidasi apa yang kembali: validasi skema, pemeriksaan grounding sitasi, filter kebijakan.
• Guardrail aksi duduk di antara model dan apa pun yang punya efek samping.

Yang ketiga itulah tempat risiko sesungguhnya berada. Di Linea, agen otomatisasi alur kerja kami, model dapat mengusulkan aksi — memanggil API, memindahkan record, mengirim pesan. Usulan dan eksekusi sengaja dibuat menjadi langkah terpisah. Setiap aksi berkonsekuensi melewati kontrak bertipe dan pemeriksaan kebijakan sebelum apa pun berjalan, dan aksi yang destruktif atau tak dapat dibalikkan memerlukan gerbang konfirmasi eksplisit. Sebuah agen yang menyarankan hal yang salah adalah masalah UX yang bisa Anda iterasi. Sebuah agen yang melakukan hal yang salah adalah sebuah insiden. Jaga kedua mode kegagalan itu berada di sisi berlawanan dari sebuah batas yang tegas.

Versi yang berpendirian: validasi output terstruktur terhadap skema dan lakukan retry saat gagal alih-alih memercayai model untuk konsisten. Dan jangan pernah biarkan output mentah sebuah model menjadi hal yang memicu aksi yang tak dapat dibalikkan. Selalu tempatkan pemeriksaan deterministik di antaranya.

Anggarkan latensi dan biaya seperti fitur

Latensi dan biaya bukan hal yang Anda ukur di akhir. Keduanya adalah kendala yang Anda rancang untuk dihadapi sejak awal, karena keduanya mengubah arsitektur, bukan sekadar tagihan.

Tetapkan anggaran eksplisit per aksi yang menghadap pengguna: target latensi p95 dan batas atas biaya per panggilan. Begitu keduanya tertulis, keputusan desain menjadi lebih mudah. Beberapa pola yang berulang kali kami andalkan:

• Sesuaikan ukuran model per langkah. Sebagian besar pipeline memiliki satu atau dua langkah yang benar-benar membutuhkan model frontier dan beberapa langkah yang bisa ditangani dengan baik oleh model yang lebih kecil dan lebih cepat. Merutekan klasifikasi sederhana ke model murah dan mencadangkan yang mahal untuk langkah penalaran yang sulit adalah optimisasi dengan imbal hasil tertinggi yang tersedia, dan biasanya juga memperbaiki latensi.
• Streaming token pertama. Untuk apa pun yang bersifat percakapan, latensi yang dirasakan didominasi oleh waktu-menuju-token-pertama. Respons yang di-stream selama empat detik terasa lebih baik daripada respons yang memblokir selama dua detik.
• Cache secara agresif. Prompt caching pada konteks sistem yang stabil, result caching biasa pada input berulang. Sebagian besar trafik produksi yang berarti bersifat mirip-duplikat.

Trade-off yang perlu Anda pegang dalam pikiran: model yang lebih besar mengurangi upaya rekayasa Anda tetapi menaikkan biaya marginal dan latensi Anda selamanya. Model yang lebih murah mendorong pekerjaan ke Anda — lebih banyak perhatian pada prompt, lebih banyak guardrail, lebih banyak eval — tetapi pekerjaan itu adalah biaya sekali bayar terhadap penghematan permanen. Untuk apa pun yang bervolume, keluarkan upaya rekayasa.

Jaga manusia dalam loop, dengan sengaja

"Human in the loop" begitu sering diucapkan hingga berhenti bermakna apa pun. Jika dilakukan dengan baik, ini bukan pengaman untuk saat AI gagal — ini adalah pembagian kerja yang dirancang. Pertanyaannya bukan apakah harus menyertakan manusia melainkan di mana penilaian manusia lebih berharga daripada latensi yang ditambahkannya.

Pola yang paling melayani kami adalah eskalasi berdasarkan tingkat keyakinan. Sistem menangani mayoritas yang penuh keyakinan secara otomatis dan merutekan minoritas yang tak pasti ke seorang manusia, dengan penalaran model dilampirkan sehingga manusia memutuskan dalam hitungan detik, bukan menit. Di MadaiOps, operasi order dalam parameter normal mengalir lancar; apa pun yang anomali dimunculkan ke seorang operator lengkap dengan konteks alih-alih dieksekusi dalam diam. Peninjau bukan sedang mengasuh mesin. Mereka menghabiskan perhatian mereka hanya di tempat yang langka dan berharga.

Satu aturan lagi: instrumentasikan koreksi manusia dan umpankan kembali ke set eval dan prompt Anda. Sistem human-in-the-loop yang tidak belajar dari manusianya hanyalah membayar dua kali untuk pekerjaan yang sama.

Ketahui apa yang tidak boleh diotomatiskan

Penilaian tersulit dalam disiplin ini adalah menahan diri. Tidak setiap tugas harus diserahkan ke model, dan kematangan adalah mengetahui yang mana yang harus dibiarkan sendiri.

Uji kasar kami: otomatiskan di tempat biaya sebuah kesalahan rendah, atau kesalahan mudah dideteksi dan dibalikkan. Menyusun draf, meringkas, mengekstrak, mengklasifikasikan, merutekan — kandidat yang baik. Draf yang salah bisa disunting; ringkasan yang salah tertangkap saat dibaca. Jauh lebih berhati-hatilah di tempat kesalahan mahal, sulit dideteksi, atau tak dapat dibalikkan: apa pun yang memindahkan uang, mengirim komunikasi yang tak dapat ditarik, atau membuat keputusan hukum atau medis. Di sana, model berada dalam peran membantu — memunculkan opsi, menyusun draf untuk ditinjau — bukan di kursi kemudi.

Garis yang kami pegang: jika Anda tidak bisa menjelaskan bagaimana Anda akan menangkap model yang salah, Anda belum siap mengotomatiskan langkah itu. Kemampuan mendeteksi kegagalan adalah prasyarat yang sesungguhnya, lebih dari sekadar akurasi. Langkah dengan akurasi 95% yang bisa Anda verifikasi sepenuhnya lebih aman untuk dihadirkan daripada langkah dengan akurasi 99% yang tidak bisa Anda verifikasi.

Bentuk dari pekerjaan itu

Mengubah sebuah prompt menjadi produk sebagian besar adalah bagian yang tidak glamor: eval agar Anda bisa mengukur, guardrail agar kegagalan tetap terkendali, anggaran agar tetap cepat dan terjangkau, manusia ditempatkan di tempat penilaian penting, dan disiplin untuk membiarkan beberapa hal tidak diotomatiskan. Model itu mungkin dua puluh persen dari sistem. Delapan puluh persen sisanya adalah rekayasa yang membuat kecemerlangan sesekali dari model itu aman untuk diandalkan.

Kabar baiknya adalah ini pekerjaan yang familier. Ia memberi imbalan pada naluri yang sama yang membuat perangkat lunak baik dalam jenis apa pun: ukur sebelum Anda mengubah, kendalikan radius ledakan Anda, hargai waktu pengguna Anda. Modelnya baru. Keahliannya tidak.