Perbezaan prompt yang “ok” dan yang bagus biasanya pada satu perkara: model tahu apa tugasnya, format apa yang diharapkan, dan bila perlu kata “tidak pasti”. Prompt yang panjang tanpa had juga boleh picu 429 rate limit — kawal output dari awal.
Tiga elemen asas
Setiap prompt patut ada:
- Peranan — contoh: “Anda jurutera Python senior”
- Tugas — contoh: “Tukar JSON di bawah kepada jadual Markdown”
- Format output — bullet, jadual, JSON, had perkataan
Contoh:
Anda editor dokumentasi teknikal. Tulis semula penjelasan ralat API di bawah sebagai FAQ Bahasa Melayu.
Syarat:
- Guna ## untuk setiap soalan
- Jawapan maksimum 80 patah perkataan
- Jika tiada bukti, tulis "perlu disahkan dengan dokumentasi rasmi"
Kurangkan halusinasi
- Minta: “Jawab hanya berdasarkan teks yang diberi; jika maklumat tidak cukup, kata tidak tahu.”
- Untuk nombor, tarikh, atau peraturan: minta rujukan atau tanda “perlu disahkan”.
- Elakkan soalan terbuka tanpa konteks — beri contoh input/output.
Few-shot (1–2 contoh)
Untuk klasifikasi tiket sokongan:
Input: Log masuk dapat 503
Output: {"type":"server","action":"retry_later"}
Input: API return 401
Output: {"type":"auth","action":"check_api_key"}
Ralat 503/429 dalam pipeline API? Rujuk strategi ulang cuba.
Masalah biasa
| Gejala | Punca | Pembetulan |
|---|---|---|
| Jawapan terlalu panjang | Tiada had | Tambah “maksimum N patah perkataan” |
| Format berbeza setiap kali | Tiada template | Minta JSON atau Markdown tetap |
| Fakta rekaan | Tiada sempadan | Larangan mengada-adakan ciri |
| Campur BM/BI | Bahasa tidak jelas | Nyatakan “jawab dalam Bahasa Melayu” |
Cara iterasi
- Tulis prompt minimum
- Uji 3–5 input sebenar
- Tambah constraint hanya pada kes yang gagal
- Simpan versi prompt dalam repo (contoh:
prompts/v2-ringkasan.md)
Semasa saya susun template untuk pasukan khidmat pelanggan Shopee seller di JB, satu perenggan contoh output BM sudah cukup menstabilkan nada. Untuk ujian tanpa API awan, cuba Ollama tempatan. Masalah log masuk web ada di panduan login.