AI/ML
RAG vs Fine-Tuning: Framework Keputusan yang Jujur
April 20269 menit baca
Foto oleh Google DeepMind
RAG mengubah apa yang bisa dilihat model dengan menyuntikkan dokumen relevan ke context window saat request, sementara fine-tuning mengubah bagaimana model berperilaku dengan menyesuaikan bobotnya dari pasangan contoh. Pengetahuan yang disimpan lewat RAG bisa diperbarui dalam hitungan detik, diaudit, dan dihapus; pengetahuan yang terpatri di weights bersifat lossy dan tidak bisa dihapus setelah training.
Pilih RAG setiap kali model perlu menjawab dari dokumen, wiki, atau database yang sering berubah, membutuhkan sitasi, atau harus di-scope per user atau tenant. Karena bobot model beku saat training, pengetahuan apapun yang berubah harian atau mingguan harus tinggal di retrieval — model yang sudah di-fine-tune jadi basi begitu data dasarnya berubah.
Weights adalah tempat yang lossy, tak bisa diaudit, dan tak bisa dihapus untuk menyimpan pengetahuan. Tim yang melakukan fine-tune pada dokumen mereka sering berakhir dengan model yang percaya diri terdengar seperti dokumen tersebut sambil menghalusinasi isinya — lebih buruk dari RAG sejak hari pertama dan makin tidak andal seiring dokumen berkembang.
Post ini merekomendasikan untuk mulai dengan prompt engineering terhadap eval set yang layak, lalu menambahkan RAG saat celah pengetahuan menjadi hambatan, dan fine-tuning paling akhir — hanya saat kegagalan format atau gaya masih bertahan di atas retrieval yang sudah bekerja. Kebanyakan produk benar-benar selesai setelah tahap retrieval.
RAG mengharuskan pemeliharaan pipeline embedding, menjaga index tetap sinkron dengan sumber dokumen, monitoring kualitas retrieval, dan meninjau ulang keputusan chunking — semuanya bisa dikelola dengan engineering biasa. Fine-tuning menambahkan 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 harus mengulang semuanya saat model dasar dideprekasi.
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