Seminggu lalu saya menghabiskan malam untuk “berdebat” dengan LLM lewat terminal. Kadang jawabannya tepat sasaran, kadang meleset jauh — dan hampir selalu, penyebabnya ada di prompt saya sendiri. Episode ini catatan saya tentang dua skill yang menurut saya wajib buat siapa pun yang kerja dengan LLM: prompt engineering dan RAG (Retrieval-Augmented Generation). Dua-duanya soal hal yang sama: bagaimana bicara efektif dengan model, entah lewat instruksi yang rapi atau lewat konteks yang relevan.
Prompt Engineering: Instruksi Itu Kode
Cara paling gampang memahami prompt engineering: anggap prompt sebagai spesifikasi program yang dieksekusi model bahasa. Prompt kabur hasilnya kabur. Beberapa pola yang terbukti membantu saya:
- Beri peran dan konteks: “Kamu reviewer kode senior, fokus ke bug konkurensi.”
- Contoh few-shot: tunjukkan 2–3 pasangan input-output sebelum tugas asli.
- Minta format keluaran eksplisit (JSON dengan skema tertentu) supaya mudah di-parse.
- Chain-of-thought: minta model menjelaskan langkah sebelum menjawab, membantu soal penalaran bertahap.
- Tetapkan batasan: panjang jawaban, bahasa, larangan menyebut topik tertentu.
Contoh prompt yang saya pakai untuk ekstraksi data terstruktur:
Kamu asisten ekstraksi data. Ekstrak info produk dari teks berikut.
Aturan:
- Keluarkan HANYA JSON valid, tanpa penjelasan.
- Skema: {"nama": string, "harga": number|null, "satuan": string|null}
- Jika data tidak ada, isi null. Jangan mengarang.
Teks:
"""Laptop ABC 14 inci, RAM 16GB, harga Rp12.500.000 unit."""Keterbatasan Prompt Saja
Masalah muncul saat pertanyaannya butuh pengetahuan privat atau yang muncul setelah cutoff pelatihan model. Model akan berhalusinasi — menjawab dengan percaya diri padahal mengarang. Solusi pertama saya dulu: tempel semua dokumen ke prompt. Tidak skala, dan context window terbatas. Solusi yang lebih elegan: RAG.
RAG: Kasih Model Catatan Sebelum Ujian
RAG = Retrieval-Augmented Generation. Analogi programmer: daripada memaksa model menghafal seluruh codebase, kita kasih dia akses pencarian. Alurnya: dokumen dipecah jadi chunk, tiap chunk diubah jadi embedding (vektor), disimpan di vector store. Saat user bertanya, pertanyaan juga di-embed, cari k chunk paling mirip (misal cosine similarity), lalu chunk itu disisipkan ke prompt sebagai konteks. Model menjawab berdasarkan konteks itu, bukan dari ingatan samar.
from sentence_transformers import SentenceTransformer
import numpy as np
model = SentenceTransformer("all-MiniLM-L6-v2")
docs = [
"Cut-off waktu deploy produksi adalah pukul 16.00 WIB.",
"Backup database harian berjalan otomatis jam 02.00.",
"Semua service baru wajib punya healthcheck endpoint.",
]
doc_vecs = model.encode(docs)
def rag_answer(question: str, k: int = 2) -> str:
q_vec = model.encode([question])[0]
scores = doc_vecs @ q_vec / (
np.linalg.norm(doc_vecs, axis=1) * np.linalg.norm(q_vec)
)
top = np.argsort(scores)[::-1][:k]
context = "\n".join(docs[i] for i in top)
return f"Jawab HANYA dari konteks ini:\n{context}\n\nPertanyaan: {question}"
print(rag_answer("Kapan backup database dijalankan?"))Contoh di atas baru sampai tahap retrieval + pembentukan prompt; langkah generation tinggal dikirim ke API LLM pilihan Anda. Intinya tetap sama: konteks yang relevan masuk prompt, model tinggal merangkai jawaban.
Pelajaran dari Praktik
- Chunking menentukan kualitas: terlalu besar konteks jadi bocor, terlalu kecil makna terpotong.
- Selalu instruksikan model untuk bilang “tidak ditemukan di konteks” ketimbang mengarang.
- Evaluasi RAG butuh dataset pertanyaan-jawaban sendiri; jangan cuma andalkan feeling.
- Prompt engineering dan RAG bukan saling menggantikan — dipakai bersama.
Dua jam eksperimen kecil dengan RAG memberi lompatan kualitas jawaban yang tidak bisa dicapai tweaking prompt saja. Kalau Anda baru mulai, coba dulu dengan 10 dokumen dan embedding lokal — rasakan bedanya sebelum menyeret framework besar.
Komentar Terbaru