← Blog · Playbook · 10 min read
Banyak tim Indonesia berhenti di demo RAG yang mengesankan tapi gagal ke produksi. Panduan ini memetakan jalur lengkap dari pilot hingga sistem yang andal, murah, dan patuh regulasi.
A 30-minute scoping call. We listen, ask three questions, tell you if we can help.
Book a callHampir setiap tim engineering di Indonesia yang menyentuh AI generatif punya satu pengalaman serupa: sebuah demo Retrieval-Augmented Generation (RAG) yang mengesankan di hadapan direksi. Pertanyaan dijawab dengan rapi, sumber dokumen muncul, ruangan terkesan. Lalu proyek itu mati pelan-pelan. Tiga bulan kemudian, jawaban mulai ngawur ketika pertanyaan keluar dari skenario demo, biaya per query membengkak tanpa terpantau, dan tim legal mulai bertanya soal data nasabah yang dikirim ke API pihak ketiga.
Jarak antara demo yang memukau dan sistem produksi yang andal jauh lebih besar daripada yang terlihat. Demo hanya perlu benar sekali; produksi harus benar ribuan kali sehari, di hadapan pengguna nyata, dengan anggaran nyata dan regulator nyata. Panduan ini memetakan jalur lengkap dari pilot dua minggu hingga sistem RAG yang murah, terukur, dan patuh — khusus untuk konteks enterprise Indonesia.
Kesalahan paling umum adalah memulai dengan memilih vector database atau model sebelum memahami pertanyaan apa yang sebenarnya ingin dijawab sistem. RAG bukan tujuan; ia alat untuk memetik jawaban dari korpus pengetahuan yang terlalu besar atau terlalu sering berubah untuk dimuat ke dalam prompt.
Sebelum menulis baris kode pertama, kunci tiga hal:
Jenis pertanyaan. Apakah pengguna bertanya fakta tunggal ("Berapa limit transfer harian rekening Tabungan Bisnis?"), ringkasan ("Rangkum perubahan kebijakan kredit Q2"), atau penalaran lintas dokumen ("Bandingkan syarat klaim polis A dan B")? Ketiganya butuh strategi retrieval yang berbeda.
Sumber kebenaran. Dokumen mana yang otoritatif? Siapa pemiliknya? Seberapa sering berubah? Jika tidak ada yang bertanggung jawab atas akurasi sumber, RAG hanya akan menyebarkan kesalahan lebih cepat.
Definisi "benar". Bagaimana Anda tahu jawaban itu benar? Tanpa kriteria ini, Anda tidak akan pernah bisa mengukur, dan tanpa pengukuran Anda tidak akan pernah berani naik ke produksi.
Pilot dua minggu yang ideal bukan untuk membuktikan bahwa RAG "bisa", melainkan untuk membuktikan bahwa ia bisa pada 30–50 pertanyaan paling penting dan paling sering muncul. Kumpulkan pertanyaan nyata dari tim CS, sales, atau operasional — bukan pertanyaan yang Anda karang sendiri agar terlihat bagus.
Cara Anda memecah dokumen menjadi potongan (chunk) menentukan langit-langit kualitas sistem. Chunk terlalu besar membuat retrieval mengembalikan banyak konteks tidak relevan dan menaikkan biaya token. Chunk terlalu kecil memotong konteks penting sehingga model kehilangan benang merah.
Beberapa prinsip yang terbukti di lapangan:
Hormati struktur dokumen. Pecah berdasarkan heading, pasal, atau bagian logis — bukan sekadar setiap 500 token. Dokumen Indonesia seperti Surat Edaran, SOP, atau perjanjian kredit punya struktur pasal-ayat yang harus dipertahankan.
Tambahkan konteks ke setiap chunk. Sisipkan judul dokumen, nama bab, dan tanggal berlaku ke dalam metadata atau awal chunk. Tanpa ini, sebuah potongan yang berbunyi "denda sebesar 2%" menjadi tak bermakna karena model tidak tahu denda atas apa.
Pertimbangkan overlap secukupnya. Tumpang tindih 10–15% antar chunk membantu menjaga kalimat yang terpotong di batas, tetapi overlap berlebihan hanya menggandakan biaya penyimpanan dan retrieval.
Kualitas RAG ditentukan jauh sebelum model dipanggil — ia ditentukan saat dokumen dipecah dan diindeks. Garbage in, garbage out berlaku ganda di sini.
Banyak tim Indonesia membangun RAG hanya dengan pencarian semantik (dense vector) dan kecewa ketika sistem gagal menemukan dokumen yang jelas-jelas mengandung kata kunci spesifik. Masalahnya, embedding pandai menangkap makna tetapi lemah pada istilah eksak: nomor polis, kode produk, nama orang, singkatan internal, atau istilah teknis yang jarang.
Pendekatan yang lebih andal adalah retrieval hybrid yang menggabungkan dua sinyal:
Pencarian leksikal (BM25 / full-text search) untuk menangkap kecocokan kata kunci eksak.
Pencarian semantik (dense embedding) untuk menangkap makna dan parafrasa.
Hasil keduanya digabung dan diurutkan ulang. Langkah berikutnya yang sering memberi lonjakan kualitas terbesar adalah reranking: ambil 20–50 kandidat teratas dari retrieval, lalu gunakan model reranker khusus untuk memilih 3–5 chunk paling relevan. Reranker jauh lebih akurat dalam menilai relevansi daripada skor kemiripan vektor mentah, dan karena hanya beroperasi pada sedikit kandidat, biayanya terkendali.
Untuk Bahasa Indonesia, perhatikan satu hal khusus: banyak embedding model dilatih dominan pada bahasa Inggris. Uji model embedding Anda pada pertanyaan dan dokumen Bahasa Indonesia nyata sebelum berkomitmen. Selisih kualitas antar model bisa dramatis pada konten lokal.
Inilah pembeda terbesar antara tim yang lolos ke produksi dan tim yang mandek. Tanpa evaluasi terukur, Anda tidak punya cara objektif untuk mengetahui apakah perubahan kode membuat sistem lebih baik atau lebih buruk.
Bangun golden dataset: kumpulan 50–200 pasangan pertanyaan dan jawaban referensi yang sudah diverifikasi oleh ahli domain (misalnya tim kepatuhan untuk produk perbankan). Setiap kali Anda mengubah prompt, model, strategi chunking, atau parameter retrieval, jalankan ulang seluruh golden dataset dan ukur dampaknya.
Metrik yang relevan untuk RAG mencakup:
Faithfulness / groundedness — apakah jawaban benar-benar didukung oleh dokumen yang diambil, atau model mengarang? Ini metrik anti-halusinasi terpenting.
Context relevance — apakah chunk yang diambil memang relevan dengan pertanyaan? Mengukur kualitas retrieval terpisah dari kualitas generasi.
Answer relevance — apakah jawaban benar-benar menjawab pertanyaan yang diajukan?
Completeness — apakah jawaban mencakup semua poin penting, bukan hanya sebagian?
Banyak metrik ini bisa dinilai otomatis dengan teknik LLM-as-judge: gunakan model untuk menilai output model lain berdasarkan rubrik ketat. Ini tidak sempurna, tetapi jauh lebih konsisten dan dapat diskalakan daripada penilaian manusia ad hoc, dan cukup baik untuk dijadikan gerbang regresi sebelum rilis.
Di demo, tidak ada yang peduli biaya. Di produksi dengan puluhan ribu query per hari, biaya menentukan apakah proyek bertahan. Pecah biaya per query menjadi komponennya: embedding pertanyaan, retrieval, reranking, dan — yang terbesar — token input dan output ke LLM generator.
Lever penghematan yang paling efektif:
Kontrol jumlah chunk yang dikirim ke model. Mengirim 10 chunk "untuk amannya" bisa melipatgandakan biaya tanpa menaikkan akurasi. Reranking yang baik memungkinkan Anda mengirim lebih sedikit chunk dengan kualitas lebih tinggi.
Prompt caching untuk bagian prompt yang statis (instruksi sistem, contoh few-shot) bisa memangkas biaya input secara signifikan pada beban tinggi.
Model routing. Pertanyaan sederhana tidak butuh model termahal. Arahkan pertanyaan mudah ke model lebih kecil dan murah, sisakan model premium untuk kasus kompleks.
Sebagai gambaran kasar, sistem RAG enterprise yang dioptimalkan biasanya bisa mencapai biaya beberapa ratus hingga seribuan Rupiah per query — angka yang sangat layak dibandingkan biaya tenaga manusia untuk menjawab pertanyaan yang sama. Tetapi tanpa optimisasi, angka itu bisa berlipat lima hingga sepuluh kali. Pantau biaya per query sebagai metrik produk, bukan sekadar baris di tagihan akhir bulan.
Sistem yang siap produksi butuh lapisan yang sama sekali tidak terlihat di demo:
Penanganan "tidak tahu". Sistem harus berani menjawab "informasi ini tidak tersedia dalam dokumen" ketika retrieval tidak menemukan konteks yang memadai. Jawaban salah yang percaya diri jauh lebih berbahaya daripada pengakuan tidak tahu, terutama di sektor regulasi.
Citation wajib. Setiap jawaban menampilkan sumber dokumen dan bagiannya. Ini memungkinkan pengguna memverifikasi dan membangun kepercayaan — sekaligus menjadi mekanisme audit.
Guardrail input dan output. Saring upaya prompt injection lewat dokumen, dan filter output agar tidak membocorkan data yang tidak seharusnya.
Observability. Lacak setiap query: pertanyaan, chunk yang diambil, jawaban, biaya, latensi. Ketika kualitas menurun, Anda butuh jejak ini untuk mendiagnosis.
Siklus update konten. Knowledge base bukan benda mati. Tetapkan proses re-indexing ketika dokumen sumber berubah, dan pemilik yang bertanggung jawab atas kesegaran data.
Untuk enterprise Indonesia, kepatuhan bukan renungan belakangan. UU Perlindungan Data Pribadi No. 27 Tahun 2022 menetapkan kewajiban nyata yang menyentuh langsung arsitektur RAG Anda.
Beberapa pertimbangan kunci:
Lokasi pemrosesan data. Jika dokumen Anda mengandung data pribadi nasabah, ke mana data itu dikirim saat embedding dan generasi? API LLM global memproses data di luar negeri. Untuk data sensitif, pertimbangkan model yang di-hosting di region Indonesia, atau deployment on-premise.
Minimisasi data. Jangan kirim lebih banyak data pribadi ke model daripada yang benar-benar dibutuhkan. Redaksi atau masking field sensitif sebelum dikirim ke LLM bila memungkinkan.
Dasar hukum pemrosesan dan retensi. Pastikan ada dasar pemrosesan yang sah, dan tetapkan kebijakan retensi untuk log query yang mungkin memuat data pribadi.
Jejak audit. Sektor yang diawasi OJK menuntut kemampuan menjelaskan dari mana sebuah jawaban berasal. Citation dan logging yang Anda bangun untuk kualitas sekaligus melayani kebutuhan audit ini.
Mengabaikan dimensi ini bukan hanya risiko hukum — ia adalah penyebab utama proyek AI diveto di tahap akhir oleh tim legal atau risiko, setelah anggaran terlanjur terpakai.
Banyak tim membayangkan transisi ke produksi sebagai satu lompatan besar. Pada praktiknya, jalur yang berhasil adalah serangkaian fase yang masing-masing menambah lapisan keandalan di atas fondasi yang sudah terbukti.
Fase pertama, pilot tertutup, fokus membuktikan kualitas pada 30–50 pertanyaan inti dengan arsitektur paling sederhana yang mungkin: satu sumber dokumen, retrieval dasar, dan model yang Anda kenal. Tujuannya bukan kelengkapan, melainkan menjawab satu pertanyaan: apakah pendekatan ini layak diteruskan? Banyak ide gagal di sini, dan itu kabar baik — Anda gagal murah dan cepat.
Fase kedua, beta terbatas, membuka sistem ke kelompok pengguna nyata yang kecil, biasanya tim internal yang memahami bahwa ini masih eksperimen. Di sinilah Anda menambahkan citation, penanganan "tidak tahu", logging menyeluruh, dan golden dataset awal. Trafik nyata akan menunjukkan pola pertanyaan yang tidak pernah Anda bayangkan, dan setiap kegagalan menjadi bahan perbaikan.
Fase ketiga, produksi penuh, baru dilakukan setelah metrik evaluasi stabil dan tim percaya pada keandalan sistem. Di tahap ini, hardening lengkap, kontrol akses, observability, alerting, dan kepatuhan harus sudah matang, bukan menyusul.
Pendekatan bertahap ini menghindari dua kegagalan klasik: meluncurkan terlalu cepat sehingga pengguna kehilangan kepercayaan pada minggu pertama, atau menyempurnakan tanpa henti sehingga proyek tidak pernah benar-benar lahir. Tetapkan kriteria keluar yang jelas untuk setiap fase, dan biarkan data — bukan tekanan jadwal — yang menentukan kapan naik ke fase berikutnya.
Dari banyak proyek RAG enterprise di Indonesia, beberapa pola kegagalan muncul berulang-ulang. Mengenalinya lebih awal menghemat berbulan-bulan kerja yang terbuang.
Mengabaikan kualitas sumber. Tim sering menganggap dokumen perusahaan sudah rapi, padahal sering kali penuh duplikat, versi usang yang bertentangan, dan PDF hasil scan yang sulit dibaca mesin. RAG akan dengan setia menyajikan kekacauan ini sebagai jawaban. Bersihkan dan tata sumber sebelum membangun di atasnya.
Tidak ada pemilik konten. Tanpa orang yang bertanggung jawab menjaga dokumen tetap akurat dan terbarui, knowledge base membusuk perlahan dan akurasi sistem ikut turun. Ini masalah tata kelola, bukan masalah teknis.
Melewati evaluasi karena terburu-buru. Tekanan untuk segera meluncurkan membuat tim melompati pembuatan golden dataset. Akibatnya, setiap perubahan menjadi tebakan dan regresi tidak terdeteksi sampai pengguna mengeluh.
Menyalin arsitektur orang lain. Apa yang berhasil untuk sebuah startup di Silicon Valley belum tentu cocok untuk bank di Jakarta dengan kebutuhan kepatuhan dan kedaulatan data yang berbeda. Arsitektur harus lahir dari konteks Anda.
Tidak memantau biaya sejak awal. Tagihan kejutan di akhir bulan sering menjadi alasan proyek dihentikan. Jadikan biaya per query metrik yang dipantau harian, bukan dilihat sekali sebulan.
Kabar baiknya, semua jebakan ini dapat dihindari dengan perencanaan yang disiplin. Tim yang berhasil bukan yang punya model terbaik, melainkan yang paling teliti pada hal-hal membosankan: kualitas data, evaluasi, observability, dan tata kelola.
Membangun RAG yang bertahan di produksi adalah disiplin rekayasa, bukan sekadar memanggil API. Dari scoping yang tajam, chunking yang menghormati struktur dokumen Indonesia, retrieval hybrid, evaluasi terukur, hingga kepatuhan UU PDP — setiap lapisan menentukan apakah sistem Anda menjadi aset terpercaya atau demo yang dilupakan.
Sainskerta Solusi Nusantara mendampingi enterprise Indonesia melewati seluruh siklus ini, dari strategi dan desain hingga build dan operate. Jika tim Anda punya pilot RAG yang menjanjikan tetapi belum tahu cara membawanya ke produksi dengan andal dan patuh, jadwalkan sesi konsultasi dengan tim kami melalui halaman Kontak. Kami akan membantu Anda menyusun jalur konkret dari demo hari ini menuju sistem yang dipercaya pengguna dan diterima regulator.
