Fine-Tuning vs Prompt Engineering: Kapan Harus Melatih Ulang Model?

Salah satu pertanyaan paling sering muncul saat tim mulai membangun produk berbasis LLM adalah: "apakah kita perlu fine-tuning, atau cukup dengan prompt yang lebih baik?" Pertanyaan ini penting karena jawabannya berdampak langsung pada biaya, waktu pengembangan, dan kompleksitas infrastruktur. Fine-tuning sering dianggap sebagai "solusi ultimate" yang bisa menyelesaikan semua masalah kualitas output model, padahal pada banyak kasus, teknik prompt engineering yang lebih baik — atau bahkan RAG — jauh lebih murah dan efektif. Artikel ini membedah kedua pendekatan secara mendalam, lengkap dengan kapan masing-masing layak dipakai, dan kapan justru harus dihindari.

Prompt Engineering: Definisi dan Teknik

Prompt engineering adalah proses merancang instruksi input ke LLM sedemikian rupa sehingga model menghasilkan output yang diinginkan, tanpa mengubah bobot model sama sekali. Ini adalah pendekatan paling murah dan cepat untuk mengarahkan perilaku model karena tidak butuh data training, GPU, atau proses training sama sekali — cukup mengubah teks yang dikirim ke API.

Zero-shot, Few-shot, dan Chain-of-Thought

• Zero-shot prompting — meminta model langsung menjalankan tugas tanpa contoh sama sekali, hanya mengandalkan instruksi natural language.
• Few-shot prompting — menyertakan beberapa contoh input-output di dalam prompt sebagai referensi pola yang diinginkan. Teknik ini sangat efektif untuk format output yang konsisten (misalnya ekstraksi data terstruktur).
• Chain-of-Thought (CoT) — memperkenalkan instruksi seperti "berpikir langkah demi langkah" sebelum menjawab. Teknik ini, dipopulerkan dalam paper Wei et al. (2022), terbukti signifikan meningkatkan akurasi pada tugas reasoning matematis dan logika kompleks karena model "diberi ruang" untuk menalar sebelum menyimpulkan jawaban akhir.
• ReAct (Reasoning + Acting) — kombinasi reasoning bertahap dengan pemanggilan tool/API di tengah proses berpikir, dasar dari banyak sistem AI agent modern.

System Prompt Design

System prompt menetapkan "kepribadian" dan batasan model — nada bicara, format output, batasan topik, hingga aturan keamanan. Praktik baik meliputi: menetapkan peran secara eksplisit, memberi contoh format output (misalnya skema JSON), menyertakan aturan negatif ("jangan menjawab di luar konteks yang diberikan"), dan menempatkan instruksi paling penting di awal maupun akhir prompt karena model cenderung memberi bobot perhatian lebih besar pada bagian tersebut.

Contoh sederhana prompt terstruktur untuk ekstraksi data:

System: Kamu adalah asisten ekstraksi data. Selalu balas dalam format JSON valid.
Jangan menambahkan penjelasan di luar JSON.

Format:
{
  "nama": string,
  "tanggal": string (YYYY-MM-DD),
  "jumlah": number
}

User: Invoice dari PT Sumber Makmur tanggal 5 Agustus 2026
sebesar Rp 1.500.000 untuk pembelian laptop.

Assistant:
{
  "nama": "PT Sumber Makmur",
  "tanggal": "2026-08-05",
  "jumlah": 1500000
}

Fine-Tuning: Definisi dan Jenis

Fine-tuning adalah proses melatih ulang sebagian atau seluruh bobot model menggunakan dataset khusus, sehingga perilaku model berubah secara permanen — bukan hanya untuk satu sesi percakapan, tapi tertanam di dalam parameter model itu sendiri.

Full Fine-Tuning

Semua parameter model diperbarui selama training. Pendekatan ini paling powerful tapi juga paling mahal — untuk model berskala miliaran parameter, ini butuh GPU dengan VRAM sangat besar dan biaya komputasi signifikan. Full fine-tuning juga berisiko catastrophic forgetting, di mana model kehilangan sebagian kemampuan umumnya karena terlalu fokus pada dataset baru yang sempit.

Parameter-Efficient Fine-Tuning (PEFT)

Untuk mengatasi biaya full fine-tuning, muncul teknik PEFT yang hanya melatih sebagian kecil parameter tambahan, sementara bobot asli model dibekukan (frozen):

• LoRA (Low-Rank Adaptation), diperkenalkan oleh Hu et al. (2021), menyisipkan matriks berdimensi rendah yang bisa dilatih di lapisan attention model, sementara bobot asli tetap beku. Hasilnya: jumlah parameter yang dilatih bisa 100-1000x lebih sedikit dibanding full fine-tuning, dengan performa yang mendekati.
• QLoRA (Dettmers et al., 2023) menggabungkan LoRA dengan kuantisasi 4-bit pada model dasar, memungkinkan fine-tuning model besar (misalnya 65 miliar parameter) di satu GPU konsumen kelas atas.
• Prefix Tuning / Prompt Tuning — melatih vector "prefix" yang disisipkan ke input, tanpa mengubah bobot model sama sekali.
• Adapter layers — menyisipkan modul kecil di antara layer transformer yang dilatih secara terpisah.

Instruction Tuning dan RLHF

Selain fine-tuning untuk tugas spesifik, ada juga fine-tuning tahap lanjut yang dilakukan oleh penyedia model dasar: instruction tuning (melatih model mengikuti instruksi natural language secara umum) dan RLHF — Reinforcement Learning from Human Feedback (dipopulerkan lewat paper InstructGPT dari OpenAI, Ouyang et al. 2022), di mana model dilatih lebih lanjut berdasarkan preferensi manusia terhadap kualitas jawaban. Sebagian besar tim produk tidak perlu melakukan RLHF sendiri — ini biasanya sudah dilakukan penyedia model, dan yang dilakukan tim aplikasi adalah fine-tuning tahap akhir dengan PEFT di atas model yang sudah di-instruction-tune.

Kapan Prompt Engineering Sudah Cukup?

• Tugas bisa dijelaskan dengan jelas dalam instruksi natural language.
• Format output bisa dikontrol dengan few-shot examples.
• Kebutuhan berubah-ubah dengan cepat (misalnya masih tahap eksperimen produk) sehingga iterasi cepat lebih penting daripada optimasi maksimal.
• Anggaran dan waktu terbatas — prompt engineering bisa diuji dalam hitungan menit, bukan jam atau hari.
• Pengetahuan yang dibutuhkan model bersifat dinamis — di sini kombinasi prompt engineering dengan RAG jauh lebih tepat daripada fine-tuning berulang.

Kapan Fine-Tuning Benar-Benar Dibutuhkan?

• Konsistensi gaya/format dalam skala besar yang sulit dicapai hanya dengan few-shot, misalnya model harus selalu menulis dalam gaya brand tertentu di ribuan variasi kasus.
• Domain sangat spesifik dengan terminologi khusus, misalnya istilah medis, hukum, atau kode internal perusahaan yang jarang muncul di data pretraining model.
• Mengurangi panjang prompt di produksi. Jika Anda harus menyertakan puluhan contoh few-shot di setiap request agar output konsisten, biaya token membengkak. Fine-tuning "menanamkan" pola itu ke model sehingga prompt bisa jauh lebih pendek.
• Mengubah perilaku dasar model yang tidak bisa diatasi lewat instruksi, misalnya menekan kecenderungan tertentu yang sudah "mengakar" dari pretraining.
• Latency dan biaya inferensi — model yang di-fine-tune untuk tugas sempit kadang bisa memakai model dasar yang lebih kecil dan lebih murah dibanding harus memakai model besar generik dengan prompt panjang.

Perbandingan Biaya, Waktu, dan Kompleksitas

RAG sebagai Alternatif (atau Pelengkap) Ketiga

Penting dipahami bahwa prompt engineering dan fine-tuning bukan satu-satunya dua pilihan. Ketika masalah utama adalah "model tidak tahu fakta tertentu" — bukan "model tidak tahu cara menjawab dengan gaya tertentu" — jawabannya sering kali bukan fine-tuning, melainkan Retrieval-Augmented Generation (RAG). RAG menyuntikkan pengetahuan faktual lewat konteks yang di-retrieve dari basis data eksternal, sehingga informasi bisa diperbarui kapan saja tanpa training ulang. Di praktik nyata, kombinasi paling umum adalah: prompt engineering untuk instruksi dasar, RAG untuk pengetahuan faktual dinamis, dan fine-tuning (biasanya LoRA) hanya diterapkan jika masih ada gap kualitas setelah dua pendekatan lain dicoba maksimal. Pembahasan detail arsitektur RAG ada di artikel kami "Retrieval-Augmented Generation (RAG): Cara Kerja dan Implementasinya".

Contoh Kasus Nyata: Fine-Tuning dengan LoRA

Berikut ilustrasi sederhana alur fine-tuning model menggunakan pendekatan LoRA dengan library Hugging Face peft:

from peft import LoraConfig, get_peft_model
from transformers import AutoModelForCausalLM, AutoTokenizer, Trainer

base_model = AutoModelForCausalLM.from_pretrained("model-dasar")
tokenizer = AutoTokenizer.from_pretrained("model-dasar")

lora_config = LoraConfig(
    r=16,               # rank matriks low-rank
    lora_alpha=32,
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    task_type="CAUSAL_LM"
)

model = get_peft_model(base_model, lora_config)
print(model.print_trainable_parameters())
# contoh output: trainable params: 4,194,304 || all params: 7,000,000,000
# hanya ~0.06% parameter yang benar-benar dilatih

trainer = Trainer(
    model=model,
    train_dataset=dataset_customer_service,
    args=training_args
)
trainer.train()

Perhatikan bahwa dengan LoRA, hanya sebagian kecil parameter (dalam contoh ini sekitar 0.06%) yang benar-benar diperbarui, sementara bobot model dasar tetap beku. Ini yang membuat LoRA jauh lebih murah dan cepat dibanding full fine-tuning, sekaligus mengurangi risiko catastrophic forgetting karena kemampuan umum model tetap terjaga di bobot aslinya.

Prompt Chaining dan Meta-Prompting sebagai Jalan Tengah

Sebelum melompat ke fine-tuning, ada satu tingkat teknik prompt engineering lanjutan yang sering terlewat: memecah satu prompt kompleks menjadi rangkaian prompt yang lebih kecil dan spesifik (prompt chaining), di mana output satu langkah menjadi input langkah berikutnya. Alih-alih meminta model melakukan ekstraksi, validasi, dan ringkasan sekaligus dalam satu prompt raksasa yang rawan error, setiap sub-tugas dipisah menjadi pemanggilan tersendiri dengan instruksi yang jauh lebih fokus. Pendekatan ini sering meningkatkan akurasi secara signifikan tanpa perlu training sama sekali, meski dengan konsekuensi latency dan biaya token yang lebih tinggi karena beberapa kali pemanggilan API.

Meta-prompting — teknik di mana satu LLM dipakai untuk menyusun atau mengoptimalkan prompt yang akan dipakai LLM lain (atau dirinya sendiri) — juga semakin populer sebagai cara mengotomatisasi proses trial-and-error yang biasanya dilakukan manual oleh prompt engineer. Beberapa tim bahkan membangun pipeline evaluasi otomatis yang mencoba puluhan variasi prompt terhadap dataset uji, lalu memilih versi dengan skor terbaik — pendekatan yang jauh lebih murah dibanding fine-tuning tapi tetap sistematis, bukan coba-coba manual semata.

DPO: Alternatif RLHF yang Lebih Sederhana

Selain PEFT untuk efisiensi parameter, ada juga perkembangan penting di sisi metodologi training preferensi. RLHF, meski efektif, punya kompleksitas implementasi yang tinggi karena butuh melatih reward model terpisah lalu menjalankan reinforcement learning (biasanya dengan algoritma PPO) yang terkenal tidak stabil dan sulit di-tuning. Direct Preference Optimization (DPO), diperkenalkan Rafailov et al. (2023), menawarkan pendekatan matematis yang menunjukkan bahwa tujuan optimasi RLHF sebenarnya bisa dicapai secara langsung lewat loss function berbasis data preferensi (pasangan jawaban "lebih disukai" vs "kurang disukai"), tanpa perlu reward model terpisah maupun loop reinforcement learning yang rumit. Ini membuat proses alignment model jauh lebih sederhana untuk diimplementasikan tim yang tidak punya sumber daya riset RL yang mendalam, dan menjadi salah satu alasan semakin banyak model open-source menggunakan DPO sebagai tahap fine-tuning preferensi mereka.

Continual Learning: Masalah "Model Jadi Usang"

Satu tantangan yang jarang dibahas di awal proyek adalah: baik prompt engineering maupun fine-tuning sama-sama menghadapi masalah pengetahuan yang menjadi usang seiring waktu. Prompt engineering tidak benar-benar punya masalah ini karena tidak menyimpan fakta di dalam model — tapi fine-tuning punya risiko nyata: setiap kali model dasar di-upgrade oleh vendor, atau setiap kali domain pengetahuan berubah signifikan, model yang sudah di-fine-tune berpotensi perlu dilatih ulang dari awal. Ini yang disebut sebagai masalah continual learning — bagaimana memperbarui pengetahuan model secara inkremental tanpa harus training ulang penuh dan tanpa menyebabkan catastrophic forgetting terhadap kemampuan yang sudah dipelajari sebelumnya. Riset di area ini masih aktif berkembang, dan sampai ada solusi yang benar-benar matang, kombinasi RAG untuk pengetahuan dinamis plus fine-tuning ringan untuk perilaku/gaya yang relatif stabil tetap menjadi pendekatan paling praktis di industri.

Studi Kasus: Menggabungkan Ketiga Pendekatan

Sebuah perusahaan fintech membangun asisten AI untuk tim customer support dengan kebutuhan: (1) menjawab pertanyaan tentang produk dan kebijakan terbaru yang sering berubah, (2) selalu menjawab dalam format dan nada bicara yang konsisten dengan brand, dan (3) memahami istilah teknis finansial internal yang spesifik. Solusi akhirnya menggabungkan tiga lapis: prompt engineering dengan system prompt yang detail dan few-shot examples untuk menjaga nada bicara, RAG yang menarik data kebijakan dan FAQ terbaru dari basis pengetahuan internal, dan fine-tuning ringan berbasis LoRA yang dilatih dari ribuan transkrip percakapan customer support terbaik untuk mengajarkan model pola respons dan istilah domain finansial yang tidak lazim ditemukan di data pretraining umum. Hasilnya: model tetap bisa menjawab pertanyaan dengan info terbaru (berkat RAG), konsisten dari sisi gaya (berkat fine-tuning ringan), dan seluruh sistem tetap fleksibel untuk di-iterasi cepat (berkat lapisan prompt engineering di atasnya). Studi kasus ini menggambarkan bahwa pertanyaan "fine-tuning vs prompt engineering" di dunia nyata sering kali bukan pilihan biner, melainkan soal komposisi yang tepat.

Menyiapkan Dataset Fine-Tuning yang Berkualitas

Terlepas dari teknik fine-tuning yang dipilih, kualitas hasil akhir sangat bergantung pada kualitas dataset training, sesuatu yang sering diremehkan tim yang baru mulai. Beberapa prinsip penting dalam menyiapkan dataset:

• Konsistensi format. Setiap contoh dalam dataset harus mengikuti format instruksi-respons yang sama persis dengan yang akan dipakai saat inferensi, termasuk template system prompt jika ada.
• Diversitas kasus. Dataset yang hanya berisi variasi sempit dari satu jenis pertanyaan akan membuat model overfit dan gagal menggeneralisasi ke variasi pertanyaan yang sedikit berbeda saat produksi.
• Kualitas di atas kuantitas. Riset menunjukkan berulang kali bahwa beberapa ratus contoh berkualitas tinggi yang dikurasi dengan hati-hati sering menghasilkan model lebih baik dibanding puluhan ribu contoh yang dikumpulkan asal-asalan dengan banyak noise atau label yang tidak konsisten.
• Data holdout untuk evaluasi. Selalu sisihkan sebagian data yang tidak pernah dilihat model selama training, khusus untuk mengukur performa secara objektif dan mendeteksi overfitting sebelum model di-deploy.
• Hindari kebocoran data (data leakage). Pastikan tidak ada contoh yang secara tidak sengaja duplikat atau sangat mirip antara set training dan set evaluasi, karena ini akan membuat metrik evaluasi terlihat bagus secara palsu padahal model sebenarnya tidak menggeneralisasi dengan baik ke data baru.

Banyak tim juga memanfaatkan LLM lain sebagai alat bantu menghasilkan dataset sintetis awal (misalnya meminta model besar menghasilkan variasi pertanyaan dari beberapa contoh seed), lalu dikurasi dan diverifikasi manusia sebelum dipakai untuk training — pendekatan yang mempercepat proses pengumpulan data tanpa mengorbankan kontrol kualitas sepenuhnya.

Kesalahan Umum

• Langsung lompat ke fine-tuning tanpa mencoba memaksimalkan prompt engineering dan few-shot examples terlebih dulu — sering kali masalah bisa diselesaikan dengan prompt yang lebih baik, jauh lebih murah dan cepat.
• Fine-tuning untuk menambah pengetahuan faktual yang sering berubah — ini adalah kasus klasik salah pilih tool; seharusnya pakai RAG.
• Dataset fine-tuning terlalu kecil atau tidak representatif, menyebabkan model overfit ke pola sempit dan performanya justru turun di luar dataset training.
• Tidak melakukan evaluasi A/B antara versi sebelum dan sesudah fine-tuning secara sistematis, sehingga sulit membuktikan apakah fine-tuning benar-benar memberi peningkatan yang sepadan dengan biayanya.
• Mengabaikan biaya maintenance — model yang di-fine-tune perlu di-retrain ulang setiap kali model dasar di-upgrade, sesuatu yang tidak terjadi pada pendekatan prompt engineering murni.

Kesimpulan

Tidak ada jawaban universal antara fine-tuning dan prompt engineering — keduanya menyelesaikan masalah yang berbeda. Prompt engineering adalah titik awal yang wajib dimaksimalkan lebih dulu karena murah, cepat, dan reversibel. Fine-tuning, khususnya dengan pendekatan efisien seperti LoRA atau QLoRA, layak dipertimbangkan ketika Anda butuh konsistensi gaya/format dalam skala besar, domain sangat spesifik, atau ingin memangkas biaya token dari prompt yang terlalu panjang. Dan jika masalah utamanya adalah model tidak tahu fakta terbaru atau data privat organisasi, jawabannya hampir selalu RAG, bukan fine-tuning. Rekomendasi praktis: mulai dari prompt engineering, tambahkan RAG jika butuh pengetahuan eksternal, dan baru pertimbangkan fine-tuning sebagai langkah terakhir setelah dua pendekatan lain benar-benar dioptimalkan dan masih ada gap kualitas yang signifikan.