AI/ML
RAG vs Fine-Tuning: Framework Keputusan yang Jujur
April 20269 menit baca
Foto oleh Google DeepMind
Foto oleh Google DeepMind
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.
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.
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 |
Saat tabel saja tidak cukup, empat pertanyaan ini yang menyelesaikan. Saya menjalankan setiap permintaan fitur AI internal melewatinya:
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.
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:
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.
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