← Blog · Comparison · 9 min read
Tiga teknik, satu kebingungan abadi. Framework ini menjernihkan kapan Anda butuh fine-tuning, kapan cukup RAG, dan kapan prompt engineering sudah memadai.
A 30-minute scoping call. We listen, ask three questions, tell you if we can help.
Book a callPertanyaan ini muncul di hampir setiap rapat perencanaan produk AI: "Untuk masalah ini, kita perlu fine-tuning model, pakai RAG, atau cukup perbaiki prompt-nya?" Dan hampir selalu, jawaban yang beredar didorong oleh apa yang sedang tren, bukan oleh sifat masalahnya. Setahun lalu semua orang ingin fine-tuning; sekarang RAG jadi jawaban refleks untuk segala hal. Keduanya keliru bila diterapkan tanpa diagnosis.
Ketiga teknik ini menjawab kebutuhan yang berbeda, dengan trade-off biaya, akurasi, latensi, dan pemeliharaan yang berbeda. Memilih yang salah berarti membayar mahal untuk hasil yang biasa-biasa saja, atau berkutat memperbaiki masalah yang sebenarnya milik teknik lain. Artikel ini memberi framework keputusan yang jernih, plus contoh konkret dari konteks Indonesia, agar Anda berhenti menebak dan mulai memilih dengan dasar.
Sebelum memilih, pahami persis apa yang setiap teknik ubah.
Prompt engineering mengubah *instruksi* yang Anda berikan ke model. Anda tidak menyentuh pengetahuan atau bobot model; Anda mengarahkan perilakunya lewat kata-kata, contoh, dan struktur. Ini cara termurah dan tercepat untuk memengaruhi output.
RAG (Retrieval-Augmented Generation) mengubah *informasi* yang tersedia bagi model saat menjawab. Anda mengambil dokumen relevan dari knowledge base dan menyuntikkannya ke konteks, sehingga model menjawab berdasarkan fakta terkini dan spesifik — bukan dari ingatan pelatihannya yang umum dan mungkin usang.
Fine-tuning mengubah *bobot model* itu sendiri dengan melatihnya pada contoh-contoh Anda. Ini menggeser perilaku dan gaya bawaan model, mengajarinya pola, format, atau nada yang konsisten — tetapi tidak menambahkan pengetahuan faktual yang dapat diandalkan dengan cara yang sama seperti RAG.
Kunci pemahaman: RAG untuk pengetahuan, fine-tuning untuk perilaku, prompt untuk pengarahan. Banyak kesalahan berakar dari mencampuradukkan ketiganya.
Apa pun masalahnya, mulai dari sini. Bukan karena prompt selalu cukup, tetapi karena ia termurah untuk dicoba dan sering kali menyelesaikan lebih banyak masalah daripada yang diduga. Sebelum berinvestasi dalam infrastruktur RAG atau biaya fine-tuning, buktikan dulu bahwa masalah Anda tidak bisa diselesaikan dengan instruksi yang lebih baik.
Prompt engineering biasanya cukup ketika:
Tugasnya dapat dijelaskan dengan jelas dalam instruksi, dan model sudah punya kemampuan dasarnya.
Anda butuh format output tertentu — bisa dicapai dengan instruksi struktur dan contoh few-shot.
Pengetahuan yang dibutuhkan bersifat umum dan ada dalam pelatihan model, atau cukup kecil untuk dimuat langsung ke prompt.
Teknik seperti few-shot examples, instruksi peran yang jelas, dekomposisi tugas, dan permintaan output terstruktur sering kali mengangkat kualitas secara dramatis tanpa biaya tambahan apa pun. Banyak tim Indonesia melompat ke fine-tuning untuk masalah yang sebenarnya tuntas dengan tiga contoh yang baik dalam prompt.
Jika Anda belum mengeksploitasi habis prompt engineering, Anda belum punya hak menyimpulkan bahwa Anda butuh RAG atau fine-tuning.
RAG menjadi jawaban ketika masalah inti adalah pengetahuan: model perlu menjawab berdasarkan informasi yang spesifik, terkini, atau privat yang tidak ada dalam pelatihannya.
Tanda-tanda Anda butuh RAG:
Jawaban harus berakar pada dokumen internal — kebijakan perusahaan, katalog produk, SOP, kontrak, basis pengetahuan dukungan.
Informasi sering berubah. Harga, regulasi terbaru, ketersediaan stok. Anda tidak mungkin melatih ulang model setiap kali sebuah angka berubah, tetapi Anda bisa memperbarui knowledge base.
Anda butuh citation dan keterlacakan — jawaban harus bisa ditelusuri ke sumbernya, krusial di sektor yang diatur OJK atau untuk kepatuhan internal.
Mengurangi halusinasi dengan menambatkan jawaban pada fakta nyata adalah prioritas.
Contoh konkret Indonesia: sebuah bank ingin asisten internal yang menjawab pertanyaan staf cabang tentang syarat produk kredit terbaru. Syarat ini berubah tiap kuartal dan harus akurat secara hukum. Fine-tuning akan usang dalam hitungan minggu dan tidak bisa menunjukkan sumber. RAG adalah jawaban yang jelas — perbarui dokumen, sistem ikut terbarui, dan setiap jawaban menyertakan rujukan ke Surat Edaran yang relevan.
Fine-tuning sering menjadi solusi yang dicari karena terdengar canggih, padahal ia paling jarang menjadi jawaban yang tepat untuk masalah pengetahuan. Ia bersinar ketika masalahnya adalah perilaku, gaya, atau format yang konsisten yang sulit dicapai lewat prompt — terutama dalam skala.
Pertimbangkan fine-tuning ketika:
Anda butuh gaya atau format keluaran yang sangat konsisten yang sulit dijaga lewat instruksi, dan Anda punya banyak contoh berkualitas tinggi. Misalnya, menghasilkan ringkasan dengan struktur dan nada baku perusahaan secara seragam.
Anda ingin memangkas biaya dan latensi dengan mengajari model kecil melakukan tugas spesifik sama baiknya dengan model besar yang di-prompt panjang. Fine-tuning model kecil bisa lebih murah per query dalam volume tinggi.
Tugasnya sempit, berulang, dan stabil — pola yang sama jutaan kali, di mana investasi pelatihan terbayar oleh penghematan jangka panjang.
Anda perlu mengajari model format atau domain yang sangat khusus yang tidak dikenalnya, seperti notasi internal atau struktur data tertentu.
Yang penting: fine-tuning menuntut dataset berkualitas tinggi dalam jumlah memadai, dan biaya pemeliharaan setiap kali kebutuhan berubah. Jika data Anda berantakan atau tugasnya masih bergerak, fine-tuning akan menjadi beban, bukan aset.
Berikut alur keputusan yang bisa Anda jalankan untuk masalah nyata:
Sudahkah prompt engineering dieksploitasi penuh? Jika belum, lakukan dulu. Sering kali berhenti di sini.
Apakah masalahnya tentang pengetahuan spesifik/terkini/privat? Jika ya, RAG. Ini menjawab mayoritas kebutuhan enterprise.
Apakah masalahnya tentang gaya/format/perilaku konsisten yang gagal dicapai prompt, dan Anda punya data berkualitas? Jika ya, pertimbangkan fine-tuning.
Apakah Anda butuh memangkas biaya/latensi pada tugas sempit bervolume tinggi? Fine-tuning model kecil bisa membayar dirinya sendiri.
Dan yang sering terlupakan: ketiganya tidak saling eksklusif. Sistem produksi yang matang sering menggabungkan prompt engineering yang baik, RAG untuk pengetahuan, dan — pada kasus tertentu — model yang di-fine-tune untuk satu komponen spesifik. Pertanyaannya bukan "mana yang menang", melainkan "kombinasi apa yang menyelesaikan masalah ini dengan biaya total terendah".
Keputusan ini sering dibuat dengan hanya melihat biaya membangun, padahal biaya yang sesungguhnya menggigit adalah biaya pemeliharaan.
Prompt engineering punya biaya pemeliharaan terendah: ubah teks, selesai. Tetapi pada volume sangat tinggi, prompt panjang menambah biaya token per query.
RAG menambah infrastruktur (vector database, pipeline ingestion, re-indexing) dan biaya retrieval per query, tetapi pembaruan pengetahuan murah — cukup perbarui dokumen.
Fine-tuning punya biaya pelatihan di muka, dan setiap perubahan kebutuhan menuntut pelatihan ulang serta pengelolaan versi model. Ini biaya yang mudah diremehkan di awal dan menyakitkan di kemudian hari.
Untuk konteks Indonesia, tambahkan satu dimensi: kedaulatan data. Jika data Anda sensitif dan tunduk pada UU PDP, pilihan teknik berinteraksi dengan pilihan deployment. Fine-tuning model open-source yang di-hosting sendiri bisa menjadi cara menjaga data tetap di dalam negeri, sementara RAG memungkinkan Anda mengontrol secara presisi data apa yang dikirim ke model di setiap query.
Diskusi tentang fine-tuning, RAG, dan prompt engineering sering berhenti pada akurasi dan biaya, padahal latensi sama pentingnya bagi produk yang dipakai manusia secara langsung. Pengguna yang menunggu terlalu lama akan meninggalkan sistem, sehebat apa pun jawabannya.
Setiap teknik punya profil latensi yang berbeda:
Prompt panjang menambah waktu. Few-shot examples dan instruksi yang panjang memang meningkatkan kualitas, tetapi juga menambah token yang harus diproses, sehingga memperlambat respons. Ada titik di mana prompt yang lebih ringkas dengan model yang di-fine-tune memberi pengalaman lebih cepat.
RAG menambah langkah retrieval. Setiap query RAG menanggung biaya waktu untuk pencarian dan, jika dipakai, reranking, sebelum model mulai menjawab. Pada sistem yang dioptimalkan ini biasanya hanya puluhan milidetik, tetapi retrieval yang lambat atau berlebihan bisa terasa oleh pengguna.
Fine-tuning bisa menurunkan latensi. Salah satu alasan kuat fine-tuning adalah memampukan model kecil dan cepat melakukan tugas yang biasanya menuntut model besar dengan prompt panjang. Untuk tugas sempit bervolume tinggi, ini bisa berarti respons yang jauh lebih cepat sekaligus lebih murah.
Untuk produk yang dipakai pelanggan secara real-time — chatbot, asisten checkout, pencarian — anggaran latensi harus masuk ke keputusan teknik sejak awal, bukan ditambal belakangan. Solusi yang akurat tetapi lambat sering kalah dari solusi yang sedikit kurang akurat tetapi terasa responsif, karena pengguna menilai pengalaman, bukan hanya jawaban.
Pesan inti artikel ini sederhana: jangan memilih teknik berdasarkan apa yang sedang populer atau terdengar paling canggih. Diagnosis dulu sifat masalahnya — apakah ini soal pengarahan, pengetahuan, atau perilaku — lalu pilih alat yang sesuai, mulai dari yang termurah. Tim yang mendisiplinkan diri dengan urutan ini membangun produk AI yang lebih cepat, lebih murah, dan lebih mudah dirawat daripada tim yang langsung melompat ke solusi paling kompleks.
Karena ketiga teknik ini sering disajikan sebagai pilihan yang saling bersaing, mudah lupa bahwa sistem produksi yang matang justru memadukannya. Memahami bagaimana mereka bertumpuk membantu Anda merancang solusi yang utuh, bukan menambal satu teknik untuk masalah yang sebenarnya milik teknik lain.
Bayangkan sebuah asisten layanan untuk perusahaan asuransi di Indonesia. Sistemnya bisa tersusun seperti ini:
Prompt engineering menetapkan persona, nada bicara yang sesuai brand, format jawaban, dan aturan keras seperti "jangan pernah menjanjikan persetujuan klaim". Ini lapisan pengarahan yang murah dan mudah diubah.
RAG menambatkan setiap jawaban pada dokumen polis, ketentuan klaim, dan regulasi terbaru — memastikan jawaban akurat, terkini, dan dapat dirujuk ke sumber. Ini menjawab kebutuhan pengetahuan.
Model yang di-fine-tune mungkin dipakai pada satu komponen sempit, misalnya mengklasifikasikan jenis pertanyaan masuk dengan cepat dan murah, di mana sebuah model kecil yang terlatih mengungguli model besar yang di-prompt panjang dalam hal biaya dan latensi.
Yang penting dari contoh ini: tidak ada satu teknik yang "menang". Masing-masing menyelesaikan bagian masalah yang menjadi keahliannya. Tugas arsitek adalah memetakan setiap kebutuhan ke teknik yang paling efisien menyelesaikannya, lalu merangkai semuanya menjadi sistem yang koheren dan mudah dirawat.
Beberapa kekeliruan dalam memilih teknik begitu sering terjadi dan begitu mahal sehingga layak disorot tersendiri sebagai peringatan.
Fine-tuning untuk pengetahuan yang berubah. Ini kesalahan paling mahal. Melatih model agar "hafal" kebijakan atau harga yang berubah tiap bulan berarti melatih ulang tanpa henti, dan model tetap tidak bisa menunjukkan sumber. Hampir selalu, RAG adalah jawaban yang benar di sini.
RAG untuk masalah yang sebenarnya gaya. Jika keluhannya adalah "nada jawaban tidak konsisten" atau "formatnya berantakan", menambah dokumen ke konteks tidak akan menolong. Itu masalah perilaku — perbaiki dengan prompt yang lebih baik, atau fine-tuning jika perlu konsistensi pada skala.
Melompati prompt engineering. Berinvestasi pada infrastruktur RAG atau biaya fine-tuning sebelum membuktikan bahwa prompt yang baik tidak cukup adalah pemborosan waktu dan uang yang sangat umum. Selalu kuras opsi termurah lebih dulu.
Mengabaikan biaya pemeliharaan. Memilih fine-tuning karena terlihat canggih, lalu terjebak melatih ulang setiap kali kebutuhan bergeser, adalah penyesalan klasik. Hitung biaya merawat solusi selama dua tahun, bukan hanya biaya membangunnya.
Menghindari empat kesalahan ini saja sudah menempatkan tim Anda jauh di depan mayoritas proyek AI yang gagal karena salah mendiagnosis masalah sejak awal.
Memilih antara fine-tuning, RAG, dan prompt engineering adalah keputusan arsitektur yang menentukan biaya, akurasi, dan beban pemeliharaan produk AI Anda selama bertahun-tahun. Pilihan yang tepat lahir dari diagnosis masalah yang tajam, bukan dari mengikuti tren — dan sering kali jawabannya adalah kombinasi yang dirancang dengan cermat.
Sainskerta Solusi Nusantara membantu enterprise Indonesia memetakan masalah ke teknik yang paling tepat, dari strategi hingga implementasi, dengan mempertimbangkan biaya total, latensi, kepatuhan, dan kedaulatan data. Jika Anda ingin kepastian sebelum berinvestasi besar di salah satu jalur, jadwalkan sesi konsultasi dengan tim kami lewat halaman Kontak. Kami akan membantu Anda memilih dengan dasar yang kuat, sehingga setiap Rupiah yang Anda investasikan benar-benar menyelesaikan masalah yang tepat.
