RAG untuk Data Perusahaan: Bikin AI Paham Konteks Bisnis Kamu

RAG (Retrieval-Augmented Generation) adalah cara bikin AI jawab pertanyaan pakai dokumen milik perusahaan kamu, bukan cuma dari pengetahuan umum yang dia pelajari waktu training.

Kenapa ini penting? Coba tanya ChatGPT: "Berapa lama SLA pengiriman ke Makassar di perusahaan aku?" Dia gak akan tau. Dan yang bahaya, kadang dia tetap jawab dengan percaya diri — padahal ngarang.

RAG nutup lubang itu. Dokumen internal kamu yang jadi bahan jawabannya.

Apa itu RAG?

RAG adalah teknik yang nyambungin model AI ke sumber dokumen milik kamu. Pas ada pertanyaan masuk, sistem nyari dulu potongan dokumen yang paling relevan, terus nyuruh AI nyusun jawaban cuma dari potongan itu. Jadi AI gak jawab dari ingatan, tapi dari bahan yang baru dia baca.

Nama panjangnya Retrieval-Augmented Generation. Retrieval = nyari. Generation = nyusun jawaban. Kata "augmented" di tengah artinya proses nyusun jawaban itu dibantu sama hasil pencarian.

Gimana cara kerja RAG?

Ada 5 langkah. Aku pakai contoh perusahaan distribusi yang punya 340 file SOP, katalog produk, dan panduan retur.

1. Chunking. Semua dokumen dipotong jadi potongan kecil, biasanya 300-800 kata per potongan. Satu SOP 12 halaman bisa jadi 25 potongan.
2. Embedding. Tiap potongan diubah jadi deretan angka yang mewakili maknanya. Potongan tentang "retur barang rusak" dan "komplain produk cacat" bakal punya angka yang berdekatan, walaupun katanya beda.
3. Simpan. Angka-angka itu masuk ke vector database. Bisa pakai pgvector di PostgreSQL yang udah kamu punya, gak harus beli tool baru.
4. Retrieval. Pas ada pertanyaan, pertanyaannya juga diubah jadi angka. Sistem nyari 3-5 potongan dengan angka paling mirip.
5. Generation. Potongan itu ditempel ke prompt, terus AI diminta jawab cuma dari situ. Plus disuruh nyebut sumbernya.

Query retrieval-nya kelihatan kayak gini kalau pakai pgvector:

-- Cari 5 potongan dokumen paling mirip
SELECT
  d.judul,
  c.isi,
  1 - (c.embedding <=> :query_embedding) AS skor_kemiripan
FROM doc_chunks c
JOIN dokumen d ON d.id = c.dokumen_id
WHERE d.divisi = 'operasional'
  AND 1 - (c.embedding <=> :query_embedding) > 0.75
ORDER BY c.embedding <=> :query_embedding
LIMIT 5;

Operator <=> itu cosine distance — makin kecil, makin mirip. Filter divisi = 'operasional' penting biar orang gudang gak kebaca dokumen HRD. Kalau kamu belum familiar sama JOIN, itu cara gabungin dua tabel; di sini buat narik judul dokumen asalnya.

Kapan RAG kepake, kapan enggak?

Situasi	Pakai RAG?	Alasan
Tanya isi SOP internal	Ya	Dokumen sering berubah, AI gak mungkin hafal
Cari klausul di 200 kontrak	Ya	Volume terlalu besar buat dibaca manual
Bantu customer service jawab komplain	Ya	Jawaban harus nyambung sama kebijakan resmi
Hitung total penjualan Q2	Enggak	Itu kerjaan SQL, bukan RAG
Ubah gaya nulis AI jadi formal	Enggak	Itu urusan prompt atau fine-tuning
Data cuma 5 halaman	Enggak	Tempel aja langsung ke prompt, lebih murah

Poin terakhir sering kelewat. Kalau dokumen kamu muat di satu prompt, kamu gak butuh RAG. Kamu cuma butuh copy-paste.

Contoh kasus: RAG di toko_berkah

Toko_berkah punya 1.240 dokumen: deskripsi produk, panduan pemakaian, template balasan komplain, dan riwayat chat customer service selama 8 bulan.

Sebelum ada RAG, tim CS butuh rata-rata 6 menit 20 detik buat jawab pertanyaan teknis produk — mereka harus buka Google Drive, cari file, scroll. Sebagian pertanyaan malah dilempar ke owner.

Setelah dokumen dipotong jadi 4.180 chunk dan dimasukkin ke pgvector, waktu jawab turun ke 1 menit 45 detik. Yang lebih penting: pertanyaan yang dilempar ke owner turun dari 31 per minggu jadi 7.

Tapi ada yang menarik dari 200 pertanyaan pertama yang aku audit. 18 jawaban keliru. Semuanya gara-gara hal yang sama: dokumen lama yang belum dihapus. AI nyari potongan paling mirip, ketemu SOP versi 2023, dan jawab pakai kebijakan yang udah gak berlaku.

Pelajarannya: RAG cuma sebagus dokumen yang kamu kasih. Kalau arsip kamu berantakan, jawabannya juga berantakan.

Kesalahan umum waktu bangun RAG

Chunk kegedean. Motong dokumen jadi potongan 3.000 kata bikin satu chunk isinya 5 topik campur. Retrieval-nya jadi meleset. Mulai dari 500 kata dengan overlap 50 kata.

Gak ngasih izin bilang "gak tau". Kalau prompt kamu cuma bilang "jawab pertanyaan ini pakai konteks di bawah", AI bakal maksa jawab walaupun konteksnya gak nyambung. Tambahin: "Kalau konteks gak ngejawab, bilang gak ketemu di dokumen."

Gak nyimpen sumber. Jawaban tanpa link ke dokumen asal itu gak bisa diverifikasi. Simpan judul file dan nomor halaman di metadata tiap chunk.

Gak ada filter akses. Kalau semua chunk bisa keambil semua orang, data gaji bisa nongol di jawaban buat anak magang. Pasang filter metadata per divisi sejak awal.

Ngirim data sensitif ke API publik. Potongan dokumen tetap dikirim ke model sebagai konteks. Buat data pelanggan atau keuangan, cek dulu kebijakan penyedia model soal retensi data. Aku bahas detailnya di artikel keamanan data saat pakai AI.

FAQ

Apa bedanya RAG sama fine-tuning?

RAG nyuapin dokumen ke AI pas dia lagi jawab. Fine-tuning ngelatih ulang modelnya. Kalau kamu mau AI tau isi SOP yang sering berubah, pakai RAG — update dokumen tinggal ganti file. Fine-tuning lebih cocok buat ngubah gaya jawaban, bukan nambah pengetahuan baru.

Apakah data perusahaan aman kalau pakai RAG?

Tergantung model yang kamu pakai. Dokumen tetap di database kamu, tapi potongan relevan dikirim ke model tiap kali ada pertanyaan. Kalau modelnya API publik, potongan itu keluar dari jaringan kamu. Buat data sensitif, pakai model yang jalan di server sendiri.

Berapa biaya bikin RAG untuk perusahaan kecil?

Buat 500-2.000 dokumen, biaya embedding sekali jalan biasanya di bawah Rp 100.000. Yang jalan terus itu biaya query — sekitar Rp 300.000-800.000 per bulan kalau tim nanya 200 kali sehari. pgvector bisa numpang di Postgres yang udah ada.

Kenapa jawaban RAG kadang masih ngarang?

Biasanya potongan yang keambil gak relevan tapi AI tetap dipaksa jawab. Kasih instruksi eksplisit buat bilang gak tau, dan pasang ambang batas skor kemiripan biar chunk jelek gak keambil.

Apakah RAG butuh vector database khusus?

Gak wajib. Di bawah 10.000 chunk, pgvector di PostgreSQL biasa udah cukup dan responsnya masih di bawah 100 milidetik. Vector database khusus baru kepake pas jumlahnya jutaan.

Penutup

Yang perlu kamu inget:

• RAG bikin AI jawab dari dokumen kamu, bukan dari ingatan — dan jawabannya bisa dilacak sumbernya.
• Kualitas jawaban ditentukan kualitas arsip. Di toko_berkah, 18 dari 200 jawaban keliru gara-gara SOP lama yang belum dihapus.
• Kalau dokumen kamu muat di satu prompt, kamu belum butuh RAG.

Buat yang mau baca lebih teknis soal cara nyimpan dan nyari vektor, dokumentasi resmi pgvector lumayan lengkap dan gratis.

Kalau kamu mau paham dulu dasarnya sebelum bangun RAG, mampir ke glossary embedding buat ngerti gimana teks diubah jadi angka. Terus lanjut ke prompt engineering untuk analis data — prompt yang bagus tetap penting walaupun kamu udah pakai RAG.