"Kami Ingin Chatbot yang Paham SOP Kami"
Permintaan ini makin sering kami dengar. Tim operasional lelah menjawab pertanyaan yang sama: prosedur retur, kebijakan cuti, cara mengisi formulir klaim. Jawabannya sebenarnya sudah ada di dokumen internal, tetapi tersebar di PDF, Google Drive, dan grup WhatsApp.
Model bahasa seperti ChatGPT tidak mengenal dokumen internal Anda. Melatih ulang model dengan dokumen perusahaan mahal, lambat, dan harus diulang setiap kali dokumen berubah. Di sinilah Retrieval-Augmented Generation (RAG) masuk. Di post sebelumnya kami membahas perbedaan chatbot dan AI agent. Post ini fokus pada satu jenis chatbot yang paling sering diminta: chatbot yang menjawab dari dokumen Anda sendiri.
Cara Kerja RAG dalam Bahasa Sederhana
Istilah RAG berasal dari makalah Lewis dkk. (2020) yang menggabungkan model bahasa dengan "memori" eksternal berupa indeks dokumen. Para penulisnya mencatat bahwa model bahasa menyimpan pengetahuan di dalam parameternya, tetapi sulit menunjukkan sumber jawabannya dan sulit diperbarui. Memisahkan pengetahuan ke indeks dokumen menyelesaikan kedua masalah itu.
Dalam praktik, alurnya terdiri dari dua tahap.
Tahap 1: Menyiapkan Dokumen (Indexing)
- Kumpulkan dokumen yang boleh dijawab chatbot: SOP, FAQ, kebijakan, katalog produk.
- Pecah menjadi potongan (chunk) beberapa paragraf. Satu SOP panjang bisa menjadi puluhan potongan.
- Ubah setiap potongan menjadi embedding, yaitu representasi angka dari makna teks.
- Simpan di vector store, database yang bisa mencari teks berdasarkan kemiripan makna, bukan hanya kata yang sama.
Banyak penyedia sudah menyediakan tahap ini sebagai layanan terkelola. Retrieval API OpenAI, misalnya, menangani pemotongan dan embedding saat file diunggah ke vector store, lalu mengembalikan potongan relevan beserta skor kemiripan dan file asalnya.
Tahap 2: Menjawab Pertanyaan (Retrieval + Generation)
- Pengguna bertanya, misalnya "Berapa lama batas retur barang cacat?"
- Sistem mencari potongan dokumen yang paling mirip maknanya dengan pertanyaan itu.
- Potongan tersebut dimasukkan ke prompt bersama instruksi: "Jawab hanya berdasarkan konteks berikut. Jika tidak ada, katakan tidak tahu."
- Model bahasa menyusun jawaban dan, idealnya, menyebutkan dokumen sumbernya.
Kuncinya: model tidak "belajar" dokumen Anda. Ia membaca potongan yang relevan setiap kali menjawab. Saat SOP diperbarui, Anda cukup memperbarui indeksnya.
Kapan FAQ Biasa Sudah Cukup
RAG bukan jawaban untuk semua kebutuhan. Sebelum membangunnya, kami selalu bertanya: seberapa beragam pertanyaannya?
FAQ atau chatbot berbasis menu sudah cukup jika:
- Pertanyaannya sedikit dan berulang, misalnya jam buka, ongkos kirim, atau cara reset password.
- Jawabannya harus persis sama setiap kali, misalnya terkait harga atau ketentuan hukum.
- Dokumennya jarang berubah dan bisa dirangkum dalam satu halaman.
RAG layak dipertimbangkan jika:
- Dokumennya banyak dan panjang, sehingga orang kesulitan menemukan bagian yang relevan.
- Pertanyaan pengguna beragam dan diucapkan dengan cara yang tidak bisa ditebak.
- Pengguna utamanya internal (staf CS, tim operasional) yang bisa memverifikasi jawaban.
Kami sering menyarankan memulai dari chatbot internal untuk staf, bukan untuk pelanggan. Jika jawabannya keliru, staf bisa mengecek sumbernya sebelum meneruskan ke pelanggan. Ini cara aman untuk mengukur kualitas sebelum chatbot berbicara langsung ke publik.
Risiko 1: Jawaban yang Salah dengan Percaya Diri
RAG mengurangi halusinasi, tetapi tidak menghilangkannya. Penyebab yang paling sering kami temui:
- Dokumen sumber saling bertentangan. SOP versi lama dan baru sama-sama ada di folder. Sistem bisa mengambil versi yang salah.
- Potongan yang terlepas dari konteks. Kalimat "berlaku 14 hari" tanpa judul bagiannya bisa merujuk ke hal yang berbeda.
- Pertanyaan di luar cakupan dokumen. Tanpa instruksi tegas, model akan mengisi kekosongan dari pengetahuan umumnya.
Solusi:
- Bersihkan dokumen sebelum diindeks. Satu topik, satu dokumen berlaku. Arsipkan versi lama di luar indeks.
- Simpan metadata per dokumen (judul, departemen, tanggal berlaku) dan sertakan judul bagian di setiap potongan.
- Wajibkan chatbot menampilkan sumber dan mengatakan "saya tidak menemukan informasinya" saat konteks tidak cukup.
- Siapkan daftar pertanyaan uji dari pertanyaan nyata tim Anda, beserta jawaban yang benar. Jalankan ulang setiap kali dokumen atau prompt berubah.
Risiko 2: Kebocoran Data Lewat Chatbot
Risiko ini lebih jarang dibicarakan, padahal dampaknya lebih besar. OWASP memasukkannya ke Top 10 risiko aplikasi LLM 2025 sebagai Vector and Embedding Weaknesses. Beberapa skenario yang mereka uraikan:
- Akses tidak sah. Jika kontrol akses di vector store tidak selaras dengan dokumen aslinya, chatbot bisa mengambil dan menampilkan data pribadi atau informasi rahasia.
- Kebocoran antar-konteks. Saat beberapa kelompok pengguna berbagi satu vector database, potongan milik satu kelompok bisa muncul di jawaban untuk kelompok lain.
- Data poisoning. Dokumen yang dimasukkan pihak tidak tepercaya bisa memuat instruksi tersembunyi yang memanipulasi jawaban.
Contoh nyatanya sederhana: dokumen gaji HR dan SOP gudang diindeks di tempat yang sama. Staf gudang bertanya soal lembur, dan chatbot dengan senang hati mengutip tabel gaji.
Solusi:
- Ikuti izin dokumen aslinya. Simpan informasi akses (departemen, peran) sebagai atribut setiap dokumen, lalu filter pencarian berdasarkan identitas pengguna. Retrieval API OpenAI, misalnya, mendukung attribute filtering untuk menyaring file sebelum pencarian semantik.
- Pisahkan indeks untuk kelompok data yang sensitif, alih-alih mengandalkan prompt seperti "jangan tampilkan data gaji". Prompt bukan kontrol akses.
- Hanya masukkan dokumen dari sumber tepercaya, dan audit isi indeks secara berkala.
- Catat pertanyaan dan dokumen yang diambil agar Anda bisa menelusuri jawaban yang bermasalah.
Jika dokumen Anda memuat data pribadi pelanggan atau karyawan, kewajiban UU PDP juga berlaku, termasuk saat data dikirim ke penyedia AI di luar negeri. Kami membahasnya di checklist UU PDP untuk aplikasi web.
Membangun Sendiri atau Memakai Layanan Jadi?
Ada spektrum pilihan:
- Fitur bawaan platform yang sudah Anda pakai (asisten di workspace dokumen atau helpdesk). Cepat, tetapi terbatas pada dokumen di platform itu.
- Layanan RAG terkelola dari penyedia model, dengan vector store dan pencarian siap pakai. Anda tetap membangun antarmuka, kontrol akses, dan integrasinya.
- Pipeline kustom dengan pilihan embedding, database, dan model sendiri. Paling fleksibel, misalnya jika data harus tetap di server Anda, tetapi butuh pemeliharaan paling banyak.
Kerangka build vs. buy kami berlaku di sini. Untuk sebagian besar bisnis, kami menyarankan mulai dari layanan terkelola, lalu beralih ke kustom hanya jika ada kebutuhan konkret seperti lokasi data atau biaya pada volume tinggi.
Checklist Sebelum Meluncurkan Chatbot RAG
- Cakupan jelas: pertanyaan apa yang boleh dan tidak boleh dijawab.
- Dokumen sudah dibersihkan, tanpa versi ganda, dan punya pemilik yang memperbaruinya.
- Kontrol akses mengikuti izin dokumen asli, diterapkan di tahap pencarian.
- Jawaban menyertakan sumber; chatbot berani bilang "tidak tahu".
- Daftar pertanyaan uji dengan jawaban yang benar, dijalankan ulang setiap perubahan.
- Log pertanyaan dan dokumen yang diambil, ditinjau rutin.
- Jalur eskalasi ke manusia untuk pertanyaan yang tidak terjawab.
Pendekatan AY Labs
Kami memulai proyek chatbot RAG dari dokumen, bukan dari model. Langkah pertama adalah memetakan dokumen yang ada, siapa yang boleh membacanya, dan pertanyaan apa yang paling sering muncul di tim Anda. Dari situ kami menyusun daftar pertanyaan uji sebelum menulis satu baris kode, sehingga kualitas jawaban bisa diukur, bukan sekadar dirasakan. Kami membangun kontrol akses di lapisan pencarian, menampilkan sumber di setiap jawaban, dan biasanya meluncurkan untuk staf internal terlebih dahulu. Jika Anda sedang menimbang apakah dokumen internal Anda siap dijadikan chatbot, atau FAQ biasa sebenarnya sudah cukup, kami siap membantu menilainya.
