
RAG vs Fine-Tuning: Kapan Pakai Masing-Masing (Dengan Angka Nyata)
Kebanyakan saran rag vs fine tuning melewatkan satu-satunya eksperimen yang mengukur keduanya pada tugas yang sama. Balaguer dkk. dalam arXiv:2401.08406 (dikutip 162 kali) menjalankan set QA pertanian melalui keduanya: fine-tuning membeli lebih dari 6 poin akurasi, dan RAG menumpuk 5 poin lagi di atasnya. Tabel 18 mereka menempatkan GPT-4 di 75% mentah, 81% fine-tuned, 86% fine-tuned dengan retrieval. Jadi kenapa kami tetap menyuruh kebanyakan tim mulai dengan RAG? Karena kesegaran data, sitasi, dan perhitungan biaya di bawah ini menentukan lebih banyak proyek daripada selisih akurasi 1 poin.
Poin-Poin Kunci
- RAG adalah default saat pengetahuan sering berubah atau jawaban harus menyertakan sumber; fine-tuning menang di format konsisten dan latensi.
- Biaya fine-tuning muncul di depan (pelatihan); biaya RAG muncul per query (embedding plus token input tambahan).
- Bukti terpublikasi pada tugas yang sama: fine-tuning menambah 6 poin akurasi, RAG 5 poin lagi di atasnya, dan hybrid mengalahkan keduanya sendirian.
- Jalankan lima cek (kesegaran data, contoh berlabel, latensi, sitasi, skill tim) sebelum menulis kode pelatihan apa pun.
Kapan Sebaiknya Kamu Pakai RAG vs Fine-Tuning? (Verdict Cepat)
Pilih RAG jika pengetahuanmu sering berubah atau jawabanmu harus membawa sitasi. Pilih fine-tuning jika kamu butuh format output konsisten dan latensi rendah, dan kamu punya ratusan contoh berlabel. Pakai keduanya setelah deployment matang. RAG mengedit konteks yang dibaca model; fine-tuning mengedit modelnya sendiri. Kebanyakan tim butuh yang pertama, bukan yang kedua.
Satu kalimat untuk diingat: RAG mengubah apa yang dibaca model; fine-tuning mengubah apa model itu. Pilih berdasarkan mana yang benar-benar dibutuhkan tugasmu.
| Pendekatan | Pakai saat | Lewati saat | Biaya awal | Biaya per query | Gesekan update |
|---|---|---|---|---|---|
| Prompt engineering | Perilaku sudah dekat, pengetahuan generik | Jawaban butuh data privat atau segar | Jam iterasi | Tidak ada di luar token | Edit prompt, deploy ulang |
| RAG | Fakta berubah, sitasi penting, data tetap privat | Butuh latensi di bawah 100ms | Rendah: bangun indeks | Embedding plus token input tambahan | Re-indeks, tanpa retrain |
| Fine-tuning | Format, tone, atau budget latensi tetap; contoh berlabel ada | Pengetahuan bergeser tiap minggu | Sedang-tinggi: persiapan data plus pelatihan | Seringnya tarif token lebih tinggi | Retrain penuh tiap pergeseran |
| Hybrid (keduanya) | Produk matang: kontrol format plus fakta segar | Tahap prototipe, budget belum jelas | Keduanya di atas | Keduanya di atas | Dua sistem untuk dirawat |
Glosarium RAG NVIDIA mendefinisikan sisi retrieval dengan rapi jika kamu mau versi buku teks. Tapi definisi tidak memilih arsitekturmu. Bukti yang memilih, jadi mulailah dari sana.
Apa yang Ditunjukkan Bukti? Satu Tugas, Kedua Pendekatan, Terukur
Satu-satunya perbandingan terukur pada tugas yang sama yang masuk lima besar Google untuk query ini adalah Balaguer dkk. 2024, studi Microsoft Research yang dikutip 162 kali. Tim menjalankan satu tugas QA pertanian melalui pipeline RAG, model fine-tuned, dan hybrid keduanya, lalu meminta GPT-4 menilai jawabannya. Pada setup mereka, fine-tuning sendirian sedikit mengungguli RAG sendirian, dan menumpuk keduanya mengalahkan salah satunya dengan selisih lebih lebar.
Studi kasus pertanian (arXiv:2401.08406)
Studi ini, diajukan Januari 2024 oleh Angels Balaguer dan 15 rekan penulis, bertanya apa yang dibutuhkan untuk memberi petani insight spesifik lokasi. Pipeline mereka mengekstrak informasi dari PDF, menghasilkan pasangan tanya-jawab darinya, dan mengevaluasi Llama2-13B, GPT-3.5, dan GPT-4 dengan dan tanpa retrieval.
Balaguer dkk. melaporkan kenaikan akurasi lebih dari 6 poin persentase dari fine-tuning, kumulatif dengan RAG, yang menambah 5 poin lagi di atasnya. Pipeline hybrid mengalahkan kedua pendekatan sendirian. Tabel 18 mereka menunjukkan urutan untuk GPT-4: 75% tanpa bantuan, 80% dengan RAG, 81% fine-tuned, 86% fine-tuned plus RAG. Perhatikan betapa dekatnya 80% dan 81%; selisih antara RAG sendirian dan fine-tuning sendirian satu poin, sementara hybrid unggul lima poin bersih dari keduanya. Dalam satu eksperimen, model fine-tuned menarik pengetahuan dari geografi lain untuk menjawab pertanyaan spesifik wilayah, mengangkat kemiripan jawaban dari 47% ke 72%.
Bukti ekonomi
Studi terpublikasi Snorkel AI (November 2022) membahas sisi biaya. Pada benchmark klasifikasi hukum 100 kelas (LEDGAR, 80.000 pasal kontrak), model RoBERTa fine-tuned menyamai GPT-3 fine-tuned sambil 1.400× lebih kecil, memakai kurang dari 1% label ground-truth, dan berjalan pada 0,1% dari biaya inference produksi model GPT-3 fine-tuned, kira-kira seperseribu. Total pembangunan: $1.915 dengan pelabelan programatik vs $7.418 untuk anotasi manual plus fine-tuning GPT-3. Satu catatan: itu klasifikasi, bukan QA generatif, jadi perlakukan rasionya sebagai arah saja.
Bacaan kami
Interpretasi kami: setup mereka adalah kasus paling ramah yang pernah fine-tuning dapat, dan tetap hanya menang satu poin. Balaguer dkk. melatih pada korpus PDF tetap dan mengevaluasi terhadap korpus beku yang sama, jadi tidak ada yang dipelajari bobot punya kesempatan menjadi usang di tengah eksperimen. Kebanyakan basis pengetahuan produksi tidak diam seperti itu. Bot support yang menjawab pertanyaan tentang rilis minggu lalu mendapatkan kembali 6 poin itu setiap siklus retrain, sementara indeks yang memberi makan RAG ter-update sore yang sama. Itu sebabnya kami membaca keunggulan akurasi 1 poin sebagai input terlemah untuk keputusan ini, dan kesegaran sebagai yang terkuat. Yang tidak bisa digeneralisasi dari bukti ini: hasil Snorkel adalah benchmark klasifikasi, dan kedua studi tidak menguji kontrol tone atau format, yang tetap menjadi kasus terkuat fine-tuning.
| RAG | Fine-tuning | Hybrid | |
|---|---|---|---|
| Akurasi tugas (Balaguer dkk., diatribusikan) | +5 p.p., kumulatif di atas fine-tuning (bukan standalone atas baseline) | +6 p.p. atas baseline | Terbaik dari ketiganya: GPT-4 di 86%, vs 81% fine-tuned, 80% RAG, 75% dasar |
| Profil biaya (Snorkel plus harga publik) | Per query: embedding plus token konteks | Di depan: $1.915-$7.418 pada kasus terpublikasi; inference di 0,1% dari biaya GPT-3 fine-tuned dengan model kecil | Bayar keduanya |
| Gesekan update | Re-indeks dokumen | Retrain penuh | Keduanya |
| Dukungan sitasi | Native | Tidak ada | Native lewat sisi retrieval |
Fine-tuning adalah jawaban yang benar lebih jarang dari yang tim kira, kebanyakan proyek yang bilang "fine-tune" sebenarnya maksudnya "retrieve."
Bagaimana Cara Kerja RAG, dan Kapan Ia Menang?
RAG (retrieval-augmented generation) menjawab dari dokumen yang kamu kontrol, bukan dari apa pun yang model hafal selama pelatihan. Pertama diusulkan oleh Lewis dkk. tahun 2020, ia menjadi default untuk pekerjaan pengetahuan karena pengetahuannya hidup di luar model: update indeks, dan setiap jawaban berubah besok tanpa retrain.
Pipelinenya empat langkah:
- Ingest. Parse dokumenmu (PDF, wiki, tiket) menjadi korpus.
- Chunk dan embed. Potong menjadi chunk beberapa ratus token dan konversi masing-masing menjadi vektor dengan model embedding.
- Retrieve. Saat query, temukan chunk top-K paling mirip, plus kecocokan keyword untuk string persis seperti SKU dan kode error.
- Augment dan generate. Masukkan chunk itu ke prompt dan biarkan LLM menjawab dengan sumber terlampir.
RAG menang di tiga sumbu: kesegaran (re-indeks alih-alih retrain), sitasi (setiap jawaban menunjuk chunk asalnya), dan kontrol data (data pelanggan tidak pernah masuk run pelatihan). Jika kamu mau walkthrough pembangunan lengkap, begini cara membangun aplikasi RAG langkah demi langkah.
Satu peringatan soal kualitas retrieval: pipeline hanya sebaik campuran embedding dan retrieval-nya. Contextual Retrieval Anthropic mengukur tingkat kegagalan retrieval top-20 sebesar 5,7% pada setup polos, turun ke 2,9% dengan embedding kontekstual plus BM25, dan ke 1,9% setelah reranker ditambahkan. Jika query exact-match terus gagal, hybrid search (BM25 vs vektor) adalah obatnya.
Kapan Fine-Tuning Menang? (Dan Apa Itu PEFT?)
Fine-tuning menang saat masalahnya adalah bagaimana model menjawab, bukan apa yang ia tahu: format output konsisten, tone brand, atau budget latensi ketat tanpa round-trip retrieval. Ia juga tuas untuk ekonomi model kecil. Hasil Snorkel kualitas-GPT-3-di-0,1%-biaya di atas hanya ada karena seseorang men-fine-tune model kecil alih-alih menyajikan model besar.
Full fine-tuning vs PEFT (LoRA / QLoRA)
Full fine-tuning memperbarui setiap bobot dalam model. Mahal, lambat, dan langka di luar lab besar. Hampir semua orang mengirim PEFT (parameter-efficient fine-tuning) sebagai gantinya. LoRA (Hu dkk. 2021) membekukan bobot dasar dan melatih adapter low-rank kecil, biasanya 0,1-1% dari jumlah parameter. QLoRA menambahkan kuantisasi 4-bit di atasnya, jadi model 13B muat di satu GPU konsumen. Satu istilah terkait yang layak diketahui: continuous pretraining, di mana model terus pretraining pada korpus domain mentah (tanpa supervisi) sebelum fine-tuning tersupervisi pada contoh berlabel.
Konfigurasi LoRA minimal, menurut dokumentasi Hugging Face PEFT:
from peft import LoraConfig, get_peft_model
config = LoraConfig(
r=16, # low-rank dimension; 8-64 typical
lora_alpha=32, # scaling factor, commonly 2x r
target_modules=["q_proj", "v_proj"],
lora_dropout=0.05,
bias="none",
task_type="CAUSAL_LM",
)
model = get_peft_model(base_model, config)
model.print_trainable_parameters()
# trainable params: ~13M || all params: 6.7B || trainable%: 0.19Untuk persiapan dataset, jumlah epoch, dan evaluasi, lihat panduan fine-tuning langkah demi langkah kami.
Risikonya nyata: overfitting pada dataset kecil (beberapa ratus contoh bisa menghafal alih-alih belajar), keusangan (bobot membekukan pengetahuanmu pada cutoff pelatihan), dan tanpa atribusi sumber (model fine-tuned tidak bisa menunjukkan bukti asalnya). Jika salah satu dari tiga itu dealbreaker, kamu baru saja menggiring dirimu kembali ke RAG.
RAG vs Fine-Tuning vs Prompt Engineering: Di Mana yang Lain Cocok?
Ketiganya adalah tangga, bukan rival. Prompt engineering mengubah instruksi, RAG mengubah konteks yang dibaca model, dan fine-tuning mengubah bobot. Panduan fine-tuning OpenAI sendiri menempatkan fine-tuning terakhir dalam loop: eval dulu, prompt kedua, pelatihan hanya saat prompting tak lagi cukup. Dua opsi lebih baru melengkapi toolkit ini.
| Pendekatan | Apa yang berubah | Pakai saat | Lewati saat | Profil biaya | Usaha |
|---|---|---|---|---|---|
| Prompt engineering | Instruksi | Perilaku sudah 90% sampai | Butuh fakta privat atau cepat berubah | Token saja | Jam |
| RAG | Konteks yang dibaca saat query | Pengetahuan segar atau bisa disitir | Latensi ketat; tidak ada yang di-retrieve | Token per query plus indeks | Hari |
| Fine-tuning (LoRA) | Bobot | Format, tone, latensi, penyajian model kecil | Tanpa data berlabel; pengetahuan bergeser | Pelatihan di depan; diperbarui tiap retrain | Minggu |
| CAG (cache-augmented) | Konteks yang di-preload dan di-cache | Basis pengetahuan kecil stabil; prompt caching tersedia | Korpus melebihi ukuran yang bisa di-cache | Tulis cache sekali, lalu baca murah | Hari |
| Agen plus penggunaan tool | Apa yang bisa model lakukan | Jawaban butuh aksi live atau komputasi | Jawaban statis sudah cukup | Token per langkah; berlipat cepat | Minggu |
Satu kebingungan yang layak disebut: server MCP dan framework agen adalah orkestrasi, bukan kustomisasi. Mereka memutuskan tool dan sumber mana yang bisa model jangkau; mereka tidak mengubah bagaimana model menjawab. Kamu bisa menjalankan pipeline RAG di dalam agen dan men-fine-tune model di bawahnya, dan banyak sistem produksi melakukan keduanya. Perang autocomplete ("vs mcp", "vs agen") adalah kesalahan kategori.
Apakah RAG Lebih Murah dari Fine-Tuning? Model Biaya Nyata
Jawaban singkat: pada volume query realistis, ya. Tagihan fine-tuning muncul di depan (data berlabel plus pelatihan), sementara tagihan RAG tiba per query (embedding plus token input tambahan). Dokumentasi fine-tuning OpenAI mengenakan biaya pelatihan per token, tapi biaya token itu uang receh dibanding biaya manusia untuk contoh berlabel. Begini perhitungannya pada harga publik.
| Item | Kapan kamu bayar | Harga publik |
|---|---|---|
| Pelatihan API hosted (gpt-4o-mini) | Sekali per versi model | $3,00 per 1M token pelatihan (OpenAI, daftar 2024-25) → 1,5M token ≈ $4,50 |
| Data pelatihan berlabel | Di depan, diperbarui saat bergeser | $1.915 programatik vs $7.418 manual (kasus terpublikasi Snorkel) |
| Inference model fine-tuned | Per query | Kira-kira 2× dasar: $0,30/$1,20 vs $0,15/$0,60 per 1M (gpt-4o-mini, OpenAI 2024-25) |
| Embedding korpus (RAG) | Sekali per update korpus | $0,02 per 1M token (text-embedding-3-small) → korpus 10M token = $0,20 |
| Konteks yang di-retrieve (RAG) | Per query | ~2.000 token input tambahan × $0,15/1M = $0,0003 per query |
Pertanyaan break-even: berapa banyak query sampai pajak per query kumulatif RAG menyamai investasi fine-tuning?
break_even = training_cost / per_query_retrieval_delta
= $1,915 / $0.0003
≈ 6.4 million queriesPada 50.000 query sebulan, itu lebih dari sepuluh tahun. Untuk kebanyakan produk, investasi fine-tuning tidak pernah balik modal lewat penghematan token saja; kamu men-fine-tune untuk format dan latensi, bukan untuk mengalahkan RAG soal biaya. Perhitungannya berbalik setelah melewati jutaan query per bulan atau dengan konteks yang di-retrieve sangat besar. Dan perhatikan asimetrinya: tagihan fine-tuning diperbarui setiap pergeseran data memaksa retrain, sementara RAG berskala linear dengan volume kali ukuran chunk. Jika pengeluaran per query adalah kekhawatiran nyata, mulai dengan memangkas biaya LLM per query dulu; jika kamu tetap menempuh jalur pelatihan, bandingkan tooling fine-tuning sebelum menulis cek.
Satu catatan kesegaran: per Juli 2026, dokumentasi fine-tuning OpenAI menyatakan platform hosted sedang dihentikan untuk pengguna baru, dengan pengguna lama mempertahankan akses pelatihan untuk beberapa bulan ke depan. Itu satu alasan lagi tim condong ke PEFT model terbuka atau RAG polos.
5 Cek Sebelum Kamu Memilih
Jalankan lima cek ya-atau-tidak ini sebelum menulis kode pelatihan apa pun; pola jawaban menunjuk ke RAG, fine-tuning, atau hybrid lebih andal daripada benchmark mana pun. Jawab jujur, lalu hitung.
- Apakah pengetahuan berubah lebih cepat dari kemampuanmu retrain? Ya → RAG. Retrain per update dokumen bukan rencana operasional.
- Apakah kamu punya beberapa ratus contoh berlabel? Tidak → RAG atau prompt engineering. Fine-tuning pada 40 contoh menghafal; tidak belajar.
- Apakah ada budget latensi ketat? Ketat → condong fine-tuning. Melewati round-trip retrieval menghemat 50-200ms.
- Apakah jawaban harus membawa sitasi atau jejak audit? Ya → RAG. Model fine-tuned tidak bisa menunjuk chunk sumber.
- Apakah tim punya skill ML plus budget GPU atau API untuk pelatihan? Tidak → RAG. Indeks yang bisa kamu bangun ulang mengalahkan bobot yang tidak bisa kamu retrain.
Kebanyakan ya pada 1, 4, 5 → RAG. Kebanyakan ya pada 2 dan 3 dengan domain stabil → fine-tuning. Jawaban terbelah, atau produk matang dengan traffic nyata → hybrid (bagian berikutnya). Inti checklist ini adalah memutuskan dengan bukti, bukan dengan teknik mana yang sedang tren di feed-mu bulan ini.
Bisakah Kamu Memakai RAG dan Fine-Tuning Bersama?
Ya, dan untuk deployment matang pola hybrid adalah norma, bukan pengecualian. Fine-tune untuk kefasihan domain dan format output (bagaimana), retrieve untuk fakta saat inference (apa). Balaguer dkk. melaporkan persis ini pada tugas pertanian mereka: pipeline hybrid mengalahkan kedua pendekatan sendirian, dengan kenaikan 5 poin RAG menumpuk di atas 6 poin fine-tuning.
Jalur kematangan yang kami rekomendasikan: mulai dengan prompt engineering, tambahkan RAG saat jawaban butuh data privat atau segar, dan tambahkan fine-tuning hanya setelah inkonsistensi format atau latensi mulai menyakitkan di produksi. Langsung lompat ke fine-tuning dan kamu membayar pajak pelatihan sebelum tahu apakah retrieval sudah menyelesaikan masalah.
Pola hybrid bukan kompromi; untuk deployment matang ia adalah default, fine-tune untuk format, retrieve untuk fakta.
Bagaimana Kamu Mengevaluasi Pemenangmu?
Pilih pemenang seperti kamu memilih database: ukur pada workload-mu, bukan pada firasat. Resepnya muat dalam satu paragraf dan mencakup empat angka yang benar-benar menentukan.
- Set pertanyaan held-out. 100-300 pertanyaan pengguna nyata. Bukan sintetis, jangan pernah apa pun yang terlihat selama pelatihan atau pengindeksan.
- Faithfulness dan kebenaran jawaban. Faithfulness bertanya apakah jawaban berdasar pada konteks yang di-retrieve; kebenaran jawaban bertanya apakah ia benar-benar tepat. Pasangan ini, dipopulerkan oleh RAGAS, menangkap halusinasi dan miss retrieval sekaligus.
- Latensi pada p95, bukan rata-rata. Retrieval menambah round-trip; ukur ekornya.
- Biaya per 1.000 query, token plus infrastruktur, diukur bukan ditebak.
- Jalankan ulang saat bergeser. Dokumen baru, snapshot model baru, kuartal baru: jalankan ulang setnya.
Rincian metrik lengkap, termasuk tooling, ada di panduan evaluasi LLM kami.
Tentang Penulis
Mert Batur adalah Co-Founder Techsy.io, tempat tim mengirim agen AI, sistem otomasi, dan pipeline voice/SDR untuk klien B2B. Ia menulis tentang stack tooling LLM yang tim Techsy benar-benar pakai di produksi. Terhubung di LinkedIn.
Pertanyaan yang Sering Diajukan
Bisakah kamu memakai RAG dan fine-tuning bersama?
Ya. Fine-tune untuk format output dan kefasihan domain, dan pertahankan retrieval untuk fakta saat inference. Balaguer dkk. mengukur hybrid ini pada tugas QA pertanian dan menemukan ia mengalahkan kedua pendekatan sendirian, dengan kenaikan akurasi menumpuk. Kebanyakan sistem produksi matang berakhir di sini: bobot untuk bagaimana, retrieval untuk apa.
Kapan tidak memakai fine-tuning?
Lewati fine-tuning saat pengetahuanmu berubah lebih cepat dari kemampuanmu retrain, saat kamu punya kurang dari beberapa ratus contoh berlabel, saat jawaban harus membawa sitasi atau jejak audit, atau saat tidak ada budget untuk retrain seiring data bergeser. Empat kondisi itu menggambarkan kebanyakan produk tahap awal, itulah kenapa RAG biasanya langkah pertama yang tepat.
Apakah fine-tuning sudah terbantahkan?
Tidak, tapi wilayahnya menyusut. Jendela konteks panjang dan RAG murah menyerap kasus penggunaan yang menuntut fine-tuning pada 2023. Yang tersisa itu nyata: format output ketat, tone brand, budget latensi tanpa round-trip retrieval, dan ekonomi model kecil. Jika masalahmu adalah bagaimana model menjawab, bukan apa yang ia tahu, fine-tuning tetap toolnya.
Kapan kamu memakai RAG vs fine-tuning?
Pakai RAG saat jawaban bergantung pada pengetahuan privat atau sering diperbarui, atau saat kamu butuh sitasi. Pakai fine-tuning saat kamu butuh format, tone, atau latensi konsisten dan kamu punya cukup contoh berlabel. Pakai keduanya setelah produk matang. Jika ragu, mulai dengan RAG: lebih murah dibatalkan daripada run pelatihan.
Apakah RAG lebih murah dari fine-tuning?
Di depan, ya. Biaya RAG per query (embedding plus token input tambahan), sementara fine-tuning mengenakan biaya sekali untuk pelatihan dan data berlabel, lalu diperbarui setiap retrain. Pada harga publik, break-even mendarat sekitar 6,4 juta query dalam contoh perhitungan kami, jadi pada volume tipikal RAG tetap lebih murah sepanjang umur produk.
Apakah RAG lebih baik dari fine-tuning untuk halusinasi?
Biasanya, tapi tidak gratis. RAG mendasarkan jawaban pada chunk yang di-retrieve, jadi kamu bisa menyitir sumber dan mengaudit kegagalan. Tapi retrieval buruk meracuni jawaban: Anthropic mengukur tingkat kegagalan retrieval top-20 sebesar 5,7% pada setup polos, dipotong ke 1,9% dengan contextual retrieval plus reranking. Fine-tuning, sementara itu, bisa menanamkan error ke dalam bobot tanpa cara melacaknya.
RAG vs fine-tuning vs prompt engineering: apa bedanya?
Prompt engineering mengubah instruksi yang kamu kirim. RAG mengubah konteks yang dibaca model saat query. Fine-tuning mengubah bobot model. Masing-masing intervensi lebih besar dari sebelumnya: coba prompt dulu, tambahkan retrieval saat pengetahuan jadi hambatan, dan latih hanya saat format, tone, atau latensi masih menyakitkan.
Bagaimana kamu mengevaluasi performa RAG vs fine-tuning?
Bangun set held-out 100-300 pertanyaan pengguna nyata dan skor kedua pendekatan padanya: faithfulness (apakah berdasar?), kebenaran jawaban (apakah tepat?), latensi p95, dan biaya per 1.000 query. Jalankan ulang setnya setiap kali dokumen atau snapshot model-mu berubah. Pertanyaan sintetis menyanjung kedua sistem; yang nyata memisahkan mereka.
Fine-tuning vs RAG untuk pertanyaan multi-hop pada pengetahuan baru?
RAG, dengan retrieval lebih baik. Mekanismenya menentukan yang satu ini: model fine-tuned hanya bisa bernalar atas apa yang bobotnya serap, jadi pengetahuan yang tidak pernah ia lihat tak terjangkau sebaik apa pun ia dilatih. Retrieval menyerahkan potongan yang hilang saat query. Tangkapannya, satu lintasan retrieval jarang mengumpulkan setiap hop, jadi rencanakan dekomposisi query atau retrieval iteratif plus reranker, bukan pencarian top-K tunggal.
Kesimpulan
Rekapnya, tanpa basa-basi:
- RAG adalah default untuk pengetahuan yang berubah dan jawaban bersitir. Fine-tuning adalah spesialis untuk format, tone, dan latensi.
- Bukti tugas yang sama (Balaguer dkk.) memberi fine-tuning +6 p.p. dan RAG +5 p.p. lagi di atasnya, dengan hybrid terbaik dari ketiganya. Saran mulai-dengan-RAG kami bertumpu pada kesegaran, sitasi, dan biaya, bukan pada papan skor itu.
- Perhitungan biaya memihak RAG pada volume realistis: break-even duduk sekitar 6,4 juta query dalam contoh perhitungan kami.
- Putuskan dengan lima cek, bukan dengan kebiasaan.
Pilih RAG? Lihat daftar tooling RAG peringkat kami untuk stack di sekitar pipeline.