Tiap beberapa minggu ada yang bertanya apakah mereka perlu fine-tune model untuk produknya, dan dalam kebanyakan kasus jawaban jujurnya: Anda tidak punya masalah fine-tuning, Anda punya masalah retrieval — atau bahkan tidak ada masalah yang tidak bisa diperbaiki prompt yang lebih baik. Kesalahan sebaliknya juga ada: tim membangun pipeline RAG rumit untuk mengajari model nada bicara, sesuatu yang secara fundamental tidak bisa dilakukan retrieval.
Saya sudah menulis panduan hands-on membangun pipeline RAG produksi di blog ini, jadi tulisan ini sengaja tinggal di level keputusan: apa yang sebenarnya diubah masing-masing teknik, pertanyaan-pertanyaan yang menentukan pilihan, dan di mana jawaban hybrid menjadi benar. Framing-nya opiniatif karena biaya salah pilih itu asimetris dan nyata.
Apa yang Sebenarnya Diubah Masing-Masing Teknik
Model mental paling bersih yang saya tahu: RAG mengubah apa yang bisa dilihat model, fine-tuning mengubah bagaimana model berperilaku. Hampir semua keputusan turun dari satu kalimat itu.
RAG: injeksi pengetahuan saat request
Retrieval mengambil dokumen relevan dan menaruhnya di context window per request. Pengetahuan tinggal di luar model, jadi bisa diperbarui dalam hitungan detik, di-scope per user atau tenant, diaudit, dihapus, dan dikutip. Modelnya sendiri tak tersentuh. Riset contextual retrieval Anthropic menunjukkan seberapa jauh teknik ini bisa di-scale: menambahkan konteks chunk sebelum embedding memangkas kegagalan retrieval 49 persen, dan 67 persen dengan reranking.
Fine-tuning: perilaku terpatri di weights
Fine-tuning menyesuaikan bobot model dari pasangan contoh. Inilah cara mengubah kepatuhan format, nada, jargon domain, dan refleks spesifik tugas — efektifnya lebih banyak contoh daripada yang muat di context window mana pun, menurut framing OpenAI sendiri. Kelemahannya: menyimpan fakta. Weights adalah tempat yang lossy, tak bisa diaudit, dan tak bisa dihapus untuk pengetahuan yang berubah.
Tabel Keputusan
Petakan kebutuhan aktual Anda ke kolom kiri dan jawabannya hampir memilih dirinya sendiri:
| Anda butuh model untuk... | Pilih | Alasannya |
|---|---|---|
| Menjawab dari dokumen, wiki, atau database Anda | RAG | Pengetahuan berubah, butuh sitasi, dan harus di-scope per tenant |
| Selalu menjawab dengan informasi terkini | RAG | Weights beku saat training; retrieval selalu hidup |
| Mengikuti format output ketat atau gaya khas perusahaan | Fine-tuning | Perilaku dan gaya tinggal di weights, bukan di teks yang diambil |
| Menguasai singkatan domain yang membuat model dasar tergagap | Fine-tuning | Interpretasi konsisten butuh contoh training, bukan lookup |
| Memangkas biaya atau latensi satu tugas sempit bervolume tinggi | Fine-tuning | Model kecil yang dituning bisa menggantikan model besar dengan prompt lebih pendek |
| Mematuhi right-to-be-forgotten atau isolasi data per pelanggan | RAG | Anda bisa menghapus dokumen dari index; Anda tidak bisa menghapusnya dari weights |
Empat Pertanyaan Sebelum Memutuskan
Saat tabel saja tidak cukup, empat pertanyaan ini yang menyelesaikan. Saya menjalankan setiap permintaan fitur AI internal melewatinya:
- Apakah kegagalannya datang dari pengetahuan yang hilang atau perilaku yang salah? Tanyakan ke model dengan dokumen relevan ditempel di prompt. Kalau jawabannya bagus, Anda punya masalah retrieval. Kalau masih melantur atau salah format, Anda punya masalah perilaku.
- Seberapa sering informasi dasarnya berubah? Harian atau mingguan berarti RAG, titik. Fine-tune jadi basi begitu daftar harga Anda berubah.
- Apakah Anda benar-benar punya data training? Fine-tune yang berguna butuh ratusan hingga ribuan contoh berkualitas. Kalau Anda harus memproduksinya, proyek pertama Anda adalah eval set dan prompt yang lebih baik, bukan training run.
- Sudahkah Anda menghabiskan opsi prompting? Model frontier dengan few-shot prompt dan konteks yang baik mencakup porsi mengejutkan dari kasus yang dikira butuh tuning. Panduan fine-tuning OpenAI sendiri menyuruh Anda mengoptimalkan prompt terhadap eval dulu — vendor penjual compute training jarang memimpin dengan saran itu.
Mitos termahal: fine-tuning sebagai penyimpan pengetahuan. Tim melakukan fine-tune pada dokumen mereka berharap model jadi mengetahuinya. Hasilnya model yang percaya diri terdengar seperti dokumen sambil menghalusinasi isinya — lebih buruk dari RAG sejak hari pertama dan makin membusuk seiring dokumen berevolusi. Kalau kebutuhan Anda mengandung kata tahu, jawabannya retrieval.
Tagihan Operasional yang Tidak Pernah Disebut
Keputusan ini bukan hanya soal kemampuan — tetapi soal apa yang Anda tanda tangani untuk dioperasikan. Saya mengelola infrastruktur sebagai pekerjaan, jadi bagian inilah yang paling saya timbang.
Apa yang masing-masing jalur bebankan setelah peluncuran:
- RAG: pipeline embedding, index yang harus sinkron dengan sumber, monitoring kualitas retrieval, dan keputusan chunking yang akan Anda tinjau ulang. Semuanya bisa diobservasi dan diperbaiki di produksi dengan engineering biasa, dan bekerja dengan model frontier yang sudah Anda pakai.
- Fine-tuning: kurasi dan versioning dataset, training run yang harus dikelola, eval harness untuk menangkap regresi dan lupa katastrofik, redeploy untuk setiap update pengetahuan atau perilaku, dan mengulang semuanya saat model dasar dideprekasi. Anda juga biasanya menuning model lebih kecil, menukar pergi penalaran frontier.
Saat Jawabannya Keduanya
Sistem produksi terkuat yang pernah saya lihat menggabungkan keduanya dengan pembagian kerja bersih: fine-tune untuk kulit yang konsisten — format output, nada, konvensi domain — dan RAG untuk setiap fakta yang menjadi dasar jawaban. Asisten support adalah kasus klasiknya: dituning agar terdengar seperti tim Anda dan mengikuti format eskalasi Anda, sementara setiap detail produk datang dari entri knowledge base yang diambil dan terkini.
Tetapi hybrid adalah kelulusan, bukan titik awal. Urutkan: prompt engineering dengan eval set yang layak dulu, tambahkan RAG saat pengetahuan jadi celahnya, dan fine-tune paling akhir, hanya saat kegagalan format atau gaya bertahan di atas retrieval yang sudah bekerja. Setiap tahap menurunkan risiko tahap berikutnya, dan kebanyakan produk benar-benar selesai setelah tahap kedua.
Intinya
RAG mengubah apa yang dilihat model; fine-tuning mengubah bagaimana ia berperilaku. Pengetahuan yang berubah, butuh sitasi, atau harus bisa dihapus, tinggal di retrieval. Perilaku yang Anda inginkan setiap saat tinggal di weights — setelah Anda punya data untuk membuktikannya dan eval untuk melindunginya. Mulai dari prompt, tambahkan retrieval saat pengetahuan jadi celah, dan perlakukan fine-tuning sebagai alat khusus sebagaimana adanya, bukan default seperti yang dipasarkan.
Sumber dan bacaan lanjutan