Kebanyakan panduan prompt engineering berhenti di tips level pemula: “jadilah spesifik”, “beri contoh”. Berguna, tapi tidak cukup untuk membangun aplikasi produksi yang butuh output konsisten dan andal. Artikel ini membahas teknik yang lebih jarang dibahas namun berdampak signifikan.

1. Decomposition: Pecah Task Kompleks Jadi Langkah Eksplisit

Alih-alih meminta LLM menyelesaikan task kompleks dalam satu prompt, pecah menjadi beberapa langkah eksplisit yang masing-masing punya output yang bisa diverifikasi.

Kurang efektif:

Analisis data penjualan ini dan buatkan rekomendasi strategi.

Lebih efektif (dipecah bertahap):

Langkah 1: Ringkas pola utama dari data penjualan ini (tanpa interpretasi).
Langkah 2: Identifikasi 3 anomali paling signifikan dari ringkasan tersebut.
Langkah 3: Berdasarkan anomali di atas, berikan rekomendasi yang bisa dieksekusi.

Pendekatan ini membuat setiap langkah bisa diaudit terpisah — jika hasil akhir salah, Anda tahu persis di langkah mana masalahnya muncul.

2. Structured Output dengan Skema Eksplisit

Untuk aplikasi yang mengonsumsi output LLM secara terprogram, jangan berharap format konsisten dari instruksi bahasa natural saja. Definisikan skema secara eksplisit (JSON schema atau function calling) daripada meminta “berikan dalam format JSON” secara longgar — model jauh lebih konsisten saat skema didefinisikan secara terstruktur dan divalidasi programmatis, bukan hanya diminta lewat teks.

3. Few-shot dengan Contoh Negatif

Kebanyakan few-shot prompting hanya memberi contoh output yang benar. Menambahkan contoh kasus yang salah beserta penjelasan mengapa salah sering meningkatkan akurasi signifikan, terutama untuk task klasifikasi atau evaluasi yang punya batas ambigu.

Contoh benar: [...]
Contoh salah dan alasannya: "[...]" — ini salah karena mencampur opini dengan fakta.

4. Self-Consistency Check di Dalam Prompt

Untuk task yang butuh akurasi tinggi, minta model memverifikasi jawabannya sendiri sebelum finalisasi:

Setelah menyusun jawaban, periksa kembali: apakah ada asumsi yang tidak didukung 
data di atas? Jika ada, revisi jawaban sebelum memberikan output final.

Teknik ini menurunkan tingkat kesalahan pada task penalaran multi-langkah, meski menambah biaya token.

5. Menangani Ambiguitas secara Eksplisit

Instruksikan model untuk secara eksplisit menyatakan ketidakpastian daripada memberi jawaban percaya diri yang salah:

Jika informasi di konteks tidak cukup untuk menjawab dengan yakin, katakan secara 
eksplisit bagian mana yang tidak bisa dipastikan, jangan mengarang.

Ini sangat penting untuk aplikasi RAG (lihat panduan membangun aplikasi RAG) di mana halusinasi berdampak langsung pada kepercayaan pengguna.

Kesalahan yang Sering Terjadi Setelah “Level Menengah”

  • Prompt yang terlalu panjang dengan instruksi bertumpuk — semakin panjang dan kompleks instruksi, semakin besar risiko model mengabaikan sebagian instruksi. Lebih baik decomposition (teknik #1) daripada satu prompt raksasa.
  • Tidak menguji prompt dengan edge case — prompt yang bekerja baik untuk kasus umum sering gagal pada input yang tidak biasa (input kosong, sangat panjang, format tidak terduga).
  • Mengabaikan versioning prompt — dalam aplikasi produksi, prompt perlu diperlakukan seperti kode: diversikan, diuji, dan diubah dengan hati-hati karena perubahan kecil bisa berdampak besar pada output.

Cara Mengukur Apakah Teknik Ini Benar-benar Membantu

Jangan hanya mengandalkan “kelihatannya lebih baik” secara subjektif. Bangun set evaluasi kecil (10-20 kasus representatif termasuk edge case) dan bandingkan hasil sebelum-sesudah perubahan prompt secara sistematis. Ini prinsip dasar yang sama dengan evaluasi retrieval pada sistem RAG — perubahan tanpa pengukuran hanya menghasilkan ilusi peningkatan.

Artikel ini melengkapi Panduan Praktis Membangun Aplikasi RAG dari Nol di seri Tutorial & Implementasi Teknis.