Prompt Engineering untuk LLM Lokal — Dari Prompt Biasa ke Hasil yang Lebih Tepat

Aku masih ingat pertama kali menjalankan LLM lokal di laptop bekasku. Rasanya seperti baru saja membangun assistant pribadi di sudut kamar: tidak perlu internet, tidak perlu langganan API, dan yang paling penting — data tidak pergi ke mana-mana. Tapi euforia itu cepat mereda begitu aku mulai menanyakan hal yang sedikit kompleks. "Jelaskan perbedaan REST dan GraphQL," jawabnya muter-muter. "Bantu aku debug ini," malah dia yang bingung. Rasanya seperti menyuruh teman yang pinter tapi pelupa untuk mengerjakan PR tanpa memberi petunjuk yang jelas.

Di sinilah prompt engineering masuk. Bukan sihir, bukan juga trik marketing. Prompt engineering itu cara kita merumuskan instruksi agar model bahasa — terutama yang berjalan di perangkat terbatas seperti LLM lokal — bisa memahami maksud kita dengan lebih akurat. Dalam artikel ini, aku akan membahas beberapa teknik yang paling sering kupakai saat berinteraksi dengan Qwen 2.5 Coder 7B yang kujalankan di rumah.

Apa Itu Prompt Engineering?

Secara sederhana, prompt engineering adalah seni (dan sedikit ilmu) menyusun masukan untuk model bahasa agar menghasilkan keluaran yang lebih baik. Bayangkan kamu memesan kopi di warung. Kalau cuma bilang "kopi," barista bisa bingung: kopi hitam? kopi susu? pahit? manis? panas? dingin? Tapi kalau kamu bilang, "Kopi susu, panas, manisnya sedikit, pakai gula aren," kemungkinan besar hasilnya sesuai harapan.

Model bahasa bekerja dengan cara yang sama. Semakin spesifik dan terstruktur instruksimu, semakin dekat hasilnya dengan yang kamu inginkan. Hal ini menjadi lebih penting untuk LLM lokal karena ukuran modelnya lebih kecil, context window-nya terbatas, dan kemampuan penalarannya lebih dalam kekurangan dibanding model kelas GPT-4o.

Mengapa LLM Lokal Butuh Teknik Ini?

Model lokal seperti Qwen 2.5 Coder 7B atau Llama 3 8B itu cukup cerdas, tapi mereka punya kelemahan yang jelas:

• Ukuran parameter lebih kecil — mereka tidak menyimpan sebanyak fakta dunia seperti model besar.
• Mudah halusinasi — terutama saat ditanya soal yang di luar domain pelatihan.
• Context window terbatas — kita tidak bisa memasukkan banyak dokumen sekaligus.
• Format jawaban bisa berantakan — tanpa instruksi yang jelas, model sering mengembalikan campuran teks, kode, dan penjelasan tanpa struktur.

Itu sebabnya, teknik prompt engineering bukan lagi bonus, melainkan kebutuhan dasar.

1. Role Prompting: Beri Model Sebuah Persona

Salah satu teknik paling cepat dan efektif adalah memberi model sebuah peran. Katakan padanya siapa dia dan dalam kapasitas apa dia menjawab.

Kamu adalah seorang sysadmin Linux berpengalaman yang sedang membimbing junior developer. Jelaskan perbedaan antara cron dan systemd timer dengan bahasa yang sederhana, tambahkan contoh perintah, dan sebutkan kapan sebaiknya memakai masing-masing.

Dengan prompt di atas, model akan mengadopsi persona tersebut dan menyesuaikan gaya bahasanya. Hasilnya biasanya lebih terstruktur, lebih relevant, dan lebih sedikit omong kosong. Teknik ini bekerja karena model dilatih dengan banyak gaya penulisan berbeda, dan memberi peran membantu model "menggeser" ke mode yang tepat.

2. Few-Shot Prompting: Ajari dengan Contoh

Model bahasa belajar dari pola. Kalau kamu memberikan satu atau dua contoh format yang kamu inginkan, kemungkinan besar output berikutnya akan mengikuti pola yang sama.

Klasifikasikan sentiment kalimat berikut sebagai POSITIF, NEGATIF, atau NETRAL.

Kalimat: Aplikasi ini sangat membantu dan cepat.
Sentimen: POSITIF

Kalimat: Saya kecewa karena fitur pencarian sering error.
Sentimen: NEGATIF

Kalimat: Update terbaru cukup biasa saja, tidak ada yang istimewa.
Sentimen:

Teknik ini sangat berguna untuk tugas-tugas berulang seperti klasifikasi, ekstraksi data, atau format JSON tertentu. Untuk LLM lokal, few-shot prompting sering kali lebih andal daripada hanya memberi instruksi abstrak.

3. Chain-of-Thought: Pikirkan Langkah demi Langkah

Model kecil cenderung melompat ke kesimpulan. Agar dia lebih hati-hati, kita bisa meminta dia untuk menuliskan proses berpikirnya.

Sebuah server memiliki 4 GB RAM. Aplikasi A memakai 1.2 GB, aplikasi B memakai 800 MB, dan sistem operasi membutuhkan 1 GB. Bisakah kita menjalankan aplikasi C yang membutuhkan 1.5 GB? Jelaskan langkah demi langkah.

Dengan tambahan "langkah demi langkah," model dipaksa untuk memecah masalah: menghitung total pemakaian, membandingkan dengan kapasitas, lalu baru memberikan kesimpulan. Hasilnya biasanya lebih akurat, terutama untuk soal matematika, logika, atau troubleshooting.

4. Break Down Complex Tasks: Potong Jadi Bagian Kecil

LLM lokal sering kewalahan jika diminta mengerjakan sesuatu yang besar sekaligus. Solusinya: pecah jadi beberapa langkah.

Saya ingin membuat shell script untuk backup otomatis. Kerjakan dalam tiga langkah:
1. Buatkan struktur direktori dan nama file yang tepat.
2. Tuliskan skrip utama dengan restic.
3. Berikan contoh cron job untuk menjalankannya setiap hari pukul 02:00.

Cara ini mirip dengan cara kita memotong roti: lebih mudah dikunyah, lebih mudah dicek, dan lebih sedikit yang tersisa di pipi.

5. Provide Context and Constraints: Beri Batasan yang Jelas

Model tidak bisa menebak apa yang ada di pikiranmu. Semakin banyak konteks dan batasan yang kamu berikan, semakin presisi outputnya.

Konteks: Saya membuat API untuk home server menggunakan PHP 8.4 native tanpa framework.
Batasan: Tidak boleh pakai Composer, tidak boleh pakai ORM, dan query MySQL harus pakai prepared statement.
Tugas: Buatkan endpoint sederhana untuk login dengan JWT, lengkap dengan validasi input dan error handling.

Dengan konteks dan batasan yang jelas, model tidak akan mengusulkan Laravel, Eloquent, atau library eksternal. Dia akan bekerja di dalam kerangka yang kamu tentukan.

Antipattern: Prompt yang Sebaiknya Dihindari

Sebelum mengakhiri, ada beberapa kebiasaan buruk yang sering kulasukan — dan sebaiknya tidak kamu tiru:

• Prompt terlalu pendek dan kabur: "Coding dong." Model tidak tahu bahasa, tujuan, atau konteksnya.
• Prompt tanpa format output: kalau kamu mau JSON, bilang JSON. Kalau mau daftar, bilang daftar.
• Prompt yang meminta banyak hal sekaligus: "Jelaskan Linux, buatkan skrip backup, terus desain database." Pecah menjadi beberapa sesi.
• Tidak memberi konteks domain: "Fix bug ini," tanpa menyertakan kode atau pesan error.

Kesimpulan

Prompt engineering bukan tentang membuat model menjadi lebih pintar, tapi tentang membuat komunikasi antara kita dan model menjadi lebih jelas. Untuk LLM lokal yang berjalan di perangkat terbatas, teknik ini bahkan lebih penting karena setiap token dan setiap konteks sangat berharga.

Mulailah dari yang sederhana: beri peran, tambahkan contoh, minta penjelasan langkah demi langkah, pecah tugas besar, dan selalu beri batasan. Dengan latihan, kamu akan terkejut betapa jauh perbedaan sebuah prompt yang dirancang dengan baik dibanding prompt yang dibuat asal-asalan.

Kalau kamu punya teknik favorit sendiri, tulis di kolom komentar. Aku masih terus belajar, dan setiap trik baru selalu menarik untuk dicoba.