RAG: AI Menjawab dari Data Bisnis Anda

RAG membantu AI menjawab dari dokumen dan data bisnis Anda. Sistem mencari sumber yang relevan lebih dulu, lalu memberi bahan itu kepada model untuk menulis jawaban. Hasilnya tetap perlu diuji: sumber bisa salah, usang, atau tidak boleh dilihat pengguna. Mulai dengan pertanyaan nyata, tampilkan rujukannya, dan siapkan jawaban saat informasi tidak ditemukan.

Dalam Retrieval-Augmented Generation (RAG), sistem mengambil bahan rujukan sebelum meminta model menyusun jawaban. Model diarahkan untuk menggunakan potongan data yang diberikan. Pengetahuan dari pelatihannya tidak dijadikan rujukan utama.

Bayangkan ujian dengan buku terbuka. Siswa mencari halaman yang relevan, lalu menyusun jawaban dengan rujukan tersebut. Urutan mencari sumber sebelum menulis jawaban menjadi dasar sistem RAG.

Bagaimana sumber data menjadi jawaban?

Saat pengguna bertanya, sistem menelusuri kumpulan sumber organisasi: dokumen, catatan basis data, kebijakan, dan spesifikasi produk. Potongan teks yang relevan diberikan kepada model bersama pertanyaan. Model kemudian diminta menjawab berdasarkan bahan tersebut.

Saya membangun sebuah asisten klasifikasi regulasi. Ia membantu bisnis menemukan kode klasifikasi resmi yang tepat untuk aktivitas mereka, memakai kumpulan sumber pemerintah resmi sebagai satu-satunya sumber kebenaran. Aturan sistem mewajibkan jawaban bertumpu pada bahan resmi yang ditemukan. Pemeriksaan tetap diperlukan untuk mendeteksi klaim model yang tidak didukung sumber. Setiap klaim harus bisa dilacak balik ke potongan teks yang diambil dari kumpulan sumber itu untuk pertanyaan yang sedang ditanyakan. Dengan cara ini, model boleh menyusun cara penyampaian, tetapi setiap fakta harus tetap memiliki dasar dalam sumber.

Kenapa jawaban tetap salah meski sumbernya tersedia?

Kelancaran tulisan tidak menjamin kebenaran jawaban. Model dapat menulis dengan meyakinkan meski bahan yang diterimanya tidak relevan. Jika pencarian mengambil tiga paragraf yang salah, model bisa menyusun jawaban keliru yang tetap terdengar masuk akal.

Jika jawaban RAG mengecewakan, periksa kualitas pencarian sebelum mengganti model. Model yang lebih besar atau instruksi yang lebih rinci tidak memperbaiki bahan rujukan yang salah. Ambil pertanyaan yang gagal, lalu tinjau potongan sumber yang diberikan kepada model. Pemeriksaan ini membantu menemukan apakah masalahnya terletak pada pencarian atau penyusunan jawaban.

Kapan pencarian kata dan makna perlu digabung?

Dua pendekatan pencarian berikut saling melengkapi.

Pencarian kata kunci (BM25, SQLite FTS5, Elasticsearch) mencocokkan kata dan frasa persis. Cepat, murah, dan presisi ketika kata-kata pengguna cocok dengan kata-kata di dokumen sumber. Ini terjadi lebih sering dari dugaan orang, terutama untuk terminologi domain, kode, dan nama produk yang butuh kecocokan persis.

Pencarian makna memakai embedding, representasi teks sebagai angka, untuk mencari kemiripan makna tanpa mengandalkan kata yang persis sama. Ia menemukan potongan teks yang menjawab "bagaimana cara membatalkan langganan" bahkan ketika dokumen sumber menulis "mengakhiri paket berulang." Inilah lapisan yang menyelamatkan pencarian saat pengguna tidak tahu kosakata internal bisnis.

Dipakai sendirian, masing-masing punya pola gagal yang bisa ditebak. Pencarian kata kunci melewatkan parafrase dan sinonim. Pencarian makna melewatkan kode, ID, dan istilah persis — kecocokan embedding hampir-tepat justru lebih buruk daripada tidak ada kecocokan sama sekali.

Di asisten regulasi tadi, teks resmi dan bahasa bisnis sehari-hari jarang memakai kata yang sama. Pencarian kata saja sering melewatkan jawaban yang tersedia. Dalam proyek tersebut, kedua pencarian dijalankan secara paralel. Hasilnya digabungkan dengan aturan skor yang menimbang kecocokan kata dan makna, tanpa panggilan LLM tambahan. Cara ini memberikan hasil yang lebih baik daripada masing-masing metode secara terpisah.

Aturan pengurutan hasil perlu diperhatikan bersama metode pencariannya. Menggunakan LLM untuk mengurutkan hasil menambah biaya dan waktu tunggu. Untuk proyek ini, fungsi skor yang disesuaikan dapat membuat keputusan tersebut secara konsisten. Panggilan model digunakan untuk menyusun jawaban.

Bagaimana pengguna bisa memeriksa jawabannya?

Tampilkan sumber agar pengguna dapat memeriksa dasar jawaban. Antarmuka dapat menyediakan rujukan, cuplikan bukti yang bisa dibuka, atau tautan langsung ke dokumen sumber.

Manfaatnya dua. Pengguna bisa memverifikasi klaim dengan satu klik, bukannya percaya begitu saja. Anda bisa mengaudit kenapa sistem berkata begitu ketika ada yang terlihat janggal.

Menampilkan bukti juga membantu pengelola menilai kualitas pencarian. Potongan yang tidak berkaitan dengan pertanyaan akan lebih mudah terlihat. Perbaiki pengambilan sumber jika masalahnya ada di sana, sebelum menyunting cara model menulis jawaban.

Kapan cukup memakai pencarian atau FAQ biasa?

Tidak semua sistem butuh ini. Kalau seluruh basis pengetahuan cukup kecil untuk muat dalam satu instruksi model (FAQ singkat, beberapa dokumen kebijakan), lewati pengambilan sumber dan taruh saja isinya langsung di konteks. Jika jawabannya sedikit dan jarang berubah, tabel rujukan atau aturan sederhana dapat lebih murah, cepat, dan mudah diperkirakan dibandingkan LLM. Dan kalau tidak ada sumber otoritatif untuk dijadikan pijakan, RAG hanya memberi cara berhalusinasi yang lebih meyakinkan. Selesaikan dulu masalah datanya.

RAG pantas dipakai ketika basis pengetahuan terlalu besar untuk satu instruksi model, sering berubah sehingga pelatihan lanjutan model perlu diulang terus-menerus, dan biaya dari satu jawaban salah cukup tinggi. "Berpijak pada sumber nyata" perlu bisa diverifikasi, bukan sekadar terdengar masuk akal.

Prinsip yang sama berlaku di luar RAG: menarik jawaban sistem dari tempat data yang sesungguhnya berada, bukan menebak, membuat dasbor operasional yang menghubungkan berbagai sistem bisa dipercaya juga. Jawaban yang dapat ditelusuri ke data sumber membantu pengguna mengambil keputusan, baik melalui percakapan dengan AI maupun laporan operasional.