Fine-tune atau retrieval: keputusannya soal apa yang berubah, bukan soal apa yang Anda suka

Dua mekanisme yang saling tertukar

Fine-tuning mengubah weight. Retrieval mengubah prompt. Keduanya sering dibicarakan sebagai teknik pesaing untuk pekerjaan yang sama, sebabnya banyak tim memilih salah satu berdasar insting lalu menghabiskan satu kuartal untuk menemukan mengapa tidak cocok.

Mereka menyelesaikan masalah berbeda. Fine-tuning jago pada bentuk: nada, format output, kepatuhan tugas, idiom domain. Retrieval jago pada isi: fakta spesifik, dokumen yang belum ada saat pelatihan, apa pun yang perlu Anda sitir.

Aturan keputusannya

Mulai dari dua pertanyaan. Pertama: seberapa sering pengetahuan ini berubah? Apa pun yang siklusnya lebih pendek dari siklus retraining Anda masuk ke retrieval, karena model yang di-fine-tune menjadi basi secara senyap dan Anda tak akan sadar sampai pengguna yang sadar. Kedua: apakah Anda perlu menunjukkan dari mana jawaban berasal? Kalau ya, retrieval bukan opsional — update weight tak bisa menghasilkan sitasi.

Hanya setelah kedua pertanyaan terjawab baik, pertimbangkan fine-tuning. Kasisnya sempit tapi nyata: Anda butuh perilaku atau format stabil yang tak bisa dihasilkan prompt secara andal, pada budget token atau latensi yang justru dibuat lebih buruk oleh retrieval.

Mode kegagalan masing-masing

Fine-tuning gagal dengan tenang. Model jadi fasih dalam kosakata domain Anda sementara tetap salah dengan percaya diri soal fakta terkini, dan karena terdengar benar, tak ada yang memeriksa. Ia juga menciptakan kewajiban pemeliharaan: setiap upgrade base model berarti mengulang pelatihan dan evaluasi.

Retrieval gagal dengan kentara, dan itu fitur. Retrieval buruk menghasilkan konteks yang jelas tidak relevan, dan bisa Anda ukur. Biayanya: Anda kini memiliki sebuah pipeline — parsing, chunking, embedding, kesegaran indeks, filter permission. Sebagian besar masalah kualitas di sistem RAG ada di pipeline itu, bukan di modelnya.

Apa yang biasanya berhasil

Retrieval dulu, untuk hampir semua hal, karena terukur dan bisa dibalik. Barulah fine-tune secara sempit untuk bentuk, setelah ada trace yang menunjukkan celah perilaku konsisten yang tak bisa ditutup prompt dan contoh few-shot. Urutan ini membuat Anda punya set evaluasi sebelum membutuhkannya — sesuatu yang justru absen saat kebanyakan tim mulai.