Dasar Prompt Engineering yang Sering Terlewat

Sejak menambahkan LLM ke sistem yang saya tangani sehari-hari — mulai dari asisten koding sampai fitur yang membantu proses coding medis di klinik — saya selalu balik ke pola yang sama ketika hasil dari model terasa meleset: masalahnya hampir selalu bukan di model, tapi di prompt. Banyak developer, termasuk saya di awal-awal, langsung lompat ke teknik-teknik rumit seperti chain-of-thought atau agentic tool use, padahal tiga dasar yang paling murah dan paling berdampak justru sering terlewat: instruksi yang eksplisit, contoh (few-shot), dan format output yang jelas. Tulisan ini saya buat sebagai pengingat praktis, karena tiga hal ini yang paling sering saya cek ulang setiap kali ada prompt yang "kadang benar kadang salah".

Instruksi eksplisit: jangan biarkan model menebak

LLM tidak membaca pikiran kita. Kalau instruksi ambigu, model akan mengisi celah itu dengan asumsi paling umum yang dipelajarinya dari data training — dan asumsi itu belum tentu cocok dengan konteks kerja kita. Misalnya, instruksi seperti "ringkas catatan ini" bisa menghasilkan ringkasan satu kalimat atau lima paragraf, tergantung mood model hari itu. Bandingkan dengan instruksi yang eksplisit menyebutkan panjang, audiens, dan batasan:

Ringkas catatan berikut untuk dibaca dokter jaga,
maksimal 3 kalimat, fokus pada diagnosis dan tindakan,
jangan sertakan riwayat yang tidak relevan dengan kondisi saat ini.

Prinsip yang saya pegang: kalau ada dua cara model bisa menafsirkan instruksi saya, saya belum selesai menulis prompt itu. Ini termasuk hal-hal yang terasa "terlalu jelas untuk disebutkan" — bahasa keluaran, satuan angka, atau apakah boleh menambahkan opini di luar data yang diberikan. Saya juga terbiasa menyebutkan secara eksplisit apa yang tidak boleh dilakukan model, karena batasan negatif sering lebih penting daripada instruksi positif, terutama untuk kasus-kasus yang berisiko seperti ringkasan medis atau kode yang menyentuh data produksi.

Contoh (few-shot): tunjukkan, jangan cuma jelaskan

Instruksi tekstual punya batas. Ada pola-pola yang jauh lebih mudah ditunjukkan lewat contoh daripada dideskripsikan dengan kata-kata — misalnya gaya penulisan, tingkat detail, atau cara memetakan input yang berantakan ke output yang rapi. Ini yang disebut few-shot prompting: menyertakan satu atau beberapa pasangan input-output sebagai contoh sebelum meminta model mengerjakan kasus baru.

Sebagai ilustrasi, kalau saya ingin model mengubah keluhan pasien dalam bahasa sehari-hari menjadi istilah yang lebih terstruktur, saya akan sertakan contoh konkret seperti ini di dalam prompt:

Input: "perut kanan bawah sakit banget udah 2 hari, agak demam"
Output: nyeri abdomen kuadran kanan bawah, durasi 2 hari, disertai demam

Input: "kepala pusing muter-muter kalau bangun tidur"
Output: vertigo, dipicu perubahan posisi

Dengan dua contoh saja, model biasanya sudah menangkap pola pemetaan yang saya mau, jauh lebih konsisten dibanding kalau saya hanya menjelaskan aturannya secara abstrak. Satu catatan penting: kualitas contoh jauh lebih menentukan daripada jumlahnya. Contoh yang tidak konsisten satu sama lain — misalnya format output yang beda-beda antar contoh — justru bikin model bingung, bukan membantu. Saya biasanya cukup dengan dua sampai empat contoh yang benar-benar mewakili variasi kasus yang akan dihadapi, daripada menumpuk banyak contoh yang mirip-mirip.

Format output: bikin hasilnya bisa langsung dipakai

Ini bagian yang paling sering saya lihat dilewatkan oleh developer yang baru mengintegrasikan LLM ke aplikasi. Kalau output model akan diparsing oleh kode, atau ditampilkan di antarmuka tertentu, jangan biarkan model bebas memilih formatnya sendiri. Minta secara eksplisit — JSON dengan skema yang jelas, tabel Markdown, daftar bernomor, atau apa pun yang sesuai kebutuhan sistem kita.

Keluarkan HANYA JSON dengan struktur berikut, tanpa teks tambahan:
{
  "diagnosis": string,
  "tingkat_keyakinan": "tinggi" | "sedang" | "rendah",
  "catatan": string
}

Beberapa hal praktis yang saya pelajari soal format output: pertama, sebutkan eksplisit kalau tidak boleh ada teks lain di luar format yang diminta — model punya kecenderungan menambahkan kalimat pembuka seperti "Berikut hasilnya:" kalau tidak dilarang. Kedua, kalau memungkinkan, gunakan fitur structured output atau tool calling yang disediakan API model modern, karena itu jauh lebih andal dibanding hanya mengandalkan instruksi teks untuk memaksa format JSON. Ketiga, tetap siapkan validasi dan fallback di sisi kode kita — sebagus apa pun instruksinya, model tetap bisa sesekali keluar dari format yang diminta, apalagi untuk input yang di luar kebiasaan.

Takeaway

Sebelum mengoprek teknik prompting yang lebih canggih, saya selalu cek dulu tiga hal ini: apakah instruksinya benar-benar eksplisit dan tidak menyisakan ruang tebak-tebakan, apakah saya sudah menunjukkan contoh konkret untuk pola yang sulit dijelaskan dengan kata-kata, dan apakah format output sudah saya tentukan sejelas mungkin. Dari pengalaman saya, memperbaiki tiga dasar ini biasanya menyelesaikan sebagian besar masalah "hasil LLM tidak konsisten" — jauh sebelum kita perlu masuk ke teknik yang lebih rumit.