Hari ini saya dapat belajar satu hal yang selama ini membingungkan saya sebagai programmer: kalau LLM kurang “bisa” untuk kasus kita, sebenarnya ada tiga jalan keluar — prompting, RAG, atau fine-tuning — dan ketiganya punya biaya, waktu, dan kasus pakai yang sangat berbeda. Saya sempat salah pilih beberapa kali (misalnya mau fine-tuning padahal cuma butuh prompt yang lebih terstruktur), jadi saya catat di sini decision matrix yang akhirnya saya pakai.
Tiga level intervensi, analoginya untuk programmer
Saya membingkai ini begini supaya mudah diingat:
- Prompting = kasih instruksi lebih jelas ke karyawan yang sudah kerja di perusahaan. Paling cepat, gratis, tapi terbatas pada kemampuan dasar dia.
- RAG = kasih akses perpustakaan dan dokumen internal ke karyawan yang sama. Dia tidak “tahu” lebih banyak, tapi bisa mencari fakta yang kita butuhkan saat diminta.
- Fine-tuning = melatih ulang karyawan supaya gaya kerjanya berubah permanen. Butuh data, waktu, dan biaya — tapi hasilnya nempel.
Prompting — selalu langkah pertama
Sebelum sentuh yang lain, saya biasanya habiskan waktu di prompt dulu: contoh few-shot, format output yang eksplisit, role yang jelas. Ini gratis dan hasilnya bisa langsung diukur. Kalau masalahnya “jawabannya kurang terstruktur” atau “sering salah formatnya”, hampir selalu cukup di tahap ini. Di episode #19 kita sudah bahas prompt engineering dan RAG dasar — sebagian besar kebutuhan sehari-hari berhenti di sana.
Batasnya jelas: kalau butuh fakta terbaru atau pengetahuan privat (dokumen internal, harga produk hari ini, knowledge base perusahaan), prompting tidak menolong — context window cuma bisa muat apa yang kita paste ke prompt.
RAG — ketika butuh fakta yang tidak ada di model
RAG (Retrieval-Augmented Generation) berarti: dokumen kita di-chunk, di-embed, disimpan di vector DB, lalu saat user bertanya kita cari potongan relevan dan sisipkan ke prompt. Modelnya tidak berubah — yang berubah adalah bahan yang dia baca. Ini solusi standar untuk knowledge base internal, FAQ produk, atau data yang berubah tiap minggu.
Sisi sulitnya bukan di model, tapi di pipeline-nya: kualitas chunking, strategi embedding, hybrid search dengan BM25, dan evaluasi retrieval-nya sendiri. Itu semua dibahas lebih dalam di episode #33.
Fine-tuning — ketika masalahnya gaya dan perilaku
Ini yang paling sering disalahpahami. Fine-tuning BUKAN cara menambah fakta baru ke model — fakta baru masuk lewat RAG atau system prompt. Fine-tuning cocok untuk: gaya bahasa yang konsisten, format output yang sangat spesifik, perilaku yang harus seragam di ratusan ribu request, atau task sempit yang butuh latensi rendah tanpa prompt panjang.
Praktisnya sekarang jauh lebih murah dari bayangan saya: LoRA dan QLoRA bikin fine-tuning bisa jalan di GPU consumer dengan dataset ribuan baris, bukan jutaan. Langkah praktisnya kita bahas di episode #32.
Decision matrix yang saya pakai
| Kebutuhan | Solusi | Biaya/waktu |
|---|---|---|
| Jawaban kurang terstruktur, format sering salah | Prompting (few-shot, schema) | Menit |
| Butuh fakta terbaru / dokumen internal | RAG | Hari (pipeline dan embedding) |
| Gaya/perilaku harus konsisten dan spesifik | Fine-tuning (LoRA) | Hari–minggu + GPU |
| Task sempit, latensi kritis, tanpa prompt panjang | Fine-tuning model kecil | Minggu |
| Validasi kualitas (semua kasus di atas) | Evals — golden dataset dulu | Wajib, lihat #30 |
Urutan default saya sekarang: ukur dulu dengan eval (episode #30), coba perbaik lewat prompt, kalau tetap kurang baru RAG, dan fine-tuning hanya kalau masalahnya memang gaya/perilaku — bukan pengetahuan.
Pseudocode keputusannya
def pilih_pendekatan(kebutuhan):
if kebutuhan == "tambah_fakta_baru" or kebutuhan == "data_berubah_sering":
return "RAG" # model tidak diubah, bahan dibaca dari vector DB
if kebutuhan == "gaya_konsisten" or kebutuhan == "format_sangat_spesifik":
return "fine_tuning" # LoRA/QLoRA, mulai dari episode #32
if kebutuhan == "format_salah_dan_jawaban_kurang_terarah":
return "prompting" # few-shot + instruksi eksplisit, gratis
return "evals_dulu" # belum tahu masalahnya? ukur dulu (episode #30)Yang saya pelajari dari kesalahan saya
Kesalahan terbesar saya: menganggap fine-tuning sebagai “upgrade ajaib” supaya model menjawab dengan benar. Setelah saya ukur dengan eval, sebagian besar kasus saya ternyata selesai di prompting dan RAG — dan saya baru sadar bahwa tanpa eval, saya bahkan tidak tahu apakah fine-tuning benar-benar memperbaiki sesuatu. Ketiganya juga bukan pilihan eksklusif: sistem yang saya temui paling matang memakai ketiganya sekaligus — RAG untuk fakta, fine-tuning untuk gaya, dan prompting sebagai lapisan terakhir yang paling murah.
Sumber
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — Lewis dkk., 2020 (paper asal RAG)
- LoRA: Low-Rank Adaptation of Large Language Models — Hu dkk., 2021
- Hugging Face PEFT docs — dokumentasi resmi LoRA dan QLoRA
- Anthropic Prompt Engineering docs
- Seri Belajar AI: episode #19 (Prompting dan RAG) dan episode #30 (Evals)
Komentar Terbaru